Cloudflareエージェント基盤を本番運用するためのSLO設計とガバナンス実装
CloudflareのWorkers AIやエージェント関連アップデートは、「エッジでAIを動かせるか」という検証フェーズから、「本番で壊れず、監査でき、利益を残せるか」という運用フェーズへ、明確に重心が移ったことを示しています。
この変化を正しく扱うには、エージェント機能を1本のAPI連携としてではなく、マルチテナントな“プロダクト基盤”として設計する必要があります。重要なのはモデル精度だけではありません。リクエスト受け付け、状態管理、アクション許可、再試行、障害時の顧客体験までを含めて、ひとつの運用品質として作り込むことです。
参考: https://blog.cloudflare.com/
1. 実装前にサービス階層を定義する
多くの障害は、技術要素そのものより、プロダクト境界が曖昧な状態で実装を始めることから発生します。先に次のような層を定義してください。
- Tier A: 顧客向け対話、低遅延、厳格なポリシー必須
- Tier B: 社内支援用途、中遅延許容、準リアルタイム
- Tier C: 非同期の調査・要約ジョブ、遅延許容
この分類を、タイムアウト、モデル選択、利用可能ツールに直結させます。SREとプロダクトが同じ言葉で議論できる状態を作ると、障害対応速度が一段上がります。
2. SLOを「会話品質」と「運用品質」に分離する
エージェントの信頼性は、単純な稼働率だけでは測れません。少なくとも次の2系統に分けると、原因特定が速くなります。
会話品質SLO:
- ターン成功率
- First Token Latencyのp95/p99
- ユーザー可視エラーからの回復率
運用品質SLO:
- ツール呼び出し成功率
- ポリシー判定レイテンシ
- 非同期ワークフローのキュー滞留時間
この分離がないと、「遅い」「失敗した」という症状に対して、モデル問題か、基盤問題か、外部ツール問題かが混ざり、改善サイクルが鈍化します。
3. セッション親和性は保持データを最小化する
セッション親和性は文脈一貫性と応答速度を改善しますが、状態管理を曖昧にすると障害時の影響範囲が拡大します。永続化対象は原則として次に限定します。
- 要約済みの短いコンテキスト
- 承認・拒否を含むポリシー決定記録
- 追跡可能な実行トレースID
逆に、生プロンプト、秘密情報、短命な埋め込みデータは保持期間を厳格に短縮し、レビュー目的の最小限ログへ落とし込む設計が安全です。
4. 「実行前ポリシー契約」を必須化する
エージェント出力をそのまま特権操作に接続してはいけません。実行前に必ず機械判定できる契約層を置きます。
- 実行主体（誰の権限か）
- 要求操作のリスクレベル
- 承認方式（不要/非同期承認/HITL）
- 監査証跡の必須項目
JSONの契約として定義し、すべてのツールアダプタの前段で評価します。これだけで、誤操作や権限逸脱の発生率を大きく下げられます。
5. FinOpsは月次集計ではなく“リクエスト時制御”で行う
エージェント負荷が高い環境では、月末レポートを見てからでは遅いです。実行時に次を制御します。
- セッション単位のトークン上限
- しきい値超過時のモデル自動フォールバック
- コンテキスト肥大時の要約圧縮ルール
予算をルーティング条件に組み込むと、コストは「事後分析対象」ではなく「リアルタイム制御対象」に変わります。
6. 失敗モードを定義し、定期的に演習する
障害を減らすより先に、障害時の挙動を標準化することが重要です。例えば次の失敗モードをライブラリ化します。
- 推論前計画中のタイムアウト
- 承認後ツール実行のタイムアウト
- ポリシー判定サービス劣化
- 古いセッションチェックポイント再生
- ストリーミング中断による部分応答
各モードに対し、ユーザー向けメッセージ、内部アラート、再試行条件、手動介入基準を固定しておくと、ピーク時でも運用が崩れません。
7. 段階的ロールアウトの実践
現実的な公開順序は次の通りです。
- Ring 0: 合成トラフィックのみ
- Ring 1: 社内限定、詳細トレース取得
- Ring 2: 外部オプトイン、厳格な利用上限
- Ring 3: 全体公開、適応型レート制御
Ring 2を省略しないことが重要です。設計上の想定と実ユーザー行動のズレは、ほぼここで顕在化します。
まとめ
2026年の差別化要因は「モデルにアクセスできること」ではなく、「壊れにくく、説明可能で、採算が合う運用を組み込めること」です。Cloudflare上でエージェントを事業として成立させるなら、SLO設計、ポリシー契約、実行時FinOpsを同時に実装するのが最短ルートです。
