マルチターン会話向けAWS Agent Evaluation Metric、最初の誤りを可視化
AWSは2026年9月10日、最終回答のスコアでは日常的に見落とされる失敗を対象に、マルチターン会話向けのAgent Evaluation Metricを発表した。エージェントは一度誤った判断を下し、その結果の状態を数ターンにわたって引き継いだ末に、不正確な回答へ至ることがある。タスクレベルの評価器は、失敗した会話を1件として記録する。しかし、失敗がどこで始まったかは特定しない。
この違いは重要だ。後続のターンは、単に破損した情報を処理しただけなのに、それぞれが独立して不具合を起こしているように見える場合がある。失敗したターンをすべて別々の問題として扱えば、エンジニアは1つの原因ではなく複数の症状を追うことになる。モデル更新の影響を実際以上に悪く見せる可能性もある。
AWSは提案するフレームワークをAEMと呼ぶ。最初に公開された評価軸では、各応答またはアクションのターンにおける真実性と完全性を通じて正確性を測定する。より大きな論点は、結果だけを評価するスコアリングと、エージェントの軌跡における因果構造を保持する評価との間にある。
この論点はAWSに限らない。AgentBenchは以前、8つの対話型環境でエージェントを評価し、初期のtau-benchはユーザー、エージェント、ツール、ドメインルールが関与する会話を検証した。どちらも、評価を孤立したプロンプトと応答の組み合わせから移行させる助けとなった。AEMは、その議論を各会話内のターンレベル診断へと押し進める。
AWS、失敗した会話をエラーマップへ変換
重要な変化は、単に新しいスコアを加えることではない。最初の誤りと、そこから続くすべての失敗を分離する方法にある。
AEM frameworkは、期待される応答とツール呼び出しを含む注釈付き会話から始まる。各ターンをその参照データと照合し、合格または不合格を割り当て、失敗したターンには具体的な理由を記録する。その結果を会話レベルのスコアへと集約する。
AWSは、この問題を5ターンの営業レポート依頼で例示している。ターン2でエージェントは適切なアクションを選択するものの、期待されるパラメータが「revenue」であるところに「profit」を渡す。ターン3から5は、その誤った結果に基づいて処理を進める。
従来の失敗数では、4つのターンが壊れていると判断される。AEMは、ターン2に根本原因が1件あり、連鎖的な失敗が3件あると識別する。後続ターンには prior_action_failed というラベルが付けられ、その出力が以前のエラーに依存するため誤っていることを示す。
この帰属は、エンジニアリング上の解釈を変える。4件の失敗は、複数のプロンプト、ツール、あるいは推論ステップにまたがる弱点を示唆するかもしれない。一方、根本エラーが1件なら、特定の引数選択の問題を指し示す。
AEMは、同じ階層の下で2種類のターンを評価する。応答ターンにはユーザーに提示されるテキストが含まれる。アクションターンにはツール選択とその引数が含まれる。
応答ターンでは、完全性は回答が依頼で求められたすべてをカバーしているかを問う。真実性は、その主張が参照データと事実上整合しているかを問う。アクションターンでは、完全性は必須パラメータキーがすべて存在するかを確認する。真実性は、提供された値が意味的に正しいかを確認する。
アクションターンには構造的な検証も必要だ。評価器は、渡されたフィールドを判定する前に、エージェントが正しいツールとアクションを選んだかを判断しなければならない。引数オブジェクトの書式が完全でも、誤ったAPIへの呼び出しは救えない。
公開版ではターンの正確性を二値で扱う。各ターンは合格か不合格かとなるが、AWSによれば、同じ分解方法は個々の主張やフィールドの連続的な評価にも対応できる。デフォルトの総合スコアは、合格したターンの非加重割合だ。
このスコアは表層的な結果にすぎない。有用な情報はその下にある。失敗した評価軸、影響を受けたフィールド、最初の失敗ターン、根本原因数、連鎖数、チェーン長だ。そのためダッシュボードでは、正確性が低下したことだけでなく、真実性と完全性のどちらがその変化を引き起こしたかも示せる。
これが、マルチターン会話向けAgent Evaluation Metricの中心的な転換点である。低いスコアは、エージェントが多数の独立したエラーを生成したことを必ずしも意味しない。1つの初期判断が長い依存関係の連鎖を汚染した可能性がある。
結果スコアは、エンジニアが修正すべき失敗を隠す
結果スコアはワークフローが成功したかを答え、ターン帰属はなぜ失敗したかを答える。本番運用チームには両方の答えが必要だ。
最終状態の評価には依然として価値がある。サポートエージェントが正しい返金を実行したか、しなかったか。リサーチエージェントが根拠に基づくレポートを作成したか、しなかったか。スケジューリングエージェントが意図されたカレンダー項目を変更したか、それとも別のものを変更したか。
問題は、その判定が診断のすべてになったときに始まる。失敗した最終状態は、誤ったツール、欠落した引数、不正確な値、不完全な応答、あるいは不適切な出力が下流全体を汚染した上流アクションによって生じうる。これらの原因には、それぞれ異なる修正が必要だ。
ツールの不一致は、ルーティング指示やツール説明の問題を示す可能性がある。パラメータの欠落は、スキーマの曖昧さを露呈させる。値の誤りは、コンテキスト選択、推論、参照データの弱さを示す可能性がある。不完全なユーザー応答は、すべてのツール呼び出しが成功していても、提示方法の失敗を明らかにする。
1つの総合スコアは、こうした欠陥をまとめてしまう。リリースを比較する際にも、チームにほとんど手掛かりを与えない。たとえば、新しいモデルが旧バージョンと同じタスク成功率を出したとする。それでも、ツール選択エラーの減少と引き換えに、不完全な応答が増えている可能性はある。
この入れ替わりは本番環境で重要だ。下書きレポートの副次的な詳細を見落とすことは、金融システムに誤った金額を送ることとは異なる。同じ集計スコアが、異なるリスクを隠す場合がある。
階層化された評価の必要性は、すでにエージェントエコシステム全体に見られる。evaluation architectureの最近の説明では、テストをruns、traces、threadsに分けている。Runsは個々のモデルまたはツール操作を扱う。Tracesは1回の完全なエージェントターンを扱い、threadsはマルチターン会話を扱う。
この構造はAEMの主張を補完する。会話レベルの評価は、ユーザーの目的がインタラクション全体を通じて維持されたかを明らかにする。ターンレベルの証拠は、振る舞いがどの瞬間、どの評価軸で逸脱したかを明らかにする。
先行ベンチマークは、対話的な振る舞いが独自の評価領域に値する理由を示した。AgentBench researchは、8つの環境で27モデルをテストし、失敗を長期的推論、意思決定、指示追従と関連付けた。これらの特性は、1つの洗練された回答ではなく、対話を通じて現れる。
tau-bench paperは、さらに小売および航空会社の環境でユーザーとエージェントの会話をシミュレーションした。結果として生じるデータベース状態を注釈付きの目標状態と比較し、反復試行における一貫性を測定した。その初期実験では、主要なfunction-callingエージェントが完了できたタスクは半数未満だったと報告している。
これらのベンチマークとAEMは異なる問いに答える。最終状態ベンチマークは、現実的な条件下でエージェントが必要な結果に到達したかを検証する。AEMは、どのターンで最初に正確性が損なわれ、その損害がどう伝播したかを調べる手段を提供する。
どちらの視点も、もう一方を置き換えるべきではない。エージェントは予想外だが有効な経路を取り、それでも正しい状態に到達する場合がある。硬直的な軌跡比較は、その柔軟性を罰するおそれがある。逆に、正しい最終回答であっても、たまたま回復できた危険または不安定な経路を隠している可能性がある。
実務的な対応は階層化スコアリングだ。チームはリリース判断のために結果チェックを維持し、その後、診断にはターンレベルの評価軸とトレースを用いることができる。厳密なアクション順序は、順序が正確性や安全性に影響する場合にのみ適用すべきだ。
これはAWSの提案から圧力を受ける対象も変える。評価ベンダーと社内プラットフォームチームは、単一の成功率を超えなければならない。エージェント開発者は、より豊富な参照データを維持しなければならない。プロダクトオーナーは、1つの混合された品質指標を受け入れるのではなく、どの評価軸に個別のゲートを設けるべきかを決めなければならない。
マルチターン会話向けAgent Evaluation Metricが最初の破綻を見つける方法
AEMは、完全な軌跡の中で各ターンを比較し、型付けされた失敗を割り当て、アクション間の依存関係を保持することで機能する。
プロセスはゴールデンデータセットから始まる。これは期待される振る舞いを定義する、レビュー済み会話の集合を意味する。各例に必要なのは最終回答だけではない。正しい応答内容、期待されるツール、必須パラメータ、有効な値、ターン間の依存関係も含めるべきだ。
AWSは、人間によるアノテーション、またはより強力なモデルが参照データの初期作成を支援する場合の人間レビューを推奨している。この要件は大きい。基盤となるゴールドレコードが曖昧または誤っている場合、分解可能な評価器は意味のある診断を生成できない。
評価器はまずターンの種類を定める。応答ターンは網羅性と事実的一貫性について判定される。アクションターンはツール選択、必須キー、意味的に正しい値について判定される。
AEMは、完全一致の文字列比較では脆弱すぎる場合に意味的比較を用いる。「NYC」と「New York City」は同じ値を表せる。「Third quarter revenue figures for 2024」と「Q3 2024 revenue」は、文字列が完全に一致しなくても対応しうる。
AWSの概念例では、設定可能なしきい値の背後に意味的スコアラーを置き、完全一致を高速パスとしている。スコアがしきい値を上回れば合格する。しきい値を下回れば真実性の失敗となる。
しきい値の選定は、普遍的な定数ではなくプロダクト上の判断となる。厳格な評価器は、無害な表現の違いによって誤った失敗を生成する。緩い評価器は、関連して聞こえてもタスクの意味を変える値を受け入れてしまう。
カレンダーアシスタントでは、「tomorrow afternoon」を確認が必要な時間帯として扱うかもしれない。レポーティングシステムでは、正確な会計期間が必要になる場合がある。コンプライアンスワークフローでは、文字どおりの識別子が求められることがある。1つの意味的しきい値で、あらゆるドメインのリスク許容度を表現することはできない。
完全性にも同様に文脈への依存がある。ゴールデン軌跡で使用されていたというだけで、任意パラメータを失敗扱いにすべきではない。必須フィールドは便利なフィールドと区別しなければならない。そうしなければ、評価器は成功した実行ではなく、参照データの模倣を報いることになる。
失敗分類は、これらの判断を検査可能にする。AWSは、ツールまたはアクションの不一致、パラメータの欠落または過剰、矛盾するパラメータ値、不完全な応答、矛盾する応答のカテゴリを挙げている。各ラベルは構造チェックまたは正確性サブメトリクスのいずれかに対応する。
次に、依存関係の帰属によって、元々の障害と継承された障害を分離する。あるターンが prior_action_failed を受けるのは、正しい上流情報があれば合格していた場合に限られる。この条件は重要だ。以前の失敗の後であっても、後続ターンには新たな独立したエラーが含まれる可能性がある。
たとえば、リサーチエージェントがターン2で誤った文書を取得したとする。その後、ターン3でその文書を正しく要約する。ターン3はユーザーの目的に照らせば誤っているが、局所的な変換自体は有効かもしれない。AEMは取得判断を根本原因として、要約を継承された失敗として記録すべきだ。
では、4番目のターンが取得済み文書には存在しない統計を捏造したとします。このハルシネーションは単なる継承ではありません。すでに軌跡が破綻していたとしても、新たな根本原因を導入します。
したがって、信頼できる帰属には明示的な依存関係ロジックが必要です。最初のエラー以降のすべてのターンを単純に連鎖としてラベル付けすれば、独立した失敗を過少に数えることになります。AEMの価値は、評価者が継承された状態と新たな誤りを区別できるかどうかにかかっています。
このフレームワークは、アクションチェーンの長さも記録します。AWSはチェーンを、単一呼び出し、2ステップ、3ステップ以上の複雑なシーケンスに分類しています。チェーンが長くなるほど、初期の欠陥が後続の作業に影響する機会が増えるため、根本原因の帰属がより有用になります。
計算後、この構造化出力はダッシュボードや回帰チェックに活用できます。チームは、全体の成功率、正確性の次元、根本原因の種類、チェーン長によってモデルバージョンを比較できます。総合スコアがほとんど動いていなくても、ツールの不一致が増加したことでリリースを不合格にすることも可能です。
AWSはこの手法をフレームワーク非依存として提示する一方、Strands Agents evaluation SDKとの統合も示しています。custom evaluator docsでは、トレースを収集し、追加の評価器を実行できる周辺評価システムについて説明しています。
この可搬性は重要です。この提案は、AWS固有の機能というより、測定パターンとしての方が有用です。中核となる流れは安定しています。すなわち、次元を定義し、各ターンを採点し、依存関係を帰属させ、結果を合成し、変化を監視します。
本当の争点は、診断と柔軟なエージェント挙動の両立にある
評価器が正しい経路を厳密に定義するほど、有効な代替経路を不当に罰するリスクは高まります。
エージェントは、複数の許容可能な経路を通じて同じ結果に到達できるため、決定論的なワークフローとは異なります。あるエージェントはポリシーを確認する前に顧客レコードを取得するかもしれません。別のエージェントはまずポリシーを確認し、必要な場合にのみレコードを取得するかもしれません。どちらの経路も有効になり得ます。
ゴールデン軌跡は、偶然にも1つの成功例を唯一受け入れられる挙動へと変えてしまうことがあります。この問題は、評価器がアクションの順序、選択したフィールド、あるいは中間的な文言を比較する場合に、さらに顕著になります。診断フレームワークには構造が必要ですが、硬直しすぎると評価は模倣テストへと変質します。
AWSは、意味的比較と順序不変のステップを認めることで、このリスクの一部に対処しています。チームは順序が重要ではないアクションを指定できるため、代替シーケンスにも評価が与えられます。このアプローチは役立ちますが、根底にある設計上の問題を解消するものではありません。
ゴールデンデータセットは、アノテーターが行った偶発的な選択をすべてではなく、不変条件を符号化すべきです。必須の結果、禁止されたアクション、不可欠なパラメーター、状態遷移は、単一の推奨トランスクリプトよりも強力な対象です。これらは正確性に必要な条件を示しながら、正当な変動の余地を残します。
ここで、結果のみを採点する方法の強みが維持されます。データベースの状態、生成された成果物、検証済みの外部効果は、経路を規定せずに成功を示すことができます。ターンレベルの評価器は、それらのチェックに基づいて失敗を説明すべきであり、それらに取って代わるべきではありません。
マルチターン会話向けのAgent Evaluation Metricも、意図的に限定した正確性の定義から始まります。真実性と完全性だけでは、安全性、指示の保持、計画品質、効率、ユーザー満足度、回復挙動をカバーできません。
エージェントは、機密データを公開しながら、すべての真実性チェックに合格する可能性があります。不必要な高リスクの呼び出しを行った後で、完全な回答を提供することもあります。また、直近の要求には従いつつ、5ターン前に設定された制約を忘れることもあります。
AWSは、正確性を拡張可能なパターンにおける最初の次元として説明しています。今後の取り組みではこの手法を安全性に適用し、さらに後には多言語・マルチモーダル評価を計画しています。これらの次元が導入され、検証を経るまでは、AEMをエージェント品質の完全な尺度として扱うべきではありません。
自動判定器は別の不確実性を加えます。意味的な採点は、埋め込みモデル、学習済みスコアラー、またはLLM判定器に依存する場合があります。いずれも、閾値への感度、ドメイン上の盲点、バージョンドリフトをもたらす可能性があります。
判定器が、人間のレビュアーと原則的な理由で意見を異にすることもあります。ドメイン専門家は、似た2つの表現が異なる業務上の意味を持つことを理解している場合があります。金融、医療、コンプライアンスでは、表面的には同等に見える値が許可されるアクションを変えることがあります。
AWSは、コストの大きいエラーについて、分解されたスコアを人間またはゴールドラベルと相関させることを推奨しています。Pearson相関またはSpearman相関により、自動スコアがレビュアーの判断を追随しているかを示せます。この検証は最終的な合成スコアだけでなく、各サブメトリクスに対して実施すべきです。
曖昧で重大なケースでは、人間によるレビューが引き続き必要です。目的はすべての判断を自動化することではありません。人間による判断が最も高い価値を持つ会話へ注意を向けることです。
より広範なagent-building guideも、モデル選択を最適化する前に評価ベースラインを確立することを推奨しています。また、人間の介入と多層的なガードレールを、信頼できるデプロイメントの要素として扱っています。
AEMは、これらのベースラインをより有益なものにできます。しかし、組織がどのエラーを許容できるかを決めることはできません。真実だが不完全な回答と、完全だが誤った回答はいずれも正確性を満たしませんが、事業上の影響は大きく異なり得ます。
非加重平均も同じ問題を導入します。すべての合格ターンが等しく寄与すると仮定するためです。本番運用の責任者は、リスクの高いアクション、重要フィールド、あるいは不可逆な状態変更に対する重み付けを、最終的には必要とするかもしれません。
チームは、分解した証拠を急いで圧縮しすぎないようにすべきです。単一の合成数値は傾向検出には有用ですが、リリース判断では依然として根底にある失敗の構成を確認すべきです。分解は、人々がその情報を保持して初めて価値を生みます。
AEMは回帰に関する議論を変える
ターンレベルの帰属により、品質低下を具体的な失敗クラスと発生箇所に結び付けられるため、モデル比較が実行可能になります。
エージェントチームは、プロンプト、モデル、ツールスキーマ、検索ロジック、メモリシステム、ポリシーを定期的に変更します。どの変更も、ワークフローの一部を改善する一方で、別の部分を損なう可能性があります。最終的な成功率だけでは、このトレードオフを説明するのに十分な解像度がないことが多いのです。
たとえば、小規模なモデルが全体の会話スコアを維持している一方で、3ステップのチェーンにおいて欠落パラメーターをより多く生成するとします。このパターンは、見かけ上の同等性が、より複雑な本番リクエストでは維持されない可能性を示唆します。エンジニアは、広範なデプロイメントの前に、こうしたチェーンを切り分けられます。
別のリリースでは、事実に関する応答エラーを減らしながら、アクションの不一致を増やす可能性があります。その場合、プロダクトオーナーは現実的な選択に直面します。誤ったツールを選ぶ頻度が高いなら、文章力が優れたモデルが必ずしもより安全なオペレーターとは限りません。
AEMの名前付きサブメトリクスは、安定した比較点を作ります。真実性は完全性と切り離して追跡できます。根本原因は、ツール、アクション、フィールド、会話の長さ、モデルバージョンごとにグループ化できます。
このフレームワークは運用上のトリアージにも対応します。多くの失敗ターンが1つの上流原因を共有する場合、チームは最初に失敗したアクションを優先できます。そのアクションを修正すれば、複数の下流の失敗を一度に取り除ける可能性があります。
これは、すべての赤いトレースを独立したインシデントとして読むより効率的です。また、より明確な責任分担も生みます。スキーマチームは欠落パラメーターを調査でき、検索チームは不正確なソース値を調べることができます。
知識集約型エージェントでは、トレース診断に、各アクション時点で利用可能だった情報を含める必要があります。チームには、バージョン管理されたプロンプト、取得したパッセージ、ツール応答、会話状態が必要です。その記録がなければ、評価器は失敗したターンを特定できても、モデルがなぜその選択をしたのかを明らかにできません。
この要件は、評価をナレッジマネジメントと結び付けます。検索可能なengineering knowledge baseは、チームがテスト証拠のそばに仕様、インシデントの知見、評価判断を保存するのに役立ちます。
本番事例は、ゴールデンデータセットを継続的に拡張すべきです。意外なユーザーリクエスト、ツール障害、曖昧な修正は、レビュー済みの回帰ケースになり得ます。これにより、評価は静的な実験室のスクリプトではなく、実際の挙動に沿ったものになります。
チームは、成功した代替経路も保存すべきです。失敗トレースは防ぐべきことを示し、多様な成功トレースは、評価器がどの程度の柔軟性を許容すべきかを明らかにします。脆弱な軌跡ルールを避けるには、両方が必要です。
組織における最大の変化は、リリースレビューにあるかもしれません。新しいエージェントのスコアが上がったかを問うのではなく、どの次元が改善したか、どこに新たな根本原因が現れたか、より長いチェーンの信頼性が低下したかを問えるようになります。
この議論を1つのダッシュボードタイルに要約するのは難しくなります。しかし、チームが実際に下す必要のある判断には、より近いものです。
AEMがAWSを超えて広がるかを示す3つのシグナル
チームが帰属を再現し、判定器を較正し、比較可能性を損なわずに拡張できて初めて、AEMは重要なものになります。
最初のシグナルは、人間がレビューした軌跡に対する根本原因ラベルの公開検証です。AWSの実例はメカニズムを明確に説明していますが、この投稿はAmazon Quick Suiteの本番環境における社内数値を報告していません。次に有用な証拠は、多様なドメインで最初の失敗ターンと連鎖ラベルに関する一致度を測定するものです。
高い一致度は、AEMがデバッグを短縮するという主張を強めます。頻繁な不一致は、依存関係の帰属がフレームワークの最も弱いリンクであることを示すでしょう。チームは、単純な線形チェーンと、分岐するワークフロー、再試行、回復の試みを分けて評価するものに注目すべきです。
2つ目のシグナルは、1つのフレームワークを超えた採用です。AWSはStrands Agentsとの統合を提供していますが、その方法論は可搬的であると説明されています。他のトレーシングおよび評価システムでの実装は、その分類法がターン、ツール呼び出し、状態の異なる表現でも維持されるかを検証することになります。
フレームワーク横断の採用は、共通定義も促進します。各プラットフォームが真実性、完全性、継承された失敗を異なる形で解釈するなら、スコアはローカルなものにとどまります。共通スキーマと参照ケースがあれば、比較の信頼性は高まります。
3つ目のシグナルは、正確性を超えると約束された拡張です。安全性は最も重要な試験になります。なぜなら、安全な挙動を単なる事実フィールドの比較として表現できるとは限らないからです。危険なアクションは、正しいパラメーターを使い、ユーザーの要求に従っていても、ポリシーに違反する可能性があります。
安全性への拡張が成功すれば、decompose-evaluate-composeという手法が質的に異なる次元を扱えることを示します。弱い拡張であれば、AEMは一般的なエージェント品質メトリクスではなく、焦点を絞った正確性デバッガーとして理解するのが最適だと示唆するでしょう。
開発者は、そのロードマップを待ってからテストを改善すべきではありません。まず、重要な会話をいくつか選び、結果、必須アクション、重要フィールド、依存関係の構造に注釈を付けます。エージェントを繰り返し実行し、最初の真のエラーと、それを継承した後続ターンを比較します。
最終状態のチェックを、ターンレベルの判定と併せて維持してください。意味的に曖昧なケースは、ドメイン専門家とレビューしてください。有効な代替経路を記録し、評価器が柔軟性を失敗と誤認しないようにしてください。
複数ターンの会話に向けた Agent Evaluation Metric は、診断の単位を見直すべきだという説得力のある主張を提示している。その持続的な価値は、独立したチームが何が最初に壊れたのかについて合意できるかどうかにかかっている。あらゆるエージェントチームにとって次の問いは具体的だ。ダッシュボードが会話の失敗を報告したとき、実際にその失敗を引き起こした判断を特定できるだろうか？
