Cloudflare PagesとWorkersの違い：構成を選ぶための判断表

Cloudflareの環境は「エッジ（Edge）」と呼ばれる、ユーザーから物理的に最も近いサーバー群で構成されています（参考：エッジコンピューティングとサーバーレスアーキテクチャの違い）。

• Pages：Gitリポジトリ（GitHubなどソースコードを管理する場所）と連携し、プッシュするだけで自動的に静的サイト（HTML/CSS/JS/画像）をビルドし、世界中に高速配信します。料理で例えるなら「すでに完成しているお弁当を素早く提供するショーケース」です。
• Workers：エッジ上でJavaScriptやTypeScriptなどのコードを実行します（リクエスト→処理→レスポンス）。データベース（DB）への保存や外部APIの呼び出しなど、プログラムを使った処理が行えます。料理で例えるなら「注文が入ってからその場で調理するキッチン」です。

つまり、誰が見ても同じ内容で良い「静的」な部分はPages、ユーザーの操作に応じて中身が変わる「動的」な部分はWorkersと考えるとスムーズです。

これらを踏まえ、よくある構成パターンは以下の3つに大別されます。

多くの中小企業・成長企業において、まずはPagesから始め、必要に応じてWorkersを足していくアプローチが最も失敗が少なくおすすめです。

① Pagesだけで十分（会社HP/LP/ブログ）

静的な情報提供がメインのサイトであれば、Pagesの基本機能だけで完結します。Next.jsのStatic Exportsなどを用いた中小企業が決断すべき「モダンWeb開発」への移行の基盤としても最適です。

② Workersだけが必要（API/BFF/認証ゲート）

画面を持たず、裏側のデータ処理だけを行いたい場合です。スマートフォンのアプリ用APIや、複数のシステムを繋ぐための中継サーバー（BFF：Backends For Frontends）などに適しています。

③ Pages + Workers （Webサイト＋動的機能の統合構成）

ページ本体を静的に配信し、フォーム送信など必要な処理だけをWorkersへ分ける構成です。動的処理の範囲を限定できる一方、配信とAPIの監視先が分かれるため、障害時の担当を決めておきます。

どちらのサービスが自社の要件に合うのか、以下の表で整理します。

自社のWebプロジェクトでどちらを使うべきか、以下の質問に答えていくだけで判断できます。

例1: 会社HP ＋ お問い合わせフォーム

最も王道となる構成です。会社のページ自体はPagesで静的に高速配信し、ユーザーがフォームの「送信」ボタンを押した際のリクエストのみWorkersが受け取ります。Workers内では自動化防止ツール（Turnstile）でスパムを弾き、メール配信サービス（Resendなど）を呼び出して担当者に通知します。

例2: 会員制ページ

社内向けポータルや会員限定のページを作るケースです。Pagesで作成したサイトの前にWorkersを立たせ、「ログインしているか？」を判定する簡易認証（Basic認証やJWT検証）を行い、未ログインならログイン画面へリダイレクトさせます。

例3: APIゲートウェイ（BFF）

モバイルアプリや別のWebシステムがデータを取得する際の中継役としてWorkersを置くケースです。バックエンドにある古いシステム（レガシーなDBやAPI）からデータを集め、スマートフォン向けに整形して返すBFF（Backends For Frontends）として機能します。

例4: 画像最適化やキャッシュ制御

Webサイトの表示速度をさらに上げる工夫です。Pagesで配信しているコンテンツに対して、Workersを仲介させることで「より効率的なキャッシュルールの適用」や「HTTPレスポンスヘッダの書き換えによるセキュリティ強化」を柔軟に行えます。

ユースケース別の推奨構成

Cloudflareの料金体系は非常に寛大ですが、それぞれの「課金ポイント」を理解しておくことが重要です。

• Pagesのコスト構造：
  ビルド、同時実行、付帯機能など、利用する機能ごとに上限を確認します。配信だけでなく、画像最適化やログなどの周辺機能も見積もりへ含めます。
• Workersのコスト構造：
  リクエスト数とCPU時間に加え、KVやD1など付帯サービスの読み書き・保存量も確認します。無料枠を前提に固定せず、通常時とアクセス増加時の両方を試算します。

事前の設計次第で防げる、典型的な失敗例を挙げます。

• SSR前提で設計し、Pagesの用途と合わない：Pagesは静的配信を中心とするサービスです。SSRの実行環境や対応機能を確認せずに設計すると、追加の設定や構成変更が必要になります。
• Workersに何でも詰め込み、責務が爆発する：ひとつのWorkersの中に、ルーティング、認証、データベース処理、メール送信などをすべてベタ書きすると、後から誰も保守できなくなります。小さなモジュールに分割する設計力が問われます。
• 環境変数 / Secrets管理の不備による情報漏洩：APIキーなどの秘匿情報をソースコードに直書きしないようにします。Cloudflareの「Secrets」機能を使い、本番環境とプレビュー環境で認証情報を分けます。
• CORS・キャッシュ・リダイレクトで混乱する：「Pages単体」「Pages + Workers」の境界線でキャッシュが効きすぎたり、ドメイン間通信（CORS）でエラーが出たりするトラブルが頻発します。ネットワークの基礎知識が求められます。
• 監視・ログ・エラー対応が後回しになる：サーバーレスの宿命ですが、「サーバーが落ちない（プロバイダ側で管理される）」ことに甘え、プログラム自身のエラー（バグ）を検知する仕組みを忘れると、ユーザーからのクレームで初めて障害に気づくことになります。

プロジェクトを開始する前の確認項目としてご活用ください。