先日、ThePrimeagen の動画で面白いものを見つけたのでご紹介します。
実は、Vercelには内部に非公開フラグがあり、next build した際にISRに最適化するための内部ロジックが動くとのこと。それにより、セルフホストした際は完全なISRが利用できないそうです。ベンチャーキャピタル上がりのOSSは利益重視なので、そのへんが絡んでいるとのことで、詳しくは以下の動画で議論されています。
Next.jsは「Webフレームワーク」ではなく「インフラ」#
Dax氏によると、Next.jsが他のフレームワークと決定的に異なるのは、開発元である Vercel自身が大規模なクラウドインフラ事業者である という点とのこと
Vercelは、
- フレームワークとして機能を実装する
- インフラの仕組みとして機能を実装する
という、二重の選択肢を同時に持つ極めて特殊な立場にあります
その代表例が PPR（Partial Prerendering）
PPRでは、以下の処理が 単一のHTTPリクエスト内で完結 する
- ヘッダーなどの静的部分を事前にビルド
- それをVercelのエッジに配置
- ユーザーのリクエストに即座にレスポンス
- 動的コンテンツは後からストリーミング配信
この構成は、一般的なサーバーやオンプレ環境では ほぼ再現不可能 な設計となっている
Astroのような他フレームワークは、特定のインフラに依存しない「移植性」を優先している
一方、Next.jsは「Vercelがある前提」で設計されており、結果として Next.js は 単なるフレームワークではなく、Vercelと一体化した“インフラソリューション” になっているとDax氏は指摘
「Dockerで動く」は事実だが、それはNext.jsの本来の価値を捨ててることに等しい#
確かに、最小構成のNext.jsアプリであれば、Dockerコンテナ1台でも起動できます。
しかし問題は、Next.jsの代名詞ともいえる以下の機能を使い始めた瞬間に発生するそうです。
- ISR（Incremental Static Regeneration）
- 画像最適化
- 高度なキャッシュ戦略
- エッジ実行とストリーミング
これらは Vercelのインフラと強く結合した設計 になっており、「Dockerで動く」という表現が成り立つのは “価値をほとんど使っていない場合のみ”
Vercelだけが使っている「非公開ビルドフラグ」#
さらに問題を複雑にしているのが、Vercelが内部でのみ使用している ドキュメント化されていないビルドフラグの存在 だといいます
一般的に開発者が実行する next build の出力は、実は Vercel成果物自身が本番で使用しているとは異なります。 Vercelは内部向けに、より最適化された別形式のビルドを生成しており、その仕様は公開されていない
しかもこの内部仕様は、
- 頻繁に変更される
- 後方互換性が保証されない
- 外部プロジェクトは追随不可能
という状態です。
Dax氏はこれを 「逆方向からのリバースエンジニアリングを常に強いられている」 とのことです。
キャッシュ問題だけでも「無数の切り傷」が始まる#
たとえば Next.js コンテナをスケールさせて複数台構成にすると、
- 各コンテナのメモリキャッシュは同期されない
- ISRの再生成タイミングがズレる
- 想定外のキャッシュ不整合が頻発する
これを解決するためには、Redisなどの外部キャッシュ基盤を自前で構築し、Next.jsと正しく連携させる必要がある。
これはほんの一例であり、Dax氏は次のように言っています
「これは銃創のような致命傷ではないが、無数の小さな切り傷が積み重なっていくような問題だ」
そしてこの問題の核心について、
「Next.jsを使う理由になる機能ほど、セルフホストでは最も難しい」
OpenNextは救援活動として誕生した#
OpenNextは、Next.jsをAWSや任意のクラウド環境で動かすための互換レイヤーを提供するOSSです。しかし、このプロジェクトは「面白そうだから始めた」ものではありません。
実態は、
- セルフホストに苦しむ開発者からの膨大な要望
- 「誰かどうにかしてくれ」という切実な声
に押し出される形で誕生した、いわば “コミュニティからのSOSに応えるプロジェクト” でした。
さらに皮肉な事実として、OpenNextの主要メンテナーの多くは 日常業務ではNext.jsを使っていません。それでも彼らは、仕様変更に追われながら、リバースエンジニアリングと互換実装を続けています。
Dax氏の言葉は、この状況を象徴しています。
「このプロジェクトが“存在している”という事実そのものが、すべての証拠だ」
VC主導のOSSは「コミュニティ」ではなく「100倍のリターン」を優先する#
Dax氏によると、この問題はNext.js固有の話ではないそうです
背景には VC（ベンチャーキャピタル）主導OSSの構造的な問題 があるとのこと
VCの世界では、
- 年商数億円の黒字企業 → 「失敗」
- 投資額の数十倍〜100倍のリターン → 「成功」
という極端な評価基準が存在
Dax氏は、Googleを例に次のように説明している
「もし今Googleが生まれていたら、ほとんどの人は月額課金モデルにしただろう。しかし現実のGoogleは“無料”を選び、結果として広告という巨大市場を生み出した」
VCがOSSに期待しているのも、まさに
- まず市場を独占する
- 収益モデルは“後から”自然発生する
という博打的成長戦略とのこと
Dockerのときはどうだった？#
この構図を最も象徴するのがDockerだそうです
- コンテナ技術を事実上の業界標準に押し上げ
- ITインフラの構造そのものを変えた
という意味で、疑いようのない成功を収めたが、Dockerが生み出した莫大な価値の多くは
- AWS
- Google Cloud
- Azure
といった巨大クラウドベンダーに吸収され、Docker社自身は長年収益化に苦しむことになった
その後、Docker Desktopの有料化に踏み切ったことで状況は一変し、Dax氏によれば、
「Dockerは、たった1年でARR1億ドルに到達した」
にもかかわらず、VC的視点では「成功までに時間がかかりすぎた」と評価されかねなかった。
これが “Dockerのパラドックス” だそうです。
結論：我々は「ツール」ではなく「エコシステム」を選ばされている#
Next.jsのセルフホストがここまで難しい理由は、技術力の不足ではなく、
- フレームワークとクラウドの密結合
- 非公開仕様に依存するビルドプロセス
- VCが求める“ベンチャースケール”の成長戦略
- 競合が容易に模倣できない“ビジネス上の堀”
これらすべてが意図的に組み合わされた結果とのこと
Next.jsを選ぶという行為は、
単なる開発ツールの選択ではなく、
「Vercelのインフラ」「VC主導のビジネスモデル」「ロックイン構造」まで含めた選択をしている
さいごに#
これを聞くと、デジタル庁がNext.jsを辞めてPHPにしたのもわかる気がします。サイトの規模にもよりますが、ある程度大きくなるとISRや画像最適化を目的としてNext.jsを利用する場合Vercel依存になるので、転送量とキャッシュの問題等含め、結局お金を搾り取られることになるのですよね。まあPHPサーバはWordpressの影響で運用ノウハウが完全にシステムとして確立されていますし、何より安いですからね。node環境は何かとモダンな技術力がいるので、運用は大変です。
ISRは非常に便利ですが、もちろんAPI提供側の転送量の問題もあります。つまりバックエンドです。結局ISRはCDNキャッシュのチューニングと同じでヒューリスティックがある程度入るのでキャッシュの間隔をあわせるのも難しい問題です。どの層でキャッシュを入れるかによりますが、少なくともセルフホストでOpenNextを利用した場合、技術的にS3などバケット保管になるので、それもそれでめんどくさそうです。
少し話がそれましたが、OSSだから無料と言って闇雲に技術選定すると、運用していくうちに沼にハマることも多々あることがわかりました。といってもDockerは偉大です、非常に勉強になりました。Daxさんありがとうございます。
Dax氏のTwitterはこちら