たける 第2回でWakuを触ってRSCの感覚は掴めたんですが、最近まわりで「TanStack Start がいい」って声をよく聞きます。TanStack Queryのあの TanStack ですよね？ Next.js とも Waku とも何が違うんですか？

りこ そう、TanStack Query / Table を作っているチームのフルスタックフレームワーク。**TanStack Router の上に SSR と Server Functions を足したもの**で、いま **v1 リリース候補（RC）** まで来ている。最大の特徴は、URLからデータ取得まで**端から端まで型が通る**こと。

「React最新ラボ」第6回。フレームワーク編の第2弾として、TanStack Start を実際に動かす。2026年2月の調査ではReact開発者の15%がすでに採用、50%が「試したい」と答えた、いま一番注目されているフレームワークだ。

立ち位置を整理する：Waku・Next.jsとの違い

ユナ 「クライアントファースト」がキモね。Next.jsがサーバ中心に倒れていったのに対して、Startは**普通のSPAの延長**として書ける。SPAに慣れた人の頭の切り替えコストが小さい。RSCが無いのは割り切りで、将来の対応は進行中。

プロジェクトを作る

公式CLIから対話形式で作れる。

npx @tanstack/cli@latest create

パッケージマネージャや、Tailwind CSS・ESLintなどのアドオンを聞かれるので好みで選ぶ。できたら開発サーバを起動する。

cd my-start-app
npm run dev
# → http://localhost:3000

ファイルベースルーティング：src/routes

ルートは src/routes 配下のファイルで定義する。Wakuの src/pages と似ているが、各ファイルで createFileRoute を呼ぶのがStart流だ。

src/
├── routes/
│   ├── __root.tsx      # 全ページ共通のルート（レイアウト）
│   ├── index.tsx       # /
│   └── posts.$postId.tsx  # /posts/:postId（動的パラメータ）
└── router.tsx

// ./src/routes/index.tsx
import { createFileRoute } from '@tanstack/react-router'

export const Route = createFileRoute('/')({
  component: Home,
})

function Home() {
  return <h1>TanStack Start を試す</h1>
}

面白いのは動的ルートだ。posts.$postId.tsx というファイル名にすると、params が自動で型付きになる。

// ./src/routes/posts.$postId.tsx
import { createFileRoute, Link } from '@tanstack/react-router'

export const Route = createFileRoute('/posts/$postId')({
  component: PostPage,
})

function PostPage() {
  // params.postId は string として型が通っている。typoはコンパイルエラー
  const { postId } = Route.useParams()
  return <h1>記事ID: {postId}</h1>
}

リンクを張る側も型が効く。存在しないパスや、パラメータの渡し忘れはビルド前にエラーになる。

<Link to="/posts/$postId" params={{ postId: '42' }}>記事42へ</Link>
// to="/psots/$postId" と typo すると即コンパイルエラー

たける リンク切れがコンパイルエラーになるのは衝撃です……。うちのReact Routerのプロジェクト、リンク先のtypoに本番で気づいたことあります。

Server Functions：サーバ処理を「型付きの関数」として呼ぶ

サーバでだけ実行したい処理は createServerFn で作る。Wakuの 'use server' に相当する仕組みだが、こちらは関数の入出力まで型が通る。

// ./src/server/get-server-time.ts
import { createServerFn } from '@tanstack/react-start'

export const getServerTime = createServerFn().handler(async () => {
  // ここはサーバでだけ実行される。DBアクセスや秘密鍵もOK
  return new Date().toISOString()
})

入力を受け取るときはバリデータを挟む。

export const greetUser = createServerFn({ method: 'GET' })
  .validator((data: { name: string }) => data)
  .handler(async ({ data }) => {
    return `Hello, ${data.name}!` // data.name は string と推論される
  })

呼び出し側はルートの loader に置くのが基本形。SSR時はサーバ内で直接実行され、クライアント遷移時は自動でHTTP経由になる。呼ぶ側のコードはどちらでも同じだ。

// ./src/routes/index.tsx
import { createFileRoute } from '@tanstack/react-router'
import { getServerTime } from '../server/get-server-time'

export const Route = createFileRoute('/')({
  loader: () => getServerTime(),
  component: Home,
})

function Home() {
  const time = Route.useLoaderData() // string と推論される
  return (
    <main>
      <h1>TanStack Start を試す</h1>
      <p>サーバ時刻: {time}</p>
    </main>
  )
}

ユナ loaderの戻り値が `useLoaderData` まで型で繋がるのがStartの真骨頂。「APIのレスポンス型を手で書いて、ズレてバグる」がそもそも起きない。TanStack Queryとの連携も公式サポートで、キャッシュ戦略はQueryにそのまま乗せられる。

デプロイ

StartはViteプラグインとして動くので、ビルドは普通に npm run build。Cloudflare Workers・Netlify・Vercelなど主要ホスティング向けのデプロイターゲットが用意されている。このシリーズの流儀でいくならCloudflareだが、手順はWakuの回とほぼ同じ流れ（アダプタ設定→デプロイ）なので、詳細は公式ドキュメントを参照してほしい。

つまずきやすい所

• RSCは使えない：async なサーバコンポーネントを書くスタイルではない。データ取得は loader + Server Functions が正解ルート
• RC版：v1リリース候補。APIはほぼ確定だが、細部は変わりうる。採用判断は1.0正式リリースを見てから
• ルートの型が更新されない：ルートツリーの型は自動生成される。エディタの型エラーが残るときは、開発サーバが動いているか（生成が走っているか）を確認する

たける WakuでRSC、StartでSSR＋Server Functionsを触って、フルスタックReactの二大潮流が体感できました。SPAの延長で書けるStartは、今のスキルからの地続き感がありますね。

りこ 「サーバ中心」に行くか「クライアント中心のまま強くする」か。両方触った今なら、案件ごとにどっちが合うか自分で判断できるはず。

まとめ

• TanStack StartはTanStack Router上のフルスタックフレームワーク。v1 RCまで到達し、APIは安定
• 思想はクライアントファースト。SPAの延長で書けて、SSRとServer Functionsが足される
• ルート・パラメータ・<Link>・loaderの戻り値まで端から端まで型安全。リンク切れがコンパイルエラーになる
• サーバ処理は createServerFn。SSR時は直接実行、クライアントからは自動でHTTP経由
• RSCは未対応（対応作業中）。RSCが必要ならWakuやNext.jsを選ぶ

React本体（Compiler・Activity）からフレームワークまで、2026年のReactは「書き味はシンプルに、最適化は道具に任せる」方向へ着実に進んでいる。次に話題の技術が出てきたら、また「最新ラボ」で実際に動かして確かめよう。