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に固定することです。キャッシュ用途だけにすると障害時に必ず迷子になります。

セッション記憶を層で分ける

1. ターン記憶（短期、生ログ）
2. タスク記憶（要約、意思決定）
3. ポリシー記憶（不変の判断証跡）
4. テナント記憶（恒久的制約）

この4層を混在させると再現性が失われます。構造を先に定義し、バージョン管理してください。

再試行に強いガードレール

最初に検証したからOKという前提は危険です。各ステップ境界で署名付きポリシー文脈を引き継ぎ、下流ツール実行前に必ず再検証します。

最低限必要なチェック:

• 外部接続先ドメイン許可リスト
• データ分類に応じた自動マスキング
• テナントプラン/リスク階層ごとのツール権限
• ワークフロー単位の累積トークン上限

コスト安定化の高ROI施策

• コンテキスト圧縮の閾値運用
• 難易度別モデルルーティング
• プリフィルキャッシュ効果の可視化

巨大1本プロンプトで運用すると改善余地が見えません。処理段を型付きで分けることが前提です。

SRE運用指標

• 対話系のp95 end-to-end遅延
• ツールチェーン障害の復旧時間
• 再試行後の状態整合率
• テナント別の費用燃焼速度

モデル遅延と外部API劣化の2系統でカオス演習を回すと、実運用での復旧速度が上がります。

60日ロードマップ

• 1-15日: 基準指標（遅延/費用/失敗分類）整備
• 16-30日: セッション主権をDurable Objectsへ集約
• 31-45日: 非同期分岐の署名付きポリシー強制
• 46-60日: 適応ルーティングとハード予算制御

まとめ

CloudflareのエッジAI基盤は十分実戦投入できます。ただし成果を出す条件は明確です。記憶、ポリシー、コストを設計の最上位に置き、運用可能な単位へ分解することが不可欠です。