AIは自らを測る「物差し」を作れるか 評価設計ベンチERB

どんな論文か

Oregon State University、AG2 AI、University of California, San Diego、Pennsylvania State University の研究チームによる論文です。テーマは再帰的自己改善（RSI、AIが自らを改良し、その結果を見て次の改良を決めるループ）です。このループは評価結果を道しるべに進みますが、重いベンチマークを毎回フルで回していては、お金も時間もかかってしまいます。

そこで著者らは「評価器の設計そのものを、AIエージェントに任せられないか」と問いかけました。その検証のために作られたのが EvalResearchBench（ERB）です。エージェントは決められた時間と API 予算の中で問題を選んだり作ったりし、採点器を実装してはテストと修正を繰り返します。そして最後に、コーディング・コワーク（調べ物や専門的な成果物づくり）・推論の3領域を採点する評価器を仕上げて提出します。

この論文の肝

一言で言うと、「評価を作る研究」そのものを、エージェントの課題として採点した点にあります。

これまでの自動改善の研究では、評価の仕組みは人間が用意していました。PostTrainBench では対象ベンチと評価ハーネスが固定されており、AlphaEvolve はユーザーが与えた評価関数に従って動きます。ベンチ構築を自動化する研究（AutoBencher、BenchAgents など）もありますが、扱うのは問題生成や絞り込みといった一部の工程だけでした。この論文は、測り方を選び、限られた実験予算をやりくりし、実行可能な評価器を「本物のベンチと順位が合うまで」鍛え上げるところまでを、ひとつの課題にまとめています。

図1　評価づくりを誰が担うか。これまでの自動改善研究とERBで、エージェントに任せる範囲と採点の仕方を比べた表。

もう一つの工夫は、作られた評価器を隠されたテスト環境でも採点する点です。研究中のエージェントに見えるのは、開発用の候補4モデルと参照ベンチ6本だけです。提出後、残りの9モデルと隠しておいたベンチ8本を加えて独立に評価を回します。見えている参照データに調子を合わせただけの評価器は、ここで見抜かれる仕組みです。

使いどころと価値

意味: いまのエージェントに評価器づくりをどこまで任せられるのか、その「現在地」が数字で明らかになりました。最良の評価器でも、候補ペアの順位がベンチと一致したのは約75%です。一方、ベンチ同士の食い違いから決まる理論上の天井は91%でした[引用1]。伸びしろはまだ大きいと言えます。さらに、開発用の参照で最も一致していた評価器が、隠したベンチでは首位になりませんでした[引用3]。「手元の参照に合う」ことと「汎用的な物差しである」ことは別問題だと、実験で裏づけた点が大きな一歩です。

価値: 繰り返し回す評価では、開発コストよりも毎回の実行コストのほうが重くのしかかります。論文で実行コストを比べると、Grok 4.7 が作った評価器は 107 問で 8.63 ドルでした。一方、ほぼ同じ問題数の Fable 5.1 は 110 問で 109.41 ドルかかっています。しかも、全体の PA（順位一致率）が最も高かったのは、安上がりな Grok の評価器でした[引用4]。問題数だけでは実行コストは読めず、「候補モデルに何を出力させるか」と「どう採点するか」がコストを左右します。

使いどころ（筆者の見方を含みます）:

• 自社モデルの改良版を毎週出し、そのたびに重いエージェント系ベンチを回していて、「軽量な代理評価」を作りたいチーム。
• エージェントに改善ループを回させており、評価用テストセット自体もエージェントに作らせようとしている開発者。この論文は、自作テストセットが回答の打ち切りや重みの偏りでいかに壊れやすいかを具体的に示しています。
• 社内のLLM評価セットを、公開ベンチから問題を抜き出して手作りしている人。人手で設計した公開問題120問のサンプル（Random120）は手強い比較相手でした[引用2]。まずは単純な層別サンプルをベースラインに据えるとよさそうです。

今日からできること: 論文のコードは GitHub で公開されており、評価器を Score（得点の一致度）と PA で採点する仕組みを手元で試せます。コードを使わなくても、設計の勘所はすぐに取り入れられます。たとえば、自作の評価セットについて次の3点を点検してみてください。(1) 全候補が正解する問題や全候補が不正解になる問題は、順位の区別に役立たない。(2) ごく一部の問題に重みが集中していないか。(3) 回答が長さ上限で打ち切られて空になっていないか。

向かない場面・前提: 実験は、研究時間3時間、エージェント推論に100ドル、開発テストに100ドル、独立評価に総額120ドル（1候補あたり上限30ドル）という予算枠で行われています。研究エピソードは各設定1回だけです。参照データは公開リーダーボードのスナップショットに頼っています。参照ベンチどうしで順位が食い違う場合、どんな評価器を作っても完全には一致させられません。

仕組み

登場人物は3つです。評価器を設計する「研究者」（Codex や Claude Code などのハーネス＝エージェントの実行環境の中で動くLLM）、測られる側の「候補」モデル、そして再現すべきお手本となる「ターゲット」ベンチです。

図2　ERBで評価器ができるまで。研究者エージェントが資料を受け取ってから、凍結した評価器が独立に採点されるまでの流れ。

研究者は、ターゲットの説明、利用可能な既存タスクと採点資源、過去の実行ログ、開発用候補の参照得点、課金つきの候補API を受け取ります。パイロット試験を回して候補の回答・コスト・参照との一致度を確かめ、その結果をもとに問題を差し替えたり、採点器を直したり、重みや回答長の上限を調整したりします。最終的な提出物は、100問以上の採点つき問題、実行可能な採点コード、集計ルールです。いったん凍結した後は変更できません。

採点は2つの指標で行います。Score は一致相関係数（CCC、順位だけでなく得点の水準やばらつきまで合っているかを見る相関）を100倍した値です。PA は、候補2モデルのペアのうち、ターゲットと同じ大小関係に並べられた割合を指します。ターゲット同士でも順位が食い違うため、PAには上限があり、全体では 91.20% と算出されています。比較相手の Random120 は、人間が選んだ16の公開ソースから、あらかじめ決めた配分で各領域40問ずつ、計120問を抜き出したものです。

結果

実験では研究者9設定、候補13モデル、ターゲット14ベンチを扱いました。全体の Score が最も高かったのは GPT-6 Astra の 22.79 で、Grok 4.7 の 22.59 が僅差で続きます。全体の PA は Grok 4.7 が 74.87% でトップに立ちました。ただし、すべての領域と指標を総なめにした研究者はいません。領域別に見ると、コーディングは Grok、コワークは Astra、推論は Opus 5 が首位でした。なお、コーディングは多くの評価器が苦戦した領域です。

図3　全体の順位一致率（PA）。14ターゲット全体でのPA（候補ペアをターゲットと同じ向きに並べた割合）と、ターゲット同士の食い違いから決まる上限。

PA の最高値 74.87% は、上限の 91.20% を大きく下回っています[引用1]。人で作った Random120（Score 13.10、PA 68.29%）と同じ候補モデル群で比べると、エージェントが作った8つの評価器のうち7つは Score で上回りました。ところが、PA で上回ったのは4つにとどまります[引用2]。また、開発用ターゲットで Score 首位だった Fable 5.1 は、隠したターゲットでは首位から陥落しました[引用3]。

分析のなかで特に目を引くのが重みの扱いです。Grok はコワーク20問のうち、わずか6問に重みの 93.87% を集中させていました。同じ回答データを均等な重みで集計し直すと、全体の Score は 22.18 から 37.03 へと跳ね上がります。PA は 76.07% から 76.01% とほぼ横ばいでした。せっかく集めた有用な測定信号を、極端な重み付けで活かしきれていなかったわけです。

また、Astra の評価器から表計算タスク8問を除くと、コワークの Score が 31.94 点、PA が 12.57 ポイント低下しました。この8問は評価の要となっていた問題群です。ただし、その回答の 46/96 件は出力長の上限に達して最終回答が途切れていました。モデルを見分ける力は、タスクそのものだけでなく、回答の打ち切りを含む実行条件も反映していたことになります。

限界と注意

研究エピソードは各設定につき1回だけで、複数回試行したときのばらつきは測られていません。候補は13モデル、ターゲットごとに対応する候補は7〜12程度と小規模な集団です。Fable 5 は評価予算を途中で使い切って一部しか測定できず、主順位から外されています。参照データはリーダーボードの公開スナップショットであり、ベンチ同士の尺度や順位の食い違いが Score と PA の上限を規定しています。コストは API 換算の推定値で、一部は協力者の報告に基づきます。著者らは、エージェントが作った評価器が回答を打ち切ったり、評価予算を使い果たしたり、ごく少数の問題に領域スコアを支配させたりするリスクがあると指摘しています。

筆者は論文を読んで解説しています。手元で動かしたのは次の小さな実験だけで、論文自体の追試は行っていません。

手元で試した結果

論文から得られる教訓（候補に差がつく問題を選ぶ、全員正解の問題や重みの集中を避ける、Score と PA は別物と意識する）をプロンプトに入れたとき、claude-haiku-4-5-20251001 が「パイロット試験の正誤表から問題の組み合わせや重みを選ぶ／PA を計算する」小問を正しく解けるようになるかを試しました。架空の候補4〜5個からなる10問を作成し、2条件で解かせています。結果は、ふつうの指示（A）が 10/10問（100.0%）、教訓を盛り込んだ指示（B）が 9/10問（90.0%）でした。どちらも9割以上正解したため、問題が易しすぎて条件間の差は確認できませんでした。これは論文の追試ではなく、研究者エージェントによる「作って試して直す」ループも試していません。

手元で試すなら

コードは GitHub（github.com/Mercury7353/self-evaluation-bench ）で公開されており、プロジェクトサイトは mercury7353.github.io/self-evaluation-bench/ です。

原文からの引用

[引用1] The best evaluators order about 75% of candidate pairs as the targets do, below the 91% ceiling set by disagreements among the targets.

（訳）最良の評価器は候補ペアの約75%をターゲットと同じ順に並べるが、ターゲット同士の食い違いで決まる91%の上限には届かない。

[引用2] On identical candidates, seven of eight agent-designed evaluators exceed it in Score, but only four exceed it in PA.

（訳）同じ候補で比べると、エージェントが設計した8つの評価器のうち7つはScoreでそれ（Random120）を上回るが、PAで上回るのは4つだけである。

[引用3] Fable 5.1 has the highest Score on development targets but not on sealed ones, so fitting visible references does not ensure transfer.

（訳）Fable 5.1は開発用ターゲットでScoreが最も高いが、隠したターゲットではそうではない。見える参照に合わせても、他へ通用するとは限らない。

[引用4] Evaluators with similar construction cost differ markedly in execution cost, and the one with the lowest recorded execution cost attains the highest PA.

（訳）構築コストが似た評価器でも実行コストは大きく異なり、記録上の実行コストが最も低い評価器が最も高いPAを得た。