テキスト・画像・エージェントをそれぞれどう測るか — 三つの領域の測定が根本的に違う理由

• はじめに — 同じ言葉で違うものを測っている
• テキスト(1) — 選択式が測るもの、測れないもの
• テキスト(2) — 生成式タスクとLLM審査者
• 画像(1) — 生成品質指標が測っているもの
• 画像(2) — 理解タスクの採点とキャプションの罠
• エージェント — 測定がもっとも難しい領域
  • 部分成功を0と1に押し込める
  • 環境の状態がスコアの一部です
  • 同じモデルが毎回違うスコアを出す
  • 時間とコストの上限がスコアを作る
  • 成功率だけを見ると見落とすもの — 安全な失敗と危険な失敗
• 三つの領域を一枚で
• おわりに — 数字の単位ではなく手続きを問うべきです
• 参考資料

はじめに — 同じ言葉で違うものを測っている

モデルの発表資料には三種類の数字が並びます。MMLU 84.2、MMMU 72.1、SWE-bench Verified 71.4。三つとも百分率で、三つとも高いほど良いと書かれています。だから同じ種類の数字に見えます。

ところがこの三つは測定の構造そのものが違います。

• 一つ目の数字は、たいていモデルに答えを生成させることすらせずに出ます。選択肢の文字列の確率を比較しただけかもしれません。
• 二つ目の数字には人間が定めた正解がありますが、採点ルールに5パーセントの誤差許容や編集距離の閾値のような任意の定数が埋め込まれています。
• 三つ目の数字は、コンテナを立ち上げ、コマンドを実行し、テストを回した結果です。同じモデルをもう一度回すと違う値が出ます。

三つの数字を並べて「このモデルは全領域で強い」と言った瞬間、私たちは三つの違う測定装置を一つの目盛りだと錯覚しています。この記事の問いはずっと同じです。この数字が見た目どおりの意味を持つには、何が真でなければならないか。

ハーネスがこの数字をどう作り出すかはLLMベンチマークツールを分解するで扱いました。ここではその一段上、領域ごとに異なる測定のロジックを見ます。

テキスト(1) — 選択式が測るもの、測れないもの

選択式ベンチマークが好まれる理由は、採点がタダだからです。正解がラベル一つなので、人間も審査者モデルも必要ありません。その代わりに三つを諦めます。

第一に、正解自体が間違っている場合があります。 MMLUを再検証した論文Are We Done with MMLU?は、30科目にわたる3,000問を専門家14人が読み直しました。全体換算した誤り率は約6.49パーセントでしたが、問題はその分布でした。Virologyは標本の57パーセントに誤りがあり(30パーセントは正解ラベルが間違っており、15パーセントは問題自体が曖昧)、Logical FallaciesとCollege Chemistryは20パーセントを超えました。つまりMMLUの総合点のかなりの部分は「間違った正解表にどれだけうまく合わせるか」を測っていたことになります。科目ごとのスコアを平均した瞬間、この事実は完全に消えます。

第二に、形式そのものが近道を作ります。 選択肢が4つなら、当てずっぽうでも25点です。しかもモデルは選択肢どうしの表面的な手がかり(長さ、具体性、消去法の可能性)で正解を絞り込めます。MMLU-Proが選択肢を10個に増やした理由がこれで、その結果プロンプトの変化に対するスコアの変動が4〜5パーセントポイント台から2パーセントポイント台に縮みました(arXiv 2406.01574)。変動が縮んだこと自体が、元の形式がいかに緩かったかの証拠です。

第三に、選択肢の順序がスコアに混ざります。Large Language Models Are Not Robust Multiple Choice Selectorsは、モデルが特定の位置の選択肢記号(AやD)を好む傾向を示し、選択肢の順序を混ぜるだけでスコアが有意に動くことを示しました。順序を混ぜて複数回回し平均を取っていない選択式のスコアは、モデルの知識とモデルの位置の好みが混ざった値です。

指標は高いのに実際には悪い場合(テキスト選択式)。 対数尤度方式で採点したMMLUで高いスコアを取ったベースモデルをそのままサービスに組み込むと、指示に従わず使えないことがよくあります。対数尤度採点はモデルに何も生成させないので、指示に従う能力をそもそも測定対象から除外しています。スコアが嘘をついたのではなく、私たちがそのスコアを別の問いへの答えとして読んだのです。

テキスト(2) — 生成式タスクとLLM審査者

要約、相談への回答、コード説明のように正解が複数あるタスクに移ると、採点そのものが研究課題になります。BLEUやROUGEのようなn-gram重なり指標は、表現が違えば良い答えも減点し、表現が同じなら間違った答えも救ってしまいます。だから実務はLLM審査者へと移りました。

審査者モデルの性能自体は悪くありません。MT-BenchとChatbot Arenaを作ったZheng et al. (NeurIPS 2023)の測定では、GPT-4審査者と人間の専門家の一致率は引き分けを除いて85パーセントで、同じ条件での人間どうしの一致率は81パーセントでした。クラウドソーシング環境では87パーセントでした。審査者は人間より劣るという反論は、この数字の前で力を失います。

問題はバイアスの構造です。同じ論文が測定した値のほうがずっと重いのです。

二つの答えの順序を入れ替えただけなのに、GPT-4でさえ三回に一回は判定を変えます。Claude-v1は四回に三回、先に出てきた答えに軍配を上げました。この状態でA/B比較を一回だけ回して「新しいプロンプトが勝った」と結論づけると、その結論のかなりの部分は順序でした。

長さバイアスも定量化されています。同じ論文の「反復リスト」攻撃 — 回答の中身を増やさずリスト形式に膨らませるだけの操作 — では、Claude-v1とGPT-3.5は91.3パーセントの場合で騙され、GPT-4は8.7パーセントでした。審査者によって長さバイアスの大きさが十倍違います。

緩和策を整理すると次のとおりです。

長さ補正は実際に効果が検証されています。AlpacaEval 2.0の長さ補正勝率は答えの長さの影響を回帰で取り除いた指標ですが、この補正だけでChatbot Arenaの順位とのスピアマン相関が0.9台前半から0.98まで上がりました。裏を返せば、補正前の指標の不一致のかなりの部分が長さだったということです。

人間選好リーダーボードも安全地帯ではありません。The Leaderboard Illusion (arXiv 2504.20879)は、Chatbot Arenaで一部のプロバイダが公開前に複数の変種を非公開で試し、気に入ったものだけを残せたと報告しています。あるプロバイダは27個の非公開変種を試したうえで一つを公開しました。データ配分も均等ではなく、GoogleとOpenAIがそれぞれ全対戦データの19.2パーセントと20.4パーセントを受け取る一方、83のオープンウェイトモデルは合わせて29.7パーセントしか受け取っておらず、追加データだけでアリーナ分布において最大112パーセントの相対的な性能向上が可能だと推定されています。Arena側はこの指摘を受け入れ、改善計画を発表しました。

指標は高いのに実際には悪い場合(生成式)。 審査者の勝率が55パーセントから62パーセントに上がったのに、ユーザー満足度は変わらない状況。プロンプトに「詳しく説明せよ」を加えて回答の長さが1.6倍になったことだけが変化だったなら、上がったのは品質ではなく審査者の長さへの選好です。長さ補正勝率と一緒に見なければ、この区別はできません。

画像(1) — 生成品質指標が測っているもの

画像生成評価でもっとも広く引用されるFIDは、名前に反して画像一枚の品質を測っていません。計算手順はこうです。

1. 実画像N枚、生成画像N枚を用意(慣例上N = 50,000)
2. 各画像を299x299にリサイズしてInception-v3に通す
3. pool3層の2048次元特徴ベクトルを取り出す
4. 両方の集合の特徴をそれぞれ多変量正規分布と「仮定」し、平均と共分散を推定
5. 二つの正規分布間のFrechet距離を計算 → この値がFID(低いほど良い)

ここに四つの仮定が隠れており、四つとも破られます。

仮定1: Inception-v3の特徴が画像品質を代表する。 Inception-v3は2015年にImageNetの1,000クラス分類用に学習されたモデルです。今日のテキスト画像モデルが作り出す内容の多様性を表すには狭すぎます。

仮定2: 特徴が正規分布に従う。 そうではありません。Rethinking FID (CVPR 2024, arXiv 2401.09603)はこの仮定が誤りであることを示し、FIDが人間評価者の判断とずれており、反復改良されるモデルの漸進的な向上を反映せず、歪みの程度を捉えられず、標本サイズによって結果が一貫しないとまとめています。代替案としてCLIP埋め込みと最大平均差異を使うCMMDを提案しています。

仮定3: 標本サイズの影響がない。 FIDは偏った推定量なので、標本が小さいほど値が大きくなります。50,000枚という慣例が固まったのもこのためで、論文ごとに標本数が違えば数字を比較できません。

仮定4: 前処理は中立である。 ここがもっとも衝撃的な部分です。clean-fid (CVPR 2022)は、リサイズの実装がライブラリごとに異なり、同じ画像から違うFIDが出ることを測定しました。正しく実装されたPIL bicubicを基準にすると、OpenCV、PyTorch、TensorFlowのbicubicはそれぞれ6以上のFID差を生みました。モデルをまったく変えず、リサイズ関数だけを変えても、論文が誇る改善幅より大きな差が出ます。 JPEG圧縮も同様で、人間の目には区別できない圧縮品質の差がFIDを動かします。

そのため最近のテキスト画像評価は、分布距離から構成要素の検証へと移っています。GenEvalは物体検出器を使い、「要求した物体が実際にあるか、個数は合っているか、色は合っているか、位置関係は合っているか」を項目ごとに確認します。DPG-Benchは段落規模の密なプロンプトを与え、VQAモデルで各意味要素を確認します。採点の根拠が人間に読める項目であるという点で、FIDよりはるかに診断的です。もちろんこの方式は、検出器とVQAモデル自体の誤差をそのまま採点に持ち込みます。

指標は高いのに実際には悪い場合(画像生成)。 FIDが12.4から9.8に「改善」したのに、人間評価はむしろ悪化した場合。前処理パイプラインでリサイズライブラリを変えたか、参照画像セットのJPEG品質が変わったことが原因かもしれません。FIDの値を報告する際、リサイズ実装・標本数・参照セットを併記しなければ、その数字は他のチームが検証できません。

画像(2) — 理解タスクの採点とキャプションの罠

画像を作るのではなく読む能力の評価は、テキスト選択式に似て見えますが、採点ルールにドメイン特有の事情が埋め込まれています。代表的な三つの指標の定義をそのまま見てみましょう。

VQA正解率 (VQAv2, TextVQA)
  score = min(その答えを言った人数 / 3, 1)
  → 10人中3人以上が同じ答えをしていれば満点。
    人々の答えが割れる問題は満点自体が不可能。

ANLS (DocVQA)
  NL = 正規化編集距離(予測, 正解)
  score = 1 - NL   (ただし NL < 0.5 のとき)
        = 0        (それ以外)
  → OCRの誤字一、二文字は部分点、半分以上間違えば0点。
    閾値0.5は「これだけ間違えばOCRの誤りではない」という判断。

Relaxed accuracy (ChartQA)
  数値の答えは相対誤差5%以内なら正解
  → チャートから値を読み取るタスクの現実を反映した許容。
    同時に、5%が重要なドメインでは間違った答えを正解扱いしてしまう。

三つの定義はどれも合理的です。同時に三つとも任意の定数を抱えています。3人、0.5、5パーセント。これらの定数は論文のなかでは正当化されていますが、あなたのドメインで同じ値が適切だという保証はありません。財務諸表の数字を読むサービスなら、ChartQAの5パーセントの許容は災いです。ChartQAで90点のモデルがあなたのタスクでは使えないことがあり、それはモデルのせいではなく、指標をそのまま持ち込んだ私たちのせいです。

選択肢数の問題はここでも繰り返されます。MMMU-Pro(arXiv 2409.02813)はMMMUの選択肢を4個から10個に増やし、質問文自体を画像のなかに埋め込んで、実際に画像を見なければ解けないようにしました。選択肢を増やしただけでGPT-4o(0513)のスコアは64.7から54.0へ、10.7パーセントポイント落ちました。その10.7点は理解力ではなく消去法だったということです。

キャプション評価はさらに古い罠です。CIDEr、SPICE、BLEUは参照キャプションとのn-gramまたはグラフの重なりを測りますが、参照キャプションはふつう5個しかなく、表現が少し違うだけでスコアが落ちます。CLIPScore (EMNLP 2021)は、参照なしで画像とキャプションの埋め込み類似度だけのほうが人間の判断とよく合うことを示しました。ただし同じ論文は限界も明示しています。ニュース写真のキャプションのように画像の外の文脈知識が必要な場合には、参照ベースの指標より弱いのです。万能な指標は存在せず、キャプションタスクの性質に応じて指標を選ばなければなりません。

指標は高いのに実際には悪い場合(画像理解)。 DocVQAのANLSが0.91の文書パーサーを契約書の金額抽出に組み込んだところ、事故が起きました。ANLSは編集距離ベースの部分点なので、「1,250,000」を「125,000」と読んでも編集距離が小さく0.9前後のスコアを得ます。金額フィールドは部分点ではなく完全一致で測らなければなりません。指標が部分点を与えるタスクなのかどうかを、まず確認する必要があります。

エージェント — 測定がもっとも難しい領域

前の二つの領域は、入力一つに出力一つが対応します。エージェントはそうではありません。入力一つに数十回の行動が対応し、その行動が環境を変え、環境が変わると次の行動の意味も変わります。ここでは測定の前提の大半が崩れます。

部分成功を0と1に押し込める

エージェントのタスクはほとんどが複数ステップです。10ステップ中9ステップを完璧にこなし最後で失敗した実行と、最初のステップからつまずいた実行が、同じ0点になります。情報の損失が大きいのです。

この問題への対処はベンチマークごとに違います。AppWorldは最終状態を検査しつつ、タスク単位の完了とシナリオ単位の完了を分けて報告します。GAIAは難易度レベルを分け、どの層で崩れるかが見えるようにします。OSWorldはタスクごとに実行ベースの検証スクリプトを別に用意し、「結果ファイルが実際にこう見えるか」を確認します。いずれにせよ、単一の成功率だけを引用すると、この構造は丸ごと消えます。

環境の状態がスコアの一部です

エージェントベンチマークは生きた環境を使います。ウェブページのDOMが変わり、ソフトウェアが更新され、CAPTCHAが出て、読み込みが遅くなります。この変化はモデル性能とは無関係なのに、スコアにはそのまま反映されます。

OSWorldチームが2025年7月28日にOSWorld-Verifiedを出した理由がこれです。300件以上の問題報告 — ウェブ構造の変更、タイミング依存、タスクの曖昧さ、複数の正解経路を認めない検証関数、厳しすぎるまたは緩すぎる採点 — を確認して直しました。つまりそれ以前に発表されたOSWorldのスコアは、かなりの部分で環境の状態を測っていたことになります。現在の人間の基準は約72パーセントと推定され、最上位システムは60パーセント台です。

SWE-bench系列は別の形で同じ問題に直面します。採点が実行ベースなので意味的に強く見えますが、テストが弱ければ間違ったパッチも通ります。SWE-benchの品質を監査した研究は、成功したパッチの32.67パーセントがイシューの説明に答えが漏れていたケースで、31.08パーセントはテストが不十分だったために通過したと報告しています。SWE-bench Verifiedでも15パーセント以上のインスタンスでテストの補強が必要で、リーダーボードの成功率が6〜7パーセントポイント水増しされているという推定が出ています。

同じモデルが毎回違うスコアを出す

温度を0にしても、エージェントの実行は決定的ではありません。ツール呼び出しの順序、ネットワーク遅延、タイムアウト、リトライ、コンテナのリソース — すべてが結果を変えます。

τ-bench系列はこの非決定性を指標に直接組み込みました。pass@kが「k回のうち一回でも成功」なら、pass^kは「k回すべて成功」です。成功率がpのタスクでは、pass^kはおよそpのk乗まで縮みます。成功率90パーセントのエージェントでも、kが8なら0.9の8乗、つまり約43パーセントまで落ちます。裏を返せば、8回のうち少なくとも一回は失敗する確率が約57パーセントあるという意味です。この二つの数字を取り違える間違いはよくあるので、どちらを言っているのか常に確認してください。τ-bench原論文の報告では、当時最上級の関数呼び出しエージェントでもタスクの半分すら解けず、retailドメインのpass^8は25パーセント未満でした。

この指標が重要な理由は、実運用の問いがpass@kではなくpass^kだからです。顧客の依頼一つを八回やり直して一回成功すればよい、というサービスは存在しません。

インフラ設定もスコアを動かします。Anthropicの測定によれば、モデルの重みにはまったく手を触れず実行リソースだけを調整しても、Terminal-Bench 2.0で6パーセントポイントの差が出ました。詳細はシグナルとノイズの記事にまとめてあります。参考までに、Terminal-Bench 2.0は2025年11月に89タスクで公開され、Harborフレームワークの上で動きます。

時間とコストの上限がスコアを作る

エージェント評価には必ず上限があります。最大ステップ数、壁時計時間、トークン予算。この上限を二倍にすればスコアは上がり、半分にすれば下がります。ところが発表されるエージェントのスコアで、この上限を見つけられるケースはまれです。

上限が明示されていない二つのスコアの比較は無意味です。もっと正確に言えば、その比較はモデルの能力ではなく予算の比較である可能性があります。実務でエージェントを選ぶときは、スコアの横に「タスクあたりの平均トークン数」と「タスクあたりの平均所要時間」を必ず一緒に見る必要があります。成功率が5パーセントポイント高くてもコストが三倍なら、それはより良いモデルではなく、より高価な設定です。

成功率だけを見ると見落とすもの — 安全な失敗と危険な失敗

ここがエージェント評価でもっとも測定が手薄な部分です。成功率は失敗をひとまとめに扱います。しかし実務では、失敗の種類は天と地ほど違います。

安全な失敗                            危険な失敗
------------------------------      ------------------------------
「できません」と言って止まる          確信ありげに間違った答えを返す
人に確認を求める                      確認なしに取り消せない操作を実行
読むだけで終了                        間違った対象に書き込んでから終了
予算超過で中断                        部分修正のあと中断(状態が壊れる)
テストの失敗を報告                    テストを書き換えて通す

成功率指標では、この十個すべてが同じ0点です。ところが右の列はサービスを壊し、左の列は人が引き継げばよいだけです。

有害な行動を直接測るベンチマークも登場しました。AgentHarm (arXiv 2410.09024)は詐欺・サイバー犯罪・嫌がらせなど11の有害カテゴリで、明示的に悪意あるエージェントタスクを110個(拡張を含めて440個)作り、拒否したかどうかと同時に「脱獄させられた後も能力を保持しているか」を測ります。報告された数値は居心地が悪いものです。GPT-4oは脱獄なしでも有害タスクの48〜55パーセントを完遂し、汎用の脱獄テンプレートを適用すると遵守率が73パーセントに上がり、拒否率は49パーセントから14パーセントに落ちました。

ここで指標の向きが逆転します。AgentHarmではタスク完遂率が高いほど悪いのです。成功率を無条件に高いほど良い値と読む習慣が、いかに浅い前提の上にあったかが露呈する地点です。

指標は高いのに実際には悪い場合(エージェント)。 SWE-bench Verifiedのスコアが5パーセントポイント上がった新しいモデルを導入したら、レビューの負担が増えた場合。新しいモデルがテストを通すためにテスト自体をいじっていたり、イシューに漏れていた答えを再生産していたりしたら、ベンチマークのスコアは上がり、実際の価値は下がります。成功率と一緒に「失敗したときどう失敗したか」を分類して数えなければ、この区別は見えません。

三つの領域を一枚で

この表で繰り返されるパターンが一つあります。すべての指標は、何かを計算可能にするために何かを捨てました。 捨てたものが自社サービスにとって重要なら、その指標は使い物になりません。指標を選ぶことは「何を捨ててよいか」を選ぶことです。

おわりに — 数字の単位ではなく手続きを問うべきです

三つの領域を見渡すと共通点が見えてきます。どの領域でも、指標は能力を直接測っていません。能力の影を、しかも特定の照明のもとで測っています。選択式は正解ラベルの正確さと選択肢構成という照明のもとで、FIDはInception特徴空間とリサイズ実装という照明のもとで、エージェントの成功率は環境状態と資源上限という照明のもとで。

だから実務で新しいベンチマークの数字に出会ったら、問うべきは「何点か」ではなく三つのことです。第一に、このスコアはどんな手続きで計算されたか。 第二に、その手続きが捨てたもののなかに、自社にとって重要なものはあるか。 第三に、同じ手続きを自社のデータに適用すると何が出るか。

三つ目の問いが結局、自前の評価セットへとつながります。その話は自社サービス向け評価セットを作るで続けます。

参考資料

• Are We Done with MMLU? (arXiv 2406.04127) — MMLU誤り率の再検証
• MMLU-Pro (arXiv 2406.01574) — 選択肢拡大とプロンプト感度
• Large Language Models Are Not Robust Multiple Choice Selectors (arXiv 2309.03882)
• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (arXiv 2306.05685) — 審査者一致率とバイアスの測定
• Length-Controlled AlpacaEval (arXiv 2404.04475) — 長さ補正勝率
• The Leaderboard Illusion (arXiv 2504.20879) — アリーナリーダーボードの構造的バイアス
• Rethinking FID / CMMD (arXiv 2401.09603)
• clean-fid (CVPR 2022) — リサイズ・圧縮がFIDに与える影響
• GenEval (arXiv 2310.11513) — 物体ベースのプロンプト忠実度評価
• MMMU-Pro (arXiv 2409.02813)
• CLIPScore (arXiv 2104.08718)
• OSWorld-Verified (2025-07-28) — 環境変化がスコアに与えた影響
• τ-bench (arXiv 2406.12045) — pass^k指標
• AgentHarm (arXiv 2410.09024) — 有害な行動を直接測るベンチマーク
• LLMベンチマークツールを分解する(関連記事)
• AIコーディングモデル評価におけるシグナルとノイズの見分け方(関連記事)
• ブラウザ・コンピュータを操作するAIエージェント(関連記事)