AI評価
AI評価の得点は、どの設定まで記録すれば再現できるのか
- AI評価
- エージェント
- 得点
- ベンチマーク
- Every Eval Ever
- 英国AISI
- 評価ハーネス
- スキーマ
- SWE-Bench Pro
- HLE
- 再現
- サンドボックス
- トークン
- 必須欄
- Terminal-Bench
- HealthBench
- FrontierMath
- EvalEval Coalition
- Hugging Face
- JSON
- 推論
目次
公開されている評価の得点を比べて、自分の用途に使うモデルを選ぼうとする実務者がいる。得点に疑問があれば、公開元と同じ測り方で測り直し、同じ得点が出るかを確かめたい。この確かめを再現と呼ぶ。
ところが得点は、モデルの能力だけでは決まらない。評価では、問題をモデルに解かせて採点するソフトウェアを使う。このソフトウェアを評価ハーネスと呼ぶ。同じ評価でも、評価ハーネスが違えば得点が食い違うことがある。
評価を実行するときの設定によっても、得点は変わる。モデルに道具を使わせ、何手もかけて課題を解かせる評価を、エージェント型の評価と呼ぶ。エージェント型の評価では、各問に使ってよいトークン数の上限を広げると、得点が上がることがある。こうした設定は、公開元によって書かれたり書かれなかったりする。
設定が書かれていなければ、読み手は公開元と同じ測り方を選べない。二つの得点の差が能力の差なのか設定の差なのかも、判別できない。
評価の得点を公開するとき、記録に何をどこまで書けば、読み手は同じ得点を測り直せるのか。
評価の得点を再現するには、評価ハーネスとモデルに加えて、得点を変える実行の設定がすべて記録に書かれている必要があり、エージェント型の評価では、トークン数などの上限、答えを提出できる回数、提出の正誤をモデルに知らせるかどうか、使わせた道具、モデルがコードを動かす隔離環境の設定がこれに当たる。 書かれていない設定は、測り直す側が自分で決めるしかなく、決め方によって得点が変わるからである。本稿が例に読むEvery Eval Ever(研究者の集まりEvalEval Coalitionが作る、評価記録の共有形式)が必須にするのは、誰が記録を出したか、どのデータセットで、どの評価ハーネスのどの版で、どのモデルを測ったか、得点と、指標は大小どちらが良いかまでである。エージェント型の設定を書く欄は任意なので、必須欄をすべて埋めた記録でも、再現に足りるとは限らない。
設定が二つ書かれていない記録は、四通りに測り直せる
※ この節の数値は説明のための仮定で、測定値ではありません。
あるエージェント型の評価で、得点を変える設定が二つだけあるとする。一つは、モデルに検索の道具を使わせるかどうかである。もう一つは、各問に使えるトークン数の上限で、10万か100万のどちらかとする。
設定の組は 2 × 2 = 4通りある。以下では、設定の組の一つひとつを測り方と呼ぶ。同じモデルを同じ評価ハーネスで測ったときの得点を、測り方ごとに次のように置く。同じ測り方で測れば、何度測っても同じ得点が出るとする。
| 測り方 | 得点 |
|---|---|
| 道具を使わせない、上限10万 | 30 |
| 道具を使わせる、上限10万 | 40 |
| 道具を使わせない、上限100万 | 45 |
| 道具を使わせる、上限100万 | 55 |
この評価について、「得点40」と書いた記録が三つある。三つとも、モデルの名前と、評価ハーネスの名前と版は書いている。違うのは、二つの設定をどこまで書いているかである。記録に書いてある設定と食い違わない測り方を、記録に合う測り方と呼ぶ。記録ごとに、記録に合う測り方を数え、測り直して出うる得点の最大と最小の差(得点の幅)を計算する。
- 記録A(設定を書いていない):測り方は4通り。出うる得点は30、40、45、55で、幅は 55 − 30 = 25。
- 記録B(上限10万と書いている):測り方は2通り。出うる得点は30、40で、幅は 40 − 30 = 10。
- 記録C(上限10万、道具を使わせると書いている):測り方は1通り。出うる得点は40だけで、幅は0。
記録Aを読んで測り直す人は、道具と上限を自分で決めるしかない。上限を100万にして道具を使わせれば、得点は55になる。この人は、記録の40と自分の55が食い違う原因を、記録からは判別できない。記録Cを読んだ人は、測り方を一つに決められる。測り直した得点が40でなければ、元の測定か自分の測定のどちらかに誤りがあると分かる。
記録A、B、Cを比べると、次の三つが言える。ここでは、これを性質1、性質2、性質3と呼ぶ。
- 記録に合う測り方の数は、書かれていない設定ごとの選択肢の数を掛け合わせた数である。モデルと評価ハーネスが書いてあっても、この数は減らない。
- 設定を一つ書くごとに、測り方の数は減り、得点の幅は同じか狭くなる。得点を変える設定をすべて書いたときに、測り方は1通りになる。
- 設定を変えても得点が変わらない評価では、その設定を書かなくても得点の幅は広がらない。表の4行の得点がすべて40であれば、記録Aでも幅は0である。
この例は、得点を変える設定が二つだけで、同じ測り方なら同じ得点が出ると仮定した。実際の評価がこの仮定を満たすとは限らない。したがって、性質2の「すべて書く」は再現に必要な条件であり、書けば必ず再現できるという保証ではない。
Every Eval Everの論文は、同じ評価ハーネスの同じ手順で3つのモデルを測り直し、公開された記録と1問ごとに比べている。データ処理で行の並びが変わって別の問題が選ばれ、比べられなくなった評価や、一致がサンプリングのばらつきと整合する約92%にとどまった評価があった1。論文は、モデルを動かしたサービングの詳細が記録に欠けていると、食い違いは見えてもその原因は決められないことがあるとも書く1。
設定を変えると得点が変わることを、評価する側が測って報告している
設定が記録に書かれていなければ、測り直す側はその設定を自分で決めるしかない。これが問題になるのは、設定の決め方によって得点が実際に違う場合である。これに当たる報告が二つある。
一つ目は、Every Eval Ever(以下EEE)を作るEvalEval Coalitionの論文である。論文は「結果は異なる評価フレームワークによって作られ、それらは名目上同一の評価に対して食い違うスコアを生み、メタデータの記録も一貫しない」と書く1。評価フレームワークは、本稿が評価ハーネスと呼ぶソフトウェアを指す。
二つ目は、英国AISI(AI Security Institute)の研究である。AISIは、道具を使わせる評価と使わせない評価を合わせた5本のベンチマークで、トークン数の上限、答えを提出できる回数、提出の正誤をモデルに知らせるかどうかを変えて得点を測った2。答えを繰り返し提出できることは広く得点を上げたが、上限を広げること、正誤を知らせること、並列に試行を重ねることの効き方はベンチマークごとに違った2。論文は、ベンチマークの得点はこうした実行の決め方に依存すると結論する2。トークン数の上限を広げると複数の領域で得点が大きく上がり、上限を固定した評価は最前線のモデルの能力を低く見せうることも示した2。論文は勧告として、実行の決め方の選択を評価設計の一部として扱い、明示して記録するよう求めている2。
逆に、設定を変えても得点がほとんど変わらない評価では、その設定が書かれていなくても、測り直して出る得点の幅は小さい。これに当たる実測も、同じ研究にある。よく使われる上限を超えてトークン数の上限を広げたとき、得点の伸び方はベンチマークで違った。FrontierMathとHumanity’s Last Exam(HLE)では大きく伸びたが、ソフトウェア工学の2本(SWE-Bench ProとTerminal-Bench)とHealthBenchではほとんど伸びなかった2。ほとんど伸びなかった3本では、上限をこの範囲で変えても、測り直して出る得点の幅は小さい。一方、上限では伸びなかったSWE-Bench Proも、提出の正誤を知らせるかどうかでは得点が変わる。論文によれば、正誤の知らせが最も効いたのはHLEとSWE-Bench Proである2。ただし、設定を書かなくても得点の幅が小さいと言えるのは、その設定で得点が変わらないことを誰かが測って確かめた範囲に限られる。
EEEの必須欄だけの記録は、設定を書かずに検証を通る
EEEは、得点を生んだ実行の記録を、共通の形式で得点と一緒に公開するための取り決めである。EEEのGitHubリポジトリは、次の三つからなる3。
- スキーマ:記録に書く欄の名前と型、省けない欄(必須欄)を定める。
- 検証の仕組み:記録がスキーマに合うかを、データベースへ入れる前に確かめる。
- 変換器:既存の評価ハーネスのログを、EEEの形式へ書き換える。
EEEは、参加者が評価結果を持ち寄るデータベースも併せ持つ3。論文によれば、データベースには2万を超えるモデルの結果が入っている1。
本稿がEEEを例に選んだのは、記録に何を書くかをJSONの欄として定めており、読者が自分でスキーマのファイルを開いて必須欄と任意欄を確かめられるからである。記録の形式を揃える取り組みは他にもあり、モデルカードやデータセットカードのような文書の形式や、評価ハーネスごとのログの形式がそれに当たる。
EEEの記録は1つのJSON文書である。最上位の必須欄は7つで、そのうちsource_metadata・model_info・eval_library・evaluation_resultsの4つが測定の中身を書く(残りの3つはschema_version・evaluation_id・retrieved_timestampである)4。evaluation_resultsは結果を並べた配列で、その要素は、評価の名前、測ったデータセット(source_data)、指標の設定(metric_config)、得点(score_details)を必須にする4。次の表は、測定について記録が答える問いと、それを書く欄を並べたものである。表のサンドボックスは、モデルがコードを動かす隔離環境を指す。
| 記録が答える問い | 書く欄 |
|---|---|
| 誰が記録を出したか、測った側とモデルの作り手の関係は何か | source_metadata(必須) |
| どのデータセットで測ったか | evaluation_resultsの中のsource_data(必須) |
| どの評価ハーネスのどの版で測ったか | eval_library(必須) |
| どのモデルを測ったか | model_info(必須) |
| 指標は大小どちらが良いか | evaluation_resultsの中のmetric_config(必須) |
| 得点はいくつか | evaluation_resultsの中のscore_details(必須) |
| どの道具を使わせたか | agentic_eval_config(任意) |
| メッセージ数、トークン数、時間の上限はいくつか | eval_limits(任意) |
| 答えを提出できる回数の上限はいくつか | max_attempts(任意) |
| 誤答の後のフィードバックは何か | incorrect_attempt_feedback(任意) |
| サンドボックスの種類と設定は何か | sandbox(任意) |
任意の5欄は、evaluation_resultsの要素ごとに、generation_config(出力の生成と実行の設定をまとめる欄)の下に書く34。generation_configは、要素の必須欄に入っていない4。
必須欄のうち、測り直しに使うのはsource_data、eval_library、model_infoである。source_dataは、データセットの名前と、URLやHugging Faceのデータセットといった取得元の種類を必須にする4。eval_libraryは評価ハーネスの名前と版を必須にする。model_infoは、モデルの名前とIDを必須にする。測った側がモデルを自分で動かしたか、外部の管理下で動かしたかと、モデルの重みが公開か非公開かも必須にする。モデルを動かした推論プラットフォームと推論エンジンを書く欄は任意である4。
残りのうちsource_metadataとmetric_configは、得点を読むために使う。source_metadataは、データを提供した組織の名前、記録の元が生の実行ログか集計値だけの文書か、測った側とモデルの作り手との関係(本人・第三者・共同など)の三つを必須にする4。測った側がモデルの作り手本人か第三者かが分かれば、読み手は数字をどこまで信用するかを決められる。metric_configは、値が小さいほうが良い指標かどうかを必須にする4。
必須欄だけを埋めた記録は、モデルと評価ハーネスは書いてあるが、道具も上限も提出の回数もサンドボックスも書いていない。測り直す人は、これらの設定を自分で決めるしかない。この記録は検証を通る4。検証が確かめるのは、記録の形式がスキーマに合っていることである。記録から測り方を一つに決められることは確かめない。
任意の欄を埋めても、測り方が決まらない場合がある。sandboxのconfigはファイル名を入れる欄で、設定の中身まで書くかは、スキーマの説明自身が未決としている4。
英国AISIの記録で、空の欄が何を表すかを確かめる
EEEの形式で結果を公開した実例が、英国AISIである。EvalEvalとAISIは2026年9月22日に連名のHugging Faceのブログで、AISIが結果をEEEの形式で公開したと書く。対象は5つのベンチマーク(HealthBench、FrontierMath、HLE、SWE-Bench Pro、Terminal-Bench 2.0)と6つのモデル(Claude Opus 4/4.5/4.6、GPT-5/5.2/5.4)で、サイバー評価2件も併せて公開した5。公開されたデータは、前の節で見たAISIの研究に付随して出たものである5。
AISIは中立の採用者ではない。ブログによればAISIはスキーマの設計にも意見を出してきた協力者で5、AISIが作った評価ハーネスInspect AIは、EEEが変換器を用意する三つの評価ハーネスの一つでもある1。
このブログは、評価の結果が「しばしば再現に足る情報を欠く」まま報告されていると書く。「評価をやり直すこと自体が、法外に高くつく場合がある」とも書く5。設定が書かれていない記録を読んだ人は、元の測り方に当たるまで設定の組み合わせを試すことになり、試す数は、書かれていない設定ごとの選択肢の数を掛け合わせた数まで増えうる。
AISIがHLEについて出した記録の一つは、トークン数の上限と実行の計画を書き、道具の一覧を空に、サンドボックスの欄を中身の無いまま出している6。論文によれば、HLEは道具もサンドボックスも使わずに解かせた評価で、空の欄はその設定と一致する2。スキーマは道具の欄を使える道具の一覧と定めているので、空の一覧は使える道具が無かったことを書いた値として読める。サンドボックスの欄は種類と設定ファイルを書く欄で、使わなかったことを表す決まった値を持たない4。記録だけを読む人には、サンドボックスの空の欄が「使わなかった」なのか「書かなかった」なのかを区別する手がかりがない。
必須欄が埋まっていても、その値から測り方が決まらない記録もある。必須欄は値の中身までは問わず、版が分からなければunknownと書くよう、スキーマの説明自身が指示している4。AISIのサイバー評価の記録は、評価ハーネスの版をunknownとしたまま公開されている7。
必須欄が少ないのは、既存の結果を取り込むための設計である
必須欄を少なくしたのは、論文が明記する設計判断である。必須欄を最小にし、書けない情報は省くか補足の欄へ入れる形にして、既存の結果を取り込む範囲の広さを優先した。論文は限界の節でも、生成の設定などが省かれうることを自ら認めている。その同じ文は、欠けたメタデータは明示的に記録されるとも書く1。ただしスキーマで「分からない」を書く値を持つのは版や重みの公開などの欄で、道具・上限・サンドボックスの欄はその値を持たない4。設計上の選択なので、必須欄に設定の欄を加えれば、この状態は変わりうる。
変換器にも限界がある。変換器が読めるのは、元の評価ハーネスがログに書いていた範囲だけで、ログに無い設定は変換しても記録に現れない。論文も限界の節で、スキーマは評価を実行しないので、実行ごとに固有の情報は記録に含まれない可能性が高いと書く1。評価ハーネスがより多くの設定をログに書くようになれば、空のまま残る欄は減る。
出典7件
-
Batzner ほか「Every Eval Ever: A Unifying Schema and Community Repository for AI Evaluation Results」arXiv, 2026. https://arxiv.org/abs/2606.14516 — 評価ハーネスごとの得点の食い違い、必須欄を最小にした設計とその限界、測り直しの結果。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
-
McFadyen ほか「How Inference Compute Shapes Frontier LLM Evaluation」arXiv, 2026. https://arxiv.org/abs/2606.17930 — 上限・提出の回数・正誤の知らせで得点が変わり効き方がベンチマークで違うことと、実行の決め方を記録せよという勧告。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8
-
EvalEval Coalition「Every Eval Ever」README(2026-09-24 取得). https://github.com/evaleval/every_eval_ever — スキーマ・検証の仕組み・変換器からなる構成と、評価結果を持ち寄るデータベース、エージェント型の設定を generation_config の下に書くこと。 ↩ ↩2 ↩3
-
Every Eval Ever「eval.schema.json」(2026-09-24 取得). https://github.com/evaleval/every_eval_ever/blob/main/every_eval_ever/schemas/eval.schema.json — 必須欄と任意欄の区別、版が不明なら unknown と書く指示、sandbox の設定の中身が未決であること。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13
-
UK AISI & EvalEval「How UK AISI and EvalEval Are Making Benchmark Results Reproducible」Hugging Face Blog, 2026-09-22. https://huggingface.co/blog/evaleval-aisi — AISI の結果の EEE 形式での公開、再現情報の欠如と再実行の高さ、設計への関与。 ↩ ↩2 ↩3 ↩4
-
UK AI Security Institute「EEE datastore の集約記録(hle・claude-opus-4-6)」(2026-09-25 取得). https://huggingface.co/datasets/evaleval/EEE_datastore/resolve/main/data/hle/anthropic/claude-opus-4-6/2ff53d4b-f449-4458-9ee3-0da16c73d717.json — トークン数の上限を書き、道具の一覧を空、サンドボックスの欄を中身の無いまま出した記録。 ↩
-
UK AI Security Institute「EEE datastore の集約記録(aisi-cyber-ctfs・claude-opus-4-5-20251101)」(2026-09-25 取得). https://huggingface.co/datasets/evaleval/EEE_datastore/resolve/main/data/aisi-cyber-ctfs/anthropic/claude-opus-4-5-20251101/7a54e50e-8c7c-4ade-8109-22280e9b6b74.json — 評価ハーネスの版を unknown としたまま公開された記録。 ↩
この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。