Amazon AgentCore Evaluations、従来の監視では見逃す障害に挑む

Amazonは、健全なインフラがエージェントの回答品質の低下を覆い隠し得ると判断し、Amazon AgentCore evaluations向けの9段階フレームワークを公開した。レイテンシーは通常どおりで、エラー率も横ばいのままかもしれない。エージェントは応答し続ける一方、自信に満ちた回答が誤った数値や顧客を参照する可能性がある。

この対立が重要なのは、従来の監視が主に、目に見える技術的痕跡を残すソフトウェア障害を検出するためだ。自律型エージェントでは、アプリケーション自体は動作していても、推論、ツール選択、結論の信頼性が低下するという意味論的な障害が生じる。

AWSは、このフレームワークを、販売担当者と営業リーダーが利用する社内マルチエージェントシステムを軸に構築した。専門エージェントは、共有の会話型体験を通じて、パフォーマンス、顧客、構造化データに関する質問へ回答する。1つの劣化したツールやサブエージェントが、アプリケーションをクラッシュさせることなく最終回答を汚染し得る。

このフレームワークは、ローンチ前にエージェントを評価する考え方から、その振る舞いを継続的に評価する考え方への転換を示す。開発実験、デプロイゲート、本番カナリア、敵対的チェック、ドリフト検出、可観測性、自動レコメンデーションを結び付ける。

真の対抗相手は別のクラウドプロバイダーではない。稼働率、レイテンシー、成功したリクエストがエージェントの健全性を示す十分な証拠になる、という馴染み深い前提だ。Amazonの事例は、こうしたシグナルが示すのは可用性であり、正しさではないと論じている。

Amazon AgentCore Evaluations、品質をリリース条件にする

重要な変化は、AWSが回答品質を最終テスト工程ではなく、運用上の統制として扱っている点にある。

AWSは2026年10月16日、社内の本番システムでの取り組みに基づき、このフレームワークを公開した。このシステムには、異なるビジネス上の質問に対応するPerformance Insights、Customer Insights、Data Insightsの各エージェントが含まれる。

Performance Insights Agentは、テリトリー範囲の収益およびパフォーマンスに関する質問を扱う。Customer Insights Agentは、製品利用状況、サポート、契約、エンゲージメントのシグナルを統合する。Data Insights Agentは、自然言語の質問を構造化データセットに対するSQLクエリへ変換する。

これらのエージェントは1つのインターフェースの背後で動作するが、障害面はそれぞれ異なる。顧客解決ツールが誤った子会社を選ぶことがある。検索コンポーネントが弱いコンテキストを返すこともある。オーケストレーターはリクエストを正しくルーティングしながらも、統合時にサブエージェントの調査結果を歪める可能性がある。

そのためAWSは、システムを3つのレベルで評価する。ツールレベルのチェックでは、検索、エンティティ解決、SQL生成といった能力を検査する。エージェントレベルのチェックでは、各専門エージェントをリクエストから応答まで採点する。マルチエージェントのチェックでは、ルーティング、コンテキスト転送、最終統合を評価する。

各レベルには、それぞれ独自の評価データセット、しきい値、昇格基準が設定される。この構造が重要なのは、良好なエンドツーエンド平均が障害中のコンポーネントを隠し得るためだ。障害は特定の顧客セグメント、クエリ種別、あるいはオーケストレーション経路にだけ影響する場合がある。

このフレームワークは、ライフサイクル全体を通じて5つの次元も測定する。安全性、品質、パフォーマンス、コスト、運用統制だ。品質が最も詳細に扱われるが、AWSは安全性もリリース要件であり続けるとしている。

9つの段階は、定義、実験、マージ、ゲート、カナリア、敵対者、ドリフト、パルス、改善という閉ループを形成する。これらの段階は、最初のコミットから本番監視、その後の改訂までをカバーする。

AWSはこれらを、制御された評価モードとライブ評価モードをサポートするAgentCore Evaluationsを通じて接続する。オンデマンド評価は、選択したデータセット、トレース、またはセッションに対して実行される。オンライン評価は、本番インタラクションを継続的にサンプリングする。

この連続性が重要な製品上の主張だ。チームは、デプロイ前とユーザーがエージェントに接した後の両方で、同じ評価器を適用できる。ソフトウェアが本番境界を越えたというだけで、評価基準が変わるべきではない。

AWSはAgentCoreをCloudWatch、S3、Redshift、Lambda、Amazon Quickとも組み合わせている。これらのサービスは、トレース、評価器出力、永続化、カスタムスコアリング、アラーム、ダッシュボードを処理する。

これは新しい基盤モデルやエージェントアーキテクチャではない。エージェントが利用に適した状態を保っているかどうかを判断するための運用モデルだ。この限定的な変化は、デモンストレーションの段階を超えようとする企業にとって、より大きな影響を持つ可能性がある。

9段階フレームワークは最初のテスト実行前に始まる

Amazonのフレームワークは、ビジネス上の観点で障害を定義することから始まる。品質目標が未定義であれば、その後のすべてのゲートが恣意的になるためだ。

第1段階では、評価契約を確立する。チームは、ビジネス成果、評価指標、障害しきい値、安全ポリシー、レイテンシー予算、コスト目標、運用対応を定義する。

AWSの販売担当者にとって成功とは、適切な詳細度で、最新かつ正確なアカウントインテリジェンスを得ることを意味する。リーダーシップ層のユーザーには、大規模な手作業なしに信頼できる週次および事業横断レビューの入力が必要だ。

こうした成果は、測定可能な障害カテゴリーへと翻訳される。AWSは、指標の取り違え、誤った期間、誤ったエンティティ、裏付けのない数値、不正確な記号、許可されていない計算を挙げている。

この分類は、単一の一般的な正確性スコアよりも実行に移しやすい。合格率の低下は何かが変わったことを示す。カテゴリー別の結果は、問題が検索、エンティティ解決、時間解釈、書式設定、生成された推論のどこにあるかを示す。

AWSは、単一の採点方法ではあらゆるリスクをカバーできないため、複数の評価器タイプを組み合わせている。組み込み評価器は、関連性、忠実性、有用性、指示追従、ツール選択を扱う。カスタマイズされた評価器は、ドメイン固有のエラーを対象とする。

決定論的チェックは、出力を正確な期待結果と比較する。アカウント識別子、契約日、収益値、SQL結果、構造化形式に適している。LLM-as-a-judge評価は、複数の応答が合理的にリクエストを満たし得る場合に、モデルとルーブリックを用いる。

この区別は不可欠だ。単純な比較でより適切に機能する正確な識別子の検証を、別のモデルに委ねれば不確実性が加わる。ニュアンスのある推論を正確な文字列一致で採点すれば、逆の問題が生じる。

AWSは、サードパーティの評価器ライブラリとゴールデンセットも利用している。これは期待される振る舞いを伴う代表的なクエリをバージョン管理したコレクションを意味する。このセットには、本番由来の例、以前のリリースで発生した障害、構成されたエッジケースが含まれる。

ツールレベルでは、ゴールデンセットが顧客識別などの能力をテストする。エージェントレベルでは、AWSは包括的な質問、レポーティングの質問、推論を要する質問、曖昧な質問を対象にする。本番障害は恒久的な回帰ケースになり得る。

第2段階では、提案された変更を同じ評価契約に照らして比較する。プロンプトの改訂、モデルの置き換え、ツールの追加、データセットの更新はすべて、マージ前にオンデマンド評価を通過する。

この比較は、品質、レイテンシー、コスト、トークン消費にまたがる。正確性を高めつつ応答時間とコストを大幅に増加させる候補が、自動的に勝者となるわけではない。このフレームワークは、そうしたトレードオフを意思決定記録に組み込む。

AWSによると、3か月間の重点的な反復により、合格率は93%から96%へ上昇した。また、純粋なハルシネーションは1万件の応答あたり138件から52件未満へ減少したとしている。

許可されていない計算は、1万件の応答あたり59件から44件未満へ減少したと報告されている。これらの数値はAWSの社内説明に基づくものであり、独立監査は受けていない。

この留保は重要だ。情報源は技術的なケーススタディであると同時に、製品を支持する主張でもある。結果は、AWSが1つの環境で達成したとしている内容を示すものであり、エージェントの信頼性に関する普遍的なベースラインを確立するものではない。

それでも、この評価設計はAWSの外でも有用である。チームがプロンプト、モデル、検索システム、オーケストレーションの変更を比較するには、その前に許容可能な振る舞いについて共通の定義が必要だ。

この契約を文書化することは、組織の記憶も生み出す。検索可能なengineering knowledge baseを利用するチームは、実装メモとともに、障害定義、評価判断、インシデント証拠を保存できる。

CIゲートとカナリアは異なる障害ウィンドウを攻撃する

リリース前のゲートは既知の回帰を止める一方、本番カナリアはデプロイが引き起こしていない品質低下を探す。

第3段階では、より小規模なセンチネルデータセットを継続的インテグレーションに組み込む。AWSは、コード、プロンプト、モデル、ツール、設定の変更を含むステージングデプロイ後、このセットを自動実行する。

センチネルは、品質、安全性、レイテンシー、コストにまたがる高リスクシナリオを重視する。完全なゴールデンセットより高速に実行できるため、頻繁なチェックに適している。しきい値を超えた場合、デプロイをブロックできる。

AWSは、ツール、エージェント、マルチエージェントワークフローごとに別個のセンチネルを維持している。最終的なエージェントスコアが許容範囲に見えるだけでは、リリースは通過できない。重要なツール内の回帰は、それだけで昇格を停止できる。

同社は、顧客名の解決に影響したデータ正規化変更について説明している。このツールは特定の形式で未解決のエンティティを返し、エージェントは一致する顧客を推測した。この振る舞いには、誤ったアカウントに関する正確なデータを返すリスクがあった。

決定論的なエンティティ解決ケースが、本番前に問題を捉えた。この例は、エージェントのテストが最終的な文章より下の層を見る必要がある理由を示している。流暢な回答であっても、機能的には不正確であり得る。

第4段階では、リリースチェックを完全な品質ゲートへ拡張する。AWSは、完全なゴールデンセットに対して候補を評価し、凍結したツール応答を使ってエージェントの振る舞いを分離する。

このリプレイ設計は、ライブツールの可用性や変化するソースデータを比較から除外する。各候補は同じ検証済みツール出力を受け取る。そのため、スコア差は環境変動ではなく、エージェントの推論を反映するはずだ。

AWSによると、そのエンドツーエンドゲートには200件のホールドアウト質問が含まれる。候補は、集計スコアが後退した場合、本番ベースラインに届かなかった場合、またはしきい値を下回る個別質問が多すぎる場合に失格となる。

最後の条件は、平均値が局所的な被害を隠すことを防ぐ。モデルは一般的な質問では改善する一方、特定の地域、顧客タイプ、リクエスト形式に対して信頼できなくなる可能性がある。

第5段階では、環境が変わる。カナリアはライブトラフィックと合成ケースを対象に本番で実行され、外部依存関係やデータ変更によって生じる障害を探す。

AWSは30分の評価ウィンドウを選んだ。15分ウィンドウでは過剰な誤警報が発生し、60分ウィンドウでは実際の低下の確認が遅れたとしている。

1回の失敗ウィンドウも運用上のシグナルとして扱われる。AWSは、3つの連続ウィンドウがしきい値を超えた場合にのみオンコールチームへページングする。別途、毎日の実行ではリリースゲートのしきい値でゴールデンセット全体を評価する。

この設計は、感度とアラーム疲れの均衡を図るものだ。カナリアは、エンジニアがノイズの多い通知を無視するようになることなく、持続的な品質低下を検出すべきである。

AWSは、検索インデックスの更新に関する例を挙げている。更新されたツールは、質問で求められる正確なコンテキストではなく、広く関連する文章を返した。

インフラストラクチャの指標は正常に見えた。レイテンシーは想定の範囲内に収まり、技術的なエラー率もゼロのままだった。その一方で、エージェントは弱い根拠に基づきながら、洗練された回答を出し続けていた。

カナリアは、最初の評価ウィンドウでグラウンディングと検索精度の低下を検出した。その後、トレースによって低スコアの原因が検索ツールにあることが明らかになった。

これが、このフレームワークにおける重要な逆転である。リクエストの成功はプロダクトの失敗を意味し得る一方、技術的に健全な依存コンポーネントであっても回答品質を低下させる可能性がある。

AWSとMotorwayによる別の実装は、もう一つの具体的な参考例を示している。同社の本番運用ブループリントでは、不正確な検索結果が8件に1件から50件に1件へ減少したと報告されている。

Motorwayのエージェントは、販売店が自然言語で車両在庫を検索できるよう支援する。その評価パイプラインは、繰り返し実行を通じてツール利用、推論、出力品質を検証する。AWSによれば、問題検出に要する時間は数時間から数分へ短縮された。

この2つの事例を直接比較することはできない。対象ユーザー、データセット、障害の定義、アーキテクチャがそれぞれ異なるためだ。しかし両者は、リリーステストと本番環境での評価が別個の課題を解決する理由を示している。

ライブ評価が静的テストセットの限界を明らかにする

ゴールデンセットは既知の失敗を防ぐが、実際のユーザーは設計者が想定しなかった入力を絶えず生み出す。

第6段階は敵対的な挙動に対処する。AWSは、リクエストのスクリーニング、機密データの保護、エージェントの指示を操作しようとする試みの検出のため、入力・出力制御を適用している。

このフレームワークでは、コンテンツフィルタリングとプロンプト攻撃の検出にBedrock Guardrailsを使用する。AWSによれば、これらのチェックは、応答がユーザーに届く前にすべてのトラフィックを同期的に対象として実行される。

脅威モデルには、直接的なジェイルブレイクの試みや、取得した文書に埋め込まれた指示が含まれる。また、内部プロンプトを抽出しようとする試みや、ユーザーの認可範囲を超えてデータを公開しようとする試みも対象となる。

AWSが正しく指摘するように、安全性は一つの段階に限定されない。ポリシーは基盤段階で定義され、統合とデプロイの段階でテストされ、その後本番環境で適用される。第6段階は、この敵対的対策の層を明示化する。

第7段階はドリフト、すなわち確立済みのベースラインと比べた持続的な挙動変化を対象とする。ドリフトは、データ更新、変化するユーザー行動、古くなった前提、またはゴールデンセットに含まれないロングテールのリクエストによって生じ得る。

AWSによれば、オンライン評価ではライブトラフィックの10パーセントをサンプリングしている。品質、レイテンシー、コストのスコアは、同じ30分間のウィンドウ構造を用いた品質状態の算出に反映される。

ある社内事例では、顧客識別が課題となった。合成テストでは、名前の表記ゆれ、子会社、略称をカバーしていた。一方で実際のユーザーは、ティッカーシンボル、略称、入力ミスも使用していた。

報告によれば、精度はあるウィンドウで98パーセントから81パーセントへ低下し、その後の2つのウィンドウでは80パーセントとなった。ローリング閾値を超えた後、CloudWatchがオンコールチームにアラートを送った。

AWSによれば、トレースはティッカーシンボルと略称の処理が主な失敗原因であることを示した。チームは正規化ロジックを更新し、低スコアのセッションをゴールデンセットへ追加した。

報告上、精度は次の評価サイクルでベースラインへ戻った。これもまた、独立して再現された結果ではなく、AWSが報告した運用上の成果である。

第7段階は、ライブトラフィックへの制御された公開も支援する。候補がオフラインのゲートを通過すると、ゲートウェイは現行バージョンと提案バージョンの間にリクエストの一部を振り分ける。

候補は、選択された評価軸全体で本番バージョンと同等以上の成果を出さなければならない。オフライン評価は既知のケースをテストする一方、ライブ比較では未知の表現や挙動が持ち込まれる。

このプロセスは、確立されたソフトウェアのカナリアリリースやモデル監視に似ているが、エージェントでは測定対象が広がる。チームは軌跡、ツール呼び出し、取得コンテキスト、最終回答、セッション結果を評価しなければならない。

この広い対象範囲は測定上の問題を生む。LLMベースの評価器は判断が一致しない場合があり、モデルのバイアスを引き継いだり、事業上の正確性を反映しない文体的な特性を高く評価したりする可能性がある。製品やユーザーの変化に伴い、ルーブリック自体が古くなることもある。

サンプリングにも別の限界がある。トラフィックの10パーセントを評価すれば処理コストは抑えられるが、まれで有害な失敗がサンプル外に落ちる可能性がある。集計スコアは、少数のユーザーグループを覆い隠すこともある。

プライバシーとデータガバナンスにも同等の注意が必要だ。本番トレースには、プロンプト、取得文書、ツール出力、アカウント識別子、その他の機密コンテキストが含まれる場合がある。保持・アクセス制御は、扱うデータに見合ったものでなければならない。

このフレームワークは安全性と運用管理を認識しているものの、実装の品質は依然として各組織に依存する。AgentCoreは評価インフラを提供するが、顧客に代わって許容可能な挙動や信頼できる正解データを定義することはできない。

Amazonのフレームワークがなお証明できないこと

Amazonの事例は継続的な評価を支持するが、自動評価器が信頼を完全に測定できることを証明するものではない。

最初の限界は、証拠の独立性である。主要なフレームワーク、実装、性能結果はいずれもAWSによるものだ。同社はシステムを運用し、支援プラットフォームも販売している。

この関係は結果を無効にするものではない。ただし読者は、報告された改善を、競合する評価スタックに対する中立的なベンチマークではなく、ケーススタディの知見として扱うべきである。

2つ目の限界は、評価器の妥当性に関するものだ。スコアが有用なのは、ユーザーが実際に価値を置く挙動と相関している場合に限られる。ルーブリックが誤った結果を測定していれば、精緻なダッシュボードは誤った安心感を生む可能性がある。

AWSは、事業目標から始め、決定論的な評価器、カスタマイズされた評価器、モデルベースの評価器を組み合わせることで、このリスクを減らそうとしている。それでもチームは、各評価器を専門家による人間レビューと照らして検証しなければならない。

評価者間一致度は有益な指標となる。評価器、領域専門家、ユーザーの判断が頻繁に食い違うなら、自動スコアだけでデプロイを管理すべきではない。AWSの投稿には、その一致度データは示されていない。

3つ目の限界はカバレッジである。このフレームワークは既知の失敗カテゴリをテストし、時間の経過とともに新たな本番ケースを取り込む。しかし、被害が発生する前にすべての新規挙動を検出できる保証はない。

ゴールデンセットには、間接的に最適化されるリスクもある。プロンプトやモデルを繰り返し変更することで、より広範な信頼性を実現せずとも、見慣れた例でのスコアだけが改善する可能性がある。ホールドアウトケースと定期的に更新されるデータセットは、このリスクを低減できる。

4つ目の限界はコストだ。継続的な評価には、モデル呼び出し、トレース保存、データ処理、ダッシュボード、エンジニアリング作業が追加される。AWSはクエリ当たりのコストと成功応答当たりのコストを追跡しているが、実装全体の総コストは公表していない。

小規模なチームは、すぐに9段階すべてを必要としないかもしれない。領域固有の失敗分類、重要な事実に対する決定論的テスト、リリースゲート、サンプリングされた本番レビューから始めることができる。

5つ目の限界は、修正措置を実行する権限である。第9段階は、失敗したトレースからシステムプロンプトやツール説明の改善案を生成できる。しかし、提案は安全な自律的変更と同じではない。

提案されたプロンプト改訂は、一つの失敗を直す一方で別の失敗を招く可能性がある。広範にデプロイする前に、同じ実験、マージ、ゲート、カナリアの手順を通すべきだ。

自動ロールバックにも慎重な境界設定が必要となる。プロンプトやモデルの復元は比較的限定的だが、業務システムにおけるエージェントの行動を取り消す場合、決済、メッセージ、記録、権限などが関係する可能性がある。

こうした懸念は、評価とガバナンスを分けるものだ。評価はエージェントが適切に振る舞ったかを推定する。ガバナンスは、エージェントに許される行為、保持すべき証拠、人間の承認が必須であり続ける領域を定める。

AWSのより広範なAgentOpsガイダンスは、評価をセキュリティ、バージョン管理されたアーティファクト、可観測性、人間によるレビューと並べて位置付けている。この枠組みは、単一のスコアを信頼の証明書として扱うよりも説得力がある。

信頼は、AgentCoreがエージェントに付与できる性質ではない。それは、結果、統制、インシデント対応、透明性に基づいて蓄積される判断である。評価はその判断に証拠を提供する。

したがって購入者にとって適切な問いは、プラットフォームが評価機能を提供しているかどうかではない。より難しい問いは、その測定が組織にとって実際の失敗コストをカバーし、変化の中でも信頼性を保てるかどうかである。

クローズドループが機能しているかを示す3つのシグナル

このフレームワークの価値は、評価器の信頼性、本番導入、フィードバックが未知のケースを改善することを示す証拠に左右される。

最初のシグナルは、自動評価器の独立した検証である。企業は、AgentCoreのスコア、領域専門家の判断、実際のユーザー成果の比較が公開されるかを注視すべきだ。

高い一致度は、評価によってリリースを統制できるというAWSの主張を強める。継続的な不一致は自動ゲートの有効性を弱め、人間によるレビューの必要性を高める。

比較は、一般的な有用性だけを対象とすべきではない。エンティティ解決、認可境界、ツール選択、根拠に基づく計算、セッション結果、マルチエージェントによる統合もテストする必要がある。

2つ目のシグナルは、AWSが執筆した事例を超えた導入である。規制産業、大手ソフトウェアベンダー、小規模なエンジニアリングチームからの本番報告は、9段階モデルがどの程度移植可能かを明らかにするだろう。

有用な報告では、データセットの構築方法、サンプリング率、誤報、見逃されたインシデント、修正時間、評価のオーバーヘッドを開示すべきだ。こうした詳細を伴わない改善率だけでは、得られる指針は限られる。

AgentCoreのオンライン構成は、エージェントエンドポイントまたは選択したCloudWatchロググループからのトレースを継続的に処理できる。オンライン評価コントロールは、設定可能な評価器、サンプリング、実行状態もサポートしている。

重要な導入指標は、有効化された構成の数ではない。ユーザーが報告する前にチームが意味的な失敗を検出し、新たなリグレッションを生まずにそれらを解決できるかどうかである。

3つ目のシグナルは、未知のトラフィックにおけるクローズドループの性能である。AWSによれば、そのレコメンデーションシステムはトレースを分析し、修正されたプロンプトや、より明確なツール説明を提案できる。

ある報告事例では、few-shotの例にハードコードされた値が、無関係な回答にも現れた。AWSはこれらの値をプレースホルダーに置き換え、ハルシネーションの減少とグラウンディングの強化を確認したとしている。

次の検証は、こうした提案が、それを生成したトレースだけでなく、ホールドアウトおよびライブのインタラクションも改善するかどうかである。すべての提案は、元の評価ループを通過すべきだ。

第8段階は、その検証の運用基盤を提供する。AgentCore Observabilityは、トレース、メトリクス、ログのオープン標準であるOpenTelemetryを通じて、構造化された実行データを記録する。

AWSによれば、そのダッシュボードはアラームを関連するエージェントトレースに結び付け、ツールの順序、入力、出力、レイテンシー、トークン使用量を確認できるようにする。評価器の結果は、別のパイプラインを通じてCloudWatchと長期保存先へ送られる。

同社は、平均検出時間が数日または数週間から4時間未満に短縮されたと報告している。また、ユーザーからの苦情が主なインシデントシグナルとなる前に、自動検出することを目標としている。

これらの結果は、このフレームワークが最も説得力をもって約束できる点を示している。Amazon AgentCoreの評価は、自律システムが常に正しく回答することを保証するものではない。しかし、静かな劣化を調査、阻止、あるいは元に戻せる程度まで可視化する。

開発者はまず、最も深刻な被害をもたらし得る誤答を特定すべきです。エンタープライズの購買担当者は、リリース前にその失敗をどう測定し、リリース後にどう検知するのかをベンダーに尋ねる必要があります。

ナレッジワーカーは、エージェントが自信ありげに語る場合でも慎重さを保つべきです。流暢な言葉遣いは、その応答の根拠となるツール、顧客、期間、情報源が正しいことを保証しません。

次世代のエージェントプラットフォームは、モデルへのアクセスやオーケストレーションだけで競争するわけではありません。チームが失敗を説明し、再現し、再発を防げるかどうかでも競争することになります。

すでに組織でエージェントを運用しているなら、最後にユーザーへ届いたインシデントを検証してください。レイテンシーやエラーの監視でそれを検知できたでしょうか。できなかったなら、そのギャップこそが実効性のある評価契約の出発点です。