AIエージェントを本番環境で評価する：Strands Evals実践ガイド

AI エージェントをプロトタイプから本番環境へ移行させる際、従来のテスト手法では対応できない課題が浮き彫りになります。エージェントは設計上、柔軟で適応性があり、文脈を理解する能力を持っていますが、その強力さをもたらす同じ特性が、体系的な評価を困難にしています。 従来のソフトウェアテストは、決定論的な出力を前提としています：同じ入力であれば、毎回同じ期待される出力が得られるはずです。しかし AI エージェントはこの前提を崩します。彼らは自然言語を生成し、文脈に応じた意思決定を行い、同一の入力からであっても多様な出力を生み出します。非決定論的なものをどのように体系的に評価すればよいのでしょうか？ 本稿では、[Strands Evals](https://github.com/strands-agents/evals) を用いて AI エージェントを体系的に評価する方法を示します。コアとなる概念、組み込みの評価機能（evaluators）、多ターンシミュレーション能力、および統合のための実践的なアプローチとパターンについて解説します。Strands Evals は、Strands Agents SDK で構築された AI エージェントを評価するための構造化されたフレームワークを提供し、評価機能、シミュレーションツール、レポート機能を備えています。エージェントが適切なツールを使用しているか、有益な応答を生み出しているか、ユーザーの目標達成を導いているかなどを検証する必要がある場合でも、このフレームワークはこれらの特性を体系的に測定・追跡するためのインフラストラクチャを提供します。 ## AI エージェントの評価が異なる理由 エージェントに「東京の天気はどうですか？」と尋ねると、多くの有効な回答が存在し、単一の絶対的に正しい答えはありません。エージェントは摂氏または華氏で気温を報告したり、湿度や風を含めたり、あるいは気温だけに焦点を当てたりするかもしれません。これらのバリエーションはすべて正しく有益でありえるため、従来のアサーションベースのテストでは不十分です。テキスト生成を超えて、エージェントは行動も取ります。よく設計されたエージェントは、会話を通じてツールを呼び出し、情報を取得し、意思決定を行います。最終的な応答だけを評価しても、その応答に至るために適切な手順が取られたかどうかを見逃してしまいます。 正解の回答であっても不十分である場合があります。回答が事実に基づいていても役に立たない場合や、有用であってもソース資料に忠実でない場合があります。これらの異なる品質の次元を捉える単一の指標はありません。会話にはもう一つの複雑さの層が加わります。なぜなら会話は時間を経て展開されるからです。多ターン対話では、以前の応答が後の応答に影響を与えます。エージェントは個々のクエリにはよく対応できても、会話全体を通じて一貫した文脈を維持できない場合があります。単一のターンを孤立してテストしても、これらの相互作用パターンを見逃すことになります。 これらの特性は、キーワード比較ではなく判断を要する評価を必要とします。大規模言語モデル（LLM）ベースの評価はこのニーズに応えるものです。言語モデルを評価者として用いることで、機械的なチェックでは困難な有用性、一貫性、忠実度といった品質を評価できます。Strands Evals はこの柔軟性を受け入れつつも、厳密で再現可能な品質評価を提供します。 ## Strands Evals の核心概念 Strands Evals は、ユニットテストを書いたことのある人なら誰でも馴染みを感じるパターンに従いますが、AI エージェントが求める判断ベースの評価に適応させています。このフレームワークは、**ケース（Cases）**、**実験（Experiments）**、および**評価者（Evaluators）**という 3 つの基礎概念を導入し、これらが連携して機能します。 Figure: High-Level Architecture **ケース（Case）** は、単一のテストシナリオを表します。これは、テストしたい入力（例えば「パリの天気はどうですか？」といったユーザーの問い合わせ）を含み、オプションとして期待される出力、軌道（trajectories）と呼ばれる期待されるツールシーケンス、およびメタデータを含みます。ケースは評価における原子単位です。各ケースは、エージェントが正しく処理すべき一つのシナリオを定義します。 from strands_evals import Case case = Case( name="Weather Query", input="What is the weather like in Tokyo?", expected_output="Should include temperature and conditions", expected_trajectory=["weather_api"] ) An **Experiment** bundles multiple Cases together with one or more evaluators. Think of it as a test suite in traditional testing. The Experiment orchestrates the evaluation process. It takes each Case, runs your agent on it, and applies the configured evaluators to score the results. **Evaluators** are the judges. They examine what your agent produced (the actual output and trajectory) and compare it against what was expected. Unlike simple assertion checks, evaluators in Strands Evals are primarily LLM-based（大規模言語モデルベース）. They use language models to make nuanced judgments about quality, relevance, helpfulness, and other qualities that cannot be reduced to string comparison. Separating these concerns helps keep the framework flexible. You can define what to test with Cases, how to test it with evaluators, and the framework handles orchestration and reporting through Experiments. Each piece can be configured independently so that you can build evaluation suites that are tailored to your specific needs. ## The task function: connecting agents to evaluation Cases define your scenarios, and evaluators provide judgment. But how does your agent actually connect to this evaluation system? That is where the **Task Function** comes in. タスク関数とは、実験に提供される呼び出し可能なものであり、ケースを受け取って、そのケースをシステムを通じて実行した結果を返します。このインターフェースは、2 つの根本的に異なる評価パターンを可能にします。 図：タスク関数のパターン **オンライン評価**では、評価実行中にエージェントを実際に呼び出します。タスク関数はエージェントを作成し、ケース入力を送信し、応答と実行トレースをキャプチャして、評価のためにそれらを返します。このパターンは、変更を即座にテストしたい開発時や、デプロイ前にエージェントの動作を検証する必要がある継続的インテグレーションおよびデリバリー（CI/CD）パイプラインで推奨されます。 from strands import Agent def online_task(case): agent = Agent(tools=[search_tool, calculator_tool]) result = agent(case.input) return { "output": str(result), "trajectory": agent.session } **オフライン評価**は履歴データと連携します。エージェントを呼び出す代わりに、タスク関数はログ、データベース、または観測システムから事前に記録されたトレースを取得します。これらのトレースを評価者が期待する形式に解析し、判断のために返します。このパターンは、本番トラフィックの評価や、履歴分析の実行、あるいは同じセットの実際のユーザー相互作用に対してエージェントバージョンを比較する場合に適しています。 def offline_task(case): trace = load_trace_from_database(case.session_id) session = session_mapper.map_to_session(trace) return { "output": extract_final_response(trace), "trajectory": session } 新しいエージェント実装のテストを行う場合でも、数ヶ月分の本番データを分析する場合でも、使用する評価器やレポートインフラストラクチャは同じです。タスク関数は、データソースを評価システムに適応させる役割を果たします。 ## 包括的な評価のための組み込み評価器 タスク関数によってエージェントの出力が評価システムに接続されたことで、どの品質側面を測定するかを決定できるようになりました。Strands Evals には、10 の組み込み評価器が搭載されており、それぞれがエージェントの質の異なる次元を評価するために設計されています。 図：評価器の種類 ## ルーブリックベースの評価器 最も柔軟性が高い評価器では、自然言語によるルーブリック（評価基準）を通じて独自の基準を定義することができます。 - OutputEvaluator は、エージェントが生成する最終応答を評価します。あなたは良い成果の基準となるルブリック（評価基準）を提供し、評価者は LLM を使用してその基準に対して出力を採点します。これは、ユースケースに固有の特定の基準を定義したい一般的な品質チェックにおいて効果的です。 from strands_evals.evaluators import OutputEvaluator output_evaluator = OutputEvaluator( rubric="応答が質問に正しく答え、かつ構造化されている場合は 1.0 を付与する。部分的に正しい場合は 0.5 を付与する。誤りまたは無関係な場合は 0.0 を付与する。" ) - TrajectoryEvaluator はこれを超えて、エージェントが実行した一連のアクション（通常はツール呼び出し）を検査します。最終回答のみを確認するだけでなく、エージェントが論理的な順序で適切なツールを使用したかどうかも検証できます。評価者には、実際の軌道と期待される軌道を比較するための 3 つの組み込み採点関数が用意されています：完全一致 (exact match)、順序一致 (in-order match)、および任意順序一致 (any-order match) です。これらのスコアラーは評価用 LLM にツールとして提供され、LLM はルブリックに基づいて最も適切なものを選択します。 - InteractionsEvaluator は、複数のコンポーネントが通信するマルチエージェントシステムを扱います。これは、エージェント間またはシステムコンポーネント間の相互作用シーケンスを評価するものです。アーキテクチャにオーケストレーター、サブエージェント、あるいは複雑なツールチェーンが含まれる場合に有用です。 ## セマンティック評価器 いくつかの品質次元は十分に一般的であるため、Strands Evals では、注意深く設計されたプロンプトと採点尺度を備えた事前構築型評価器を提供しています。 - HelpfulnessEvaluator は、「全く役に立たない」から「それ以上」までの 7 段階スケールを用いて、ユーザーの視点から回答を評価します。技術的に正しいかどうかだけでなく、実際にユーザーのニーズに応えているかを評価対象とします。 - FaithfulnessEvaluator は、回答が会話履歴に基づいているかを確認します。これは特に、エージェントが情報を捏造（ハルシネーション）していないことを確認する必要がある Retrieval Augmented Generation (RAG) システムにおいて重要です。5 段階スケールは、「全く基づいていない」から「完全に基づいている」までをカバーしています。 - HarmfulnessEvaluator は安全性チェックを実行し、回答に有害、不適切、または危険なコンテンツが含まれていないかを判断するのを支援します。明確な意思決定のために、Yes/No の二値判定を提供します。 ## ツールレベル評価器 エージェントがツールを使用する場合、最終結果だけでなく、個々のツールの呼び出しの質も評価する必要があります。 - ToolSelectionAccuracyEvaluator は、文脈内の各ツール呼び出しを検査し、会話の状態を踏まえてその特定のツールを選択することが正当化されたかどうかを判断します。これは「会話のこの時点で、このツールを呼び出すことは妥当だったか？」という問いに答えます。 - ToolParameterAccuracyEvaluator はさらに深く入り込み、各ツールに渡されたパラメータが正しく適切であったかどうかを確認します。これにより、正しいツールが選択されたものの、誤ったまたは不完全な引数で呼び出されてしまうような微妙なエラーを検出するのに役立ちます。 ## セッションレベルの評価器 - GoalSuccessRateEvaluator は最も広範な視点を取り、会話セッション全体を評価して、ユーザーが最終的に目標を達成したかどうかを判断します。タスク指向のエージェントにおいては、成功は単一の応答ではなく結果によって定義されます。 ## 適切な評価器の選択 適切な評価器の選択は、アプリケーションにとって何が最も重要かによって異なります。カスタマーサービスエージェントであれば、有用性と目標達成率を優先するかもしれません。研究アシスタントであれば、忠実性を強調するでしょう。まずはコアとなる品質次元をカバーする少数の評価器から始め、エージェントがどのように失敗するかを理解した上で、必要に応じて追加していくのがよいでしょう。 ## 多ターンテストのためのユーザーシミュレーション 前述の評価機能は、入力を提供して出力を取得し、それを評価する単一ターンの対話においてはよく機能します。しかし、多ターンでの会話ではより困難な課題に直面します。実際のユーザーはスクリプト通りに動くわけではありません。フォローアップ質問をしたり、方向を変えたり、混乱を示したりします。これをどうテストすればよいのでしょうか？Strands Evals には、AI を活用した模擬ユーザーを作成し、あなたのエージェントとの多ターン会話を駆動する「ActorSimulator」が含まれています。 図：ユーザーシミュレータのフロー **ActorSimulator** は、ユーザーが達成したいことを定義したテストケースから開始します。これに基づき、LLM（大規模言語モデル）を使用して、性格特性、専門知識レベル、コミュニケーションスタイル、および特定の目標を含む現実的なユーザープロファイルを生成します。このプロファイルは、会話全体を通じて模擬ユーザーがどのように振る舞うかを形作ります。 from strands_evals import Case, ActorSimulator from strands import Agent case = Case( input="I need help setting up a new bank account", metadata={"task_description": "Successfully open a checking account"} ) user_sim = ActorSimulator.from_case_for_user_simulator( case=case, max_turns=10 ) 相互作用中、模擬ユーザーはあなたのエージェントにメッセージを送信し、応答を受け取り、次に何を言うかを決定します。このループは、特別な停止トークンを発して目標が達成されたか、または最大ターン数に達するまで続きます。 agent = Agent(system_prompt="あなたは親切な銀行アシスタントです。") user_message = case.input while user_sim.has_next(): agent_response = agent(user_message) user_result = user_sim.act(str(agent_response)) user_message = str(user_result.structured_output.message) 次に、このようにして生成された会話のトランスクリプトを、セッションレベルの評価器（例：GoalSuccessRateEvaluator）に渡すことで、エージェントがシミュレートされたユーザーの目標達成を無事に支援できたかどうかを評価できます。手動で多段階のスクリプトを作成する代わりに、目標を定義し、シミュレーターに現実的な対話パターンを作成させることができます。予期せぬフォローアップ質問をしたり、混乱を示したり、スクリプト化されたテストでは見逃されがちなエッジケース（境界条件）を捉えるために、あなたが想定していなかった方向へ会話を進めたりすることもあります。 ## 評価レベル：階層構造の理解 シミュレーションされた会話か実際の会話かに関わらず、異なる評価器は異なる粒度で動作します。Strands Evals は TraceExtractor を使用して、セッションデータを各評価器が必要とする形式に解析します。 **セッションレベル**の評価は、最初から最後までの一連の会話を包括的に見ます。評価器は完全な履歴、ツール実行情報を受け取り、文脈全体を理解します。GoalSuccessRateEvaluator はこのレベルで動作します。なぜなら、目標達成を判断するには、相互作用全体を理解する必要があるからです。 **Trace level**評価は、個々のターン、各ユーザープロンプトとエージェント応答のペアに焦点を当てます。このレベルの評価者は、その時点までの会話履歴を受け取り、特定の応答を判断します。有用性（Helpfulness）、忠実度（Faithfulness）、有害性（Harmfulness）に関する評価者がここで機能するのは、これらの品質がターンごとに評価可能だからです。 **Tool level**評価は、個々のツール呼び出しにまで掘り下げます。各ツールの呼び出しは、利用可能なツール、これまでの会話、および渡された特定の引数へのアクセスを伴う文脈内で評価されます。ツール選択（Tool Selection）とツールパラメータ（Tool Parameter）の評価者がこの粒度で動作します。 階層型設計を活用することで、複数のレベル simultaneously に品質を検証する評価スイートを構成できます。単一の評価実行の中で、個々のツール呼び出しが妥当であるか、応答が有用であるか、そして全体の目標が達成されたかを検証することが可能です。 ## 正解と期待される動作 多くの異なる評価レベルにおいて、評価者は比較のための基準点を持つことで恩恵を受けます。Strands Evals は、Cases の3 つの期待フィールドを通じて、正解（ground truth）に対する第一級のサポートを提供します。 expected_output フィールドは、エージェントが発言すべき内容を指定するものです。これは正解が存在する場合や、標準的な応答フォーマットがある場合に有用です。また、expected_trajectory フィールドは、エージェントが取るべきツールまたはアクションのシーケンスを定義します。例えば、カスタマーサービスエージェントに対して変更を加える前にアカウントステータスを確認することを要求したり、研究用エージェントに対して合成を行う前に複数のソースを検索することを要求したりできます。すべてのケースで全てのフィールドが必要というわけではありません。評価目標にとって重要な事項に基づいて期待値を設定してください。期待値が提供された場合、評価者は期待される結果と実際の結果の両方を受け取り、単独での品質評価に加えて比較に基づくスコアリングが可能になります。 ## すべてを統合する これらの概念がいかにして統合されるかを確認するために、典型的な評価ワークフローを追ってみましょう。

AIエージェントを本番環境で評価する：Strands Evals実践ガイド

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

調べる

選ぶ

サイト