Cloudflare Workersは「エッジ全部入りプラットフォーム」になった
Cloudflare Workersは数年前まで「軽量なエッジ関数」というポジションでしたが、Durable Objects（状態保持）・D1（SQLite）・R2（S3互換ストレージ）・Vectorize（ベクトル検索）・Queues・AI Gateway などが加わり、フルスタックアプリをエッジだけで完結できるようになりました。Vercel/AWSとは違う「エッジファースト」設計思想で考える必要があります。
Workersが向くワークロード5選
- 世界中のユーザーに低遅延で配信するAPI（地理分散が前提）
- 画像変換・リクエスト書き換えなどのレスポンス加工
- イベント駆動の軽量処理（Webhook受け→Queues→非同期処理）
- SaaSの認証ゲートウェイ・レートリミット
- LLMのAI Gateway経由でのプロキシ・キャッシュ層
避けた方が良いワークロード
長時間計算（CPU 30秒制限）、大容量メモリが必要な処理（128MB制限）、複雑なPostgreSQLトランザクションが中心の処理は不向き。これらはAWS Lambda+RDSやコンテナで書いた方が素直です。
主要コンポーネントの役割
- Workers: V8 Isolatesで動くJavaScript/TypeScript/WASM。コールドスタートほぼゼロ
- Durable Objects: シングルトンな状態を持つアクター。チャット・ゲームのルーム単位状態に最適
- D1: 分散SQLite。読み書きが中規模までの小〜中サイズアプリ向き
- R2: S3互換オブジェクトストレージ。エグレス無料が最大の差別化要因
- Vectorize: ベクトルDB。RAGアプリのエッジ実行に使える
- Queues: 非同期メッセージング。バッチ処理・リトライ制御に
実装で詰まりやすい3つの罠
- Node.js互換のギャップ:
node:fs等は使えない。nodejs_compatフラグで一部使えるが完全ではない - Durable Objectsのロック: 同一IDへの並列リクエストは直列化される。設計時にホットスポットを避ける
- D1の同時書き込み: SQLiteの特性上、書き込みは1スレッド。大量書き込みはバッチ化必須
CI/CDとデプロイ戦略
Wrangler CLIでローカル開発、GitHub Actions＋wrangler deployでCD化が標準。本番・ステージング環境はenvironment機能で分離し、シークレットはwrangler secretで管理します。プレビューデプロイ（PR単位）も標準対応しており、Vercel的なフローが組めます。
料金感（実務目安）
- Workers Free: 1日10万リクエスト・10ms CPU/req
- Workers Paid: 月$5から、1000万req込み
- R2のエグレス無料は大規模配信で月数百ドルの節約になることもある
関連リンク
サーバーレスの全体像は サーバーレスツール選び方、エッジ環境でのフロント設計は Next.js深掘り、AIアプリのエッジ実行は RAG構築 を参照してください。インフラ系のキャリア設計は SREのキャリア もどうぞ。