Cloudflare で新しくサイトやアプリを公開するなら、公式は Workers を勧めています。Pages の公式文書のトップに「新しいプロジェクトは Workers で始めてください」という意味の一文があり、Cloudflare のブログは、Pages は引き続きサポートするが、今後の投資・最適化・機能開発はすべて Workers に向ける、と書いています。廃止とは書かれていません（2026年10月10日時点）。
この記事は、Cloudflare にサイトを置きたいけれど、Pages と Workers のどちらを選べばよいか迷っている初心者に向けて、2つの違い、無料プランの上限、Git とつないで公開する手順の違い、Pages から Workers へ移す方法を説明します。Cloudflare の文書は随時更新されるので（例: Workers の上限のページは2026年10月8日に更新）、日付が効く話には「2026年10月10日時点」と、出どころのページを添えています。
- Cloudflare Pages と Workers とは何か（「Workers」という言葉の2つの意味も）
- 公式が「新しく始めるなら Workers」と言っている根拠と、Pages が廃止とは書かれていないこと
- Pages と Workers の違い（見つからない URL の扱い・独自ドメイン・機能の対応表）
- 無料プランの上限（ビルド・ファイル数・リクエスト）を、プランの呼び名と単位をそろえて
- Git とつないで公開する手順の違いと、Pages から Workers へ移す手順
\\ 3丁目オーナー開発アプリ！コンテンツ随時更新中 //
\\ これからITフリーランス //
\\ 3丁目オーナー開発アプリ！コンテンツ随時更新中 //
\\ これからITフリーランス //
Cloudflare Pages と Workers とは？
Cloudflare の公式の説明では、Pages はフルスタックのアプリを作って、Cloudflare の世界中のネットワークにすぐ公開できるサービスです。どのプランでも使えます。公開の方法は3つあります。
- Git（GitHub・GitLab）とつなぐ
- 作り終えたファイルを直接アップロードする（Direct Upload）
- コマンドラインから C3（Cloudflare のコマンドラインの道具）を使う
Pages の主な機能は、Pages Functions（サーバーを置かずに、サーバー側のコードを動かす機能）、ロールバック（前の本番の公開に戻す機能）、リダイレクト（アクセスを別の URL へ回す設定）です。
Workers は、公式の説明では、サーバーレスの実行環境です。サーバーレスとは、インフラ（サーバーなど）を自分で設定・保守しなくても、コードを動かせる仕組みのことです。Workers を使うと、インフラを設定・保守せずに、新しいアプリを作ったり、既存のものを強くしたりできます。
出典: Cloudflare Pages の文書（2026年8月25日更新）
「Workers」という言葉は2つの意味で使われる
ここで、言葉をそろえておきます。「Workers」は、次の2つの意味で使われます。
- サーバーで動くコード（Worker スクリプト）
- そのコードと一緒に、静的なファイルを配る仕組み（Workers の静的アセット。Static Assets）
静的なファイルとは、HTML・CSS・画像のように、サーバー側で組み立てずにそのまま配るファイルのことです。公式の説明では、HTML・CSS・画像などのファイルを Worker の一部としてアップロードでき、キャッシュと配信は Cloudflare がしてくれます。
この記事で「Workers」と書くときは、1と2をあわせた製品全体を指します。Pages と比べるときは、とくに2の静的アセットの話になります。
出典: Workers の静的アセット（2026年7月3日更新）
Cloudflare そのものが何をする会社・サービスなのかは、Cloudflare とは？の記事で説明しています。また、サイトを置く場所は Cloudflare だけではありません。WordPress を自分で置く手順はWordPress の始め方の記事に、サーバーを借りる選択肢はレンタルサーバーの比較の記事にあります。
Pages は廃止されるの？新しく始めるならどっち？
Pages の公式文書のトップには、「Are you sure you want to use Pages?」（本当に Pages を使いますか？）という囲みがあります。中身は次の趣旨です。
- Workers は、Pages の使い道のほとんどに対応していて、機能も広い
- Workers は、Cloudflare がアプリを作るための主な基盤にしている
- 新しいプロジェクトは Workers で始める
「Workers は Pages の使い道のほとんどに対応し…」の部分は、公式の「Pages から Workers への移行」のページへのリンクになっています。
Cloudflare のブログ（2025年4月8日）にも、同じ趣旨が書かれています。日本語版の文を、そのまま引きます。
Workersが静的アセットの配信とサーバーサイドレンダリングの両方をサポートするようになったので、Workersから始めるのがよいでしょう。Cloudflare Pagesは引き続きサポートしますが、今後の投資、最適化、機能開発の作業はすべてWorkersの改善に向けられます。
サーバーサイドレンダリング（SSR）とは、サーバー側で画面（HTML）を組み立てて返すことです。同じブログには、Workers で静的アセットを無料で配る機能は2024年9月にベータとして出た、とも書かれています。
出典: Cloudflare Pages の文書・Cloudflare のブログ（日本語版）・同（英語版）
「廃止」とは書かれていない
「Cloudflare Pages は廃止されるの？」と気になる人は多いはずです。2026年10月10日時点で、次のページの本文には、廃止（deprecated）や終了（sunset、end of life）を意味する語がありません。
- Pages の文書のトップ
- 「Pages から Workers への移行」のページ
- Pages の上限のページ
ブログの言い方は「引き続きサポートします」です。この記事で言えるのは、ここまでです。
- 公式は、新しく始めるなら Workers を勧めている
- Pages は引き続きサポートされる。ただし、今後の投資・最適化・機能開発は Workers に向かう
- 廃止の予定や日付は、読んだページに書かれていない
「いずれ廃止される」「非推奨になった」とは、公式が書いていないので、この記事も書きません。
「どっち？」への答え
公式に根拠があるのは、「新しく始めるなら Workers」という点です。ただし、Workers にできないこと、まだ足りないことも、次の節の表に載っています。たとえば、ネームサーバーを Cloudflare に置いていないドメインは、Workers では使えません。自分の使い方がその行に当たるかどうかを、次の節の表で確かめてから選びます。
Cloudflare Pages と Workers の違いは？
違いは、公式の「Pages から Workers への移行」のページ（2026年9月22日更新）に、いちばんまとまっています。最初に、公式が書いている大きな点を挙げます。
- 料金の作りは似ている。 静的アセットへのリクエストは、Pages と同じく Workers でも無料です。Pages Functions の呼び出しは、Workers と同じ料金で数えます
- 機能は Workers のほうが明らかに広い。 公式は例として、Durable Objects・Cron Triggers・より充実した観測（Observability。動きを見る仕組み）を挙げています
- 移行は、たいてい素直な作業。 公式は「often a straightforward process」と書いています
動きの違い（表）
初心者がつまずきやすい、動きの違いを表にします。
| 項目 | Pages | Workers（静的アセット） |
|---|---|---|
| 見つからない URL | 404.html と index.html の有無で、SPA か独自の 404 ページかを自動で決める | 誤設定を防ぐため、自分で明示的に設定する（assets.not_found_handling） |
| コードと静的ファイルの順番 | Pages Functions を静的アセットより先に動かすのが既定 | 静的アセットを先に返すのが既定。先にコードを動かすなら assets.run_worker_first を設定する |
| 不要なファイルの扱い | node_modules・.DS_Store・.git などを自動でアップロードから外す | アセットのフォルダに .assetsignore を置いて外す |
| 手元の確認・公開のコマンド | wrangler pages dev・wrangler pages deploy（手元の確認用サーバーの既定のポートは 8788） | wrangler dev・wrangler deploy（既定のポートは 8787） |
_headers・_redirects | アセットのフォルダに入れて使う | そのまま使える（アセットのフォルダに入れる） |
| 既定の URL | pages.dev のサブドメイン | workers.dev のサブドメイン |
| 独自ドメイン | サブドメインなら、ネームサーバーを Cloudflare にしなくても使える場合がある | ネームサーバーを Cloudflare で管理しているドメインだけ |
出典: Pages から Workers への移行（公式）・Pages の配信の仕組み（2026年4月21日更新）
用語を補います。
- SPA（シングルページアプリ）。 ページを切り替えても、ブラウザがページ全体を読み込み直さない作りのアプリのこと
- Wrangler（ラングラー）。 Cloudflare が配っている、コマンドラインの道具。手元で動かして確かめたり、公開したりするときに使う
_headers・_redirects。 ヘッダー（通信に添える情報）の追加と、URL の転送の設定を書くファイル
見つからない URL の扱い
存在しない URL を開かれたときの動きは、Pages と Workers で考え方が違います。
Pages の既定は、次のとおりです。いちばん上の階に 404.html が無いと、Pages は SPA だと見なして、どの URL もトップ（/）に当てます。404.html があれば、近い階の 404.html を探して返します。
Workers は、公式によれば誤設定を防ぐために、この動きを自分で明示的に設定します。assets に、SPA なら "not_found_handling": "single-page-application"、独自の 404 ページなら "not_found_handling": "404-page" を足します。404-page にすると、見つからない URL には、いちばん近い 404.html を 404 Not Found で返します。
独自ドメインの違い
独自ドメインの条件は、2つで大きく違います。
- Workers は、ネームサーバーを Cloudflare で管理しているドメインしか使えません。公式は「Unlike Pages, Workers does not support any domain whose nameservers are not managed by Cloudflare.」と書いています。前提は「有効な Cloudflare のゾーン」です。すでに CNAME のあるホスト名や、自分のものではないゾーンには、独自ドメインを作れません
- Pages は、サブドメイン（例:
shop.example.com）なら、ネームサーバーを Cloudflare に向けなくても使えます。いまの DNS に、<YOUR_SITE>.pages.dev向けの CNAME を足します。ルートのドメイン（例:example.com）は、Cloudflare のゾーンにする必要があります
ネームサーバーとは、そのドメインの DNS の設定を預けている先です。DNS は、ドメイン名とサーバーを結びつける仕組みで、CNAME は「この名前は、あの名前の別名です」と伝える DNS の記録です。ゾーンは、Cloudflare に登録した1つのドメインの設定のまとまりです。
ドメインの DNS を他社に置いたまま、サブドメインだけを向けたい場合は、Pages ならできます。Workers でも同じようにできる、とは書かれていません。
注意があります。Pages で、CNAME だけを先に足して、Pages の画面でドメインを結びつけていないと、そのドメインは 522 エラーになります。
出典: Workers の独自ドメイン（2026年9月29日更新）・Pages の独自ドメイン（2026年4月21日更新）
機能の対応表
公式の移行のページには、機能の対応表があります。その中から、選ぶときに効く行を抜き出しました。2026年10月10日時点の表です。公式は、表に載っていないものは Pages でも Workers でも動く、と書いています。下の表は、公式の表から抜き出したものです（全部の行は、公式の表で確かめてください）。
| 機能 | Workers | Pages |
|---|---|---|
| Cloudflare Vite plugin | 対応 | 未対応 |
| Gradual Deployments（少しずつ切り替える公開） | 対応 | 未対応 |
| Serve assets on a path（サイトの一部のパスだけで配る） | 対応 | 未対応 |
| Non-root routes（ドメインの一部のパスだけに割り当てる） | 対応 | 未対応 |
| Workers Logs・Logpush・Tail Workers・Source Maps | 対応 | 未対応 |
| Cron Triggers（決まった時刻にコードを動かす） | 対応 | 未対応 |
| Queue Consumers・Rate Limiting・Email Workers・Image Resizing | 対応 | 未対応 |
| Durable Objects | 対応 | 回避策あり |
| Rollbacks・Preview URLs・Local Development | 対応 | 対応 |
| Redirects・カスタム HTTP ヘッダー（静的アセット） | 対応 | 対応 |
| D1・KV・R2・Secrets・環境変数 | 対応 | 対応 |
| Custom domains・Custom subdomains | 対応 | 対応 |
| Early Hints | 回避策あり | 対応 |
| Branch Deploy Controls | 回避策あり | 対応 |
| File-based Routing（フォルダの形がそのまま URL になる仕組み）・Pages Plugins | 回避策あり | 対応 |
| Custom Branch Aliases | 近日対応予定 | 対応 |
| Custom domains outside Cloudflare zones（Cloudflare のゾーンの外のドメイン） | 未対応 | 対応 |
出典: 公式の移行ガイドの表から抜粋（2026年10月10日時点。Compatibility matrix）。公式の記号を言葉に直しました。「回避策あり」は、そのままでは未対応だが、公式の脚注に別のやり方が書かれているものです。この表は、公式の側で更新されます。
表からわかるのは、次のことです。
- Workers にあって Pages に無い機能が、多く並びます。公式が「Workers の機能は明らかに広い」と書くとおりです
- 逆に、Pages だけが対応の行もあります。とくに、Cloudflare のゾーンの外のドメインを（サブドメインなら）使えるのは Pages だけです
- 「Workers は Pages のすべてができる」とは言えません。Pages のトップの文も「ほとんどの使い道に対応」であって、「すべて」ではありません
Pages を選ぶ理由として公式の表から言えるのは、この表で Pages だけが対応の行に、自分の使い方が当たるときです。当たらないなら、公式が勧める Workers で始める形になります。
無料プランの上限はどこまで？
上限と料金は、2026年10月10日時点の公式の文書の数です。公式の文書は随時更新されるので（例: Workers の上限のページは2026年10月8日に更新）、使う前に、表の下に書いたページで最新の数を確かめてください。
最初に、読み間違えやすい点が3つあります。
- 「無料プラン」の呼び名が、ページで違います。 Pages の上限のページは「Cloudflare の Free プラン」（Free・Pro・Business の3段）で書かれています。Workers の上限のページは「Workers Free」と「Workers Paid」で書かれています。同じ「無料」でも、別のプランの話です。この記事では、表を分けて書きます
- ビルドの数え方の単位が違います。 Pages は「回数」、Workers の Git 連携（Workers Builds）は「分」で数えます。数字をそのまま比べられません
- 「1日 100,000 リクエスト」は、コードを動かすリクエストの枠です。 静的なファイルへのリクエストの枠ではありません。詳しくは、このあとの表の下で説明します
Pages の上限（Cloudflare の Free プラン）
| 項目 | Free プランの上限 |
|---|---|
| ビルド | 同時に1つ。月 500 回（Pro は 5,000 回、Business は 20,000 回） |
| ビルドの時間 | 20分で打ち切り（同時ビルドの数は、アカウントごとに数える） |
| 独自ドメイン | 1プロジェクトあたり 100（Pro は 250、Business は 500） |
| ファイルの数 | 1サイトあたり 20,000 ファイル |
| ファイル1つの大きさ | 25 MiB まで |
_headers | 100 ルールまで。1つのヘッダーは 2,000 文字まで |
_redirects | 静的な転送 2,000 と動的な転送 100、合わせて 2,100 まで |
| プレビューの公開 | 数の制限なし |
| プロジェクト | アカウントごとに 100 まで（ふだんは増やされない） |
出典: Pages の上限（公式。2026年9月5日更新）。ページの前置きに「Cloudflare の Free プランの上限」と書かれています。
MiB は、1 MiB = 1,024×1,024 バイトの単位です。25 MiB を超える大きいファイルは、R2（Cloudflare のファイルの置き場）に置いて配ることを、公式が勧めています。
Pages では、Git のリポジトリに新しいコードを push するたびに、ビルドと公開が走ります。つまり、ビルドの回数は push の回数で増えていきます。ファイルの数は、有料プランなら 100,000 まで増やせます（環境変数 PAGES_WRANGLER_MAJOR_VERSION=4 を、Pages の設定に入れる必要があります）。
Workers の上限（Workers Free）
| 項目 | Workers Free の上限 |
|---|---|
| コードを動かすリクエスト | 1日 100,000 回（UTC の0時に戻る）。超えると Error 1027 |
| CPU 時間 | 1回のリクエストで 10 ms（ネットワークの待ち時間は数えない） |
| サブリクエスト（Worker から外へ出すリクエスト） | 1リクエストあたり 50 回 |
| メモリ | 128 MB |
| 環境変数 | 1つの Worker に 64 個まで。1つ 5 KB まで |
| Worker の数 | 100 |
| Cron Triggers | 5（アカウントごと） |
| 静的アセットのファイルの数 | Worker の1つの版あたり 20,000 ファイル |
| 静的アセット1ファイルの大きさ | 25 MiB |
_headers・_redirects | Pages と同じ数（_headers は 100 ルール、_redirects は合計 2,100） |
出典: Workers の上限（公式。2026年10月8日更新）
コードを動かすリクエストの枠を超えたときは、ルートの設定で2つから選べます。Fail open は、Worker を飛ばして、Worker が無いときと同じに扱います。Fail closed は、Cloudflare の 1027 のエラーページを返します。
有料の Workers Paid なら、静的アセットのファイルは 100,000 まで増やせます。Wrangler で使うには、版 4.34.0 以上が要ります。Workers Paid は、アカウントあたり最低で月5米ドルです（円には直していません）。
静的なファイルへのリクエストは、無料・無制限
料金の話で、いちばん間違えやすい点です。
- Pages。 無料でも有料でも、静的アセットへのリクエストは無料・無制限です。Pages Functions を動かさないリクエストが「静的」です
- Workers。 静的アセットへのリクエストは、無料・無制限です。Worker のコードを動かすリクエスト（たとえば SSR）は、Workers の料金で数えます。アセットの保管にも、追加の料金はありません
出典: Pages Functions の料金（公式。2026年9月8日更新）・Workers の静的アセットの課金と制限（公式。2026年4月23日更新）・Workers の料金（公式。2026年10月2日更新）
つまり、「Workers にすると、1日 10 万アクセスまでしか受けられない」わけではありません。1日 100,000 回の枠を使うのは、コードを動かすリクエストです。
ただし、次の2つに注意します。
- コードを動かす機能を足すと、枠を使います。 Pages Functions も、Workers Free の1日 100,000 回の枠を、Workers と分け合います。公式の例では、Functions を 50,000 回と Workers を 50,000 回で、1日の枠を使い切ります。枠は UTC の0時に戻ります
run_worker_firstに当たる URL は、必ずコードを動かします。 無料の枠を超えると、静的アセットには戻らず、429（Too Many Requests）が返ります
また、公式の料金のページの脚注には、Workers Caching を有効にすると、Worker のキャッシュから返したリクエストが、Worker を動かしたリクエストと同じ単価になる、と書かれています。この記事では Workers Caching を調べていないので、「静的アセットは、どんな設定でも無料」とは言いません。「静的アセットへのリクエストは無料・無制限」は、公式の課金のページの言い方です。
Git とつないだときのビルドの上限
Git とつないで公開するときのビルドの上限は、Pages と Workers で、数え方が違います。
| Pages（Free プラン） | Workers Builds（Free プラン） | |
|---|---|---|
| ビルドの量 | 月 500 回 | 月 3,000 分 |
| 同時ビルド | 1つ | 1つ |
| 打ち切り | 20分 | 20分 |
Workers Builds の Free プランのビルド環境は、2 vCPU・メモリ 8 GB・ディスク 20 GB です。有料プラン（Paid）は、月 6,000 分で、超えると1分あたり 0.005 米ドル、同時ビルドは6つです。
出典: Workers Builds の上限と料金（公式。2026年5月29日更新）
「回数」と「分」は単位が違うので、どちらが多いかは、1回のビルドが何分かかるかで変わります。「Workers のほうが多い（少ない）」とは言えません。
公式のページに書かれていなかったこと
サイト全体の合計の大きさ（容量）の上限は、Pages と Workers の上限のページに、見つかりませんでした。書かれているのは、ファイルの数と、ファイル1つの大きさです。そのため、「無料で〇 GB まで」とは書きません。また、Pages の上限のページには、転送量（帯域）の項目がありません。「帯域は無制限」とも書きません。
Git とつないで公開する手順は、どう違う？
GitHub などのリポジトリとつなぐと、push のたびに自動でビルドと公開が走ります。つなぐ手順は、Pages と Workers で違います。以下は、2026年10月時点の公式の文書の手順で、ボタン名も文書のとおりです。画面は変わることがあり、この記事では画面を開いて確かめていません。
| Pages | Workers | |
|---|---|---|
| 仕組みの名前 | Git integration | Workers Builds |
| 自動の公開 | push のたびにビルドと公開 | push のたびに自動でビルドと公開 |
| つなげるサービス | GitHub・GitLab | GitHub・GitLab など |
| 本番のブランチ | 多くは main か master。それ以外のブランチはプレビュー | 本番のブランチは新しい「版」になる。それ以外のブランチはプレビュー |
| 公開後の URL | プロジェクト専用の URL | workers.dev のサブドメイン |
出典: Pages の Git 連携（公式。2026年4月21日更新）・Workers Builds（公式。2026年10月1日更新）・Workers Builds の Git 連携（公式。2026年10月1日更新）
Workers Builds について、公式は、自分で立てた GitHub・GitLab（セルフホスト）にはつなげないと書いています。Bitbucket など別のサービスを使うときは、外の CI/CD（たとえば GitHub Actions）から Wrangler で公開する形を、公式が案内しています。
Pages の手順（Git とつなぐ）
- Cloudflare の画面で Workers & Pages を開く
- Create application → Pages → Connect to Git を選ぶ
- Git のサービスにログインして、リポジトリを選ぶ
- Install & Authorize → Begin setup を選ぶ
- Set up builds and deployments で設定する
- Save and Deploy を選ぶ
設定で決めるのは、次の4つです。
- プロジェクト名（公開の URL の名前になる）
- 本番のブランチ
- ビルドのコマンド（ビルドが要らないなら、空でよい）
- ビルドの出力フォルダ
公開が終わると、そのサイト専用の URL がもらえます。
Workers の手順（Git とつなぐ）
新しく作るときの手順です。
- Cloudflare の画面で Workers & Pages を開く
- Create application を選ぶ
- Import a repository の横の Get started を選ぶ
- Git account を選んで、リポジトリを選ぶ
- プロジェクトを設定して、Save and Deploy を選ぶ
workers.devのサブドメインで、公開されたものを見る
すでにある Worker につなぐときは、その Worker を選んで、Settings → Builds → Connect と進みます。
つまずきやすい点が2つあります。
- 名前を合わせる。 画面の Worker の名前と、設定ファイルの
nameが一致しないと、ビルドが失敗します - 設定ファイルが無いとき。 リポジトリに Wrangler の設定ファイルが無いと、Cloudflare がフレームワークを見分けて設定を作り、プルリクエストを送ってきます。マージすると、公開できる状態になります
最初に選んだ方式は、Pages では後から変えられない
Pages には、Git とつなぐ方式のほかに、Direct Upload があります。自分のビルドの仕組み（CI）を使うときや、手元のパソコンから上げるときに選ぶ方式です。Wrangler か、画面へのドラッグ＆ドロップ（zip かフォルダ）で上げます。
大事なのは、最初に選んだ方式を、後から変えられないことです。
- Git 連携で作ったプロジェクトは、後から Direct Upload に切り替えられません（自動の公開を止めて、Wrangler で上げることはできます）
- Direct Upload で作ったプロジェクトは、後から Git 連携に切り替えられません。自動で公開したいなら、Git 連携の新しいプロジェクトを作り直します
Wrangler で Direct Upload するコマンドは、次のとおりです。
# Pages のプロジェクトを作る
npx wrangler pages project create
# ビルドの出力フォルダを公開する（<プロジェクト名>.pages.dev に出る）
npx wrangler pages deploy <BUILD_OUTPUT_DIRECTORY>
# プレビューとして公開する（<ブランチ名>.<プロジェクト名>.pages.dev に出る）
npx wrangler pages deploy <OUTPUT_DIRECTORY> --branch=<BRANCH_NAME>Workers で静的なサイトを始める公式の手順は、次の流れです。
# 1. 作る（質問が出たら、Hello World example → Static site を選ぶ）
npm create cloudflare@latest -- my-static-site
# 2. 手元で見る
npx wrangler dev
# 3. 公開する（*.workers.dev か独自ドメインに出る）
npx wrangler deploy出典: Pages の Direct Upload（公式。2026年4月21日更新）・Workers の静的サイトの始め方（公式。2026年8月25日更新）
公開のコマンド（deploy・pages project create）は、Cloudflare のアカウントにつなぐ操作です。公式の手順どおりに載せていて、この記事では、どれも流していません。出力例も載せません。（wrangler dev は、手元で確認用のサーバーを動かすコマンドです。）
Workers で、自動の本番公開を止めて、「版」だけを残したいときは、公開のコマンドを npx wrangler versions upload にします。ビルドは自動で走り、版として保存されますが、本番には出ません。
Pages から Workers に移すには？
すでに Pages を使っている人向けの節です。公式は、Pages は引き続きサポートすると書いています。今すぐ移さないといけない、とは読んだページに書かれていません。移したくなったときのために、公式の移行のページ（2026年9月22日更新）の手順を、順に説明します。公式は、移行はたいてい素直な作業だと書いています。
1. 設定ファイルを作る
プロジェクトの直下に、Wrangler の設定ファイルを作ります。名前は wrangler.jsonc・wrangler.json・wrangler.toml のどれかです。必須の項目は、name と compatibility_date の2つです。
Pages の「ビルドの出力フォルダ」（pages_build_output_dir）は、Workers では assets.directory に書きます。公式の例は、次のとおりです。
// Pages の設定（前）
{
"name": "my-pages-project",
"pages_build_output_dir": "./dist/client/"
}// Workers の設定（後）
{
"name": "my-worker",
// 書いた日の日付に置き換える
"compatibility_date": "2026-10-10",
"assets": {
"directory": "./dist/client/"
}
}compatibility_date は、公式の例で「今日の日付にする」とコメントされています。ここに書いた日付は、この記事を書いた日のものなので、自分で書く日の日付に置き換えてください。
ファイルだけで Worker のコードが無いときは、設定に "binding": "ASSETS" を書きません。この項目は、main でコードを指しているときだけ有効です。
2. 見つからない URL の扱いを決める
先に説明したとおり、Workers では明示します。SPA なら "not_found_handling": "single-page-application"、独自の 404 ページなら "not_found_handling": "404-page" を、assets の中に足します。
3. Pages Functions（functions/ フォルダ）があるとき
Pages Functions を functions/ フォルダで書いていたら、次のコマンドで1本の Worker にまとめ、設定の main にその出力を書きます。
npx wrangler pages functions build --outdir=./dist/worker/フォルダの形で URL を決める書き方（File-based Routing）を続けたいなら、別のフレームワークも検討するよう、公式が書いています。公式が挙げている例は HonoX です。
4. コマンド・ビルド・ファイルの扱いを置き換える
- コマンド。
wrangler pages devとwrangler pages deployの代わりに、wrangler devとwrangler deployを使います - Git 連携のビルド。 Pages の組み込みの CI/CD を使っていたなら、Workers Builds にリポジトリをつないで、Pages の自動公開を止めます
- 不要なファイル。 Pages が自動で外していたファイルを外したいときは、アセットのフォルダに
.assetsignoreを置きます - 変数。 Pages と違い、Workers は実行時の変数とビルド時の変数を共有しません
- コードを先に動かしたいとき。 Workers は静的アセットを先に返すのが既定です。認証や記録のために、先にコードを動かすなら
assets.run_worker_firstを設定します _headers・_redirects。 そのまま使えます。Pages と同じく、アセットのフォルダに入れておきます
ブランチごとのプレビューを出したいときは、設定に "preview_urls": true と "previews": {} を足して、Workers Builds でプレビューのビルドを有効にします。
5. 全部移し終えたら、Pages のプロジェクトを消す
本番の通信を全部 Workers に移し終えたあとなら、公式の手順の最後に、Pages のプロジェクトは Cloudflare の画面か、Wrangler（npx wrangler pages project delete）で消せる、とあります。消す操作なので、本番の通信を全部移してから行います。
独自ドメインをつけた Pages のプロジェクトを消すときは、先に、そのプロジェクトに向けた CNAME の記録を消します。消し忘れると、DNS の記録が残ったまま、無くなったプロジェクトを指すことになります（Pages の Git 連携（公式。2026年4月21日更新）の注意書き）。
公式は、AI のコーディング支援（Claude Code や Cursor など）に渡す、移行用のプロンプト（実験的）も出しています。この記事では、プロンプトの中身は確かめていません。公式のプロンプトに目を通してから使います。
よくある質問
Cloudflare Pages は廃止されるの？
2026年10月10日時点で、公式の文書に、廃止の予定や日付は書かれていません。公式は、Pages は引き続きサポートする、ただし新しく始めるなら Workers と書いています（くわしくは、上の「Pages は廃止されるの？」の節）。
Cloudflare の無料枠は、どこまで使える？
Pages と Workers では、プランの呼び名も、数え方も違います。Pages は Free プランでビルド月 500 回・ファイル 20,000・1ファイル 25 MiB、Workers は Workers Free でコードを動かすリクエスト1日 100,000 回・静的アセットのファイル 20,000・1ファイル 25 MiB です。静的なファイルへのリクエストは、どちらも無料・無制限です。表と出どころは、上の「無料プランの上限はどこまで？」の節にあります。サイト全体の合計の容量の上限は、見つかりませんでした。
Workers で静的なサイト（HTML だけのサイト）を置ける？
置けます。HTML・CSS・画像などのファイルを Worker の一部としてアップロードでき、キャッシュと配信は Cloudflare がします。設定ファイルの assets.directory に、ファイルのフォルダを書きます。既定では、URL がファイルに当たればそのファイルを返し、コードは動きません。当たらず、コードもなければ、404 Not Found が返ります。見つからない URL に 404.html を返すなら、not_found_handling を "404-page" にします（くわしくは、上の「見つからない URL の扱い」の節）。
独自ドメインは使える？
どちらも使えます。ただし条件が違います。Workers は、ネームサーバーを Cloudflare で管理しているドメインだけです。Pages は、サブドメインなら、ネームサーバーを Cloudflare に向けなくても、CNAME を足して使えます。ルートのドメインは Cloudflare のゾーンにする必要があります。独自ドメインの数は、Pages の Free プランで1プロジェクトあたり 100 までです。
料金はかかる？
静的なファイルへのリクエストは、Pages も Workers も無料・無制限です。コードを動かすと（Pages Functions や、SSR のような Worker のコード）、Workers の枠と料金を使います。Workers Free の枠は、1日 100,000 回です。有料の Workers Paid は、アカウントあたり最低で月5米ドルです（2026年10月10日時点）。
まとめ
- Cloudflare Pages も Workers も、サイトやアプリを Cloudflare に公開する仕組み。公式は、新しく始めるなら Workers を勧めている
- Pages は廃止とは書かれていない。引き続きサポートされるが、今後の投資・最適化・機能開発は Workers に向かう（2026年10月10日時点）
- 違いは、見つからない URL の扱い・コードと静的ファイルの順番・コマンド・独自ドメインの条件など。Workers は機能が広いが、Cloudflare のゾーンの外のドメインを（サブドメインなら）使えるのは Pages だけ
- 無料プランは、Pages は「Cloudflare の Free プラン」、Workers は「Workers Free」と、呼び名も単位も違う。静的なファイルへのリクエストは、どちらも無料・無制限
- 1日 100,000 リクエストは、コードを動かすリクエストの枠。Pages のビルドは「回数」、Workers Builds は「分」で数える
- Pages の Git 連携と Direct Upload は、後から切り替えられない
- Pages から移すときは、設定ファイルを作り、
pages_build_output_dirをassets.directoryに置き換える。本番の通信を全部移したあとに、Pages のプロジェクトを消す
参考資料
- Cloudflare Pages の文書（トップ）
- Cloudflare のブログ: Your frontend, backend, and database — now in one Cloudflare Worker（日本語版）
- Cloudflare Workers: Static Assets
- Cloudflare Workers: Migrate from Pages to Workers
- Cloudflare Pages: 上限（Limits）
- Cloudflare Workers: 上限（Limits）
- Cloudflare Workers: 料金（Pricing）
- Cloudflare Workers Builds: 上限と料金
- Cloudflare Pages: Git integration
- Cloudflare Pages: Direct Upload
- Cloudflare Workers Builds
- Cloudflare Pages: 独自ドメイン
- Cloudflare Workers: 独自ドメイン
※この記事は、公式の資料をもとに AI（Claude）で下書きし、2026年10月10日時点の公式の資料と照らして確かめてから公開しています。誤りに気づいたらお問い合わせからお知らせください。
