コンテンツにスキップ
Vibecoding Notes Vibecoding Notes

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

WVP CloudflareWorkersCloudflarePagesWorkersStaticAssets

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

1. 結論

Section titled “1. 結論”
  • 本サイトのハンズオンは Pages を主軸にする。初学者が最短で「公開できた」に到達でき、手順が少なくてすむこと、そしてシンプルなLPなど多くの用途にはこれで必要十分なため
  • 一方、Cloudflare 公式は新規プロジェクトでは Workers を推している。今後の新機能投資は Workers に集中する
  • Pages が廃止されるわけではない。継続サポートが明言されており、強制移行の期限も発表されていない
  • 🚨 ただし 2026年9月から、Wrangler で新しく作ると Workers になる（→ 5章）。本サイトは ブラウザで作る → Pages、Wrangler から新しく作る → Workers という切り分けにした

これはハンズオン（教材）としての方針であって、サイトのあらゆる部分を Pages に縛るものではない。ハンズオン以外（込み入ったアプリや、Workers 固有の機能が要る場面）では Workers を使うこともある。要は「初心者が最初に学ぶ受け皿として Pages が軽い」という話で、Pages と Workers のどちらが上という話ではない。

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

2. 公式の方向性

Section titled “2. 公式の方向性”

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

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

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

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

Section titled “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に対応する：

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

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

4. 実用面の違い

Section titled “4. 実用面の違い”

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

観点PagesWorkers
URLプロジェクトごとに <プロジェクト名>.pages.devアカウント共通の親の下に <Worker名>.<アカウント名>.workers.dev
プレビューpush ごとに <ハッシュ>.<プロジェクト名>.pages.dev を自動発行Preview URLs はあるが制約あり（ログ不可など）
ブラウザからのアップロード更新できる（Direct Upload）できる（Deployments → New deployment）。ただし HTML・CSS・JS だけ
過去のデプロイに戻すダッシュボードからダッシュボードのほか wrangler rollback でも。直近100バージョンまで
全リクエストへの割り込みfunctions/_middleware.js をルート直下に置けば既定で割り込む🚨 run_worker_first の指定が要る（→ 3章）
独自ドメインサブドメインなら外部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. Wrangler で新しく作ると Workers になる

Section titled “5. Wrangler で新しく作ると Workers になる”

🚨 2026年9月から、Wrangler で新しいプロジェクトを作ると Pages ではなく Workers になる。 「Cloudflare Pages に公開して」と頼んでも、*.workers.dev の Worker ができる。

$ npx wrangler pages deploy ./public --project-name=my-site
Delegating to the latest version of Cloudflare Pages, now part of Cloudflare Workers

AI エージェントが実行したときだけ起きる。 人が同じコマンドを手で打っても Pages のまま。判定は Wrangler が内部で持っているので、プロンプトの書き方では避けられない。

条件は次の全部がそろったときだけ（Wrangler の PR #14312 に列挙されている）。

  • AI エージェントが実行している
  • --force が付いていない
  • 対象の Pages プロジェクトがまだ無い
  • functions/ _worker.js _redirects _headers _routes.json のどれも無い
  • pages deploy に --branch が付いていない

Wrangler 4.108.0（2026年7月）で入り、4.130.0（2026年9月8日）で対象が広がった。 当初は Pages を1つも持たないアカウント限定だったのが、既に Pages を使っているアカウントでも、新しいプロジェクトなら委譲されるようになった。

⚠️ まだ実験的な機能で、公式ドキュメントには載っていない（一次情報は Wrangler の CHANGELOG と PR）。オプトアウトの --force も未掲載で、フラグ名を変える提案が未マージのまま出ている。手順書に --force を書くと、いずれ動かなくなる。

どうするか

Section titled “どうするか”
したいことやり方
Pages のまま新しく作るブラウザのダッシュボードで作る（→ SUP）。作ったあとは Wrangler からそのまま更新できる
Workers で作るそのまま Wrangler に任せる（→ WRG の補足）
既存の Pages を更新するこれまでどおり。委譲は起きない

本サイトはこの切り分けにしている：ブラウザで作る → Pages、Wrangler から新しく作る → Workers、既存 Pages の更新 → Pages のまま。

Cloudflare Pages が非推奨になったわけではない（公式の非推奨一覧に Pages 製品の記載はない）。ただし Pages の公式ドキュメントの冒頭には「Start new projects with Workers.」と書かれている。

6. 使い分けの指針

Section titled “6. 使い分けの指針”
  • 静的サイトを手軽に公開したい・URL は pages.dev で十分 → Pages。ただしプロジェクトはブラウザで作る（→ 5章）。作ったあとは Wrangler から更新できる
  • Wrangler だけで作成から公開まで済ませたい → Workers。URL は長くなるが、プロジェクト作成の手順が要らない
  • 静的サイト＋軽い API（データ共有型Webアプリ）→ どちらでも組める。Pages なら functions/＋D1（本サイトのロードマップ構成）、Workers なら Static Assets＋Worker。新規で長く育てるなら Workers が公式の本流
  • サイト全体に認証などの割り込みをかけたい → Pages のほうが素直。functions/_middleware.js を置くだけで済む（Workers は run_worker_first の指定が要り、忘れると無言で素通りする。→ 3章）
  • Cron 実行・Durable Objects・Queues など Workers 固有の機能を使いたい → Workers 一択
  • すでに Pages で動いているもの → そのままでよい。困っていないなら移行の必要はない

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

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

Section titled “7. 本サイトのハンズオンとの対応”

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

Workers を使う記事も増えている。

  • WRG の補足：Wrangler だけで新しく作って公開する
  • SVY：Workers Static Assets ＋ Workers Analytics Engine。サイト全体への割り込みが要らないので Workers に向く
  • LAP・WAI：Workers Static Assets ベース

分かれ目は「サイト全体に割り込むか」。 割り込むなら Pages（BAU）、/api/ だけ足すなら Workers（SVY）が素直になる。

8. もっと詳しく

Section titled “8. もっと詳しく”

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

☕️ Vibecoding Notes を応援