はじめに
こんにちは、Watanabe Jin(@Sicut_study)です。
今日、私たちが当たり前のように使っているReactフレームワーク「Next.js」。 Netflix、Uber、OpenAIなど、世界中の巨大企業が採用し、日常的に利用するサービスの多くがNext.jsで構築されています
。
前回のReactの歴史の記事では、Reactが初期の激しい批判を乗り越えてウェブ開発の「王者」へと上り詰めた物語を紹介しました。
しかし、Reactの勝利は、新たな問題の始まりでもあったのです。
今回は、Reactの抱えていた課題を解決するために生まれ、現代のフロントエンド開発で 事実上の標準（デファクトスタンダード） となりながらも、現在新たな試練に直面している Next.jsの歴史 を紹介します。
動画も力をいれて作成してますので、ぜひそちらで見てほしいです！！
↓↓↓
目次
目次
1. Reactが残した課題 - 「SPAの三重苦」
2. 一人のハッカーの挑戦
3. Next.jsの「6つの原則」と静かな革命
4. ISRの魔法とGatsbyとの戦い
5. Vercel時代の光と影 - テレメトリ問題
6. App Routerの混乱とRSCの脆弱性
7. なぜ開発者はNext.jsから離れられないのか
8. まとめ
1. Reactが残した課題 - 「SPAの三重苦」
2014年から2016年にかけて、Facebook、Instagram、Airbnbなど多くの企業がReactを採用し始めました。当時、多くの開発者がCreate React Appを使い、ワンコマンドで簡単にReactアプリを作っていました。
しかし、Create React Appにははっきりとした限界がありました。
それは基本的に SPA（シングルページアプリケーション）しか作れなかったこと です。
SPAには、開発者とユーザーを苦しめる「3つの大きな問題」がありました
-
巨大なバンドルサイズ
SPAは最初に多くのJavaScriptを読み込むため、アプリが表示されるまで時間がかかり、スマホや遅い回線では致命的でした。 -
SEOの悪夢
当時の検索エンジンは「JavaScriptで動的に生成されたコンテンツ」の扱いが苦手であり、インデックスされないリスクがありました。 -
ローディング地獄
画面を切り替えるたびにクライアント側からAPIにデータを取りに行くため、そのたびにローディングスピナーが回り、ユーザーをイライラさせました。
ルーティングやデータフェッチ、サーバーサイドレンダリング（SSR）を自力で構築する webpack の設定地獄に、ある開発者はこう叫びました。
「Reactを使うのに、まだこんなに勉強しないといけないのか？」
業界は、「Reactの力を保ちつつ、これらの問題を解決するフレームワーク」を求めていました。
2. 一人のハッカーの挑戦
この問題に挑んだのが、アルゼンチンのブエノスアイレス近郊で生まれた若きプログラマー、 Guillermo Rauch（ギジェルモ・ラウチ） です。
彼は普通の子供ではなく、幼い頃からプログラミングに熱中し、10代のうちにオープンソースの世界で名を知られる存在になりました。多くの人が大学に入る年齢で、すでに LearnBoost や Cloudup を共同創業し、CTOを務めていたほどの天才です。
ギジェルモには、「ウェブはもっと良くなれる。もっとシンプルになれる」という確信がありました。
彼はWebSocketsがまだ一般的でなかった頃に、大ヒットしたリアルタイム通信ライブラリSocket.IOを作ったことでも知られています。
2015年、ギジェルモは新しい会社を立ち上げます。
名前は 「Zeit」 （ドイツ語で時間を意味する）
最初のプロダクトは、ワンコマンドでアプリを公開できる画期的なデプロイツール「Now」でした。
しかし、彼の野望はさらに大きく、次のように考えていました。
「Reactは素晴らしい。でも複雑すぎる。フルスタックのReactフレームワークを作ろう。設定なしで、すぐに使えるやつを」
チームのメンバーからは「リスキーだ」「本当に需要があるのか？」と言われましたが、彼には明確なビジョンがありました。
3. Next.jsの「6つの原則」と静かな革命
ギジェルモと彼のチームは、新しいフレームワークの設計思想として、以下の方向性を定めました。
- ゼロセットアップ: インストールしたら、すぐ使える
- JavaScript everywhere: フロントもバックも、全部JavaScript
- 自動コード分割: 必要なコードだけを読み込む
- デフォルトでサーバーサイドレンダリング: SEOの問題を解決する
- 柔軟なデータフェッチング: いつ、どこで、どうやってデータを取るか、自由に選べる
- ワンコマンドデプロイ: 作ったら、すぐ公開できる
（公式な名前ではありませんが、設計思想をよく表した「6原則」と呼ばれていました）
2016年10月25日。
派手な発表イベントやプレスリリースもなく、小さなGitHubリポジトリとして「Next.js」が公開されました。
Create React Appと違い、最初からルーティングが入っており、ファイルを置くだけで自動的にルートが生成され、SSRもサポートされていました。
これを見た開発者たちは即座に反応し、「これだ。これを待っていた」と口コミでじわじわと広がり始めました
4. ISRの魔法とGatsbyとの戦い
Next.jsの本当のイノベーションは2020年に訪れます。
Next.js 9.3で新しいデータ取得APIが導入され、続く9.4〜9.5で ISR（Incremental Static Regeneration：段階的静的再生成） が登場しました。
従来の静的サイトは「速いけれど全ページの再ビルドが必要」、動的サイトは「常に最新だが遅い」というトレードオフがありました。ISRはこの両方のいいとこ取りをし、「最初はビルド時に静的ページを生成し、アクセスされたタイミングで個別のページだけを裏側で再生成する」という魔法のような機能を提供しました。
これはブログやECサイトにとって革命的でした。
同じ時期、Jamstackの人気者であるGatsbyとの覇権争いがありました。
Gatsbyは静的サイト生成に特化して高速でしたが、GraphQLを前提とする複雑さや、大規模サイトになるとビルドに数十分から1時間かかるという問題を抱えていました。
実運用での信頼性を求めたTwitch、TikTok、Huluなどの大規模サービスは、次々とNext.jsへ移行していきます。
そして2020年、Zeitは社名を Vercel に変更し、Next.jsの専用プラットフォームとしての色をより強く打ち出しました。
5. Vercel時代の光と影 - テレメトリ問題
Vercelの登場により、エッジ機能、画像の自動最適化、CDNとの統合など、Next.jsは「完璧なエコシステム」を築き上げました
。
決定的な出来事として、Reactの公式ドキュメントが「Reactを使うならNext.jsのようなフレームワークを使うのが推奨」と書き換えられました。
「Reactを本番で使う＝Next.jsを使う」という事実上の標準となったのです。
しかし、勝者の裏で最初の亀裂も見え始めます。
Next.jsは利用統計などの テレメトリ（匿名データ送信）をデフォルトで有効 にしていました。
Vercelは「フレームワーク改善のため」と説明しましたが、「明示的な同意なし（オプトインではない）に送られること」に対してコミュニティから批判が殺到しました。
「Next.jsは本当にコミュニティのためのフレームワークなのか？それともVercelのためのツールなのか？」
オープンソースでありながら、ロードマップを決め、新機能を設計しているのはVercelであり、その機能はVercel上で最高に動くように作られているという構造に、開発者たちは疑問を抱き始めました。
6. App Routerの混乱とRSCの脆弱性
2022年10月、Next.js 13が発表され、新技術 React Server Components（RSC） を使った全く新しいルーティングシステム App Router が導入されました。
理論上は革命的でしたが、現実は厳しいものでした。
開発者からは以下のような不満が噴出します。
ホットリロード（Fast Refresh）が安定せず、待ち時間が長い。
ビルド時間が伸びる。
エラーメッセージが難解で原因がわからない。
ある開発者は、プロジェクトを別のフレームワーク（Remix）に移行した結果、Next.js時代に比べて依存関係とバンドルサイズを大幅に削減できたと報告し、こう表現しました。
「これは最適化じゃない。発掘作業だ」
さらに、2025年には重大な脆弱性が立て続けに発見されます。
CVE-2025-29927 (CVSS 9.1)（2025年3月）: Next.js Middlewareの認可ロジックを迂回でき、保護されたページに不正アクセスされる可能性
CVE-2025-55182 (CVSS 10.0)（2025年12月）: React Server Componentsにおけるリモートコード実行の脆弱性
Reactエコシステムを支える著名な開発者たちからも、厳しい声が上がりました。
7. なぜ開発者はNext.jsから離れられないのか
これほど不満が出ているのなら、なぜ開発者は Remix、Astro、SvelteKit といった、より軽量で満足度の高いフレームワークに移行しないのでしょうか？
その理由はエコシステムの重力（ベンダーロックインなき市場ロックイン） にあります。
UIライブラリやデプロイツールは、まずNext.jsで動くように（専用に）作られる。
学習や就職・求人も「Next.js経験」が有利になるため、学習者が増え続ける。
他へ移行するには、チームの再教育や既存コードの書き換え、ステークホルダーへの説得など、多大なコストと「政治的判断」が必要になる。
開発者たちは「Next.jsが絶対に最良だから」ではなく、
「離れることのコストが、留まる痛みを超えていないから」 使い続けているのです。
これを 「慣性の法則」 と呼びます。
8. まとめ
Next.jsの歴史から私たちが学べることは何でしょうか。
-
偉大な功績は色褪せない
Next.jsがSPAの問題を解決し、SSRやISRを誰でも使えるようにしたことで、Reactはフルスタック基盤へと進化しました。いまのウェブの形を作った功績は間違いなく本物です。 -
トレードオフと代償
機能の多さや進化のスピードを優先した結果、「シンプルさ」が失われ、未成熟な技術をデフォルトにしてしまうという代償を払うことになりました。 -
選択には責任が伴う
「みんなが使っているから」と盲目的に従うのではなく、「これは本当に最良の選択なのか？」と常に問い続けることが重要です。
いかがでしたでしょうか？
「救世主」として誕生したNext.jsが、現在「問題児」として扱われつつある物語。
これはNext.jsを非難するものではなく、技術の選択に伴う責任についての物語です。
技術の進化に完璧な解決策はありません。
より良いウェブの未来を作るのは、私たち開発者自身の選択にかかっているのです。
おわりに
いかがでしたでしょうか？
Next.jsはAIブームがあり、より選択せざるを得なくなってきているように思えます。
これからフロントエンドの歴史がどう変わるのか？他のフレームワークが覇権争いに加わるのか？
動きが楽しみです。
詳しく解説した動画を投稿しているのでよかったらみてみてください！
JISOUのメンバー募集中！
プログラミングコーチングJISOUでは、新たなメンバーを募集しています。
日本一のアウトプットコミュニティでキャリアアップしませんか？
興味のある方は、ぜひホームページからお気軽にカウンセリングをお申し込みください！
▼▼▼
参考