Motorway が Strands と AgentCore で構築した AI エージェント評価パイプラインの紹介

本記事は 2026 年 7 月 23 日 に公開された「Evaluating AI Agents: A production blueprint with Strands and AgentCore」を翻訳したものです。

本記事は、Motorway および AWS Prototyping and AI Customer Engineering (PACE) チームと共同で執筆しました。

英国を拠点とするオンライン中古車マーケットプレイスの Motorway は、最大 8,000 のディーラーが最大 2,500 台の車両に入札する日次オークションを運営しています。Motorway は AWS Prototyping and AI Customer Engineering (PACE) と協力し、AI を活用したディーラー向け在庫検索エージェントを構築しました。このエージェントによって、ディーラーの車両の探し方は大きく変わり、何時間もかかっていた手作業のフィルタリングが自然言語での問い合わせに置き換わりました。

課題

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

• ツール選択の誤りは誤った検索結果を招き、ディーラーの信頼を損ないます。
• セマンティック検索の誤解釈は、無関係な結果を返します。「5 年落ちまでのガソリン車、ハイブリッド車、電気自動車」のような問い合わせでは、エージェントが複数の条件を正しく解釈する必要があります。
• 複数ターンの会話でのコンテキストのずれは、ディーラーが絞り込んだ条件を失わせます。
• 非決定的な出力は、1 回だけのテストを信頼できないものにします。

解決策

Motorway と AWS は共同で、エンドツーエンドの評価パイプラインを構築しました。その結果、誤った結果は 8 件に 1 件から 50 件に 1 件へと減り、問題の検知にかかる時間は数時間から数分に短縮されました。

このパイプラインは、Strands Agents SDK と Amazon Bedrock AgentCore を組み合わせています。AgentCore は、AI エージェントを大規模にデプロイして運用するためのフルマネージドサービスです。本記事では、自分のエージェント向けにこのパイプラインを構築する方法を紹介します。

• 2 段階の評価戦略。ビルド時のテスト (Strands Agents 向けのオープンソース評価ライブラリ strands-agents-evals を使用) と、本番環境での監視 (Amazon Bedrock AgentCore Evaluations を使用) にまたがります。
• ツールの使い方、推論、出力品質を評価する3 層のフレームワーク。
• 品質ゲートを備えた5 段階のデプロイパイプライン。指標がしきい値を下回るとリリースをブロックします。

付属のリポジトリには、自分のエージェントに合わせて調整できる、デプロイ可能な設計図が含まれています。この設計図は 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 USD かかります。本番環境の監視コストは、サンプリングレートによって変わります。

セキュリティに関する注記: 付属のリポジトリは、最小権限の 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 エージェントの導入により、ディーラーはエージェントに話しかけられるようになりました。たとえば「近くのディーラーにある 2 万 5,000 ポンド以下のディーゼル SUV を探して」や「家族向けのスポーティなオートマ車」のように問いかけます。

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

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

大規模言語モデル (LLM) の評価は、テキスト生成の品質、つまり一貫性、事実の正確さ、応答の関連性に注目します。一方、エージェントの評価は、それとは根本的に異なるものを見ます。こう考えるとわかりやすいでしょう。LLM の評価はエンジンの性能を調べるものです。エージェントの評価は、渋滞のなか、雨のなか、あるいは後部座席が乗客でいっぱいのときに、車全体がどう走るかを見るものです。

従来の LLM の指標では、Motorway のエージェントが「グレード 1 の Suzuki のモデル」に対して正しい検索ツールを呼び出したかどうかはわかりません。エージェントが LanceDB に正しいフィルターパラメータを渡したかどうかも明らかになりません。さらに、前のターンの結果を絞り込むディーラーが正しい応答を得られたかどうかも見落とします。

「7〜12 年落ちの Volkswagen Golf」のような正確な問い合わせは完璧に動くかもしれません。しかし、「古めの VW を探している」のような口語的な言い回しは、セマンティック検索の層が適切に評価されていないと失敗することがあります。

strands-agents-evals でデプロイ前に問題を検出する

この設計図は、GenAIOps のライフサイクルに対応する 2 つのフェーズで評価を実装します。ビルド時の評価はデプロイ前に問題を検出し、本番環境での評価は合成テストが見落とすものを捉えます。次の図 (図 2) は、ツールの使い方、推論、出力品質の各層が、デプロイ前にすべて合格しなければならないことを示しています。このフレームワークは、エージェントを 3 つの層で評価します。

• レイヤー 1 (ツールの使い方) は、正しいツール選択とパラメータの受け渡しを、95% 超のしきい値で検証します。
• レイヤー 2 (推論) は、論理的な意思決定を、85% 超のしきい値で評価します。
• レイヤー 3 (出力品質) は、応答の有用性と正確さを、90% 超のしきい値で測定します。デプロイを進めるには、3 つの層すべてが合格する必要があります。

開発時、および継続的インテグレーションと継続的デプロイ (CI/CD) の際、パイプラインは strands-agents-evals フレームワークを使ってデプロイ前に問題を検出します。このフレームワークは、出力の検証、軌跡 (trajectory) の評価、複数ターンの会話のシミュレーション、実験の自動生成を提供します。いずれも、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 ポンドのディーゼル車」は、型付きフィルター
  (fuel_type=diesel、min_price=7000、max_price=20000) を指定して search_vehicles を使うべきです。
• 「走行距離の少ない新しめのハッチバック」は、セマンティックな埋め込みと構造化フィルターを組み合わせた 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 の出力は実行のたびに変わるため、1 回だけの試行の結果は誤解を招くことがあります。付属リポジトリの run_all_layers() 関数は、これに対処するために num_trials パラメータを受け取ります。コード生成の研究コミュニティ発の 2 つの指標が、信頼性の測定に役立ちます。

• pass@k は、k 回の試行で少なくとも 1 回成功する見込みを測ります。正しい解を 1 つ見つければ十分な場合に役立つ指標です。
• pass^k (pass の k 乗) は、k 回連続で成功する確率を測ります。ユーザーが毎回信頼できる挙動を期待する場合に役立つ指標です。

顧客向けのエージェントでは、pass^k が最も重要です。1 試行あたりの成功率が 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: 「かわりにステーションワゴンはどう?」

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 個の評価器を選んで、あとは実行させておきます。

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

AgentCore は、一般的なシナリオ向けにあらかじめ構成された評価器を提供します。次の表は、組み込みの評価器と、それぞれが測定する対象を示しています。

ドメイン固有の要件には、LLM-as-a-judge の構成を使ってカスタム評価器を作成できます。どのエージェントにも、組み込みの評価器がカバーしないドメイン制約があります。たとえば、データの鮮度、アクセスのスコープ、禁止された行動、レイテンシーの予算、コストの上限などです。

付属のリポジトリには、調整して使える 5 つのカスタム Evaluator サブクラスが含まれています。

LatencyEvaluator と CostEvaluator の例は、付属のリポジトリを参照してください。

追跡すべき主要な指標

付属のリポジトリには、CloudWatch のダッシュボードとアラームをプロビジョニングする AWS CDK スタックが含まれています。エージェントの健全性を監視するために、次の指標を追跡してください。

品質チェックをデプロイのゲートにする

評価は、後回しにするものではなく、デプロイパイプラインの品質ゲートにすべきです。図 4 は、評価ゲートを備えたデプロイパイプラインを示しており、ビルド時の評価、ステージングでの検証、シャドウモード、A/B テスト、本番環境へのロールアウトにまたがります。失敗するとデプロイはブロックされます。

デプロイパイプラインは、5 つのフェーズで進みます。

1. ビルド時の評価: ユニットテスト、ツールの正確さ (ToolSelectionGrader 95% 超)、軌跡のテスト、LLM-as-judge による採点 (HelpfulnessEvaluator 85% 超)。
2. ステージングでの検証: ステージングデータに対する合成トラフィックを使った、オンデマンドの AgentCore 評価。
3. シャドウモード: 実際の本番トラフィックを、ユーザーに影響を与えずに並行して処理します。2% の乖離しきい値を設定し、少なくとも 4 時間実行します。
4. A/B テスト: 稼働中のトラフィックの 5% を候補のエージェントにルーティングし、実際の結果を測定します。
5. 本番環境へのロールアウト: 継続的なオンライン評価と監視のもとで、トラフィックの 100% を移行します。

各フェーズにしきい値を定義します。ツール選択の正確さが 95% を下回るか、タスク完了率が 80% を下回ると、デプロイはブロックされます。大きなリリースでは、num_trials=5 による複数試行の評価が pass^k でゲートし、非決定的な失敗を捉えます。

シャドウモード

ステージングと本番環境の間で、候補のエージェントを、ユーザーに影響を与えずに実際の問い合わせに対して実行します。シャドウモードは、本番トラフィックの複製を受け取り、候補のエージェントで並行して処理し、結果を比較します。A/B テストに進む前に、シャドウモードを少なくとも 4 時間実行してください。デプロイを自動的に一時停止する乖離しきい値 (2% が良い出発点です) を定義します。

シャドウモードは、ほかの段階が見落とす問題を捉えます。

• 同時負荷のもとでのタイムアウト処理。
• 合成テストに含まれていないドメイン用語。
• 実際のトラフィックパターンのもとでレイテンシーの急増を引き起こす、ツール呼び出しの順序。

始め方: 段階的なアプローチ

フェーズ 1: テストスイートを作る。 実際のユーザーの問い合わせから抜き出した 20〜50 個のテストケースから始めます。ポジティブケースとネガティブケースの両方を含めます。エージェントが行うべきことと、拒否すべきことの両方をテストします。

フェーズ 2: ビルド時の評価を構成する。 採点器の種類を、測定する対象に合わせます。ツール選択には決定的な採点を、推論と出力品質には LLM-as-judge を使います。

フェーズ 3: 本番環境の監視を有効にする。 AgentCore Evaluations を 1〜5% のサンプリングレートで構成します。低めから始め、評価器のコストが許容範囲だと確認できたら引き上げます。

フェーズ 4: フィードバックループを閉じる。 本番環境の失敗をテストケースに変えます。失敗がリグレッションテストになると、このフィードバックループは、複数のチームで一貫して評価品質を高めてきました。

成果とインパクト

この評価パイプラインを導入する前、エージェントのツール選択の正確さは 87% でした。つまり、ディーラーの問い合わせ 8 件に 1 件は誤った結果を返していたことになります。本番環境のインシデントは月に 12 件発生しており、ディーラーに影響が出始めてから問題を検知するまで、平均 4 時間かかっていました。

パイプラインを導入した後の結果は次の通りです。

ビジネス面のインパクトとして、ディーラーは車両の検索を数時間ではなく数分で完了できるようになり、結果が正確で最新であるという確信も得られています。

トラブルシューティング

軌跡の採点器の失敗、LLM-as-judge のばらつき、評価結果が空になる問題、コストしきい値の調整など、よくある問題の解決策は、付属リポジトリの README を参照してください。

重要なポイント

評価パイプラインを構築するときは、次の原則を念頭に置いてください。

• 評価を層に分ける: ツールの使い方 (95% 超)、推論 (85% 超)、出力品質 (90% 超) は、それぞれ異なる失敗パターンを捉えます。
• 単一試行ではなく pass^k でゲートする: 1 試行あたりの成功率が 75% でも、3 回連続では信頼性が 42% しかありません。
• 本番環境の失敗をテストケースに変える: 実際のユーザーの行動で評価スイートを育てましょう。
• シャドウモードは合成テストが見落とすものを捉える: 実際のトラフィックは、タイムアウト処理、まれな用語、レイテンシーのパターンを明らかにします。
• 監視は 1% のサンプリングから始める: 評価器のコストを管理するために、少しずつ拡大します。

まとめ

ここまで、Motorway のディーラー向け在庫検索エージェントを実例として、AWS 上で本番運用の AI エージェント向けの評価パイプラインを構築する方法を見てきました。

核心となる教訓は、流暢な応答は、エージェントが正しいことをした証拠にはならないということです。ツールの選択、パラメータの正しさ、推論の一貫性、そして繰り返し実行したときの安定性を検証する必要があります。strands-agents-evals によるビルド時のテストと、AgentCore Evaluations による本番環境の監視を組み合わせることで、エージェントが設計通りに動くという裏付けを持ってデプロイできます。

これらのパターンは、複数のツールを使う顧客向けエージェントの多くに当てはまります。ナレッジベースやチケットシステムに問い合わせるカスタマーサービスのエージェント、ポートフォリオデータや市場フィードを取り込む金融アドバイザリーのエージェント、患者記録やスケジュール調整ツールにアクセスするヘルスケアのトリアージエージェントなど、いずれにも適用できます。

まずは次の手順から始めます。

1. 付属のリポジトリをクローンします。

   git clone https://github.com/aws-samples/sample-evaluating-agents-on-aws-with-strands-and-agentcore

2. CDK プロジェクトのディレクトリに移動します。

   cd sample-evaluating-agents-on-aws-with-strands-and-agentcore/examples/vehicle-auction-agent/cdk

3. サンプルのインフラをデプロイします。
   リポジトリの README のデプロイ手順に従って、サンプルのインフラをデプロイします。デプロイが完了したら、AWS CloudFormation コンソールですべての AWS CloudFormation スタックが CREATE_COMPLETE の状態になっていることを確認し、インフラを検証します。CloudWatch のダッシュボードと Lambda 関数が、それぞれのコンソールに表示されているはずです。
4. サンプルの評価スイートを実行します。 付属のテストケースに対して実行し、3 層のフレームワークが動く様子を確認します。成功したかどうかは、レイヤー 1 (ツールの使い方) の合格率が 95% 超、レイヤー 2 (推論) が 85% 超、レイヤー 3 (出力品質) が 90% 超になっていることで確認します。いずれかの層が失敗した場合は、CloudWatch のログで詳細なエラーメッセージを確認してください。
5. 評価器を自分のドメインに合わせてカスタマイズします。 DataFreshnessEvaluator と SafetyGuardrailEvaluator をテンプレートとして始めます。

さらに深く知るには、Amazon Bedrock AgentCore のドキュメントと、GitHub 上の Strands Agents SDK を調べてみてください。

リソースのクリーンアップ

継続的な課金を避けるために、このチュートリアルで作成したリソースを削除します。

1. CDK プロジェクトのディレクトリに移動します。

   cd sample-evaluating-agents-on-aws-with-strands-and-agentcore/examples/vehicle-auction-agent/cdk

2. デプロイしたすべてのスタックを削除します。

   cdk destroy --all

3. プロンプトが表示されたら、削除を確定します。
4. AWS マネジメントコンソールで、Lambda 関数、S3 バケット、DynamoDB テーブル、CloudWatch のロググループとダッシュボード、EventBridge のルール、SNS トピックを含むすべてのリソースが、クリーンアップ処理で削除されたことを確認します。

注意: オブジェクトが入っている S3 バケットは、手動での削除が必要な場合があります。保持したい評価データやログがある場合は、クリーンアップを実行する前にエクスポートしてください。

参考資料

• Evaluating AI agents for production: A practical guide to Strands Evals。
• Strands Agents SDK。
• strands-agents-evals。
• Amazon Bedrock AgentCore Evaluations。
• Evaluating AI agents: Real-world lessons from Amazon。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。