CurrentStack
#ai#agents#cloud#edge#finops

Cloudflare Workers AI実運用ガイド: セッションアフィニティとガバナンスを同時に設計する

Cloudflare の Workers AI が大規模モデル対応を強化し、Kimi K2.5 のようなモデルを実サービスで使いやすくなったことで、注目すべき論点は「どのモデルを使うか」だけではなくなりました。いま実務で差になるのは、推論・状態管理・ポリシー・コスト管理をどれだけ一貫した運用面で扱えるかです。

参考: https://blog.cloudflare.com/workers-ai-large-models/、https://developers.cloudflare.com/workers-ai/models/kimi-k2.5/。

なぜ今、運用設計がボトルネックになるのか

PoC 段階では回答精度が主な評価軸になりますが、本番に入ると次の問題が顕在化します。

  • 同じワークフローでも時間帯で遅延が大きくぶれる
  • 会話が長くなるほどトークンコストが急増する
  • リトライ時にツール呼び出し順序が揺れて再現性が落ちる
  • 障害解析でログの所在が分散し、復旧までが長い

これらはモデル品質の問題というより、システム設計の問題です。Workers AI の価値は、統合された実行基盤により「壊れ方を制御しやすい設計」に寄せられる点にあります。

セッションアフィニティは最適化ではなく信頼性設計

x-session-affinity のような仕組みは、コスト削減の小技として扱われがちですが、実際には SLO を守るための中核です。

セッション局所性を維持すると、

  1. TTFT（初回トークン到達時間）の分散が縮む
  2. 文脈プレフィックスのキャッシュ効率が上がる
  3. 再試行時の応答差分が減る
  4. トラブル時の因果追跡が容易になる

推奨するキー設計は tenantId:workflowId:conversationId です。ここに TTL を設定し、期限切れセッションの自動ローテーションを入れると、ホットキー偏りや古い文脈汚染を防げます。

3層構造で責務を分離する

Workers AI を実運用する際は、次の 3 層で管理すると設計負債が減ります。

1. Runtime Plane（実行層）

  • Workers: 認証、入力検証、ポリシー評価前処理
  • Durable Objects: 会話状態、一貫性、排他制御
  • Workers AI: 推論
  • R2/KV: 成果物、要約、検索用スナップショット

2. Control Plane（制御層）

  • モデル選択ルール（リスク階層別）
  • ツール利用許可ポリシー（ワークフロー別）
  • 予算ガード（最大出力、最大リトライ、キャッシュ目標）

3. Observability Plane（観測層）

  • ルート別トークン量、キャッシュヒット率
  • ツール呼び出し時系列とポリシー判定ID
  • p95遅延、完了率、成功タスク単価のダッシュボード

この分離がないと、問題発生時に「推論が遅いのか」「ポリシーが過剰なのか」「ツール応答が肥大化したのか」を切り分けられません。

コスト管理は「1リクエスト単位」から卒業する

本番環境で効くのは、リクエスト単位の課金監視ではなく、ワークロード単位の設計です。

実務で効果が高い順に挙げると、

  • Nターン要約チェックポイントで文脈肥大を抑える
  • 難易度別ルーティングで高単価モデルを限定利用する
  • ツール出力正規化で不要な長文を抑える
  • キャッシュ前提プロンプト設計で安定した再利用を作る

評価指標は以下が有効です。

  • ワークフロー完了あたりコスト
  • キャッシュ入力比率
  • ツール種別ごとの出力トークン p95

単純な総トークン量より、運用品質を正しく反映します。

監査可能なエージェント運用を先に作る

AI エージェントは「回答が返る」だけでは運用できません。外部作用を伴う以上、説明責任が必須です。

最低限の統制として、

  • ツール実行前のアウトバウンド許可制御
  • policy_version と decision_id の不変記録
  • 永続化前の機微情報マスキング
  • 実行権限と運用権限の分離

を標準化してください。

監査対応の本質は、障害後に説明することではなく、平時から「再構築可能な意思決定ログ」を残すことです。

45日導入ロードマップ

1〜2週目: 現状可視化

遅延分布、キャッシュ利用率、失敗パターン、トークン消費を計測し、基準線を作る。

3〜4週目: 挙動安定化

セッションアフィニティと要約チェックポイントを導入。プロンプト版管理を固定化する。

5〜6週目: 統制導入

ポリシーゲート付きツール実行、予算上限、リトライ上限を適用する。

7週目: 負荷試験

実トラフィックに近いテナント分布でバースト試験を実施し、SLOと予算逸脱を検証する。

この順序なら、プロンプト調整だけを繰り返して本質的な不安定性を放置する失敗を避けられます。

まとめ

Workers AI の最新動向は、単なるモデル追加ニュースではありません。エージェント運用を「分散する責務の寄せ方」で再設計する契機です。セッション局所性、ポリシー追跡性、ワークロード単位の FinOps を同時に導入したチームほど、速度と品質を両立できます。

おすすめ記事

← 記事一覧へ戻る