1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【無料枠】Cloudflare × Next.jsエッジ開発:制限を理解して最大限活用する

Posted at

1. はじめに

本記事では、Next.jsを用いたエッジ実行による高速なWebアプリケーション開発に関心のあるエンジニアを対象に、Cloudflare WorkersCloudflare 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用にビルドできます。基本的なステップは以下のとおりです。

  1. パッケージをインストール
    npm install -D @cloudflare/next-on-pages
    
  2. Next.js設定ファイルでエッジ実行を有効化
    • App Router使用時には、ページやレイアウトごとに
      export const runtime = 'edge';
      
      の指定が必要です。
  3. ビルドコマンドに組み込む
    // package.json (例)
    {
      "scripts": {
        "build": "next build",
        "pages:build": "npx @cloudflare/next-on-pages"
      }
    }
    
  4. Cloudflare Pagesのビルド設定で上記コマンドを実行
    • 「Build command」にnpm run build && npm run pages:buildのように設定し、ビルド後にエッジで動作可能な成果物を生成します。

導入手順と設定の注意点

  • Edge RuntimeではNode.js特有のモジュール(fsやnetなど)が使えないので注意が必要です。
  • 大規模アプリの場合はビルド時間が長くなることがあるため、Pagesのビルド回数制限(後述)に留意しながらCI/CDを計画しましょう。
  • デプロイ後はyour-project.pages.devでSSRやAPIルートがすぐに利用できます。カスタムドメインの設定も可能です。

4. 無料プランのリソース上限と制限

Cloudflareの無料プランは非常に寛大ですが、以下のようにWorkersPagesでそれぞれ制限があります。用途やアクセス規模によっては有料プランへの移行を検討してください。

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. メリット・デメリットの考察

メリット

  1. グローバルな低レイテンシ
    Cloudflareのエッジネットワークにより、世界中のユーザーに対して一貫して高速なレスポンスを実現。
  2. 無料プランが充実&スケーラブル
    100,000リクエスト/日までのWorkers枠や無制限帯域のPagesなど、開発初期のコストを抑えつつ、スケール時には有料プランで強化可能。
  3. エッジ実行による高速SSR
    Next.jsのSSRもエッジ上で完結し、コールドスタートも小さいため、動的ページでも体感速度が高い。
  4. 運用がシンプル
    GitにプッシュするだけでCI/CDが自動化され、カスタムドメインやSSLも無料。複数環境のプレビュー生成も容易。
  5. Cloudflareエコシステムとの統合
    KV、R2、D1などのサーバレスストレージや、Queue、AI機能などとも連携しやすい。

デメリット(注意点)

  1. Node.js APIの非互換
    Edge RuntimeではNode.jsのネイティブモジュールやファイルシステムが使えない。画像処理ライブラリ(Sharpなど)もNG。
  2. Next.js新機能の一部制限
    ISRの一部挙動やMiddlewareなど、Edge Runtime未対応の機能がある。アダプタのアップデート状況を追う必要あり。
  3. 無料プランのリクエスト上限
    大量アクセス時に1日100kリクエストを突破すると、その日はWorkersが停止するリスクがある。
  4. デバッグ手法の差異
    ローカルNode.jsと同じ感覚ではデバッグできず、WranglerやCloudflareログでの確認が主体。
  5. ベンダーロックインの可能性
    @cloudflare/next-on-pagesやWorkers特有の実装に依存すると、他サービスへ移行時に修正コストが発生する。

7. まとめと今後の展望

Cloudflare WorkersCloudflare Pagesは、Next.jsをはじめとするモダンフロントエンドフレームワークと組み合わせることで、グローバルCDNとエッジサーバレスの強みを最大限活かせるプラットフォームです。
特に無料プランでも十分なリソースを試せるため、個人プロジェクトから企業のPoCまで幅広く導入が進んでいます。将来的にはD1(Cloudflare独自のSQLデータベース)やAI機能の強化など、よりエッジネイティブなアプリケーション構築が当たり前になるでしょう。
今後のアップデートでNext.jsの新機能対応がさらに進めば、フロントエンドとバックエンドの垣根を感じさせない快適なエッジ開発体験が実現していくはずです。ぜひこの機会に、Edge Runtimeを活用したNext.jsアプリを試してみてください。


参考文献

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?