TanStack Start を標準スタックにすべきか

「Cloudflare でホスティングするなら TanStack Start を標準スタックにすべきだ」という主張を、ここ数か月よく見かけるようになりました。Vite をそのまま使える、ルーティングの型が通る、Vercel に縛られない。理由はどれも具体的で、実際に乗り換えた報告も増えています。

ただしこの議論は、たいてい Next.js との一騎打ちの形で語られます。実際の選択肢は、そこまで狭くありません。

React のフルスタックフレームワークとして Cloudflare 公式のガイドが用意されているもののうち、標準スタック候補として実務で検討に載るのは次の四つです。

• TanStack Start — Vite と TanStack Router の上に建つ、型安全志向のフレームワーク
• Next.js + OpenNext — Next.js をアダプタ経由で Workers に載せる構成
• RedwoodSDK — Cloudflare 向けに設計された、RSC 中心のフレームワーク
• React Router v8 — Remix の後継。Web 標準準拠で、Cloudflare が本番利用可と明記

このほかに Vike や Waku もガイドを持ちますが、採用事例と情報量がまだ薄いため本記事では扱いません。以下では、まずサーバ描画が要るかを確かめたうえで、四つの性格とケース別の選び方を整理します。

結論 — 翻訳層・ISR・エコシステムで決まる

先に一段上の分岐があります。認証の内側で完結する管理画面やダッシュボードなら、フルスタックフレームワークは要りません。 React + Vite の SPA を静的アセットで配り、同じ Worker に API を載せるのが Cloudflare では最も素直です。以下は公開ページを持つ場合の話になります。

そのうえで、四つの差は性能ではありません。分かれ目は三つです。Next.js を Workers 向けに翻訳する層を抱えるかどうか、ISR を持つかどうか、そしてエコシステムの厚みです。

以前ならここに RSC も並んでいました。いまは違います。TanStack Start が 2026年4月に RSC を搭載し、RedwoodSDK は当初から RSC 中心の設計で、四つのうち三つが RSC を持ちます。RSC は選択の分岐点から降りました。 ただし Next.js は既定でサーバ描画、Start は experimental な opt-in と、成熟度と扱いには差が残ります。

Start・RedwoodSDK・React Router は Vite プラグインが Worker を直接出力します。使うのは Start と React Router が Cloudflare の Vite プラグイン、RedwoodSDK が Miniflare です。実装は違いますが、いずれも開発中から Workers runtime を踏みます。Next.js だけがアダプタ @opennextjs/cloudflare を挟み、その代わりに ISR を手に入れます。

「Start が第一候補」はデプロイ機構の素直さだけを見た場合に成り立ちます。ISR やエコシステムの厚みに重みを置くと結論は変わります。

サーバ描画が要るかを先に決める

四つを比べる前に確かめるべきことがあります。サーバ描画がそもそも必要かどうかです。

不要なら、Cloudflare で最も素直な構成は React + Vite の SPA を静的アセットとして配り、同じ Worker に API を載せる形です。公式ガイドにも React + Vite の項目があり、フレームワーク固有のアダプタも翻訳層も要りません。デプロイは1回、同一オリジンなので CORS の設計も消えます。後から DB や API が必要になっても、binding を足すだけで載せ替えが起きません。

判断の分かれ目は、公開ページを検索とクローラに読ませる必要があるかどうかです。クライアント描画だけの構成は、HTML が空のシェルになります。Googlebot は JavaScript を実行するので索引はされます。一方 GPTBot・ClaudeBot・PerplexityBot といった AI クローラは JavaScript を実行しないため、生成 AI の回答からは事実上見えなくなります。SNS やチャットの OG カードも同じで、ルートごとのタイトルや画像が出ません。LCP もクライアント描画の鎖の後ろに回ります。

四つの選択肢の性格

TanStack Start — Worker をそのまま出力する

Vite と TanStack Router の上に建つフルスタック React フレームワークです。サーバ側の入口はサーバ関数 createServerFn とサーバルートで、どちらも Request を受けて Response を返す fetch handler の形をとります。これは Workers の runtime である workerd の実行モデルと同じ形です。

デプロイは vite.config.ts に @cloudflare/vite-plugin と tanstackStart() を並べ、ビルドして wrangler deploy するだけで済みます。開発サーバの SSR 環境も workerd の中で走ります。KV・D1・R2・Durable Objects・Workers AI のバインディングを、開発中から env 経由でそのまま触れます。

公式対応の表明は 2025年10月でした。以降も静的プリレンダリングが 2025年12月、Auxiliary Workers が 2026年1月（Vite 7 以上）と続いています。ルート単位で SSR・SSG・SPA を切り替える selective SSR も持つので、公開ページは静的、ログイン後はクライアント描画という構成が素直に組めます。

最大の武器は型が通る範囲です。パスパラメータだけでなく検索パラメータまで型が通り、検証も挟めます。この点は四つの中で頭一つ抜けています。

RSC も 2026年4月から使えます。ただし既定では無効で、rsc: { enabled: true } の設定と React 19 以上、Vite 7 以上（または Rsbuild 2 以上）が必要です。ドキュメントは "Server Components are experimental! The API may see refinements." と明記し、"will remain so into early v1" と続けています。設計も Next.js とは別物で、RSC をデータとして扱います。React Flight ストリームを renderServerComponent() や createCompositeComponent() で欲しい場所に差し込む形で、既定でサーバ描画にして opt-out するのではなく、宣言的に opt-in します。Start 独自のシリアライゼーションは server components 側では未対応です。

弱点は ISR を持たないこと、フルスタック構成としての事例の薄さ、そして更新の速さです。TanStack Query や TanStack Router 自体の利用者は多いので、部品が足りないというより、四つを組み合わせた構成での前例が少ないという意味です。@tanstack/react-start は 1.168.x を頻繁に更新していて、2026年8月だけでも複数のリリースが出ています。追随の手間は見込んでおく必要があります。

統合面の粗さも残っています。@cloudflare/vite-plugin と @tanstack/react-start を併用して viteEnvironment: { name: "ssr" } を指定すると、SSR のルート読み込みが TypeError で落ちる不具合が workers-sdk の #13952 として報告されています。2026年8月時点で open です。回避策は Cloudflare プラグインを外すことですが、それをやると bindings が使えません。本記事が挙げた推奨構成そのものに刺さる問題なので、採用前に現状を確認してください。

Next.js + OpenNext — アダプタが翻訳して載せる

OpenNext は Next.js を Vercel 以外へデプロイするためのアダプタ群で、Cloudflare 向けの実装が @opennextjs/cloudflare です。next build が吐いた成果物を読み取り、Workers が実行できるエントリポイントへ組み替えます。

動かすには前提があります。Workers が備える軽量な Node.js 実装を使わせる互換フラグ nodejs_compat を有効にし、互換日付を 2024-09-23 以降に設定する。アプリ側の runtime は Node.js を選ぶ（edge runtime では動きません）。ここを通せば、Next.js 本体に手を入れずに Workers へ載ります。

この構成の要は、Vercel のインフラと不可分な機能を OpenNext が代替実装で埋めている点です。

• ISR の増分キャッシュ → KV か R2 へ写像
• 画像最適化 → Cloudflare Images。images.unoptimized を立てて外部処理するか、変換エンドポイントを指す custom loader を書く
• middleware と タグ単位のキャッシュ無効化 → 独自の仕組み

画像の custom loader は width・quality・src を受け取り、Cloudflare 側の w・q・fit・format へ写します。対応形式は PNG・JPEG・WebP・AVIF・GIF・SVG で、それ以外は無変換のまま返ります。動きますが、設定項目とハマりどころがここに集まります。

サイズは意識しておく必要があります。Worker のスクリプト上限は圧縮後で無料プラン 3MiB・有料プラン 10MiB で、Next.js の出力はこの枠に対して軽くありません。削減は継続していて、2025年6月の v1.2 では create-next-app の生成物が 14MiB から 8MiB（gzip 後で 2.3MiB から 1.6MiB）へ落ちました。ただしこれは1年以上前の値です。アダプタは 2026年7月時点で 1.20.2 まで進んでいるので、現在のサイズは自分のアプリでビルドして測るのが確実です。

型については、typedRoutes を有効にすると next/link の href と next/navigation の push / replace / prefetch が検証されます。この設定は Next.js 16 でトップレベルへ昇格しました。ただしリテラル文字列が対象で、動的に組んだ文字列は as Route でキャストが必要です。検索パラメータは型付けの対象外で、ここが Start との差になります。PageProps や LayoutProps などのルート型ヘルパーは自動生成されます。

翻訳層のコストは、よく言われる「Next.js への追従が遅れる」ではありません。OpenNext は Next.js 16 の全 minor / patch と、14・15 の最新 minor をサポートしています。本体が 16.3 系まで進んだ現在も追随できています。14 の打ち切りも、Next.js チーム自身のサポート終了に合わせたものです。追従ラグを翻訳層のコストとして挙げるのは、実測に反します。

実際のコストは二つです。ひとつは開発と本番の runtime のずれで、next dev は Node.js の上、本番は workerd です。Node.js API の対応状況やグローバルの違いが、デプロイして初めて表に出ることがあります。もうひとつは設定の集中で、上に挙げた代替実装の設定がすべてアダプタ層に積み上がります。

RedwoodSDK — RSC を主軸に据えるための選択

Cloudflare 向けに設計された React フレームワークです。Vite プラグインの形で SSR・RSC・サーバ関数・ストリーミング・リアルタイムを提供します。ローカル開発は Miniflare で Workers runtime をエミュレートするので、D1・R2・Durable Objects・Queues にそのまま触れます。

Start が RSC を持った今、RedwoodSDK の位置づけは「RSC が手に入る唯一の非 Next.js」ではなくなりました。残る差は扱いの重さです。Start の RSC は experimental な opt-in で、既定は無効です。RedwoodSDK はドキュメントが "By default, all components are server components." と書くとおり、既定が完全にサーバ側です。クライアント側の対話性が要る箇所に "use client" を付けて opt-in します。RSC を主軸に据えたいなら、Cloudflare 上ではこちらのほうが素直です。

引き換えになるのは実績です。v1.0 に到達したのは 2026年3月で、そこから5か月で 1.7.2 まで進んでいます（2026年8月時点）。おおよそ3週ごとにマイナーが出ている計算です。開発は活発ですが、その分 API の変動も速い。踏んだ問題の前例も、四つの中で最も少ない位置にいます。

したがって「Start の RSC が experimental だから RedwoodSDK へ」という理屈は通りません。RedwoodSDK を選ぶ理由は、RSC を設計の主軸に据えたいという一点に限られます。静的プリレンダリングの対応と型付けの範囲も本記事では確認できていないので、この二つに要件があるなら事前に検証してください。

React Router v8 — 保守側の安全牌

Remix の後継です。ファイルベースのルーティング、サーバローダー、サーバアクション、SSR を持ち、Request と Response を素で扱う Web 標準準拠の設計です。

v8 は 2026年6月にリリースされました。Framework Mode は v7 から継続していて、廃止されていません。変更は破壊的なものを絞った内容で、ESM-only ビルドへの移行、middleware の既定有効化、future flag の昇格、react-router-dom の廃止が中心です。年次リリースの方針を明言しているので、更新の見通しが立ちます。随時更新の Start と RedwoodSDK に対する明確な利点です。

Cloudflare 側の扱いも堅めです。2025年4月にフルスタックフレームワークの GA が発表された際、本番利用可能なアダプタとして名前が挙がっています。Vite プラグイン経由で開発サーバも workerd で走ります。実績とドキュメントの厚みは Remix 時代から継承しているので、Start や RedwoodSDK より情報が見つかります。

制約が二点あります。RSC を持たないこと。そして Cloudflare の Vite プラグインと併用する場合、公式ドキュメントが "SPA mode and prerendering are not currently supported when using the Cloudflare Vite plugin." と明記していて、SPA モードと静的プリレンダリングが使えません。公開ページを静的に配りたい構成では、ここが Start との差になります。

何が判断を分けるのか

四つを並べたうえで、選択を実際に動かす軸は三つに絞れます。

軸1: 翻訳層を抱えるか

Next.js だけがアダプタを挟みます。得るものは ISR です。支払うのは、開発と本番で runtime が揃わなくなること、そして代替実装の設定がアダプタ層へ積み上がることです。

「内蔵で楽な Next.js」対「自前で組む Start」という対比はよく持ち出されますが、これが成立するのは Vercel 上です。Cloudflare 上では Next.js 側も custom loader を書いて Cloudflare Images に降ります。着地点が同じなので、画像最適化に関する Next.js の優位はその分だけ縮みます。

軸2: ISR が本当に要るか

RSC はもう分岐点になりません。四つのうち三つが持っています。残るのは ISR です。

ISR が要るのはコンテンツ量が多く更新も走るサイトです。オウンドメディア、EC、製品ドキュメント、事業サイト。再ビルドせずにページを差し替える仕組みを自前で組むのは骨が折れるので、当たる案件では軸が一つでも決定的になります。

どれだけの案件がここに当たるかは扱う領域によります。事業サイトとメディアの比率は高いので ISR は軽く扱えない、というのが後のケース別表の前提です。これは筆者の見立てで、統計で裏を取った数字ではありません。

要らない場合は、Cache-Control に s-maxage と stale-while-revalidate を載せて CDN 側に持たせるか、ビルド時にプリレンダリングして静的に配る形で足ります。

軸3: エコシステムの厚みとリスクの形

「残った機能差が少ないほうを落とす」という進み方をしがちですが、軸の数は重みではありません。

認証、ヘッドレス CMS、決済、i18n、管理画面のコンポーネント群、そして引き継ぎと採用。Next.js を前提に書かれた記事・サンプル・ライブラリの蓄積量は、残る三つを大きく上回ります。生成 AI にコードを書かせるときの精度も、この蓄積量に引きずられます。実務ではここが効いてきます。

リスクの形も違います。アダプタ構成のリスクは、代替実装のどこかで詰まることです。設定は多いものの、詰まる場所は既知の一覧の中にあります。対して Start や RedwoodSDK のリスクは「踏んだ問題に前例がない」で、こちらは上限が読めません。先に挙げた #13952 が、その手触りの一例です。推奨構成の組み合わせで SSR が落ち、回避策は bindings を捨てることしかない。事例が積み上がっていないフレームワークでは、こういう問題の最初の踏み手が自分になります。

更新の見通しも見ておくべきです。Start と RedwoodSDK はどちらも更新が速く、追随の手間が定常的に乗ります。この点で年次リリースを明言している React Router v8 は、標準スタックとしては扱いやすい位置にいます。

Next.js から Start へ乗り換える場合の移行コスト

「標準スタックを変えるか」という問いには、既存資産の移行という側面が付きます。本記事の起点である「Next.js をやめて Start へ」という経路について、触る範囲を挙げておきます。

• ルーティング — App Router のファイル規約から TanStack Router のファイル規約へ。パスの形は近いものの、ルートとデータ取得の境界が変わります
• データ取得 — RSC と async component、Server Actions から loader と createServerFn へ。Start の RSC は experimental なので、既存の RSC をそのまま持ち込む前提では見積もらないほうが安全です
• middleware — Worker の fetch handler か Start のサーバルートに手で書き直します
• 画像 — next/image から Cloudflare Images へ。ただし OpenNext でも custom loader を書くので、Cloudflare を前提にするなら差は小さいところです
• ISR — 相当する機能がありません。CDN キャッシュかプリレンダリングへ設計そのものを変えることになります。ここが最大の非互換です
• 周辺ライブラリ — 認証や CMS の SDK が Next.js 前提だと個別対応が必要です

ルーティングとデータ取得はアプリ全体に触るので、段階移行が効きにくい組み合わせです。動いている Next.js を移す正味の便益は、Cloudflare のバインディングを深く使いたい場合を除けば大きくありません。

ケース別の選び方

判断の軸は、翻訳層を抱えてでも欲しい Next.js の機能と資産があるかどうか、その一点に落ちます。「Next.js は重いから Start へ」という言い方は、この重み付けを飛ばしています。フレームワークの品質を採点する話ではありません。

前提の明示

ここに挙げた対応状況とバージョンは 2026年8月時点のものです。Start の RSC は experimental で、API が変わる可能性を公式に明示しています。React Router の Cloudflare 併用時の制約、RedwoodSDK の成熟度、OpenNext のバンドルサイズも動きが速い領域です。

未確認のまま残した点を挙げておきます。RedwoodSDK の静的プリレンダリング対応と型付けの範囲は、公式ドキュメントで確認できませんでした。ISR を要する案件の比率は、筆者の見立てによるものです。統計で裏を取ってはいません。バージョン依存の記述は各プロジェクトの現在のドキュメントで確認してください。

参照した一次情報は次のとおりです。

• Framework guides · Cloudflare Workers docs
• Full-stack frameworks are now Generally Available on Cloudflare Workers
• Vite plugin · Cloudflare Workers docs
• Hosting | TanStack Start React Docs
• Server Components | TanStack Start React Docs
• React Server Components Your Way | TanStack Blog
• Selective SSR | TanStack Start React Docs
• Build TanStack Start apps with the Cloudflare Vite plugin
• Static prerendering support for TanStack Start
• Auxiliary Workers
• OpenNext Cloudflare / Image Optimization
• OpenNext bundle size reduction
• Next.js · Cloudflare Workers docs
• TypeScript · Next.js docs
• Type Safety · React Router docs
• RedwoodSDK · Cloudflare Workers docs
• React Server Components | RedwoodSDK
• React Router (formerly Remix) · Cloudflare Workers docs
• React Router v8 | Remix Blog
• workers-sdk #13952

AI クローラの JavaScript 実行状況については、一次資料に当たれていないため二次情報を参照しています。

• Do AI Crawlers Render JavaScript? GPTBot, ClaudeBot, and Perplexity in 2026