Workers AI大規模モデル運用の実装論：Session AffinityとPrefix Cacheでコストを崩さない

Cloudflare Workers AIがKimi K2.5のような大規模モデルを提供し始めたことで、エージェントをエッジ基盤上で完結運用する現実性が一気に高まりました。ただし、導入直後に起きやすいのは「動くが高い・遅い・読めない」という状態です。

設計の前提

大規模モデル呼び出しは、単純なHTTPリクエストではなく状態を持つ分散システムとして設計するべきです。

マルチターンで毎回長いシステムプロンプトやツール定義を再送すると、推論時間の大半がprefill処理に消えます。ここで効くのがPrefix CacheとSession Affinityです。

推奨アーキテクチャ

• Workers：オーケストレーションとポリシー適用
• Durable Objects：セッション状態とAffinityキー保持
• Workflows：長時間ジョブの制御
• Workers AI：推論実行
• R2/KV：中間成果物の保存

この構成なら、状態・実行・観測を分断せずに運用できます。

Session Affinityの運用ポイント

セッション単位で安定したAffinityキーを付与します。

• 連続ターンをキャッシュ有利な経路へ寄せる
• キャッシュヒット率を上げる
• TTFTのばらつきを抑える

逆に、異なる業務セッションでキーを共有すると観測性が悪化し、障害時の影響範囲も広がります。

コストを抑える4パターン

1. 固定プロンプト骨格の再利用（ヘッダを安定化）
2. コンテキスト上限の予算化（要約チェックポイントを挿入）
3. ツール定義の最小化（未使用定義を送らない）
4. ターン別モデルルーティング（軽量処理は低コストモデルへ）

信頼性設計

• idempotency key付きリトライ
• prefill重い処理とgeneration重い処理をキュー分離
• セッション単位でキャッシュ/トークン種別を計測
• ポリシー違反時はfail-closedで停止

セキュリティ設計

常時稼働エージェントでは次を必須化します。

• ツール実行トークンの最小権限化
• 外向き通信の許可リスト
• ログ前の構造化マスキング
• データ区分に応じたリージョン処理制約

45日導入計画

• 1〜2週目：主要ワークロードの遅延/トークン実測
• 3〜4週目：AffinityとCache指標の導入
• 5〜6週目：業務分類ごとのモデルルーティング適用
• 7週目：SLOと障害Runbookを確定

まとめ

大規模モデルを使えることと、本番運用できることは別です。安定運用の鍵は、セッション設計・文脈予算管理・統制境界の明文化です。Workers AIは、これらを組み合わせた時に初めて強い基盤になります。