はじめに
Next.jsはReactベースの強力なフレームワークであり、Vercelはその最高の実行環境です。しかし、プロジェクトが成長するにつれ、以下のようなニーズが出てくることがあります。
- 「既存のAWS環境にインフラを統合したい」
- 「Vercelのデータ転送コスト（Bandwidth）を抑えたい」
- 「Cloudflare Workersのエッジ性能をフル活用したい」
そんな時の救世主が OpenNext です。本記事では、OpenNextの概要から各クラウド（AWS、Cloudflare、Deno）との関係性までを、初心者向けに分かりやすく解説します。
この記事の対象読者
- Next.jsをVercel以外で動かしたいエンジニア
- OpenNextの名前は聞いたことがあるが、仕組みが分からない方
- インフラのコスト最適化やベンダーロックイン回避を検討中の方
OpenNextとは？
OpenNextは、Next.jsのビルド成果物を、Vercel以外の環境（主にサーバーレス）で動作させるためのオープンソース・アダプターです。
Next.jsを next build すると、通常はVercelに最適化された形式で出力されます。OpenNextはこの出力を解析し、各クラウドベンダー（AWS LambdaやCloudflare Workersなど）が理解できる形式へと「翻訳」する役割を担います。
Vercelとの関係：iPhoneとAndroidの比喩
VercelとOpenNextの関係は、スマートフォン業界によく似ています。
- Vercel（iPhone）: ハードウェア（インフラ）とソフトウェア（Next.js）が垂直統合されており、最高に使いやすいが、エコシステムの外には出にくい。
- OpenNext（Android）: ソフトウェアをオープンにし、様々なメーカー（AWS、Cloudflare等）のハードウェアで動かせるようにする。
Vercelは内部でOpenNextと同等の「最適化エンジン」を持っていますが、それは非公開です。OpenNextは、その 「魔法の箱」をコミュニティの力で再現したOSS なのです。
なぜOpenNextを使うのか？
Vercelという快適な環境を離れてまでOpenNextを使うのには、明確な理由があります。
メリット
- 圧倒的なコストパフォーマンス: 大規模トラフィックがある場合、AWS S3やCloudFront、Cloudflare R2を組み合わせることで、Vercelの定額＋従量課金よりも安く済むケースが多いです。
- 既存インフラ・VPCとの統合: すでにAWSで運用しているプロジェクトなら、VPC内のDB（RDSなど）にセキュアかつ低遅延で接続できます。
- ベンダーロックインの回避: 特定のプラットフォームに依存せず、ビジネスの状況に合わせてインフラを柔軟に切り替えられます。
注意点（トレードオフ）
- 設定の複雑さ: 「ボタン一つでデプロイ」とはいかず、IaC（CDKやTerraform）の知識が必要になります。
- 新機能への追従: Next.jsの最新機能（最新のキャッシュ戦略など）への対応は、Vercelより数週間〜数ヶ月遅れることがあります。
各プラットフォームとの関係
OpenNextは、デプロイ先に応じて「プロバイダー」を切り替えることができます。
1. AWS：エンタープライズの標準構成
AWS上では、Next.jsの機能を複数のサービスに分解して配置します。
- Lambda: SSR（サーバーサイドレンダリング）やAPIルートを実行。
- S3: 静的ファイル（JS/CSS/画像）をホスト。
- CloudFront: 全世界にコンテンツをキャッシュ・配信。
構成イメージ:
ユーザー ──▶ CloudFront ──┬──▶ S3 (静的ファイル)
└──▶ Lambda (SSR / API) ──▶ DynamoDB (キャッシュ用)
2. Cloudflare：最強のエッジ環境
Cloudflare WorkersはNode.jsとは異なるランタイムですが、OpenNextが適切に変換を行うことで、エッジでのNext.js実行が可能になります。
- Workers: 超低遅延なSSR実行。
- R2: S3互換ストレージでISRキャッシュや画像を管理。
- Wrangler: Cloudflare公式CLIツールと連携してデプロイ。
3. Deno：次世代の実行環境
Deno Deploy上での動作もサポートされています。Deno KVなどのネイティブ機能と組み合わせることで、よりモダンで高速なフルスタックアプリを構築できます。
比較表：どこで動かすのが正解？
| 項目 | Vercel | AWS (OpenNext) | Cloudflare (OpenNext) |
|---|---|---|---|
| デプロイ難易度 | ✨ 非常に簡単 | 🛠 中〜高 (CDK等が必要) | 🛠 中 (Wrangler使用) |
| コスト（大規模） | 📈 高め (帯域課金) | 📉 安め (従量課金) | 📉 非常に安い |
| コールドスタート | 🏎 高速 | 🐢 やや低速（改善中） | 🏎 高速 |
| 柔軟性・拡張性 | △ 制限あり | ◎ 無限大 | ○ エッジ制約あり |
| 最適な用途 | 個人・スタートアップ | 企業・既存インフラ統合 | グローバル・低遅延重視 |
ストレージの扱い：Vercel Blob or 外部ストレージ？
Vercel以外の環境へ移行する際、最も考慮すべきが「ファイルの保存先」です。
- Vercel Blob: Vercel専用。コード数行で実装できる手軽さが魅力。
-
AWS S3 / Cloudflare R2: OpenNext環境での標準。SDK（
@aws-sdk/client-s3など）を使って自前で実装しますが、容量制限やコスト面で有利です。
Tips: OpenNextを使うなら、ストレージもデプロイ先に合わせたもの（AWSならS3、CloudflareならR2）を選ぶのが最もシンプルで低コストです。
実装の第一歩：SST（Ion）の活用
OpenNextを直接、素の状態で設定するのは大変です。現在は、OpenNextの開発主体である SST (Serverless Stack) を使うのが一般的です。
# SSTを使ってOpenNext（AWS）環境をセットアップする例
npx sst@latest init
npx sst deploy
SSTを使えば、Next.jsのコードはそのままに、裏側でOpenNextがビルドを行い、AWS上の最適なリソースを自動で構築してくれます。
まとめ
OpenNextは、「Next.jsのポータビリティ（持ち運びやすさ）」を担保する重要なプロジェクトです。
- 小規模・スピード重視なら、迷わず Vercel。
- コスト最適化・インフラ統合・自由度を求めるなら、OpenNext + AWS/Cloudflare。
Next.jsという強力な武器を、Vercelという一つの場所だけでなく、あなたのプロジェクトに最適な場所で輝かせるために、OpenNextを検討してみてはいかがでしょうか？
📎 参考リンク
- OpenNext 公式ドキュメント
- SST (Serverless Stack) — OpenNextを最も簡単に扱えるフレームワーク