Cloudflare WorkersとPagesの違い｜新規サイトと既存サイトで選び分ける

新規のWebサイトやアプリでは、Workers Static Assetsを含む構成をまず検討できます。既存のPagesは、必要な機能と移行作業を比べて判断します。 「Pagesだから静的」「WorkersだからAPIだけ」という区分では、現在の機能を捉えきれません。

この記事では2026年10月22日時点の公式情報を基に、公開先を選ぶWeb担当者と開発者向けに違いを整理します。Pagesの終了時期を予測したり、動いているサイトへ一律に移行を勧めたりするものではありません。

どちらも静的配信と動的処理を扱える

Workersでは、HTML・CSS・JavaScript・画像などのStatic Assetsと、APIやSSRの処理を一緒に配置できます。Pagesでは静的サイトに加え、Pages Functionsでサーバー側の処理を実行できます。公式：Workers Static Assets、公式：Pages Functions

比較する点	Workers	Pages
静的ファイル	Static Assetsとして配信	ビルド成果物を配信
サーバー側の処理	Workerのコードで実行	Pages Functionsで実行
定期実行・状態管理	Cron Triggers、Durable Objectsなどを含めて構成	必要に応じて別Workerとの分担を確認
開発・配置の設定	Wrangler、フレームワークの生成設定など	Pagesのプロジェクト設定とFunctionsの構成
移行時の確認	アセットとWorkerの実行順、環境変数、ルーティング	既存の動作を比較基準として保存

静的アセットの通常リクエストは両者とも無料で、Pages FunctionsはWorkersの料金体系で課金されます。選定時は配信費用だけでなく、開発・監視・切り戻しまで比較します。公式：PagesからWorkersへの移行

新規サイトは、必要な処理から構成を決める

公開先を先に選ぶより、ページごとに「ビルド時に作れるもの」「アクセス時に処理が必要なもの」を分けると判断しやすくなります。

作りたいもの	構成を決めるときの問い
会社案内・サービス紹介	更新時にビルドすれば足りるか
記事メディア	CMSの更新をどう公開へ反映するか
問い合わせフォーム	入力の検証・保存・通知をどこで実行するか
社内ツール	全ページとAPIへ認証・権限チェックを適用できるか
会員向けアプリ	ユーザー別データを共有キャッシュへ入れない構成か

たとえば、会社案内は静的配信、フォームの受付だけWorkerという分担にできます。社内アプリでは、表示が静的でも公開してよいとは限りません。先に認証が必要なファイルを決めてください。

Next.jsを使う場合は、フレームワークの名前だけで互換性を判断せず、Next.jsをWorkersで動かす条件で採用する実行方式を確認します。

既存Pagesは、移行で得たいものを一つ決める

すでにPagesで問題なく運用しているサイトなら、移行理由を具体的にします。定期処理を追加したい、アプリとAPIの管理をまとめたい、Workersの観測機能を使いたい、といった理由です。

移行判断は「Workersで表示できたか」ではなく、「必要な機能が増え、今の業務も保てるか」で行います。

移行対象の一覧には、HTMLだけでなく次を含めます。

• ビルドコマンド、出力先、使用するフレームワークとアダプター
• Functionsのルーティング、認証、ミドルウェア
• リダイレクト、応答ヘッダー、404、SPAの直リンク
• 本番・検証用の環境変数、Secrets、DB・ストレージ接続
• 独自ドメイン、アクセス制限、計測、通知先

これが比較表になります。旧環境を残したまま検証用のWorkerを用意し、同じURLパスと操作で差を確認します。

移行で変わりやすい四つの設定

1. ビルド成果物の場所

Pagesの出力ディレクトリは、Workersでは通常 assets.directory へ対応させます。フレームワークを使う場合は生成される設定を優先し、手書きの値で上書きしないようにします。

純粋な静的サイトで、成果物が dist にある場合の最小例は次のとおりです。

{
  "name": "company-site-preview",
  "compatibility_date": "2026-10-22",
  "assets": {
    "directory": "./dist",
    "not_found_handling": "404-page"
  }
}

これはSSRアプリや認証付きサイトをそのまま動かす設定ではありません。SPAなら not_found_handling の選択が変わります。存在しないURLがすべて200にならないか、直接URLを開いても画面へ到達するかを確かめます。公式：アセットのHTML処理

2. アセットと認証処理の実行順

Workersは、設定によっては静的アセットをWorkerより先に返します。認証処理をWorkerへ移しただけで、全ファイルを保護できるとは限りません。

保護対象では assets.run_worker_first などのルーティング設定を確認し、未ログインの状態からHTML・API・ダウンロードURLを直接開きます。Pagesの _routes.json やミドルウェアの挙動も照合します。公式：移行時の実行順

3. ビルド時と実行時の値

画面を作るときに使う値と、リクエストを受けたときに使う値は別です。Workers Buildsのビルド環境と、Workerの実行環境へ必要な値をそれぞれ設定します。

APIキーをクライアント向け環境変数へ入れないこと、検証環境が本番DBを参照していないことも確認します。秘密情報は公式のSecrets管理に従って登録します。

4. ドメインと転送

検証用URLでの成功後に、独自ドメインを切り替えます。元サイトのHTTP→HTTPS、www有無、古い記事URL、クエリ付きURLを確認し、転送ループや意図しない404を探します。DNSの移管も伴う場合は、DNS切り替えの確認項目を別作業として扱います。

切り替え前に、同じ操作で新旧を比べる

確認対象	合格条件の例
主要ページ	内容・タイトル・画像・内部リンクが一致する
404とSPA	不明なURLと正規の直リンクを区別できる
認証	未ログイン・権限なしの利用者が保護情報へ入れない
フォーム	検証データが保存され、通知結果まで追える
キャッシュ	更新が反映され、利用者固有データが共有されない
運用	ログを確認でき、旧環境へ戻す担当と手順が決まっている

フォームを新旧両方から同時に使える状態にすると、受付が二重になることがあります。切り替え中の入力先とデータの正本を決めます。公開先を戻すだけで、移行中に更新されたDBまで戻るわけではありません。

よくある質問

Pagesからすぐ移行しないといけませんか？

この記事では一律の期限を設けません。現在の公式案内、必要機能、既存運用を確認し、移行の効果と作業量を比べて決めます。

静的サイトだけならWorkersは大げさですか？

Workerのサーバーコードを持たず、Static Assetsのみを配置する構成もあります。将来のAPI追加だけでなく、今の更新方法と保守担当者が扱えるかも判断材料です。

移行すれば料金は下がりますか？

静的配信と動的処理で似た料金構造がありますが、経路・キャッシュ・関連サービスによって利用量は変わります。Workersの料金試算に新旧の構成を当てはめて比較してください。

次に読む記事

• Workersの料金と無料枠を試算する
• Next.jsをWorkersへ公開する手順と互換性
• Cloudflareの主要サービスを整理する

公式情報の確認日：2026年10月22日。設定例は説明用です。利用するフレームワークと環境に合わせて検証してください。