Research・arXiv論文より

AIエージェント比較の約75%は「引き分け」——軌跡を比べれば約35%に減る、と主張する論文が登場

合否だけの採点では、システム間の比較の約75%で優劣がつかない——実行過程(軌跡)ごと比べれば約35%に減る、と査読前の単著論文が主張します。数字はすべて著者の自己申告です
3行で要点
  • 成功/失敗だけでAIエージェントを採点すると、システム間の比較の約75%が「引き分け」になり優劣がつかない——途中経過(軌跡)を直接比べれば約35%に減る、と著者は主張(数字はいずれも自己申告)
  • 論文はarXiv:2606.17541として実在を確認済み(2026年6月16日投稿、Fernando Diaz氏の単著、所属の記載なし)。査読前のv1プレプリントで、実験詳細やコードは未公開
  • もし正しければ、問題は「ベンチマークが尽きた」ことではなく「採点が差を捨てていた」ことかもしれない。「解き尽くされた」ベンチマークにも判別力が残り、高コストなエージェント評価を少ないデータで済ませられる可能性がある
1 何が起きたか

「最後だけ見る採点」への異議申し立てが投稿された

あなたのエージェントとライバルのエージェント——ベンチマークで比べても、約75%のケースで優劣がつかない。そう主張する論文が2026年6月16日、arXivに投稿されました。原因は、いまの標準的な採点が「タスクに成功したか、失敗したか」の二択で最後だけを見ていること。この論文は、それをやめて、エージェントが動いた全過程——専門用語で軌跡(trajectory、タスク中に何をどう進めたかの一部始終の記録)——を丸ごと比較しようと提案します。

確認できる事実から押さえておきます。論文はarXiv:2606.17541として実在し(分類はcs.LG、cs.AIにもクロスリスト)、DOIも付与されています。著者はFernando Diaz氏の単著で、アブストラクトのページに所属機関の記載はありません。PDFとTeXソースは公開されていますが、投稿から約1か月のv1、つまり査読を経ていない初稿段階です。以下で紹介する数字は、この前提で読んでください。

2 何が問題か

成功/失敗の採点では、4分の3が「区別不能」——という主張

冒頭の約75%という数字を、もう少し正確に押さえます。著者によれば、成功ベースの指標で2つのシステムを比べると、多様なエージェント系・対話系ベンチマークのおよそ75%のインスタンスで比較が引き分け(tied comparison)になる——つまり同じ点数がつき、どちらが優れているか判定できないと言います。この75%は論文アブストラクトの自己申告値で、対象ベンチマークの一覧や実験の詳細はアブストラクトからは確認できません。

とはいえ、構造的な理屈は分かりやすいものです。難しいタスクでは多くのシステムが揃って失敗し、易しいタスクでは揃って成功する。0点か100点かしかない採点では、その中間の「どこまで迫れたか」がすべて捨てられます。統計の言葉で言えば、引き分けはデータの有効サンプルサイズ(比較に実際に情報を与えるデータの量)を食いつぶします。100タスク走らせても75タスクが引き分けなら、優劣の判定に効いているのは実質25タスク分だけ、ということです。

平たく言うと

採点基準が「完走したかどうか」しかないマラソン大会を想像してください。40km地点まで粘った走者と、5kmで棄権した走者は、どちらも「完走ならず」で同じ記録になります。実力差は歴然なのに、記録表の上では永遠に引き分け。いまのエージェント評価は、これと同じことをしている——というのが論文の見立てです。

3 提案の中身

同じ失敗でも、「どちらがマシだったか」は見える

提案手法の名前は「選好ベースの軌跡評価(preference-based trajectory evaluation)」。発想はシンプルで、各システムの点数を別々に出して見比べるのではなく、2つの走り(軌跡)を直接横に並べ、進捗の積み上がり方や成果に到達するまでの時間プロファイルをもとに「どちらが好ましいか」という選好で順位をつけます。

これはオフライン評価(新しく実験を回さず、記録済みの走行ログだけから判定するやり方)として機能する点も重要です。同じログでも、最後の成否だけ読めば引き分け、過程まで読めば優劣がつく。捨てていた情報を拾い直すだけなので、追加の実行コストはかからない理屈です。

従来:成功/失敗だけ エージェントA × 失敗 エージェントB × 失敗 → 引き分け(区別できない) 提案:進捗の軌跡を比べる 進捗 時間 A:8割近くまで前進 B:序盤で停滞 → Aが優位、と判定できる
同じ2つの実行ログでも、成否だけ見れば引き分け、軌跡まで見れば優劣がつく(論文の主張を図式化した概念図)。
POINT
拾い直すのは「捨てていた情報」:この手法の魅力は、新しいベンチマークを作れとも、追加でモデルを走らせろとも言わない点です。すでに手元にある実行ログの読み方を変えるだけで判別力が上がる——それが本当なら、導入の障壁はかなり低いはずです。

ただし、この「75%→35%」という数字そのものには、立ち止まって読むべき但し書きが4つあります。次の節で見ていきます。

4 数字の読み方

75%から35%へ——ただし、すべて著者の自己申告

論文の中心的な実証主張は1つです。成功ベースの指標で約75%あった引き分けが、軌跡ベースの選好評価に切り替えると約35%まで減った。差し引き約40ポイントの改善で、著者はさらに、順位づけの安定性とデータ効率も向上したと述べています。

~75%
成功ベース指標で引き分けになるインスタンスの割合(著者自己申告)
~35%
軌跡ベース選好評価に切り替えた後の引き分け率(著者自己申告)
約40pt
引き分けの減少幅。論文の中心的な実証主張だが、実験詳細は未確認
観点成功ベース評価(従来)軌跡ベース選好評価(提案)
採点に使う情報最終的な成功/失敗のみ進捗の積み上がりと到達時間の全過程
引き分けの割合約75%(著者自己申告)約35%(著者自己申告)
データ効率引き分けがサンプルを浪費少ない実行数で順位づけ可能と主張
← 表は横にスワイプできます →

ここから先は、数字よりも留保が重要です。第一に、現時点で確認できるのはアブストラクトだけで、どのベンチマークで測ったのか、比較対象のベースラインは何か、効果量の内訳はどうか、といった実験の中身は見えません。第二に、75%と35%はどちらもアブストラクト自身が「roughly(おおよそ)」と幅を持たせた数字です。

第三に、コードやデータの公開には一切触れられておらず、第三者が追試するための材料はまだありません。そして第四に、単著のv1プレプリントであり、査読という他人の目はまだ通っていません。つまり、この記事で紹介した数字はすべて「著者がそう主張している」段階です。

5 なぜ重要か

「解き尽くされたベンチマーク」は、本当に解き尽くされたのか

この論文がひときわ挑発的なのは、ベンチマーク飽和(多くのシステムが上限近くに張り付き、テストとして役に立たなくなる現象)への含みです。著者は、飽和に見える現象の一部は、データや問題の難易度ではなく「測り方」の産物かもしれない、と示唆します。引き分けだらけの採点法が差を塗りつぶしているだけなら、「もう卒業した」とされたベンチマークにも、モデルを見分ける余力が残っているかもしれない——ただしこれはアブストラクトが掲げる仮説であって、実証された結論ではありません。

実務面の意味も小さくありません。エージェントの評価は1回の実行が長く、費用もかさみます。引き分けが減って1タスクあたりの情報量が増えれば、統計的に意味のある順位づけに必要な実行数が減る。つまり、高価なエージェント同士の比較が安くなる可能性があります。評価手法の論文は地味に見えますが、「何をもって進歩と呼ぶか」を決める土台の話であり、影響範囲はベンチマークを使う全員に及びます。

結論

アイデアの筋の良さと、証拠の確かさは別物です。「成功か失敗か」しか見ない採点は、エージェントの実力差の大半を塗りつぶしているかもしれない——新しい難問を作る前に、いまの採点が情報を捨てていないかを疑え、という問題提起は急所を突いています。ただし、75%が35%になるという肝心の数字は、査読前・単著・実験詳細非公開のプレプリントによる自己申告。追試とv2以降の充実、そして査読の行方を待って評価すべき段階です。

出典:Fernando Diaz, "preference-based trajectory evaluation" に関する論文(arXiv:2606.17541、cs.LG/cs.AI、2026年6月16日投稿、DOI: 10.48550/arXiv.2606.17541)。本文中の75%・35%などの数値はいずれも同論文アブストラクトの著者自己申告値であり、査読・第三者検証は行われていません。図は論文の主張をもとにした概念図です。