結果だけを記録した評価は、縮めると壊れる——過程の記録は評価を安く回すための前提投資
評価には手間がかかります。AIツールの比較でも、業務プロセスの点検でも、全部を毎回測っていたら時間も費用も足りません。そこで「代表的なものだけ選んで測れば、全体の傾向は分かるはずだ」と考えるのは自然な発想です。
ただ、この発想には前提があります。何を選べば全体を代表できるのかを、手元の記録から判断できることです。2026年9月16日付のプレプリント(arXiv:2609.18909v1)は、AIエージェントの評価を題材に、この前提を正面から扱いました。最終スコアだけでなく、エージェントがタスクをどう進めたかという過程の情報を使うと、小さなタスク集合からの予測が改善した、という報告です。
この記事では、論文で確認できた範囲を整理したうえで、「結果だけを記録している評価は、縮めようとしたときに手がかりが足りない」という読み方を、筆者の解釈として示します。
30秒で要点
- AIエージェントの評価は高くつく。論文は、あるベンチマークで1つのモデルを評価するのにAPIコストが約1万900ドル、別のモデルでは理想的な並列条件でも約2.7日かかる例を挙げている
- このコストは、エージェントの改訂や新モデルの導入のたびに繰り返し発生する
- 既存の圧縮手法は、主に「タスク×モデルの最終スコア分布」だけを見て冗長性を判断していた
- 論文は、エージェントの動き方(過程)から6つのシグナルを取り出し、結果と過程の両方を使って小さなタスク集合を選ぶ手法 DualViewEval を提案した
- 20タスクだけで、比較手法より全体スコアの予測誤差が小さかった。ただし著者自身による評価で、査読前のプレプリント
| 用語 | 意味 |
|---|---|
| AIエージェント | 指示を受けて、ツールの呼び出しやファイル操作などを自分で順に行い、タスクを進めるAIの仕組み |
| API(エーピーアイ) | 外部のプログラムから機能を呼び出すための窓口。AIモデルをAPI経由で使うと、使った量に応じて料金がかかる |
| ベンチマーク | 性能を比べるために用意された、決まった課題の集まり |
| 軌跡(trajectory) | エージェントがタスクを進める途中で行った操作の記録。何回試したか、どのツールを使ったか、などが残る |
| miniset | 全体のベンチマークから選び出した小さなタスク集合。これだけを評価して全体のスコアを予測する |
| 平均絶対誤差(MAE) | 予測したスコアと実際のスコアの差(絶対値)を平均したもの。単位はスコアと同じで、小さいほど予測が正確 |
| Kendall の τ(タウ) | 2つの並び順がどれだけ一致しているかを表す数値。-1〜1の範囲で、1に近いほど順位の付き方が一致している |
評価のコストは、1回では終わらない
論文は冒頭で、エージェントの評価が時間と推論資源の両面で高くつくことを、具体例で示しています。
- 費用の例: APEX-Agents というベンチマークで Claude Opus 4.8 を評価すると、APIコストが約1万900ドル
- 時間の例: Gemini 3.5 Flash の評価は、理想的な10並列でも約2.7日
どちらも論文が評価例に挙げたモデルで、費用と時間は別々のモデルの値です。同じ条件で比べた数字ではない点に注意してください。
論文がこの例で強調しているのは、金額の大きさそのものより、このコストがエージェントの改訂や新モデルの導入のたびに繰り返し発生することです。一度きりなら全部測れば済みます。改善を回すたびに測り直すからこそ、「どう縮めるか」が問題になります。
最終スコアだけでは、何が冗長かを判断しにくい
評価を縮める研究はこれまでにもありました。論文によれば、既存の手法は主にタスク×モデルの最終スコア分布の冗長性をモデル化していました。筆者なりに言い換えると、多くのモデルで似た点数の付き方をするタスクどうしは互いに代わりがきくので、一部を残せば足りる、という発想です。
論文はこれを限界として挙げ、最終スコアに加えて過程を見ることを提案しています。大規模な軌跡を分析し、最終的な性能と体系的に関連する6つの相補的なシグナルを同定しました。付録に挙がっている項目名は次のとおりです(日本語は筆者による字面の訳)。
- Agent steps(エージェントの手順数)
- Tool failed rate(ツール呼び出しの失敗率)
- Tool-category entropy(使ったツールの種類の散らばり)
- Validation-tool rate(検証用ツールを使った割合)
- Required-write execution(必要な書き込みを実行したか)
- Read–write–validate closure(読む・書く・確かめるを一巡させたか)
各指標の定義式や、どれが最も効いたかは、筆者は論文の該当節を読んでいないため、ここでは項目名の紹介にとどめます。
結果と過程の両方を使うと、20タスクで予測が改善した
提案手法の DualViewEval は、結果の関係と過程の関係を同時に使い、指定したサイズの miniset を学習して、全体ベンチマークのスコアを予測します。論文の報告は次のとおりです。
- 5つのエージェントベンチマーク、5つの代表的な比較手法に対し、すべてのデータセットで最良の結果
- 20タスクだけで、APEX-Agents と BFCL で24〜40倍の圧縮
- 最も強い比較手法と比べて、平均絶対誤差(MAE)を14.5〜28.2%削減
- SWE-bench Verified では、EssenceBench という比較手法より Kendall の τ を最大7.2%(相対)改善
数字の読み方を確認しておきます。MAE の「14.5〜28.2%削減」は、分母が最も強い比較手法のMAE、分子がそこからの減少幅です。全数評価との差がゼロに近づいたという意味ではありません。τ の「7.2%改善」も、EssenceBench の τ を基準にした相対的な伸びです。どちらも「他の圧縮手法より良かった」という比較であり、「全数評価と同じ結果が出る」ことを示したものではありません。
同じ点数は、同じ中身とは限らない
ここからは論文の主張ではなく、筆者の読み方です。
最初は「最終スコアが同じなら、そのタスクで起きたことも同じだろう」と考えていました。けれども、過程のシグナルの項目名を眺めると、同じ正解に至る道筋はいくつもありうることに気づきます。少ない手順で素直に解いた場合と、何度もツール呼び出しに失敗しながらようやくたどり着いた場合は、点数では区別できません。
過程のシグナルで予測が改善したという結果は、この区別に情報があることを示唆していると筆者は考えます。そうだとすれば、結果しか記録していない評価は、縮めようとしたときに「どのタスクが全体を代表するか」を判断する材料が足りないことになります。
この取り違えが起きやすい理由は3つあると考えています。
1つ目に、点数は比べやすいので、点数だけが残る。過程の記録は形式がばらばらで集計しにくく、評価の報告書からは真っ先に落ちます。
2つ目に、過程の記録は、全数評価をしている間は役に立たないように見える。全部を測っているなら、最終スコアだけで結論は出ます。過程の記録が効いてくるのは、縮めようとした後です。必要になった時点では、もう記録は残っていません。
3つ目に、縮めた評価の誤差は、縮めた評価の中からは見えない。20タスクの結果がそれらしければ、それが全体を代表しているかどうかを疑うきっかけがありません。
確かなことと、まだ確かではないこと
確かなこと(arXiv:2609.18909v1 の記載による):
- エージェント評価のコスト例(APIコスト約1万900ドル、10並列でも約2.7日)と、それが改訂や新モデル導入のたびに再発生すること
- 既存の圧縮手法が主に最終スコア分布の冗長性をモデル化していたこと
- 過程に関する6つのシグナルを同定し、結果と過程を併用する DualViewEval を提案したこと
- 20タスクで24〜40倍の圧縮、MAE 14.5〜28.2%削減、τ 最大7.2%(相対)改善という報告
まだ確かではないこと:
- 査読前のプレプリントで、結果は著者自身による評価である。著者の所属には、評価される側でもあるAI開発企業(Tencent)が含まれる
- 6つのシグナルそれぞれの定義や、どれが最も効いたか(筆者は本文の該当節を未確認)
- 上で触れた3つ以外のベンチマークでの個別の数値
- 例に挙がったモデル名が現時点でどの位置づけにあるか。本記事は論文中の例として扱っているだけで、最新かどうかは確認していない
人の評価に当てはめると、何が言えそうか
ここからは筆者の仮説で、論文はAIエージェントのベンチマーク以外を扱っていません。
人事評価や業務監査でも、「成果の数字だけを残し、どう取り組んだかは残さない」運用はありえます。全員を毎回詳しく見ているうちは、それで困りません。しかし工数を減らすために「一部だけ詳しく見る」に切り替えたとき、成果の数字しか手元になければ、誰を・どの案件を見れば全体の実態をつかめるのかを選ぶ根拠が乏しくなります。
もしこの仮説が当たっているなら、過程の記録は「丁寧な評価のための追加コスト」ではなく、評価を安く回せるようにするための前提投資と位置づけ直せます。記録にかかる手間を払うかどうかは、将来その評価を縮めたいかどうかで判断することになります。
AIエージェントを導入するときのベンチマークの読み方はAIエージェントは「ベンチマーク9割、本番6割」で扱っています。ベンチマークの点数が本番の成果をどこまで表すかという問いと、点数だけを残した評価をどこまで縮められるかという今回の問いは、どちらも「点数に何が含まれていないか」を問う点で同じ根を持っています。
自分の評価で確かめる最小の手順
いま繰り返し回している評価を1つ選び、次を確認してください。AIツールの比較でも、定例の業務レビューでもかまいません。
- 最終結果以外に、何が記録されているかを書き出す。点数、合否、件数以外に、どんな手順を踏んだか、どこでつまずいたかが残っているか
- 同じ結果になった2件を選び、記録から違いを説明できるか試す。説明できなければ、その評価は結果しか記録していない
- 「来月から半分だけ評価する」としたら、どれを残すかを記録だけで決められるか考える。決められないなら、縮めた評価は当て推量になる
3で迷ったなら、次回の評価から過程の記録を1項目だけ足すところから始められます。何を足すかは、2で「説明できなかった違い」が手がかりになります。
この記事で扱ったような判断を、自社の状況に照らして整理したい場合は、無料診断ツールで状況を言語化するところから始めることができます。
状況を整理する(15分)