本記事では、AWSのマネージドサービス「Amazon Bedrock AgentCore Evaluations」を使って、学習用にサンプルとして構築したAIエージェントを評価してみた内容を紹介します。
モチベーション
「AIエージェント元年」と呼ばれた2025年を経て、AIエージェント構築に関する案件を目にする機会がぐっと増えてきたように感じます。
自分自身も、ここ数年で複数のAIエージェント構築案件に携わってきました。
AIエージェントの構築自体は、フレームワークやマネージドサービスの充実もあって、以前より格段にハードルが下がってきたように感じます。
一方で実際の案件では、動くものができた後の継続的な改善・運用、いわゆるLLMOps的な仕組みづくりの部分でつまずくことが多いのが実情です。
そのLLMOpsを構成する要素の1つとして、「AIエージェントの評価」があります。
エージェントは会話が多段になり、ツール呼び出しも絡むため、従来のLLM単体の評価よりも見るべき観点も多いです。
評価ロジックを自前で作り込む選択肢もありますが、評価基盤をゼロから整備するのは骨が折れます。
そこで今回は、AWSがマネージドで提供する評価サービスAgentCore Evaluationsを使ってエージェント評価を試してみました。
AgentCore Evaluations概要
AgentCore Evaluationsは、AIエージェントのタスク達成度やツール利用の適切さなどを自動評価するマネージドサービスで、2026年3月にGAされました。
LLM-as-a-Judgeの仕組みで動作しており、収集されたトレースデータから、審判役のLLMが品質スコアを算出します。
評価の実行方式
評価の実行方式は、大きくオンデマンド評価とオンライン評価に分かれます。
| 実行方式 | 説明 |
|---|---|
| オンデマンド評価 | コードから任意のタイミングで呼び出し、その場でテストケースを評価する方式 |
| オンライン評価 | 本番環境に流れるトラフィックを継続的に監視し、自動で評価する方式 |
今回は、オンデマンド評価を利用して検証しました。
評価の指標
評価の指標には、あらかじめ用意されたBuilt-in evaluatorsと、独自の評価基準を定義できるCustom evaluatorsが存在します。
今回はBuilt-in evaluatorsを使って検証しました。
Built-in evaluatorsは、AIエージェントの品質をチェックするための汎用的な評価指標です。
Response Quality・Safety・Task Completion・Component・Trajectoryの5つのカテゴリに分かれています。
| カテゴリー | エバリュエーター名 | 評価観点 |
|---|---|---|
| Response Quality | Helpfulness | ユーザーが目的を達成する助けになっているか |
| Response Quality | Correctness | 回答内容が事実として正しいか |
| Response Quality | Faithfulness | 与えられた情報源やこれまでのやり取りと矛盾していないか |
| Response Quality | Response Relevance | 質問の論点からズレずに答えられているか |
| Response Quality | Context Relevance | 検索結果に、質問に答えるための情報が十分含まれているか |
| Response Quality | Conciseness | 冗長になりすぎず、必要な内容だけを伝えられているか |
| Response Quality | Coherence | 話の筋道が通っており、矛盾や飛躍がないか |
| Response Quality | Instruction Following | ユーザーからの指示をきちんと満たせているか |
| Response Quality | Refusal | 答えられるはずの質問を不必要に断っていないか |
| Safety | Harmfulness | 差別的・攻撃的・有害な内容を含んでいないか |
| Safety | Stereotyping | 特定の集団への偏見や決めつけを含んでいないか |
| Task Completion | Goal Success Rate | 会話全体を通してユーザーの目的を達成できたか |
| Component | Tool Selection Accuracy | その場面で呼び出すツールとして妥当だったか |
| Component | Tool Parameter Accuracy | ツールに渡したパラメーターが会話内容から正しく導かれているか |
| Trajectory | Trajectory Exact Order Match | 想定した順序・内容とツール呼び出しが完全に一致しているか |
| Trajectory | Trajectory In Order Match | 想定したツールが、余分な呼び出しを挟んでも順序通りに現れているか |
| Trajectory | Trajectory Any Order Match | 想定したツールが順序を問わずすべて呼び出されているか |
今回はこの中から、以下5つを使って評価しています。
- Helpfulness
- Correctness
- Faithfulness
- Goal Success Rate
- Tool Selection Accuracy
各エバリュエーターは、0〜1に正規化されたスコアと、その判定理由（reason）をセットで返します。
後述の検証結果では、このreasonをもとにスコアの背景を深掘りします。
Built-in evaluatorsで用いられる判定用のプロンプトについては、公式ドキュメントで公開されています。
例えばHelpfulnessでは、以下のような7段階の基準で判定するように指示しています。
あなたは、AIアシスタントの応答がユーザーにとってどれだけ役立ったかを、
ユーザー視点で評価する客観的な審査員です。
アシスタントの発言が、ユーザーが目標を達成・明確化する助けになっているかを判断してください。
重要:事実の正確性やバックエンドの処理内容は考慮せず、
純粋に「ユーザーの視点から見てその応答がどれだけ助けになったか」だけを評価してください。
重要:ツールの出力は、あなた自身の知識より常に優先されます。
ユーザーの目標は、ユーザーの最初のリクエストとその後の追加情報だけから推測してください。
# 会話コンテキスト:
## それまでのやり取り:
{context}
## 評価対象の発言:
{assistant_turn}
# 評価ガイドライン:
以下のスケールでアシスタントの発言の「役立ち度」を評価してください:
0. 全く役に立たない
- 意味不明・支離滅裂
- 目標達成の妨げになっている
- 誤った方向に誘導している
1. とても役に立たない
- 混乱や誤解を生じさせる
--- 中略 ---
6. 期待を超える
- 「とても役に立つ」水準であり、かつユーザー入力の質の問題やコンテンツの制約に関する
フィードバックが的確で、その制約の中でできる限りユーザーを目標に近づけている
- 「とても役に立つ」水準であり、かつユーザーの一般的な懸念を先読みして対応している
（実際のプロンプトは英語ですが、便宜上和訳しています。）
上記のプロンプトの通り、Helpfulnessは出力された内容が「正確かどうか」ではなく「ユーザーの目的に近づいたか」だけを見る指標だと分かります。
このように各指標ごとに、どのような観点を評価するかがLLMに指示されています。
AgentCore Evaluationsを使うメリット
後述するように今回はStrandsを使って検証していますが、Strands自体にもstrands_evalsという評価機能があります。
そのため単体で見ると、AgentCore Evaluationsの旨味は薄く感じるかもしれません。
それでも、改めて整理するといくつかメリットがあると思います。
- 評価ロジックをAWSに任せられ、自分でメンテしなくてよい
- 異なるフレームワークのエージェントを同じ評価基準で横断的に評価できる
- AgentCore Runtimeで稼働するエージェントであれば、CloudWatchに溜まるログをそのまま評価に使えるため、繋ぎ込みが容易
検証用に構築したAIエージェント
検証にあたり、以下のようなシンプルなAIエージェントを構築しました。
https://github.com/ko-koyama/spike-agentcore-evaluations
- フレームワーク: Strands Agents
- モデル: Claude Sonnet
-
搭載しているツール
-
python_repl: 計算を実行するツール -
get_temperature: 都道府県名を渡すと気温を返すダミーツール -
retrieve: 2026年9月に販売されているマクドナルドのハンバーガーメニューの栄養成分をRAGで検索するツール、バックエンドはBedrock Knowledge Baseで動作
-
アーキテクチャは以下の通りです。
検証用プロンプト
評価対象のエージェントが3種のツールを一通り使うよう、以下5つのテストケース（プロンプト）を用意しました。
| No. | プロンプト | 使用されるツール（想定） |
|---|---|---|
| 1 | 123 * 456 を計算して | python_repl |
| 2 | 東京都の気温を教えて | get_temperature |
| 3 | ビッグマックのカロリーを教えて | retrieve |
| 4 | ビッグマックとチーズバーガーのカロリーの差を教えて、その差がハンバーガーのカロリーの何倍かを小数点第2位まで教えて | retrieve → python_repl |
| 5 | コク旨ビーフデミグラコロのカロリーを教えて | retrieve |
5番目のプロンプトで尋ねている「コク旨ビーフデミグラコロ」は、Knowledge Baseのソースデータに含まれていないメニューとなります。
retrieveで検索しても該当情報が見つからないケースで、エージェントがどう振る舞い、AgentCore Evaluationsがそれをどう評価するかを見たかったため、あえて用意しました。
検証結果
応答とツール呼び出し
まずは、各プロンプトに対するAIエージェントの応答内容と、実際に使用されたツールについて見ていきます。
| プロンプト | 応答内容（概要） | 使用されたツール |
|---|---|---|
| 123 * 456 を計算して | 123 × 456 = 56,088です | python_repl |
| 東京都の気温を教えて | 現在の東京都の気温は28°Cです | get_temperature |
| ビッグマックのカロリーを教えて | ビッグマックのカロリーは524kcalです | retrieve |
| ビッグマック/チーズバーガー差分 | 両者のカロリー差は214kcalで、ハンバーガー（259kcal）の0.83倍です | retrieve → python_repl |
| コク旨ビーフデミグラコロのカロリーを教えて | コク旨ビーフデミグラコロのカロリー情報はナレッジベース内に見つかりませんでした | retrieve |
いずれのプロンプトでも意図したツールが使用されており、ハルシネーションも発生しませんでした。
また、5番目の「コク旨ビーフデミグラコロ」についても、ナレッジベースに該当情報が見つからなかった旨を正直に返せていることが確認できます。
評価スコア
続いて、各プロンプトに対する評価スコアを見ていきます。
| プロンプト | Helpfulness | Correctness | Faithfulness | Goal Success Rate | Tool Selection Accuracy |
|---|---|---|---|---|---|
| 123 * 456 | 0.83 | 1.0 | 1.0 | 1.0 | 1.0 |
| 東京都の気温 | 0.83 | 1.0 | 1.0 | 1.0 | 1.0 |
| ビッグマックのカロリー | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| ビッグマック/チーズバーガー差分 | 0.83 | 1.0 | 1.0 | 1.0 | 1.0 |
| コク旨ビーフデミグラコロ | 0.67 | 1.0 | 1.0 | 0.0 | 1.0 |
Correctness・Faithfulness・Tool Selection Accuracyは全問1.0で頭打ちになった一方、Helpfulnessだけは満点に届かないケースが多く、評価指標としての解像度の違いが見えました。
ここからは、いくつかのプロンプトについてHelpfulnessのreasonを具体的に見ていきます。
まず、満点だった「ビッグマックのカロリーを教えて」に対するHelpfulnessのreasonは以下の通りでした。
アシスタントの応答は、カロリー（524kcal）を見やすい表で明確に示し、この質問に直接答えている。
さらに、カロリーだけでなく他の栄養成分（中略）も含んでおり、絵文字を使った見やすい表形式で提示されている。
（中略）
これはユーザーのリクエストを完全に満たす、包括的でよくまとまった回答であり、カロリーを尋ねるユーザーにとって役立つことが多い付加的な栄養情報も提供している。
（プロンプトと同様に出力は英語ですが、便宜上和訳しています。）
質問に直接答えるだけでなく、他の栄養成分も添えて回答した点が、加点要素として評価されていることが分かります。
一方、満点に届かなかった「ビッグマックとチーズバーガーのカロリーの差」については、Helpfulnessが0.83でした。
応答は、個々のカロリーと差分を示す明確な表と、倍率についての明確な説明で構成されており、よくまとまっている。
（中略）
ツール出力に基づき、ユーザーの質問の両方の部分に完全かつ正確に答えている。
（中略）
不要な情報を加えることなく、結果を明確で読みやすい形式で提示しており、これはユーザーの目的を完全に満たしている。
内容自体は問題ないと評価されつつ、前述の「ビッグマック単体」のケースのような付加情報がないため、満点の一歩手前にとどまったと考えられます。
一方「コク旨ビーフデミグラコロ」は、Helpfulness 0.67、Goal Success Rate 0.0という、他とは異なる傾向のスコアになりました。
Helpfulness
アシスタントの応答は、ナレッジベースに情報が見つからなかったことを明確に伝えたうえで、妥当な説明（期間限定商品である可能性）を示し、正確な情報を得るために公式のマクドナルドWebサイトへ誘導している。
（中略）
これは「Somewhat Helpful」から「Very Helpful」に相当する応答であり、直接的な答えは提供できていないものの、制約の中でユーザーに提示できる最善の次の一手を示している。
Goal Success Rate
ナレッジベースに「コク旨ビーフデミグラコロ」に関する情報が含まれていないため、AIアシスタントはカロリー情報を提供できなかった。
（中略）
ユーザーは求めていたカロリー情報を得られなかったため、目的は達成されていない。
同じ「情報が見つからず正直に伝えた」という応答に対して、Helpfulnessは「次の一手を示した点」を評価して0.67を付けた一方、Goal Success Rateは「そもそもユーザーの目的（カロリーを知ること）が達成されていない」ということで0.0となっています。
特に5番目のプロンプトでは、指標によって見ている観点が明確に異なることが、スコアの対比からよく分かりました。
まとめ
今回は、AWS AgentCore Evaluationsを使って、自作のAIエージェントを評価してみました。
Built-in evaluatorsを使うだけで、多角的な観点からエージェントの応答を自動評価できる点は、マネージドサービスならではの手軽さだと感じました。
特に、先述の「コク旨ビーフデミグラコロ」のケースのように、HelpfulnessとGoal Success Rateが似たような失敗ケースでも全く異なる評価軸でスコアを付けていた点は、複数指標を組み合わせて評価する意義を体感できました。
今回のような個人の検証・小規模スクリプトの範囲でも、評価の型ができた実感は得られました。
今後、複数フレームワークのエージェントを横断的に評価する場面や、AgentCore Runtime上での本番運用と組み合わせる場面では、さらに真価を発揮しそうだと感じています。