1. まず一文で区別する：Workers は「エッジでコードを実行する」、Pages は「サイトを公開する」
Cloudflare の製品を初めて見ると、少し戸惑う人も多いでしょう。Workers、Pages、R2、KV、D1、Queues……結局どれを使えばいいの？
まずは一番直感的な例えを覚えましょう。
- Workers はどちらかというと「Cloudflare の世界各所のノード上で動くプログラム」です。書くのは サーバー側のロジック、たとえば API、認証、転送、データ処理、A/B テスト、動的レンダリングなどです。
- Pages はどちらかというと「フロントエンドプロジェクトをワンクリックで Web サイトとしてデプロイする」ものです。静的サイト（HTML/CSS/JS）や、一部のフレームワークの SSR／エッジ関数機能（Pages Functions 経由）が得意です。
概念を覚えたくない場合は、こう考えることもできます。
- 「バックエンド」を作りたいなら、Workers が向いています。
- 「Web サイトを公開したい」なら、Pages が向いています。
もちろん、この2つは組み合わせて使うこともできます。多くのプロジェクトでは「フロントエンドは Pages、バックエンドは Workers」という構成もよくあります。
2. 共通点：なぜこの2つがよく一緒に語られるのか？
Workers と Pages がよく一緒に登場するのは、共通する基盤機能が大きくかぶっているからです。
- どちらも Cloudflare のグローバルエッジネットワーク上で動作する
- つまり、特定の固定サーバーにデプロイするのではなく、できるだけアクセス者に近い場所で動作します。
- その結果、通常はアクセスが速く、遅延が少なく、地域をまたいだ体験がより一貫します。
- どちらも Cloudflare のセキュリティ・ネットワーク機能に標準で接続される
- DDoS 防护、WAF（有効にしていれば）、Bot 管理、TLS 証明書、CDN キャッシュなど。
- 自分で Nginx を設定したり、証明書を購入したり、さまざまなセキュリティポリシーを用意する必要はありません。
- どちらも独自ドメインをバインドできる
- 例：
api.example.comを Workers に。 www.example.comを Pages に。
- 例：
- どちらも Cloudflare のストレージ／データベース機能と組み合わせて使える
- たとえば KV、D1、R2、Durable Objects、Queues。
- 実際のプロジェクトでは、「Workers だけ、または Pages だけ」ではなく、「Web サイト＋データ＋ロジック」の組み合わせになることがよくあります。
- どちらも Git 駆動の開発手法に対応している（特に Pages）
- Pages は基本的に「GitHub／GitLab と接続して、push したらデプロイ」です。
- Workers も
wranglerに GitHub Actions を組み合わせて継続的デプロイができます。
3. 核心的な違い：「プロダクトとしての位置づけ」が異なる
次に、より「実践的」な観点で違いを説明します。
3.1 デプロイするものが違う
- Workers：デプロイするのはコード（サーバー側プログラム）
- 公開するのは worker スクリプトです。
- それがリクエスト（HTTP）を受け取り、ロジックを処理し、レスポンスを返します。
- Pages：デプロイするのは Web サイトの成果物（静的リソース）
- 公開するのはビルド後のファイル、たとえば
index.html、assets/xxx.js、style.cssです。 - Pages はこれらのファイルをエッジノードに配信し、CDN のようにユーザーに近い場所から返します。
- 公開するのはビルド後のファイル、たとえば
3.2 「動的な能力」の由来が違う
- Workers の動的能力：そもそもリクエストを処理するコードを書くのが前提です。
- Pages の動的能力：主に Pages Functions に由来します。
- Pages プロジェクト内に関数を書いて、
/api/*や特定ルートを処理できます。 - ただし、その位置づけはあくまで「Web サイトが主体、関数は補助」です。
- Pages プロジェクト内に関数を書いて、
3.3 典型的なユースケースが違う
- Workers の方が適している
- APIゲートウェイ：統一認証、レート制限、ログ、カナリアリリース。
- BFF（フロントエンド向けバックエンド）：複数のバックエンドAPIを1つのAPIに集約する。
- 軽量バックエンド：フォーム送信、メール通知、Webhook処理。
- エッジコンピューティング：画像処理、テキスト処理、コンテンツ書き換え。
- リバースプロキシとリクエスト書き換え：リクエストをサードパーティサービスへ転送し、署名やヘッダー注入を行う。
- Pages の方が適している
- 企業公式サイト、製品ランディングページ。
- ドキュメントサイト（Docusaurus、VitePress、Next.js の静的エクスポートなど）。
- ブログ（Hugo、Hexo、Astro）。
- シングルページアプリケーション（React/Vue/Svelte）のデプロイ。
- プレビュー環境が必要なフロントエンドプロジェクト（各PRでプレビューリンクを自動生成）。
3.4 開発体験の違い
- Pages の体験は「ホスティングプラットフォーム」に近い
- Gitリポジトリと連携。
- 自動ビルド＆デプロイ。
- Preview環境（PRプレビュー）がある。
- フロントエンドチームのワークフローに適している。
- Workers の体験は「クラウド関数／サーバーレス」に近い
wranglerで初期化・開発・公開する。- ルーティング、リクエスト処理、環境変数のバインド、KV/D1/R2へのアクセスに注目する。
- バックエンド／フルスタックのワークフローに適している。
4.「タピオカ店を開く」例えで説明：いつ Workers を使い、いつ Pages を使うのか？
あなたはタピオカ店を経営していて、オンラインシステムを作る必要があるとしましょう。
- あなたには公式サイトが必要です。メニュー、店舗住所、キャンペーンポスターを表示します。
- また注文用APIも必要です。ユーザーが注文を送信し、決済コールバックを処理し、注文状況を照会します。
このとき：
- Pages = 店舗のショーウィンドウ
- メニュー画像、キャンペーンページ、紹介文。
- 大半のコンテンツは毎秒変わるわけではないため、静的ホスティングに非常に適しています。
- Workers = 店員とレジシステム
- 注文リクエストを受け取る。
- クーポンを検証する。
- 決済プラットフォームを呼び出す。
- 注文をデータベースに書き込む。
もちろん、Workers だけを使ってWebページを出力することもできます（Workers はHTMLを返せます）。しかし、それは「店員に手作業でショーウィンドウを飾ってもらう」ようなもので、できなくはないが割に合いません。
逆に、Pages Functions で一部の動的APIを実装することもできます。しかしビジネスロジックが複雑になるにつれて、結局バックエンドを書くことに近づいていくため、自然に Workers へ移行することになるでしょう。
5. Cloudflare 無料プランでできること（「まず始められるか」の視点で）
Cloudflare の無料プランは個人開発者、小規模チームのプロトタイプ、学習プロジェクトにとても親切です。次のように理解できます：
- 1つのWebサイトを公開するのに十分（Pages の無料枠は強力）。
- 軽量なAPIを書くのにも十分（Workers の無料枠で実行可能）。
通常、無料枠の範囲で以下のことができます：
5.1 Pages で無料でサイトを公開する
無料プランでは以下のことが可能です：
- GitHubリポジトリを連携し、pushで自動デプロイ。
- Previewプレビューリンクを生成（コラボレーションに非常に便利）。
- カスタムドメインを紐付け、自動HTTPS。
- 静的サイトのリソースをホスティング。
適した例：
- 個人ブログ。
- 製品紹介ページ。
- オープンソースプロジェクトのドキュメントサイト。
- フロントエンドのデモ。
5.2 Workers で無料で軽量APIを書く
無料プランでは以下のことができます：
- 1つの
GET /api/helloインターフェース。 - フォーム送信インターフェース：
POST /api/feedback。 - Webhookレシーバー（決済成功コールバックの受信など）。
- リバースプロキシ：リクエストを別のサービスに転送し、認証を行う。
さらに、KV、D1、R2 などの各製品の無料枠（各製品でポリシーは異なりますが、通常は無料枠があります）を組み合わせれば、実用的な「小規模バックエンド」を構築できます。
说明：免费套餐的具体额度会随 Cloudflare 调整而变化。选择前建议以 Cloudflare 官方页面的最新说明为准。
6. Workers と Pages の「共通点 vs 相違点」まとめ表
| 観点 | Workers | Pages |
|---|---|---|
| 位置付け | エッジでコードを実行（バックエンド/ロジック） | ウェブサイトのホスティングと公開（フロントエンド/静的リソース） |
| 主な成果物 | スクリプトとルート（リクエスト処理） | ビルド後のサイトファイル（HTML/CSS/JS） |
| 動的機能 | ネイティブで強力 | Pages Functions を通じて提供 |
| 典型的なワークフロー | wrangler での開発とデプロイ | Git と連携し、push でデプロイ、PR プレビュー |
| 向いている人 | バックエンド、フルスタック、プラットフォームエンジニア | フロントエンド、コンテンツ、プロダクト、グロース |
| 一般的な用途 | API、認証、集約、プロキシ、計算 | 公式サイト、ブログ、ドキュメント、SPA |
7. Workers の長所と短所（わかりやすく）
7.1 Workers の長所
- 「リクエストを好きなように処理できる」
- ヘッダーを読んだり、URLを変更したり、データベースを検索したり、署名検証を行ったりできます。
- 複雑なビジネスロジックに適しています。
- エッジでの実行により、速度と安定性に優れている
- 世界中のどこからでも、ユーザーは近くのエッジで処理を受けられます。
- 遅延に敏感なAPIに適しています。
- 「中間層」として非常に適している
- 複数のサービスを、フロントエンドに優しい1つのインターフェースに統合できます。
- 例えば、ユーザー情報、注文情報、レコメンド情報を1つのリクエストに集約できます。
- Cloudflare エコシステムと連携しやすい
- KV：設定、セッション、キャッシュ。
- D1：構造化データ。
- R2：オブジェクトストレージ。
- Durable Objects：強い一貫性や単一状態が必要なシーン。
7.2 Workers の短所
- 「バックエンド能力が強い」ということは、より多くのバックエンド設計作業を引き受ける必要がある
- 認証はどうする？
- エラーコードはどう定義する？
- データはどう保存する？
- ログはどう出力する？
- 従来の意味での「完全なサーバー」ではない
- ランタイム、制限、リクエスト処理モデルは、従来のNode/VMとは完全には同じではありません。
- ローカルファイルシステムや長時間接続に依存する一部のシナリオでは、考え方を変える必要があります。
- プロジェクト規模が大きくなると、より体系的なエンジニアリングが必要になる
- マルチ環境、カナリアリリース、監視、アラート、ロールバック。
- すべて実行可能ですが、あなた自身で規範を整備する必要があります。
8. Pages の長所と短所（わかりやすく）
8.1 Pages の長所
- ウェブサイトのデプロイがとても簡単
- リポジトリを接続する。
- ビルドコマンドを設定する。
- push するだけで本番公開される。
- 静的サイトのパフォーマンスが非常に良い
- 静的リソースは本質的にCDN配信に適しています。
- SEOや初回表示速度にも一般的に有利です。
- プレビュー環境はコラボレーションに強い
- 各PRごとにアクセス可能なプレビューリンクが生成されます。
- デザイン、プロダクト、テスト関係者は直接クリックして確認できます。
- 一般的なフロントエンドフレームワークに親しみやすい
- React/Vue/Svelte/Next/Astro などでも成熟したデプロイ方法が見つかります。
8.2 Pages の短所
- その核心はあくまで「ウェブサイトのホスティング」にある
- いったん「複雑なバックエンドが欲しい」というニーズになると、Pagesは主戦場ではなくなります。
- Pages Functionsでも可能ですが、軽量API向きです。
- 動的機能や状態管理の複雑さはすぐに増大する
- 例えば、ログイン、セッション、権限、注文などを実現しようとする場合。
- これらをすべてPages Functionsに詰め込むと、プロジェクト構造が不明瞭になります。
- 完全に動的なサイトでは、純粋な Workers に比べると自然ではない
- すべてのページをリアルタイムで組み立て、データAPIに強く依存する場合、Workersの方が使いやすいことが多いです。
9. Workers vs Pages：どう選ぶ？シンプルな判断方法
以下の質問に沿って自分でチェックできます。
9.1 主な成果物は「ウェブページファイル」ですか、それとも「APIロジック」ですか？
- 主にウェブページ：Pages を選択。
- 主にAPI：Workers を選択。
9.2 Git 駆動のプレビューとリリースのフローは必要ですか？
9.3 複雑な認証・レート制限・データ処理が必要ですか？
- 必要：どちらかといえば Workers を優先。
- 単純なフォームや簡単なAPIだけでよければ、Pages Functions と Workers のどちらでも構いません。
9.4 おすすめの組み合わせ（最も一般的で確実）
- Pages でフロントエンドをホスト + Workers で API を提供
- ドメイン例：
www.example.com→ Pagesapi.example.com→ Workers
- メリットは役割分担が明確なこと：
- Pages 专注“展示”。
- Workers 专注“逻辑”。
- ドメイン例：
10. 2つの小さい例：見ればすぐ分かる使い方
例A：個人ブログ + コメント送信
- ブログページ：Pages を使用
- Hugo/Hexo/VitePress でビルドしてそのまま公開。
- コメント送信API：Workers（または Pages Functions）を使用
POST /api/comment- パラメータを検証。
- D1 に書き込む。
- コメントIDを返す。
ブログのコンテンツは静的で Pages に向き、コメントは動的に書き込まれるため Workers に向く、ということが分かるでしょう。
例B：サードパーティAPIを「ラップ」して認証とキャッシュを実装
サードパーティの天気APIを呼び出す場合を想定します：
- サードパーティのAPIキーをフロントエンドに直接置きたくない。
- さらに、呼び出し回数を減らすためにキャッシュも行いたい。
こういうときは Workers が最適です：
- フロントエンドが自分のAPIエンドポイントにリクエスト：
GET /api/weather?city=shanghai - Workers がキャッシュ（KV）を確認。
- キャッシュがなければサードパーティサービスにリクエスト。
- 結果を KV に書き込み、有効期限を設定。
- フロントエンドに返す。
Pages でも「フロントページを置く」ことはできますが、この「中間層」のロジックは明らかに Workers の得意分野です。
11. 最後のアドバイス：まずは最もシンプルな組み合わせから始める
ゼロからプロジェクトを始めるなら、通常最も確実な進め方は次のとおりです：
- まずはサイトを Pages で動かす（最も速く公開でき、コストも最小）。
- API が必要になったら、Workers を追加。
- データ保存は要件に応じて KV、D1、R2 を選択。
この方法の利点は：
- 公開が速い。
- アーキテクチャが明確。
- その後の拡張性が高い。
コメント