Architecting on Cloudflare

開発者プラットフォームの意思決定・トレードオフ・パターン。
"なぜそれを選ぶのか" を、構造から理解する。

Jamie Lord 著「Architecting on Cloudflare」(2026年5月版) より  ·  導入判断のためのリファレンス

アジェンダ

00 哲学
まず Cloudflare から始め、使わない理由を探す I Foundation — 構造的な違い
Isolate・グローバル既定・Binding・メンタルモデル II Core Compute — Workers
CPU 時間課金の経済性・Service Bindings III Stateful Systems
DO・Workflows・Queues・Containers・Realtime IV Data & Storage
ストレージ選択マトリクス・R2 の Egress ゼロ V The AI Stack
統合バインディング・RAG・エージェント VI Production
TCO・可観測性・セキュリティ VII–VIII Decisions & Migration
適合判断・失格条件・移行プレイブック

この資料の位置づけ — 中立的な技術評価

出典

独立系の技術書「Architecting on Cloudflare」(Jamie Lord 著)。Cloudflare 非公式・無関係。著者は Cloudflare パートナー所属だが、本書は商業的義務ではなく技術的評価に基づく。

なぜ提案・評価に役立つか

マーケ資料ではなく限界・失敗閾値・ハイパースケーラが優位なシナリオまで率直に記述。顧客に正直に伝えられる内容で、提案の説得力と信頼を高める。

対象範囲: 開発者プラットフォーム(Workers / Durable Objects / D1 / R2 / Queues / Workflows / Containers / Realtime / AI スタック)。WAF・DDoS・Zero Trust 等のセキュリティ／ネットワーク製品は範囲外。

想定読者: CTO・アーキテクト・リードエンジニア — クラウドアーキテクチャの素養を前提に、別のアプローチを評価する人。

Philosophy

まず Cloudflare から始め、
"使わない理由" を探す

移行する理由を探すのではなく、不採用の理由を探す。評価のデフォルトを逆転させる視座。

経験則 — 評価のデフォルトを逆転させる

他のプラットフォームから始めて移行する理由を探すのではなく、まず Cloudflare から始めて、それを使わない理由を探すべきだ。 — Jamie Lord, Architecting on Cloudflare

Cloudflare から始める

グローバル配信・即時スケール・ゼロコールドスタート・統合セキュリティがデフォルトで手に入る。制約は明示的・文書化済みで、自社ワークロードに当たるかすぐ分かる。

ハイパースケーラから始める

不要な制約を回避する設計と、管理不要だったはずの複雑さに対価を払う。評価する頃にはスイッチングコストが積み上がっている。

提案における示唆

プロトタイプ起点

新規案件は "慣れた AWS" ではなく Cloudflare で1週間試作し、ハード制約に当たるか検証。ブロッカーを早期に発見できる。

TCO で語る

単価ではなく総コスト。Egress・NAT ゲートウェイ・CPU 課金の観点で語ると、差が明確になる。

率直さが信頼に

不適合シナリオを先に提示することで提案の信頼性が上がる。"合わなければ別の選択も妥当"。

本資料は ① 全体像 → ② プリミティブ別の強み・数値 → ③ 適合／不適合の判断軸 の順で、提案の引き出しを揃えることを目的とする。
Part I · Foundation

何が "構造的に" 違うのか

メンタルモデルを揃える。以降すべての土台になる4つの前提。

V8 Isolate モデル — コールドスタートの消滅

Workers は VM でもコンテナでもなく、Chrome の JS エンジンと同じ V8 isolate(既存プロセス内の軽量サンドボックス)で実行される。

<5ms
Isolate 生成
(Lambda: 100ms–1s+)
128MB
メモリ上限
(変更不可・ハード)
5分
最大 CPU 時間
(既定30秒)
330+
都市に同時展開
(100+ カ国)
経済性の逆転 — CPU 時間課金: 課金対象は実 CPU 時間のみで I/O 待機は無料。外部 API 応答を2秒待っても計算が20msなら、20msで完了する処理と同コスト。Lambda は "待ち" も課金する。

プロビジョンド・コンカレンシーや keep-warm といったコールドスタート対策のカテゴリが丸ごと不要になる。

Global by Default — リージョン選択が存在しない

デプロイすると全データセンターに同時展開。リージョンのドロップダウンは無い。サンパウロのユーザーはサンパウロに、シンガポールはシンガポールに着地する。

マルチリージョンのレプリケーション・フェイルオーバー・整合性管理という数週間のエンジニアリングが "既定動作" になる。

Smart Placement

バックエンドへ複数回呼び出す場合、ユーザー近接ではなくバックエンド近接に自動配置し、総レイテンシを最小化。

コンプライアンス対応

グローバルが既定。制約は "特定地域に限定する" 方向のオプトイン。

  • Durable Objects: jurisdiction=eu で実行・保存を EU 内に限定(グローバルアクセスは維持)
  • Regional Services: ステートレス Worker の処理地域を制限

→ 規制ワークロードを "拡張" ではなく "限定" で実現。

Binding モデル — 接続文字列も認証情報も無い

worker.ts 
export default {
  async fetch(req, env) {
    // env.DB = D1, env.STORAGE = R2,
    // env.CACHE = KV — 設定で実体が決まる
    const r = await env.DB
      .prepare("SELECT * FROM users").all();
    const f = await env.STORAGE.get("config.json");
    return Response.json(r);
  }
};

設定であってコード化ではない

本番／開発／テストでコードを変えずに実体を切替。資格情報の誤コミットが構造的に起きない。

ネットワーク越えなし 0.1–0.5ms

バインド資源呼び出しはインターネットを経由せず、多くは同一マシン内。RPC 的な呼び出し。

設計で SSRF 免疫

内部サービスは URL で到達不能(env.SERVICE 経由のみ)。攻撃面そのものが存在しない。

メンタルモデルの転換

ハイパースケーラの問いCloudflare では
"どのリージョンに置く?"問いが消える — 全箇所に自動配置。制約は地域限定のみ
"インスタンス数は?"問いが消える — 設定なしで自動スケール(上限キャップも無い)
"コネクションプールの調整は?"ネイティブ資源はバインディングが吸収。外部 DB は Hyperdrive
"コールドスタート対策は?"不要 — 既定で sub-5ms。warm-ping／プロビジョニングは過剰
水平スケールが第一原理: D1 は1DB 10GB だが 5万DB／アカウント。Durable Objects は "数百万の小さなオブジェクト" を想定。問いは "どう大きくするか" から "どう正しくシャードするか" へ。
Part II · Core Compute

Workers — すべての土台

Durable Objects も Workflows も Queues も Containers も、Workers の上に建つ。

Workers の経済性 — "待ち" の対価を払わない

典型的な API(JWT 検証 + D1×2 + 外部 API + 整形)の内訳:

Workers

CPU 時間 ≈15ms のみ課金。待機の205msは無料。I/O 主体のワークロード(大半の API／Web／統合層)で劇的に有利。

Lambda (512MB)

壁時計 220ms ぶん課金。93%は待機。"計算" ではなく "存在" に課金される。

逆もまた真: 計算主体(データ変換・暗号・大規模処理)では両モデルは拮抗、または Lambda 優位。Workers は Web ワークロードの common case に最適化。サブリクエスト 既定10,000 → 最大1,000万

Service Bindings — ネットワークなしのマイクロサービス

Worker 間を型安全な RPC で接続。同一ロケーション実行なら1ms 未満。DNS・接続確立・シリアライズ・TLS が無く、失敗は "相手 Worker の失敗" のみ。

通信レイテンシ
Service binding(同居)0.1–0.5ms
Service binding(別所)1–5ms
外部 HTTP(同一地域)20–50ms
外部 HTTP(地域跨ぎ)100–300ms

分割の判断

まずは単一 Worker から。分割は安いが無料ではない。

  • デプロイ独立性が必要なとき
  • リソースプロファイルが大きく異なるとき
  • チーム境界がサービス境界と一致するとき
  • 複数入口で機能を共有するとき(認証など)

流行で分割しない。20回の binding 呼び出しはモノリスより遅い。

Part III · Stateful Systems

ここが "本当に面白い"

他クラウドに等価物が無い、協調プリミティブ群。

Durable Objects — 最大の差別化

グローバル一意の ID + 専有 SQLite を持つ "コードを実行できる DB の行"。AWS に等価物なし・Azure は複数サービスの組合せ・GCP は無い。

10GB
SQLite／オブジェクト
32,768
WebSocket／オブジェクト
~1,000
req/秒(単一 DO 上限)
30日
ポイントインタイム復元

適合

リアルタイム協調(チャット／共同編集=1ドキュメント1DO)、レート制限、リーダー選出、ゲームセッション、プレゼンス。出力ゲーティングで線形化可能な強整合を設定ゼロで。

非適合・注意

読み取り主体で陳腐化許容→KV。協調なしのリレーショナル→D1。"神オブジェクト" は ~1,000 RPS で詰まる。移行の逃げ道が無い=最大のロックイン。

Workflows — 耐久実行(Durable Execution)

TypeScript で書き、プラットフォームがリプレイ・チェックポイント・ステップ永続化を担う。失敗しても最後の完了ステップから再開(各ステップ exactly-once 成功)。

キラー機能 step.sleep()

日〜週単位の待機をハイバネートしながら限界コストゼロで。Step Functions は同じ待機に状態遷移課金。waitForEvent() で人間承認／Webhook も。

50,000
同時インフライト／アカウント
300/s
インスタンス生成レート
1 MiB
ステップ結果上限
週
最大実行期間

非適合: 独立・冪等タスク → Queues(安い)。リアルタイム状態照会・WebSocket → DO 直接。決定性と冪等性が必須。

Queues — 非同期処理の脱結合

"あとでやる"。Worker プロジェクト内のバインディングで、別サービス設定が不要。プロデューサは即返し、コンシューマが後で処理。

項目値
メッセージ上限128 KB(超過分は R2 参照)
スループット~5,000 msg/秒／キュー
コンシューマ wall time15分
配信保証at-least-once のみ

必ず冪等に

メッセージは再配信される。順序保証・exactly-once は無い。DLQ を必ず構成し、バックログ深さ・エラー率を監視。

SQS／Service Bus との差

運用が単純(IAM／可視性タイムアウト不要)。一方で FIFO／順序保証なし・128KB 上限。ステータス追跡や補償を足し始めたら → Workflows の出番。Pull 型 API で K8s／レガシーからも消費可。

Containers — V8 の制約を超えるとき

第一の論点: Workers は "考えること(CPU 時間)" に、Containers は "存在すること(壁時計)" に課金。I/O 主体だと 100〜500倍高くなる(例: 同一処理が Workers $0.20/月 vs Containers $100/月)。

Containers が必要なとき

  • メモリ >128MB(最大 12GB)
  • CPU >5分(時間制限なし)
  • 非 JS ランタイム(Go／Java／.NET／Ruby)
  • ディスク必要(最大 20GB)

各インスタンスは Durable Object が制御(DO=頭脳、Container=筋肉)。

限界・非適合

  • コールドスタート 3〜15秒 → 対話型に不適
  • >4 vCPU／12GB → ハイパースケーラへ
  • インバウンド TCP/UDP 不可(HTTP 経由のみ)

再設計が1週間未満かつ月1万回以上なら、Workers 化が回収早い。

Realtime — エッジの音声・映像(WebRTC)

2種類のリアルタイム: データ(テキスト／JSON)は DO + WebSocket。メディア(音声／映像)は Cloudflare Realtime(WebRTC/UDP)。

Anycast SFU が差別化

SFU を300+拠点で実行。各参加者が最寄りに接続し "SFU をどこに置くか" のトレードオフが消滅。AWS Chime 14拠点／Azure 18／Twilio 7。

項目値
SFU／TURN 帯域課金$0.05/GB
無料枠1,000 GB／月
最大参加者1,000(Chime 250／Twilio 50)
録画R2 へ組込(SDK)

非適合: PSTN 電話発着信なし → Chime／Twilio。FedRAMP／HIPAA 要件は要確認。"リアルタイム" が単なるテキストなら DO+WebSocket が安い。

Part IV · Data & Storage

正しいストレージが、
アーキテクチャの "歌か苦悩か" を決める

"大きな1つ" ではなく "小さな多数" を選ぶ。

ストレージ選択 — "大きな1つ" より "小さな多数"

ニーズ選択理由／数値
読み取り主体・陳腐化 OKKVsub-10ms グローバル／結合的整合(〜60s 伝播)
リレーショナル・新規D1SQLite・強整合・1DB 10GB／5万DB でシャード
既存 PG/MySQL + 運用Hyperdrive接続プール+地理短縮(Sydney→us-east 600→50ms)
協調・カウンタ・レート制限Durable Objects単一スレッドで競合を排除・線形化可能
ファイル・blob・メディアR25TB／オブジェクト・Egress 無料
ベクトル／意味検索Vectorize1536次元・1000万ベクトル／インデックス

判断順序 ①アクセスパターン ②整合性(read-after-write が要るなら KV を除外) ③協調の要否。"Hyperdrive で既存 Postgres" は恒久的に妥当な選択であり踏み石ではない。

R2 — Egress ゼロが経済を変える

Egress 無料は販促ではなく構造(ネットワークで収益化、保存データでなく)。目安: Egress が総ストレージ費の30%超なら R2 圧勝。

シナリオ(月)S3R2削減
1TB 保存／10TB egress~$740~$1598%
10TB 保存／100TB egress~$7,200~$15098%
動画基盤／~6PB egress~$50,000~$60099%

強み

S3 互換 API(操作の90%)・Workers バインディング・Sippy(遅延移行)／Super Slurper(一括)・R2 SQL($2.50/TB ≈ Athena の半額)。

S3 に留まる理由

認証済 WORM／Object Lock(SEC 17a-4)、深いアーカイブ(Glacier Deep)、S3 Select、同一リージョン内転送が既に無料、深い AWS 統合。

Part V · The AI Stack

インフラ税なしの AI 推論

"エッジの AI = すべての都市ではなく、正しい大陸での AI"。

AI スタック — 統合バインディングと多プロバイダ

env.AI.run() 一本で 12+プロバイダ・70+モデル(OpenAI／Anthropic／Google／Alibaba…)に到達。プロバイダ切替は1行。AI Gateway が観測性・キャッシュ・フェイルオーバーを内蔵。

Workers AI

サーバーレス推論。OSS〜フロンティア級(Kimi K2.6, 262K 文脈)。proprietary 比 10〜500倍安い。

Vectorize

ベクトル DB。最大1536次元・1000万ベクトル／インデックス。名前空間でマルチテナント。

AI Search

マネージド RAG。ハイブリッド検索(ベクトル+BM25)。最大5,000インスタンス／100万ファイル。

現実: GPU は地域クラスタ(全300+拠点ではない)。Worker→GPU で10〜50ms。fine-tuning なし・データ所在の成熟度は低め。推奨はハイブリッド — 高頻度は Workers AI、品質重視はフロンティアモデルを AI Gateway 経由。

RAG とエージェント — コストの実像

RAG

運用コストの95%超は推論(保存ではない)。10万クエリ/月: インデックス$6・保存$4 vs 推論$180〜500。最大の品質レバーはチャンク分割(意味単位300〜500トークン、10〜15%重複)。埋め込みモデルは混在禁止。

AI エージェント

難しいのは AI ではなく制約。"すべてのツールが攻撃面"。Durable Objects がユーザー単位で競合排除・状態保持。1操作が 5〜50回 の LLM 呼び出しに膨張しうる。Code Mode で最大81%トークン削減。

エージェントを使う条件(3つ全て満たすとき): ①状態を変えるツール使用 ②行動列を事前決定できない(できるなら Workflows) ③人間承認の遅延が許容できない。それ以外は単純な LLM アプリで十分。
Part VI · Production

実際のコスト・運用・セキュリティ

請求書が来てから気づかないために。

TCO 比較 — 50M req/月の SaaS API

AWS(Lambda+API GW+RDS+S3+CloudFront+NAT)
~$965 / 月
Cloudflare(Workers+D1+R2+KV)
~$434 / 月

約55%削減

I/O 主体ワークロードでは 70〜80% 削減も珍しくない。

差の源泉:

  • Egress ゼロ(~$425)
  • NAT ゲートウェイ不要(~$150)
  • API Gateway 相当が不要($3.50/M が消える)
  • CPU 時間課金 vs 壁時計課金

逆に高くなる場面: 計算主体ワークロード、超低トラフィック($5/月基本料を償却できない)、深い AWS サービス統合、既存リザーブド契約。Egress が請求の20%超なら Cloudflare 優位の目安。

可観測性とセキュリティ — 違い と 成熟度

Observability

  • デバッガ接続・フレームグラフは不可。ログが debugging の主役
  • Workers Logs: 7日保持(無料3日)、2,000万イベント/月無料
  • Logpush→R2 は Datadog 比 ~200倍安い(300GB: $4.5 vs $900)
  • 地域別アラートを: "グローバル5%" と "単一地域20%" 両方
  • インシデントは wrangler rollback(数秒・グローバル)が第一手

Security & Compliance

  • V8 isolate: 攻撃ウィンドウが時間→ミリ秒に。V8 パッチ <24時間
  • SOC 2 Type II／ISO 27001／GDPR／HIPAA BAA／PCI DSS
  • プラットフォーム適格 ≠ アプリ準拠 — 設計責任は自社
  • Data Localization Suite で処理地域・鍵・ログ境界を制御
  • エッジ認証で不正トラフィック ~10% をバックエンド到達前に排除

デプロイは段階的ロールアウト(両バージョン同時稼働、ロールバックは再ルーティングで数秒)。1%→10%→50% をエラー／レイテンシ基準とともに。

Part VII–VIII · Decisions & Migration

適合の見極めと、提案への落とし込み

合わなければ "使わない" も妥当な結論。だからこそ提案が信頼される。

適合するワークロード — Cloudflare の強み圏

よく合う

  • グローバルユーザーの API バックエンド
  • レイテンシ重要な認証(200ms→5ms)
  • リアルタイム協調・共同編集(Durable Objects)
  • I/O 主体のオーケストレーション(課金で有利)
  • マルチテナント SaaS(DB-per-tenant)
  • グローバルユーザーへの AI 機能

苦戦する

  • メモリ集約処理(>128MB)
  • 長時間計算(>5分 CPU)
  • 単一の大規模 DB(>10GB・複雑 join)
  • インバウンド TCP/UDP(非 HTTP)
  • バックエンドが特定1地域に集中
評価の問い: メモリ上限? CPU プロファイル? ユーザーの所在? バックエンドの所在? プロトコル? リアルタイム協調の要否? — 複数が低スコアなら "プラットフォームと戦う" サイン。ハイブリッドが最適解のことが多い。

使うべきでないとき — 失格条件(率直に)

制約閾値超えたら
リクエストあたりメモリ128 MBContainers(最大12GB)／外部コンピュート
リクエストあたり CPU 時間5分Containers／Queues／外部
単一 DB サイズ10 GB複数 D1／Hyperdrive で外部 DB
インバウンドプロトコルHTTP のみ従来クラウド + LB(唯一の代替不能制約)
クロスパーティション・トランザクションなしSaga／Workflows／外部 DB
GPU 学習・カスタム CUDAなしハイパースケーラ(Workers AI は推論のみ)
"違う" と "劣る" を区別: "現プラットフォームと独立に要件を正当化できるか?" — "画像ライブラリが全体をロードするため2GB必要"=本物。"Lambda のコールドスタート対策にプロビジョニング必要"=捨ててよい思い込み。

移行プレイブック — 共存 → 段階移行

4原則: カットオーバー前に共存／アトミックより漸進／可逆性を要件に／計測してから移行。一括移行ツールは "設計上あえて" 存在しない。

①
エッジ確立
(プロキシ Worker <5ms)
②
ストレージ移行
(Sippy／Slurper)
③
コンピュート移行
(段階デプロイ)
④
データ移行
(dual-write／Hyperdrive)
⑤
廃止
(30日ロールバック窓)
各フェーズは単独で価値があり、恒久的な停止点にもなる。 S3→R2 は Sippy(遅延・要求分のみ egress)。Lambda→Workers は再アーキテクチャ(API Gateway $175/月 が消える)。既存 PG/MySQL は Hyperdrive で移行せず接続も恒久解。

提案の要点 — 3つのメンタルモデル

水平 ≠ 垂直

"どう大きくするか" でなく "どう自然に分割するか"。DB-per-tenant、object-per-user から始める。

グローバル ≠ リージョン

既定で全展開。制約は規制のための限定のみ。データの局所性は物理が要求する分だけ。

プリミティブ ≠ サービス

合成可能な構成要素。前払いの利便性と引き換えに持続的な柔軟性を得る。

提案の話法: ①TCO(Egress+NAT+CPU 課金)で語る ②スイッチングコストを正直に($500/月削減 vs $50K 移行 = 8年回収なら無意味) ③失格条件を先に提示 ④ハイブリッド(エッジ認証／キャッシュ／ルーティング + 既存バックエンド)を恒久アーキテクチャとして提案。

Build with the principles.
Verify the specifics.

新規はまず Cloudflare で試作し、使わない理由を探す。
制約は明示的・原則は不変、具体値は常に最新ドキュメントで確認を。

出典: Jamie Lord「Architecting on Cloudflare」(2026年5月版) · architectingoncloudflare.com — 導入判断のための独自要約

☰ アジェンダ