#cloud#edge#ai#agents#finops
Cloudflare Workers AI本番運用: セッション記憶・ガードレール・コスト安定化の実務設計
CloudflareのAI関連拡張は、推論、状態管理、実行制御の距離を大きく縮めました。重要なのはモデルが増えたことより、運用面で責任分界を作りやすくなったことです。一方で設計を誤ると、セッション破綻、再試行ループ、コスト急騰が同時に発生します。
参考: https://blog.cloudflare.com/workers-ai-large-models/
本番で起きる4つの典型障害
- 長文ツール応答でコンテキストが肥大化する
- 再試行時にセッション状態が競合する
- テナント別の費用が予測不能になる
- 非同期分岐でポリシー検証が抜け落ちる
PoCで見えにくいのは、これらが負荷時に連鎖する点です。
推奨アーキテクチャ
- Workers: 認証、事前ポリシー判定、ルーティング
- Durable Objects: セッションの単一責任点（整合性境界）
- Workers AI: モデル実行
- Workflows/Queues: 長時間処理と再試行
- R2/KV: 永続成果物と要約保持
ポイントは可変状態の主権をDurable Objectsに固定することです。キャッシュ用途だけにすると障害時に必ず迷子になります。
セッション記憶を層で分ける
- ターン記憶（短期、生ログ）
- タスク記憶（要約、意思決定）
- ポリシー記憶（不変の判断証跡）
- テナント記憶（恒久的制約）
この4層を混在させると再現性が失われます。構造を先に定義し、バージョン管理してください。
再試行に強いガードレール
最初に検証したからOKという前提は危険です。各ステップ境界で署名付きポリシー文脈を引き継ぎ、下流ツール実行前に必ず再検証します。
最低限必要なチェック:
- 外部接続先ドメイン許可リスト
- データ分類に応じた自動マスキング
- テナントプラン/リスク階層ごとのツール権限
- ワークフロー単位の累積トークン上限
コスト安定化の高ROI施策
- コンテキスト圧縮の閾値運用
- 難易度別モデルルーティング
- プリフィルキャッシュ効果の可視化
巨大1本プロンプトで運用すると改善余地が見えません。処理段を型付きで分けることが前提です。
SRE運用指標
- 対話系のp95 end-to-end遅延
- ツールチェーン障害の復旧時間
- 再試行後の状態整合率
- テナント別の費用燃焼速度
モデル遅延と外部API劣化の2系統でカオス演習を回すと、実運用での復旧速度が上がります。
60日ロードマップ
- 1-15日: 基準指標（遅延/費用/失敗分類）整備
- 16-30日: セッション主権をDurable Objectsへ集約
- 31-45日: 非同期分岐の署名付きポリシー強制
- 46-60日: 適応ルーティングとハード予算制御
まとめ
CloudflareのエッジAI基盤は十分実戦投入できます。ただし成果を出す条件は明確です。記憶、ポリシー、コストを設計の最上位に置き、運用可能な単位へ分解することが不可欠です。
