5 分で読めます

AIエージェント本番評価——シャドーモードとサンプリング

本番エージェントの品質は、リリース後も静かに劣化し続ける。ユーザー行動の変化、外部APIのレスポンス変動、新しいエッジケースの出現——これらはオフラインのゴールデンデータセットでは捕捉できない。本番トラフィックをどう評価基盤に組み込むかが、エンタープライズ規模のエージェントガバナンスの中核となる。

オフライン評価だけでは何が見えないか

オフライン評価は既知のパターンしか検証できず、本番トラフィックにのみ存在する未知のエッジケースや配布シフトは検知できない。

AIエージェントのオフライン評価(ゴールデンデータセット + 回帰テスト)は、既知の入力パターンへの正確性を保証する。しかし本番環境には3種類の見えないリスクがある。

配布シフト(Distribution Shift): ユーザーが実際に送るプロンプトの分布は、テストデータ収集時から継続的に変化する。新機能リリース後や季節要因で入力の傾向が変わっても、既存のゴールデンデータセットはそれを反映できない。

連鎖劣化: マルチエージェント構成では上流の出力が下流の入力になる。あるステップのわずかな品質低下が複数のサブエージェントを経由するうちに増幅され、最終出力に大きく現れる。サブエージェントのオーケストレーション設計でも述べたように、連鎖構造はオフラインテストでは再現が難しい。

外部依存の変動: MCPサーバー、RAGインデックス、外部APIのレスポンス特性は本番環境でのみ観測できる変数だ。スタブやモックでは実際のレスポンスパターンのばらつきを模倣しきれない。

シャドートラフィック評価とはどういう設計か

シャドートラフィック評価は本番リクエストを複製してユーザー影響ゼロで候補モデルを検証する手法で、本番昇格前の最後の品質ゲートとなる。

実装の構造

シャドートラフィックはAPIゲートウェイまたはロードバランサーのレイヤーでリクエストを複製する。本番モデル(Champion)への呼び出しはそのまま進み、ユーザーには Champion の応答が返る。同じリクエストが非同期でチャレンジャー(新モデル・新プロンプト版)にも送られ、その応答はサイドキューに蓄積される。

``
Request ─┬─► Champion ──► User Response
└─► Challenger ──► Async Queue ──► Evaluator
``

チャレンジャーのレスポンスはユーザーに届かない。レイテンシーのSLAを壊さずに、本番の実際のリクエスト分布のみで観測できる行動データを収集できる。

Champion/Challenger 比較の評価層

サイドキューに蓄積されたペアに対して自動評価を走らせる。評価は3層に分ける。

  • 高速ヒューリスティック(全量): レイテンシー・トークン数・エラー率・フォーマット遵守。実装コストが低く100%カバレッジを保てる。
  • LLM-as-judge(5〜10%): 回答の事実整合性、有害性、タスク達成度。コストが大きいため全量には適用しない。
  • 人間アノテーション(1〜3%): LLMジャッジの高不確実出力からサンプリングし、自動スコアのキャリブレーションに使う。

サンプリング戦略はどう設計するか

一律10%のサンプリングは非効率で、エラー・高価値トランザクション・LLMジャッジ低スコア出力を100%取得するリスクベース設計が原則だ。

一律サンプリングは直感的だが、コスト対効果が低い。リクエストをリスク分類し、分類ごとに異なるサンプリング率を適用する。

トラフィック分類サンプリング率目的
通常リクエスト5〜10%ベースライン品質の継続監視
エラー(4xx/5xx)100%全件分析が必須
P99レイテンシー超過100%パフォーマンス劣化の特定
高価値トランザクション(金融・契約系)100%ビジネスインパクトの管理
LLMジャッジ低スコア出力100%連続劣化の早期検知

Anthropic の推奨するエージェント設計原則(sandboxed environments での段階的検証)をオンライン評価に拡張すると、本番環境自体を影響範囲を制御したサンドボックスとして運用するアーキテクチャ観点になる。

サンプリングアーカイブの保持期間

収集したトレースをすべて永続化するとストレージコストが急増する。監査・回帰用途を満たしながらコストを抑える保持期間の設計例:

  • 詳細スパン(全フィールド): 7〜30日
  • サンプリング済みトレース(LLMジャッジ対象): 90〜365日
  • 低スコアサンプル(ゴールデンデータセット候補): 無期限

フィードバックループ——本番データをテスト資産に変える

本番の低スコアトレースを自動でゴールデンデータセットに還流させる設計が、オフラインテストを本番に追従させ続ける唯一の方法だ。

パイプライン設計

オンライン評価の本質的な価値は品質劣化の検知だけでなく「テスト資産の継続更新」にある。次のパイプラインを実装することで、本番トラフィックがゴールデンデータセットとして自動的に成長する。

  1. 低スコア検出: LLMジャッジスコアが閾値(例: 0.7未満)を下回ったトレースをキャッチ
  2. レビューキュー投入: 低スコアトレースをアノテーションキューに自動転送。SREまたはドメインエキスパートが期待出力を付与
  3. ゴールデンデータセット追加: 承認済みペアをオフラインテストスイートに自動マージ
  4. CI回帰テストへの反映: 次回リリースから新ケースが自動包含

このループにより、エージェントの回帰テストが本番エッジケースで継続的に充実する。運用4〜6ヶ月でゴールデンデータセットの信頼性が大幅に向上する。

メトリクスの時系列監視

個別トレースのスコアだけでなく、集約メトリクスを時系列で監視する。監視すべきシグナル:

  • ロールアップ品質スコア: 7日移動平均。急激な下落が問題の先行指標になる
  • スコア分布変化: 平均値が安定していても分散が拡大している場合は特定パターンの劣化を示す
  • カバレッジ率: 「評価済みリクエスト数 / 全リクエスト数」の推移

参考

まとめ

本番トラフィックによるオンライン評価は、オフライン回帰テストでは補足できない配布シフト・連鎖劣化・外部依存の変動を継続的に捕捉する。シャドートラフィック設計でユーザー影響ゼロのままチャレンジャーを評価し、リスクベースのサンプリングでコストを制御しながら品質監視する。低スコアサンプルをゴールデンデータセットに還流させるフィードバックループが、本番エージェントを長期的に健全に保つ基盤となる。

エンタープライズ規模でのオンライン評価基盤の設計・実装は、Kuuの RDE サービスで支援しています。本番エージェントの品質管理体制を確立したい場合は、お気軽にご相談ください。

関連記事

ゴールデンデータセットで始めるエージェント回帰テスト設計LLM-as-a-judgeでエージェント品質を自動採点する評価基盤設計マルチステップ評価設計——ターン単位とエンドツーエンドの使い分け9軸評価×LLM-as-judgeでエージェントを自動採点する