AIエージェント評価を、仕事の直し方につなげる

同じ「変更しました」でも、仕事の正しさは違う

「予約を金曜日に変更しました」と返す二つのAIを比べる。 どちらも本人確認済みの利用者の予約R42を変更し、同じ日時と料金を保存した。 このサービスでは、日時と料金を提示して承認を得てから保存する、と決めている。

一つ目の実行は、空き枠を調べ、変更内容を示し、承認を受けてから保存した。 二つ目は、保存した後で承認を求めた。 これは評価方法を説明する想定例であり、特定製品の測定ではない。 回答文と保存結果が同じでも、二つ目の実行はサービスの条件を破っている。

2026年7月11日までのOpenAI、Google、AWS、Anthropicの資料は、回答に加えて実行記録や道具の使い方を評価する方法を示す。 私の判断は、記録を業務の期待と照合し、破った条件ごとに修正先を決める、というものだ。 「答えがよくなった」を「仕事がよくなった」と判断するには、実際の操作まで説明できる証拠が要る。

何を頼まれ、何を行い、何が残ったかを分ける

予約の例を一つの総合点で採点すると、自然な回答が承認順序の違反を埋めることがある。 本稿では、次の三つを別々の確認事項として記す。 これは業界共通の分類ではなく、合否の理由を具体的にするための整理である。

料金が変わったため、再照会して再承認する経路も正しくなり得る。 一方、利用者が拒否した場合は、変更しないことが正しい結果になる。 必ず同じ操作をさせるのではなく、依頼と条件に応じた結果を定める必要がある。

OpenAIのトレースは、判定に使う出来事を集める

OpenAI Agents SDKは、生成、関数ツールの呼び出し、引き継ぎ、ガードレールなどをトレースとして記録する。 一連の処理を識別するIDと、開始時刻や終了時刻を持つ個々の操作を関連付け、独自の出来事を加える仕組みもある。

その記録だけで、「予約変更は正しい」と自動的に決まるわけではない。 この予約サービスで必要なのは、提示した内容、承認対象、保存要求、保存結果を対応付けることである。 業務側の承認や外部システムの保存まで、SDKの標準記録が必ずすべて捉えると仮定しない。

たとえば、予約IDが正しくても、承認後に料金が変われば、以前の承認は新しい内容への承認にならない。 操作の名前と時刻に加えて、どの版の何を承認したかを調べる。 実行記録が役立つのは、順序だけでなく、判断した対象と実際の更新を追える場合である。

トレースには入力や出力が含まれ得るため、必要な証拠と保存する情報の範囲を合わせて設計する。 SDKには機密データの記録を制御する設定もある。 本文をすべて残す代わりに、確認に必要な識別情報や審査した再現データを用意できるかを考える。

Googleの三つの照合方式は、許す経路を変える

Google ADKの評価基準は、期待する道具の呼び出しと実際の呼び出しを比べる。 完全一致、順序を保って必要な呼び出しが現れる一致、順序を問わない一致を選べる。 完全一致が既定であり、回答の類似度やモデルによる品質判定は別の指標になる。

照合の実装では、道具の名前に加えて引数も比較する。 予約R42への保存を期待したのにR43へ保存する誤りは、名前が同じでも一致しない。 これは道具名だけの検査から一歩進むが、期待する引数を正しく用意できることが前提になる。

完全一致なら、料金変更を受けて必要になった再照会まで不一致にすることがある。 順序を保つ方式なら、その追加操作を許しながら必要な呼び出しを確認できる。 ただし、許した追加操作の中に別の予約への保存が混ざっても、必要な部分が一致する可能性は残る。

したがって、「承認が保存より前にある」と「承認されていない保存が一度もない」は別の検査になる。 独立した読み取りの順番を固定する必要はない場合があるが、書き込みの禁止条件は別に調べる。 照合を緩くするなら、何を許し、何を追加で検査するかを一緒に変える。

AWSでは、期待する答えと一連の行動を別に渡す

AWS AgentCore SDKの評価クライアントには、期待する回答、道具名の列、行動について満たすべき記述を渡す仕組みがある。 回答は特定の実行単位に、一連の道具や条件は会話全体に対応付けられる。 CloudWatchから実行記録を集め、指定した評価器へ渡す構成だ。

ここで渡す道具の列は名前の一覧であり、予約IDや金額を含む構造化された引数の一覧ではない。 Google ADKの引数比較と、同じ内容を検査するとまとめない。 予約の例では、名前の並びとは別に、承認対象と保存内容、実際の予約データを照合する必要がある。

一般提供発表は、事前に指定した実行を調べる評価と、本番の記録をサンプリングする評価を説明する。 評価対象を会話全体にするか、一回の応答や道具の呼び出しにするかによって、見える違反も変わる。 採点する機能の存在から、全操作が実行前に認可されるとは結論できない。

採点器が合格を出した理由も確かめる

道具の順序や明確なIDの一致は、規則で判定しやすい。 一方、利用者に料金変更を分かりやすく伝えたかなどは、人やモデルによる判定が役立つ。 どちらを使うかは、判定対象と許容する言い換えによる。

Anthropicの評価の解説は、実行記録、採点器、最終結果を分け、採点器自体の誤りにも注意を向ける。 たとえば正しい別表現を不合格にしたり、もっともらしい成功報告を合格にしたりすれば、評価を上げる変更が仕事を改善するとは限らない。

予約の想定例では、正しいIDに承認済みの値を保存した記録と、承認前に保存した紛らわしい記録を用意する。 担当者が期待する判定と採点器の判定を比べ、違いの理由を調べる。 規則や採点モデルを変えた場合も、同じ記録で判定が変わっていないか確認する。 これは提案する検査であり、特定の採点器の精度を測定した結果ではない。

保存結果と、繰り返して成功する確かさを測る

τ-benchの初版は、会話終了後のデータベースを目標の状態と比較する。 さらに、複数試行のどれかで成功することと、複数試行で続けて成功することを区別する。 流暢な回答や一度の成功だけでは、同じ依頼を任せ続けられるかを判断しにくい。

最終データを照合する評価も、承認順序の検査を置き換えない。 冒頭の二つの実行は、同じデータを残していても順序の条件では違う。 反対に、正しい順序で呼び出していても、道具側が失敗すれば保存は終わっていない。 実行の適切さと結果を両方見る必要がある。

同じ初期データを戻して複数回実行し、正しい変更、適切な拒否や停止、誤操作、証拠不足を分ける。 成功した実行だけを採点対象にすると、難しい状況で止まった割合が見えなくなる。 保存応答が途切れたケースでは、保存済みかを調べる前に再送していないかも確認する。

変更前後で、どの条件がよくなったかを比べる

評価セットには、通常の予約変更に加え、利用者の拒否、料金の変更、権限不足、似た予約ID、保存応答の切断を含める。 モデル、指示、道具、採点規則の版を記録し、変更前後を同じ初期データと操作予算で比べる。 すべてを同時に変えると、どこが結果を変えたか説明しにくい。

合否の内訳から、修正する場所を選ぶ。 対象の選び違いなら照会や識別の方法、承認後の変更なら承認内容と保存の結び付け、未保存なのに完了と返すなら結果の確認を調べる。 すべての失敗を、モデルを大きくする問題にまとめない。

回答の品質、経路の違反、保存結果、証拠不足、遅延、費用を別に示す。 簡潔な回答が高得点でも、別の予約を変更した違反と相殺しない。 担当者が記録を読む時間や、利用者へ確認を求める回数も測れば、成功率を保ったまま負担が増えていないかを判断できる。

本番の観測を、次に再現できるケースへ戻す

本番記録は、固定した評価セットにない失敗を見つける手段になる。 ただし、サンプルで見なかった違反が全体にもないとは限らない。 記録の欠損や取得範囲も含め、どの操作を観測できたかを示す。

新しい失敗を見つけたら、必要な情報を審査して匿名化し、初期状態、依頼、期待する操作、禁止条件、結果を持つ再現ケースにする。 次の修正で直ったかを確かめ、以後の変更でも同じ失敗が戻らないかを調べる。 評価セットに合格しても、まだ収集していない状況まで安全だと保証することはできない。

トレースを増やすだけなら、担当者が読む量も増える。 修正の判断に使うには、失敗した条件と、その根拠へ到達できる必要がある。 記録を全部見せるより、どの予約、承認、保存の対応が崩れたかを示せる方が調査しやすい。

評価を、仕事を直すための判断材料にする

四社の資料が支えるのは、実行を記録し、期待する行動と照合するための異なる方法である。 同じ条件で測った製品順位や、共通の完全な監査機能を示すものではない。 必要な記録と判定を、対象の予約サービスの条件から選ぶ。

初めに、担当者が重要だと判断する成功条件と禁止条件を少数のケースで明示する。 回答、実行、保存結果が食い違うケースを含め、判定の理由を調べられるようにする。 既存の手順や規則で判定できる部分には、それを使う。

評価のゴールは、得点の上昇を眺めることにとどまらない。 何がよくなり、どの条件で悪くなったかを説明し、次に直す場所を選べることである。 予約変更の「完了」を、利用者と担当者が確かめられる仕事へつなげたい。