Evaluate AI agents systematically with Agent-EvalKit｜Agent-EvalKit で AI エージェントを体系的に評価する | AIニュース最前線

AI エージェントを構築するチームは、通常、他のソフトウェアと同様に、出力が期待通りに一致しているかどうかを確認することで評価を行います。しかし、自律的にツールを選択し、複数のソース間で操作をシーケンス化するエージェントは、出力レベルのテストでは完全に特徴付けられない振る舞いを生み出します。 あるエージェントは、構造化され実用的な応答を提供しながらも、ツールの返却結果が空であったために事実を捏造するハルシネーションを起こす可能性があります。また、信頼性の高いプロセスに必要な検証ステップをスキップして正しい結論に達することもあります。これらの失敗は最終的な応答の表面の下に潜んでいるため、それらを捉えるには、エージェントが呼び出したツール、そのツールが返したデータ、そして応答がそのデータを忠実に反映しているかどうかを追跡する評価が必要です。 このギャップを埋めるには、多くのエージェントチームがゼロから構築するための人員を備えていないインフラストラクチャが必要です。正解（グランドトゥルース）を持つテストケース、ツール呼び出しと中間状態をキャプチャするための観測性（オバザビリティ）の計装、そして表面精度だけでなく忠実度やツールの使用状況を評価する指標が必要となります。 Agent-EvalKit は、[Claude Code](https://claude.com/product/claude-code)、[Kiro CLI](https://kiro.dev/cli/)、および [Kilo Code](https://kilo.ai/) といった AI コーディングアシスタントと統合することで、この評価インフラストラクチャをオープンソースツールキット（Apache 2.0 ライセンス）として提供します。これにより、評価をデプロイ後の別工程として扱うのではなく、開発環境全体にワークフローを組み込むことができます。自然言語で評価の目標を記述するだけで、ツールキットが各フェーズを処理し、エージェントのソースコードの読み込みからターゲットを絞ったテストケースの生成、評価の実行、そしてコードベース内の特定の場所を参照した改善推奨事項を含むレポート作成までを一貫して行います。以下のセクションでは、[Strands Agents SDK](https://strandsagents.com/) と [Amazon Bedrock](https://aws.amazon.com/bedrock/) を用いて構築された旅行調査エージェントを例に挙げながら、Agent-EvalKit が 6 つの評価フェーズ全体でどのように機能するかを順を追って解説します。 ## エージェント評価に必要なもの インフラそのものを選ぶこと以上に、何を測定するかを決めることも同等に困難です。エージェントの品質は、単一の指標では捉えきれない複数の次元にわたります：回答が実際にツールから返された結果に基づいているか、エージェントが適切なツールを正しいパラメータで呼び出したか、そして最終的な出力が質問者にとって整合性があり有用であるかなどです。回答は読みやすく見えても、空の結果に対して静かにハルシネーション（幻覚）を起こしている可能性があり、また、不具合のあるツール呼び出しの連鎖を通じて妥当な答えに到達するエージェントもあり得るため、各次元は隣接する指標から推測するのではなく、それぞれ独立して検証する必要があります。 単一の評価スタイルがこれら3つの側面すべてをうまく処理することはできません。コードベースの評価者は高速で再現性のある結果を提供しますが、アプローチの有効なバリエーションに対してペナルティを与える傾向があります。大規模言語モデル（LLM）を判事とする評価者は、追加の推論コストと慎重なプロンプト設計を要する一方で、微妙なニュアンスを含んだ評価を提供します。最も効果的な評価戦略は、これらの2つのアプローチを組み合わせたものです。評価スコアを具体的なコード変更へと翻訳することは、多くの取り組みが最終的に立ち往生するポイントであり、そのため評価ワークフローは数値のダッシュボードで終わるのではなく、特定のコードレベルでの推奨事項で完了する必要があります。 ## Agent-EvalKit の仕組み Agent-EvalKit は、独立した評価プラットフォームとして動作するのではなく、既存の AI コーディングアシスタントを通じて機能します。Claude Code、Kiro CLI、あるいは Kilo Code などのアシスタントが、コードを読み込み、評価プロセスの各段階におけるエージェントの振る舞いを推論する能力を活用することで、評価エンジンとなります。このワークフローは、/evalkit.plan や /evalkit.data といったスラッシュコマンドを通じて操作し、自然言語によるガイダンスを追加して、どの品質次元があなたのエージェントにとって最も重要かを指示します。この設計により、評価プロセスが開発環境内に留められ、エージェントの構築を支援する同じアシスタントが、その評価も支援することになります。 このプロセスは、エージェントのソースコードから始まります。ここでアシスタントはツールの定義、システムプロンプト、およびフレームワーク構成を読み込み、エージェントが何を行うか、どのツールを呼び出せるか、またどこで振る舞いに問題が生じる可能性があるかを詳細にモデル化します。評価計画から最終レポートに至るまで、このツールキットが後続の段階で生成するすべての成果物は、このコードレベルでの理解に基づいて構築されます。 その基盤に基づき、アシスタントはエージェントの機能とリスク領域に焦点を当てた指標を備えた個別評価計画を策定し、その後続フェーズを通じてテストケースを生成し、OpenTelemetry 互換のトレーシングでエージェントに計測機能を追加し、各テストケースを実行しながら構造化されたトレースを収集し、結果を基準に対して評価します。このプロセスは最終的にレポートに集約され、その優先順位付けられた推奨事項はコード内の特定の場所を参照し、評価結果を具体的な修正措置と直接結びつけます。例えば、空の結果によって引き起こされるハルシネーション（幻覚）の発生に焦点を当てるようシステムに指示した場合、そのガイダンスがテストケース生成、指標選択、およびレポートで最終的に強調されるパターンを形成します。 以下の図は、テストケースから指標評価に至るまでのこのフローを示しています。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/18/ML-20590-1.png) このツールキットは、この作業を 6 つのフェーズに整理しており、各フェーズで生成された成果物は eval ディレクトリに配置され、次のフェーズへと引き継がれます。各フェーズは AI アシスタントを通じてスラッシュコマンドとして呼び出し、コマンド後のテキストはそのフェーズに対する自然言語によるガイダンスとして機能します。初期の成果物が整った後、異なるガイダンスで任意のフェーズを再実行することで、ゼロから構築し直すことなく焦点を移したり分析を深めたりすることが可能です。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/18/ML-20590-2.png) これら 6 つのフェーズは、エージェントの能力を理解することから、具体的なコード改善を推奨するまでを含む、完全な評価ライフサイクルを網羅しています。 - Plan (/evalkit.plan) は、エージェントのコードを読み込んでそのツールとフレームワークを理解し、各指標に対応する具体的な評価手法を組み合わせる評価計画を生成します。あなたのガイダンスが、計画で優先される品質次元を決定し、その優先順位は後のフェーズにおける実行可能な評価コードにも反映されます。 - Data (/evalkit.data) は、評価計画に基づいてテストケースを生成します。各ケースには入力と期待される結果が含まれ、エージェントが処理すべき特定の動作や障害モードを対象としています。すでに生産環境のログや手動テストからテストデータをお持ちの場合は、このフェーズで既存のデータセットを指すように指定することも可能です。 - Trace (/evalkit.trace) は、OpenTelemetry 互換性のトレーシング（tracing）をエージェントに追加することで、実行パス全体を可視化します。Strands、LangGraph、CrewAI を含む対応するフレームワークでは、自動的にフレームワークを検出し、適切なインストルメンテーション（instrumentation）を適用します。 現在のサポートマトリックスについては、Agent-EvalKit リポジトリをご覧ください。 - エージェントの実行 (/evalkit.run_agent) は、各テストケースに対してエージェントを実行し、ツール呼び出しの完全な履歴、モデルからの応答、中間状態を記録した構造化されたトレースファイルを各実行ごとに生成します。 - 評価 (/evalkit.eval) は、計画に記載された指標を実行可能な評価コードとして実装し、収集されたトレースに対してそれを実行して構造化された結果を保存します。DeepEval や Strands Evals SDK などの評価ライブラリをサポートしており、エージェントと指標に最も適したアプローチを選択します。 - レポート (/evalkit.report) は、テストケース全体のパターンを分析し、エージェントのコード内の特定の場所を参照しながら優先順位付けされた推奨事項を生成します。各推奨事項には期待される影響が含まれており、これにより改善努力が最も効果的な場所に集中できるようになります。 これらのフェーズを通じて、曖昧な品質に関する懸念は、テストケース、実行トレース、指標スコア、そしてコード内の特定の場所とすべて結びついた優先順位付けされた推奨事項という構造化された証拠の集合体へと変換されます。 ## デモンストレーション研究：旅行調査エージェントの評価 Strands Agents SDK と Amazon Bedrock を活用して構築した旅行調査エージェントの開発中に、同エージェントが回答において疑わしいほど正確な数値を提示するケースがあることに気づきました。このエージェントは、ウェブ検索、フライト情報、気象データ、通貨換算、予算計算などのツールを使用してユーザーの旅行計画をサポートしますが、精度に関する問題がどの程度広範囲にわたるものか、またどのようなクエリで発生するかを特定することができませんでした。 Agent-EvalKit はエージェントのコードを分析し、Plan（計画）フェーズにおいて、3 つの指標に焦点を当てた集中的な評価を設計しました。Faithfulness（忠実度）は、回答がツールが実際に返したデータに基づいているかどうかを測定します。Tool Parameter Accuracy（ツールパラメータ精度）は、エージェントが正しい入力値でツールを呼び出したかを確認します。Response Quality（応答品質）は、出力がいかに一貫性があり有用であるかを評価します。その後、Data（データ）フェーズでは、目的地調査、季節のタイミング、 itinerry（旅程）構築、比較質問、予算計算を網羅する 100 の多ターンテストセッションを生成し、その後のフェーズで各セッションを実行しながら詳細な実行トレースをキャプチャしました。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/18/ML-20590-3.png) 結果は、品質と信頼性の間に明確な隔たりがあることを露呈しました。応答の質（Response Quality）は 83.9% と評価され、エージェントが明確で実行可能な旅行アドバイスを提供していることが確認されました。また、ツールパラメータ精度（Tool Parameter Accuracy）は 64.5% に達し、エージェントが一般的に適切なツールを選択している一方で、不正確なパラメータを渡す場合もあることが示されました。忠実度（Faithfulness）はわずか 32.3% と低く、ウェブ検索ツールの結果が空または不完全だった際に、エージェントが為替レートや気温、観光地の詳細などを捏造し、それらをあたかもツールからの情報であるかのように提示していたことが明らかになりました。 以下の図は、このハルシネーション（幻覚）パターンが単一の実行内でどのように現れるかを示しています。ここでは、エージェントが空のツール応答を受け取り、捏造されたデータをあたかもツールからの情報であるかのように提示する様子が描かれています。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/18/ML-20590-4.png) レポートでは、ハルシネーションを防ぐガードレール（安全装置）の強化が最優先課題として特定され、ツールから空の結果が返された際にその旨を明記するシステムプロンプト指示や、すべてのコードパスにおけるツールのエラーハンドリングの改善が推奨されました。Agent-EvalKit を実行する前には、エージェントが時折不信頼性があるように見えることは知っていましたが、実行後には、ハルシネーションを引き起こす根本原因が空のツール出力であること、そしてそれに対処するための具体的なコード変更が必要であることを把握しました。 ## 手順解説 以下のセクションでは、Agent-EvalKit の前提条件、ツールのインストール方法、および対象のエージェントに対するエンドツーエンドの評価の実行方法を順を追って説明します。 ## 前提条件 Agent-EvalKit を用いた評価を実行するには、基盤モデルの推論のためのクラウドアクセスと、評価ワークフローのためのローカルツールが必要です。 - Amazon Bedrock コンソールで基盤モデルが有効化されたアクティブな AWS アカウント。Agent-EvalKit はスコアリングに基盤モデルを必要とする LLM-as-judge（LLM を判定者として用いる）指標を使用するため、続行する前に Model access ページで利用可能なモデルを確認してください。 - Python 3.11 以降と Git。 - uv パッケージマネージャー。macOS および Linux では、curl -LsSf https://astral.sh/uv/install.sh | sh を実行してインストールします。 - 機械にインストールおよび設定された対応する AI コーディングアシスタント（Claude Code、Kiro CLI、または Kilo Code）。本記事の例では Claude Code を使用していますが、ワークフローはこれら 3 つすべてに適用されます。インストール手順については、各アシスタントのドキュメントを参照してください。 ## はじめに uv を使用してツールキットをインストールします。これは Agent-EvalKit の GitHub リポジトリから直接取得します。 ```bash uv tool install evalkit --from git+https://github.com/awslabs/Agent-EvalKit.git ``` 評価プロジェクトを初期化し、エージェントのコードをプロジェクトディレクトリにコピーします。エージェントディレクトリには、ソースコード、ツール定義、およびエージェントを実行するために必要な設定が含まれている必要があります。対応するエージェントフレームワークとプロジェクト構造の詳細については、Agent-EvalKit リポジトリを参照してください。 ```bash evalkit init my-agent-evaluation cd my-agent-evaluation cp -r /path/to/your/agent . ``` 評価プロジェクト内で AI アシスタントを起動してください。Claude Code の場合は、claude コマンドを実行します。 claude ガイド付きの最初の評価には、quick コマンドを使用すると、6 つのフェーズすべてを段階的に案内し、各フェーズが何を行うか、次にどのコマンドを実行すべきかを説明します。 /evalkit.quick /evalkit.quick Evaluate my agent at ./my_agent for response quality and tool accuracy より細かな制御が必要な場合は、各フェーズを個別に実行してください。 /evalkit.plan /evalkit.plan Evaluate my agent at ./my_agent for response quality and tool accuracy /evalkit.data /evalkit.trace /evalkit.run_agent /evalkit.eval /evalkit.report 以下の動画では、コード分析から最終評価レポートに至るまでの 6 つのフェーズ全体にわたり、Web 検索およびプランニングツールを備えた旅行調査用エージェントを Agent-EvalKit が評価する完全なワークフローを紹介しています。 ## ベストプラクティス エージェントの評価は、リリース前のチェックポイントとしてではなく、意味のある変更ごとに実行される場合に最も効果が発揮されます。以下に示す実践方法は、Agent-EvalKit を継続的な開発サイクルに組み込む際に最も有用であると私たちが発見したものです。 - 最初は範囲を狭くし、エージェントの最も重要な品質次元に焦点を当てるために 2 つまたは 3 つの指標に絞り込みます。初期の発見に対処し、ベースラインに対する信頼を得るにつれて、後の評価で対象範囲を広げていきます。 - ドメイン知識に基づいてガイドし、各フェーズで観察した特定の入力、エッジケース、および障害モードを記述してください。自然言語による指示がより具体的であればあるほど、生成されるテストケース、指標、推奨事項の関連性が高まります。 - 実行前にテストケースを見直してください。データフェーズでは評価計画からケースを合成しますが、実際のユーザー行動に関する理解は代替不可能です。本番環境で観察するパターンを反映したシナリオを追加してください。 - 重要な変更ごとに評価を実行して、早期に回帰を検出し、各改善の影響を測定します。エージェントのバージョン間でのレポートを比較することで進捗が可視化され、開発が最も価値の高い修正に集中し続けます。 - レポート内の影響度の高い項目から始めて、推奨事項を段階的に対応してください。修正を実装し、改善を確認するために再評価を行い、次に発見された課題へと移ります。 - 既存のテストケースと計測機能を再利用しながら、個別のフェーズを再呼び出して新しい品質次元を探求することで、過去の評価に基づいて進めます。忠実性に焦点を当てた初期の評価に続き、データ再生成やエージェントへの計測機能の再設定を行わずに、ツールの精度についてより深い検証を行うことができます。 - Amazon Bedrock AgentCore Observability を使用して本番トラフィックからのトレースを取得し、AgentCore Evaluation でそれらのトレースに対して品質指標を実行することで、本番環境でエージェントを継続的に監視します。本番モニタリングは、デプロイ前の評価では予測できない回帰や新しい障害モードを浮き彫りにします。 - 定期的に LLM-as-judge のスコアと専門家の判断または人間の注釈者の判断を比較することで、評価者を人間専門家と整合させます。両者が乖離した場合は評価者用プロンプトを更新し、自動化された指標がユーザーにとって重要な品質次元を反映し続けるようにしてください。 ## CI/CD との統合 自動化を準備しているチーム向けに、以下の図は Agent-EvalKit が継続的インテグレーションおよび継続的デリバリー（CI/CD）パイプラインにどのように統合されるかを示しています。コード変更が評価トリガーとなり、品質ゲートがメトリクス閾値と回帰をチェックし、失敗した場合は評価レポート内でフラグ付き項目としてルートされます。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/18/ML-20590-6.png) パイプラインが設置されると、各テストラウンドは前回のラウンドからテストケースと計測（インストルメンテーション）を再利用するため、プロジェクトが成熟するにつれて新規評価を実行するコストは低下します。 ## クリーンアップ 追従のために評価プロジェクトを作成した場合は、完了後にプロジェクトディレクトリを削除してください。評価で Amazon Bedrock を通じて基盤モデル（Foundation Models）を使用した場合は、AWS Management Console の Amazon Bedrock 価格ページで利用状況を確認し、関連するコストを理解してください。 ## 結論 Agent-EvalKit は、コード記述に既に使用している同じ AI アシスタントへ、評価設計からメトリクス計算、レポート作成に至るまでの各ステップを委譲することで、AI エージェントの評価に体系的な形を与えます。旅行調査エージェントのケーススタディは、これが実践においてどのように見えるかを示しました。これは、漠然とした品質への懸念を、特定の行における具体的な修正と、期待される影響を伴うものへと変換するものです。 エージェントが高リスクかつ広範囲のタスクを引き受けるようになると、出力チェックを超えた評価が生産環境への適合性の前提条件となります。Agent-EvalKit は設計上

Agent-EvalKit で AI エージェントを体系的に評価する

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト