AIエージェントの評価では、回答が読みやすいかだけでなく、必要な操作が正しく行われたかを確かめます。「登録しました」と答えていても、登録先や内容が違ったり、同じものを二重に作ったりしていれば、業務上は成功ではありません。
最終回答、操作の過程、操作後の状態を分けて見ると、何が改善されたかを判断しやすくなります。
最終回答と実行軌跡を分ける
GoogleのAgent Development Kit（ADK）は、評価対象をツール利用を含む実行軌跡と最終回答に分けています。実行軌跡は、どのような手順やツール操作で回答へ到達したかを表すものです。Google ADK: Why evaluate agents
例えば問い合わせ登録なら、必要情報の確認、登録先の選択、登録操作、結果の確認、利用者への回答を追います。自然な文章だけを採点すると、途中の誤操作や余分な操作を見落とすおそれがあります。
先に成功条件と禁止操作を書く
以下は、架空の社内問い合わせ登録エージェントに対する評価設計です。実在する業務の実績や、共通の合格基準ではありません。
| 観点 | 条件の例 | 確認する証拠 |
|---|---|---|
| 完了 | 指定された窓口に1件登録されている | テスト環境の登録結果 |
| 内容 | 利用者が述べた事実が保たれている | 入力と登録内容の比較 |
| 不足情報 | 必須項目がなければ確認を求める | 会話とツール呼出しの記録 |
| 禁止操作 | 指示のない削除・外部送信を行わない | 全ツール呼出しと対象 |
| 報告 | 実際の結果に合う完了・未完了を伝える | 操作後の状態と最終回答 |
「業務を完了できたか」と「してはいけない操作をしなかったか」は別に数えます。平均点が高くても、禁止操作を起こしたケースを相殺して合格にしない設計が考えられます。許容範囲は、その業務の責任者が決めます。
正常な依頼以外をテストへ入れる
最初の評価セットには、通常の依頼だけでなく、入力が足りない場合、複数の窓口に解釈できる場合、既に登録済みの場合、ツールがタイムアウトする場合を入れます。
タイムアウトのケースでは、処理されなかった場合と、処理されたが応答だけ届かなかった場合を分けます。後者で新しい登録を作ってしまわないか、既存状態を確認するかを観測します。検証環境を使い、外部送信などの実際の副作用を評価のために起こさないようにします。
各ケースに、初期状態、入力、許可する操作、期待する最終状態を保存します。初期状態が毎回違うと、エージェントの変更による差かどうかを判断しにくくなります。
操作順序が違うだけで失敗にしない
ADKには、期待した操作と照合する方法や、評価基準に沿ってツール利用を判断する方法があります。Google ADK: Evaluation approach
業務によっては、二つの参照処理をどちらから行っても正しく完了できます。この場合、決めた一つの順番との完全一致だけを合否にすると、妥当な操作まで失敗に数えてしまいます。
一方、「承認を得る前に送信しない」のような前後関係は守る必要があります。順番が必須の箇所と、結果が同じなら許容する箇所を分けて書いてください。必要のないツール呼出しは、時間や費用の観点で別に評価できます。
変更前後を同じ条件で比べる
プロンプトやモデル、ツールの説明を変更したら、同じケースと初期状態で比較します。実行結果が変動することを考慮し、繰り返し試した結果も残します。試行回数は一律の数字で決めず、ばらつきと業務上の影響に応じて判断します。
集計では、完了件数だけでなく、誤登録、禁止操作、不足情報の確認漏れ、未完了を成功と報告した件数を分けます。失敗したケースの実行記録へ戻れる形にすれば、回答文の修正で済む問題と、ツールや状態管理の修正が必要な問題を切り分けられます。
任せる業務や権限の範囲は、AIエージェントの業務導入で整理しています。評価表は、その範囲が実際に守られたことを確かめるために使います。