AIエージェント評価：実行記録で誤操作を見つける

同じ回答を返す二つの予約変更

「予約を金曜日に変更しました」という回答だけでは、AIエージェントの操作が正しかったかは分からない。変更前に必要な確認をしたか、別の人の予約を触っていないか、書き込みが実際に成功したかは、回答とは別の記録で調べる必要がある。

次は評価方法を説明する想定例であり、製品の実測ではない。本人確認済みの利用者が予約R42の変更を依頼し、このサービスでは新しい日時と料金への承認を保存前に求めるとする。二つの実行は同じ予約を同じ日時に変更し、同じ最終回答を返した。

回答と保存結果が正しくても、Bはサービスが定めた承認順序に違反する。この違いを検出するには、「よい回答」の採点に加えて、承認と保存の前後関係を判定しなければならない。

OpenAI Agents SDKのトレースは、生成、道具の呼び出し、引き継ぎ、ガードレールなどの実行イベントを記録する。その記録を使って何を不合格にするかは、別に定める必要がある。トレースの仕様

予約の例なら、実行ID、予約ID、照会結果、提示した変更内容、承認対象、保存要求、保存結果を対応付ける。承認された内容と保存した内容が一致し、保存より前に承認がある場合に、その条件を合格とする。承認イベントが見つからなければ、承認済みと推測せず、証拠不足として調査する。

最終状態の確認にも独立した役割がある。 τ-benchは、会話終了後のデータベースを目標の状態と比較してタスクの成否を評価する研究である。τ-bench 予約変更でも、回答文に成功と書かれているかだけでなく、対象予約が意図した状態になり、別の予約に変更がないかを評価用データで照合できる。

ただし、ログが欠けていると、記録に禁止操作がないことは、禁止操作をしなかった証明にならない。道具の実行を記録する箇所と、業務システム側の変更履歴を対応付け、機密情報を必要以上に保存しない方法も決める。

実行Aが合格だからといって、Aと完全に同じ道具の列だけを正解にすると、必要な再照会まで誤りとして数えることがある。たとえば料金が変わったため再提示して承認を取り直す経路も、サービスの条件を満たし得る。

AWS AgentCoreの評価資料は、期待する道具の列との完全一致、順序を保った一致、順序を問わない一致を区別している。期待結果を使う評価どれを使うかは業務条件による。承認前の保存を検出したいなら順序が必要だが、独立した二つの読み取りの順番まで固定する必要はない場合がある。

また、道具名の列だけでは、別の予約IDを書き込む誤りは判定できない。前後関係の検査と、入力値や保存結果の検査を組み合わせる。文章の有用性をモデルで採点する場合も、このような明示的に判定できる違反を総合点で相殺しない。

評価セットには通常の変更だけでなく、利用者が拒否する場合、料金が変わる場合、権限がない場合、保存の応答が途切れる場合を入れる。応答が途切れた例では、保存済みか不明なまま再送していないかを見る。同じ初期データと条件で変更前後を試せば、回答が改善した一方で操作が悪化したケースを分けて確認できる。

評価結果には、回答の合否、保存結果、禁止操作、証拠不足を別々に残す。遅延や費用はさらに別の指標として測る。実行を複数回試し、一度だけ成功した経路に依存していないかも確認する。 τ-benchも、複数試行での信頼性を一回の成功とは区別して評価している。

本番で新しい失敗が見つかったら、必要なデータを匿名化した再現ケースを評価セットへ加える。ただし、評価セットに合格したことは、未収集の状況でも安全だという保証にはならない。実行記録を評価へつなぐ意味は、特定の変更がどの業務条件を破ったかを説明できるようにすることにある。