OpenNextでNext.jsをVercel以外にデプロイする方法

VercelはNext.jsをデプロイする際の最も抵抗の少ない選択肢ですが、唯一の選択肢ではありません。コスト最適化、既存のクラウドインフラストラクチャ内での運用、あるいはランタイム環境のより細かな制御が必要な場合でも、Vercel以外へのNext.jsのデプロイは2026年において十分にサポートされた選択肢となっています。

本記事では主なアプローチとして、ネイティブなセルフホスティングとOpenNext経由のプラットフォームアダプターを紹介します。

アダプターは常に必要なわけではない

OpenNextに手を伸ばす前に、Next.jsが標準でサポートしている内容を知っておくと役立ちます。

Next.jsは公式に、Node.jsサーバー、Dockerコンテナ、または静的エクスポートによるセルフホスティングをサポートしており、コンテナデプロイを最適化するためにstandalone出力が一般的に使用されます。詳細はセルフホスティングガイドに記載されています。

• Node.jsサーバー — Nginxなどのリバースプロキシの背後で next start を実行
• Dockerコンテナ — Dockerfileでアプリをパッケージ化し、任意のコンテナプラットフォーム(ECS、Cloud Run、Fly.io)にデプロイ
• standalone出力 — 必要なものだけをバンドルした最小限のビルド成果物で、コンテナに最適

これらのアプローチは完全な制御を可能にし、既にコンテナ化されたワークロードを実行しているチームに適しています。トレードオフとして、スケーリング、複数インスタンス間のキャッシュ調整、CDN設定を自分で管理する必要があります。

ISR、オンデマンド再検証、ストリーミングを複数インスタンスにわたって正しく動作させる必要がある場合、それらの機能要件は明示的に組み込む必要があり、マネージドプラットフォーム外では自動では提供されません。

OpenNextが追加するもの

OpenNextは、Next.jsのビルド出力をサーバーレスおよびエッジプラットフォーム向けに変換するオープンソースプロジェクトです。2023年にSSTコミュニティによるAWS Lambdaアダプターとして始まり、その後CloudflareおよびNetlifyへと拡張されました。

中心的なアイデアは、Next.jsが構造化されたビルド出力を生成し、OpenNextがその出力を各プラットフォームのプリミティブ(Lambda関数、Workers、CDNルール、キャッシュレイヤー)にマッピングするというものです。

Deployment Adapter API(Next.js 16.2以降)

OpenNextの取り組みは、エコシステムの大きな変化に直接的な影響を与えました。Vercel、Cloudflare、Netlify、AWS Amplify、Google Cloudとの協業のもと、コミュニティはNext.js 16.2で安定したDeployment Adapter APIを確立しました。

これまでプラットフォームはNext.jsのビルド出力をリバースエンジニアリングする必要があり、リリースごとに壊れる脆弱なプロセスでした。現在ではNext.jsはアプリのルート、静的アセット、キャッシュルール、ランタイムターゲットを型付き・バージョン管理された記述として生成します。アダプターはこの契約を直接利用します。

NetlifyのPhilippe Serhal氏が述べたように、「私たちの問題の90%に共通していたのは、ビルド出力を設定・読み取るための文書化された安定したメカニズムが単純に欠けていたことだ」。これは今や上流で解決されています。

Vercel自身のアダプターも、この同じ公開契約を使用しており、プライベートなフックは存在しません。

OpenNextを使用したAWSおよびCloudflareへのデプロイ

Next.js AWSデプロイメント

SSTコミュニティによってメンテナンスされているOpenNext AWSアダプターは、Next.jsアプリをLambda関数にマッピングし、CDNにはCloudFront、静的アセットにはS3を使用します。ISR再検証とサーバーレスインスタンス間のキャッシュ同期を処理してくれます。これらは手動で組み込むのが本当に難しい部分です。

Next.js Cloudflare Workersデプロイメント

CloudflareチームによってメンテナンスされているCloudflareアダプターは、アプリをCloudflare Workers互換のフォーマットに変換します。新規および既存のアプリでは、推奨されるセットアップは通常、アダプターのツールを使用してプロジェクトを初期化または移行することを含みます。詳細はCloudflareアダプターのドキュメントを参照してください。

重要な注意点として、ビルド変換には時間がかかるため、このアダプターはアクティブな開発イテレーションには適していません。開発中は next dev を使用し、デプロイ準備ができた段階でビルドを行ってください。

適切なアプローチの選択

新しいAdapter APIにより、アダプターは共有の互換性レイヤーとテストスイートに収束しつつあり、ストリーミングSSRやPartial Prerenderingといった機能のサポートを評価する際に、プラットフォーム間の一貫性が向上しています。

まとめ

Vercel以外へのNext.jsのデプロイは、もはや回避策ではなく、第一級の選択肢となっています。ネイティブなセルフホスティングはシンプルなケースをカバーします。サーバーレスおよびエッジでのデプロイには、OpenNextがAWSおよびCloudflare向けの堅牢なアダプターを提供し、現在では安定した公式サポートのAPI上に構築されています。セットアップが最も少ないものではなく、自身のインフラに最適なアプローチを選びましょう。

FAQ

Vercel以外でNext.jsをデプロイすると、ISRやストリーミングSSRなどの機能を失うことになりますか?

いいえ。AWSおよびCloudflare向けのOpenNextアダプターを使用すれば、ISR、オンデマンド再検証、ストリーミングSSRといった機能が本番環境でサポートされます。Next.js 16.2のDeployment Adapter APIにより、アダプターは共有テストスイートを通じて互換性を維持できるようになり、機能のパリティはかつてよりはるかに近づいています。

OpenNextを使用する代わりに、Dockerでセルフホスティングすべきはどんな時ですか?

チームが既にECS、Cloud Run、Fly.ioといったプラットフォーム上でコンテナ化されたワークロードを実行しており、ランタイムを完全に制御したい場合には、Dockerまたはnext startを選択しましょう。一方、AWS LambdaでのサーバーレスのスケーリングやCloudflare Workersによるエッジ配信を、自身でインフラを管理することなく実現したい場合には、OpenNextの方が適しています。

OpenNextは本番環境で使用できますか?

SSTコミュニティによってメンテナンスされているAWSアダプターは2023年から本番環境で使用されており、Cloudflareアダプターも Cloudflareチームによって積極的にメンテナンスされています。Next.js 16.2以降、両者は公式のDeployment Adapter APIに基づいて構築されており、リバースエンジニアリングされたビルド出力に依存することなく、安定した契約が提供されています。

ローカル開発でCloudflareアダプターを使用できますか?

日常的な開発では、高速なホットリロードを提供するnext devを使用してください。Cloudflareのビルド変換は時間がかかるため、プレビューまたはデプロイ向けであり、アクティブな反復作業には適していません。推奨フローは、next devで開発し、デプロイ前にアダプターのツールを使用してビルド・プレビューすることです。