Elvis Li
Back to all posts
Tutorial

究极の解決策: OpenNextを使用してNext.js 15をCloudflare PagesからWorkersに移行する

#cloudflare-workers#cloudflare-pages#opennext#nextjs#deployment

Next.js 15 アプリケーションを構築し、@cloudflare/next-on-pages を使用して Cloudflare Pages にデプロイしようとしている場合、おそらく壁にぶつかったことがあるでしょう。

恐ろしい "Invalid prerender config" エラー、静的ルートと動的ルートのレンダリングの不整合、そしてエッジランタイム設定の衝突は、コミュニティにとって大きな悩みの種でした。私のポートフォリオサイトでこれらの正確な問題をデバッグするのに何時間も費やした後、ついに完璧な解決策を見つけました。それは、OpenNext を使用して Cloudflare Pages から Cloudflare Workers に移行することです。

このガイドでは、なぜ Next.js on Pages が失敗するのか、そしてアーキテクチャを Cloudflare Workers にクリーンに移行し、完璧で堅牢なデプロイメントを実現する方法を正確に紹介します。

問題: Next-on-Pages の制限

Cloudflare Pages は元々、純粋な静的サイト向けに設計されました。@cloudflare/next-on-pages を介してサーバーサイドレンダリング (SSR) や Edge Functions をサポートするように進化しましたが、Next.js 15 の App Router との統合は依然として脆弱です。

静的な SSG ルート (ブログ記事など) と動的な edge ルート (API エンドポイントやデータベースクエリなど) を混在させると、ビルドプロセスが頻繁に行き詰まります。

Error: Invalid prerender config for /app/[locale]/about
The following routes were not configured to run with the Edge Runtime...

根本的な問題は、Vercel のビルド出力が想定する関数の構造と、next-on-pages が Pages 環境向けにそれらをどのように解釈するかの間の不一致です。

解決策: OpenNext と Cloudflare Workers

Pages のビルドシステムと格闘する代わりに、現代的なアプローチは OpenNext (@opennextjs/cloudflare) を使用し、直接 Cloudflare Workers にデプロイすることです。

Workers は、Next.js の SSR および API ルート要件に完全に適合する真のサーバーレス実行環境を提供し、一方 Cloudflare Assets が静的ファイルを処理します。

段階的な移行パスは次のとおりです。

ステップ 1: 依存関係のインストール

next-on-pages を削除し、Cloudflare 向けの OpenNext をインストールします。

npm uninstall @cloudflare/next-on-pages
npm install -D @opennextjs/cloudflare

ステップ 2: OpenNext の設定

プロジェクトのルートに open-next.config.ts ファイルを作成します。これにより、OpenNext に対して Next.js のビルドを Cloudflare 向けにどのように適応させるかを指示します。

import type { OpenNextConfig } from 'open-next/types/open-next.js';

export default {
  default: {
    override: {
      wrapper: 'cloudflare-node',
      converter: 'edge',
      incrementalCache: 'dummy',
      tagCache: 'dummy',
      queue: 'dummy',
    },
  },
  middleware: {
    external: true,
    override: {
      wrapper: 'cloudflare-edge',
      converter: 'edge',
      proxyExternalRequest: 'fetch',
    },
  },
} as OpenNextConfig;

ステップ 3: Workers 向けの Wrangler のセットアップ

Worker のデプロイメントを定義するために wrangler.jsonc (または wrangler.toml) が必要です。メインエントリを生成された OpenNext ワーカーに向け、静的アセットをバインドしている点に注目してください。

{
  "main": ".open-next/worker.js",
  "name": "your-project-name",
  "compatibility_date": "2026-06-15",
  "compatibility_flags": [
    "nodejs_compat"
  ],
  "assets": {
    "directory": ".open-next/assets",
    "binding": "ASSETS"
  }
}

ステップ 4: ビルドスクリプトの更新

最初に Next.js でビルドし、次に OpenNext で処理するように package.json を更新します。

"scripts": {
  "build": "next build && opennextjs-cloudflare",
  "preview": "npm run build && wrangler dev",
  "deploy": "npm run build && wrangler deploy"
}

ステップ 5: エッジ設定のクリーンアップ

OpenNext を使用すると、ビルドシステムをなだめるためだけにすべての動的ファイルの先頭で export const runtime = 'edge' を厳格に強制する必要がなくなります。OpenNext の cloudflare-node ラッパーは Node.js API と エッジ API をインテリジェントに処理し、コードベースを大幅に簡素化します。

Cloudflare R2 についてはどうですか？

この移行中に、Cloudflare R2 バケットをプロビジョニングする必要があるかどうか疑問に思うかもしれません。

短い答えは「いいえ、すぐには必要ありません」です。 Next.js の静的アセット (画像、CSS、JS チャンク) は、wrangler.jsonc で定義された Cloudflare Assets バインディングによって完全に提供されます。

ただし、アプリケーションがユーザーのアップロードしたメディア、大容量の動画、または大規模なデータセットを処理するようにスケールする場合、R2 はこの Worker アーキテクチャにシームレスに統合されます。wrangler.jsonc で R2 バケットをバインドし、サーバーアクションや API ルート内で env.MY_BUCKET を介してアクセスするだけです。

結果

OpenNext を使用して Cloudflare Workers に移行することで、以下のことが達成されます。

  • ビルドエラーなし: プリレンダリング設定で頭を悩ませることはもうありません。
  • 完璧なローカライゼーション: 国際化ルーティング (/[locale]/) は何も設定せずに機能します。
  • Node.js 互換性: nodejs_compat フラグにより​​、より幅広い npm パッケージがサポートされます。

Cloudflare Pages はシンプルな静的サイトにとっては素晴らしいものですが、野心的な Next.js 15 アプリケーションにとっては、Cloudflare Workers 上の OpenNext こそが間違いなく前進するための手段です。