更新を通す前に
平均点が上がったのに、利用者は安心して任せられない
資料から締切を読み、予定表へ登録するエージェントを考える。 これは評価設計を説明する想定例である。 新しいモデルは多くの資料を読めるようになり、全体の成功率も改善した。 ところが、別のタイムゾーンの締切をずらして保存する失敗や、途中で再試行して同じ予定を二件作る失敗が残る。 この更新を、平均点が上がったという理由で配備してよいだろうか。
利用者が困るのは、全体の点数ではなく、自分の締切を逃すことや、どちらの予定が正しいかを調べ直すことだ。 私の判断は、評価を配備に使うには、改善した能力と、許容できない失敗を分けて説明する必要がある、というものになる。 公開ベンチマークの点数だけから、全ての業務に使える合格点を導くことはできない。
そのためには、エージェントが何をしたかだけでなく、採点が何を正解にしたのかも読む必要がある。 課題を一度解けること、同じ条件で繰り返し解けること、利用者が手直しせずに使えることは、それぞれ違う問いだからだ。
点数の対象
公開評価は、任せたい仕事との距離を測る手掛かりになる
AgentBenchの原版は、8種類の対話的な環境で推論と意思決定を評価した。 GAIAの原版は、推論、画像などの入力、Web閲覧、道具の利用を組み合わせる466問を作った。 前者は環境での複数段階の行動を、後者は複数の情報から答えへ到達する力を扱う。 どちらも、予定表へ正しい時刻を一件だけ保存するという自社の条件を、そのまま採点しているわけではない。
OSWorldの原版は、Webやデスクトップアプリ、ファイル操作などの369課題に、初期状態と実行結果の判定を用意した。 このような環境の評価は、説明のもっともらしさから、実際に残った状態へ目を向ける助けになる。 ただし、公開課題でできた操作が、別のアプリの版や権限でもできるとは限らない。
公開評価の使い方は、総合点で候補を並べることに尽きない。 自社の仕事に必要な能力が試験に含まれるか、含まれない条件は何かを調べる。 予定表なら、資料の読み取りだけでなく、対象の予定表、タイムゾーン、重複の扱いを確認する。 試験の範囲を知ることで、別に検査する必要がある部分が見えてくる。
繰り返したときの差
八回のうち一回成功することと、八回とも成功することは違う
τ-benchの原版は、小売と航空の業務を模した環境で、エージェントにAPIと業務ルールを与え、言語モデルが演じる利用者との対話を試した。 会話後のデータベースを期待する状態と比較して採点する。 本物の顧客による導入試験ではなく、対話、道具、ルールを一緒に検査する研究環境である。
同論文は、複数回の試行で少なくとも一回成功する指標pass@kと、全ての試行が成功する確率を課題全体で平均する指標pass^kを区別する。 小売の実験では、GPT-4oがAPI呼出しを選ぶ構成の平均成功率が60%を超える一方、8回全て成功するpass^8は25%未満まで下がると報告した。 同じ課題でも対話の生成に揺らぎがあるため、一回の成功だけでは安定して扱えるとは言えない。
この二つは、使いたい仕事によって意味が変わる。 複数の下書きから人が一つを選ぶなら、どれか使えるものが得られる能力には価値がある。 既存の予定表を変更する仕事では、成功するまで何度も保存し、後から良い結果を選ぶことはできない。 繰り返しの検査では同じ初期状態に戻し、成功だけでなく、重複や途中で残った変更も調べる必要がある。
取り戻せない失敗
丁寧な応答の陰で、次の操作を失うことがある
τ-benchの付録には、利用者が同じ注文の二つの商品を交換したい場面で、一注文の交換は一回だけというルールを忘れ、一品を先に交換してしまう例がある。 本来は必要な情報を集め、二品を一度の操作で扱う必要があった。 最初の操作が動いても、残った要望を実行できなくなる。 この失敗は、口調が丁寧か、道具を呼べたかだけでは見えない。
予定表の想定例でも、資料を正しく読むことと、既存の予定を壊さないことは分けて検査したい。 読み取りが改善して平均点が上がっても、登録先を取り違えたり、重複を増やしたりすれば、利用者の負担は減らない。 一件の重大な失敗を、別の簡単な課題の成功で相殺してよいかを、配備前に決める必要がある。
私は、許容しない変更が観測された更新は、平均点と切り離して原因を調べるべきだと考える。 一方、評価中にその失敗が出なかったことは、今後も起きない証明にはならない。 どの条件を何回試し、どこは未検査なのかまで記録することで、配備を認める範囲を狭く説明できる。
採点側の点検
低い点数が、エージェントの誤りとは限らない
SWE-bench Verifiedの発表は、評価そのものを点検する必要を示す。 OpenAIは、問題文の条件不足、正しい解決まで拒むほど具体的なテスト、実行環境の設定不良を挙げ、開発者による選別を経た500課題を公開した。 点数を信じる前に、要求、判定器、環境を確かめるという論点である。
同発表の例では、ライブラリの引数が使われていないという問題に対し、テストが特定の警告と、その正確な文言を要求していた。 エージェントへ渡す問題文にその条件がなければ、合理的な修正でも不合格になりうる。 これは、採点器が厳しければ信頼できる、という単純な関係を崩す具体例だ。 人が確認した課題も、全ての品質を漏れなく測る保証にはならない。
予定表への登録を採点するときも同様だ。 同じ瞬間を別のタイムゾーン表記で保存した結果を、文字列が違うという理由だけで誤りにしていないか。 逆に、日時の説明が正しければ、別の予定表へ保存した結果まで合格にしていないか。 正しい変更を拒む判定と、誤った変更を通す判定の両方を点検したい。
実務に近い課題でも
過去の報酬を付けても、導入効果がそのまま分かるわけではない
SWE-Lancerの原版は、Upworkの1,400件を超えるソフトウェア開発課題を集め、過去の実際の支払額を合計100万ドルとして扱った。 実装の課題は経験のある開発者が三重に確認した一連の動作試験で採点し、管理の課題は技術提案から選んだ案を元の担当者の選択と比較する。 コードを書く力と、案を選ぶ判断を別の形で測る研究である。
この設計は、抽象的な問題数より仕事の内容を読みやすくする。 ただし、過去の支払額はAIが実際に稼いだ収益ではない。 担当者の選択に一致したことも、その提案が全ての条件で最適だったという証明ではない。 経済的な意味を考えるなら、検査が測った成果と、運用時の費用や人の確認時間を分ける必要がある。
予定表の仕事なら、一件の自動登録だけを便益と数えない。 利用者が日時や登録先を確認し、重複を消し、必要なら資料を読み直す時間も含めて比べる。 人が直接登録する方法や、日時を抽出して人が保存する方法より負担が減るか。 その比較があって初めて、エージェントに任せる範囲を増やす理由になる。
更新を比較する設計
条件をそろえ、点数と原因を別に残す
BrowserGymの原版は、複数のWeb評価環境を共通の観測・行動形式で扱う仕組みを示した。 AutoGen v0.4は、メッセージ追跡やデバッグなどを提示した。 実験の条件をそろえることと、失敗した処理を追うことは、配備判断の説明を支える。 ただし、記録が詳しくても、正しい登録日時の定義は別に必要だ。
予定表の検査では、資料、既存の予定、権限、タイムゾーン、アプリの版をそろえて旧構成と新構成を比べる。 一度に複数の条件を変えると、改善や悪化をどの変更へ戻すべきか分かりにくい。 完了数とは別に、参照した資料、読み取った日時、登録先、送信した引数、保存後の状態を残す。 資料の誤読と、時刻変換の誤りと、保存先の取り違えを区別できる記録にする。
調整に使った課題だけで良い結果が出ても、新しい資料で使えるかは未確認である。 従来の失敗を再検査する組と、調整に使わなかった課題を試す組を分ける。 さらに、時刻が欠けた資料や権限がない予定表では、確認や保留を正しい結果として定める。 全ての仕事を人へ返す方式との違いが分かるよう、必要な保留と不要な引き戻しも別々に数える。
完了と残った変更
正しい予定を一件保存できたか。重複、登録先の誤り、途中の変更は別に記録する。
条件ごとの安定性
資料や権限の条件を分け、初期状態を戻して繰り返す。平均に隠れる失敗を読む。
利用者に戻った負担
必要な確認と不要な引き戻しを分ける。調べ直しと修正にかかった時間も比べる。
配備を判断するために
何を任せるかと、何が起きたら更新を止めるかを対にする
Building effective agentsは、必要に応じて複雑さを増やし、定めた経路を通す処理と、モデルに判断を委ねる処理を選ぶ考え方を示す。 評価の結果、自由な再試行が重複を増やすなら、入力を準備する範囲へ戻す選択もある。 配備はエージェント全体を一度に認める判断ではなく、検査した仕事と条件に対して行える。
本稿が提案する導入条件は、成功率の目標だけを置くことではない。 対象の仕事、繰り返し検査、許容しない失敗、保留すべき条件、利用者の負担を先に定め、更新後も同じ基準で比べることだ。 十分な試行数や合格水準は、失敗したときの影響と確認できた範囲から決める。 少数の成功例だけで、長期の安定性まで宣言することはできない。
点数が上がったことを、利用者が安心して任せられることへつなぐには、何が改善し、どの失敗が残り、誰がそれを直すのかを示す必要がある。 評価をその説明に使えば、進歩を認めながら、通してはいけない更新も選べる。 配備を支えるのは、点数の高さに加えて、点数の外に残る仕事を読めることだ。