AWS、AIエージェント評価の生産用ブループリントを公開

この記事は、Motorway と AWS Prototyping および AI Customer Engineering (PACE) チームとの共著です。

イギリスに拠点を置くオンラインカーマーケットプレイス「Motorway」では、毎日最大 8,000 のディーラーが最大 2,500 台の車両について入札を行うオークションを開催しています。Motorway は AWS Prototyping と AI Customer Engineering (PACE) チームと連携し、AI を活用したディーラー向け在庫検索エージェントを構築しました。これにより、ディーラーが車両を探す方法が劇的に変わり、これまで数時間を要していた手動での絞り込み作業に代わり、自然言語によるクエリで即座に結果を得られるようになりました。

課題

このエージェントは自信ありげな回答を返しますが、実際に金銭がかかっている状況でも確実に機能していることをどう証明すればよいのでしょうか？

• ツール選択の誤りにより検索結果が間違ったり、ディーラーの信頼を損なうリスクがあります。
• 意味検索の誤解によって無関係な結果が返されることがあります。例えば「5 年以内のガソリン車、ハイブリッド車、電気自動車」といったクエリでは、エージェントが複数の制約条件を正しく解釈する必要があります。
• 多段会話における文脈のズレ（Context drift）により、ディーラーによる絞り込み条件が見失われる可能性があります。
• 非決定的な出力のため、単一の試行でのテスト結果は信頼性に欠けます。

解決策

Motorway と AWS は共同でエンドツーエンドの評価パイプラインを構築し、誤った検索結果の発生率を「クエリ 8 回に 1 回」から「50 回に 1 回」に削減するとともに、問題検出にかかる時間を数時間から数分に短縮しました。

このパイプラインは、Strands Agents SDK と Amazon Bedrock AgentCore を組み合わせています。Bedrock AgentCore は、大規模な AI エージェントのデプロイと運用を完全に管理するサービスです。本記事では、あなた自身も同様の評価パイプラインを構築する方法について解説します。

本稿では、開発段階でのテストに strands-agents-evals（Strands Agents 向けのオープンソース評価ライブラリ）と、本番環境での監視に Amazon Bedrock AgentCore Evaluations を活用する、2 フェーズからなる評価戦略を提案します。

ツール使用能力、推論プロセス、出力の品質を評価するための 3 レイヤー構成フレームワークと、閾値を下回るメトリクスが検出された際にリリースをブロックする品質ゲートを備えた 5 ステージのデプロイパイプラインも紹介しています。

コメンションリポジトリ では、そのまま導入可能なブループリントを提供しており、これをベースに独自のエージェント向けにカスタマイズが可能です。本稿のブループリントは AWS サービスを利用していますが、その根底にある原則は、AWS に限らずあらゆるプロダクション環境で AI エージェントを運用する上で不可欠なシステム非依存の要件です。具体的には、3 レイヤー構成の評価フレームワークや、一貫性を確認するための pass^k メトリクスの活用などが含まれます。

前提条件

本記事の内容を実践するためには、以下の前提条件を満たしている必要があります。

このチュートリアルを完了するには、以下の環境と準備が必要です。

• Amazon Bedrock、AWS Lambda、Amazon Simple Storage Service (Amazon S3)、Amazon DynamoDB、Amazon EventBridge、Amazon CloudWatch、および Amazon Simple Notification Service (Amazon SNS) へのアクセス権限を持つ AWS アカウントが必要です。

• インストール済みかつブートストラップされた AWS Cloud Development Kit (AWS CDK) v2 が必要です。

• Python 3.14 以降が利用可能であること。

• Amazon Bedrock モデルアクセス を通じて、Anthropic の Claude モデルおよび Amazon Titan モデルへのアクセス権限が必要です。

• Python、AWS CDK、およびエージェントの基本概念（ツール呼び出しや多段階会話など）に関する知識があること。

所要時間: 初期デプロイに 30〜45 分、ドメイン固有のカスタマイズに 2〜3 時間。

想定コスト: サンプル評価スイートの実行には、Amazon Bedrock の推論利用料として約 5〜10 ドルがかかります。本番環境の監視コストはサンプリングレートによって変動します。

セキュリティに関する注意: 付属のリポジトリでは、最小権限の AWS Identity and Access Management (IAM) ロールを実装し、API キーを環境変数ではなく AWS Systems Manager Parameter Store に格納しています。また、インジェクション攻撃を防ぐために型付きパラメータを使用しています。詳細は リポジトリの README をご覧ください。

具体的な事例：ディーラー在庫検索エージェント

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

従来、ディーラーは CSV ファイルや厳格なフィルターを使って在庫を検索するのに数時間を要していました。しかし、対話型 AI エージェントを導入することで、ユーザーはエージェントに自然言語で問い合わせることが可能になりました。「私の店舗の近くで 250 ドル以下のディーゼル SUV を探して」や「家族向けのスポーティーでオートマチックな車を探して」といった具合です。

ピーク時で約 1,500 人の同時接続ユーザーを抱える環境では、エージェントの動作を正しく設計することは必須です。ツールの選択ミスやセマンティック検索の誤解釈は、直接的にユーザーの信頼を損ないます。

図 1 は、エンドツーエンドのリクエストフローを示しています。ディーラーは Web インターフェースを通じて自然言語でクエリを入力し、それが Amazon Bedrock AgentCore Runtime にルーティングされます。このランタイムは、Amazon Bedrock モデル（推論には Claude を、埋め込みには Amazon Titan を使用）を活用しながら、8 つの異なるツールへの呼び出しを調整します。ツールのレスポンスは再びランタイムを経由して戻され、最終的にディーラー向けの結果が生成されます。

エージェント評価が異なる理由

大規模言語モデル（LLM）の評価は、主にテキスト生成の質—一貫性、事実の正確さ、回答の関連性—に焦点を当てています。一方、エージェントの評価は根本的に異なるものを測るものです。

こう考えてみてください。LLM の評価が「エンジンの性能」を検査するものだとすれば、エージェントの評価は「雨の中や渋滞の中で、後部座席に乗客を乗せた状態で車がどう走るか」を評価するものです。

従来の LLM 指標では、「Grade 1 Suzuki モデル」に対して Motorway エージェントが適切な検索ツールを呼び出したかどうかは分かりません。また、LanceDB に正しいフィルタパラメータを渡したかも不明です。さらに、前のターンで得られた結果をディーラーが絞り込んだ際に、適切なレスポンスが返されたかという点も見逃してしまいます。

「Volkswagen Golf 7-12 年式」のような正確なクエリは完璧に機能しますが、意味検索層が適切に評価されていない場合、「古い VW を探している」といった口語的なバリエーションでは失敗する可能性があります。

strands-agents-evals でデプロイ前の課題を検出

本ブループリントは、GenAIOps ライフサイクル に沿った 2 つのフェーズで評価を実施します。ビルド時の評価ではデプロイ前の課題を事前に発見し、本番環境での評価では合成テストで見逃された問題を捉えます。

次の図（Figure 2）は、ツール使用、推論、出力品質の各層がデプロイ前に通過すべき基準を示しています。このフレームワークはエージェントを以下の 3 つの層で評価します。

• レイヤー 1（ツール使用）：ツールの正しい選択とパラメータ引渡しが検証され、95% を超える閾値を満たす必要があります。
• レイヤー 2（推論）：論理的な意思決定が評価され、85% を超える閾値を満たす必要があります。
• レイヤー 3（出力品質）：回答の有用性と正確性が測定され、90% を超える閾値を満たす必要があります。デプロイを進めるには、これらすべての層を通過させることが必須です。

開発中および継続的インテグレーション・継続的デプロイメント（CI/CD）の段階では、strands-agents-evals フレームワークがパイプラインに組み込まれ、本番環境への展開前に不具合を検出します。このフレームワークは、出力の検証、実行経路の評価、複数回の対話シミュレーション、そして自動化された実験生成を提供しています。これらはすべて、Strands Agents SDK をベースに構築されたエージェントとネイティブに連携するように設計されています。

同フレームワークでは、以下の 3 つの基本要素（プリミティブ）を用意しています。

• Experiment：エージェントに対して実行するテストケースの集合体です。
• Case：入力クエリ、期待される出力、そして期待されるツールの実行経路を定義します。
• Evaluator：スコアリングロジック（決定論的または LLM ベース）を担当します。

テストはレイヤー構造で設計しましょう。レイヤー 1 では、ツール選択の精度を検証するための決定論的なコードベースのグラダーを実行します。レイヤー 2 と 3 では、推論能力と出力品質を評価するために LLM-as-judge（LLM を用いた採点）を採用します。

カスタム Evaluator サブクラスは、ドメイン固有の課題に対応します。例えば Motorway エージェントでは、データの鮮度、ディーラーのスコープ、および安全ガールレールが対象となります。各エージェントには独自のドメイン制約が存在します。

3 つのグラダーの種類

評価フレームワークでは、3 つのグラダータイプを用意しており、それぞれが異なる評価ニーズに適しています。

実際には、エージェントが生成した結果を評価する方が、そのプロセスを追跡して評価するよりも多くの課題を発見できます。重要なのは、ユーザーが関連性の高い結果を得たかどうかであり、エージェントが最初にどのツールを呼び出したかではありません。

3 レイヤー評価フレームワーク

ビルド時の評価は、それぞれに特定の合格/不合格基準を持つ 3 つの異なるレイヤーにわたって行われます。

レイヤー 1: ツール使用 (>95% の閾値) エージェントが適切なツールを正しいパラメータで呼び出したか？

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

「走行距離の少ない現代的なハッチバック」という検索クエリは、hybrid_search をトリガーし、意味的埋め込みと構造化フィルタを組み合わせます。

この動作は決定論的に評価できます。ToolSelectionGrader が呼び出されたツールを確認し、TrajectoryOrderGrader がその呼び出し順序を検証します。

レイヤー 2: 推論（閾値は 85% 以上）

意思決定のプロセスは論理的だったか。strands-agents-evals に含まれる HelpfulnessEvaluator と TrajectoryEvaluator は、LLM-as-judge スコアリングを用いて、エージェントの推論が一貫しているかを評価します。たとえ結果が正しくても、非論理的な推論プロセスを経て回答に到達したエージェントは、状況が変化した際に予測不能な形で失敗する可能性があります。

レイヤー 3：出力品質（90% の閾値以上）

回答は有益で、正確かつ実行可能だったか？strands-agents-evals に含まれる OutputEvaluator と GoalSuccessRateEvaluator は、LLM-as-judge 評価を用いて、ユーザーが有用で整形された回答を得られたかを判定します。

デプロイにはこの 3 つのレイヤーすべてを通過する必要があります。いずれかのレイヤーで失敗すれば、パイプラインはブロックされます。

非確実性の扱い

LLM の出力は実行ごとにばらつくため、単一の試行結果だけでは誤解を招く可能性があります。これに対処するため、コンパニオンリポジトリにある run_all_layers() 関数には num_trials パラメータが用意されています。

信頼性を測定するために、コード生成研究コミュニティで用いられる2 つの指標があります。

• pass@k は、k 回の試行のうち少なくとも1回成功する確率を測る指標です。正解となる解を1つ見つけられれば十分という場合に有用です。

• pass^k (pass to the power of k) は、k 回の連続した試行すべてで成功する確率を測る指標です。毎回安定して動作することをユーザーが期待する場合に役立ちます。

顧客対応型エージェントにおいて、パス率（pass^k）が最も重要です。1 回の試行あたりの成功率が 75% のエージェントでも、3 回連続で成功する確率はわずか 42%（0.75³）に過ぎません。ユーザーは、すべてのやり取りで一貫した高品質な成果を期待しています。

コンパニオンコードでは、run_all_layers(task_fn, registry, num_trials=5) が評価レイヤーを実行し、複数回の試行をサポートするとともに、パス率^k に基づいてデプロイを制御します。詳細な実装は こちら をご覧ください。

テストケースの管理

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

• ハッピーパス: 成功が期待される一般的なクエリです。
• エッジケース: 曖昧なクエリ、スラング、複数回のやり取りによる微調整などです。
• 安全性/ガードレール: エージェントが拒否または誘導すべきクエリです。

本番環境のモニタリングで問題を検知した場合、その対話は新たなテストケースとして登録されます。Motorway の事例では、初期の 50 件から 3 ヶ月で 150 件に増えましたが、これらはすべて実際のユーザー行動に基づいています。まずは 20〜50 件のケースから始め、本番データによって_suite_を拡張していくのがおすすめです。

エージェントが特定のツールを呼び出すべきではないネガティブケースも含まれるようにしてください。例えば、プロフィールに関するクエリでは検索ツールではなくプロフィールツールを呼び出す必要がありますし、構造化されたクエリには生 SQL のフォールバックではなく構造化検索を使用すべきです。片側だけの評価は、片側の最適化につながってしまいます。

複数回の対話テスト

単発の評価では見逃しがちなのが、会話の一貫性という重要な次元です。ディーラーは自然に複数のやり取りを通じて検索を洗練させていきます：

• 1 回目：「ディーゼル SUV を探して」
• 2 回目：「今度はオートマチック車だけにして」
• 3 回目：「ステーションワゴンはどう？」

strands-agents-evals フレームワークは、ActorSimulator を用いて現実的な複数回の対話シーンを生成し、InteractionsEvaluator によって各ターン間の文脈保持能力をスコアリングします。単発テストでは見逃されがちな文脈のズレやフィルタの蓄積による誤り、代名詞の解決失敗などを、複数回テストで検出できます。

AgentCore Evaluations で本番環境の挙動を監視する

Strands Agent を Amazon Bedrock AgentCore Runtime にデプロイした後、AgentCore Evaluations が継続的な監視を提供します。これは業界標準の観測性フレームワークである OpenTelemetry による計装を通じて Strands Agents と統合されます。図 3 は本番環境におけるアーキテクチャを示しており、観測性のトレースは 1〜5% の割合でサンプリングされ、メトリクスは Amazon CloudWatch に集約されています。

2 つの監視アプローチ

AgentCore Evaluations は、2 つの補完的なモードを提供します。

オンデマンド評価は、Amazon CloudWatch ログからスパンを選択して特定のエージェント対話を分析します。これは問題のデバッグや修正内容の検証に役立ちます。

オンライン評価では、ライブトラフィックを自動的にサンプリングし、バックグラウンドで評価器を実行します。サンプリング率（1〜5% を推奨）を設定し、最大 10 個の evaluator を選択して実行するだけです。

組み込みとカスタム評価器

AgentCore では、一般的なシナリオに対応した事前設定済み評価器が用意されています。以下の表は、組み込み評価器とその測定項目の一覧です。

評価器

レベル

測定内容

Builtin.Helpfulness

TRACE

エージェントの回答がいかに役立ったか（7 レベルで 0〜1 のスコア）

Builtin.GoalSuccessRate

SESSION

ユーザーの全体的な目標が達成されたかどうか

Builtin.ToolSelection