Cloudflare Workers

解決する課題

オリジンサーバーを常時稼働させる負担や、リージョンごとの配置・スケーリング設計の手間を避けつつ、ユーザーに近い場所で低遅延にコードを実行したい、というニーズに応えます。

• サーバーのプロビジョニングや常時起動をせずにコードを動かしたい
• ユーザーの居場所によらず低レイテンシでリクエストを処理したい
• 急なアクセス急増にも自動でスケールしてほしい
• リクエストの書き換え・認証・A/Bテストなどを既存オリジンの前段で軽量に挟みたい
• サーバーレスの実行環境とKVS/オブジェクトストレージ/DBを疎結合に組み合わせたい

主要概念と用語

• Worker: 実行単位となるスクリプト（JavaScript / TypeScript、または WebAssembly 経由で各種言語）。リクエストイベントに応答する形で動作する
• V8 Isolate: Workers の実行基盤。ブラウザのタブのように軽量な分離単位で、コンテナや仮想マシンに比べて起動が非常に速い
• ルート（Route）/ カスタムドメイン: Worker をどの URL パターンで起動させるかの紐付け設定
• バインディング（Binding）: Worker のコードから KV・D1・R2・Durable Objects・Queues・AI などの他サービスへ、環境変数のような形でアクセスするための仕組み
• wrangler: Workers のビルド・ローカル開発・デプロイを行う公式 CLI
• Cron Triggers: 一定間隔で Worker をスケジュール実行する仕組み
• Service Bindings: Worker から別の Worker をネットワークを経由せず直接呼び出す仕組み
• Durable Objects: Workers から利用できる、状態を1か所に集約して一貫性を保つコンパニオン機構（強整合が必要な処理向け）

仕様・制限・クォータ

• CPU 実行時間には上限があり、無料プランと有料プランで許容される時間が異なる（実行時間は「壁時計時間」ではなく「CPU 時間」で計測される点に注意）
• リクエスト本文やレスポンスサイズ、サブリクエスト（Worker から発行する fetch）の回数にも上限があり、プランによって差がある
• 1つの Worker スクリプトのサイズにも上限がある
• 環境変数・バインディングの数、KV/D1 などの容量やスループットは、それぞれの連携サービス側の制限にも従う
• 具体的な数値は変更されることがあるため、最新の上限は公式ドキュメントで都度確認するのが安全

内部の仕組み

Workers は仮想マシンやコンテナではなく、V8 Isolate という軽量な分離単位でコードを実行します。ブラウザが多数のタブを1プロセスで安全に分離するのと同じ技術を応用しているため、新しい Isolate の起動はミリ秒単位で完了し、いわゆるコールドスタートの影響をほとんど受けません。

• リクエストは利用者に近いエッジのデータセンターで受け付けられ、そこで Worker のコードが実行される
• 同じスクリプトの Isolate は必要に応じて多数同時に立ち上がり、水平方向に自動でスケールする
• バインディングを介して KV・D1・R2・Durable Objects・Queues などへアクセスすることで、状態やデータの永続化は専用サービス側に委ねる設計になっている
• Service Bindings を使うと、複数の Worker 間の呼び出しをインターネット経由せず内部的に完結できる

設計パターン / ベストプラクティス

• 状態は Worker 内に持たず、KV（結果整合の読み取り最適化）、D1（SQLベースの構造化データ）、R2（オブジェクトストレージ）、**Durable Objects（強整合が必要な調整処理）**など用途に応じたサービスに委ねる
• オリジンの前段に置いて、認証チェック・ヘッダー書き換え・キャッシュ制御・A/Bテストなどの軽量なエッジロジックを担わせる
• 重い処理や長時間ジョブは Worker に抱え込ませず、Queues で非同期化し後段で処理する
• 秘密情報はコードや環境変数に直書きせず、Secrets の仕組みで管理する
• 依存や初期化処理を軽くし、スクリプトサイズを抑えることでさらに実行効率を高める
• 複数の Worker にまたがる処理は Service Bindings で疎結合につなぐ

運用・監視

• ログや実行結果は Cloudflare のダッシュボードや wrangler tail によるリアルタイムログで確認できる
• 標準の可観測性機能に加え、外部の監視基盤と連携してメトリクスやログを集約することもできる
• エラー率・実行時間・リクエスト数などの推移を継続的に確認し、しきい値超過やスローダウンの兆候を早期に検知する
• デプロイはバージョン管理されており、問題が起きた場合は前のバージョンへ切り戻せる

コスト

リクエスト数と実行時間（CPU時間ベース）に応じた従量課金が基本で、一定の無料枠が用意されています。バインディングで利用する KV・D1・R2 などは、それぞれ別立てで課金される点に注意してください。

セキュリティ

• 秘密情報は Secrets の仕組みで管理し、コードやリポジトリに直書きしない
• バインディングで接続する KV・D1・R2 などへのアクセス範囲は、それぞれの権限設定で必要最小限に絞る
• オリジンへの到達経路を Worker 経由に限定し、直接アクセスを避けたい場合は WAF やアクセス制御と組み合わせる
• 入力値の検証やレート制御をエッジ側で行うことで、オリジンに届く前に不正なリクエストを弾ける
• Cron Triggers やキュー連携など自動実行の経路についても、実行権限とアクセス範囲を最小限に保つ

関連サービス・比較

ハンズオン / CLI例

Workers の作成・開発・デプロイは、公式 CLI である wrangler で行います。

# プロジェクトを新規作成（対話形式でテンプレートを選択）
npx wrangler init my-worker

# ローカルでの開発サーバーを起動し、動作を確認
npx wrangler dev

# リアルタイムログを表示して本番の挙動を確認
npx wrangler tail

# 本番環境へデプロイ
npx wrangler deploy

# シークレットを登録（値は対話プロンプトで入力）
npx wrangler secret put API_KEY