TanStack Startとは?フルスタックReactフレームワークの特徴・使い方・デプロイ【2026年版】
TanStack Startは、TanStack RouterとViteを基盤に構築されたフルスタックのReactフレームワークです。フロントエンドとバックエンドを1つのプロジェクトで開発でき、サーバーサイドレンダリング(SSR)、ストリーミング、サーバー関数(Server Functions)、エンドツーエンドの型安全を備えます。Next.jsやRemixと同じメタフレームワークの系譜にありながら、型安全なルーティングとサーバー連携を強みにしています。本記事では、TanStack Startの特徴・セットアップ・Server Functions/Server Routesの書き方・各種プラットフォームへのデプロイ・Next.jsとの比較までを、2026年時点の最新情報とともに解説します。
まとめ:TanStack Startの要点
- 正体:TanStack Router+Vite基盤のフルスタックReactフレームワーク。Next.js/Remixの代替候補。
- 主な機能:ストリーミング対応SSR、完全に型推論されるルーティング、Server Functions(型安全RPC)、Server Routes(HTTP APIエンドポイント)。
- バージョン:2025年9月にv1.0リリース候補(RC)を発表後、2026年6月時点で
@tanstack/react-startは1.168系として継続リリース中。SolidJS版は2.0系ベータ。 - 始め方:
npm create @tanstack/start@latestでひな形を生成し、npm run devで起動。既定ポートは3000。 - デプロイ:Vercel・Netlify・Cloudflare Workers・Node.js・Bun・Dockerなど配備先を選ばない。
- 向き/不向き:型安全と開発者体験を重視する新規SPA/SSRに向く。成熟したエコシステムや実績の豊富さを最優先するなら現時点ではNext.jsが無難。
以下、各機能とコードを順に見ていきます。
TanStack Startとは何か(概要とバージョン状況)
TanStack Startは、ルーティングライブラリ「TanStack Router」とビルドツール「Vite」の上に構築された、フルスタックのReactフレームワークです。ページのルーティングとAPIの実装を単一プロジェクトで完結でき、SSRやサーバー関数といったサーバー側の処理もフレームワークが面倒を見ます。React向けが主軸ですが、SolidJS版も並行して開発されています。
TanStack Router+Viteを基盤にしたメタフレームワーク
最大の特徴は、ルーティングが完全に型推論される点です。ルートパラメータやクエリパラメータまで含めてコンパイル時に整合性が検査されるため、URLの不一致やデータ取得の型ずれをビルド時に検出できます。ビルドにViteを採用しているため、開発サーバーの起動とホットリロード(HMR)が速く、設定もVite互換の構成で扱えます。React Routerの作者が中心となるTanStackエコシステム(Router/Query/Tableなど)と統一的に組み合わせられる点も、既存のReact開発者にとって導入の障壁を下げます。Vite+Reactの環境構築そのものはVite+React+TypeScriptの開発環境構築も参考になります。
Next.js・Remixとの位置づけ
TanStack Startは、Next.jsやRemixと同じ「Reactのメタフレームワーク」というカテゴリに属します。共通するのは、SSR・ファイルベースルーティング・サーバー処理を1つのフレームワークで提供する点です。違いは設計思想にあります。Next.jsがApp Routerとサーバーコンポーネントを中心に独自の規約を広げているのに対し、TanStack Startはクライアント主導のSPA的な開発体験と型安全なルーティング/RPCを軸に据えています。Reactのメタフレームワーク選定で迷う場合は、用途の近いAstroとReactの違いのような比較記事も判断材料になります。
バージョンと安定性(RCから1.x系へ)
TanStack Startは2025年9月22日にv1.0リリース候補(RC)を発表しました。その後も活発に更新が続き、2026年6月時点ではTanStack Routerと統一された1.x系のバージョン(@tanstack/react-start 1.168系、@tanstack/react-router 1.170系)として継続的にリリースされています。SolidJS版は2.0系のベータとして別トラックで進行中です。本番採用する場合は、APIの細かな変更に備えて依存パッケージのバージョンを固定し、更新時に変更点を確認する運用が安全です。最新の安定状況とAPI仕様は公式ドキュメントで確認してください。
主要機能:SSR・ストリーミング・型安全ルーティング
TanStack Startの中核は、レンダリングとルーティングの仕組みです。ここが他のSPA構成(ViteのみのCSR)との差になります。
ストリーミング対応のSSRとSEO
TanStack Startはサーバー側でHTMLを生成して返すSSRに対応し、生成済みの部分から順次クライアントへ送るストリーミングも備えます。初期HTMLにコンテンツが含まれるため、クライアントだけでレンダリングするSPAに比べてクローラーが本文を取得しやすく、SEOの面で有利です。サーバーから送られたHTMLは、クライアント側のハイドレーションを経て通常のReactアプリとして動作します。ストリーミングSSRはReactのSuspenseと連動する設計で、データ取得の完了を待たずに先に表示できる部分から描画します。この非同期レンダリングの背景はAsync Reactの技術的背景で補足できます。
完全に型推論されるルーティング
TanStack Router由来のルーティングは、ルートパス・パラメータ・検索クエリの型がコード全体に伝播します。たとえば /posts/$postId のような動的ルートでは postId の型が自動で推論され、リンク生成やデータ取得の引数に型が効きます。文字列でURLを組み立てる従来のやり方と違い、存在しないルートへの遷移やパラメータの渡し忘れをビルド時に検出できるため、リファクタリング時の事故を減らせます。ルーティングの定義方法は次章のファイルベースルーティングが基本です。
Server Functions(サーバー関数)の使い方
Server Functionsは、サーバー側だけで実行される関数を定義し、クライアントから通常の関数のように呼び出せる仕組みです。データベース操作や認証、環境変数の参照といったサーバー専用処理を、ネットワーク境界を意識せずに型安全に呼び出せます。
@tanstack/react-start の createServerFn で定義します。HTTPメソッドを指定し、validator で入力を検証してから handler に処理を書くのが現在の基本形です。
import { createServerFn } from '@tanstack/react-start'
// サーバー側だけで実行される関数(入力を検証して結果を返す)
export const greetUser = createServerFn({ method: 'GET' })
.validator((data: { name: string }) => data)
.handler(async ({ data }) => {
return `Hello, ${data.name}!`
})
// クライアント側からの呼び出し(dataで引数を渡す)
const message = await greetUser({ data: { name: 'React' } })
validator の戻り値の型がそのまま handler の data の型になり、サーバーとクライアントで入力の型が共有されます。Zodなどのスキーマライブラリを validator に渡せば、実行時の値検証も同時に行えます。Server Functionsを使えば、REST APIやGraphQLを別途用意しなくても型付きのRPCが実現でき、フォーム送信やデータ更新の処理をそのまま関数呼び出しとして書けます。外部の別アプリやReact以外のクライアントから叩く必要があるエンドポイントには、次のServer Routesを使います。
Server Routes(旧API Routes)の使い方
Server Routesは、HTTPで直接アクセスできるAPIエンドポイントを定義する機能です。以前は「API Routes」と呼ばれていた機能で、Next.jsのAPIルートに相当します。Server Functionsが関数呼び出しによるRPCなのに対し、Server RoutesはHTTPリクエストで叩く従来型のAPIで、外部サービスからの呼び出しやWebhookの受け口に向きます。
ルーティング用のファイル内で createFileRoute に server プロパティを追加し、HTTPメソッドごとのハンドラを定義します。レスポンスは Response.json() でJSONを返すのが簡潔です。
import { createFileRoute } from '@tanstack/react-router'
// src/routes/api/todos.ts → /api/todos に対応
export const Route = createFileRoute('/api/todos')({
server: {
handlers: {
GET: () => {
const todos = [{ id: 1, title: 'Learn TanStack Start' }]
return Response.json(todos)
},
},
},
})
ハンドラは request や動的パスの params を受け取れます。routes/posts/$id.ts のように $ 付きのファイル名にすれば /posts/123 のようなIDごとのエンドポイントを定義でき、ページのルーティングと同じファイルベースの規約でAPIを実装できます。レスポンスやリクエストの型を付けておけば、フロントエンドと同一プロジェクト内で型の通ったAPI契約を保てます。
セットアップとファイルベースルーティング
開発を始めるには、最新のLTS版Node.jsを用意します。TanStack StartはViteベースのため、Vite 7系が必要とするNode.js 20以上(LTS)を推奨します。
CLIでのプロジェクト作成と起動
公式のスキャフォールドコマンドでひな形を生成します。プロジェクト名やTypeScript・Lintなどのオプションを対話式に選ぶと、依存パッケージがインストールされた状態のプロジェクトが作られます。
npm create @tanstack/start@latest
cd my-app
npm run dev
開発サーバーの既定ポートは3000で、起動後は http://localhost:3000 でプレビューできます。起動URLやポート番号はつまずきやすい箇所なので、最初に控えておくと安全です。なお、TanStackは複数の作成コマンドを統合CLIへ移行中で、推奨コマンドが変わる場合があります。エラーが出る場合は公式のGetting Startedで最新のコマンドを確認してください。
src/routesによるファイルベースルーティング
ルーティングは src/routes 配下のファイル構成がそのままURLパスになります。ファイルを追加・編集するだけでルートが増えるため、別途ルート設定ファイルを書く必要がありません。
src/routes/
├── __root.tsx // 全ルート共通のレイアウト
├── index.tsx // /(ホーム)
├── about.tsx // /about
└── posts/
└── $postId.tsx // /posts/123 のような動的ルート
$ プレフィックスのファイルが動的パラメータ、__root.tsx が全ルートの親レイアウトです。TanStack Startはこれらのファイルから型付きのルート定義を自動生成します。大規模アプリでルート定義を細かく制御したい場合は、createRouter などを使うコードベースの定義も併用できますが、まずはファイルベースで始めるのが簡潔です。
デプロイ:Vercel・Cloudflare・Node.js・Bun・Docker
TanStack Startは特定のホスティングに縛られず、配備先を選べます。要件に応じて、マネージドなホスティングからエッジ、自前サーバーまで使い分けられます。
マネージド/エッジへの配備(Vercel・Netlify・Cloudflare Workers)
VercelやNetlifyは、Gitリポジトリを連携するだけで自動ビルド・デプロイができ、SSR対応アプリをそのまま公開できます。Cloudflare Workersは公式のフレームワークガイドが用意されており、エッジ環境で動かせます。グローバルに低遅延で配信したいケースではエッジ配備が有力です。
Node.js・Bun・Dockerでの自前運用
従来型のサーバーで動かす場合は、npm run build でビルドし、出力されたアプリを npm run start で起動します。この成果物をDockerコンテナに組み込めば、任意のサーバーやRailwayのようなサービスへ展開できます。実行ランタイムはNode.jsに加えてBunもサポートしており、Bun向けの構成で本番運用も可能です。BunやDockerでの自前運用は、ランタイムやコンテナを自分で選べる柔軟性が利点で、社内サーバーやPaaSへの配置と相性が良いです。一度作れば配備先を後から変えやすいため、開発初期は手軽なホスティングで公開し、トラフィック増加に応じてエッジや自前サーバーへ移す進め方が取りやすくなっています。
Next.js・Remixと比較した選定基準
「Next.jsから乗り換えるべきか」は最も多い悩みどころです。結論から言えば、全面的な置き換えを急ぐ必要はありません。TanStack StartとNext.jsは強みが異なるため、プロジェクトの性質で選び分けます。
TanStack Startが向くケース
型安全を最優先する中〜大規模のSPA/SSRアプリに向きます。ルーティングからサーバー関数まで型が通るため、チーム開発でインターフェースが明確になり、リファクタリングの安全性が高まります。Viteの開発体験をそのまま活かしたい場合や、TanStack Query・Routerをすでに使っている場合も相性が良好です。クライアント主導のアプリ設計を好む開発者には、Next.jsのサーバーコンポーネント中心の規約よりも素直に書けます。
採用を見送るべきケース
一方で、現時点ではNext.jsなど実績の厚いフレームワークが無難なケースもあります。最大の障壁はエコシステムの成熟度です。TanStack Startはv1.x系として安定してきたとはいえ、周辺ライブラリ・ホスティング最適化・日本語の知見はNext.jsほど蓄積されておらず、つまずいたときに頼れる情報が少ない。加えて、画像最適化やISR(増分的静的再生成)といったNext.js標準機能に強く依存する構成では、同等の仕組みを自前で用意する手間がかかります。長期運用で変更追従コストを抑えたい場合も、更新頻度の高い新興フレームワークより枯れた選択肢が安全です。新規プロジェクトで型安全とDXを取りに行くならTanStack Start、既存資産と安定運用を優先するならNext.js、という線引きが実務的です。
よくある質問
TanStack Startは本番運用できますか?安定版はありますか?
2025年9月にv1.0リリース候補(RC)が発表され、2026年6月時点では1.x系として継続的にリリースされています。実運用は可能ですが、更新頻度が高いため、依存パッケージのバージョンを固定し、アップデート時に変更点を確認する運用が安全です。最新の安定状況は公式ドキュメントで確認してください。
Server FunctionsとServer Routes(API Routes)の違いは何ですか?
Server Functionsは、クライアントから関数として呼び出せる型安全なRPCで、アプリ内部のサーバー処理に向きます。Server Routes(旧API Routes)は、HTTPで直接叩ける従来型のAPIエンドポイントで、外部サービスやWebhookからの呼び出しに向きます。アプリ内で完結するならServer Functions、外部公開が必要ならServer Routes、と使い分けます。
TanStack StartはBunで動きますか?
動きます。実行ランタイムとしてNode.jsに加えBunをサポートしており、Bun向けの構成で本番運用も可能です。Dockerコンテナに組み込んで任意のサーバーへ展開する運用にも対応します。
開発サーバーのデフォルトポートは何番ですか?
既定は3000で、起動後は http://localhost:3000 でアクセスできます。別のポートで起動したい場合は、Viteの設定やコマンドのオプションでポートを変更します。
SolidJSでも使えますか?
使えます。TanStack StartはReact版が主軸ですが、SolidJS版も提供されています。2026年6月時点ではSolid版は2.0系のベータとして開発が進んでおり、React版とは別のバージョン系列で進行しています。
Next.jsから乗り換えるべきですか?
用途次第です。型安全とViteの開発体験を重視する新規アプリならTanStack Startが有力ですが、エコシステムの成熟度や画像最適化・ISRなどNext.js固有機能への依存が強い場合は、現時点でNext.jsを維持するほうが無難です。既存プロジェクトを急いで全面移行する必要はありません。