AIエージェントがすぐに返事をしても、その回答を業務で使えるとは限りません。監視画面では正常なのに、回答に含まれる数値の意味が違う。このずれを、リリース前にも運用中にも見つけたいところです。

2026年10月16日にAWSが公開したAgentCoreの評価フレームワーク事例は、この問題を開発から本番まで連続して扱っています。9段階という整理の中心にあるのは、評価基準を決め、その基準で変更を試し、本番の失敗を次のテストへ戻す流れです。

では、既知の質問で良い成績を出せれば、本番へ進めてよいのでしょうか。評価器、テストデータ、実行履歴をどう組み合わせれば判断できるのか、順に考えていきます。

顧客・期間・単位までそろえて、回答の正しさを測る

AWSの営業支援エージェントでは、公開前の評価で410.08ドルを410.08百万ドルと回答する誤りが見つかりました。通信や処理が成功していても、業務上の意味は大きく変わってしまいます。数値の文字列だけを比べても足りないわけですね。

この問題から始めるなら、正解を「自然な文章」ではなく、顧客、対象期間、指標、通貨・単位が一致している状態として定義すると、評価を実装しやすくなります。これは事例を自分のシステムへ適用する際の設計上の提案です。問い合わせの目的によって、必要な項目は変わります。

AgentCoreには、LLMが採点する組み込み評価器と、独自の評価方法を定義するカスタム評価器があります。カスタム評価器ではLLMの採点基準を指定する方法に加え、AWS Lambdaでコードを実行する方法も選べます。評価器の公式ドキュメントが、この役割分担を説明しています。

顧客IDや確定した金額なら、コードで一致を判定できます。一方、説明が質問に答えているかは、評価基準を言葉で定めてLLMに採点させる候補です。両者の点数を最初から一つに混ぜず、「事実が一致したか」と「説明が役立つか」を残しておくと、修正先を考えやすくなります。

既知ケースの再生で、ツールの不具合と回答生成の不具合を分ける

評価基準ができたら、それを繰り返し測るための質問と期待結果を用意します。こうした基準データがゴールデンセットです。AWSの事例では、ツール、個別エージェント、複数エージェントの連携それぞれを評価対象にしています。

顧客IDを取り違えたツールから情報を受け取れば、後段の文章が自然でも回答は誤ります。逆に、取得したデータが正しくても、回答の組み立て方で意味が変わることがあります。最終回答だけで不合格を数えるより、途中の境界でも期待結果を持つ方が、原因を絞りやすいと考えられます。

事例のリリース前評価では、検証済みのツール応答を固定して候補へ再生しています。この方法なら、比較中に外部データが変わる影響を抑え、同じ材料から候補がどう回答したかを比べられます。ただし、固定応答のテストだけでは、本物の接続先の遅延やデータ更新後の挙動までは判断できません。

導入するなら、まず影響の大きい既知ケースを変更時に実行し、公開前には対象を広げる構成が考えられます。合否には正解率だけでなく、応答時間とコストの許容範囲も持たせたいところです。例えば、平均点が上がっても特定の顧客群で失敗が増えていれば、その変更をそのまま採用する理由にはなりません。

本番の未知の質問には、正解付きテストとは別の評価が必要になる

固定した問題を通過しても、実際の利用者が同じ聞き方をするとは限りません。さらに、コードを変えずに参照データだけが更新される運用もあります。リリース判断に使うテストと、稼働中の変化を見つける評価には、それぞれ出番があります。

AgentCoreの評価方式は、評価対象を選ぶ方法と実行の仕方が異なります。

評価方式	対象と実行の仕方	運用での使いどころ
オンデマンド	選んだ実行履歴を指定して評価	変更前後の比較、失敗した応答の調査
バッチ	CloudWatch Logs内の複数セッションを非同期ジョブで評価	まとまった対象の回帰評価、定期的な品質点検
オンライン	本番セッションをサンプリング・フィルタリングして評価	テストにない入力を含む品質の変化の検出

ただし、同じ評価器をすべての方式へ無条件に持ち込めるわけではありません。期待する回答やアサーション、ツール実行順序を表す正解データのプレースホルダーを使うカスタム評価器は、オンライン評価には設定できません。本番入力にはその正解データがないためです。カスタム評価器の制約に明記されています。

そのため、正解付きの既知ケースで測る結果と、実トラフィックから測る結果は、母集団や採点条件を区別して扱う設計が必要です。監視のサンプリング率も、検出したい失敗の頻度と評価量を踏まえて決めます。サンプルに現れなかった失敗まで、スコアが保証してくれるわけではありません。

CloudWatchの履歴と採点結果を結び、評価の欠落も見つける

評価で低い点が出たら、次に知りたいのは原因です。そのためには、質問、ツール呼び出し、返された情報、最終回答という実行の流れへ戻れる必要があります。履歴を集める処理と、その履歴を採点する処理を接続して、初めて調査に使える状態になります。

AWSのオンデマンド評価の導入手順では、適切なIAM権限、モデル呼び出し権限、CloudWatch Transaction Search、対応する計装などを準備します。掲載されたPythonの手順はPython 3.10以降とADOTライブラリを前提としています。ログの反映には時間がかかるため、呼び出し直後に履歴が空でも、回答が正常だったとは判断できません。

さらに、評価APIの結果には成功と失敗が混在する場合があります。モデルのタイムアウトなどで採点できなかった結果を除外して平均点だけを表示すると、評価対象を十分に測れたのかが見えなくなります。同じ結果の説明で、部分的な失敗とエラー情報の扱いを確認できます。

ここから実装へ落とし込むなら、品質スコアに加えて、評価予定件数、採点できた件数、採点エラーを並べるのが一案です。低いスコアは回答改善の入口、採点の欠落は評価基盤の調査の入口として分けると、担当者が次に取る行動も明確になります。

本番で見つけた失敗を、次のリリースを止めるテストへ戻す

原因を修正した後も、その失敗を再現するケースが残っていなければ、次の変更で同じ問題が戻る余地があります。AWSの9段階の枠組みも、低評価の実行履歴を基準データへ追加し、改善を次の評価につなぐところまで含んでいます。

製品側では、AgentCore optimizationが、実行履歴と対象評価器からシステムプロンプトやツール説明の改善案を生成します。また、Gatewayでトラフィックを振り分け、オンライン評価で候補を比較するA/Bテストも用意されています。提案された変更を、そのまま良い変更とみなすのではなく、検証へ進める材料として使えます。

まず自分たちの業務で誤ると困る一つの項目を決め、期待結果と判定方法を作り、その失敗がリリースを止めることを確かめる。そこから本番の履歴と改善を接続していくのが、取り組みやすい順序です。

冒頭の「既知の質問で良ければ公開してよいか」という問いには、既知ケースでの合格だけでは運用中の品質を判断しきれない、と答えられます。変更を止めるテストと、本番で新しい失敗を拾う評価を往復させることで、回答の正しさを継続的に判断できる運用へ近づけます。

出典

• Title: Building trust in AI agents: A production-ready evaluation framework with Amazon Bedrock AgentCore
• URL: https://aws.amazon.com/blogs/machine-learning/building-trust-in-ai-agents-a-production-ready-evaluation-framework-with-amazon-bedrock-agentcore/