Workers

スタンドアロン Cloudflare Workers と Wrangler 設定

Cloudflare Workers はエッジで実行されるサーバーレス関数。スタンドアロンのサービスとしても、Pages プロジェクトの一部（Pages Functions として）としても使用できる。

Workers と Pages Functions の比較

スタンドアロン Workers を使うべき場合

以下のような場合にスタンドアロン Workers を使用する：

• 関数が独立したサービスの場合（例：検索ワーカー、AI チャットワーカー）

• カスタムドメインやルーティングが必要な場合

• 静的サイトとは独立したリリースサイクルが必要な場合

• Pages Functions では利用できない機能が必要な場合

このセクションの内容

• Wrangler 設定 -- 設定ファイルのフォーマットとオプション

• スタンドアロン Workers -- 独立した Workers のデプロイ

• 互換性日付 -- 互換性日付の理解と管理

• Durable Objects -- WebSocket Hibernation と SQLite バックの Durable Objects

• 静的アセット -- [assets] バインディング、run_worker_first、プレビュー URL の落とし穴

• ハッシュ付きアセットのブラウザキャッシュ -- コンテンツハッシュ付きバンドル向けの _headers immutable ルール、103 Early Hints、CSS 全文インライン化が誤った対処である理由

• ゼロからのデプロイ -- リポジトリベースの Worker をゼロからプロビジョニングする際の非自明な罠

• ローカル開発: バインディング対応表 -- wrangler dev でどのバインディングがローカルエミュレートされるか、クレデンシャル不要な e2e 用の設定パターン

• ランタイムの落とし穴 -- self-fetch のホスト名、ストアされた fetch レスポンス、waitUntil / scheduled の予算、バインディングをラップするライブラリ、cloudflare:workers のアンビエント env、CORS と WebSocket

• Pages から Workers への移行 -- 最小限のダウンタイムで Pages から Workers Static Assets へライブサイトを移行し、うまくいかなかった場合にきれいにロールバックする

• Workers Cache（ctx.cache） -- エッジレベルの cache.enabled / ctx.cache 機能 -- バージョンの下限、Cache-Control/Cache-Tag/Vary、ctx.cache.purge のスコープ、Cf-Cache-Status、Next.js の ISR をめぐる論点、そして検証がデプロイ済み Worker に対してしか成立しない理由