アリババ、AI エージェントの精密な評価体系設計と実装を公開

砚东 2026-09-02 18:11 浙江

本記事はアリババグループ傘下の国際ECプラットフォーム「AliExpress（アリエクスプレス）」技術チームが提供する公式情報に基づいています。

AliExpress Tech は、同社の技術部門を代表する公式アカウントであり、国際EC分野における最新技術の動向や革新的な取り組みを紹介しています。

AI エージェントの運用における評価体系の設計と、その実装に関する実践的な知見について、いくつかの経験と参考事例を共有します。

優れた評価体系は、チームが AI エージェントをより自信を持ってリリースする手助けとなります。評価がないと、本番環境で問題を検知し、その修正が別の不具合を生むという悪循環に陥りやすくなります。

——— 《Demystifying evals for AI agents》

2026 年、第 57 回記事

（本文の読了時間：約 20 分）

01

導入：AI エージェントに何を評価すべきか？

1.1「使える」から「使いやすい」への距離

近年、大規模言語モデルを基盤とした AI エージェントは各業界で急速に普及しています。しかし、エージェントアプリケーションがリリースされた後、チームはしばしば困難な状況に直面します。「回答が間違っている」「反応が遅い」「質問と関係ない答えばかりだ」といったユーザーからのフィードバックに対し、開発者が根本原因を特定するのは容易ではありません。

意図の理解にズレが生じたのか？ルートの選択を誤ったのか？知識検索で重要な情報が抜け落ちたのか？それともツール呼び出しのパラメータが間違っていたのか？複数のモジュールが直列に連携する際、エンドツーエンドのブラックボックス評価では「結果が正しくない」という事実しか示せず、「どこが問題なのか」を説明することはできません。

1.2 従来の評価手法の限界

NLP（自然言語処理）分野の評価の歴史を振り返ると、BLEU や ROUGE などの指標は長年、機械翻訳やテキスト要約の標準的な評価手段として使われてきました。しかし、エージェント時代においては、「テキストの類似度」に焦点を当てたこれらの指標ではもはや対応しきれません。なぜなら、エージェントは「正解を生成する装置」ではなく、「意図を理解し、意思決定を行い、ツールを呼び出し、タスクを完了させる多段階の自律型システム」だからです。

これまでのチームの評価活動は、主にエージェントが出力した最終回答の質に注目が集まっていました。事前に用意した数種類の「テキスト類似度」指標を用いて LLM に採点させることで、エージェントがある程度基礎的な能力を備えていることを簡易的に確認することは可能です。しかし、この手法には以下の根本的な課題があります：

評価の粒度が粗すぎると、総合スコアが AI エージェントの実働ルートの真価を隠してしまいます。例えば、2 つのバージョンの Agent がほぼ同点の場合、開発者は「特定の工程で劇的に改善され、別の工程では著しく劣化しているのか」、それとも「全工程が均等に振動しているだけなのか」を判断できません。

幻覚（ハルシネーション）を検出できないという課題もあります。テキストの類似度指標は、一見妥当だが実際にはでっち上げられた回答に高得点を与えてしまう可能性があります。幻覚の内容は文法や論理、語彙において完璧なことが多いですが、LLM は「表現が似ているか」しか確認できず、「内容が正確か」を検証することはできません。

中間プロセスを無視している点も問題です。最終回答だけを比較するのは、Agent をブラックボックスとして扱うに等しく、Agent が遠回りをしたかどうか（例えば、冗長なツール呼び出しを行ったか、重要なステップでズレが生じた末に「当たって」しまったのか）を発見できません。

コスト効率のカバーも不十分です。2 つの Agent が同じ品質の回答を出力しても、片方はツールを 3 回呼び出して 2 秒で完了し、もう片方は 15 回呼び出して 15 秒かかる場合、単一の品質スコアではこのリソース消費の違いが完全に隠されてしまいます。しかし、これは本番環境において極めて重要な要素です。

多輪対話の評価が欠如しています。実際の Agent は多輪対話を前提としていますが、評価は往々にして単発の質問応答に留まります。そのため、多輪のやり取りの中で文脈を失っていないか、確認済みの情報を繰り返し質問していないか、ユーザーの指摘に対して頑なに自分の意見を曲げないかなどを衡量できません。

実社会との乖離も懸念点です。評価セットは人工的に作られた「きれいな」問題が中心ですが、本番環境でのユーザー入力は曖昧さや口語表現、文脈依存に満ちています。ある評価セットで高得点を取得した Agent でも、実際のユーザーの曖昧な要求に対しては頻繁に失敗する可能性があります。

以前の評価手法にご興味があれば、以下の実践記事もご参照ください：『グローバル商品センター向けインテリジェント Q&A エージェントの実践』

1.3 本稿が提案する解決策

粗粒度的な「合格/不合格」の判定では、ビジネスの急速なイテレーションを支えることができません。私たちは「どの工程で」「どのような理由で」「どれほどの確率でエラーが発生したか」を知りたいのです。そこで、商品センター Agent アプリケーションのアーキテクチャ刷新に伴い、本稿では AI エージェントアプリケーションのための精緻化評価体系を構築しました。その設計は以下の 3 つのコア原則に基づいています。

・評価はアーキテクチャに即して：商品センター Agent は「知覚」「計画」「記憶」「ツール」という 4 つの核心モジュールで構成されています。評価も同様にこの構造に沿って逐層分解し、各層の品質を独立して観測可能とします。

・指標は行動指向：各指標は「成績表」ではなく「診断レポート」です。その価値は高得点を出すことではなく、スコアが低下した際に開発者に「Skills を修正すべきか」「MCP ツールを交換すべきか」「知識検索を最適化すべきか」を正確に示すことにあります。

・能力は製品指向：評価はリリース前に一度実行して捨てるスクリプトであってはなりません。監視アラートのように持続的に運用でき、横断的な比較が可能で、進化の追跡が可能なインフラストラクチャであるべきです。

本稿では、指標体系の設計、データセット工学、評価方法論、実行エンジンから可視化プラットフォームに至るまで、この評価体系の設計思想とエンジニアリング実践を包括的に共有します。

02 評価体系の全体像：ブラックボックスからホワイトボックスへ

2.1 Agent の内部構造を理解する

評価体系を設計する前に、まず評価対象となるものの内部構造を理解する必要があります。商品センターの Agent アプリケーションは、以下の 4 つのコアモジュールが連携して動作します。

・知覚モジュール：ユーザー入力の受信を担当し、LLM を用いて問題が登録済みの Skill で直接処理可能かを判断します。これにより、ユーザーの問題に対する意味理解と意図認識を実現します。また、デグラード戦略も提供しており、条件に合致しない場合は自動的に知識ベース検索パスへ切り替えることで、ユーザーのインタラクション体験を向上させます。

・計画モジュール：知覚結果に基づいて実行戦略を策定し、ツールの呼び出しが必要か、知識ベースの検索を行うべきか、記憶をどのように保存すべきかを決定します。永続化設定を通じて実行ロジックを定義することで、Skill シナリオと RAG（Retrieval-Augmented Generation）シナリオの自動分流を実現し、システムの保守性と拡張性を高めます。

・記憶モジュール：Agent に短期および長期の記憶能力を提供します。短期記憶はセッション ID を基に多輪対話の文脈を維持し、スライディングウィンドウ機構を用いて直近の N 輪分の履歴を切り取り、ユーザープロファイル情報を注入します。一方、長期記憶は RAG 知識ベースと連携し、検索結果をコンテキストとして Prompt に注入することで、回答の精度と専門性を高めます。

ツールモジュールは、エージェントへのツール接続管理機能を提供します。具体的には、MCP プロトコルを通じてリモートツールの自動検出と登録を行い、複数サーバーの設定と統一された呼び出しを可能にします。また、ファイルシステムに基づくスキル管理では、エージェント単位でデータを隔離し、ホットアップデートの配信をサポートしています。これら 2 つのツールは標準的なコールバックインターフェースとして統一され、エージェントが必要に応じてスケジューリングして実行されます。

エージェントの詳細な仕組みについてさらに知りたい方は、以下の実践記事をご覧ください：「国際化 IC- 基盤とした Spring AI Alibaba のスマート Q&A 実装」

2.2 なぜモジュールレベルで評価するのか？

仮にエージェントのタスク完了率が 85% から 60% に低下した場合、その原因は以下のいずれかです。

• 知覚モジュールが「Trace の確認」を誤って知識ベースへの質問と認識した（意図認識エラー）
• 計画モジュールがスキル呼び出しを行うべき場面で RAG 検索を選択してしまった（ルーティング判断エラー）
• 記憶モジュールが多輪会話の中で、直前の発言で言及された商品 ID を失った（記憶喪失エラー）
• ツールモジュールが MCP やツールのパラメータを誤って呼び出した（ツール呼び出しエラー）

エンドツーエンド評価は本質的にブラックボックステストです。まるで車をテストコースに走らせるようなもので、エンジン回転数やギアチェンジのロジック、ブレーキパッドの摩耗度合いには関心を持ちません。ユーザー視点で問うのは「この車は A 地点から B 地点まで無事に到着できるか」という一点だけです。

一方、モジュールレベル評価はホワイトボックス診断です。車をリフトアップしてエンジン、ブレーキ、油路の各状態を個別にチェックし、「安全に」「定時で」「経済的に」目的地へ到達できるかを重視します。エンドツーエンド評価が「良い車とは何か」の基準を定義するのに対し、モジュールレベル評価は「車を修理する方法」を示すものです。両者は補完関係にあり、どちらも不可欠です。

2.3 なぜ「品質 × コスト × パフォーマンス」指標が必要なのか？

「回答は正しいが、完了までに 30 秒かかる」エージェントは良いとは言えません。「回答は正しいが、1 回あたり 10 万トークンを消費する」エージェントも持続可能ではありません。最終的にエージェントは本番環境にデプロイされ、実ユーザーにサービスを提供します。そのため、評価フレームワークは以下の 3 つの問いに同時に答えなければなりません。

• 回答の質はどうか？
• コストは高くないか？
• 速度は十分か？

したがって、本稿では AI エージェントアプリケーションの評価を次の 3 つの次元で設計します。

品質の次元：回答が正しいか、完全か、知識ソースに忠実か、あるいはハルシネーション（幻覚）が発生していないか。これは最低限の要件ですが、すべてではありません。

コストの次元：1 回のリクエストでモデル呼び出しが何回発生し、外部ツールを何ラウンド呼び出したか、また消費されたトークン数はどれくらいか。

パフォーマンスの次元：ユーザーが Enter キーを押してから最初の文字が表示されるまでの遅延、そして回答が完全に完了するまでの遅延。これらが直接ユーザー体験を左右します。

理論上、この 3 つの次元はすべて欠かせません。品質のみを追求すればコストやレイテンシが制御不能になる恐れがあります。速度だけを最適化すると複雑な問題で過度に簡略化するリスクがあり、コストだけを見ると精度が急激に低下する可能性があります。健全なエージェントとは、現在のビジネスシーンにおいてこれら 3 つの次元の最適なバランスを実現したものです。

2.4 評価範囲、データセットと指標のマッピング

既存の評価ワークを参考にし、本稿では全体評価を以下の 2 つの部分に分類します。

エンドツーエンド評価：主にエージェントが単一のユーザー質問を受け取った後、自律的かつ効果的にタスクフロー全体を完了し、期待通りの出力結果を得られるかに焦点を当てます。タスクの完成度、コスト消費量、効率性、そしてセキュリティとロバスト性の 4 つの観点から、エージェント全体の性能を総合的に評価します。

核心モジュールの評価：主要な評価対象は、エージェントの内部動作メカニズムや潜在的なボトルネックを深く分析するための「知覚」「計画」「記憶」「ツール」といった各モジュールです。各モジュールについては、能力・効率・有効性といった複数の観点から細かく評価を行い、問題の根本原因を特定しやすくします。

評価の目的に応じて、必要なデータセットや指標の組み合わせは異なります。また、指標そのもののデータソースも多様です。例えば、初回応答までの遅延（首響）やトークン消費量、モデル呼び出し回数といったコストや性能に関する指標は、システムに埋め込んだ計測ポイント（埋点）から直接収集できます。一方、タスクの完了率や意図認識の精度、ツール呼び出し成功率、忠実度（ファースト性）といった品質に関わる指標については、評価用データセットに基づいて判定する必要があります。

本稿では、事前に定義した評価範囲と、それに対応するデータセット・指標のマッピングを通じて評価を実施します。評価範囲を指定すると、自動的に該当のデータセットが用意され、関連する計測ポイントも取得されます。評価範囲を変更すれば、データセットや計測項目も自動で切り替わるため、人手による個別のデータソース連携は不要です。「評価範囲の選択→データセットの自動準備→指標の自動選定」という流れにより、評価プロセスをシンプルかつ柔軟に運用できます。

• 評価モード：対象となるデータセット / カバーする計測項目
• エンドツーエンド評価：基本スキル評価セット、知識クエリ評価セット、多輪対話評価セット、異常入力評価セット / モデル呼び出し回数、ツール呼び出し回数、トークン消費量、初回トークン遅延、エンドツーエンド応答遅延、モジュールレベル遅延
• コアモジュール評価：基本スキル評価セット、知識クエリ評価セット、多輪対話評価セット、ツール呼び出し評価セット、マルチ意図評価セット、曖昧意図評価セット、長文対話減衰評価セット / モデル呼び出し回数、ツール呼び出し回数、トークン消費量、モジュールレベル遅延
• 知覚モジュール評価：基本スキル評価セット、知識クエリ評価セット、マルチ意図評価セット、曖昧意図評価セット / 意図認識遅延
• 計画モジュール評価：基本スキル評価セット、知識クエリ評価セット、ツール呼び出し評価セット / 計画意思決定遅延
• 記憶モジュール評価：知識クエリ評価セット、多輪対話評価セット、長文対話減衰評価セット / 短期記憶注入遅延、長期記憶検索遅延
• ツールモジュール評価：ツール呼び出し評価セット / ツール呼び出し遅延、ホットアップデート適用までの遅延

• データセット名：カバーする評価指標
• 基本スキル評価セット：タスク完了率、指示従順性、意図認識精度・再現率・適合率、ルーティング意思決定の正確さ、計画パスの評価スコア
• 知識クエリ評価セット：タスク完了率、ハルシネーション率（忠実度）、意図認識精度・再現率・適合率、フェイルオーバートリガーの正確さ、ルーティング意思決定の正確さ、計画パスの評価スコア、ナレッジベース検索意思決定の正確さ、長期記憶検索の適合率・再現率
• 多輪対話評価セット：多輪対話完了率、短期記憶保持率
• 異常入力評価セット：異常入力処理率
• ツール呼び出し評価セット：ツール呼び出し意思決定の正確さ、ツール呼び出し精度、ツール呼び出し成功率、パラメータマッピングの正確さ
• マルチ意図評価セット：マルチ意図認識率
• 曖昧意図評価セット：曖昧意図の明確化率
• 長文対話減衰評価セット：記憶減衰曲線

03

評価指標：主要指標設計のロジック

3.1 エンドツーエンド：ユーザーが体感する6 つの指標

これは、ユーザーが最も直接的に感じ取ることができる指標群です。

「タスク完了率」は、評価体系における最も重要な指標（北极星指標）です。これは「エージェントがユーザーの依頼したタスクを無事に完了させたか」という最も基本的な問いに答えるものです。

判断基準は意味的な完成度に基づきます。字面通りの一致を要求するのではなく、核心となる情報が欠落していなければ合格とみなします。例えば、「商品が販売不可になった理由」をユーザーが尋ねた際、エージェントが販売不可の診断分析を正しく出力すれば、回答の表現が標準解答と完全に一致しなくても通過となります。

「多輪対話完了率」は、複数回のやり取りが行われるシナリオにおけるエージェントのパフォーマンスを評価するものです。2〜5 回程度の会話を通じて、ユーザーの意図を継続的に理解し、文脈の一貫性を保ちながら最終的にタスクを達成できるかが問われます。この指標では、各ターンを個別に採点するのではなく、一連の対話全体に対して総合的な評価を下す必要があります。

「指示遵守能力」は、形式の正しさに焦点を当てた指標です。特定のスキル（Skill）シナリオでは、回答フォーマットに明確な制約が設けられている場合があります。例えば、モジュールごとに分けて出力する必要がある場合や、特定の分析次元を含める必要がある場合、あるいは表形式で提示することが求められるケースなどです。この指標は、エージェントが業務上の制約に従って適切なフォーマットで回答できているかを測定するために用いられます。

「ハルシネーション率（忠実性）」は、エージェントが取得した知識ベースの断片や、ツールからの返却データ、多輪対話における過去の文脈に対して忠実に応答しているかどうかを判断するものです。「根拠のない情報を捏造」したり、「既存の内容を勝手に改変」したりしていないかを確認します。

この指標を設計する際、評価の範囲を明確に区切りました。評価の対象は「エージェントが忠実に転記したか」という点のみで、情報源自体の正確性までは判断しません。その理由は、エージェントの本質が情報処理装置であるためです。エージェントは知識ベースを検索したりツールを呼び出したりして情報を取得し、それに基づいて推論と回答を行います。もし知識ベースの原文自体に誤りがあれば、それは知識ベース独自の評価体系で保証すべき事項です。エージェントが自身の目にした内容をそのまま反映していれば、最終的な答えが客観的事実と異なっていたとしても「忠実」と判定されます。

具体的な判定基準としては、検索結果に対する合理的な要約や、文脈に基づいた説明性の補足はすべて「忠実」に分類します。一方で、文脈上に存在しないインターフェース名、関数名、設定項目などをでっち上げたり、検索結果と直接矛盾する核心情報を提示したりした場合は、「ハルシネーション（幻覚）」として扱います。

「異常入力処理率」は、エージェントのセキュリティと堅牢性を評価する指標です。空の入力、極端に長いテキスト、文字化け、特殊文字の注入、さらにはプロンプトインジェクション攻撃といった異常な入力に対して、エージェントが適切にフェイルオーバー（優雅な低下）できるかが問われます。具体的には、システムがクラッシュしたり無意味な回答を返したりするのではなく、ユーザーにとって適切な誘導メッセージを返せるかどうかです。

「ユーザー満足度」は、オンライン上のフィードバック収集を通じてエージェントの回答品質に対する評価を集計したものです。これは評価プロセスの見落とし（盲点）を補正し、改善活動の方向性を示すために用いられます。

3.2 知覚モジュール：6 つの「理解できたか」指標

エージェントが最初に行うべきは、「ユーザーが何を言っているのかを理解する」ことです。知覚モジュールの評価は主に、意図認識能力とフェイルオーバー（低下）トリガー能力を中心に展開されます。

意図認識における 3 つの基本要素は、古典的な情報検索の評価パラダイムを踏襲しています。「精度（Accuracy）」は「認識された意図が正しいか」を、「再現率（Recall）」は「認識すべきものがすべて認識されているか」を、「適合率（Precision）」は「スキルとして認識されたリクエストが実際に処理可能かどうか」をそれぞれ衡量します。これら 3 つの視点を相互検証することで、意図認識能力をより包括的に反映させることができます。

「多意図認識率」は、複合的な問題が発生するシナリオを対象としています。ユーザーが一つの文に複数の意図を混在させた場合（例：「この商品が販売不可になった理由を調べてほしい。ついでにエラーコード F_IC_SERVICE_QUERY_020 の意味も分析してほしい」）、エージェントがすべての意図を完全に分解して抽出できるかが問われます。

「曖昧な意図の明確化率」は、ユーザーから曖昧な質問が来た際のエージェントの振る舞いが適切かどうかに関心があります。「この商品の状態を確認してほしい」といった、具体的な指示に欠ける問いに対して、合理的な対応とは、意図を明確にするために積極的に追问することか、あるいは妥当な推論に基づいて価値ある回答を提供することです。一方、的はずれな回答やハルシネーションを起こすことは不適切とみなされます。

「低下トリガー精度」は、ユーザーの質問がすべてのスキル（Skill）の処理範囲を超えた場合に、エージェントが適切に知識ベース検索によるバックアップ（デフォルト動作）を起動したかどうかを衡量するものです。単にマッチングしないスキルへ無理やりルーティングしようとしていないかがチェックされます。

3.3 計画モジュール：4 つの「正しく考えられたか」指標

意図を理解した後、エージェントは実行に関する意思決定を行う必要があります。計画モジュールの評価は主に、計画決定能力とその決定の妥当性を中心に展開されます。

「路由判断の精度」は、プランニング（計画）モジュールの中核をなす指標です。各ユーザーリクエストに対し、エージェントは「スキルを呼び出すか」「知識ベースを検索するか」という二つの選択肢から正しく判断する必要があります。誤ったルーティング判断が下されると、その後の実行プロセスが本来の軌道から外れてしまいます。

「ツール呼び出しの精度」は、ツール呼び出しを行うと決めた際に、エージェントが適切な種類のツールを選定できているかを問う指標です。例えば、「Trace（トレース）分析ツールを呼ぶべきか」「エラーコード照会ツールを呼ぶべきか」といった判断が正しいかどうかを確認します。

「知識ベース検索の精度」は、質問がどのスキルの範囲にも属さない場合に、エージェントが適切に知識ベースの検索トリガーを発動したかを評価するものです。

「プランニングパスの評価」では、人間による評価を通じて、エージェントが選択した実行パスが最適かどうかを判断します。このプロセスにはドメインの専門家が関与し、全体的な戦略の妥当性を検証する必要があります。

3.4 記憶モジュール：4 つの「記憶できたか」指標

エージェントは状態を持たない単なる関数呼び出しではありません。記憶能力が直接、多輪会話におけるユーザー体験を左右します。記憶モジュールの評価は主に、「記憶への注入能力」と「記憶注入の有効性」の二点に焦点を当てて行われます。

短期記憶保持率は、多輪会話における文脈の一貫性を評価する指標です。例えば、3 番目の発言でユーザーが「この商品」と言った際、エージェントが 1 番目の発言で言及された商品 ID を覚えていたかどうかを確認します。本稿では判断基準を設計する際、文字通りの一致ではなく「意味的な一貫性」を特に重視しました。つまり、エージェントは過去のエンティティ名を逐字に繰り返す必要はなく、文脈上の議論の主題や制約条件を意味的に引き継いでいればよいのです。

長期記憶検索の精度（Precision）は、RAG（Retrieval-Augmented Generation）によって返却された知識断片の質を衡量するものです。検索結果のうち、ユーザーの質問に本当に関連しているものはどれほどあるかという問いに対する答えです。本稿における「関連性」の定義は寛容なもので、質問に直接答える核心内容はもちろん、問題理解に必要な背景文脈（関連概念の定義やテーブル構造の説明など）もすべて「関連あり」と判定します。ただし、その業務領域と完全に無関係な断片のみが「非関連」とされます。

長期記憶検索の再現率（Recall）は、知識ベース内にあるべき知識ポイントのうち、エージェントの最終回答でどれだけカバーできているかを問う指標です。この評価には事前に「検索すべき知識ポイントのリスト」を注釈付けしておく必要があり、そのリストに含まれる知識がエージェントの回答に反映されているかどうかを確認します。

記憶減衰曲線は、エージェントの記憶における「賞味期限」を直感的に示すものです。多輪会話において異なるラウンド（2 番目、3 番目、5 番目など）に、過去の情報を参照する必要がある質問を挿入し、各ラウンドでの記憶保持率を統計的に分析します。

3.5 ツールモジュール：5 つの「正しく実行できたか」指標

ツール呼び出しは、エージェントが外部世界とやり取りを行うための窓口です。ツールモジュールの評価は主に、「ツールの読み込み能力」と「ツールの呼び出し能力」に焦点を当てて行われます。

MCP & Skills の読み込み成功率は、ツールモジュール評価における最低限の指標（ベースライン）です。エージェントの起動や実行プロセスにおいて、外部サービスが正しく初期化されシステムに接続できるかを確認するもので、ツール呼び出しが成立するための「前提条件」を衡量するものです。

ツール呼び出しの精度は、エージェントが適切なツールを呼び出せたかどうかをチェックします。過剰な呼び出しや重複呼び出しはないか、必要なツールの呼び出し漏れはないかを検証します。

ツール呼び出しの成功率は実行結果に焦点を当てます。ツール呼び出しが成功し、有効な結果を返却できたかどうかを確認します。

パラメータマッピングの精度は、エージェントがユーザーの意図を正しくツール呼び出しのパラメータに変換できているかを衡量するものです。例えば、「商品 1005007651467330 の韓国の在庫状況を確認して」というユーザーの指示に対し、エージェントがツールに渡す商品 ID パラメータが正確かどうかを問います。

3.6 コストとパフォーマンス指標

コスト指標には以下の 4 つが含まれます：平均モデル呼び出し回数、平均ツール呼び出し回数、平均入力トークン数、平均出力トークン数。これらの指標はすべて、エージェント実行時の埋め込みポイント（メトリクス収集点）を通じて自動的に収集され、リクエストごとに集計されます。

パフォーマンス指標は以下の 2 つの層をカバーします。

エンドツーエンド（E2E）レベルでは、主に「最初のトークンまでの遅延」と「エンドツーエンド応答遅延」に焦点を当てます。最初のトークンまでの遅延は、ユーザーの「待ちわびる不安感」を直接決定づけます。完全な回答が得られるまでさらに時間がかかる場合でも、最初に素早く表示される文字があれば、ユーザー体験は大きく向上します。

コアモジュールレベルでは、「意図認識の遅延」「プランニング判断の遅延」「短期記憶注入の遅延」「長期記憶検索の遅延」「ツール呼び出しの遅延」「ホットリロード（即時更新）の適用までの遅延」に焦点を当てます。これらのモジュールごとの遅延データは、エージェントのパフォーマンスボトルネックを精密に特定するために役立ちます。

04 評価用データセット：実業務シナリオのカバー

#### 4.1 データセット概観

本稿では、実際の業務シナリオを基に8種類の評価セットを構築し、「基礎カバー＋専門的探査」の階層構造を形成しました。基礎スキルと知識応答の評価セットは、AI エージェントの中核的な能力が閉じたループを形成しているかを検証するものであり、評価体系全体の基盤となります。一方、多輪対話、異常入力、ツール呼び出し、複数意図、曖昧な意図、長文対話における性能低下といった専門的な評価セットは、それぞれ異なる側面からアプローチし、知覚・計画・記憶・ツールなどの各モジュールが抱える具体的な弱点を特定する役割を果たします。

• 評価セットの種類：構築方法 / カバーされる評価指標 / 推奨規模
• 基礎スキル評価セット：Skill（スキル）の次元に沿って構成。一部のリアルタイム分析シナリオでは、外部依存を分離するために Mock ツールの返却値を利用します / タスク完了率、指示従順性、意図認識精度・再現率・適合率、ルーティング判断精度、計画パス評価スコア / 50 件以上
• 知識応答評価セット：知識ベースから Q&A ペアを抽出。明確な回答が存在するケース、回答がない場合のフォールバック処理、部分的な一致などのシナリオを網羅します / タスク完了率、ハルシネーション（幻覚）発生率（忠実性）、意図認識精度・再現率・適合率、フォールバックトリガー精度、ルーティング判断精度、計画パス評価スコア、知識ベース検索判断精度、長期記憶検索精度・再現率 / 100 件以上
• 多輪対話評価セット：2〜5 回の対話ラウンドからなる対話チェーンを構成。文脈参照、話題の切り替え、指代解消などのシナリオをカバーします / 多輪対話完了率、短期記憶保持率 / 10 グループ以上
• 異常入力評価セット：空の入力、超長テキスト、文字化け、特殊文字による質問などを含みます / 異常入力処理率 / 20 件以上
• ツール呼び出し評価セット：ツールの次元に沿って構成。正しいパラメータ、欠落したパラメータ、誤ったパラメータなどのシナリオを網羅します / ツール呼び出し判断精度、ツール呼び出し実行精度、ツール呼び出し成功率、パラメータマッピング精度 / 20 件以上
• 複数意図評価セット：2〜3 の意図を含む複合的なシナリオの問題を構成します / 複数意図認識率 / 20 件以上
• 曖昧な意図評価セット：意味が不明確、重要なパラメータが欠落している、または指示が不鮮明な問題を構成します / 曖昧な意図の明確化率 / 20 件以上
• 長文対話性能低下評価セット：5 ラウンド以上の長文対話チェーンを構成し、重要なラウンドに過去の情報を参照する必要がある質問を挿入します / 記憶の減衰カーブ / 10 グループ以上

4.2 評価用例の構築規範

優れた評価用例とは、「入力＋期待される出力」だけではありません。本稿では各用例に対して豊富な注釈フィールドを設計し、単一のデータが複数の Judge Task（判定タスク）で同時に活用できるようにしました。これにより、データの利用率が大幅に向上しています。以下では、基礎スキル評価セット、知識応答評価セット、多輪対話評価セットの構築規範と注意点を主に解説します。

基礎スキル評価セットは Skill の次元に沿って構成されており、各用例には評価チェーンに必要な情報が完全に注釈されています。これにより、異なる Judge Task は必要な情報だけを抽出して利用することが可能になります。

AI エージェントの精密な評価：評価体系設計とエンジニアリング実践

以下は、評価データ構造の一例です。

{
  "id": "BF-TRACE-001",
  "sceneCode": "i18n-ic-trace-analyzer",          // シーンコード。グループ統計に使用されます
  "sceneName": "Trace 調査",                      // シーン名。可読性を示す識別子です
  "userInput": "traceId：2116440e17706430209582423d0733",
  "expectedSkill": "i18n-ic-trace-analyzer",    // 期待される Skill（意図の精度率を評価）
  "expectedRoute": "SKILL_HIT",                 // 期待されるルーティング方向（ルーティング決定の精度率を評価）
  "expectedIntent": "i18n-ic-trace-analyzer",   // 期待される意図タイプ（意図の再現率・精度率を評価）
  "bizCode": "IC_PRODUCT",                      // ビジネスコード。Agent の入力パラメータ構築に使用
  "datasetType": "BASIC_FUNCTION",              // データセットタイプ。Judge ルーティングの根拠
  "evalMode": "E2E_MOCK",                       // 評価モード：E2E_MOCK / E2E_REAL
  "mockDataId": "MOCK-TRACE-001",               // 関連する Mock データ ID（存在しない場合は NULL）
  "referenceOutput": "Agent は trace 分析ツールを呼び出す必要があります..." // 参照出力。モデル評価の根拠となります
}

ここで、evalMode フィールドは評価の実行戦略を区別するために使用されます。

E2E_MOCK（Mock モード）：

mockDataId を介して事前に用意された Mock データを関連付けます。Agent の実行時には、この Mock データが注入され、実際のツール呼び出しに代わります。これにより、評価結果の再現性が確保され、商品の状態変動の影響を受けなくなります。Trace 調査や販売可能分析、タグ分析など、外部ツールのリアルタイムな応答を必要とするシナリオに適しています。

E2E_REAL（実環境モード）：

Mock データは注入せず、Agent が直接実際のサービスへ呼び出しを行います。これは、リアルタイム分析に依存しない Skill 類の評価（エラーコードの照会など）や知識質問応答の評価に適しています。このようなケースでは、あえて Mock を使用すると評価の意味が失われます。

E2E_MOCK モードではツールからの返却値が確定しているため、referenceOutput は具体的なデータ内容ではなく、Agent が取るべき行動と出力構造を記述するだけで十分です。これにより、評価基準を Mock シナリオに整合させることができます。

具体的内容ではなく行為のみを記述する理由は、基本スキル評価セットの目的が、回答の具体的な表現そのものではなく、エージェントの「エンドツーエンドの動作フロー（意図認識 → Skill ルーティング → ツール呼び出し → 結果生成）」が正しく機能しているかを検証することにあるからです。Mock データによってツールからの返却値は確定しており、Agent が正しい動作フローを完了すれば、その確定した入力に基づいて合理的な出力を生成できます。

具体的な出力の質（ハルシネーション率や検索精度・再現率）については、知識質問応答用の評価セットで別途検証します。

Mock データはツールごとに整理されており、各記録にはツールの返却結果が事前に設定されています。評価実行時にツール呼び出しの段階に達すると、インターセプターが現在のツール名に基づいて Mock データから該当する返却値を検索し、実際の遠隔呼び出しを代替します。Agent は実際の呼び出しと全く同じ形式の結果を受け取るため、これに基づいて推論を続け回答を生成できます。これにより、外部環境に一切依存することなく、意図認識から最終的な回答に至るまでの Agent の完全な能力を検証することが可能になります。

Trace 調査のシナリオを例にとると：

AI エージェントの応用における精緻な評価：評価体系の設計とエンジニアリング実践

知識回答評価セットは、エージェントがナレッジベースに基づいて専門分野の質問に答える能力を評価するために使用されます。ここでは特に、検索の質と回答の事実上の正確性を検証することが重点となります。評価セットはすべて E2E_REAL モードで構成されており、Mock データは注入されません。知識回答の核心は RAG（Retrieval-Augmented Generation）チェーン、つまり「検索→生成」の実際の効果を検証することにあるため、Mock を使用すると検索プロセスを迂回してしまい、評価の意味が失われてしまうからです。

{

"id": "KQA-BASE-001",

"sceneCode": "default", // シーンコード。知識回答では統一して default とする

"sceneName": "基本情報", // シーン名。可読性を高めるための識別子

"userInput": "商品と SKU の違いは何ですか？具体例を挙げて説明してください。",

"referenceOutput": "商品（Product/Item）とは、プラットフォーム上で販売可能な実体またはサービスのことです...",

"expectedSkill": null, // 期待されるスキルはなし

"expectedRoute": "SKILL_MISS", // 期待されるルーティング先：ナレッジベースへ。ルーティング決定の精度検証用

"expectedIntent": "knowledge_qa", // 期待される意図タイプ。意図認識の精度検証用

"expectedKnowledge": [ // 期待される検索結果。長期記憶検索の適合率・再現率検証用

"商品（Product/Item）とは、プラットフォーム上で販売可能な実体またはサービスのことです。商品 ID は商品の一意な識別子です",

"SKU（Stock Keeping Unit：在庫管理単位）は商品の最小販売単位のことで、skuId で表されます"

],

"bizCode": "IC_PRODUCT", // ビジネスコード。エージェントへの入力パラメータ構築用

"datasetType": "KNOWLEDGE_QA", // データセットタイプ。Judge のルーティング判断基準

"evalMode": "E2E_REAL" // 直接、実際のナレッジベースを呼び出すモード

}

また、知識回答評価セットには、エージェントの境界能力を検証するためのネガティブサンプル（負例）も含まれています。これは、本来回答すべきではない質問や、回答が不可能な状況において、エージェントがそれを正しく認識し、誤った推論（ハルシネーション）を回避できるかどうかを確認するためです。

例えば、以下のユースケースでは、deleteAllProducts というインターフェース名は IC の命名規則に完全に合致しているように見えます。そのため、エージェントは既存の saveProduct や queryProduct などの知識に基づいて、「一見合理的だが実際には存在しない」回答を推論してしまうリスクがあります。まさにこれが、ハルシネーション率（忠実性）の検出で捉えるべき問題です。

AI エージェントのアプリケーションにおける精密な評価：評価体系の設計とエンジニアリング実践

多輪対話評価セットは、エージェントが連続する複数回のやり取りにおいて文脈を記憶できる能力——すなわち、会話の状態を正しく維持し、前回の情報を覚えており、異なるシナリオへ切り替わる際にも記憶の一貫性を保てるか——を測定するものです。

この評価セットに特有の構造として、順序付けられた対話ラウンド数からなる配列（conversationChain）があります。評価実行器は、同一のセッション文脈を維持しながらエージェントに対して各ラウンドの userInput を順次送信し、実際の多輪対話をシミュレートします。各ラウンドにおける expectedContains には、その回答に含まれるべきキーワードが注記されており、Judge がエージェントが正しい文脈情報を保持しているかどうかを逐次検証する際の基準となります。

{
  "id": "KQA-NEG-004",
  "sceneCode": "default",
  "sceneName": "負例 - 概念の捏造",
  "keywords": "存在しないインターフェース，捏造",
  "userInput": "IC の deleteAllProducts インターフェースの呼び出し方と、必要なパラメータを教えてください。",
  "referenceOutput": "IC には deleteAllProducts というインターフェースは存在しません。該当するインターフェースに関する情報は見つかりませんでしたと明確に伝えるべきです。",
  "expectedSkill": null,
  "expectedRoute": "SKILL_MISS",
  "bizCode": "IC_PRODUCT",
  "datasetType": "KNOWLEDGE_QA",
  "expectedIntent": "knowledge_qa",
  "evalMode": "E2E_REAL",
  "expectedKnowledge": []
}

4.3 LLM を活用した評価セットの自動生成

数百件のテストケースを手作業で記述するのは非効率であり、カバレッジも不足しがちです。そこで本稿では、知識ドキュメントから評価用テストケースを自動的に生成する仕組みを実装しました。

Aone ドキュメント知識ツールセットの機能を活用し、語雀（Yuque）ドキュメントの URL と対象となるデータセットタイプを入力すると、システムはデータセットタイプ固有のプロンプトテンプレートと実際のドキュメント内容を基に、注釈仕様に準拠した構造化テストケースを自動生成します。例えば、データセットタイプとして KNOWLEDGE_QA（知識问答）を指定すれば、生成器は「expectedKnowledge（検索すべき知識ポイント）」を含むテストケースを自動的に出力します。

ただし、LLM が生成したケースの品質にはばらつきがあるため、正式利用前に人手による審査が必要です。「LLM による生成→人間による審査→登録」という半自動化ワークフローを採用することで、品質を担保しつつ、評価セット構築の効率を数倍に引き上げることができました。

05

Judge Task の設計：大モデルを信頼できる「審判」にする

数百のテストケースと複数の評価指標を扱う大規模な評価において、人手による検証は持続可能ではありません。従来のルールマッチング（キーワードや正規表現）では、意味的に等価なケースを処理できません。

例えば、「商品が削除されたことに対応するイベント識別子」と「product-downshelf メッセージタイプ」は、意味上完全に同じですが、単純なキーワードマッチングでは不一致と判定されてしまいます。

評価の持続性と一貫性を高めるため、LLM-as-Judge を中核的な自動化評価手法として採用しました。その最大の強みは、意味レベルでの判断が可能であり、「異なる表現で同一の意味を伝える」という等価関係を理解できる点にあります。

しかし、LLM を信頼性の高い「審判」として機能させるには、指標の種類に応じた特定の評価タスク（Judge Task）とプロンプト（Judge Prompt）を設計し、各指標に対応する計算可能な結果を出力させる必要があります。

5.1 Judge Task の階層設計

本稿では、評価セットに基づく指標の評価タスクを以下の 6 つのタイプに分類しました。それぞれの判断基準と定量化手法は次の通りです。

【画像挿入予定】

5.2 Judge Prompt の設計原則

質の高い Judge Prompt は評価精度の基盤となります。実務経験に基づき、本稿では以下の 4 つの設計原則をまとめました。

第一に「単一責任」です。一つのプロンプトは必ず一つの指標のみを対象とします。

以前、一つのプロンプトでタスク完了率と忠実性の両方を同時に判断しようとしたことがありますが、その結果、どちらの指標の精度も低下しました。理由は単純で、複数のタスクを混合すると LLM の理解負荷が増大し、判断品質が下がってしまうからです。

第二に「推論後に判断する」アプローチです。各プロンプトでは、LLM に対してまず reasoning（思考連鎖による推論）を出力させ、その後に結論を下すよう指示します。

これにより判断の精度が高まるだけでなく、評価結果の説明可能性も確保されます。例えば、Judge が不合格と判定した場合でも、その根拠となる推論プロセスを確認できるためです。

第三に、ネガティブ例の提示です。各プロンプトには、典型的な「合格」および「不合格」の事例が含まれています。例えば、タスク完了率の評価では以下のような対比が示されます。「商品 XXX が販売できない理由を教えてください」というユーザーの問いに対し、エージェントが具体的な販売不可の理由を分析して回答した場合→合格；一方、商品の基本情報だけを答えて販売不可の理由の分析を行わなかった場合→不合格。ネガティブ例を提示することで、評価者（Judge）の判断基準を適切に調整できます。

第四に、構造化された出力です。すべての評価結果は、自動化解析や指標計算を容易にするため、厳格な JSON 形式で出力する必要があります。プロンプト末尾に明確な出力フォーマットテンプレートを示すことが、LLM が解析可能な形式で回答を得るための鍵となります。

5.3 どのようにして評価用例の合格・不合格を判定するか？

よくある手法として、すべての Judge Task の結果を AND 演算で結合し、「すべてが通過した場合のみ合格」とするケースがあります。一見すると厳格に見えますが、実際には不合理な場合もあります。

例えば知識问答（クエリ）のシナリオにおいて、エージェントが「商品が販売できない理由」について正確に回答し、内容も完全で結論も正しいにもかかわらず、返答のフォーマットが参照出力の段落構成と厳密に一致していないというだけで、指示遵守の判定が不合格となるケースです。もしフォーマットのわずかな違いのために、中身は正しい回答を否定してしまえば、評価結果の真実性は著しく損なわれます。

本稿では、各評価シナリオごとに主要指標（メインメトリクス）を設定し、この指標のみをもってケースの合格・不合格を判定します。他の指標は最終的な通過判定には影響せず、あくまで品質の次元として個別に測定され、具体的な能力の弱点特定に役立てます。

主要指標の選定は、事前に定義された評価範囲に基づき、「評価データセット」と「評価モード」の 2 つのカテゴリに分けて行われます。このうち、評価モードの評価優先度は評価データセットよりも高いものとします。

• 評価モード：主指標 / 選択理由
• エンドツーエンド評価：タスク完了率 / エンドツーエンドでは最終的なタスク達成の結果に焦点を当てる
• コアモジュール評価：タスク完了率 / モジュール間の連携後のタスク達成結果に焦点を当てる
• 知覚モジュール評価：インテント認識精度 / 知覚の核心的な役割はユーザーの意図を理解することにある
• プランニングモジュール評価：ルート決定精度

AI エージェントの精度ある評価：評価体系の設計とエンジニアリング実践

計画の中核的な役割は、進むべき道筋を決定することです。

記憶モジュールの評価

短期記憶の保持率

記憶の中核的な役割は、会話の内容を記憶し続けることです。

ツールモジュールの評価

ツールの呼び出し精度

ツールの本質的な役割は、必要なツールを正確に呼び出すことにあります。

評価用データセット

主要指標

選定理由

基礎スキル評価セット

タスク完了率

最終的にユーザーの質問に適切に回答できなければ、合格とはみなしません。

知識回答評価セット

タスク完了率

ユーザーの質問に正しく答えられなければ、それは不合格とみなされます。

多輪対話評価セット

多輪対話完了率

単発の応答ではなく、会話フロー全体を評価する必要があります。

異常入力評価セット

異常入力処理率

「タスク完了」が目的ではありません。重要なのは、状況を適切に処理できるかどうかです。

ツール呼び出し評価セット

ツール呼び出し精度

適切なツールを選択することが大前提であり、細かいニュアンスのズレは許容されます。

多意図評価セット

多意図認識率

ユーザーの意図を完全に把握できていなければ、その後の実行も欠落してしまいます。

曖昧な意図評価セット

曖昧な意図の明確化率

推測するよりも問い返すことが優先され、ハルシネーション（幻覚）は避けるべきです。行動が正しいかどうかを判断することが、単なる正誤判定よりも重要です。

長文対話における減衰評価セット

記憶減衰曲線

記憶能力に特化して評価を行います。基準となるのは、どれだけ情報を保持できているかです。

5.4 見落としがちだが重要なポイント：ルーティングエラー時は下流の指標評価をスキップする

知識回答タイプの評価用例として、「IC 商品の在庫切れ後、販売可能フィールドはどうなるのか？」という質問があるとします。この場合、期待されるルーティングは「SKILL_MISS」（知識ベース検索へ遷移）です。

しかし実際の実行では、エージェントが誤って特定の Skill にルーティングしてしまいました。つまり、ルーティング判断自体にエラーがあります。その結果、Skill が直接回答を生成し、RAG による検索は全く実行されません。

この状態で以下の指標評価を実行するとどうなるでしょうか？

・ハルシネーション率（忠実度）：エージェントの回答と知識ベースの原文を照合する必要があるが、原文が存在しないため比較できない。

・長期記憶検索精度：返されたチャンクの中で関連するものがいくつあるかを統計化する必要があるが、何も返されていないため計算不可能。

・長期記憶検索再現率：期待されるチャンクがカバーされているか確認する必要があるが、検索自体が行われていないため前提条件を満たさない。

もしそのまま評価を強行すれば、これら三つの指標はすべてルーティングエラーによって不合格と判定されてしまいます。しかし、これらの指標は本来、エージェントの回答生成能力や知識ベース検索能力を測るためのものです。それらの機能自体に欠陥があるわけではなく、単に実行される機会が失われただけです。

本稿で提案する解決策は以下の通りです。RAG データに依存する Judge Task を実行する前に、まずルーティングの誤作動（期待値は SKILL_MISS だが実際には SKILL_HIT となったケース）がないか検知します。もしエラーを検出すれば、関連する下流の Judge Task は自動的に「error」としてマークされ、統計処理から除外されます。分子にも分母にも含めません。

最終的な通過率を算出する際も、このように「error」扱いされた結果は計算対象外とし、正常に実行された結果のみを集計します。

これにより、ルーティングのエラーは「ルーティング決定の精度」という指標にのみ反映されます。ハルシネーション率や検索精度、検索再現率は、あくまで知識ベース検索と回答生成モジュール自体の能力を正しく表すことになります。上流のルーティングエラーによってデータが汚染されることはありません。

各指標はそれぞれの役割を果たし、ある一つのモジュールでエラーが発生しても、それが雪崩式に他のモジュールの評価データを壊すことを防ぎます。

06

評価実行エンジン：用例からレポートへ

6.1 全体フロー

評価実行の完全なプロセスは以下の通りです。

・評価リクエストの送信：評価範囲を指定します。ここでは datasetType（評価対象データセット）と evalMode（評価モード）を指定します。

・データセットの自動アセンブリ：評価範囲に基づいて評価用例を読み込みます。各用例には、ユーザー入力、期待される出力、Mock データなどが含まれています。

・並列実行による評価用例の実行：単一の用例のタイムアウトは 120 秒とし、失敗時は最大 2 回自動リトライします。これにより、実行効率と結果の安定性の両方を確保します。

・単一用例の実行リンク（主要な 4 つのステップ）：

1. 入力構築：sessionId や Mock データを注入し、実際のユーザーセッション環境をシミュレートします。
2. エージェント完全ループの呼び出し：「知覚 → 計画 → 記憶 → ツール → 生成」の一連の流れを実行します。
3. EvalTrace の収集：知覚、計画、記憶、ツールモジュールに加え、RAG 検索やモデル消費などの多角的なデータを収集します。
4. Judge Task による構造化スコアリング：エージェントの出力と EvalTrace を Judge に渡し、指定された範囲に基づいて関連指標を評価します。

・評価レポートの生成：品質、コスト、性能の 3 つのカテゴリにわたる指標を出力します。各用例の通過可否は、そのデータセットタイプに対応する主要指標によって決定されます。これにより、評価結論が中核的な能力に焦点を当てられるようにしています。

6.2 データセットの自動構成

評価においてまず問われるのは、「特定の範囲を指定した場合、どのテスト用例を読み込むべきか」という点です。

本稿では、単一データセットから全モジュールにわたる広範な評価までを網羅する 15 の評価範囲を定義しました。各範囲には、対応するデータセットの組み合わせルールが設定されています。

• 指定データセット（8 種）: 特定のテストセットを直接読み込みます。例えば BASIC_FUNCTION を指定すれば、基礎スキルに関する評価セットのみがロードされます。
• エンドツーエンド評価（END_TO_END）: 基礎スキル、知識応答、多輪対話、異常入力といった複数の評価セットを組み合わせ、エージェントの全体像を把握します。
• モジュール別評価（4 種）: 例えば「感知モジュール」の評価では、基礎スキル、知識応答、多意図、曖昧な意図に関するデータセットを読み込みます。これら 4 つのカテゴリは、意図認識における境界条件を網羅しているためです。
• コアモジュール評価（CORE_MODULE）: 全 8 種類の評価セットを読み込み、感知・計画・記憶・ツールの 4 つの主要モジュールを包括的に評価します。

6.3 ランタイム指標の収集

評価における核心的な課題の一つは、「エージェントの実行プロセス中に中間指標を取得しつつ、ビジネスロジックに侵入しないようにどうするか」です。

本稿では、軽量な Trace データ構造を設計し、エージェントの処理フローに沿って情報を伝播させます。実行中、各ノードが自身のタスクを終えた時点で、重要な情報をこの Trace に記録します。

• 感知ノード: スキルヒットの有無、実際にヒットしたスキルの名称、実際の意図タイプ、意図認識にかかった時間
• 計画ノード: 計画決定にかかる時間
• 記憶ノード: 記憶の注入にかかる時間、会話履歴の輪数
• ツールノード: ツール呼び出し記録（ツール名、引数、成功/失敗、呼び出し時間）
• RAG ノード: 検索にかかる時間、検索結果の数、取得した生テキストブロック
• その他統計: モデル呼び出し回数、入力・出力のトークン消費量など

エージェントの実行が完了すると、この Trace と最終的な出力は Judge エンジへと渡されます。Judge は単にエージェントの回答テキストを参照するだけでなく、Trace に記録された中間データも活用します。例えば、「実際に特定のツールを呼び出したか」という判断は、回答文から推測する必要はなく、Trace 内のツール呼び出し記録を直接確認すれば済みます。

6.4 多輪対話評価における特別な処理

多輪対話は評価において最も複雑なシナリオであり、いくつかの特殊な課題に対処する必要があります。

• 会話コンテキストの共有: 各多輪対話グループには独立したセッション ID が生成され、全ラウンドで同じ ID を共有します。これにより、エージェントは完全な会話履歴を読み込むことができます。
• ラウンド間の同期: 各ラウンドの実行完了後、会話の永続化が完了するまで（通常 2 秒）待機し、次のラウンドを開始します。これを怠ると、次ラウンドで前回の履歴が読み込めず、「エージェントに記憶能力がない」と誤判定される恐れがあります。実際には単にデータを読み取れなかっただけです。
• 指標の累積: 多輪対話におけるモデル呼び出し回数やトークン消費量などのコスト指標は、ラウンドごとに累積して計算し、一連の対話全体の総コストを反映させます。
• 総合評価: すべてのラウンドの出力をつなぎ合わせてから Judge に評価を依頼します。個別にラウンドごとの評価を行うのではなく、多輪対話の質は全体として判断されるべきだからです。例えば、最初の回答が正しくても、3 番目の回答で記憶喪失を起こした場合は、その一連の対話は失敗と判定されます。

6.5 2 つの評価モード

本稿では、「真実性」と「再現性」という評価における相反する要件を解決するため、2 つの補完的な評価モードを設計しました。

6.5 評価モード：E2E_REAL と E2E_MOCK

エンドツーエンド実環境モード（E2E_REAL）では、エージェントが実際のオンラインリンクを完走します。LLM の呼び出し、ツールの実行、そして知識ベースの検索すべてがリアルタイムで行われます。このモードは、本番環境におけるエージェントの振る舞いを最も忠実に反映しますが、外部依存の影響を受けやすいという欠点があります。

具体的には、ツールインターフェースの一時的なタイムアウトや、評価直前の知識ベース更新、そして LLM の出力に含まれるランダム性などが要因となり、同じテストケースでも2回実行すると結果が異なる可能性があります。

一方、エンドツーエンドモックモード（E2E_MOCK）では、ツールの呼び出しに対する返却値を事前に設定したデータに注入します。エージェントの推論や意思決定プロセスは依然としてリアルですが、ツールからのレスポンスは固定されたモックデータになります。これにより外部依存の不確実性が排除され、評価結果の再現性を保証できます。

両者にはそれぞれ適した用途があります。Mock モードは、トレーシング（Trace）によるトラブルシューティングや、販売可能性分析、タグ分析など、外部ツールのリアルタイムな応答を必要とするシナリオに適しています。一方、Real モードは、エラーコードの照会などのスキル系評価や、知識ベースへの質問回答など、リアルタイム性の依存度が低いテストに活用されます。

6.6 リトライとフォールトトレランス

評価プロセスでは、LLM API の偶発的なタイムアウトやサービスの一時停止など、さまざまな異常が発生します。これらに対応するためのリトライおよびフォールトトレランス戦略は以下の通りです。

• 実行時の異常（タイムアウト、ネットワークエラー等）: 最大2回までリトライし、間隔は3秒空けます。通常、この対策で処理を回復できます。
• 評価失敗（Judge による不合格判定）: リトライは行いません。これはエージェント自体の能力不足が原因であるため、再試行しても結果は変わらないからです。
• タイムアウト保護: 単一のテストケースには120秒の制限を設け、異常なケースが評測全体をブロックするのを防ぎます。

6.7 並列実行と非同期管理

バッチ評価では3スレッドでの並列実行を採用しています。この並行度は、評価効率と LLM API のレートリミット（制限）のバランスから導き出された最適解です。並行度を上げすぎると API 制限に引っかかり逆に処理が遅くなり、低すぎると一連の評価に時間がかかりすぎてしまいます。

評価タスクは「非同期提出 - ポーリング」モードで運用されます。

1. クライアントが評価リクエストを送信すると、即座にタスク ID（taskId）が発行されます。
2. 実際の評価処理はバックグラウンドで非同期実行され、クライアント側はポーリングインターフェースを通じて進行状況を随時確認できます。
3. 実行中のタスクであれば、いつでもキャンセルが可能です。

7. 評価の可視化：エージェント指標ダッシュボード

本稿では、軽量な評価ダッシュボードを構築しました。評価範囲を選択するだけで、対応する評価データセットが自動的に構成され、関連するメトリクス（埋点指標）も同時に取得されます。

評価範囲を変更すれば、データセットとメトリクスは即座に連動して更新されるため、手作業で各データソースを個別に連携させる必要はありません。「評価範囲の選択 → データセットの自動構成 → 該当指標の自動選別」というフローにより、評価プロセスをシンプルかつ柔軟に運用できます。

7.1 評価フロー