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

「Pagesは静的、Workersは動的」だけでは、現在の使い分けを説明できません。両方ともCloudflareのネットワークから静的ファイルを配信できます。

• Pages：Git連携やビルド済みファイルのアップロードでHTML・CSS・画像などを公開します。
• Pages Functions：Pagesにフォーム送信、認証、ミドルウェアなどを追加する仕組みです。Workersの実行環境を利用します。
• Workers + Static Assets：静的ファイルと必要なAPI処理を同じプロジェクトで公開できます。静的配信だけならWorkerコードは不要です。

Workers Static Assetsでは、既定の設定のままだと、ファイルに一致するリクエストはコードを実行せずに配信されます。認証などを配信の前に実行する場合は、ルーティングの設定が必要です（確認日：2026年10月）。Static Assets公式資料とPages Functions公式資料で対応範囲を確認できます。

先に新規構築か、既存Pagesの継続運用かを分けると、不要な移行を避けられます。

Cloudflare公式のPages概要は、新規プロジェクトにWorkersを推奨しています（確認日：2026年10月）。この記事では、これを新しく設計するときの判断材料として扱い、既存サイトをすぐに移行する理由にはしません。

① 新規サイト：静的配信とAPIをまとめる

Workers Static Assetsで会社HP・LP・ブログを配信し、必要なAPIだけをコードで実装します。静的生成とサーバー側処理の違いはモダンWeb開発の判断基準も参考になります。

② 既存Pages：継続か、機能追加かを判断する

フォームなどは、Pages Functionsで追加することも、別のWorkerに分けることもできます。移行が必要な機能、設定の差分、検証と保守の費用を比べます。費用と更新方法、WordPressを残す判断は中小企業サイトの運用コストとCloudflare Pagesの選び方で整理しています。

③ APIのみ：Workersで処理を提供する

画面を持たないAPIや、複数のシステムからデータを集めるBFF（画面向けの中継API）を構築する場合です。公開範囲、認証、接続先、エラー時の担当を決めます。

静的配信はどちらでもできるため、機能の追加方法と運用の単位で比較します（確認日：2026年10月）。

表は横にスクロールできます →

まず新規か既存かを確認します。静的配信の有無だけでは構成を決められないためです。

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

新規ならWorkers Static Assetsでページを配信し、フォーム送信先をWorkerコードで実装する構成を検討できます。既存PagesならPages Functionsや別のWorkerを使えます。どの構成でも、Turnstileなどによる検証、入力のチェック、メール配信サービスとの連携、送信の失敗の記録をサーバー側で実装します。

例2: 会員制ページ

認証が必要なファイルは、配信の前に認証と権限のチェックを通す設計にします。Workers Static Assetsは既定ではアセットを先に配信するため、保護するルートでコードを先に実行する設定などを確認します。ログイン画面への転送だけでなく、未認証のファイル直アクセスも検証します。

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

モバイルアプリや別のWebシステムがデータを取得するときの中継役として、Workersを置く場合です。裏側にある古いシステム（以前から使っているDBやAPI）からデータを集め、スマートフォン向けに整えて返す中継のAPI（BFF）として使います。

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

静的配信の設定と、画像の変換や独自のキャッシュ処理は分けて考えます。標準の設定で足りるか、Workerのコードや画像サービスが必要かを確認し、追加した処理の費用と監視の手間も見積もります。

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

表は横にスクロールできます →

静的ファイルの配信と、コードが実行されるリクエストを分けて見積もります（確認日：2026年10月）。

• 静的配信：PagesとWorkers Static Assetsの静的アセットへのリクエストは無料です。ただし、配信前にWorkerコードを実行する設定なら、コード実行側のリクエストとして扱われます。ファイル数・サイズ、ビルドなどの上限は別に確認します。
• 動的処理と付帯サービス：WorkerのコードやPages Functionsの実行、DB・ストレージ、メール配信、監視などの費用を確認します。Workersではリクエスト数とCPU時間を分け、通常時とアクセス増加時を試算します。

表は横にスクロールできます →

事前に設計しておけば防げる、よくある失敗の例を挙げます。

• フレームワークの実行環境を確認しない：静的エクスポートとSSR（リクエストごとの描画）は分けて考えます。Next.jsの静的エクスポートはPagesで配信できますが、フルスタックで使う場合は、Workers向けの公式ガイドと、使う機能の対応状況を確認します。
• Workersに何でも詰め込み、役割が膨らむ：一つのWorkerの中に、ルーティング、認証、データベースの処理、メール送信などをすべて直接書き込むと、後から直すときに影響の範囲が分かりにくくなり、保守が難しくなります。処理を役割ごとの小さなモジュールに分けて設計します。
• 環境変数 / Secretsの管理の不備による情報漏えい：APIキーなどの秘密の情報は、ソースコードに直接書かないようにします。CloudflareのSecretsの機能を使い、本番環境とプレビュー環境で認証情報を分けます。
• ルーティング・キャッシュを確認しない：アセットとAPIの経路、404やSPAへのフォールバック、別ドメインのAPIのCORSを検証します。移行するときは、PagesとWorkersの設定の差分も確認します。
• 監視・ログ・エラー対応が後回しになる：サーバーレスで起こりやすい失敗です。サーバーの稼働はサービス提供者が管理しますが、プログラム自身のエラー（バグ）を検知する仕組みは自社で用意する必要があります。用意していないと、利用者からの問い合わせで初めて障害に気づくことになります。

プロジェクトを始める前に確認する項目です。