powered by TechFeed
表示モード
Deep Dive

「返金しました」と言ったのにシステムは何もしていなかった — SalesforceがAIエージェントを「会話の品質」ではなく「実際の変化」で評価すべき理由を解説

8月18日、Salesforceが「How to Evaluate AI Agents: Measure Outcomes, Not Responses」と題した記事を公開した。この記事では、AIエージェントの評価はレスポンスの品質ではなくシステムへの実際の作用で測るべきだという設計原則について詳しく紹介されている。

8月18日、Salesforceが「How to Evaluate AI Agents: Measure Outcomes, Not Responses」と題した記事を公開した。この記事では、AIエージェントの評価はレスポンスの品質ではなくシステムへの実際の作用で測るべきだという設計原則について詳しく紹介されている。


「返金しました」と言ったが、実際には何もしていなかった

本記事が提示する問題は具体的だ。AIエージェントが顧客に「返金処理を完了しました」と返答する。会話ログは正常に見える。エラーも出ていない。しかし請求システムを確認すると、請求書はまだオープンのままで、返金ツールは一度も呼ばれていなかった——。

これがなぜ起きるのか。LLMベースのエージェントは、推論のたびにツールを呼ぶかどうかを動的に決定する。同一コード・同一プロンプトの2回の実行で、一方はツールを呼び出し、もう一方は「呼び出した」と文章で述べるだけ、という結果になりうる。これはバグではなく、LLM駆動エージェントの本質的な性質だ。

つまり、会話の出力とシステムへの作用は別物である。会話だけを評価していると、両者を区別できない。


正しい評価軸は「最終的なシステム状態」

Salesforceはこの問題に対処するベンチマーク「CRMAgentBench」を開発している。本記事執筆時点では内部ツールとして紹介されており、外部への一般公開については明示されていない。同ベンチマークでは、各タスクに共有のステートフルな環境を与え、エージェントのツール呼び出しがその環境を変化させていく。タスク終了後、期待されるシステム状態変化が実際に起きたかを検証する仕組みだ。

例えばCRMのワークフローなら、以下のような検証が行われる。

  • 正しい技術者でフィールドサービスの予約が登録されているか
  • クーポンが正しいアカウントに紐付いているか
  • 会話中に発見したIDが使われているか(モデルが推測したIDではなく)

重要なのは「正しい最終状態」は必要条件だが十分条件ではないという点だ。


「副作用」と「禁止操作」も検出する

別の失敗パターンも存在する。正しい結果に到達したが、途中で意図しない変更が生じたケースや、使用を禁じられたツールを呼び出していたケースだ。

CRMAgentBenchは厳格なオール・オア・ナッシング採点を採用している。タスクの成功は以下のすべてを満たした場合のみだ。

  • 正しいツールを正しい引数・順序で呼び出した
  • システムが意図した最終状態に到達した
  • 禁止された操作を行わなかった
  • 意図しないレコードを変更しなかった

ハードタスクでは、キャンペーンIDをあえて与えず、エージェントが自力で発見してから処理する順序を検証するケースや、処理前に確認質問を要求するケース(実行だけでなく「自制」のテスト)も含まれる。


1回成功するのと、毎回成功するのは別問題

本記事で特に実践的な指摘が、pass^k(パス・カレット・k)という指標の導入だ。キャレット記号(^)は数学的な冪乗を意味し、「すべてのk回で成功する確率」を表す。

同一タスクをk回繰り返し、すべてのk回で成功する確率を推定する。例えば、10回中9回成功するエージェントであれば、pass^10は0.9の10乗=約0.35、つまり約3分の1まで落ちる計算になる。1回の失敗が全体の成功判定を崩すため、安定性のわずかな差が本番での信頼性に大きく影響する。

これはpass@k(k回中1回でも成功すれば良い)とは対照的な指標で、安定して成功できるかを測る。ユーザーが経験するのは平均値ではなく、その1回のインタラクションだ。全体的な成功率が高くても、ばらつきが大きければ本番運用で問題が生じる。


ベンチマーク自体が劣化する問題

CRMAgentBenchが直面したもう一つの課題も興味深い。初期バージョンでは、フロンティアモデルがほぼ満点に近いスコアに集中してしまい、モデル間の差異を測れなくなった。

解決策はベンチマーク自体を難化させることだった。ただし、エージェントやタスクを宣言的に定義しているため、フレームワークを再構築せずにハードなシナリオを追加できる。結果として、最も優秀なモデルでも易しいタスクで96%だったスコアが、ハードタスクでは66%まで低下した。評価フレームワークが拡張可能でなければ、やがて最も重要な失敗を検出できなくなる。


自分たちのAIエージェント評価に取り込む5つの問い

記事は、どのドメインにも適用できる評価の基準として以下5つを提示している。

  1. エージェントは正しいアクションを実行したか?
  2. 正しい引数と順序を使ったか?
  3. システムが意図した最終状態に到達したか?
  4. 禁止された操作や副作用を避けたか?
  5. その成功を一貫して繰り返せるか?

「本番AIエージェントの最も重要なアウトプットは生成した文章ではなく、それが残した変化だ」——本記事の結論はシンプルだが、評価設計の出発点を根本から問い直すものだ。


詳細はHow to Evaluate AI Agents: Measure Outcomes, Not Responsesを参照していただきたい。