Cloudflare Workers と Pages — 関係の整理とどちらを使うか

WVP CloudflareWorkersCloudflarePages

Cloudflare で Web サイト・Web アプリを公開する受け皿には Cloudflare Pages と Cloudflare Workers の2つがある。本サイトのハンズオンは Pages を主軸にしているが、Cloudflare 公式は新規開発の主軸を Workers に移しつつある。本記事では両者の関係と違い、どちらを使うかの判断材料を整理する（2026年6月時点）。

1. 結論

本サイトのハンズオンは当面 Pages を主軸にする。個人・初学者が「公開できた」に最短で到達でき、設定の説明が軽いため
一方、Cloudflare 公式は新規プロジェクトでは Workers を推している。今後の新機能投資は Workers に集中する
Pages が廃止されるわけではない。継続サポートが明言されており、強制移行の期限も発表されていない（2026年6月時点）

つまり「いま Pages で学ぶことが無駄になる」心配は不要。Pages Functions の実体は Workers そのものなので（→ 3章）、Pages で覚えた概念はほぼそのまま Workers に持ち越せる。

2. 公式の方向性

2024〜2025年にかけて、Cloudflare の方針が大きく動いた。

公式ブログ Your frontend, backend, and database — now in one Cloudflare Worker で、新規のフルスタック開発は Workers で、というメッセージが示された
公式ブログ Pages and Workers are converging into one experience で、Pages と Workers を1つの体験に統合していくこと、今後の投資は Workers 側に集中することが表明された
きっかけは Workers Static Assets（→ 3章）。これにより「静的サイトの配信は Pages でないとできない」という理由がなくなった

ただし同時に、Pages の継続サポートも明言されている。公式の Pages → Workers 移行ガイドにも移行期限のような記述はなく、既存の Pages プロジェクトを急いで移す必要はない。

移行ガイドには、コーディングAI向けの移行用プロンプト（実験的）も用意されている。Claude Code に渡して「このPagesプロジェクトをWorkersに移行して」と頼む使い方が想定されており、いかにも今どきのアプローチ。

3. 役割の分担と重なり — Workers Static Assets

もともと両者は役割が分かれていた。

Pages: 静的サイトのホスティング。Git 連携でデプロイし、pages.dev の URL が発行される。サーバー側の処理が必要なら Pages Functions を足す
Workers: Cloudflare のネットワーク上で動くサーバー側のコード。API やリダイレクトなどのロジック担当

ここに Workers Static Assets が登場し、Workers でも HTML/CSS/画像などの静的ファイルを一緒にアップロードして配信できるようになった。wrangler.jsonc に公開フォルダを指定するだけ：

{
  "name": "my-site",
  "compatibility_date": "2026-06-01",
  "assets": {
    "directory": "./public"
  }
}

重要な挙動として、リクエストが静的ファイルに一致する場合は Worker のコードを起動せずにファイルを返す。静的アセットへのリクエストは無料・無制限なので、静的サイト部分の配信コストは Pages と同じ感覚で済む。

逆方向の対応も整理されている。Pages Functions は実体が Workers なので、両者の構成要素はほぼ1対1に対応する：

Pages	Workers
静的ファイルのホスティング	Workers Static Assets
`functions/` ディレクトリ（ファイルベースルーティング）	Worker の `fetch` ハンドラ＋ルーティング
Pages の Git 連携	Workers Builds
プレビューデプロイ	Workers の Preview URLs

こうして機能が重なった結果、「2つを別製品として維持する理由が薄れた」のが統合方針の背景。

4. 実用面の違い

機能は重なったが、使い勝手の細部には差が残っている（2026年6月時点）。

観点	Pages	Workers
URL	プロジェクトごとに `<プロジェクト名>.pages.dev`	アカウント共通の親の下に `<Worker名>.<アカウント名>.workers.dev`
プレビュー	push ごとに `<ハッシュ>.<プロジェクト名>.pages.dev` を自動発行	Preview URLs はあるが制約あり（ログ不可など）
独自ドメイン	サブドメインなら外部DNSのまま CNAME で設定可	Cloudflare でネームサーバ管理しているドメインのみ
無料枠（ビルド）	月500ビルド	Workers Builds は月3,000ビルド分（分単位で計測）
静的配信	無料・無制限	無料・無制限（Worker を起動しない）
バックエンド	Pages Functions（`functions/` に置くだけ）	Worker 本体に書く（自由度が高い）
使える機能	Workers の一部機能は使えない	Durable Objects・Cron・Queues など全機能
新機能	来ない（継続サポートのみ）	公式が投資する側

特に効いてくる差が2つ。

URL 体系: Pages はプロジェクト名がそのまま pages.dev のサブドメインになり、URL が簡潔。Workers はアカウント単位のサブドメインが親に入るため URL が長くなり、公式も本番運用では workers.dev ではなく独自ドメインを推奨している。つまり Workers できれいな URL にするなら独自ドメインが前提になりやすい。

外部 DNS: ドメインを Cloudflare 以外の DNS で管理している場合、Pages はサブドメインの CNAME だけで独自ドメインを張れるが、Workers は Cloudflare のネームサーバ管理が必須。DNS を移したくない事情があるなら Pages が柔軟。独自ドメインの具体的な設定手順は独自ドメインを設定するを参照。

5. 使い分けの指針

静的サイトを手軽に公開したい・URL は pages.dev で十分 → Pages。プロジェクト作成から公開までが一番軽く、プレビューも自動で付く
静的サイト＋軽い API（データ共有型Webアプリ）→ どちらでも組める。Pages なら functions/＋D1（本サイトのロードマップ構成）、Workers なら Static Assets＋Worker。新規で長く育てるなら Workers が公式の本流
Cron 実行・Durable Objects・Queues など Workers 固有の機能を使いたい → Workers 一択
すでに Pages で動いているもの → そのままでよい。困っていないなら移行の必要はない

デプロイの自動化（Git 連携 vs GitHub Actions）という別軸の選択については CDM を参照。Pages の Git 連携に相当する Workers 側の機能が Workers Builds で、構図は同じ。

6. 本サイトのハンズオンとの対応

本サイトのロードマップ（SUP → WRG → CGT → D1G）は Pages ラインで構成している。理由は1章のとおり、初学者が最短で「公開できた」に到達できるため。

静的サイト公開: SUP（ブラウザアップロード）、CGT（Git連携）
データ共有型（Pages Functions + D1）: D1G

Workers ラインのハンズオンは、Workers Static Assets ベースのものを別途展開していく予定。

7. もっと詳しく

Pages and Workers are converging into one experience — 統合方針の公式アナウンス
Migrate from Pages to Workers — 移行ガイドと機能対応表
Workers Static Assets — 静的アセット配信の公式ドキュメント

2026-06-10 (last updated: 2026-06-17) タツヲ (yto)

☕️ Vibecoding Notes を応援