OpenNextとは？ Next.jsをVercel以外で動かすアダプターの仕組みと2026年の最新状況
OpenNext は、Next.js のビルド出力を AWS や Cloudflare、Netlify で動く形に変換するオープンソースのアダプター群です。ホスティングサービスではなく、インフラも作りません。あくまで「ビルド結果を各プラットフォームの部品に割り当てる変換レイヤー」です。2026年3月の Next.js 16.2 で公式の Adapter API が安定版になり、OpenNext はその API に乗せた新しいアダプターを開発中という過渡期にあります。この記事では、OpenNext が解決している問題、AWS と Cloudflare それぞれの構成、そして今から採用する場合の判断基準を整理します。
OpenNext の正体：ホスティングではなく「変換レイヤー」
OpenNext は 2023年、SST コミュニティが AWS Lambda 向けに作ったサーバーレスアダプターとして始まりました。2024年5月の V3 で他プラットフォームが上に乗れる構造になり、Cloudflare と Netlify が参加してマルチプラットフォームのプロジェクトへ広がっています。現在は AWS アダプターを SST コミュニティ、Cloudflare アダプターを Cloudflare チーム、Netlify アダプターを Netlify チームが保守する体制です。
重要なのは役割の境界です。OpenNext の公式ドキュメントは、OpenNext が基盤インフラを作らないことを明記しており、インフラは SST・AWS CDK・Terraform・Serverless Framework など好きなツールで用意する前提になっています。管理画面もマネージドサービスもサポート契約もありません。つまり「Vercel の代わりに契約するサービス」ではなく、「自分のクラウドアカウントに Next.js を載せるための部品」です。ここを取り違えると、導入後に運用コストの見積もりが大きく外れます。
そもそも OpenNext が要らないケースもある
Next.js は OpenNext なしでもセルフホストできます。next start で Node.js サーバーとして動かす、standalone 出力や Docker でコンテナ化する、サーバー機能を使わないなら静的出力にする、といった方法です。Next.js 公式ブログも、単一の Node.js サーバーで運用しているチームが多数存在し、そこに制限はないと述べています。
問題が出るのはスケールさせたときです。同ブログは、サーバーインスタンスを複数並べると「キャッシュ内容のインスタンス間同期」「オンデマンド再検証の伝播」「ストリーミングの安定動作」が最適化ではなく機能要件になると指摘しています。さらに CDN からのキャッシュ配信やサーバーレスでのコールドスタート対策を重ねると、アーキテクチャの複雑さが積み上がります。
OpenNext の価値は「Vercel 以外で動かせること」そのものではなく、この配線を既製の形で用意してくれることにあります。逆に言えば、1台のコンテナで足りる規模のサイトなら、OpenNext を入れる理由は薄いと判断できます。
AWS アダプターは何をデプロイするのか
AWS 向けの推奨構成では、ビルド時に .open-next/ 以下へ役割ごとの成果物が生成されます。公式ドキュメントの記述に沿って整理すると、主な構成要素は次のとおりです。
- 静的アセット：
.open-next/assetsに出力され、サーバー関数を経由せず配信します。ハッシュ付きファイルはpublic,max-age=31536000,immutable、public/由来のハッシュなしファイルはpublic,max-age=0,s-maxage=31536000,must-revalidateが推奨値です（後者はデプロイ時の CDN キャッシュ無効化が前提）。 - キャッシュファイル：
.open-next/cacheに ISR と SSG 用のデータが入ります。fetch のレスポンスを含むため、公開可能な場所に置いてはいけないとドキュメントが明示しています。 - サーバー関数：standalone ビルドの NextServer をラップし、SSR・ISR・SSG・API リクエストを処理します。
- 画像最適化バックエンド：
<Image>のリクエストを sharp で処理します。sharp は既定で arm64 向けにコンパイルされ、Node 上で動く想定です。 - 再検証バックエンド：FIFO キューをポーリングし、対象ルートへ HEAD リクエストを送って再検証します。
- ウォーマー関数とタグプロバイダー：コールドスタート緩和と、再検証タグの登録に使われます。
この分解は、障害切り分けの単位がそのまま増えることを意味します。画像が重いサイトなら画像最適化関数が、更新頻度の高いサイトなら再検証キューがボトルネック候補になります。導入時点で各コンポーネントのメトリクスを見られるようにしておくべき、というのがこの構成から導ける実務上の結論です。
最短の導入経路は SST です。公式の手順は Next.js アプリ内で npx sst@latest init、npm install、npx sst deploy の3ステップ。SST を使わない場合は npx @opennextjs/aws@latest build でビルドし、生成物を自前の IaC からデプロイします。
Cloudflare アダプターの対応範囲と制約
@opennextjs/cloudflare は、Next.js の Node.js ランタイムを使って Cloudflare Workers にデプロイするアダプターです。Edge ランタイム専用だった @cloudflare/next-on-pages との最大の違いがここで、Workers が提供する Node.js API を使えるため、対応機能の幅が広くなります。
サポート対象は Next.js 16 の全マイナー・パッチバージョンと、14・15 の最新マイナーです。ドキュメントには Next.js 14 のサポートを 2026年第1四半期に終了する旨が記載されており、Next.js チーム自体も 14 をサポート対象外としています。古いバージョンのまま移行を検討している場合は、先に Next.js 側のアップグレード計画を立てる必要があります。
機能面では App Router、Route Handlers、SSG、SSR、Middleware、ISR、Pages Router、画像最適化、Partial Prerendering、after、'use cache'、Turbopack に対応しています。一方で Next.js 15.2 で導入された Node Middleware は未対応とされています。
見落としやすい制約が Worker のサイズ上限です。Free プランで 3MiB、Paid プランで 10MiB、判定に使われるのは圧縮後のサイズです。依存が多い管理画面つきアプリをそのまま載せると上限に当たる可能性があるため、検証は早い段階でやるべきです。また Windows の完全サポートは保証されておらず、WSL や Linux VM、あるいは Linux/macOS で動く CI（GitHub Actions など）でのビルドが推奨されています。
2026年の最大の変化：公式 Adapter API の安定化
2026年3月18日にリリースされた Next.js 16.2 で、プラットフォームがビルド処理をカスタマイズするための Adapters が安定版になりました。ビルド時に Next.js がルート、プリレンダー結果、静的アセット、ランタイムターゲット、依存関係、キャッシュ規則、ルーティング判断を型付き・バージョン付きの記述として出力し、アダプターがそれを各社のインフラへ割り当てる形です。破壊的変更には Next.js のメジャーバージョン更新が必要と定められています。
3月25日には Next.js 公式ブログが、公開テストスイート、Next.js の GitHub 組織でホストされる「verified adapter」制度、そして Ecosystem Working Group の設置を発表しました。Vercel 自身のアダプターも同じ公開契約を使い、オープンソースで公開されています。公開時点の verified adapter は Vercel と Bun（リファレンス実装）で、Netlify・Cloudflare・AWS（OpenNext 経由）のアダプターは開発中、2026年内のリリースが見込まれています。OpenNext 側も、AWS と Cloudflare のアダプターを共有モノレポで開発中であり、既存アダプターは引き続きコミュニティが保守すると明言しています。
これは実務上、無視できない変化です。従来の OpenNext はビルド出力を解析して組み立て直す必要があり、Next.js 内部の変更がそのまま破損につながるリスクを抱えていました。公開契約とテストスイートができたことで、そのリスクは構造的に下がります。ただし万能ではありません。Google Cloud / Firebase 側の投稿は、Cache Components（旧 PPR）や Proxy（旧 Middleware）のような機能には、CDN 層の前で静的シェルと動的ストリームを縫い合わせるといったアーキテクチャ上の難所が残り、Working Group で標準化を進めている段階だと説明しています。最先端機能を前提にした設計は、現時点では慎重に扱うべきです。
採用を判断するためのチェックリスト
ここまでの事実を踏まえると、検討の順番は次のように整理できます。
- サーバー機能を使うか。SSR や Route Handlers が不要なら静的出力で十分で、OpenNext は不要です。
- 単一インスタンスで足りるか。足りるなら
next startやコンテナ運用が最も単純です。複数インスタンスに分ける段階で、キャッシュ同期と再検証の伝播という要件が発生します。 - サーバーレスやエッジが要件か。既存の AWS 環境に統合したいなら AWS アダプター（SST 経由が最短）、グローバルな低遅延配信や Workers・R2 などの活用が目的なら Cloudflare アダプターが候補です。
- 運用責任を引き受けられるか。サーバー関数、画像最適化、再検証キューといったコンポーネントごとの監視とログ確認が前提になります。
- アップグレード運用を決めているか。Next.js を上げる前にアダプター側の対応バージョンを確認し、ステージングで検証する運用をルール化しておくと、移行期のリスクを抑えられます。
- 将来のアダプター移行を見込んだ構成にしているか。2026年内に公式 API ベースの新アダプターが出る見込みなので、インフラを IaC で管理し、差し替えやすくしておく価値は高まっています。
コストについては、AWS や Cloudflare のどちらに載せても自動的に安くなるわけではありません。実際の金額はトラフィック特性、キャッシュヒット率、画像処理量、データ転送量で決まります。移行前に現行の指標を取り、構成ごとに試算しておくのが先です。
まとめ
OpenNext は「Vercel の代替サービス」ではなく、自分たちのインフラに Next.js を正しく載せるための変換レイヤーです。まずは単一サーバー構成で足りるかを確認し、足りない理由（スケール、既存 AWS 環境との統合、エッジ配信）が明確になった段階で、AWS か Cloudflare のアダプターを選ぶ。そして Adapter API 安定化後の移行を見据えて、インフラを IaC で管理しておく。この順番で考えれば、過剰な構成を избежать…は避けられます。
Next.js のホスティング構成の見直しや、AWS・Cloudflare へのセルフホスト移行の設計でお困りの際は、Web サイト制作とフロントエンド開発を手がける chot Inc. のお問い合わせからご相談ください。
出典
- OpenNext: プロジェクト概要（現在の状況とアダプター一覧）
- OpenNext: OpenNext の3年間（Adapters API と今後の予定）
- OpenNext: AWS の既定アーキテクチャ
- OpenNext: AWS 向けの導入手順
- OpenNext: Cloudflare アダプターの概要と対応機能
- Next.js 公式ブログ: プラットフォームを越える Next.js — アダプター、OpenNext、私たちのコミットメント
- Next.js 公式ブログ: Next.js 16.2 リリースノート
- Next.js GitHub Discussions: デプロイメントアダプター API の RFC
- Firebase ブログ: Next.js デプロイメントアダプターと Google Cloud での今後
- Netlify ブログ: Next.js アダプター API がリリースされ、次に来るもの
- SST ドキュメント: SST による AWS 上の Next.js デプロイ
