Next.js 15.1+はVercel以外の環境では事実上使えない

 (omarabid.com)
13 ポイント 投稿者 GN⁺ 2025-06-13 | 5件のコメント | WhatsAppで共有
  • Next.js 15.1.8以降、メタデータ処理方式が変更され、Vercel以外のデプロイ環境で深刻な問題が発生
    • メタデータがHTML headに直接レンダリングされず、「メタデータストリーミング」という方式で別送される
  • 検索エンジンがJavaScriptを実行しない場合、メタデータがまったく露出せず、SEOが致命的に損なわれる
    • クローラー検知(htmlLimitedBots)で例外処理するが、完全ではない
  • VercelではないNetlify、Cloudflare、AWSなどはOpenNextで互換対応を試みているが、実際にはNext.jsがVercelインフラに強く結び付いており、移植自体が難しくバグも多い
  • 静的ビルドでもメタデータがHTML headに含まれず、あらゆるデプロイ環境で複雑なクローラー検知/JS実行を強いられる構造に変わる
  • セキュリティ問題（2025年3月に公開された致命的な脆弱性）
    • メタデータストリーミングを避けるために旧バージョンに固執すると、深刻なセキュリティ脆弱性にさらされる（パッチは15.2.3でのみ提供）
  • メタデータストリーミングは実際にはページ性能の問題を隠し、SEOにも悪影響を与える
  • 結論:
    Next.jsはオープンソースのように見えて、実際にはVercel依存が深刻なフレームワークになっているため、新規プロジェクトでは別の選択肢を検討するのが賢明

概要

  • Next.js 15.1.8以降、Vercelを除く環境でmetadata処理に深刻な問題が発生している
  • これはNext.jsの本質的なVercelインフラへの依存深化と、検索エンジン最適化（SEO）の低下、さらにはセキュリティ上の脅威まで引き起こす

問題の始まり: metadata streamingの導入

  • 2024年、Vercelはmetadata streamingという実験的機能を導入した
  • 従来方式と異なり、metadata（tags: title, description, Open Graphなど）をHTML ``に直接レンダリングせず、初期ページ読み込み後に別途送信する
  • この機能ではJavaScriptの実行が必要になる

Vercelの技術的説明と実質的な問題点

  • 導入背景: metadata生成の計算上のボトルネックを解消することが目的
  • しかし実際のmetadataはほとんどが静的で少量（1KB未満）のデータ
  • サーバーのround-tripコストはinline処理より大きい
  • 動的metadataはごく一部の例外的ケースにすぎない
  • metadata streamingの実装複雑性と混乱を増大させる

性能問題の背景

  • 一部の開発者が外部API連携などでmetadata生成遅延という性能問題を経験した
  • Vercelはこの問題を解決するためにストリーミング方式を開発した

検索エンジンクローラーとSEOへの影響

  • JavaScriptを実行しない検索エンジンはmetadataを読めない
  • その結果、SEOに大きな悪影響を与える
  • 解決策としてVercelは、サーバーがクローラーを検知した場合にストリーミングをスキップしてHEADにmetadataを入れるhtmlLimitedBots機能を提供している

その他のクラウド事業者の限界

  • Netlify、Cloudflare、AWSなどもNext.jsとの互換性のためにOpenNextというアダプタープロジェクトを作った
  • しかしNext.jsがあまりにもVercelに密接に依存しているため、移植にはリバースエンジニアリングが必要になる
  • OpenNextの品質問題により、実運用ではまともに動作しない

静的ビルドでさえ不完全

  • 静的サイトビルド（Static Build）でもmetadataがもはやHTML headに含まれない
  • React Server Componentsと一緒にバンドルされるため、JavaScriptの実行が必要
  • 基本的なHTML metadataのためにクローラー検知ロジックまで自前で実装しなければならないという不合理が生じる

深刻なセキュリティ脆弱性とアップデート問題

  • 2025年3月21日、**致命的脆弱性（セキュリティ等級9.1、GHSA-f82v-jwr5-mffw/CVE-2025-29927）**が公開された
  • この脆弱性により、特定のヘッダー操作を通じてミドルウェアの認証セキュリティを回避できる
  • 脆弱性のパッチはNext.js 15.2.3に適用されたが、metadata streamingを避けるために15.1.8に留まるとセキュリティ上きわめて脆弱になる

ストリーミング導入がもたらした否定的な結果

  • metadata streamingは隠れた性能問題をさらに見えにくくする
  • ページのメタデータ処理が遅延しても実利用者は気付きにくい
  • 検索エンジンクローラーは遅い応答に応じてSEOスコアのペナルティを与えることになる

結論

  • Next.jsはオープンソースフレームワークを装ったVercelのベンダーロックインへと変質した
  • 次のプロジェクトで技術スタックを選ぶ際は、Next.jsではなく他のフレームワークを検討するほうが賢明

関連記事

5件のコメント

 
kansm 2025-06-13

Remixが代替になりますよね？
 
bth15923 2025-06-13

本文で言及されている通り、過度なベンダーロックイン、あまりにもブラックボックス的な挙動、直感的でないAPI。しかもReact側でも、このようなサーバーでレンダリングする形の開発が、あたかもReactの標準的な開発方式であるかのように露骨にマーケティングしています。大半のアプリはViteベースのSPAで十分だと思います。
 
pcj9024 2025-06-13

ベンダーロックインが起きること自体はある程度認めますが、Next.jsという技術自体についての意見は、見ていると結局「私は文章を読みたくありません」というレベルから抜け出していないように思います。
 
ndrgrd 2025-06-13

前から一貫して、開かれているふりをしながら閉鎖的な動きを見せていましたが、結局ほとんど門を閉ざしてしまいましたね。
 
GN⁺ 2025-06-13
Hacker Newsの意見

  • Next の使用は絶対に勧めない。開発者体験はひどく、ベンダーロックインも強く、文書化されていない奇妙な慣習のせいで、CRUD 中心の単純な B2B SaaS でもない限り至る所に地雷がある感じ。特に Next の <Image /> タグが同じページの WebGL シーンの FPS を 2 まで落とした事例を経験した

    • Vercel がどうやって一般の React ユーザーをベンダーロックインへとじわじわ誘導したのか不思議。React は Meta がオープンソースを強調していたプロジェクトで、オープンソースがベンダーロックインを防ぐ役割を果たしてほしいと思っていたのに、実際はそうではない点に失望している

    • 完全に同意。最近かなり久しぶりに Next を使ってみたが、開発体験には非常に失望した。ドキュメントは曖昧で探しにくく、アプリ自体も基本的に遅い感じがする。Docker で AWS にデプロイしようとして、Vercel が提供するサンプル Dockerfile のせいで数多くの苦労を味わった

    • <Image /> の問題を直接分析したのか、それとも NextJs の問題だと推測しているだけなのか気になる。自分は NextJs、<Image>、RTF の組み合わせで仕事をしているが、そのような問題に遭遇したことはない

  • この 3 年間、業務で Next.js を使ってきたが本当に苦痛だった。Vercel にホスティングしており、会社は Vercel のサービスをほぼ全部導入したので、本格的なベンダーロックインを体験している。以前 Dan が RSC に関連して HN に投稿した記事に悪い体験を共有したが、彼の指摘は正確だと感じた。"RSC 自体は今ではかなり堅牢だが、Next.js のようなフレームワークはまだ少し粗い" という言葉の通り、全体的に React も今では平均以下で、Next.js はむしろ悪い評判を加速させている感じがする。距離を置くのが得策

  • Vercel は今回のバグを修正するだろうが、こういう細かい問題が積み重なって、もう Next.js にうんざりしている。例えば、ミドルウェアで prefetch を識別する方法が何週間も、あるいは何か月も壊れたままだ。こういう細かな問題がずっと積み上がっているので、Next.js に対する疲労感が大きい。ただ、JS エコシステム自体にはまだ愛着がある

    • Next.js から離れて Astro に移行した。原点に戻りたかったが、自分でルート、テンプレート、静的アセット、ビルドを設定するのは面倒だった。Astro はそのすべてを処理してくれて、しかもデフォルトで SSR。React や Vue を本来意図された通り、インタラクション層として上に載せて使う感覚で、JS フレームワークが実際にはどれほど不要かを思い知らされた。Next はどんどん魔法のような要素が増え、サーバーアクションもぎこちなく、"NextJS流" の実装が多すぎた

    • 現在、業務でもサイドプロジェクトでも Next.js を使っているが、以前は楽しくて生産的だったツールが、pages から app router へ移行して以降、方向性が残念になった

    • 15.1.8 以降、一部のライブラリ1が壊れ、投稿者が言及した脆弱なバージョンへダウングレードしなければならない状況が発生した

    • 同感。今後 Next.js は静的サイトか事前ビルドされた SPA にしか使わないつもり

  • Next は冗談のネタになりつつある。Remix が理解不能なくらい react-router に変身してしまった今、まともな React フレームワークは極めて少なくなった感じがする。結局 plain vite と tanstack router の組み合わせに戻った

    • こういう批判的な投稿が Hacker News に残っていること自体が驚き。以前、Remix ならもっと簡単に実装できるという投稿をしたら、Vercel の社員複数人から削除するよう求められたり、ミーティングしようと言われたりしたことがある。複数の SNS アカウントから同時に連絡してきた

    • ブランド変更後は Remix をもう使っていないという意味なのか、それともフレームワークではないという意味なのか気になる。RR7(React Router 7) もフレームワークとして問題なく動作する1。自分は 15 年間バックエンドをやっていて最近フルスタックに転向し、親しい友人の勧めで RR7 を使っているが、毎日感心している

    • 新しいプロジェクトで TanStack Router を使ってみたらとても良かったので、TanStack Query と TanStack Form も追加した

    • 代替として何が最良なのか、そして Vite を使う理由が気になる。自分は小規模プロジェクトに Next を使っているが、SEO が最大の利点だと聞いていた。静的ファイルだけ生成して S3 にアップロードすれば終わりではないのか、という疑問がある

    • Remix が react-router に変わったことで、具体的に何が問題なのか気になる。自分には単なるリブランディングに見える

  • Vercel のようなところが主導する React、Next、Svelte などには、もっと慎重に向き合うべきだと何年も前から強調してきた。彼らの目標は Heroku のようなことを、しかもはるかに攻撃的に、スタック全体(言語-ランタイム-マシン)で完全なロックインを誘導することだ。他の企業にも問題はある。例えば Cloudflare の CLI デプロイツールは macOS 13.5+ しかサポートしていないが(2年少し前のもの)、理由がよく分からない。2 年前に出た OS が旧式扱いされる現実が悲しい。古いバージョンの wrangler を使うことはできるが、ドキュメントと機能が一致せず、どうせさらに悪化していきそうだ。いつか互換性も切られるかもしれない。一方、別のツール(vim、neovim、emacs など)は今でも古い OS X で動く。こうしたオープンなツールにはロックインの動機がないからだと思う

  • Next と RSC は、これまでフロントエンドで触った中で最も苛立たしいものだ。フロントエンドだけでも十分に厄介なのに、そこへ Next の "魔法" が加わり、さらに Vercel にまでベンダーロックインされる。チームでは今週、tanstack router と vite に切り替えて、普通の CSA を作ってみる予定なので楽しみだ

    • RSC の何がそんなに苛立たしいのか気になる。自分の経験では本当にうまく動いていて、今でも Next.js を使う唯一の理由がまさに RSC だ

  • 開発モードの Next.js で、ルートのコンパイルに 10 秒かかる現象をもっと大きく取り上げるべきだ。Rust コンパイラは隅でタバコを吸っているようなものに感じる

    • 使いものにならないレベル。自分が経験した中で最悪の devx だ。最後にこれほど嫌だったスタックは、Sharepoint サイトの手伝いをしたときくらい

    • 今では単なるスクリプト言語の JS ですらビルド/コンパイル段階を何度も経るようになり、もはや C++ コンパイラより時間がかかる。Clang をブラウザに入れたほうがまだマシな体験になりそうなほどだ。ちなみに会社では PHP も使っているが、そこでも同じ問題がある。スクリプト言語だから簡単だと思っていたのに、PHP 自体のパフォーマンス限界のせいでコードの事前生成と Composer のビルド段階を別に設けなければならない。しかもこのビルドも遅い。GCC の作者たちが作ったわけではないからだろう

    • 不思議なことに、next dev —-turbo オプションも自社のコードベースでは速くならない

    • Rust コンパイラは本当にコンパイル作業をしているが、Next.js コンパイラが実際にそれほど複雑な処理をしているのか疑問だ

  • 今の Next.js の姿は残念だ。今でも使ってはいるが、自分でフォークしてパッチを当てて使わなければならないほど。next.config.js はデフォルト動作を変えるための険しい脱出口になっていて、こうしたオプションは本来、拡張ポイントとして提供し、"feature flag" の裏に隠すべきではなかったと思う。今では完全にスパゲッティコードに近い D 評価のフレームワークだ

  • NextJS でないなら、フルスタックとして何を組み合わせるのがおすすめかという質問。自分は 15 年の経験を持つバックエンド開発者だが、フロントは AngularJS 以来ほとんど触っていない。最近サイドプロジェクトのためにフルスタックアプリを作ろうとして調べたところ、Gemini でも公式ドキュメントでも NextJS が推奨されていた。まだ初期段階なので代替案を学びたい。すべて Docker で VPS に自前運用する予定なので、Vercel や Netlify は避けるつもり

    • サーバーレンダリングが不要なら、フレームワークなしの React と Vite1 の組み合わせを勧める。開発中は Vite で回し、本番ビルドでは HTML + JS ファイルだけが出るので、S3 のような静的ホスティングに載せれば終わり。10 年以上使ってきたが問題はない。バックエンドは自分が使いやすいものを使えばよく、自分は最近 PostgREST2 を主に使っている。クライアントからの API 呼び出しには react-query3 を勧める

    • どんなプロジェクトを開発しているのか気になる。自分は典型的な SaaS Web アプリを作っているが、React/Refine.dev/Vite の組み合わせがとても良かった。Refine.dev のおかげで CRUD ページに悩まず、機能開発そのものに集中できる

  • 今回の問題は誇張されていると思う。React でストリーミングがどう動くかを知っている人にとって、HTML を 1 行ずつストリーム処理できないのは常識だ。メタデータのために最初のペイント(HTML であって JS ではない)までブロックされるべきではない。こうした挙動で一部のユーザーエージェントを例外扱いするのは合理的だ。大半のトラフィックでは、できるだけ速く表示することのほうが重要だからだ。メタデータの読み込みに時間がかかるユーザーがいる場合、どう解決するのか気になる