Cloudflare Agents Weekを本番設計に落とす: 制御プレーン実装パターン

CloudflareのAgents Weekで出た各機能は、単体で使うより「1つの制御プレーン」として組み合わせると価値が出ます。Sandboxes、Artifacts、Workflows、egress制御を別々に導入すると、運用時に境界が曖昧になり事故調査が難しくなります。

エージェント時代は“セッション”が最小運用単位

従来のWebは「1アプリに多数ユーザー」が前提でした。エージェントでは「1ユーザーが複数セッションを並列実行」する形が増えます。この前提では、以下が必須です。

セッション単位の隔離実行
作業状態の版管理
長時間処理の耐障害オーケストレーション
外向き通信のポリシー統制

ここを作らずに関数実行だけで回すと、規模拡大時に破綻します。

実装しやすい参照構成

Workers: 入口認証、テナント判定、ポリシー適用
Durable Objects: セッション状態、排他、ロック
Sandboxes: ツール実行と状態保持タスク
Artifacts: 人間とエージェントの成果物受け渡し
Workflows: 長時間分岐、再試行、補償処理
R2/KV + 監査ログ: 証跡と分析

この構成は速度を維持しつつ、統制境界を明確にできます。

セッションライフサイクルを契約化する

セッション状態を暗黙運用しないことが重要です。

created（本人性確認・ポリシー付与）
active（許可済みツールのみ実行）
checkpointed（成果物スナップショット）
suspended（リソース制限）
closed（保持期間・マスキング適用）

状態遷移が明確であれば、障害や不正時の切り分け時間を短縮できます。

egress制御が最重要

実運用の重大事故は、プロンプトより外向き通信で起きることが多いです。最低限、次を実装します。

宛先許可リスト（環境・用途別）
資格情報は境界で注入
セッション単位の短命クレデンシャル
拒否理由を機械可読で記録

特に、長寿命トークンを実行環境に平文で渡さないことが重要です。

Artifactを3層で扱う

Artifactsは1種類にしないほうが安全です。

作業状態（可変）
意思決定証跡（追記専用）
リリース候補（昇格・署名対象）

この分離で、証跡改ざんリスクを抑えつつ開発速度を落としません。

長時間エージェントの信頼性設計

ツール操作のidempotency key
失敗種別別リトライ（容量不足/タイムアウト/ポリシー拒否）
ステップごとのheartbeat監視
ポリシー拒否タスクのDLQ分離
チェックポイントからの決定的再開

再開位置を決めずに再実行すると、重複処理や整合性崩れが発生します。

SREが追うべき指標

ワークロード別セッション完了率
ツール障害からの平均復旧時間
ポリシー拒否率と誤検知率
egress拒否の主要因
Artifact復元遅延
完了ワークフロー当たりコスト

これらは品質、統制、コストの3軸を同時に可視化します。

90日導入の現実的手順

1カ月目

上位5ユースケースを分類
Durable Objectsでセッション管理を導入
クレデンシャル注入を境界方式へ移行

2カ月目

Artifactsのチェックポイント標準化
非同期分岐をWorkflowsへ寄せる
完了率・復旧時間のSLO策定

3カ月目

egress迂回を想定したレッドチーム演習
保持期間と証跡エクスポートを自動化
経営向けにコスト・リスク・供給速度の週次報告を運用化

まとめ

Agents Weekは機能追加の集合ではなく、エージェント時代のクラウド運用設計図です。実行環境、状態、オーケストレーション、外向き統制を1つの制御面で扱えれば、スケールと統制を両立できます。