「Next.js の App Router にしたけど、“use server” と “use client” の貼り分けが複雑で、チームの学習コストが想定の 3 倍になった」——コーポレートサイト受託の現場で、この声を聞く頻度が高まっています。
こうしたディレクティブ疲れに対する、実務的な対抗馬として注目されているのが TanStack Start です。2026 年 4 月時点で “use server” / “use client” を書かずに RSC を扱える独自の設計を提示しており、コーポレートサイト・B2B サイト・小〜中規模アプリでNext.js 一強体制に風穴が空きつつあります。
本記事では、TanStack Start がコーポレートサイト受託で採用に値するか、Next.js からの移行コスト、受託提案の型を整理します。
なぜディレクティブ疲れが起きたか
Next.js App Router は強力ですが、“use server” / “use client” をコンポーネントごとに正しく貼る必要があり、規模が大きくなるほど次の問題が顕在化します。
- 境界の誤判定：Server Component にうっかり
useStateを書いて本番ビルドが壊れる - 意図と実体の乖離：宣言と実態がずれたとき、デバッグの起点が掴みにくい
- 学習コスト：チーム新人が「どちらを書くべきか」で数週間詰まる
コーポレートサイトは記事・事例・フォームが中心で、本来フロントエンド初級者でも組めるはずの領域です。ここに RSC のディレクティブ貼り分けが入ると、生産性が 30〜50% 落ちるのが現場感です。
私たちが Next.js vs Astro の比較記事 で書いた「コーポレートサイトには重すぎる」という課題に対し、Astro 以外の答えも揃ってきた、という状況です。
TanStack Start の設計思想
TanStack Start は、“use server” / “use client” を明示的なディレクティブではなく、ファイル配置と関数定義で自動推論します。
// routes/about.tsx
// ファイル名・配置から「ルート」であることが推論される
import { createFileRoute } from "@tanstack/start";
import { useCompanyProfile } from "../server/company";
export const Route = createFileRoute("/about")({
// サーバーで実行されるローダー（use server を書かない）
loader: async () => await useCompanyProfile(),
component: About,
});
function About() {
const { data } = Route.useLoaderData();
// ここはクライアントでも動く（use client を書かない）
return <section>{data.mission}</section>;
}「ファイル名と関数名から何がサーバー側に寄るべきかを決める」という発想は、Astro や Remix に近く、宣言より配置というコーポレートサイト向けの設計です。
コーポレートサイトでの採用判断
適している案件
- ページ数 10〜50 の企業サイト
- ブログ・事例・導入事例・採用情報が中心
- フォーム数個、管理画面なし or 小規模
- チームの React 経験は中級〜上級 1 名 + 初級 2〜3 名
向かない案件
- Server Actions をフル活用する SaaS ダッシュボード
- Next.js エコシステムの特定ライブラリ（
next-auth等）に強く依存 - SSG で十分な、コンテンツほぼ静的なサイト（こちらは Astro が最適）
Astro と TanStack Start の棲み分けは明快で、対話 UI が少ないなら Astro、そこそこあるなら TanStack Startが実用的な目安です。私たちが Astro + microCMS のガイド で書いた領域との補完関係になります。
Next.js からの移行コスト試算
中規模コーポレートサイト（30 ページ、フォーム 3 本、ブログ CMS 連携）を Next.js App Router から TanStack Start へ移行する場合の作業量は、おおむね次の通りです。
| 作業 | 工数目安 |
|---|---|
| ルーティング定義の書き換え | 2 週 |
| Server Actions → Route loader 化 | 1 週 |
next/image → 代替画像最適化 | 0.5 週 |
next-auth → TanStack Query auth パターン | 1 週 |
| CI / デプロイ変更（Vercel → Cloudflare Workers など） | 0.5 週 |
| QA・リグレッション | 1〜2 週 |
| 合計 | 6〜8 週 |
工数の内訳を見ればわかる通り、移行は既存の Server Actions 依存度・CMS 連携・認証まわりで作業量が大きく振れます。移行自体がプロジェクトの中長期 ROI（保守コスト削減・開発速度向上）で語れないと、発注側の意思決定が通りません。工数がかさむ移行だからこそ、この ROI を発注側の言葉で言語化できるかが分かれ目になります。
提案ストーリーの型
移行を提案するときは、次の 4 段階で話を組み立てます。
- 現状の Next.js 運用の痛みを言語化（ビルド時間・デプロイ失敗率・開発者の離職率）
- 移行後の運用像を提示（シンプルなファイル配置・ビルド時間 30% 短縮）
- リスクを明示（エコシステム分の薄さ・事例の少なさ）
- フェーズ分け（新規ページから徐々に TanStack Start 化）
特に「新規ページから導入して、既存は保守フェーズで置換」というフェーズ分けは、リスク最小で発注側に刺さりやすいパターンです。
ホスティングの選択肢
TanStack Start は Node 環境に加え、Cloudflare Workers / Deno Deploy / Bun サーバー上でも動作します。私たちが Hono + Cloudflare Workers でのエッジ API 設計 で整理した構成と同じホスティング上に載せられます。
| 選択肢 | メリット | 向くケース |
|---|---|---|
| Cloudflare Workers | グローバル低レイテンシ・安価 | 国際展開 / コスト最優先 |
| Vercel | エコシステム・DX | 既存 Next.js 資産流用 |
| 自社 VM / ECS | 既存インフラに統合 | エンタープライズ・社内規程あり |
ホスティングで悩む企業には、Cloudflare Workers + TanStack Startの組み合わせが、コーポレートサイトの運用コスト最小解として有力です。
スコープの切り出し方
TanStack Start を核にした案件は、いきなり全面移行に踏み切るのではなく、次のように段階を切ってスコープを組むと意思決定が進みやすくなります。
- 新規コーポレートサイト構築：ゼロから設計できるため配置ベースの設計思想を最も素直に活かせる
- Next.js からの段階移行：新規ページから TanStack Start 化し、既存は保守フェーズで置換する
- 1 セクションだけの PoC：導入判断の素材として小さく試し、経営層への提案前にチームの手応えを確かめる
特に PoC スコープは、期間・工数ともに小さく抑えられるため、経営層の合意形成コストを下げる入口として有効です。
まとめ — 「Next.js 以外の選択肢」が現実化した
RSC の流儀は、2024〜2025 年にかけて Next.js = 唯一解、という空気がありました。2026 年に入り、配置ベースで RSC を扱う TanStack Start や Astro の進化で、コーポレートサイト受託は「自社に合った流儀を選ぶ」フェーズに戻っています。
弊社では、TanStack Start / Astro / Next.js の比較評価から、コーポレートサイトの新規構築、Next.js からの段階移行までを受託で承っています。最適な流儀も、どこから移行を切り出すかも、ページ構成・既存の Next.js 資産・チームの React 習熟度によって変わります。「App Router のディレクティブ疲れをどう解くか」「どの範囲から TanStack Start に寄せるべきか」を一緒に見極めたい方は、要件をお聞かせいただければ具体的な進め方をご提案します。まずはお問い合わせフォーム からご相談ください。
