Cloudflare WorkersとPagesの違い｜Webサイト・API・フルスタック開発の選び方
CloudflareでWebサイトやアプリを公開するとき、WorkersとPagesのどちらを使うか迷いやすくなっています。Pagesは静的サイトとGit連携の印象が強く、WorkersはAPIやエッジ処理の印象がありますが、現在はWorkersでも静的アセットを扱え、PagesでもFunctionsでサーバー処理を追加できます。
判断では製品名だけでなく、アプリケーションの中心が静的フロントエンドかサーバー処理か、どのフレームワークを使うか、Preview・権限・ログ・ロールバックをどう運用するかを確認します。
静的フロントエンドとGitベースのPreviewを中心に始めるならPages、API・認証・バックグラウンド処理・複数バインディングを中心に構成するならWorkersが分かりやすい選択です。新規開発ではWorkers Static Assetsも比較対象にします。
本記事のポイント
- WorkersはAPIやサーバー処理を中心に静的アセットも同じプロジェクトで配信できます。
- PagesはフロントエンドのGit連携とPreview運用を始めやすく、Pages Functionsで動的処理を追加できます。
- 新規案件ではフレームワーク対応だけでなく、デプロイ権限、環境変数、ログ、ロールバック、バインディングで選びます。
この記事で分かること
| 確認対象 | 見る内容 | 判断のポイント |
|---|---|---|
| 主な入口 | Pages: Git/直接アップロード | Workers: Wrangler/API/Git連携 |
| 静的配信 | Pagesの基本機能 | Workers Static Assetsで同梱可能 |
| 動的処理 | Pages Functions | Workerハンドラー、Cron、Queues等 |
| データ接続 | Functionsからバインディング | Workersのバインディングを中心に設計 |
| 向く案件 | フロントエンド中心 | API・フルスタック・処理中心 |
Pagesが向く構成
マーケティングサイト、ドキュメント、静的生成サイトなど、フロントエンド成果物をGitのブランチごとにPreviewし、本番へ反映したい構成に向きます。ビルドコマンド、出力ディレクトリ、環境変数を設定しやすく、制作チームと開発チームのレビュー導線を作れます。
動的処理が必要な場合はPages Functionsを追加できます。ただし、Functionsやバインディングが増え、アプリケーションの中心がサーバー処理へ移るなら、Workersとして管理した方が構成を理解しやすい場合があります。
Workersが向く構成
API、認証、リダイレクト、リクエスト変換、Webhook、定期処理、AI推論、データ接続など、サーバー側のロジックが中心の構成に向きます。静的アセットを同じWorkerへ含めれば、フロントエンドとAPIを一つのデプロイ単位にできます。
R2、D1、KV、Durable Objects、Queuesなどのバインディングを使う場合も、Workerの設定とコードから関係を追いやすくなります。処理時間、互換性、依存パッケージ、外部通信の要件を事前に確認します。
Workers Static AssetsとPagesを比較する
Workers Static Assetsは、静的ファイルを効率的に配信しながら、必要なパスだけWorkerコードへルーティングする構成を作れます。APIとフロントエンドを同じリポジトリ・設定で扱いたい場合に有力です。
Pagesの既存運用が安定している場合、機能が重なっただけで移行する必要はありません。Preview URL、ビルド時間、環境変数、独自ドメイン、デプロイ履歴、ロールバックの運用価値を比較します。
フレームワーク互換性と実行環境を確認する
Node.jsサーバーを前提とするフレームワークやライブラリが、そのままWorkers実行環境で動くとは限りません。公式アダプター、互換性フラグ、Web標準APIへの対応、動的レンダリング方式を確認します。
ローカルではWranglerなど本番に近い開発環境を使い、環境変数と秘密情報を分離します。本番だけで発生するバインディング不足やルーティング差を減らすため、Previewでも同じ構成を検証します。
運用・権限・監視で最終決定する
誰が本番デプロイできるか、ブランチと環境をどう対応させるか、失敗時にどの版へ戻すかを決めます。自動デプロイは速い一方、承認なしに本番へ進む設定では事故が広がります。
ログ、エラー、リクエスト数、外部API失敗、データ操作を観測し、アプリケーションとプラットフォームの責任範囲を分けます。公開後まで内製する全体像は、Webサイト制作を内製化する手順も参考になります。
本番導入で必要な変更管理と評価方法
Cloudflareの設定は通信経路の手前で効くため、小さな変更でも複数ページや外部連携へ影響します。開発・検証環境で再現できるものは先に試し、本番では対象ホスト、パス、利用者、時間帯を限定して段階反映します。変更票には目的、変更前後、実施者、承認者、確認URL、期待結果、切り戻し条件を残します。
確認は「画面が開くか」だけで終えません。HTTPステータス、レスポンスヘッダー、認証、フォームやAPIの完了、オリジンログ、Cloudflareイベントを同じ時刻で照合します。正常系だけでなく、権限なし、期限切れ、過剰アクセス、外部API停止、再送などの異常系も試し、利用者へ返すエラーと運用担当者が見る証拠を分けます。
導入効果は、表示速度やブロック件数など一つの数値だけで評価しません。可用性、正常完了率、オリジン負荷、エラー率、誤検知、サポート問い合わせ、変更作業時間、月額・従量費を導入前後で比較します。性能が上がっても問い合わせやログインの失敗が増えていれば、事業成果としては改善していません。
料金と上限は利用プランや使用量で変わります。無料枠や小規模検証の結果をそのまま本番へ外挿せず、ピーク時のリクエスト、保存・操作、ログ量、利用者数、サポート、監査要件を公式料金ページと契約条件で確認します。上限へ近づいたときの通知と、機能を縮退させる順序も決めます。
設定の所有者と定期レビュー日を決め、不要なルール、トークン、例外、接続先を残しません。Cloudflare画面だけでなく、設定のエクスポート、コード、変更履歴、復旧手順をチームで参照できる場所へ保管します。担当者の退職や委託先変更があっても、誰が承認し、どこまで戻せるか分かる状態を維持します。
公開後は一週間程度の観測期間を設け、導入前と同じ時間帯・同じURL・同じ業務操作で比較します。異常がなくても、例外が増え続けていないか、想定外の回避策が現場で使われていないかを確認します。問題が見つかった場合は、影響を受けた利用者とデータを特定し、暫定回避と恒久修正を分けて記録します。
また、Cloudflare以外の構成要素を含む依存関係図を残します。DNS、レジストラ、オリジン、IdP、メール、外部API、監視、CI/CDのどこで設定が重複し、どこが単一障害点になるかを明示します。障害時に別サービスの担当者へ連絡すべき条件も決めておくと、Cloudflare側だけを調べ続ける時間を減らせます。
本番の設定変更は、可能ならAPIやInfrastructure as Codeで再現可能にし、画面で行った緊急変更も後から正本へ戻します。秘密情報は設定ファイルへ直接書かず、環境ごとのSecret管理へ分離します。手作業とコードの状態がずれると、次回デプロイで緊急修正が消えるため、復旧後の同期までをインシデント対応に含めます。
公開・変更前チェックリスト
- 静的配信とサーバー処理の比重を整理した
- 利用フレームワークの公式対応を確認した
- Preview・本番・ロールバックの運用を比較した
- 必要なR2・D1・KV等のバインディングを列挙した
- 環境変数と秘密情報を分離した
- ログ・エラー・外部APIを監視できる
- 既存Pagesから移行する実益を確認した
よくある質問
Pagesは廃止されますか？
この記事では廃止を前提にしません。公式の現行機能と自社の運用要件を確認し、既存Pagesを理由なく移行しないことが重要です。
Workersだけで静的サイトを配信できますか？
Workers Static Assetsを使って静的ファイルを配信できます。動的処理と同じプロジェクトへまとめる構成も可能です。
Pages FunctionsはWorkersと同じですか？
Workersランタイムを利用しますが、プロジェクト構造やデプロイ体験はPagesのモデルに沿います。設定と対応機能を確認します。
Vercelから移行すべきですか？
一律ではありません。フレームワーク統合、Preview、分析、実行環境、データ転送、運用負荷を比較し、移行効果がある場合に検討します。
関連ページと関連記事
仕様確認に使った公式情報
Cloudflareの機能、プラン、上限、画面構成は更新されます。実装時は利用する機能の最新公式ドキュメントも確認してください。
まとめ
WorkersとPagesを、実行モデル、静的配信、Git連携、API、フルスタック構成、運用方法で比較する開発者向けガイドです。 設定を有効にしただけで完了とせず、正常系・異常系・切り戻しを同じ手順で確認することが、安全な運用につながります。
