はじめに
Next.jsで開発しているWebアプリを、VercelからCloudflare Workersへ移行する準備を進めています。
その過程で登場したのが、OpenNextという技術です。
Next.jsはVercel以外でも動作しますが、デプロイ先によってはNext.jsのサーバー機能を動かすための対応が必要になります。
OpenNextは、その違いを吸収するためのオープンソースの仕組みです。
今回は、OpenNextの役割やCloudflare Workersとの関係、導入時に注意したい点について整理してみます。
OpenNextとは？
OpenNextは、Next.jsのビルド結果を、Vercel以外のプラットフォームでも動かせるようにするためのオープンソースプロジェクトです。
もともとはAWS LambdaなどでNext.jsを動かすために始まり、Cloudflare WorkersやNetlifyなど、複数のプラットフォームに対応するアダプターが開発されています。
例えば、Cloudflare Workers向けには@opennextjs/cloudflareというパッケージが提供されています。
OpenNextは、Next.jsそのものを置き換えるフレームワークではありません。
Next.jsで作成したアプリケーションを、デプロイ先の実行環境に合わせて動かすためのアダプターという位置づけです。
なぜOpenNextが必要なのか？
Next.jsには、静的なHTMLを配信するだけでなく、サーバー側で処理を行う機能があります。
例えば、以下のような機能です。
- SSR（サーバーサイドレンダリング）
- API Routes・Route Handlers
- React Server Components
- Server Actions
- ISR（Incremental Static Regeneration）
これらを動かすには、デプロイ先でNext.jsのサーバー処理を実行できる必要があります。
通常のNode.jsサーバーであれば、Next.jsをnext startなどで実行できます。
しかし、Cloudflare Workersは一般的なNode.jsサーバーとは異なる実行環境です。
そこでOpenNextが、Next.jsのビルド結果をWorkersで実行できる形式へ変換します。
OpenNextの仕組み
Cloudflare Workersへのデプロイを例にすると、処理の流れは以下のようになります。
Next.js
↓
next build
↓
Next.jsのビルド結果
↓
OpenNext
（Cloudflare向けアダプター）
↓
Cloudflare Workers向けの出力
↓
Wrangler
↓
Cloudflare Workers
それぞれの役割を整理すると、以下のとおりです。
| 技術 | 役割 |
|---|---|
| Next.js | Webアプリケーションを開発する |
| OpenNext | ビルド結果をデプロイ先に合わせて変換する |
| Cloudflare Workers | アプリケーションを実行する |
| Wrangler | Workersのローカル実行やデプロイを行う |
つまり、OpenNextはNext.jsとCloudflare Workersをつなぐ橋渡し役です。
Cloudflare WorkersでOpenNextを使うには？
Cloudflare Workers向けには、@opennextjs/cloudflareというアダプターを使用します。
pnpmを利用している場合、例えば次のようにインストールできます。
pnpm add @opennextjs/cloudflare
pnpm add -D wrangler
既存のNext.jsアプリを移行する場合は、OpenNextの設定やWranglerの設定を追加します。
設定が完了したら、次のコマンドでWorkers向けのビルドを作成できます。
pnpm opennextjs-cloudflare build
ローカルのWorkers環境で確認する場合は、以下を使用できます。
pnpm wrangler dev
実際のデプロイでは、次のように実行します。
pnpm opennextjs-cloudflare deploy
なお、これらはOpenNextの設定が完了していることを前提としたコマンドです。実際の導入では、wrangler.jsoncなどの設定や、必要に応じたBindingsの設定も行います。
OpenNextを導入すればNode.jsのパッケージも動く？
ここは注意が必要です。
OpenNextを導入したからといって、Node.js向けのパッケージがすべてCloudflare Workersで動くようになるわけではありません。
OpenNextが担当するのは、主にNext.jsのビルド結果をWorkers向けに変換することです。
一方、Node.js向けパッケージの互換性は、Cloudflare Workersが提供するNode.js互換機能や、パッケージ自体の実装に左右されます。
例えば、今回の移行準備では、画像アップロードに使用していたCloudinaryの公式Node.js SDKへの依存を見直しました。
Cloudinary自体は継続して利用しつつ、SDK経由の処理をREST APIへの直接リクエストに置き換えています。
これはOpenNextの役割とは別の問題です。
整理すると、以下のようになります。
| 課題 | 対応する仕組み |
|---|---|
| Next.jsをWorkersで動かす | OpenNext |
| Node.js APIをWorkersで利用する | WorkersのNode.js互換機能 |
| 対応していないライブラリを利用する | 実装変更や代替ライブラリの検討 |
つまり、OpenNextはNext.jsの移植を支援しますが、アプリケーションのすべての依存関係まで自動的に解決してくれるわけではありません。
OpenNextとvinextの違い
ここで、もうひとつ知っておきたいのがvinextです。
2026年11月時点で、Cloudflareは新しくCloudflare Workers上でNext.jsアプリケーションを構築する場合、OpenNextではなくvinextを推奨しています。
OpenNextがNext.jsのビルド結果を変換するアダプターであるのに対し、vinextはViteを利用してNext.js互換のアプリケーションをビルド・実行するアプローチです。
両者はNext.jsアプリケーションをCloudflare上で動かすという目的は似ていますが、内部の仕組みが異なります。
既存のOpenNextアプリケーションについては引き続き維持できますが、今後の構成を検討する際には、vinextの対応状況も確認しておく必要があります。
まとめ
OpenNextは、Next.jsのアプリケーションをVercel以外の環境でも動かすための仕組みです。
Cloudflare Workersの場合、@opennextjs/cloudflareがNext.jsのビルド結果をWorkers向けに変換する役割を担います。
ただし、OpenNextを導入すればすべての互換性問題が解決するわけではありません。
実際には、Node.js向けパッケージや外部サービスとの連携など、アプリケーション側の実装も確認する必要があります。
Next.jsを動かすための仕組みと、その上で動くアプリケーションの互換性は別の問題である。
今回の移行準備では、その違いを理解することが重要だと感じました。
また、Cloudflareではvinextという新しい選択肢も登場しているため、今後の移行方針についても比較しながら検討していきたいと思います。