Agent-EvalKit は AWS が 2026 年 6 月 11 日に公開したオープンソースの AI エージェント評価ツールキットで、ライセンスは Apache 2.0 です（出典：AWS Machine Learning Blog）。ツール呼び出し、検索、外部 API、マルチステップ計画を扱うエージェント向けです——Claude Code、Kiro CLI、Kilo Code で /evalkit.* コマンドを打つと、アシスタントがコードを読み、テストケースを生成し、トレースを仕込み、評価を実行し、どのコードを直せばいいか教えてくれます。
「いくつか質問して回答をざっと見る」代わりにはなりません。これが捉えるのは、最終的な回答は正しく見えるけど、ツール呼び出しが間違っていたり、空の結果が事実として捏造されていたり、引用が元データと合っていない——そういう問題です。
どんなときに使うべきか
エージェントが以下の条件のうち 2 つ以上に当てはまるなら、人手による抜き打ちチェックではなく、開発段階で Agent-EvalKit を導入する価値があります：
| 条件 | 評価のポイント |
|---|---|
| 検索、DB、CRM、チケット、内部 API を呼び出す | 正しいツールを選んだか、パラメータは正しいか、失敗時に停止するか |
| ツールの結果を最終回答に書き込む | 回答がツールの返したデータに忠実か |
| マルチターンタスクを処理する | 中間状態、コンテキストの継承、ツールの順序が安定しているか |
| モデル変更、system prompt 変更、ツール記述の更新を予定している | 変更前後で同じトレースを比較できるか |
| 「本当っぽいけど出典がない」問題をすでに発見している | 空のツール結果が開示されているか、モデルが補完していないか |
エージェントがまだ純粋なチャットだけで、外部ツールや業務アクションがないなら、手動のチェックリストと固定プロンプトで十分です。Agent-EvalKit の価値は、実行経路を見る必要があるときに発揮されます。
AgentCore 評価データセットとの違い
当サイトにはすでに AI エージェント評価データセットの作り方 という記事があり、本番障害をバージョン管理されたデータセットとリリースゲートに落とし込む方法を解説しています。Agent-EvalKit はもっと上流に位置します：ローカルの開発ディレクトリでコードを解析し、eval/ 成果物を生成し、トレースを実行し、レポートを出力します。
| 質問 | Agent-EvalKit 向き | AgentCore データセット/本番評価向き |
|---|---|---|
| エージェントを書いたばかりで、どこで幻覚を見るか知りたい | はい | いいえ |
| ツール呼び出しと中間状態を逐一確認したい | はい | 後で補足可 |
| 本番障害をリリースゲートにしたい | 補助可 | はい |
| 長期的に本番品質を監視したい | いいえ | はい |
| コーディングアシスタントにどのコードを直せばいいか指摘してほしい | はい | いいえ |
実際の運用では、まず Agent-EvalKit で高リスク行動を特定し、安定して再現する失敗をバージョン管理された評価データセットに追加していきます。
前提条件
| 項目 | 要件 |
|---|---|
| AWS アカウント | Amazon Bedrock コンソールで評価に使う foundation model を有効化しておく |
| ローカル環境 | Python 3.11+、Git、uv |
| コーディングアシスタント | Claude Code、Kiro CLI、Kilo Code のいずれかがインストールされ、プロジェクトで実行可能であること |
| エージェントコード | ソースコード、ツール定義、プロンプト、実行設定を含む |
| 対応フレームワーク | AWS 記事では Strands、LangGraph、CrewAI が自動計装可能と記載；最新の対応状況は Agent-EvalKit リポジトリを参照 |
macOS/Linux での uv インストール：
curl -LsSf https://astral.sh/uv/install.sh | sh
Agent-EvalKit のインストール：
uv tool install evalkit --from git+https://github.com/awslabs/Agent-EvalKit.git
最小限のスタート手順
評価プロジェクトを作成し、エージェントのコードをコピーします。以下のパスは例であり、当サイトの実行結果ではありません：
evalkit init my-agent-evaluation
cd my-agent-evaluation
cp -r /path/to/your/agent .
Claude Code を使う場合は、評価ディレクトリから起動します：
claude
初回は quick コマンドでアシスタントがステップバイステップでガイドします：
/evalkit.quick Evaluate my agent at ./my_agent for faithfulness, tool parameter accuracy, and response quality
各フェーズを個別に制御したい場合は、6 つのコマンドを順に実行します：
/evalkit.plan Evaluate my agent at ./my_agent for faithfulness, tool parameter accuracy, and response quality
/evalkit.data
/evalkit.trace
/evalkit.run_agent
/evalkit.eval
/evalkit.report
この 6 ステップで eval/ ディレクトリに評価計画、テストデータ、トレース、スコア、レポートが生成されます。あとは特定のフェーズだけ再実行することもできます。たとえば指標を変えたら /evalkit.eval だけ、ツールコードを変えたら /evalkit.run_agent と /evalkit.report だけ再実行します。
6 つのフェーズの役割
| フェーズ | コマンド | 成果物 | チェックポイント |
|---|---|---|---|
| Plan | /evalkit.plan |
評価計画と指標 | 指標が実際のリスクをカバーしているか、見た目の良さだけではないか |
| Data | /evalkit.data |
テストケース | 空結果、誤パラメータ、権限不足、期限切れデータなどのケースが含まれているか |
| Trace | /evalkit.trace |
OpenTelemetry 互換の計装 | ツール呼び出し、モデル応答、中間状態が取得できるか |
| Run agent | /evalkit.run_agent |
テストケースごとの構造化トレース | エージェントがテストケース通りに実行されたか |
| Eval | /evalkit.eval |
実行可能な評価コードとスコア | ルールベース評価と LLM-as-judge がそれぞれの役割を果たしているか |
| Report | /evalkit.report |
修正推奨事項 | 具体的なファイル、動作、期待される影響を指摘できているか |
Data フェーズの手動レビューは省略しないでください。テストケースはアシスタントが生成できますが、実際のユーザー行動、ビジネス上のレッドライン、過去の障害はあなたが追加する必要があります。
3 つの主要指標の選び方
AWS のサンプル旅行リサーチエージェントでは、Faithfulness（忠実性）、Tool Parameter Accuracy（ツールパラメータ精度）、Response Quality（応答品質）の 3 指標を使いました。ツールを使うほとんどのエージェントに適しています：
| 指標 | 主に何を検出するか | 適した評価方法 |
|---|---|---|
| Faithfulness | 最終回答がツールの返したデータに基づいているか、空の結果を捏造していないか | トレース + LLM judge + 引用チェック |
| Tool Parameter Accuracy | 正しいツールが正しいパラメータで呼ばれたか | ルールチェック優先、必要に応じて人手確認 |
| Response Quality | 回答が明確で完全で実行可能か | LLM judge または人手サンプリング |
エージェントが権限、支払い、削除、メッセージ送信などを扱う場合は、ハードルールを追加してください：
- 権限チェックを通過しない限り業務 API を呼び出さない
- ツールが空の結果を返した場合は「データが取得できませんでした」と明示する
- 高リスクアクションは人間の確認を待つ
レポートの読み方
AWS の例では、旅行リサーチエージェントの Response Quality は 83.9%、Tool Parameter Accuracy は 64.5%、Faithfulness はわずか 32.3% でした。旅行アドバイスが書けないわけではなく、web search ツールが空や不完全な結果を返したときに、為替レートや気温、観光スポットの詳細を捏造し、あたかもツールから取得したデータのように表示していたのです。
レポートは次の順序で処理します：
- 高リスクの幻覚を先に修正：空のツール結果、誤ったユーザー、権限失敗、期限切れのリアルタイムデータ
- 次にツールパラメータを修正：日付、地域、ユーザー ID、通貨、製品 SKU、フィルタ条件
- 最後に表現品質を改善：フォーマット、サマリー順序、表現
Response Quality のスコアが高いからといってリリースを許可しないでください。ツールを使うエージェントの場合、きれいな回答が誤った経路を隠している可能性があります。
CI/CD への組み込み方
最初から完全自動化を目指さないでください。まずローカル評価で安定したベースラインを作り、最も重要なシナリオだけを CI に組み込みます：
| ステップ | 合格基準 |
|---|---|
| 20〜50 の高リスクテストケースを固定 | 空のツール結果、権限失敗、パラメータエラー、期限切れデータをカバー |
| トレースとレポートを保存 | モデルやプロンプト変更前後で比較可能に |
| ハードゲートを設定 | high-risk Faithfulness または権限シナリオが 1 つでも失敗したらブロック |
| ソフトゲートを設定 | response quality が閾値を下回ったら人の承認を必須に |
| 同じテストセットで比較 | テストケースを変えながらスコアを比較しない |
テストセットが安定したら、本番トレースを Amazon Bedrock AgentCore Observability と AgentCore Evaluation に接続します。AWS 公式記事も、本番モニタリングは開発時評価の代替ではなく、その後のステップとして位置づけています。
よくある間違い
最終回答だけテストする。 エージェントが正しい結論にたどり着いても、権限チェックをスキップしていたり、間違ったツールを使っていたりする可能性があります。
LLM-as-judge を唯一の判定基準にする。 意味的な品質は judge に任せても構いません。権限、ツールの順序、パラメータ、禁止アクションの呼び出しは、ルールチェックを優先してください。
生成されたテストケースをレビューしない。 /evalkit.data は広いカバレッジを生成できますが、実際のビジネス上の失敗ケースは手動で追加する必要があります。
一度に多くの指標を詰め込みすぎる。 最初は faithfulness、tool parameter accuracy、response quality の 3 つから始め、ベースラインが安定してからコスト、レイテンシ、スタイル、安全性の指標を追加してください。
リリース前だけ実行する。 プロンプト、ツール記述、モデルバージョン、検索戦略を変更するたびに評価を実行してください。そうしないと、レポートはすでに発生している問題を説明するだけのものになります。
FAQ
Agent-EvalKit に Amazon Bedrock は必須ですか？
AWS 公式記事によれば、評価の実行には AWS アカウントと、Amazon Bedrock コンソールで LLM-as-judge に使う foundation model を有効にしておく必要があります。公式ワークフローで完全な評価を実行するなら、Bedrock へのアクセスが必要です。
どのコーディングアシスタントに対応していますか？
Agent-EvalKit は Claude Code、Kiro CLI、Kilo Code に対応しています。公式記事の例では Claude Code が使われています。
コードを自動修正してくれますか？
最終フェーズの /evalkit.report は優先順位付きの修正推奨事項を、コードの位置と期待される影響とともに出力します。修正を適用するかどうかは開発者が判断します——レポートは自動修正ツールではありません。
すでに評価データセットがあります。Agent-EvalKit はまだ必要ですか？
データセットが入力と期待される出力だけを保存している場合、Agent-EvalKit は依然として価値があります——トレース、ツールパラメータ、忠実性チェック、コードレベルの推奨事項を補完します。すでに完全なツールトレースを記録し、実行可能な修正推奨事項を出力できる評価プラットフォームをお持ちなら、追加価値は小さくなります。
初回のプロンプトはどう書けばいいですか？
「品質を評価してください」のような一般的な書き方ではなく、具体的なリスクを指定してください。例えば：
/evalkit.plan Evaluate ./my_agent for hallucinations when tools return empty results, wrong tool parameters for date and region filters, and response quality for business users.
こうすることで、評価は空の結果、日付/地域パラメータ、業務上のユーザビリティに集中し、その後の Data、Eval、Report の各フェーズも同じ方向性で進みます。