AIエージェントの評価：StrandsとAgentCoreを用いたプロダクションブループリント

この記事は、MotorwayおよびAWSプロトタイピングおよびAIカスタマーエンジニアリング（PACE）チームとの共著です。

Motorwayは英国を拠点とするオンライン自動車マーケットで、毎日最大8,000のディーラーが最大2,500台の車両に入札するオークションを運営しています。MotorwayはAWS PACEチームと協力して、AI搭載のディーラー在庫検索エージェントを構築しました。このエージェントは、ディーラーが車両を見つける方法を変革し、数時間に及ぶ手動フィルタリングを自然言語クエリに置き換えます。

課題

エージェントは自信満々の応答を返しますが、実際の資金がかかる場面で確実に動作することをどう証明するのでしょうか？ツール選択の誤りにより検索結果が間違って表示され、ディーラーの信頼を損なう恐れがあります。セマンティック検索の誤解釈により無関係な結果が返されます。「ガソリン、ハイブリッド、電気自動車で車齢5年まで」のようなクエリでは、エージェントが複数の制約を正しく解析する必要があります。マルチターン会話におけるコンテキストのドリフトにより、ディーラーの絞り込みが失われます。非決定的な出力により、単一試行のテストは信頼できません。

解決策

MotorwayとAWSは共同で、エンドツーエンドの評価パイプラインを構築し、誤った結果をクエリ8回に1回から50回に1回に削減し、問題検出時間を数時間から数分に短縮しました。このパイプラインは、Strands Agents SDKとAmazon Bedrock AgentCore（AIエージェントを大規模に展開・運用するためのフルマネージドサービス）を組み合わせています。この記事では、独自のエージェント向けにこのパイプラインを構築する方法を学びます：

ビルド時テスト（strands-agents-evals）と本番監視（Amazon Bedrock AgentCore Evaluations）にわたる2フェーズ評価戦略。

ツール使用、推論、出力品質を評価する3層フレームワーク。

メトリクスがしきい値を下回るとリリースをブロックする品質ゲートを備えた5段階デプロイメントパイプライン。

付属のリポジトリは、独自のエージェントに適応可能なデプロイ可能なブループリントを提供します。ブループリントはAWSサービスを使用していますが、コア原則はどのプロダクション対応AIエージェントにも必須であり、システムに依存しません。これらの原則には、3層評価フレームワークと一貫性のためのpass^kメトリックの使用が含まれます。

前提条件

この記事に沿って進めるには、以下の前提条件が必要です。

Amazon Bedrock、AWS Lambda、Amazon S3、Amazon DynamoDB、Amazon EventBridge、Amazon CloudWatch、Amazon SNSのアクセス許可を持つAWSアカウント。

AWS CDK v2がインストールされ、ブートストラップされていること。

Python 3.14以上。

Amazon Bedrockモデルアクセスを通じてAnthropic ClaudeモデルおよびAmazon Titanモデルへのアクセス。

Python、AWS CDK、エージェントの概念（ツール呼び出し、マルチターン会話）に関する知識。

完了時間：初期デプロイに30～45分、ドメインにカスタマイズするのに2～3時間。

推定コスト：サンプル評価スイートの実行には、Amazon Bedrock推論料金として約5～10ドルかかります。本番監視コストはサンプリングレートによって異なります。

セキュリティ注意事項：付属リポジトリは最小権限のAWS IAMロールを実装し、APIキーをAWS Systems Manager Parameter Storeに保存し（環境変数ではない）、型付きパラメータを使用してインジェクション攻撃を防止します。詳細はリポジトリのREADMEを参照してください。

実例：ディーラー在庫検索エージェント

Motorwayはディーラー在庫検索エージェントをStrands Agents SDKとAmazon Bedrock AgentCore上に構築しました。このエージェントは、89以上の車両属性にわたる構造化フィルタリングと、LanceDBおよびAmazon Titan Text Embeddings V2によるベクトル類似性検索を組み合わせた8つのツールを公開しています。

ディーラーは従来、CSVや固定フィルターを使ってリストを閲覧するのに数時間を費やしていました。会話型AIエージェントの導入により、ディーラーはエージェントと会話できるようになりました：「私のディーラーの近くで2.5万ポンド以下のディーゼルSUVを探して」とか「ファミリー向けでスポーティーでオートマチックな車」など。

ピーク時には約1,500人の同時ユーザーがいるため、エージェントの動作を正しくすることは必須です。ツール選択の誤りやセマンティック検索の誤解釈は、ユーザーの信頼に直接影響します。図1はエンドツーエンドのリクエストフローを示しています。ディーラーはWebインターフェースを通じて自然言語クエリを送信し、Amazon Bedrock AgentCore Runtimeにルーティングされます。ランタイムは8つの異なるツールへの呼び出しを調整し、Amazon Bedrockモデル（推論用Claude、埋め込み用Amazon Titan）を使用します。ツールの応答はランタイムを介して戻り、最終的なディーラー向け結果が生成されます。

なぜエージェント評価が異なるのか

LLM評価はテキスト生成の品質（一貫性、事実の正確性、応答の関連性）に焦点を当てます。エージェント評価は根本的に異なるものを評価します。次のように考えてみてください：LLM評価はエンジンの性能を調べます。エージェント評価は、車全体が交通の中、雨の中、または後部座席に乗客が満員の状態でどのように走行するかを評価します。

従来のLLMメトリクスでは、Motorwayエージェントが「Grade 1 Suzukiモデル」に対して正しい検索ツールを呼び出したかどうかはわかりません。エージェントが正しいフィルタパラメータをLanceDBに渡したかどうかもわかりません。また、ディーラーが前のターンからの結果を絞り込んだ際に正しい応答が返ってきたかどうかも見逃されます。

評価の次元 エージェントにとって重要な理由

タスク完了 エージェントはマルチステップワークフローを実行し、部分的な完了が一般的

ツール使用の正確性 間違ったツールやパラメータはワークフロー全体を台無しにする可能性がある

推論の一貫性 欠陥のある推論は、条件が変化すると予測不可能な障害を引き起こす

信頼性と一貫性 非決定性により、同じ入力が異なる出力を生む可能性がある

安全性とコンプライアンス 自律エージェントは現実世界の結果をもたらす行動をとる可能性がある

コストと効率性 タスクあたり50回のAPI呼び出しを必要とするエージェントは経済的に成り立たない可能性がある

「フォルクスワーゲンゴルフ 7～12年落ち」のような正確なクエリは完璧に機能するかもしれませんが、「もう少し古いVWを探している」のような口語的なバリエーションは、セマンティック検索レイヤーが適切に評価されていないと失敗する可能性があります。

デプロイ前にstrands-agents-evalsで問題をキャッチ

ブループリントはGenAIOpsライフサイクルに対応する2つのフェーズで評価を実装します。ビルド時評価はデプロイ前に問題をキャッチし、本番評価は合成テストでは見逃されるものをキャッチします。以下の図（図2）は、ツール使用、推論、出力品質の各層がデプロイ前に合格しなければならないことを示しています。フレームワークはエージェントを3つの層で評価します：

第1層（ツール使用）：正しいツール選択とパラメータ引き渡しを検証し、しきい値は95%超。

第2層（推論）：論理的な意思決定を評価し、しきい値は85%超。

第3層（出力品質）：応答の有用性と正確性を測定し、しきい値は90%超。3つの層すべてが合格して初めてデプロイが進行します。

開発およびCI/CD中、パイプラインはstrands-agents-evalsフレームワークを使用してデプロイ前に問題をキャッチします。出力検証、軌跡評価、マルチターン会話シミュレーション、自動実験生成を提供します。それぞれはStrands Agents SDK上に構築されたエージェントとネイティブに動作するように設計されています。フレームワークは3つのプリミティブを提供します：

実験：エージェントに対して実行されるテストケースのコレクション。

ケース：入力クエリ、期待される出力、期待されるツール軌跡。

評価器：スコアリングロジック（決定論的またはLLMベース）。

テストを層に構造化します。第1層はツール選択の正確性に対して決定論的なコードベースの評価器を実行します。第2層と第3層はLLM-as-judge評価器（LLMを使用してエージェント出力をスコアリング）を使用して推論と出力品質を評価します。

カスタム評価器サブクラスはドメイン固有の懸念事項を処理します。Motorwayエージェントの場合、これらはデータの鮮度、ディーラーのスコープ、セーフティガードレールをカバーします。あなたのエージェントには独自のドメイン制約があります。

3種類の評価器

評価フレームワークは3つの評価器タイプを使用し、それぞれ異なる評価ニーズに適しています。

評価器タイプ 層 測定内容 トレードオフ

コードベース決定論的 第1層 ツール選択、パラメータ引き渡し、軌跡順序 高速、安価、再現可能

LLM-as-judge（Claude Sonnet 4.6） 第2～3層 推論品質、出力の有用性、目標達成度 柔軟；非決定論的（pass^kで制御）

人間によるレビュー キャリブレーション エッジケースと安全性 高価；LLM評価器のプロンプトをキャリブレーションするために使用

実際には、エージェントが生成したものを評価する方が、たどった経路を評価するよりも多くの問題をキャッチします。重要なのはユーザーが関連する結果を得たかどうかであり、エージェントが最初にどのツールを呼び出したかではありません。

3層評価フレームワーク

ビルド時評価は3つの異なる層で動作し、各層には特定の合格/不合格しきい値があります。

第1層：ツール使用（>95%しきい値）。エージェントは正しいツールを正しいパラメータで呼び出しましたか？

「£7,000から£20,000のディーゼル車」は、型付きフィルタ（fuel_type=diesel, min_price=7000, max_price=20000）を伴うsearch_vehiclesを使用する必要があります。

「低走行距離のモダンハッチバック」は、セマンティック埋め込みと構造化フィルタを組み合わせたhybrid_searchをトリガーする必要があります。

これを決定論的に測定します：ToolSelectionGraderはどのツールが呼び出されたかをチェックし、TrajectoryOrderGraderは呼び出しシーケンスを検証します。

第2層：推論（>85%しきい値）。意思決定プロセスは論理的でしたか？HelpfulnessEvaluatorとTrajectoryEvaluatorはLLM-as-judgeスコアリングを使用して、エージェントの推論が一貫しているかどうかを評価します。非論理的な推論で正しい応答にたどり着いたエージェントは、条件が変化すると予測不可能に失敗します。

第3層：出力品質（>90%しきい値）。応答は有用で正確で実行可能でしたか？OutputEvaluatorとGoalSuccessRateEvaluatorはLLM-as-judge評価を使用して、ユーザーが有用で適切にフォーマットされた応答を得たかどうかを評価します。

3つの層はデプロイ前に合格しなければなりません。ある層での失敗はパイプラインをブロックします。

非決定性への対処

LLMの出力は実行ごとに異なるため、単一試行の結果は誤解を招く可能性があります。付属リポジトリのrun_all_layers()関数は、この問題に対処するためにnum_trialsパラメータを受け入れます。コード生成研究コミュニティからの2つのメトリックが信頼性の測定に役立ちます：

pass@kは、k回の試行で少なくとも1回成功する確率を測定します。これは、1つの正しい解決策で十分な場合に便利です。

pass^kは、k回の連続試行で成功する確率を測定します。これは、ユーザーが毎回信頼性の高い動作を期待する場合に便利です。

顧客向けエージェントの場合、pass^kが最も重要です。試行ごとの成功率が75%のエージェントが3回連続で成功する確率はわずか42%（0.75³）です。ユーザーはすべてのインタラクションで一貫した品質を期待します。

付属コードでは、run_all_layers(task_fn, registry, num_trials=5)がマルチ試行サポートで評価層を実行し、pass^kに基づいてデプロイをゲートします。完全な実装を参照してください。

テストケース管理

テストケースはカテゴリ別に整理されます：

ハッピーパス：成功するはずの一般的なクエリ。

エッジケース：あいまいなクエリ、スラング、マルチターンの絞り込み。

セーフティ/ガードレール：エージェントが拒否またはリダイレクトすべきクエリ。

本番監視で問題が検出されると、そのインタラクションが新しいテストケースになります。Motorwayのテストスイートは、最初の50ケースから3ヶ月で150ケースに成長し、それぞれ実際のユーザー行動に基づいています。20～50ケースから始めて、本番データでスイートを成長させてください。

エージェントが特定のツールを呼び出すべきでないネガティブケースも含めてください。例えば、プロファイルクエリは検索ツールではなくプロファイルツールを呼び出すべきです。構造化クエリは構造化検索を使用すべきであり、生のSQLフォールバックは使うべきではありません。一方的な評価は一方的な最適化を生みます。

マルチターン会話テスト

シングルターン評価は重要な次元を見逃します：会話の一貫性。ディーラーは自然に複数のターンにわたって検索を絞り込みます：

ターン1：「ディーゼルSUVを探して。」

ターン2：「今度はオートマチックだけ表示して。」

ターン3：「エステートはどう？

（コスト抑制のため省略）