こんにちは。Osukeラーニング、運営者の「osuke」です。
Cloudflareでsiteを公開しようとして、「PagesとWorkersのどちらを選ぶのか」「静的siteなのにWorkersを使う必要があるのか」「すでにPagesで動くsiteを移行すべきか」と迷っていませんか。以前は静的siteならPages、APIならWorkersと分けやすかったものの、Workers Static AssetsでHTML・CSS・JavaScriptも配信できるようになり、境界が変わりました。
結論からいうと、2026年9月時点の新規projectはWorkers Static Assetsを第一候補にします。Cloudflare公式もstatic site、SPA、full-stack appを新しく作る場合はWorkersを推奨しています。ただしPagesが廃止されたわけではありません。既存Pagesが安定し、Git branch previewとPages Functionsで足りるなら、移行を急ぐ必要はありません。
この記事はosuke本人の利用体験としては書かず、Cloudflare公式資料14件とXで公開された8件の公開・移行・料金事例を照合しました。Xの結果は各投稿者のprojectに限られるため、料金、上限、機能対応は公式資料を優先します。Cloudflare全体の役割がまだ曖昧なら、先にCloudflareの機能と無料範囲を確認してください。
記事のポイント
- 新規projectはWorkers Static Assetsが公式推奨
- 既存Pagesは必要な機能が不足するまで継続できる
- 静的requestは両方無料で、FunctionsはWorkers枠を使う
- 移行前にrouting・binding・preview・domainの差を確認する
Cloudflare PagesとWorkersの違い
PagesとWorkersはどちらもCloudflareのglobal networkへsiteを公開できます。違いは表示速度の順位ではなく、buildとpreviewの自動化、server codeの書き方、利用できるplatform機能、requestのrouting、今後の機能開発の中心です。
2026年の新規projectはWorkersを基準にする
Cloudflare公式Workers Best Practicesは、static site、SPA、full-stack appの新規projectをWorkers Static Assetsで始めるよう推奨しています。Pagesは継続して動作しますが、新機能と最適化はWorkersへ重点を置く方針です。2026年にゼロから選ぶなら、「静的だからPages」と自動判断せずWorkersを比較の基準にします。
Workers Static Assetsは、build済みのfileをedgeへ置き、必要なURLだけWorker scriptへ通せます。portfolioならほぼ全requestをstaticで返し、/api/contactだけWorkerで処理できます。後からD1、R2、KV、Durable Objectsをbindingで追加する場合も同じWorker projectの中で拡張できます。
ここで古い「Workers Sites」と混同しないでください。Cloudflare公式ではWorkers SitesはWrangler v4でdeprecatedです。新規に使うのはWorkers Static Assetsです。検索結果に古いKV upload手順が出た場合、document名と更新日を見てください。
- 新規site・SPA・Web appはWorkers Static Assets
- 既存Pagesは正常なら即時移行しない
- Workers SitesではなくStatic Assetsを選ぶ
- 必要なdynamic routeだけWorkerを実行する
静的配信とserver処理の境界が違う
PagesはrepositoryまたはDirect Uploadの成果物をsiteとして公開し、server処理が必要なURLをfunctions/directoryへ追加します。file構成からrouteが決まり、初めてserverless処理を作る人には役割を理解しやすい仕組みです。単純なHTML/CSSなら管理画面へuploadする入口もあります。
WorkersはWorker scriptが中心で、assets.directoryにstatic fileを関連付けます。assetが存在するURLは無料のstatic response、APIやSSRはscript invocationです。assets.run_worker_firstを設定すれば、認証やredirectのようにassetより前にWorkerを通すrouteも指定できます。
Xではセカヤサ氏が単純なHTML/CSSをPagesへuploadする入口の簡単さを紹介しています。一方、小路氏はlocalからpublicへ進む際にWorker、DNS、DB、Secrets、CLIまで理解する必要があったと投稿しています。Pagesの入口は軽く、Workersは拡張性と引き換えに確認範囲が広い、という違いが現れます。
| 比較項目 | Pages | Workers Static Assets |
|---|---|---|
| 中心 | site buildとpreview | Worker＋static assets |
| server処理 | functions/のfile route | fetch handlerとrouter |
| 静的file | build outputを配信 | assets.directoryを配信 |
| 拡張 | Pages Functionsの範囲 | Workers platform全体 |
- file uploadだけならPages Direct Uploadは分かりやすい
- API追加予定なら最初からWorkersが移行を減らす
- 不要なbindingやcompatibility flagを増やさない
- 最初の成功条件は1 URLの公開だけにする
Git buildとpreviewの作り方を比較する
PagesのGit integrationはGitHubまたはGitLabへpushすると自動buildし、production branch以外へhash付きpreview URLとbranch aliasを作ります。Pull Requestにはpreview URLとstatusを表示し、defaultでX-Robots-Tag: noindexが付くため、文章や画面をproduction前に確認するworkflowが最初からまとまっています。
WorkersもWorkers BuildsでGit repositoryへ接続し、production branchとnon-production branchをbuildできます。さらにversioned Preview URLとalias Preview URLを作れます。ただしPagesから移す場合、non-production branch build、preview URL、alias、environmentを意識して構成します。Pagesのbranch previewが同じ形で自動移植されるわけではありません。
XではCikyyy2氏がwrangler deploy --temporaryによる一時的なWorker previewを紹介しています。短期検証やAI agentが作った変更を共有するには便利ですが、PagesのPRごとの自動previewとは目的が異なります。共同reviewが中心なら、採用前に同じrepositoryでbranchを1本作り、URL生成から削除まで通してください。
- PR作成時にURLが自動生成されるか
- previewへproduction Secretを渡さない
- noindexとAccess保護を確認する
- branch削除後も残るURLを整理する
利用できる機能と監視範囲が違う
WorkersはVite plugin、Cron Triggers、Durable Objects、Gradual Deployments、Workers Logs、Logpush、Tail Workers、source mapなど、Cloudflareのapplication platform機能を広く使えます。定期処理、statefulな処理、段階release、production error調査が必要ならPagesより選択肢が増えます。
Pagesはbranch preview、Git連携、file-based Functions、rollbackを中心に、frontend siteを公開するworkflowが完成しています。静的blogやdocumentationで、deploy後に見るのがbuild成功と表示確認だけなら、Workersの高度な機能は便益になりません。機能数ではなく、毎月実際に使うoperationで比較してください。
Xではma2no4413氏がsampleから入った不要なDurable Objects、migration、nodejs_compat設定を見直したと投稿しています。Workersの機能が多いことは利点ですが、使わないbindingとflagは設定事故の入口です。templateを使った後は、binding名、migration、compatibility dateを1行ずつ説明できる状態にします。
- Cron・Durable Objects・Queueを使う
- Gradual Deploymentsで段階公開する
- Logs・Logpush・Tailで障害を追う
- Vite pluginでlocalとproduction差を減らす
料金と上限は静的・動的を分ける
Workers Static Assetsのstatic requestは無料・無制限です。Worker scriptを実行するAPIやSSR requestだけがWorkers pricingへ入ります。Pagesもstatic asset requestは無料で、Pages FunctionsはWorkers requestとして数えます。Pages Functions専用の別の無料枠があるわけではありません。
Free planではPages FunctionsとWorkersを合計して1日100,000 dynamic requestsです。たとえばPages Functionsが50,000回、別Workerが50,000回なら同じ日次枠を使い切ります。file上限はPages FreeもWorkers Freeも20,000、paidは100,000、1 fileは25 MiBです。staticだけならPagesからWorkersへ移してrequest料金が劇的に下がる、とはいえません。
Pages Freeの固有上限は500 builds/月、同時1 build、1 build 20分、100 projectsです。Workers Freeは100 Workers、Paidは500 Workersです。Xではちまめ氏がWorkers Paidは個人には枠が広いという感想を投稿していますが、cost判断は感想ではなく、requests、CPU time、build回数、file数を公式単位で試算してください。
| Freeの主な項目 | Pages | Workers |
|---|---|---|
| 静的request | 無料 | 無料・無制限 |
| 動的request | Workersと共有で100,000/日 | 共有で100,000/日 |
| file数 | 20,000/site | 20,000/version |
| build | 500/月、同時1、20分 | Workers Buildsの条件を確認 |
| project数 | 100/account | 100 Workers/account |
- staticとscript invocationを分けて数える
- Pages FunctionsとWorkersの日次枠は共有
- build回数とrequest回数を混同しない
- 移行工数も月額差へ含める
Cloudflare PagesからWorkersへ移行する判断
新規はWorkers推奨でも、既存Pagesをすべて移す必要はありません。現在困っていること、移行で得る機能、変わるrouting、切り戻し時間を先に書き、便益が明確なprojectだけをpreviewへ複製します。
Pagesを継続してよい条件を確認する
静的site、blog、documentation、marketing pageで、Git push、PR preview、custom domain、Pages Functionsの小さなAPIだけを使うならPagesを継続できます。Pagesが動き続けることと、新規推奨がWorkersになったことは矛盾しません。今後の機能投資先がWorkersでも、移行による障害riskが今すぐゼロになるわけではありません。
特に複数人がbranch preview URLを共有し、branch aliasへCMSやreview toolを接続している場合、workflowの置換costを見ます。preview environmentごとに異なるvariablesやbindingを使っているなら、Workers Buildsで同じ分離を再現できるかを先にtestしてください。productionだけ見て移行するとreview環境で壊れます。
Abhijith氏は初めてWorkersとPagesを使い、ゼロから約5時間で構築・公開した例を公開しています。初回projectのscopeを小さくすれば到達できますが、既存siteではdomain、redirect、headers、Functions、Secretsが加わります。新規の成功時間を既存移行の所要時間へそのまま当てはめないでください。
- 現在の公開とpreviewが安定している
- Pages Functionsの機能で足りる
- Cron・Durable Objects・段階releaseが不要
- 移行benefitより検証・切替costが大きい
Workersへ移行する条件を決める
移行を検討するのは、Cronで定期処理したい、Durable Objectsでstateを持ちたい、path単位のRouteを使いたい、Vite pluginでruntime差を減らしたい、Workers Logsでproductionを調べたい時です。「公式推奨だから」だけでなく、現在のPagesで解決できないoperationを1つ以上挙げてください。
新規のfull-stack appもWorkers向きです。Static Assets、API、D1、R2を一つのdeploy単位にでき、bindingでcredentialをcodeへ直書きせず接続できます。ただしserviceをまとめるほど、1回のdeployがfrontendとAPIの両方へ影響します。asset変更とAPI変更のrollback単位を分けたいならWorkerを分割する設計も候補です。
すでにVercelなど他platformから移す場合も、Pagesを経由せずWorkers Static Assetsを直接検証できます。Bicen Dinh氏はVercelからCloudflareへの移行がone-clickではなく調整を要したと報告しています。framework adapter、Node.js API、image処理、cacheを移行項目へ含め、hosting料金だけで工数を判断しないでください。
- 現在のPagesで不足する機能を1つ書く
- 月に何回使う機能か数える
- 移行・test・rollback時間を見積もる
- 6か月分の便益が工数を上回る時に進める
設定fileとroutingを変換する
Cloudflare公式のPagesからWorkersへの移行guideでは、pages_build_output_dirをassets.directoryへ変えます。Pagesのadvanced modeで_worker.jsを使っている場合はWorkerのmainに指定し、functions/はwrangler pages functions buildで1つのWorkerへcompileする方法があります。
重要なのはrequest順序です。PagesではFunctionsがassetより先に処理される構成がありますが、Workers Static Assetsはdefaultで一致するstatic assetを先に返します。認証、middleware、動的headerを全pageへ適用するならassets.run_worker_firstを設定します。逆に不要な全request実行はdynamic requestとCPUを増やすため、routeを絞ります。
SPAはPagesの自動判定へ依存せず、Workersでassets.not_found_handling = "single-page-application"を明示します。_headersと_redirectsはstatic assetsで利用できますが、Worker scriptが返すresponseへ自動適用されるとは限りません。存在しないURL、deep link、redirect、404、authenticationを表にしてtestします。
assets.directoryのbuild出力先mainとcompiled Functionsの入口run_worker_firstで変わるrequest順序- SPA fallback・404・redirect・headers
Binding・preview・domainの差を確認する
Pagesはadvanced modeのWorkerへASSETS bindingを自動で用意します。Workersではscriptからassetを読む場合、設定fileへbindingを明示し、名前も自分で決めます。D1、R2、KV、Secret、environment variableもproductionとpreviewで同じ対象を向いていないか確認し、test dataがproductionへ書き込まれないようにします。
custom domainも差があります。WorkersのCustom Domainは対象zoneをCloudflare nameserverで管理する必要があります。Pagesのapex domainもCloudflare nameserverが必要ですが、外部DNSで管理するsubdomainはCNAMEを使える構成があります。現在のDNS providerを変えたくない場合、domain条件だけでPages継続が合理的なことがあります。
CLIはwrangler pages dev/deployからwrangler dev/deployへ変わり、URLはpages.devからworkers.devになります。旧URLを外部service、OAuth callback、webhook、Search Consoleへ登録している場合は一覧化します。公開siteだけ表示できても、callbackとwebhookが旧URLのままなら移行は未完了です。
- D1・R2・KV・Secretの環境別binding
- Custom Domainとnameserverの条件
- OAuth callback・webhook・CORS許可URL
- Search Console・monitoring・sitemapのURL
段階移行して切り戻せる状態を作る
production Pagesを直接書き換えず、同じbuild outputを別名のWorkerへdeployします。temporaryまたはpreview URLでhomepage、deep link、404、redirect、form、login、API、image、downloadを確認します。次にcustom subdomainでtestし、最後にproduction domainを切り替えます。旧Pages projectは24〜72時間残します。
XではKeisuke Nishitani氏がframework、hosting、DNSを段階的に変更した経過を公開しています。個別siteの事例ですが、原因を1変更へ絞れる進め方はPagesからWorkersへの移行にも使えます。code変換、hosting切替、DNS切替を同じ日にまとめないでください。
切替後はstatic asset hit、Worker invocation、4xx/5xx、CPU time、form到達、login成功を見ます。問題があればdomain routeを旧Pagesへ戻し、Workers側の原因をpreviewで修正します。今日の1stepは、新規projectなら最小のWorkers Static Assetsを1つ公開し、既存Pagesなら移行理由を1行書いてpreviewへ複製することです。
- 別名Workerへ同じbuildをdeploy
- static・API・login・formをpreview確認
- test用subdomainで外部連携を確認
- production domainだけを切り替える
- 24〜72時間後に旧環境を整理する
Cloudflare PagesとWorkersの違いは、「静的か動的か」だけではなくなりました。新規projectは今後の機能開発と統合範囲を考えてWorkers Static Assetsを基準にし、既存Pagesは明確な不足が出るまで安定運用を優先します。Workersを初めて公開する場合はCloudflare Workersの始め方、他社も含めて公開先を選ぶ場合はCloudflareとVercelの比較も確認してください。
