【完全保存版】Next.jsをVercelからOpenNext for Cloudflareへ移行する：世界一詳しい実践ガイド
なぜ今、私はOpenNext for Cloudflareへの移行に踏み切ったのか
このブログを書こうと決めた直接のきっかけは、あるデプロイログに表示された一行のエラーでした。
CopyGenerated Pages Functions bundle size (xxxxxxxx) is over the limit of 25.0 MiB
空音開発のアプリは Cloudflare Pages（@cloudflare/next-on-pages）で運用してきました。
しかしプロダクトの成長とともにバンドルサイズが膨らみ続け、ついに 25 MiBという上限の壁にぶつかってデプロイが通らなくなったのです。
これが、Pagesを卒業して Cloudflare Workers（OpenNext for Cloudflare） へ移行することを決意した、すべての始まりでした。
そもそも「バンドルサイズ制限」とは何なのか
Next.jsアプリをデプロイすると、サーバーサイドのコード（API Routes、Server Components、Server Actions、Middlewareなど）は、最終的にひとつの実行ユニットにまとめてバンドルされます。
このバンドルには、自分が書いたコードだけでなく、利用しているnpmパッケージ、UIライブラリ、各種SDK、そしてランタイムの差異を埋めるためのポリフィルまでが含まれます。
そして各プラットフォームには、この1つのバンドルが取り得る最大サイズにハードな上限が設けられています。
筆者が運用していたCloudflare Pagesの場合、Pages Functionsのバンドルが 25 MiB を超えるとデプロイが失敗します。
問題なのは、ここ数年でNext.jsアプリの依存関係が肥大化していることです。
rechartsやframer-motionのような重いUIライブラリ、各種SaaSのNode.js SDK、それにNext.js自身が生成するNode.js互換ポリフィルが積み重なり、何気なく機能を足していくだけで、バンドルは簡単に2倍、3倍に膨れ上がります。
なぜ単なる「サイズ削減」では解決しないのか
最初に考えたのは、もちろんバンドルを削って25 MiBに収める方向です。
実際、不要な依存を削ったり、importを最適化したりすれば、一時的には上限の内側に戻すことはできます。
しかし、これは本質的な解決ではありません。
なぜなら上限ギリギリで運用するということは、新しい機能をひとつ足すたび、依存をひとつ追加するたびに、またデプロイが通らなくなるリスクを抱え続けることを意味するからです。
つまりこれは「プロダクトの成長そのものがブロックされる」状態であり、放置すれば「機能を足したいのにデプロイできない」という最悪のジレンマに陥ります。
サイズを削るのは延命策にすぎず、いずれ同じ壁にもう一度ぶつかるのは目に見えていました。
制限と戦い続けるのではなく、制限の前提そのものを変える ——— つまり、next-on-pages（Pages）からOpenNext（Workers）へ、土台ごと乗り換えるという選択です。
なぜWorkers（OpenNext）への移行が答えになるのか
ここで「Workersのほうが制限が緩いのか？」という疑問が湧くと思います。
数字だけ見ると、実はWorkersの制限は圧縮後サイズで無料プラン3 MiB・有料プラン10 MiBと、Pagesの25 MiBより小さく見えます。
しかしこれには重要なカラクリがあります。
判定されるのは圧縮後（gzip）のサイズだという点です。
Pagesの25 MiBは非圧縮サイズでの判定であり、Workersの10 MiBは圧縮後での判定なので、同じアプリでも実際に比較される数値の意味がまったく異なります。
そしてこちらが本質ですが、OpenNext（Workers）はNode.jsランタイムで動くという点です。
旧来のnext-on-pages（Pages）はEdgeランタイム専用で、fsやcryptoといったNode.js APIが使えず、その制約を回避するために大量のポリフィルやシムをバンドルに抱え込んでいました。
バンドルが肥大化していた一因は、まさにこのEdgeランタイムをむりやりNode.js風に見せるための「水増し」だったというわけです。
OpenNextに移行すれば、Cloudflare WorkersがネイティブにNode.js APIを提供し、nodejs_compatフラグによって内蔵の軽量実装が使われるため、そもそもバンドルに詰め込む必要があったポリフィル自体が大幅に減ります。
移行することで得られるメリット
OpenNext for Cloudflareへの移行は、25 MiBの壁を回避するためだけのものではありません。
実は、次のような複合的なメリットがあります。
その一つが、動かせるライブラリの幅が劇的に広がることです。
Pages時代はEdgeランタイムの制約で動かなかったNode.js依存のライブラリが、Workers（Node.jsランタイム）では多くそのまま動きます。
これまで「Cloudflareだから諦めていた」ライブラリの選択肢が一気に開けます。
また、対応できるNext.js機能が増えることです。
OpenNextはISR、PPR、Server Actions、use cacheなど、next-on-pagesでは制約のあった機能を幅広くサポートしており、Cloudflareも公式にこちらを「推奨デプロイ方法」と位置づけています。
Pagesは事実上の旧世代となりつつあり、長期的に見ても移行は時流に沿った判断です。
これは見落とされがちですが、バンドルと向き合うことで依存関係が健全化されるという副次効果です。
移行作業を通じて「本当に必要な依存は何か」を棚卸しすることになり、結果的にアプリ全体が軽く、速く、保守しやすくなります。
25 MiBの壁は厄介な敵に見えて、実はコードベースを健全に保つための強制力でもあったわけです。
Vercelとの比較とトレードオフ
移行自体はみなさんお使いのAIとともに問題なく実装できると思います。
移行を検討する際の判断材料として両者のトレードオフを整理します。
Cloudflareへ移行する最大の動機はスケール時のコストです。
Vercelは開発体験が圧倒的に優れている一方、トラフィック増加に伴うコストが急増しやすく、ビルド時間の肥大化やエッジ関数のコールドスタートといった課題も報告されています。
Cloudflareは帯域課金がなく、R2はエグレス無料、Workersの料金体系も大規模になるほど有利になりやすい傾向があります。
一方でCloudflareのデメリットは、本記事で見てきたとおりセットアップとキャッシュ設計の複雑さです。
Vercelなら自動で済むISRやオンデマンド再検証を、R2・D1・Durable Objects・Queueといったプリミティブを組み合わせて自分で構築する必要があります。
Workerサイズ制限への対処も継続的な運用負荷になります。
したがって判断軸はシンプルで、小〜中規模で開発スピードを最優先するならVercelの体験は依然として最良です。
トラフィックが大きくコストが経営課題になっている、あるいはすでにCloudflareエコシステム（R2、D1、Workers）に投資しているなら、OpenNext for Cloudflareへの移行は強力な選択肢になります。
筆者の場合は、Cloudflareエコシステム（R2、D1、Workers）に投資しているので、迷うことはありませんでした。
まとめ
OpenNext for Cloudflareは、2025年の1.0-betaを経て、Next.js 14/15/16のほとんどの機能を実用レベルで動かせるところまで成熟しました。
これらを理解していれば、移行は決して難しくありません。
まずはnpx @opennextjs/cloudflare migrateで第一歩を踏み出し、npm run previewで本番に近い環境を確認しながら進めることをおすすめします。