AIエージェントの評価　道具の成功と仕事の完了を分ける

検索は成功した。だが、答えは別の機器のものだった

社内の担当者が「この機器の保守期限を教えて」とAIへ尋ねる。 AIは文書検索を呼び、期限の書かれた資料を開き、出典付きで日付を返す。 ところが、資料は旧型機種のものだったとする。 検索の実行記録は成功でも、担当者が知りたかった期限は分かっていない。 これは評価を考えるための想定例である。

道具を呼べるようになると、回答の見た目だけでは分からない失敗が増える。 正しい機能を呼んだが引数を間違えた、正しい資料を取得したが条件を読み落とした、途中まで操作したが保存していない。 どれも一つの「エージェントが失敗した」という説明だけでは、直す場所を選べない。

2025年1月1日までの研究には、この違いを測るための部品がそろっていた。 ReActとToolformerは行動の選択と観測の利用を、WebArena、SWE-bench、OSWorldは環境の中で仕事を終える条件を扱う。 本稿の判断は、エージェントの比較単位を、できる操作の一覧から、入力、行動、完了の根拠を持つ仕事へ移したいというものだ。 これらの資料から市場全体の移行を断定するわけではない。

外部情報を取りに行く仕組みと、その使い方を分ける

ReActの第3版は、推論の記述と課題に応じた行動を交互に生成し、得た観測から次の行動を選ぶ。 質問応答では、Wikipediaを検索し、ページ内の情報を探し、回答を確定する。 冒頭の想定例へ当てはめれば、最初の資料に必要な条件がなければ、別の資料を探す判断を途中へ置ける。

ただし、外部検索を使うこと自体が全課題の改善を意味しない。 同じPaLM-540Bを使う論文の比較では、HotpotQAの完全一致率はReActが27.4%、推論過程を順に記す方式（CoT）が29.4%だった。 FEVERの事実確認の正解率は60.9%対56.3%で、順序が逆になる。 課題と尺度が異なるため、検索の有無だけで一つの優劣へまとめられない。

Toolformerの初版は、どのAPIをいつ呼び、どの引数を渡し、結果を後続の生成へ使うかを、少数の例から自己教師ありで学ぶ方法を提案した。 計算機、質問応答、検索、翻訳、カレンダーなどを対象とする。 ReActが推論と観測の往復を扱うのに対し、こちらは呼出しを学習へ取り込む問題を扱っている。

両者から、道具の選択、引数、戻り値の解釈を分けて見る視点が得られる。 検索が応答したかだけでは、型番が合っているか、期限の条件を回答へ反映したかは分からない。 途中の記録を読む理由は、自然な説明を眺めることより、どこで条件が失われたかを特定することにある。

Webの仕事は、クリックした回数ではなく最終状態で測る

WebArenaの第2版は、電子商取引、フォーラム、共同ソフトウェア開発、コンテンツ管理の動作するWeb環境を使い、長い操作列の機能的な完了を測る。 ページを開ける、入力できるという能力を、仕事全体の完了へ結び付けるための環境である。

この版で報告された最良のGPT-4ベースのエージェントの完了率は14.41%、人は78.24%だった。 これは当時のタスク、環境、エージェント構成についての数値であり、現在のモデルや自社サイトの成功率ではない。 むしろ、自然に指示を解釈して操作する姿と、定めた仕事を最後まで終える能力の間に、測定すべき差があることを示している。

たとえば社内の問い合わせを登録する想定例なら、フォームへ文字が入ったことと、正しい案件の記録が保存されたことは違う。 入力先を取り違えたまま送信できる場合、操作の成功だけを数えれば誤りを見逃す。 最終状態の判定を先に決めることで、必要な操作と、途中で読まなければならない情報も明確になる。

コードと画面操作では、完了を確かめる方法が違う

SWE-benchの初版は、12のPythonリポジトリから、実際のGitHub Issueと対応する修正に基づく2,294件の課題を集めた。 モデルにはコードベースと問題の説明が渡され、関連するファイルを修正する。 評価では、失敗していたテストが通ることと、既に通っていたテストが通り続けることを確認する。

この設計では、修正らしいコードを書くことと、問題を解き、既存の動作を保つことを区別できる。 一方、選ばれたテストに合格しても、未測定の品質や運用条件を全て満たすとは限らない。 テストを成果物の根拠として使いながら、その根拠がどの範囲を検査したかも残したい。

OSWorldの初版は、Webとデスクトップのアプリ、ファイル操作、複数アプリをまたぐ369件の課題を置き、初期状態と実行ベースの評価スクリプトを用意した。 環境はUbuntu、Windows、macOSに対応するが、対応することと、全てのOSで同じ性能が測れたことは別である。 コードのテストとは異なる、保存先やアプリ内の状態を確かめる対象がある。

想定する資料作成なら、画面に表が見えるだけでなく、指定したファイルへ必要な値が保存されたかを確認する。 逆に、見た目が想定と少し違っても、要求されたデータが正しく保存されていれば成功とする仕事もある。 人が望む結果に合わせて判定器を作る必要があり、全エージェントを同じ一つの点数で比較するのは難しい。

共通の実験環境でも、課題の意味はそろわない

BrowserGymの初版は、Webエージェントの複数のベンチマークを共通の観測と行動の形式へ置き、AgentLabとともに実験の管理や分析をそろえる。 実行する基盤が違うせいで、比較条件を追いにくくなる問題へ取り組んでいる。

同じ形式で実行できれば、モデル、入力に見せる情報、許す行動、試行の設定を比較しやすい。 それでも、ある課題が情報を答える仕事で、別の課題が記録を更新する仕事なら、成功の意味は違う。 共通の操作形式から、全業務に適用できる順位表が得られるとは言えない。

冒頭の保守期限の仕事を評価するときも、文書の検索方式、回答の作り方、参照する資料の版を固定して比較する。 モデルを変えると同時に資料や制限時間も変えれば、改善が何によるものか分からなくなる。 測定可能にすることには、繰り返し実行できる環境と、変えた条件を説明できる記録の両方が含まれる。

製品の構築機能は、評価する仕事を実装する足場になる

AWSの2024年4月のBedrock Agents更新は、関数と引数を定義する仕組みや、呼出し元のアプリケーションへ制御を戻す機能を示した。 モデルが必要な操作を選び、その処理を既存のアプリが実行する構成を取れる。 道具の選択と、実際に処理を行う場所を分ける製品上の例である。

GoogleのVertex AI Agent Builder発表は、検索と会話を含む構築機能をまとめた。 Claudeの2024年5月のtool use発表も、定義した道具とAPIへ自然言語の依頼をつなぐ機能を示している。 いずれも実装の選択肢であり、利用者の仕事の成功を測定した証拠そのものではない。

保守期限の想定例なら、検索可能な文書と取得する項目を定義し、結果を回答へ使う処理を作れる。 ただし、正しい資料を返すこと、契約に適用すること、正しい日付を答えることは、それぞれ検査する必要がある。 構築機能を選ぶ際には、道具を追加できる数だけでなく、この検査をどこへ置けるかを見る。

Anthropicのエージェント設計の解説は、決めた手順を進めるワークフローと、モデルが手順を選ぶエージェントを区別する。 必要な資料と順番が固定される仕事なら、毎回自由に行動を選ばせることが利点とは限らない。 単純な構成でも要求を満たせるかを比較し、追加する柔軟さのために増える時間と失敗を確かめたい。

保守期限を答える仕事なら、不明を返す条件も決める

ここまでの研究を、冒頭の想定例の採点条件へ移す。 入力には機器の型番と契約を持たせ、参照できる文書の範囲を定める。 資料へ期限が書かれていても、その型番、契約、適用期間に合うと確認できなければ、答えを確定しない。 以下は本稿の評価案であり、特定の製品の導入成績ではない。

比較する問い合わせには、答えが得られる通常例だけでなく、型番違い、期限の更新、契約不足も入れる。 全件へ「不明」と答える方式なら誤答は減るが、担当者の調査は残る。 条件を満たして答えた割合、根拠の取り違え、確認へ戻した割合を別々に記録する。

加えて、呼出し回数、待ち時間、人が調べ直した時間を見る。 正しい回答が増えても、担当者が毎回すべての資料を読み直す必要があるなら、省けた仕事は小さい。 必要な箇所と適用条件を確かめられる回答になったかまで、同じ問い合わせで比較したい。

失敗を読めることが、次の改善につながる

当時の資料を重ねると、道具を選ぶ研究、実環境の完了を測る研究、仕事を構成する製品機能は、それぞれ別の問題を扱っていた。 一つの方式が全てを解決したという結論より、この三つをつないで評価する意味が見える。 どこで条件を失い、どの状態を残し、何を人が確認し直したかを説明できる仕事を比較したい。

冒頭の担当者に必要なのは、検索が成功したという報告より、自分の機器へ適用できる期限とその根拠である。 それが分からない場合には、何を確認すれば先へ進めるかが欲しい。 エージェントを測定可能な仕事として設計する目的は、失敗を直せる場所へ分け、任せた人が結果を使えるようにすることにある。