1. はじめに
本記事では、Next.jsを用いたエッジ実行による高速なWebアプリケーション開発に関心のあるエンジニアを対象に、Cloudflare WorkersとCloudflare Pagesを活用してフロントエンドからバックエンドまで一括管理する方法をご紹介します。
サーバーレスやエッジコンピューティング、さらにCI/CDの自動化を重視する方にとって、Cloudflareは無料プランでも非常に使いやすいプラットフォームです。本記事を通じて、以下の内容を体系的に理解できるようまとめました。
- Cloudflare WorkersとPagesの概要
- Next.js App Routerとの連携方法
- 無料プランでのリソース上限と制限事項
- 具体的な構成例とメリット・デメリット
- 今後の展望
次章より順を追って解説していきます。
2. Cloudflare WorkersとPagesの概要
Cloudflare Workersとは
Cloudflare Workersは、グローバルに分散されたCloudflareのエッジネットワーク上で、JavaScript/TypeScriptなどのコードをサーバーレスで実行できるサービスです。AWS LambdaやFirebase Functionsと同様に、リクエストに応じて動的な処理を行うバックエンドロジックを簡単にデプロイできます。
最大の特徴は、リクエストがユーザーに近いエッジサーバーで即時に処理されるため、従来のリージョンサーバー型に比べてレイテンシが非常に低いことです。また、Workers KVやR2、D1などの各種ストレージサービスと組み合わせることで、グローバルにスケーラブルなバックエンド環境が構築可能です。
Cloudflare Pagesとは
一方のCloudflare Pagesは、静的サイトやフロントエンドアプリケーション(ビルド済みのHTML/CSS/JavaScript)のホスティングに特化したサービスです。Jamstackを念頭に置いており、ビルドした成果物をCDNを介してエッジ配信することで高速なレスポンスを実現します。
さらに、Pagesはフルスタック対応が可能になり、エッジ関数(Edge Functions) を通じて動的処理を組み込むこともできます。結果的に、フロントエンドとバックエンドの両方をCloudflareで一元化し、シームレスにデプロイできるのが大きな強みです。
サービスの住み分け
- Workers: バックエンド処理(API、動的ロジック)
- Pages: フロントエンド配信(静的アセット、SSR対応のNext.jsなど)
両者は用途こそ異なるものの、相互連携することで高いパフォーマンスのフルスタックアプリケーションを実現します。
3. Next.js App Routerとの連携
Next.jsのエッジ対応ポイント
Next.jsはもともとNode.jsランタイム上で動作することを前提としていますが、近年はEdge Runtimeにも公式対応しており、export const runtime = 'edge'
を宣言することでエッジ上で実行できるようになりました。
一方、Cloudflare Pages上でNode.jsのAPIをそのまま使うことはできません。そこで登場するのが公式アダプタ(@cloudflare/next-on-pages
) です。
公式アダプタ(@cloudflare/next-on-pages)の利用方法
@cloudflare/next-on-pages
を使うと、Next.jsのアプリをCloudflare Pages用にビルドできます。基本的なステップは以下のとおりです。
-
パッケージをインストール
npm install -D @cloudflare/next-on-pages
-
Next.js設定ファイルでエッジ実行を有効化
- App Router使用時には、ページやレイアウトごとに
の指定が必要です。
export const runtime = 'edge';
- App Router使用時には、ページやレイアウトごとに
-
ビルドコマンドに組み込む
// package.json (例) { "scripts": { "build": "next build", "pages:build": "npx @cloudflare/next-on-pages" } }
-
Cloudflare Pagesのビルド設定で上記コマンドを実行
- 「Build command」に
npm run build && npm run pages:build
のように設定し、ビルド後にエッジで動作可能な成果物を生成します。
- 「Build command」に
導入手順と設定の注意点
- Edge RuntimeではNode.js特有のモジュール(fsやnetなど)が使えないので注意が必要です。
- 大規模アプリの場合はビルド時間が長くなることがあるため、Pagesのビルド回数制限(後述)に留意しながらCI/CDを計画しましょう。
- デプロイ後は
your-project.pages.dev
でSSRやAPIルートがすぐに利用できます。カスタムドメインの設定も可能です。
4. 無料プランのリソース上限と制限
Cloudflareの無料プランは非常に寛大ですが、以下のようにWorkersとPagesでそれぞれ制限があります。用途やアクセス規模によっては有料プランへの移行を検討してください。
Cloudflare Workersの無料枠
- リクエスト数: 1日あたり 100,000リクエストまで
- CPU時間: 1リクエストあたり最大10ms
- メモリ: 1つのWorkers実行あたり最大128MB
- Workers KV: 1日100k回の読み取り、1k回の書き込み/削除、1GBストレージ
- サブドメイン/Worker数: 無料枠で100個までのWorkerを作成可能
Cloudflare Pagesの無料枠
- ビルド(デプロイ)回数: 月500回まで(同時ビルドは1件)
- 静的サイト配信: 帯域無制限(ただしファイルサイズは1ファイル25MB以下、最大20,000ファイル程度)
- Edge Functions(Pages Functions): 実質Workersのリクエスト枠を利用
- カスタムドメイン: 1プロジェクトにつき100件まで追加可能
- プロジェクト数: ソフトリミットで100個程度
比較表
項目 | Cloudflare Workers (無料) | Cloudflare Pages (無料) |
---|---|---|
リクエスト数 | 1日 100,000回 | 静的コンテンツは実質無制限 |
CPU実行時間 | ~10ms/リクエスト | (FunctionsはWorkersと同等の制限) |
ビルド/デプロイ | 制限なし(Workers側にビルドの概念はなし) | 月500回(同時ビルド数1) |
静的ストレージ | - | 1ファイル25MB/合計20,000ファイル程度 |
KVストレージ | 1日100k読/1k書、最大1GB | Workers枠と共有 |
カスタムドメイン | 任意ドメインにバインド可能 | 1プロジェクト100件 |
料金超過時の動作 | 超過分はエラー応答 | ビルド回数超過時はその月の追加デプロイ不可 |
ポイント:
- Workersはバックエンド処理での1日リクエスト上限があり、約1.16リクエスト/秒に相当します。アクセスが多い場合や不正リクエストが多い場合にはすぐに到達する可能性があります。
- Pagesは静的配信が原則無制限ですが、ビルド回数が月500回なので、頻繁に更新・デプロイするワークフローの場合は注意が必要です。
- 超過時の挙動はそれぞれ異なるので、商用で利用する際は早めに有料プランの検討がおすすめです。
5. 具体的な活用例と構成図
ここからは、Next.jsアプリをCloudflare Pages(フロントエンド)+Workers(バックエンド)で構築する構成例を示します。
フロントエンドとバックエンドの統合構成
-
Cloudflareエッジがユーザーの最寄りロケーションでリクエストを受け取り、フロントエンドに該当すれば
Pages
が静的ファイルまたはエッジSSRを実行。 -
API呼び出しが必要になれば
Workers
が処理し、必要に応じてKVやD1などのストレージを参照してデータを取得・更新。 - HTML/JS/CSSなどの静的コンテンツはPagesが配信するため、グローバルなCDNとして機能。
- 結果的に静的アセットの超高速配信とエッジでのAPI処理を両立した構成になります。
実際の利用シナリオ
-
ヘッドレスCMS連携
Next.jsで構築したブログやコーポレートサイトを ISR(増分静的再生成) やエッジSSRで配信しつつ、CMSのデータをWorkers
経由で取得して動的に更新。 -
認証付きWebアプリ
ログインやJWT検証などの認証APIをWorkers
で実装。Next.jsのサーバーコンポーネントやAPI Routes(edge runtime)で呼び出し、グローバルにユーザー認証が可能。 -
画像処理サービス
フロントはNext.js、画像アップロードはR2、そしてWorkers
でリサイズやフォーマット変換。エッジ上で処理することで高速な応答を提供。
6. メリット・デメリットの考察
メリット
-
グローバルな低レイテンシ
Cloudflareのエッジネットワークにより、世界中のユーザーに対して一貫して高速なレスポンスを実現。 -
無料プランが充実&スケーラブル
100,000リクエスト/日までのWorkers枠や無制限帯域のPagesなど、開発初期のコストを抑えつつ、スケール時には有料プランで強化可能。 -
エッジ実行による高速SSR
Next.jsのSSRもエッジ上で完結し、コールドスタートも小さいため、動的ページでも体感速度が高い。 -
運用がシンプル
GitにプッシュするだけでCI/CDが自動化され、カスタムドメインやSSLも無料。複数環境のプレビュー生成も容易。 -
Cloudflareエコシステムとの統合
KV、R2、D1などのサーバレスストレージや、Queue、AI機能などとも連携しやすい。
デメリット(注意点)
-
Node.js APIの非互換
Edge RuntimeではNode.jsのネイティブモジュールやファイルシステムが使えない。画像処理ライブラリ(Sharpなど)もNG。 -
Next.js新機能の一部制限
ISRの一部挙動やMiddlewareなど、Edge Runtime未対応の機能がある。アダプタのアップデート状況を追う必要あり。 -
無料プランのリクエスト上限
大量アクセス時に1日100kリクエストを突破すると、その日はWorkersが停止するリスクがある。 -
デバッグ手法の差異
ローカルNode.jsと同じ感覚ではデバッグできず、WranglerやCloudflareログでの確認が主体。 -
ベンダーロックインの可能性
@cloudflare/next-on-pages
やWorkers特有の実装に依存すると、他サービスへ移行時に修正コストが発生する。
7. まとめと今後の展望
Cloudflare WorkersとCloudflare Pagesは、Next.jsをはじめとするモダンフロントエンドフレームワークと組み合わせることで、グローバルCDNとエッジサーバレスの強みを最大限活かせるプラットフォームです。
特に無料プランでも十分なリソースを試せるため、個人プロジェクトから企業のPoCまで幅広く導入が進んでいます。将来的にはD1(Cloudflare独自のSQLデータベース)やAI機能の強化など、よりエッジネイティブなアプリケーション構築が当たり前になるでしょう。
今後のアップデートでNext.jsの新機能対応がさらに進めば、フロントエンドとバックエンドの垣根を感じさせない快適なエッジ開発体験が実現していくはずです。ぜひこの機会に、Edge Runtimeを活用したNext.jsアプリを試してみてください。
参考文献
- Main Differences Between Cloudflare Workers and Pages
- Cloudflare WorkersとCloudflare Pagesの違い | ithands
- Deploying Next.js 13 (app dir) to Cloudflare Pages | LogSnag
- Cloudflare Pagesがフルスタック
- Cloudflare Workersを使ってパスベースでリクエストをルーティングする #cloudflare - Qiita
- Pricing · Cloudflare Workers KV docs
- Cloudflare Pages
- And just like that, I was done with Netlify - Made Mistakes
- Limits · Cloudflare Pages docs
- Cloudflare Pages Goes Full Stack
- Supported features · Cloudflare Pages docs
- Implementing the “Cloudflare worker stack” - DEV Community