Cloudflare Agent Cloud実運用, セキュリティと速度を両立する制御プレーン設計（2026）
2026年4月のCloudflareの発表群は、エージェント実行基盤の前提を一段引き上げました。Dynamic Workersによる起動特性の改善、Agent Cloudの拡張、そしてプライベートネットワーク接続の整理によって、従来のコンテナ中心構成より軽く速い実装が現実的になっています。
ただし、導入の成否は「速いかどうか」では決まりません。自律実行を増やしても、権限境界と監査性を維持できるかが本質です。
なぜ今、設計論点が変わるのか
今回の流れは単機能の追加ではなく、運用モデル全体の更新です。実行面の高速化だけでなく、ネットワーク境界とワークロード分離まで含めて再設計できる段階に入りました。
つまり、SREやPlatformチームは「実験を回す段階」から「統制を前提に本番化する段階」へ進む必要があります。
典型的な失敗, 速さに合わせて境界が崩れる
現場で起きやすいのは次です。
- 実行主体のIDが広すぎる
- メモリストアが事実上のデータレイク化する
- 人間向けトークン権限をそのまま流用する
- 障害調査の近道で監査証跡が欠落する
PoCでは見えにくいですが、本番に広げると短期間でコンプライアンス課題に変わります。
制御プレーン先行の3層設計
1. アイデンティティとスコープ
作業種別ごとに役割を分けます。例として、閲覧専用の障害トリアージ、コード解析、限定的な自動修復です。各役割に対して到達可能ネットワークと利用ツールを最小化します。
2. データライフサイクル
コンテキストとメモリを保存期間で分類します。
- 一時コンテキスト（分, 時間）
- 運用メモリ（日単位, マスキング前提）
- 監査記録（改ざん不可, 参照ログ必須）
メモリを「便利な一時保存」と扱わず、規制対象データとして管理するのが重要です。
3. 実行ポリシー
高リスク操作の前にポリシーチェックを入れます。具体的には本番変更、顧客データ参照、外部書き込みです。影響範囲が大きい操作には人手承認を残します。
導入ロードマップ
Phase A, 制約付き試行
まずは顧客影響のない業務に限定します。
- Runbook下書き
- ログ要約と一次切り分け
- ドキュメント同期
速度だけでなく、レビュー負荷と引き継ぎ品質を測定します。
Phase B, 境界付き本番運用
限定的な書き込みを許可し、各アクションに証跡項目を強制します。実行主体、対象、理由、結果を構造化して残します。
Phase C, 適応型ガードレール
障害学習を使ってルールを更新し、過剰遮断と過少統制の両方を減らします。
初日から取るべき計測
- ポリシークラス別の成功率とロールバック率
- タスク起動時間の中央値とp95
- 保持期限順守率と削除成功率
- 承認キュー滞留時間
- ポリシー判定の誤検知率
この計測がないと、運用議論は体感ベースになり、改善が止まります。
まとめ
Cloudflareの新しい基盤は、速度と統制を同時に上げる余地を作りました。ただし、自律実行を先に拡大すると境界が追いつきません。先に設計すべきは、ID境界、メモリ保持ルール、監査証跡です。
その順序を守れば、エージェント活用は「便利な実験」ではなく、再現可能な本番能力になります。
