Next.jsをCloudflare Workersで動かす｜対応機能とデプロイ前の確認事項

2026年10月22日に確認したCloudflare公式ガイドでは、Next.jsアプリをWorkersで動かす標準的な経路としてvinextが案内されています。 vinextはViteを使ってNext.jsのAPIを実装する仕組みで、Next.jsのすべての環境や動作が無条件に同じになるわけではありません。公式：Next.js on Workers

公式にはbetaと明記され、既存の本番アプリでは互換性の確認が求められています。すでにOpenNextで動いているアプリや、静的出力のみのサイトもあるため、新規構築と移行を分けて説明します。

新規・既存・静的出力で、入口が違う

状況	確認する導入経路
新しいアプリを作る	Cloudflareの作成ツールでWorkers向け構成を生成する
既存Next.jsアプリを試す	対応バージョン・機能を調べ、別ブランチでvinextを追加する
OpenNextで運用中	現行構成の互換性と保守条件を確認し、移行する理由を整理する
静的出力だけで足りる	Static AssetsやPagesへの静的配信を検討する

現行ガイドの既存アプリ向け説明はNext.js 16を基準にしています。古い版や特殊なビルド設定のアプリへ、同じ手順がそのまま適用できるとは考えないでください。vinext公式リポジトリ

OpenNextを利用する経路も、既存アプリの互換性などのために案内が残っています。古い解説を見て一律にOpenNextを入れる、または動くOpenNext環境を理由なく置き換えるのではなく、必要な機能で選びます。

最初に、アプリが使う機能を一覧にする

機能・依存	自分のアプリで記録する内容
App Router／Pages Router	ルート、レイアウト、動的ページの種類
Server Actions・Route Handlers	データ更新、認証、入力検証の箇所
キャッシュ・ISR	更新トリガー、有効期限、利用者ごとの差
画像	next/image、画像元、変換サイズ、認証
Node.js依存	ファイル操作、プロセス起動、ネイティブモジュール
外部接続	DB、メール、決済、ストレージ、OAuth
運用	ログ、定期処理、公開方法、戻し方

Cloudflareの対応表だけでなく、vinextの互換性情報とWorkersのNode.js互換性を照合します。npmでインストールできることと、Workersの実行環境で動くことは別です。公式：WorkersのNode.js互換性

たとえば、CSV出力のためにサーバー上の固定ファイルへ書き込む設計なら、HTTP応答やR2などへ置き換える必要がないか確認します。長い一括処理は、Workersの実行制限に合うかも調べます。公式：実行制限

新規プロジェクトは、生成された設定を基準にする

公式ガイドの新規作成は、次のコマンドから始めます。作業用の空きディレクトリで実行し、作成先とデプロイの案内を確認します。

npm create cloudflare@latest -- my-next-app --framework=next

生成後は、そのプロジェクトの package.json と設定を読みます。現行の案内では、開発・ビルド・デプロイのスクリプトを使う流れです。

cd my-next-app
npm run dev

開発サーバーで確認した後に、生成された手順に従って本番用の成果物を作り、検証用の公開先へ配置します。

npm run build
npm run deploy

これは記事読者向けの手順例です。実際の生成内容はツールの版で変わるため、既存のWrangler設定やアダプター設定を他の記事から丸ごと貼り付けず、生成物との差を確認してください。デプロイ先アカウントと課金条件も事前に確認します。

既存アプリは、互換性チェックと比較用ブランチから始める

先にGitの変更を保存し、試行用ブランチを用意します。現行のvinext CLI経路は、次の順序です。公式：既存アプリへの追加

npx vinext check
npx vinext init

check で報告された問題を読み、init の変更内容を差分で確認します。公式ガイドでは、既存のNext.js環境を残して試せる経路として説明されていますが、自分のプロジェクトの設定や依存関係まで無条件に安全と扱わず、変更前の状態を保持します。

既存アプリへ追加した場合は、生成される dev:vinext・build:vinext などのスクリプトを確認して使用します。新規プロジェクトの dev と名前が違う点にも注意してください。

まずは本番の独自ドメインを接続せず、検証用アカウント・DB・通知先で確かめます。ログイン後の処理が実顧客へメールを送るアプリなら、画面確認の前に送信先を隔離します。

開発表示の成功後に、実行時の挙動を確認する

トップページが表示できたことを、アプリ全体の移行完了としません。利用者が行う一連の操作を、新旧で比べます。

確認対象	見るポイント
ログイン・ログアウト	Cookie、OAuthの戻り先、セッション失効
データの作成・更新	保存先、認可、再送時の重複
動的ルート	パラメーター、直リンク、404
Server Actions	フォーム送信、エラー表示、利用者の権限
キャッシュ	更新後の反映、別ユーザーへの情報混在
画像	表示、サイズ変更、外部画像の許可範囲
応答・ログ	重い入力、外部API失敗、調査に必要な記録

認証された利用者のページを共有キャッシュへ入れないこと、ログアウト後に古い情報を見せないことは、画面の見た目だけでは確認できません。別の利用者や未ログインの状態でも試します。

SecretsとBindingsを公開先ごとに分ける

APIキーなどはサーバー側のSecretsへ置き、ブラウザー向けの値へ混ぜません。ビルド時の変数と実行時の値も分けて管理します。公式：Workers Secrets

D1・R2などへのBindingsは、検証環境と本番環境で接続先を確認します。DB名が似ている場合も、設定ファイルとダッシュボードで識別できる名前を使います。型情報を生成しても、意図する本番データに接続していることまで保証されるわけではありません。

費用は、Workersのリクエスト・CPUに加えて、DB、R2、画像変換、外部APIを含めます。SSRが増えれば、静的配信のみの見積もりは使えません。

公開する条件と、戻す条件を決める

本番反映前に、主要な業務操作、権限、キャッシュ、通知、ログが確認できたかを記録します。エラー率や処理時間など、切り戻しを判断する条件も決めます。

コードの公開先を戻しても、DBへ書き込んだ内容や外部送信は取り消せません。DB変更を伴う場合は、旧バージョンでも読める期間を設けるなど、データ側の移行計画が必要です。まず小さな読み取り画面から試すと、全機能を一度に切り替えるより確認範囲を限定できます。

よくある質問

Next.jsならすべての機能が同じように動きますか？

対応状況は機能・バージョンで変わります。vinextの互換性チェックと対応表を使い、自分のアプリの機能で確認してください。

Pagesへデプロイする手順と同じですか？

静的出力の配信と、SSRなどを含むWorkers上の実行は分けます。WorkersとPagesの違いを先に確認すると、手順を混ぜずに済みます。

OpenNextで運用している場合もすぐ変えるべきですか？

必要性と互換性で判断します。現行の動作、利用機能、保守条件を記録し、新方式を別環境で試してから移行を決めてください。

次に読む記事

• WorkersとPagesを新規・既存サイトで選び分ける
• Workersの料金と無料枠
• Turnstileのサーバー検証をフォームへ組み込む

公式情報の確認日：2026年10月22日。この記事は公式手順に基づく構成・確認方法の解説であり、すべてのNext.js機能の実機動作を保証するものではありません。