Workers AI × Kimi K2.5を本番運用する設計論：Session AffinityとPrefix Cacheを中心に

CloudflareがWorkers AIでKimi K2.5のような大規模モデルを正式提供し、Prefix Cacheとx-session-affinityを強調したことは、単なるモデル追加ではありません。エージェント基盤の主戦場が「モデル選定」から「運用設計」に移ったことを示しています。

まず前提を切り替える

エージェント推論を1回限りのAPI呼び出しとして扱うと、次の問題が必ず出ます。

• 文脈が肥大し、prefillコストが増える
• TTFTがセッションごとに大きくぶれる
• 同じ処理でもコスト予測ができない

したがって、設計単位は“リクエスト”ではなく“セッション”です。

推奨構成

• Workers：入口制御、認可、ポリシー適用
• Durable Objects：セッション状態とAffinityキー保持
• Workers AI：推論実行
• Workflows：長時間タスク制御
• R2/KV：成果物と要約の保存

この形にすると、状態・実行・統制を分断せずに運用できます。

Prefix CacheをKPIにする

キャッシュは内部最適化ではなく、運用KPIとして公開すべきです。

• ワークロード別キャッシュヒット率
• cached token比率
• セッション群ごとのTTFT分散

これが見えないと、月末に突然コストが跳ねます。

信頼性を作る4つの実装

1. ツール実行のidempotency key
2. prefill重/生成重のキュー分離
3. Nターンごとの要約チェックポイント
4. データ区分に応じたリージョン固定

セキュリティ実装

• ツール別の最小権限トークン
• 外向き通信先の許可リスト
• ログ前の構造化マスキング
• ポリシー判定結果の改ざん困難な保存

60日導入ロードマップ

• 1〜2週：現行ワークロードの遅延/トークン実測
• 3〜4週：Affinity運用とCache可視化導入
• 5〜6週：業務リスク別にルーティング分離
• 7〜8週：SLO化と障害Runbook確定

まとめ

大規模モデル時代は、モデルそのものより「どう状態を持って運用するか」が競争力になります。Session AffinityとPrefix Cacheを運用指標に昇格できるかが分岐点です。