AWSがAgentCore Evaluationsでエージェント品質評価の9段階を解説

何が報告されたのか

AWSのSales, Marketing, and Global Services(SMGS)Operationsチームは、AWS Field Sales向けの本番マルチエージェントシステムを開発し、その品質評価の仕組みをブログで紹介した。このシステムは、営業担当者とリーダーという2つの利用者層に向けて、自然言語の質問に答える形でビジネスインテリジェンスを提供する。回答の範囲は担当者のテリトリーとロールレベルのセキュリティで制限される。

システムの背後では複数の専門サブエージェントが協調して動作する。Performance Insights Agentは売上データから自然言語の分析ナラティブを生成し、Customer Insights Agentは製品利用状況やサポート履歴、契約状況などを統合して顧客の360度ビューを組み立てる。Data Insights AgentはSQLを書かずに自然言語で構造化データを照会するテキストto SQLエージェントである。

品質評価の中核にはAmazon Bedrock AgentCoreのAgentCore Evaluationsが据えられ、安全性にはAmazon Bedrock Guardrails、メトリクスとアラームとトレーシングにはAmazon CloudWatch、評価結果の保存にはAmazon S3とAmazon Redshiftが使われる。ダッシュボードはAmazon Quick、カスタム評価器はAWS Lambdaが担う。

エージェント特有の難しさ

従来のソフトウェアは決定的で、同じ入力からは同じ出力が得られる。機械学習モデルは確率的な出力を持ち込み、MLOpsがその学習・バージョン管理・監視・再学習を扱うようになった。AIエージェントはさらに自律的な多段推論という第3の層を加え、問いは「何か壊れたか」から「推論の連鎖全体で妥当な判断をしているか」へと変わる。

エージェントは同じ入力でも異なる推論経路をたどり、ルーティングやツール選択、統合にわたって連鎖的に判断する。ある一段が静かに失敗すると、後続のすべてを壊しうる。最も厄介なのは、レイテンシもエラー率も平常のまま品質だけが劣化する「静かな失敗」である。原文は、エージェントが自信ありげで流暢に読めるが誤った回答を返す点を、従来ソフトウェアとの違いとして挙げている。

5つの評価軸と3つの階層

評価は5つの次元で行われる。安全性(定義された境界内で振る舞っているか)、品質(正しく一貫性があり根拠に基づく回答か)、性能(十分に速く信頼できるか)、コスト(大規模に効率よく動いているか)、運用統制(問題を迅速に検知・診断・修復できるか)である。安全性が最優先とされ、安全性の基準を満たせないエージェントは出荷も運用継続もされない。

フレームワークはエージェント階層のすべてのレベルに適用される。ツールレベルでは、顧客の曖昧性解消ツールやグラフ検索ツールといった各機能が独自の評価契約を持つ。エージェントレベルでは各サブエージェントがエンドツーエンドで評価され、マルチエージェントレベルではエージェント境界をまたぐルーティングや統合の正確性が評価される。各レベルがそれぞれ独自のゴールデンセット、評価器、昇格基準を持つ。

9段階の評価ループ

9つの段階は、初回コミットから本番応答までをたどる。各段階はチームがエージェントの成熟に伴って直面する問いに対応する。基盤では「良い状態とは何か」、実験では「どのバージョンが良いか」、マージ(CI)では「何かを壊していないか」、ゲート(CD)では「本番投入して安全か」を問う。

さらにカナリアでは「静かに壊れていないか」、敵対的検証では「誰かが壊そうとしたらどうか」、ドリフトでは「本番で品質がずれていないか」、パルスでは「今動いているかをどう知るか」、フィードバックループでは「どう自動的に良くなるか」を問う。これらは後からつなぎ合わせた別々のツールではなく、単一の連続した評価面の9つの点として位置づけられる。

実装パターンとしては、CI/CDの回帰ゲート、カナリアスコアリング、ドリフト検知、自動フィードバックループが挙げられている。原文ではシステム構成図も示されているが、各段階の詳細な手順の記述は参照した範囲には含まれていない。

本番前に見つかった誤り

ローンチ前にCustomer Insights Agentを評価したところ、いくつかの誤りが見つかった。ある顧客の3か月の売上410.08ドルを「410.08 Million(4億1,008万ドル)」と報告し、調整を除く売上高とラベルされた値を売上高として報告した。データのどこにも存在しない年間経常収益(ARR)の推計を提示し、さらに自身の計算を出典に基づく事実として提示していた。

これらの実行を通じて監視はグリーンのままだった。監視が示していたのは「システムが応答したか」であり、「回答が正しいか」ではなかった。原文は、こうした誤りが出荷されていれば現場が代償を払っていたとし、水増しされた数値を繰り返す営業担当者は顧客への信頼を失いかねないと指摘している。

リスクはローンチで終わらない。上流のパイプラインが毎週データを更新するため、リリースがなくてもリスクは増える。データ変更・ツール変更・ペアとなるプロンプト更新が同時に出荷されるべきなのにずれて着地すると、すべてが追いつくまでシステムは不整合のまま動く。ある本番前テストでは、この不整合の期間だけで合格率が78%から38%に落ちたという。