OpenAINext.jsMar 25, 2026, 5:00 PM

Next.js Across Platforms: Adapters, OpenNext, and Our Commitments

A condensed section focused on the key takeaways first.

Original Post

Quick Digest

Summary

A condensed section focused on the key takeaways first.

openaienmodel: gpt-5-mini-2025-08-07

Next.js Across Platforms: Adapters, OpenNext, and Our Commitments

Key Points

  • Stable, typed Adapter API
  • Public, shared adapter test suite
  • Verified open-source adapters

Summary

Next.js 16.2 introduces a stable, public Adapter API that emits a typed, versioned build description (routes, prerenders, static assets, runtime targets, dependencies, caching rules, routing decisions). Adapters consume this output and map framework semantics onto platform primitives. The API exposes two hooks: modifyConfig (on config load) and onBuildComplete (when build output is ready). Breaking changes require a new major Next.js release.

OpenNext helped prove the model by translating Next.js build output into provider targets; collaboration with Netlify, Cloudflare, AWS Amplify, and Google Cloud produced the Adapter API, a shared test suite, verified adapter rules, and an Ecosystem Working Group for coordination.

Key Points

  • Adapter API: typed, versioned build output; adapters implement modifyConfig and onBuildComplete; Vercel uses the same public contract (open source).
  • Test suite: public, provider-agnostic correctness tests (streaming, caching, client navigation, revalidation); adapter authors should run it to validate behavior.
  • Verified adapters: must be open source and pass the full test suite to be hosted under the Next.js org; maintainers retain publishing and release control.
  • Existing & upcoming adapters: Vercel and Bun are available; OpenNext is enabling Netlify, Cloudflare, and AWS adapters in active development.
  • Governance & coordination: Next.js Ecosystem Working Group provides early visibility into changes; meeting notes are public and the RFC process remains open.

Practical actions for engineers:

  • Adapter authors: implement the two hooks, run the adapter test suite, open-source the adapter to be eligible for verification.
  • Platform engineers: map the typed output to your provider primitives and use the new docs (Rendering Philosophy, Deploying to Platforms, PPR Platform Guide, Revalidation, CDN Caching).
  • App teams: expect feature behavior to be encoded in the shared tests and breaking changes to follow semver major updates.

Full Translation

Translations

A translation section that keeps the flow of the original article.

openaijamodel: gpt-5-mini-2025-08-07

プラットフォーム横断の Next.js:アダプター、OpenNext、そして私たちの約束

ブログに戻る — 2026年3月25日(水)

投稿者: Jimmy Lai (@feedthejim), JJ Kasper (@_ijjk)

概要

Next.js 16.2 は、OpenNext、Netlify、Cloudflare、AWS Amplify、Google Cloud と共同で作成した安定した Adapter API を導入しました。本記事ではその経緯と、Next.js をあらゆるプラットフォームで適切に動作させるために我々が行うコミットメントを説明します。

  • Adapter API (stable): プラットフォームがターゲットにできる、型付きかつバージョン管理されたアプリケーション記述。
  • テストスイート: Vercel を含む全てのアダプター向けの共通の正当性テスト。
  • 検証済みアダプター: Next.js 組織下でホストされるオープンソースのコミュニティ所有アダプター。
  • Ecosystem Working Group: プロバイダー間で変更を調整するための常設フォーラム。

ここに至るまで

多くの Next.js アプリは単一の Node.js サーバーで next start を実行してデプロイされています。数十万のチームがこの形でプラットフォームを問わず運用しています。しかし、アプリをスケールさせるには複数のサーバーインスタンスを動かす必要があり、その場合いくつかの動作が正しく機能する必要があります:

  • キャッシュされたコンテンツがインスタンス間で同期されること
  • on-demand revalidation が正しく伝播すること
  • ストリーミングが信頼性高く動くこと

これらは最適化ではなく機能上の要件です。さらに、グローバルCDNからの配信、エッジでのコンピュート、サーバレスでのコールドスタート最適化など、選択するパフォーマンス手法によりアーキテクチャの複雑さが増します。プラットフォームやアーキテクチャによっては、ストリーミング、Server Components、Partial Prerendering、middleware、Cache Components、on-demand revalidation といった表面領域が大きくなり、それぞれの相互作用はこれまで正式に文書化されていませんでした。

プロバイダーがマルチテナント環境でリリースの進化に合わせて Next.js を完全にサポートしようとすると、課題はさらに複雑になります。

When the Next.js team reached out with an offer to discuss Netlify's challenges, we started compiling a laundry list of specific issues to share, but it quickly became clear that the common thread among 90% of these was simply the lack of a documented, stable mechanism to configure and read build output. That was what we needed above all. So that's what we told Jimmy, and we're glad we did.

— Philippe Serhal, Engineer at Netlify

足りなかったのは、プロバイダーが対応できる上流の安定した公開コントラクトでした。

OpenNext が架け橋を作った

OpenNext はそのギャップを埋めました。Next.js のビルド出力をプロバイダーが消費できる形に翻訳し、フレームワークのセマンティクスを各プロバイダーのプリミティブにマッピングしました。互換レイヤーとして始まったものが、特に AWS 上で早期の本番グレードのアダプターになり、Cloudflare と Netlify も後から参加しました。OpenNext は Next.js のビルド出力がアダプターが直接ターゲットにできる安定した定義済みインターフェースになり得ることを示しました。

この気づきにより、Next.js チームと OpenNext のメンテナ、さらに Netlify、Cloudflare、AWS Amplify、Google Cloud のエンジニア間での広範な協力が始まりました。2025年4月に Build Adapters RFC を公開し、ワーキンググループを結成して以来、これらのパートナーと共に API の設計、テスト、検証を行ってきました。

Adapter API

Next.js 16.2 には安定した公開 Adapter API が同梱されています。ビルド時に Next.js はアプリケーションの型付き・バージョン管理された記述を出力します: ルート、prerenders、静的アセット、ランタイムターゲット、依存関係、キャッシュルール、ルーティングの決定など。アダプターはこの出力を消費し、自社インフラにマッピングします。

アダプターは 2 つのフックを実装します:

  • modifyConfig (設定ロード時)
  • onBuildComplete (完全な出力が利用可能になったとき)

破壊的変更が必要な場合は Next.js のメジャーバージョンアップが必要になります。Vercel のアダプターもこの公開コントラクトを使っており、プライベートなフックや特別な統合経路はありません。Vercel アダプターはオープンソースです。

ワーキンググループからのフィードバックを踏まえ、プラットフォーム統合の表面をよりよく説明するためにドキュメントの大部分を改訂しました。新しいガイドには次のものが含まれます: Rendering Philosophy、Deploying to Platforms feature matrix、PPR Platform Guide、How Revalidation Works、CDN Caching。

テストスイート

Next.js のテストスイートをアダプター作成者向けに公開しました。これにはストリーミング動作、キャッシュの相互作用、クライアントナビゲーション、現実世界のエッジケースが含まれます。新機能が出ると、その振る舞いはこれらのテストにエンコードされます。詳細は adapter testing documentation を参照してください。

アダプター作成者は任意のアダプターでスイートを実行し、各機能ごとに合否の判定を得られます。これは Vercel が自社アダプターに対して使っているのと同じテストスイートであり、正当性の基準は全プロバイダーで共有されます。

検証済みアダプター

Next.js GitHub 組織下でホストされ、Deploying to Platforms ドキュメントに掲載される検証済みアダプターになるには、次の2点が必要です:

  1. オープンソースであること
  2. テストスイートを完全にパスすること

アダプターをオープンソースにすることで、アダプターの保守場所が確保され、問題の報告とトリアージができるようになります。テストスイートは Next.js との互換性を測定可能にします。各検証済みアダプターはそれを作るチームが所有します。公開/リリース権やリリース頻度、実装判断はそのチームに委ねられます — プラットフォームは非常に異なり得るため、我々が実装を規定することはできません。

プロバイダーは同じ公開 API 上でクローズドソースのアダプターを構築・出荷することも可能です。

現在公開されている Adapters API としては:

  • Vercel adapter: オープンソース、Next.js 出力を Vercel の serverless と CDN インフラにマッピング
  • Bun adapter: 代替ランタイム上での完全な Next.js デプロイターゲットの作り方を示すリファレンスアダプター

Netlify、Cloudflare、AWS 向けのアダプター(OpenNext 経由)は積極的に開発中で、今年後半にリリースが見込まれています。

Cloudflare has been part of OpenNext since the beginning because we believed developers deserve a stable, open contract for deploying Next.js apps anywhere. The official Next.js Adapter API makes that vision real. Developers running Next.js on Cloudflare's global developer platform will now have a shared foundation to build on, one designed in collaboration with the Next.js team to keep pace as the framework evolves. We are excited to be partners in this shared effort.

— Fred K Schott, Engineer at Cloudflare

Ecosystem Working Group

Next.js Ecosystem Working Group を設立し、Next.js チーム、ホスティングプロバイダー、アダプターメンテナ間の常設フォーラムとします。ミーティングノートは公開されます。グループに参加したい場合は Jimmy に連絡してください。

我々はプロバイダーに対して、リリース後に変更を知るのではなく、早期に変更を把握できるようにしたいと考えています。破壊的変更にはその範囲に応じたリードタイムが付与されます。新機能はリリース前に環境間でテストされます。詳細はフルガバナンス文書でコミットメントをご確認ください。

パートナーからの追加情報

  • The Next.js Adapter API Just Shipped: Here's What Comes Next (Netlify)
  • 3 Years of OpenNext (OpenNext)
  • Next.js Deployment Adapters: A Bright Future for Next.js on Google Cloud (Google Cloud / Firebase)

The collaboration between OpenNext and the Next.js team transformed a community-driven workaround into an official standard, proving that the future of web frameworks is built on openness and shared innovation.

— Dorseuil Nicolas, OpenNext

感謝とまとめ

Build Adapters ワーキンググループに参加して API の共同設計とプラットフォーム検証に時間を割いてくれた Netlify、Cloudflare、Google Cloud、AWS Amplify、OpenNext のエンジニアの皆さんに感謝します。アダプターを構築し、バグを報告し、回避策を出してくれたすべての貢献者にも感謝します。

Next.js は何百万もの開発者に使われており、その多くは Vercel 以外のインフラ上で動いています。彼らは同等の信頼性と新機能へのアクセスを受けるに値します。Adapter API はそのための共有コントラクトを提供し、公開テストスイートは我々自身を含むすべてのプロバイダーに同じ基準を課します。今後追加するすべての新機能はアダプター契約に文書化されます。RFC プロセスは引き続きオープンで、アダプター作成者と連携しながら API を進化させていきます。

参考リンク

Adapter API ・ Deploying to Platforms ・ Rendering Philosophy ・ PPR Platform Guide ・ How Revalidation Works ・ CDN Caching ・ Build Adapters RFC ・ Vercel adapter ・ Next.js Ecosystem Working Group ・ OpenNext