Cloudflare PagesとWorkers Static Assetsの違い、エッジキャッシュが効く仕組み

結論

• 2026年3月、Cloudflare Workersの「Static Assets」機能はPagesと機能面で並び、Cloudflareは新規プロジェクトにWorkersを使うことを推奨している。既存のPagesプロジェクトも引き続きサポートされ、移行を急ぐ必要はない。
• Workers Static Assetsとして配信される静的ファイルへのリクエストは無料・無制限で、Workers本体のリクエスト課金（無料枠は1日10万件）にはカウントされない。カウントされるのは、Workerのコードが実際に実行されたリクエストだけである。
• 「Cloudflare Workersにデプロイする」といっても、ビルド時に生成した静的HTMLをアップロードするだけなら、リクエストのたびにサーバーサイドのコードが動いているわけではなく、CDNのエッジがファイルを返しているだけになる。これはCloudflare Pagesの仕組みと変わらない。
• mdx-playground（このサイト）はNuxt 3 + @nuxt/content製で、nitroのcloudflare-pages-staticプリセットで全ページを事前生成し、Cloudflare Pagesにデプロイしている。GitHub Actions経由の自動デプロイは2026年1月に無効化しており、現在は手元からwranglerで直接デプロイしている。

Cloudflare PagesとWorkers Static Assetsの関係

Cloudflare Pagesは、GitリポジトリをつないでpushするだけでビルドとCDN配信を済ませる、静的サイトホスティング専用のプロダクトとして始まった。動的な処理が必要な場合は「Pages Functions」を使うが、これは内部的にCloudflare Workersのランタイム上で動いている。

Cloudflare Workersは元々サーバーレス実行環境（Workers自体）として提供されていたが、2024年後半に静的ファイルを直接配信できる「Static Assets」機能が追加された。Cloudflare公式のPages移行ガイドによると、2026年3月時点でWorkers Static Assetsは静的ファイル配信・SSR・カスタムドメインの機能面でPagesと肩を並べており、Cloudflareは新規プロジェクトについてPagesではなくWorkersでのデプロイを推奨している。

実務上の違いを整理すると、次のようになる。

つまり、既存のPagesプロジェクトを急いでWorkersに移す理由はないが、これから新規に静的サイトをCloudflareにデプロイするなら、選択肢としてWorkers Static Assetsも並んで候補に上がる状況になっている。

静的サイトでオリジンが叩かれない仕組み

「静的サイトをCloudflareで配信すると転送量が減る」という話の実体は、CDNのエッジキャッシュとCloudflareの課金体系の組み合わせで説明できる。

キャッシュの挙動: Cloudflareは静的アセットをネットワーク全体で自動的にキャッシュする。あるエッジロケーションが最初にリクエストを受けるとそこでキャッシュされ、以降のリクエストは、オリジンまで戻らずに、階層型キャッシュ（Tiered Cache）の仕組みによって近くのキャッシュ拠点から返される。

課金の挙動: Cloudflare公式のWorkers Static Assets課金ドキュメントによると、静的アセットへのリクエストは無料・無制限で、Workers本体のリクエスト課金（無料枠は1日10万件）にはカウントされない。課金対象になるのは、サーバーサイドのWorkerコードが実際に呼び出された場合だけである。またCloudflare Pagesについても、エグレス（転送）に対する課金は発生しない。

この2つを組み合わせると、静的サイトをCloudflare上でホストする限り、リクエストの大半はオリジンサーバー（ビルド元のインフラ）まで到達せず、エッジのキャッシュとStatic Assetsの無料枠内で完結する。「転送量が大きく削減される」という体感は、この仕組みに基づいている。

なお、mdx-playgroundのapps/web/public/には_headersファイルが存在せず、Cache-Controlの明示的なチューニングはしていない。現状はCloudflareのデフォルトのキャッシュ挙動に任せている状態で、キャッシュ期間の延長やTiered Cachingの明示設定は未着手の余地として残っている。

デプロイ経路: GitHub Actionsを使う場合・使わない場合

GitHub Actionsは、CI/CDパイプラインのトリガーの一つに過ぎない。「AIで記事を作ってデプロイまで自動化する」という文脈では、GitHub ActionsのスケジュールトリガーでAIエージェントを無人起動し、記事生成・コミット・デプロイまでを人の介在なしにループさせる構成を指すことが多い。これは、開発者がClaude CodeやCodexのようなCLIツールと対話しながら記事を作る運用とは別のモデルで、「人が起動する対話型のAI」と「人手を介さず定期実行される無人のAI」という違いがある。

mdx-playgroundでは現在、GitHub Actions経由の自動デプロイを使っていない。2026年1月に、SSGビルド時のメモリ使用量がCI環境の上限を超える問題が発生したため、GitHub Actionsでの自動デプロイを無効化し、手動トリガーのみに切り替えた。現在の運用は次のコマンドで、ローカル環境でビルドしてからwranglerで直接Cloudflare Pagesにデプロイする形になっている。

pnpm deploy:cloudflare  # ローカルビルド + Cloudflare直接デプロイ

mdx-playgroundの実際の構成

このサイトはAstroではなく、Nuxt 3 + @nuxt/contentで構築されている。コンテンツのインデックスにはSQLiteを使い、スキーマはcontent.config.tsでZodにより定義している。

デプロイ先はCloudflare Pagesで、wrangler.tomlで次のように設定している。

name = "mdx-playground"
compatibility_date = "2025-10-03"
pages_build_output_dir = "./dist"

nuxt.config.tsのnitro設定ではcloudflare-pages-staticプリセットを使い、prerenderでほぼ全ページを事前生成している。

nitro: {
  preset: "cloudflare-pages-static",
  prerender: {
    crawlLinks: true,
    routes: ['/blog', '/', '/beat-monitoring', '/memory-makers'],
    // ...
  }
}

crawlLinks: trueにより、指定したルートからリンクをたどれるページも含めてビルド時にHTMLとして書き出す。結果として、リクエストごとにサーバーサイドのレンダリング処理が走ることはなく、Cloudflare Pagesは生成済みの静的ファイルを配信するだけになる。

まとめ