長年、「これをCloudflareのどこにデプロイすればいいか」という問いへの答えはシンプルでした。静的サイトとフロントエンドはPagesへ、サーバーレスのロジックはWorkersへ、というものです。2026年、その境界線はあいまいになりました。Workersが今や静的アセットを直接配信できるようになり、つまり1つのWorkerでサイト全体、フロントエンドとバックエンドを一緒にホストできるからです。これによりCloudflare自身の新規プロジェクトへの推奨が変わりました。どちらを選ぶか決める前に、その理由を理解しておく価値があります。

このガイドでは、各製品が何であるか、静的アセットへの移行がCloudflare Pages vs Workersの判断をどう変えたか、そして新規構築や移行を検討している人への明確な推奨を説明します。

要点

  • Pagesは静的サイトとフロントエンドフレームワーク向けのgit連携ホスティングで、CI/CDとプレビューデプロイを内蔵しています
  • WorkersはCloudflareのサーバーレスコンピュートプラットフォームで、今や静的アセットも配信するため、サイト全体をホストできます
  • 2026年の新規プロジェクトには、Cloudflareは静的アセットを用いたWorkersを推奨します。フロントエンドとバックエンドを1つのデプロイに統合できるからです
  • Pagesは引き続き完全にサポートされており、既存のPagesプロジェクトを慌てて移す必要はありません
  • ワークフローに基づいて選びましょう。純粋なgit-pushの静的デプロイならPages、静的コンテンツと動的ロジックが混ざるものならWorkersです

Cloudflare Pagesとは

Cloudflare Pages は、gitリポジトリから直接ウェブサイトをデプロイするためのプラットフォームです。GitHubまたはGitLabのリポジトリを接続すると、Cloudflareがビルドコマンドを実行し、その出力がグローバルエッジにデプロイされます。すべてのプッシュは独自のURLを持つプレビューデプロイを得て、本番ブランチへのマージでライブサイトが更新されます。これは古典的なJamstackのワークフローです。コードをプッシュすれば、デプロイ済みのサイトが得られます。

PagesはPages Functionsを通じて動的な振る舞いもサポートします。これは内部的にはWorkersなので、ほかは静的なサイトにAPIルートやサーバーサイドのロジックを追加できます。私はまさにこのアプローチで、Cloudflare Pages上の完全なユーザー登録・ログインシステム を構築しました。これは「静的」なホストがどこまで広がれるかを示しています。

Cloudflare Workersとは

Cloudflare Workers は、サーバーレスコンピュートとサーバーレスホスティングのプラットフォームです。Cloudflareのネットワーク上で、ユーザーの近くで動くコードであり、管理すべきサーバーはありません。WorkersはAPI、ミドルウェア、エッジロジック向けの純粋な関数として始まり、プラットフォームの他の部分、R2 、D1 、KV、Queues、Workers AI に結び付きます。これらのストレージバインディングの上に構築するなら、私の無料デスクトップアプリが管理を簡単にします。Easy Cloudflare R2 、Easy Cloudflare D1 、Easy Cloudflare KV です。

2026年の重要な進展はStatic Assetsです。Workerは今や静的ファイル(HTML、CSS、JS、画像)のディレクトリを直接配信でき、Workerが動的ルートを処理します。つまり1つのWorkerでビルド済みのフロントエンドとAPIを1つのデプロイにまとめてホストでき、これは以前ならPagesとWorkersに作業を分割する必要があったものです。

Pages vs Workersで何が変わったか:Static Assets

この比較が今や意味を持つ理由は、静的アセットの機能です。これまでは、ReactやAstroのフロントエンドにバックエンドAPIがある場合、自然な分割はフロントエンド用のPagesとAPI用の別個のWorkerでした。2つのプロジェクト、2つのデプロイ、そしてつなぎ合わせるべき2つのものです。

Workers上の静的アセットでは、デプロイは一度きりです。Workerは通常のリクエストには静的ビルドを配信し、APIルートやサーバーレンダリングされたページにはコードを実行します。静的コンテンツと動的コンテンツが混ざるフルスタックのフレームワークやアプリにとって、これは構築・デプロイ・把握がより簡単です。これがCloudflareが今、新しいフルスタックプロジェクトをPagesではなくWorkersへ向ける理由です。

Pages vs Workers:横並び比較

基準Cloudflare PagesCloudflare Workers
主な目的git連携のサイトホスティングサーバーレスコンピュート + 静的アセット
静的ホスティングあり(中核機能)あり(静的アセット経由)
動的/サーバーロジックPages Functionsネイティブ
Git CI/CD + プレビュー内蔵CI連携 / Wrangler経由
バインディング(R2、D1、KV、AI)ありあり、第一級
最適な用途純粋な静的/JamstackサイトフルスタックアプリとAPI
新規構築への2026年の推奨引き続きサポート推奨

Pagesを選ぶべきとき

Pages vs Workersの判断において、Pagesは次の場合に今でも優れた選択です。

  • 純粋な静的サイトやフロントエンドフレームワークのビルドがあり、可能な限りシンプルなgit-pushのデプロイワークフローが欲しいとき
  • 何も設定せずに内蔵のCI/CDとプレビューデプロイを重視するとき
  • 動的なニーズが軽く、Pages Functionsで十分に満たせるとき
  • すでにPagesを使っていて問題なく動いているとき。とどまることに不利益はありません

Workersを選ぶべきとき

Pages vs Workersの判断において、Workersは次の場合により良い選択です。

  • 静的コンテンツに相当なサーバーサイドロジックを混ぜるフルスタックアプリケーションを構築しているとき
  • 2つの連携プロジェクトではなくフロントエンドとバックエンドを1つのデプロイにまとめたいとき
  • D1、R2、KV、Queues、Workers AIといったバインディングに大きく依存するとき
  • 2026年に新しいプロジェクトを始めていて、Cloudflareの現在の推奨経路に従いたいとき
  • ルーティング、キャッシュ、リクエスト処理をめぐるきめ細かな制御が必要なとき

Cloudflare Pages vs Workers:移行すべきか?

いいえ、反射的にする必要はありません。動いているPagesプロジェクトがあるなら、それは引き続き完全にサポートされ、移行を強いる期限もありません。具体的な理由があるときに移行しましょう。大幅なバックエンドロジックを追加する、分割されたフロントエンド/バックエンドを1つのデプロイに統合したい、あるいはWorkersが解決するPages固有の制約に直面している、といった場合です。

Pages vs Workersの選択における新規プロジェクトでは、静的アセットを用いたWorkersから始めましょう。既存で満足しているPagesのデプロイなら、本当に必要が生じるまでそのままにしておきましょう。移行の最悪の理由は目新しさであり、最良の理由はそうしなければ分割せざるを得ないフルスタックアプリを統合することです。

重要なポイント

  • Pagesは静的サイトやJamstackサイト向けのgit連携ホスティングで、CI/CDとプレビューを内蔵しています
  • Workersはサーバーレスコンピュートで、今や静的アセットも配信するため、サイト全体をホストできます
  • Static Assetsは、1つのWorkerでフロントエンドとバックエンドを一緒にホストできるようにする変化です
  • 2026年の新しいフルスタックプロジェクトには、WorkersがCloudflareの推奨経路です
  • Pagesは引き続き完全にサポートされており、具体的な理由があるときだけ移行しましょう
  • Cloudflare Pages vs Workersの判断では、純粋な静的のシンプルさにはPagesを、静的コンテンツに本物のロジックを混ぜるものにはWorkersを選びましょう

よくある質問

Cloudflare PagesとWorkersの違いは何ですか? Pagesは静的サイトとフロントエンド向けのgit連携ホスティングで、CI/CDとプレビューデプロイを内蔵しています。WorkersはCloudflareのサーバーレスコンピュートプラットフォームです。2026年に境界があいまいになったのは、Workersが今や静的アセットを配信でき、1つのWorkerでフロントエンドとバックエンドの両方をホストできるからです。

2026年の新規プロジェクトにはPagesとWorkersのどちらを使うべきですか? ほとんどの新しいフルスタックプロジェクトでは、静的アセットを用いたWorkersが今やCloudflareの推奨選択です。フロントエンドとバックエンドを1つのデプロイに統合できるからです。最もシンプルなgit-pushワークフローが欲しい純粋な静的サイトなら、Pagesは今でも優れた選択肢です。

Cloudflare Pagesは廃止されますか? いいえ。Pagesは引き続き完全にサポートされます。Cloudflareは今、新しいフルスタックプロジェクトをWorkersへ向けていますが、既存のPagesプロジェクトは動き続け、強制的な移行はありません。

Workersは静的ウェブサイトをホストできますか? はい。静的アセット機能により、WorkerはHTML、CSS、JS、画像などの静的ファイルを直接配信しつつ、コードで動的ルートも処理できます。これが1つのWorkerでサイト全体をホストできる仕組みです。

PagesとWorkersは同じバインディングを使いますか? どちらもR2、D1、KV、Workers AIといったCloudflareのバインディングを使えます。PagesはそれらをPages Functions経由で公開し、Workersは第一級として扱います。機能的には、どちらからも同じプラットフォームサービスに到達できます。

既存のPagesサイトをWorkersに移行すべきですか? 具体的な理由があるときだけです。たとえば、大幅なバックエンドロジックの追加や、分割されたフロントエンドとバックエンドを1つのデプロイに統合する場合などです。動いているPagesプロジェクトは完全にサポートされており、移す必要はありません。