Next.js最新App Routerの本質的な限界とは？実践開発者が語るリアルな問題点と脱却術

この記事の途中に、以下の記事の引用を含んでいます。
One Year with Next.js App Router – Why We’re Moving On

「React Server Components」の衝撃！なぜNext.jsはこんなにも評判が悪いのか？

この記事は、Next.js 15のApp RouterとReact Server Components（RSC）の設計の根本的な課題を、現場志向の開発者が赤裸々に語ったものです。
筆者は、日常的にNext.jsでプロダクションアプリを開発していた経験から、「小さなバグではなく、設計上の考え方そのものに納得できない」点が多々あると主張します。
そして、実際に自社プロダクトのフロントエンドをTanStack Startへ移行した経験を詳細に説明し、そのモチベーションや過程・結果を綿密に共有しています。

複雑化するサーバー／クライアント分離――「Server Components」モデルの功罪

筆者が特に強調する先進機能のひとつが「React Server Components」（以下RSC）です。
RSCは、コンポーネントを「server」と「client」に分け、前者はバックエンド環境（Node.js等）でデータ取得や処理を担い、後者は従来のブラウザ上のUI管理を担当します。
記事より引用します。

“The pitch of RSC is that components are put into two categories, “server” components and “client” components. Server components don’t have useState, useEffect, but can be async functions and refer to backend tools like directly calling into a database. Client components are the existing model, where there is code on the backend to generate HTML text and frontend code to manage the DOM using window.document.*.”
（One Year with Next.js App Router – Why We’re Moving On より）

このこと自体は一見するとモダンなWebアプリには合理的ですが、実装体験として「破綻しやすい」と筆者は考えます。

実践で生じる違和感：ネーミングの「罠」と二重性

Server/Clientという用語自体が既存の定義を無視し、現実には「Clientコンポーネントですらバックエンド上で動作」する現象も混在します。
この設計は、「コーディング時の直感」と「実際の挙動」の乖離を生み出しやすく、プロジェクトメンバー間の混乱や認識齟齬を頻発させる元凶となっています。

筆者自身、設計上の整理として“backend／frontend”という本来的な実行環境の視点を重視せざるを得ず、Next.js標準の語彙選択自体が混乱の温床だと分析しています。

現場で次々現れる「やってられない！」制約たち

データ取得分離の苦痛、SSR下の中途半端な役割分担

RSC採用下では、状態管理（useState等）やSSR（Server Side Rendering）の仕組みの中で「どこでデータを取得する？」「どこまでをServer Componentに留める？」等、再考を迫られる場面が頻出します。

記事でも、

“Components rendered by the React Server, by design, can not be modified after mounting. Elements that could change need to be inside a client component, but data fetching cannot happen on the client components, even during SSR on the backend. This results in awkwardly small server components that only do data fetching and then have a client component that contains a mostly-static version of the page.”

と明言される通り、データ取得の場所と手段が分断され、結果として「とにかく小さなServer Component → モノリシックなClient Componentへデータ受け渡し」という形に陥る傾向があります。

かつ、クライアント側でのデータ再利用やキャッシュの難しさも付きまとい、「たった少しのUIを動的にするだけで、設計やファイル分割が複雑化」しやすく、開発生産性や保守性が著しく低下します。

任意のページ遷移ですべて再フェッチ…“本当にこれでいいの？”

RSCベースのApp Routerは、「どんなページ遷移でも必ずBackEndから再フェッチが走り得る」という構造的問題を抱えます。

“The App Router starts every page as a server component, with (ideally) small areas of interactivity, a navigation to a new page has to fetch the Next.js server, regardless of what data the client already has available!”

Webアプリでは多くの場合、前のページで既に取得したデータやキャッシュを有効活用してUXを向上させたいのですが、Next.jsの思想だと「毎回ゼロからfetch」「loading表示も多発」「同一データの再取得による帯域・パフォーマンス浪費」などUX上の痛手が顕著となります。

実際、筆者が記述するコードの中では、意図的に「RSCによるデータfetch phaseを飛ばす」ようheaderを見て判定する小技まで使わざるを得なかったとのことです。

「2重ダウンロード問題」と不可解なデータ冗長――React Server Componentsの根源的欠陥

Next.jsのApp Router及びRSC実装は「初期描画（サーバーレンダリング）」＋「水面下でのReact Server Componentの呼び出し」を併用することで、全体的に「同じ内容を2回送る（HTML＋JSON in JS）」という帯域・効率上の大きな無駄が生まれます。

“This solution doubles the size of the initial HTML payload. Except it’s worse, because the RSC payload includes JSON quoted in JS string literals, which format is much less efficient than HTML.”

たとえBrotli等で圧縮できても、根本的に「本来1回で済むべきデータ/HTMLを2回送る」仕様は避けがたく、たとえばNext.js本家のドキュメントページすら「750kB規模の配信のうち、250kBがHTML・500kBがスクリプト＝内容が2重化」という非効率が発生しています。
特に、大規模サイトやアクセス負荷が高い現場では、余計な帯域とコスト・無駄な遅延が無視できない課題となるでしょう。

Turbopackの現実：「速さ」も「デバッグ体験」も理想とは程遠い

Next.jsが「未来のビルドツール」として推すTurbopackですが、現場目線では

• 開発体験が本当に速いどころか、不安定
• エラー時のメッセージが酷くて、原因特定も困難
• モジュール名の難読化や意味不明な挙動が多い

…等々、正直ここにメリットを見出すのは難しいというのが筆者の所感です。

「脱Next.js」成功事例―なぜTanStack Startへ？

では、筆者はどう現状を変えたのか？
現場でNext.js＋Vercelに見切りをつけ、Vite＋TanStack Startへ「シームレスに段階的移行」した経緯が詳細に解説されています。

移行のコツは
– Next.jsのAPIやhookをstub化（仮実装モジュールを用意）し、新旧並存を可能に
– Viteやtailwindcss等、既存技術資産の活用
– ページ/ルート単位で段階的に新環境へ移し替え（例：「1つのページのみ先行移行→動作を確認」）

という方式。
しかも、「TanStack Router」を駆使することで、型安全性・開発効率・ページ遷移・SSRパフォーマンスすべてでNext.jsを上回る体感が得られたとのことです。
また、次第に業界全体でもNext.js離れの動きが強まっていることも複数事例として挙げられています（例：ChatGPTがRemixへ移行など）。

“At the end, the site performed faster from every angle: Development Mode, Production page load times, Soft navigations, and at a lower price than our Next depoyment with Vercel.

We’re not the only ones seeing the change. … someone sent me the results of Brian Anglin’s work at Superwall, showing incredible CPU reductions on TanStack Start. I also recall ChatGPT switching from Next.js to Remix…”

筆者独自の補足意見―Nextにしかないもの？「next/metadata API」は評価

全体的に「Next.jsの設計・思想・DXには否定的」な筆者でも、「唯一よかったのはnext/metadata API」だと明記しています。
これについては自分でシンプルな移植版ライブラリを作成・公開し、他への応用も推進するという「技術コミュニティ貢献」路線も垣間見えます。

こう考える！私なりの総括・解釈

この長文記事は、単なる技術批判や「使いこなせない愚痴」ではありません。
筆者はReact Server Componentsの根本設計に密接に関わる立場（BunのRSC実装担当など）を持っており、そのうえで以下のような冷静な評価を下しています。

1. RSCの二重化・複雑化・効率の低下は設計的必然
   　「全部を既存UIパラダイムに縛らずモダン化」しようという思想は一定評価できますが、現実にはSSRとCSR（クライアント・サイド・レンダリング）の良いとこ取りどころか「両方の悪い面」を重ねてしまっている構造です。
   　とりわけ、分かりにくいコンポーネントの2系統管理や、ページ間のデータの再利用不全、無駄な帯域消費などは大規模サービスほど痛みが増します。

2. 設計パラダイムの“急進的すぎる変化”は現場DXに負担
   　エンジニアが直感的に分かりやすい抽象化・APIでないと、定着や属人化回避は困難です。
   　冒頭で筆者が言う「みんな不満ながら使い続けている」のは需要と供給のミスマッチを示唆しています。
   　成熟した業界こそ保守性や継続性の観点から“ツール選定の地に足をつけ直す”べきという問題提起にも読み取れます。

3. モダン生態系の混迷には“より良いものづくり”の理念で対抗
   　筆者は「現場に使いやすく・尊敬できる技術」を推すべきとし、現時点ではVite＋TanStack Startに軍配を上げつつも、「ツール自体のリスペクト感」を何より重視している態度が伺えます。

今後のフロントエンド開発者にとっての教訓・提言

この考察から、現代Web開発者に伝えたい意義や示唆は以下の通りです。

• 流行り廃りや業界巨大企業の標準化圧力に踊らされない
  　自分／自社が本当に求めるDX・保守性・コストメリットを冷静に検証し、現場軸で“道具を選び直す”姿勢・スキルを大切にしたい。
• 「新技術＝銀の弾丸」ではなく、“副作用や限界”も技術評価には不可欠
  　RSC／App Routerのように“先進的”とうたわれていても、実際の現場や組織・システムに与える影響は千差万別。常に客観的・多角的に判断する視点が必要です。
• 柔軟で段階的なマイグレーションが成功のカギ
  　いきなり全置き換えではなく、仮実装やAPIのスタブ・ルーティングの共存など、「漸進的移行」「きちんと現行資産を活かしつつアップグレードする」戦略が中長期的開発の現実解となります。
• コミュニティドリブンな小規模・高品質OSSへの支持も一手
  　巨大ベンダーロックインを回避し、信頼できるテック・コミュニティや個人開発者へも目を向けることが、長期的な事業／技術の柔軟性を守るでしょう。

まとめ

Next.js 15のApp RouterとReact Server Componentsがもたらした「設計上の大転換」は、理想と現実のギャップが大きいことが業界現場で浮き彫りになりつつあります。
現場開発者の実体験からは、「現状のNext.jsは多くのWebアプリ・サイトの要件に合致せず、“もっと良い道具”への乗り換えが現実的に選ばれている」ことが明確に伝わってきます。

自分が “真に求める開発体験” を見極め、「納得できるツール」へ柔軟にシフトする、その姿勢こそが、これからのWeb開発者にとって最も重要なスキルとなっていくでしょう。

categories:[technology]