Cloudflare 上で Web サイトを公開する方法を調べると、Cloudflare Pages と Cloudflare Workers という2つの名前が出てきます。
Pages は静的サイトを公開するサービス、Workers はプログラムを動かすサービス、と説明されてきました。
しかし現在は、Workers でも HTML、CSS、画像などの静的ファイルを配信できます。そのため、これから新しくサイトを作る方だけでなく、すでに Pages を使っている方も「今後は Workers を選ぶべきなのか」「既存サイトも移行した方が良いのか」と迷いやすくなっています。
2026年9月28日の確認時点では、Cloudflare は新しいプロジェクトに Workers を推奨しています。ただし、Pages が利用できなくなったわけではありません。既存の Pages サイトが問題なく動き、必要な運用もできているなら、推奨先が変わったという理由だけで急いで移行する必要はないでしょう。
この記事では、Pages と Workers の役割、共通点、違いを初心者向けに整理します。そのうえで、新規制作、既存 Pages サイトの維持、Workers への移行という3つの場面に分けて、現在の選び方を考えます。
現在の結論を先に整理する
判断の出発点は、次のように整理できます。
| 現在の状態 | 基本的な考え方 | 次に確認すること |
|---|---|---|
| これから新しく作る | Workers Static Assets を起点に検討する | 使用する制作ツールやフレームワークが Workers に対応しているか |
| 既存の Pages サイトが問題なく動いている | Pages のまま維持する選択肢がある | 必要な機能、更新手順、保守体制を維持できるか |
| Workers の機能が必要になった | 移行の目的と影響を確認して検討する | Functions、ルーティング、変数、独自ドメインなどを移せるか |
Cloudflare の Pages 公式ページ には、Workers が Pages の多くの用途に対応し、より広い機能を持つ主要なアプリケーション基盤になったため、新規プロジェクトは Workers から始めるよう案内があります。
さらに、Workers のベストプラクティスでは、静的サイト、シングルページアプリケーション、フルスタックアプリケーションを公開する推奨方法として Workers Static Assets が挙げられています。同時に、Pages は引き続き動作するものの、新機能と最適化は Workers に重点が置かれると説明されています。
ここで大切なのは、公式の推奨先と、今動いているサイトを移行する判断を分けることです。新規制作で Workers を選ぶことと、既存の Pages サイトを直ちに移すことは、同じ判断ではありません。
Pages と Workers は何をするサービスなのか
違いを比べる前に、それぞれの役割を確認しておきましょう。
Cloudflare Pages
Cloudflare Pages は、Web サイトの制作ファイルを Cloudflare のネットワークへ配置し、公開するサービスです。GitHub や GitLab などの Git プロバイダーと連携して更新を自動公開したり、完成したファイルを直接アップロードしたりできます。
Git は、ファイルの変更履歴を記録する仕組みです。Git プロバイダーは、そのファイルと変更履歴をオンラインで保管し、制作や公開の流れと連携できるサービスを指します。
Pages は、HTML、CSS、JavaScript、画像などを中心とした静的サイトを公開できます。静的サイトとは、アクセスのたびにデータベースからページを生成するのではなく、あらかじめ用意したファイルを中心に表示するサイトです。
Pages Functions を加えると、フォームの受付や外部サービスとの通信など、閲覧者からの要求に応じた処理も実装できます。Functions は、専用サーバーを自分で管理せずに、必要なプログラムを実行する仕組みです。
Cloudflare Workers
Cloudflare Workers は、Cloudflare のネットワーク上でプログラムを実行できるサーバーレスのプラットフォームです。サーバーレスとはサーバーが存在しないという意味ではなく、利用者が個別のサーバーや OS を用意し、その稼働を管理する負担を減らせる提供方法です。
Workers では、Web ページを返す、API を提供する、外部サービスと通信する、アクセスに応じて表示を変えるといった処理を実装できます。API は、異なるシステム同士がデータや機能をやり取りするための窓口です。
さらに、Workers Static Assets を使うと、プログラムだけでなく HTML、CSS、画像などの静的ファイルも Workers のプロジェクトとして配信できます。プログラムが不要な静的サイトなら、Worker のスクリプトを書かずにファイルだけを公開することもできます。
Pages と Workers の共通点
Pages と Workers は別々の名前ですが、現在は対応できる範囲が大きく重なっています。
主な共通点は次の通りです。
- Cloudflare のネットワーク上で Web サイトを公開できる
- HTML、CSS、JavaScript、画像などの静的ファイルを配信できる
- 独自ドメインを設定できる
- 公開前の表示を確認するプレビュー環境を用意できる
- Git と連携したビルド・公開の流れを構築できる
- 静的ファイルだけでなく、サーバー側の処理を組み合わせられる
- 以前の公開状態へ戻すロールバックを利用できる
ビルドは、制作中のファイルを公開用の形式へ変換する工程です。プレビュー環境は、本番公開前の内容を別の URL で確認する仕組みです。ロールバックは、問題が起きたときに以前の状態へ戻す操作です。
このように共通点が多いため、「静的サイトなら必ず Pages、動的な処理があるなら必ず Workers」とは分けられなくなっています。
Pages と Workers の主な違い
現在の違いは、単に「ファイルを置くサービス」と「プログラムを動かすサービス」というより、今後の開発基盤としての位置づけや、設定方法、利用できる機能の広さにあります。
| 比較する点 | Pages | Workers |
|---|---|---|
| 2026年9月時点の位置づけ | 既存プロジェクトを含め、引き続き利用できる | Cloudflare が新規プロジェクトに推奨する主要基盤 |
| 静的ファイル | Pages プロジェクトとして公開する | Static Assets として Worker と一緒に、または静的ファイルだけで公開する |
| サーバー側の処理 | Pages Functions を使う | Worker のコードや対応フレームワークを使う |
| 機能の広さ | Pages 向けの公開・運用機能を利用する | Durable Objects、Cron Triggers、より広い監視機能などを利用できる |
| 設定 | Pages が構成を判断する部分がある | wrangler.jsonc などで明示的に設定する項目がある |
| 独自ドメイン | Cloudflare 外で DNS を管理するドメインにも対応する | 独自ドメインには、DNS を Cloudflare で管理するドメインを使う |
| 今後の新機能・最適化 | Pages は継続して動作する | Cloudflare は Workers に重点を置くと案内している |
Durable Objects は、複数のアクセス間で状態を共有する処理に使える仕組みです。Cron Triggers は、決めた時刻や間隔で Worker を動かす仕組みです。どちらもすべてのホームページに必要な機能ではありません。
Workers の方が利用できる機能は広いものの、機能が多いことだけで最適な選択になるわけではありません。既存の Pages サイトに必要な機能がそろい、更新や障害対応の流れも確立しているなら、使わない機能のために移行作業を増やさない判断もあります。
また、Pages にしかない、または Workers では代替方法が必要な機能もあります。Cloudflare の移行ガイドには機能ごとの互換表が用意されているため、個別のサイトでは最新の表を確認してください。
新しく作るなら Workers を起点に検討する
これから新しくサイトやアプリケーションを作る場合は、公式方針に沿って Workers Static Assets を起点に検討するのが自然です。
Workers Static Assets では、静的ファイルと Worker のコードをひとつのプロジェクトとして公開できます。最初は静的ファイルだけで公開し、あとから API や認証などの処理を追加する構成も考えられます。
ただし、Cloudflare が Workers を推奨しているからといって、すべてのサイトを Cloudflare 上で作る必要はありません。
- 更新担当者が管理画面から記事を投稿したい
- 使用予定の CMS や制作ツールが別の公開環境を前提としている
- 制作後に誰がコードと設定を保守するか決まっていない
- 利用するフレームワークが Workers にどう対応するか確認できていない
- 別のホスティングサービスですでに安定した運用ができている
このような場合は、WordPress、別の CMS、ほかのホスティングサービスも含めて比較した方が良いでしょう。技術的に公開できることと、運営者が無理なく更新・保守できることは別だからです。
既存の Pages サイトは、問題がなければ維持できる
すでに Pages で公開しているサイトについて、Cloudflare は「Pages が利用できなくなる」とは案内していません。公式のベストプラクティスにも、Pages は引き続き動作すると明記されています。
そのため、次のような状態なら Pages を維持する選択肢があります。
- 現在の表示や機能に問題がない
- 更新から公開までの手順が定着している
- Pages Functions を含め、必要な機能が動いている
- 担当者が現在の構成を把握している
- Workers 固有の機能を必要としていない
- 保守や障害対応に困っていない
一方で、現在動いているから何も確認しなくて良いわけではありません。利用しているフレームワークやパッケージの更新、ビルド環境、独自ドメイン、Pages Functions、変数やシークレットの管理状況は定期的に確認したいところです。
シークレットは、API キーやトークンなど、公開してはいけない認証情報です。ソースコードや一般公開されるファイルへ書かず、Cloudflare が用意する安全な保存方法で管理します。
僕は、基盤の推奨先が変わったときほど、「新しい方へ移すこと」を目的にしない方が良いと考えています。今困っていること、今後必要になる機能、移行後の管理者を先に整理し、移行によって運用がどう良くなるのかを説明できる状態で判断したいところです。
Workers への移行を検討したい状態
既存の Pages サイトでも、次のような目的がある場合は Workers への移行を検討できます。
- Workers に集約し、設定や公開方法を統一したい
- Workers で提供される機能を利用したい
- 静的ファイルと API などの処理を同じプロジェクトで管理したい
- 新しい開発環境やフレームワークへ更新する予定がある
- 今後の機能追加を Workers を前提に進めたい
- 現在の Pages 構成を見直す時期に来ている
ただし、移行は保存先の名前を変えるだけではありません。Cloudflare の公式移行ガイドでは、少なくとも次の項目が確認対象になっています。
- 使用中のフレームワークと Workers 向けの設定
wrangler.jsoncなどのプロジェクト設定ファイル- 静的ファイルの出力先と配信方法
- Pages Functions と Worker のコード
- どの要求を静的ファイルと Worker のどちらで処理するかというルーティング
- 環境変数、シークレット、Cloudflare サービスとの接続設定
- Git 連携、ビルド、プレビュー環境
pages.devからworkers.devまたは独自ドメインへの切り替え- 本番公開後の動作確認と、問題があった場合の戻し方
環境変数は、公開環境やテスト環境によって変わる設定値を、コードから分けて管理する仕組みです。ルーティングは、アクセスされた URL に応じて、どのファイルやプログラムへ処理を渡すかを決める設定です。
Pages では自動的に判断されていた配信方法を、Workers では明示的に設定する部分があります。また、Pages Functions を使っている場合は、Workers 向けのコードやフレームワーク設定への変更が必要になることがあります。
独自ドメインの条件にも注意が必要です。公式移行ガイドでは、Workers の独自ドメインには、ネームサーバーを Cloudflare で管理しているドメインが必要だと説明されています。Pages で Cloudflare 外の DNS を使っている場合は、移行前にドメイン管理への影響も確認します。
移行前には、現在の Pages プロジェクトをすぐ削除せず、新しい Workers 側で表示、フォーム、認証、リダイレクト、独自ドメインなどを確認します。 本番のアクセスを移したあとも問題がないことを確認してから、旧プロジェクトの扱いを決めます。
自分で確認できる範囲
移行作業を始める前に、まずは現在の構成と目的を確認してみてください。この段階では、Pages プロジェクトを削除したり、独自ドメインを付け替えたりする必要はありません。
- 新しく作るサイトか、すでに Pages で動いているサイトか
- 現在のサイトに困っていることがあるか
- Pages Functions を使っているか
- 使用しているフレームワークや制作ツールは何か
- Git のリポジトリと公開手順を把握しているか
- 独自ドメインと
pages.devのどちらを使っているか - 環境変数、シークレット、外部サービスとの接続があるか
- フォーム、ログイン、検索、リダイレクトなど、止めたくない機能は何か
- 公開後に誰が更新と保守を担当するか
Cloudflare の管理画面だけでなく、制作ファイル、Git のリポジトリ、ドメイン、外部サービスの契約情報も確認します。分からない項目は、推測で設定を変更せず「不明」として記録しておくと、相談時の確認項目になります。
制作者へ相談した方が良い状態
次のような場合は、Cloudflare と使用中の制作環境を確認できる制作者へ相談した方が良いでしょう。
- Pages Functions や
_worker.jsを使っているが、役割が分からない - 使用中のフレームワークを Workers 向けに変更できるか判断できない
- フォーム、認証、決済、会員機能など、止められない処理がある
- 環境変数やシークレットをどこで管理しているか分からない
- 独自ドメインや DNS の切り替えによる影響を判断できない
- Pages 固有の機能を Workers でどう置き換えるか分からない
- テスト環境や、問題が起きたときに元へ戻す手順を用意できない
- 制作会社や以前の担当者から十分な資料を引き継げていない
Pages や Workers だけでなく、Git、フレームワーク、ドメイン、外部サービスを含めて確認する必要があります。大規模なシステムや社内ネットワーク、契約上の要件が関係する場合は、それぞれの担当者や専門事業者にも確認してください。
相談前に用意しておきたい情報
相談時には、次の情報が分かる範囲でまとまっていると、確認を始めやすくなります。
- 対象サイトの URL
- 新規制作、既存 Pages の維持、Workers への移行のどれを検討しているか
- 現在困っていることと、実現したいこと
- Cloudflare アカウントの管理者
- Git リポジトリの保管場所と管理者
- 使用中のフレームワーク、ビルド方法、公開手順
- Pages Functions、外部 API、データベースなどの利用状況
- 独自ドメイン、DNS、メールの管理状況
- 希望する時期と、停止を避けたい時間帯
- 仕様書、設定ファイル、過去の作業記録
問い合わせフォームへ、パスワード、API トークン、シークレットの値を記載しないでください。認証情報が必要になった場合は、相談後に安全な共有方法を確認してから渡します。
まとめ
2026年9月28日時点で、Cloudflare は新規プロジェクトに Workers Static Assets を推奨しています。Workers では、静的ファイルだけのサイトから、API などの処理を組み合わせたサイトまで、ひとつの基盤で構築できます。
一方で、Pages は利用できなくなったわけではありません。既存の Pages サイトが安定して動き、必要な機能と運用体制がそろっているなら、Pages のまま維持する選択肢があります。
Workers への移行は、必要な機能や運用上の目的があり、設定、Functions、ルーティング、変数、独自ドメインなどを確認できるときに検討します。新しい方を選ぶことではなく、新規制作と既存運用を分け、今後も無理なく管理できる方法を選ぶことが大切です。
新規サイトの公開方法や、既存 Pages サイトを維持・移行する判断を整理したい場合は、対象サイトの URL、現在の構成、実現したいことを分かる範囲でまとめて、お問い合わせフォームからオレインデザインへご相談ください。個別の対応可否は、使用中のフレームワークや機能、必要な確認範囲を伺ったうえで判断します。
