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サイト＋動的機能の統合構成）

静的サイトの圧倒的な表示速度を保ちつつ、一部分だけ動かすパターンです。たとえば会社HP（Pages）の中で、「お問い合わせフォームの送信処理」だけをWorkersで受け持つ構成が今の主流です。

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

自社の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のコスト構造：
  「無料プラン」の枠が非常に大きく、一般的な中小企業の会社HPやブログであれば、事実上ずっと無料で運用できるケースがほとんどです。帯域幅（データ転送量）による直接的な課金がないのも大きな強みです。
• Workersのコスト構造：
  「リクエスト数（何回実行されたか）」と「実行時間（CPUをどれだけ使ったか）」が主な課金ポイントになります。こちらも無料枠（1日10万リクエスト）が大きいため、月間数十万PV程度のサイトの裏側で動かす分には無料枠に収まることが多いです。ただし、KVS（キーバリューストアなどの簡易データベース）など付帯サービスを多用すると費用が発生しやすくなります。

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

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

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