AIの性能ベンチマークって、その数字は何の割合なん？｜読み方の基本
AIの性能ベンチマークで「30.4%」「1588」と書かれていても、それが何の数字なのか分かりにくいままになっています。この記事では、パーセントの3つの型（正答率・pass@1・部分点なしの全条件クリア）と、Arenaのスコアがパーセントではない理由を、公式の採点方法から説明します。数字を見たときに確認する5つの項目まで持ち帰れます。
新しいモデルが出るたびに、「ベンチマーク最高スコア」という言葉が流れてくる。「30.4%で1位」「1588」「65%」。数字は並ぶのに、それを見て「へえ、すごいんやろな」で終わってる人がほとんどやないか。
その数字、何を分母にした割合か答えられる？30.4点は100点満点の30.4点なんか、それとも別の数え方なんか。1588は点数なんか、順位なんか。答えられへんのは、あなたの理解が足りひんからやない。単に、説明されてへんかっただけや。
この記事は、指標の名前を1つも覚えんでも、ベンチマークの数字そのものが読めるようになる回にする。パーセントの正体、部分点のあるなし、Eloに見える数字の中身、そして同じベンチマーク名でも数字が変わる理由まで、全部持って帰ってもらう。
そもそも、AIは1つの試験を受けてるんやない
「MMLUで90%」と「AutomationBenchで30%」。この2つの数字は、同じモデルの中で普通に両立します。矛盾しているわけやない。
理由は単純です。AIは1つの共通試験を受けているわけやない。何十種類もの、まったく別の試験を、バラバラに受けとる。ある試験は知識を問い、ある試験はコードを書かせて実際に動かし、ある試験は業務アプリを最後まで操作させる。試験の中身が違えば、同じモデルでも点数はまったく違う値になる。テストの設計者が違えば、何を「できた」と判定するかの基準そのものが変わるんやから、当然の結果や。
陸上競技に例えると分かりやすいです。100m走の記録とマラソンの記録を、1つの「運動能力」という指標にまとめることはできません。100mが9秒台でも、42.195kmを走り切れるとは限らへんし、その逆もある。「運動能力が高い」とひとことで言えないのと同じで、「AIの性能が高い」も、どの試験の話かを外したら意味を持たへん。
だから、ベンチマークの数字を見るときにまず要る質問は「その数字、良いか悪いか」やなくて「その数字、何を測った試験の結果か」になる。ツールを選ぶときも同じです。長文の記事を書かせたいのに、コード修正系の試験の点数だけを見て選んでも、実際の作業では期待したほど差が出ないことがあります。自分がやらせたい作業に近い試験を、先に見つけておく必要があります。次の章から、実際の数字を1つずつ開けていく。
数字を比べる前に、まず「同じ試験か」を確認する。それだけで、9割の誤読は避けられる。
「30.4%で1位」が弱そうに見える理由
Zapierが作った業務自動化ベンチマーク、AutomationBenchを教材にします。公開セットは600タスクです。47の疑似SaaSアプリと約500のAPIエンドポイントを使い、Sales・Marketing・Operations・Support・Finance・HRの6分野にまたがります。実際の業務ツールを模した環境で、AIエージェントに一連の作業をやらせて採点する仕組みです。「メールを送る」「請求書を発行する」のような単発の指示やなく、複数のアプリをまたいだ一連の業務フローを最後まで通せるかを見ています。
採点方法が、この数字を読むうえでの核心になる。AutomationBenchは決定論的な最終状態アサーションで採点していて、LLMによる採点は使わへん。人間が「なんとなく良さそう」と判断するんやなく、あらかじめ決められた条件(データベースにこの値が入っているか、このメールが送られたか、この設定が変更されているか)を、プログラムが機械的にチェックする。判定にあいまいさが入り込む余地がないぶん、数字の信頼性は高くなる。
主指標はtask_completed_correctlyです。この指標には部分点がありません。採点対象のアサーションが全部通って、はじめて1点になります。10個のアサーションのうち9個を満たしても、1個抜けたら0点です。診断用にpartial_credit(通過したアサーションの割合)という値も出ますが、これは順位には使われません。「惜しかったタスク」は、この採点方式では「失敗したタスク」と同じ扱いになるということです。
Gemini 3.7 Flashは、このAutomationBenchでZapier公式リーダーボード(v1.0.6)30.44%を記録し、1位になりました。これを「3割しかできない」と読むと、採点方法を見落としてる。正しくは「業務ルールを一つも破らずに、最後までやり切ったタスクが3割あった」という意味や。途中で1つでもミスがあれば0点になる採点方式のもとでの3割は、部分点方式の3割とは重みがまったく違う。他の分野のベンチマークで見かける「80%正解」のほうが、実はゆるい採点をしている場合すらあります。
「1位なのに低い数字」を見たら、まず採点に部分点があるかどうかを確認する癖をつけとくとええで。
パーセントには3つの型がある
ここまでの話を整理すると、AIベンチマークの「%」には、少なくとも3つの型がある。
| 型 | どういう数え方か | 代表例 |
|---|---|---|
| 正答率（accuracy） | 問題数のうち、正解した数の割合 | MMLU、GPQA、MMMU |
| pass@1 | 1回目の挑戦で成功した割合。生成したコードを実際に動かして判定する | SWE-bench系、Terminal-Bench |
| 全条件クリア率 | 部分点なし。決められた最終状態を全部満たして、はじめて1点 | AutomationBench、τ-bench |
同じ「%」という記号を使っていても、数え方はまったく違います。正答率は単純に「何問中、何問正解したか」。pass@1は「実際に動かして1回目で成功したか」。全条件クリア率は「1つでも条件を破ったら0点」。この3つを同じ物差しで比べたら、正しい比較にはなりません。「正答率80%のモデルより、全条件クリア率30%のモデルのほうが劣っている」と早合点するのが、いちばんよくある誤読の型です。母数の数え方がそもそも違うのやから、数字の大小をそのまま比べる意味がありません。
pass@1は「1回目で成功したか」
pass@1は、コード生成系のベンチマークでよく出てくる指標です。AIが生成したコードを実際に動かして、テストが通るかどうかで判定します。ポイントは「1回目の生成で」という条件が付いていることです。
何度も生成し直せる条件なら、当たるまで繰り返せばスコアは上がります。それでは「実力」を測れたことになりません。pass@1は、1回勝負に絞ることで、その回避策を防いでいます。逆に言うと、同じベンチマークでも「pass@5」(5回のうち1回でも通ればOK)のような別条件で測った数字は、pass@1の数字とはそもそも比較できません。試験の名前だけやなく「@」の後ろの数字まで見て、はじめて同じ条件かどうかが分かります。ここも「同じ名前の指標でも、条件を見ろ」の一例になる。
1588はパーセントやない
続いて、パーセントの形をしていない数字の話に移ります。LMArena(旧Chatbot Arena。2026年1月から「Arena」に名称変更)で見かける1588のような数字です。
LMArenaは、カリフォルニア大学バークレー校のLMSYS Orgが2023年4月に公開した、ユーザー投票型のAI比較サービスや。2つのモデルの回答を見比べて、どちらが良いかを投票する。この累計投票数は、2026年6月時点で全プラットフォーム合計8,200万票を超えている。
この投票データから強さを算出する計算方法は、Eloそのものではなく、Bradley-Terryモデルになる。対戦の勝ち負けから強さを逆算する統計的な計算で、ロジスティック回帰による最尤推定を使う。ここに、係数へ400を掛けて1000を足すという人為的な変換がかけられている。理由は公式に説明されていて、チェスのEloレーティングと同じ数値レンジに収めるためや。
つまり1588という数字そのものに絶対的な意味はありません。意味を持つのは、他のモデルの数字との「差」だけです。
差を勝率に直す式
差を、読者が実感できる形に翻訳する式がこれや。
Aの勝率 = 1 / (1 + 10^((R_B − R_A) / 400))RAとRBは、それぞれのモデルのスコアです。この式に当てはめると、100点差はおよそ勝率64%、200点差はおよそ勝率76%になります。1588という数字を単体で見るんやなく、比べたい相手との差を出して、この式に入れる。それでようやく「パーセントやない数字」が、日常語の勝率に変わる。
ちなみに、LMSYSが2023年12月7日の公式ブログでオンラインEloからBradley-Terryへ切り替えた理由も書いておきます。オンラインEloは対戦1回ごとにスコアを更新するため、同じ結果でも対戦の順番が違うとスコアがずれてしまいます。Arenaは全対戦履歴を保持していて、モデルの強さは時間で変わらないという前提が置けるため、一括で最尤推定するほうが理屈として正しくなります。この変更の副作用として、投票数がまだ少ない新しいモデルは信頼区間が広く出るようになりました。新モデル発表直後の順位は、まだ揺れる余地があるということです。
新しく出たモデルのランキング、発表直後に一喜一憂せんでもええ。信頼区間が狭まるまで、ちょっと待ってからでも遅くない。
同じ名前でも、中身が違う
数字が読めるようになったところで、次の落とし穴に行く。同じベンチマーク名でも、バージョンが違えば数字が大きく動くという話や。
題材はSWE-bench。プリンストン大学などが2023年10月に発表し、ICLR 2024で採択された、コード修正タスクのベンチマークになる。12のリポジトリにある約90,000件のプルリクエストから、Issueを解決してテストを変更したものを抽出して、2,294件の問題を作った。
2024年8月、OpenAIがこのオリジナル版に大がかりな検証をかけた。1,699件をランダム抽出し、93名の経験あるPython開発者が人手でレビューした。その結果が、SWE-bench Verifiedという別バージョンとして公開されている。
レビューで見つかった問題は2種類ありました。Issueの記述が不十分で、何を直せばいいか正しく伝わらない問題が38.3%。テストの条件が厳しすぎて、実質的に正しい解答まで不正解として弾いてしまう問題が61.1%。この結果、オリジナルの68.3%が除外され、残った500件がSWE-bench Verifiedになりました。
同じ「SWE-bench」という名前でも、母集団が3分の1以下に絞り込まれています。母集団の質が違えば、そこで測った数字が動くのは当然の結果です。A社の記事に「SWE-bench 65%」、B社の記事に「SWE-bench 48%」と書いてあって驚いた経験があるなら、その原因はだいたいここにあります。数字を見るときは、ベンチマーク名の後ろにバージョン名が付いているかを、まず確認する習慣をつけるとええ。
揃ってへんのは、バージョンだけやない
条件の食い違いは、バージョン以外にもいくつもあります。reasoning effort(推論にどれだけ計算を割り当てるかの設定)を変えれば、同じモデルでも数字は変わります。外部ツールの使用を許可するかどうかでも変わります。1回勝負か、複数回試して良い方を採るかでも変わります。機械的な判定かLLMによる判定かでも、基準の厳しさが変わります。
そして見落としがちなのが、メーカーが自社発表した数字と、第三者機関が独立に測り直した数字を、同じ表の中で混ぜてしまうことです。発表の主体が違えば、テスト条件の公開度も検証のしやすさも違います。混ぜて比較した表を見かけたら、それぞれの数字がどちらの立場から出たものかを、まず分けて考えるとええ。実行環境のスペックや、タイムアウトの設定時間まで揃えて比べている記事は、実はそう多くありません。
比較表を作る側にとって、条件を全部揃えるのは手間がかかります。手間を省いた表がすべて悪いわけやないけど、「この表、条件は揃ってるんかな」と一度立ち止まる癖があるだけで、読み間違いはかなり減ります。
テストにも寿命がある
ベンチマークは、作られた瞬間から時間とともに劣化していきます。上位モデルがほぼ全問正解に近づくと、モデル同士の差が見えなくなるからです。この状態を飽和と呼びます。
MMLUはすでに飽和しています。Humanity’s Last Examの論文(2025年1月公開)は、LLMが現在MMLUのような人気ベンチマークで90%超を達成していると明記していて、Artificial Analysisの現行評価一覧からもMMLUは外れています。GPQA Diamondもほぼ飽和状態で、上位モデルは94%台に達しています。この数字は、専門家の正答率65%を大きく上回っています。AIME 2025に至っては完全に飽和していて、上位モデルは満点を取っています。
一方で、まったく飽和していない指標もあります。AA-Omniscienceは、満点100点に対して2026年8月時点の最高スコアが43にとどまっています。「昔から有名なテストで高得点」という情報は、いまのモデル比較の材料にはならへん。どの指標がまだ差を測れているかを、都度確認する必要があります。上位モデルが軒並み90%を超えている指標を見かけたら、それは「差が付きにくくなってきた指標」やと思って、他の指標も合わせて見る方が安全です。
問題がネットにあると、測れへんくなる
ベンチマークにはもう1つ、寿命を縮める要因があります。データ汚染です。問題がWeb上に公開されていると、モデルの学習データに問題そのものか類似問題が紛れ込む可能性があります。そうなると「推論して解いた」のか「見たことがあった」のかが、区別できなくなります。
対策として実際に行われていることが、いくつかあります。AIMEは年号つきで呼ばれます(「AIME 2025」のように)。理由は、その年に出た新作問題を使えば、過去の学習データに含まれている心配がないからです。SWE-bench Proは、コピーレフト(GPLなど)ライセンスのリポジトリを意図的に選んでいます。MIT・Apacheのような寛容ライセンスのコードは、AIの事前学習コーパスに広く取り込まれやすいという理由があります。HLEは、公開している2,500問とは別に、非公開のホールドアウトセットを保持していて、モデルがベンチマークに合わせて過学習していないかを検出する仕組みを持っています。
対策そのものが、なぜその対策が必要なのかの説明になっとる。年号つきの名前を見たら、それはただの命名規則やなくて、汚染対策のサインやと思ってええ。逆に言うと、年号もバージョンも付いていない古いベンチマーク名だけで語られている記事を見かけたら、汚染や飽和への対策がどこまで取られているか、一段慎重に見る価値があります。
うちの仕事、3つ書き出してみよか
ここまでで、数字の読み方の骨格はそろった。あとは、あなたの仕事に当てはめる番になる。
わしの場合、よくやる仕事は3つある。長文の記事を書くこと。リサーチして事実を集めること。作ったプログラムの不具合を直すこと。この3つに、それぞれどの試験が効いてくるかは、このシリーズの第2回以降で1つずつ埋めていく。仕事を先に書き出しておくと、次回以降で指標の名前が出てきたときに「これは自分の①に関係ある」「これは関係ない」がその場で判断できます。指標の一覧を先に丸暗記するより、この順番のほうが結局早いです。
同じことを、あなたの仕事でもやってみてほしい。下の表に、自分がよくやる仕事を3つ書き出してみてな。今すぐ全部埋まらんでも大丈夫。「①に効く試験は？」の列は、次回・次々回を読んだあとに戻ってきて埋めればええ。
| 確認項目 | AI大将の場合 | あなたの場合 |
|---|---|---|
| よくやる仕事① | 長文の記事を書く（SNS投稿の下書きも） | ______ |
| よくやる仕事② | リサーチする | ______ |
| よくやる仕事③ | 作ったプログラムを直す | ______ |
| ①に効く試験は？ | 第2回・第3回で埋まる | ______ |
| ②に効く試験は？ | 第2回・第4回で埋まる | ______ |
| ③に効く試験は？ | 第3回で埋まる | ______ |
この表、スクショでも保存でもしといてや。第5回まで、ずっと同じ表を使い回すことになる。
数字を見たときの5つの確認
ベンチマークの数字を見かけたら、次の5つを順番に確認する。
- 何の割合か：正答率か、pass@1か、全条件クリア率か。母数の数え方を確認する
- 部分点はあるか：部分点ありの数字と、部分点なしの数字は、同じ%でも重みが違う
- どのバージョンか：ベンチマーク名の後ろにバージョン名（Verifiedなど）が付いているか確認する
- 誰が測ったか：メーカーの自社発表か、第三者機関による独立評価か
- 何問あるか：問題数が少ない指標は、1問あたりの重みが大きく、誤差が出やすい この5つを確認するだけで、数字単体を眺めているだけでは見えへんかった中身が、だいたい見えてくる。5つ全部を毎回調べる必要はありません。数字を見て「お、これは良さそうやな」と反射的に判断しそうになった、その一瞬だけ思い出せれば十分です。慣れてくると、記事の見出しに数字が出た時点で、ある程度どのタイプの数字かの見当がつくようになります。
やってしまいがちな読み方
数字に慣れてきたころに、逆にやりがちな誤読が4つある。
- 違う試験の%を引き算する：MMLUの90%とAutomationBenchの30%を引いても、何の意味もない数字が出るだけ
- Eloをパーセントとして扱う：1588は点数やない。差を勝率に直す式を通さないと、比較にならへん
- 問題数の少ない指標で、1〜2ポイント差を語る：GPQA Diamondは198問しかない。1問正解が変わるだけで、約0.5ポイント動く。小さい差を騒ぐ前に、問題数を確認する
- 古いテストの高得点で、いまの実力を判断する：MMLUやAIME 2025のように飽和した指標の高得点は、いまのモデル同士の差を映していない この4つのどれかをやると、正しい情報を持っていても、間違った結論に着地してしまう。
よくある質問
Q. ベンチマークの点数が高いモデルを選べば間違いないですか。 A. その点数が、自分の使い方に近い試験のものかどうかによります。コードを書かせたいのに、知識系ベンチマークの点数だけを見て選ぶと、実際の作業では期待通りの結果にならないことがあります。まず自分の仕事に近い試験を選んでから、そこでの点数を比べる順番が有効です。
Q. 同じベンチマークなのに、サイトによって数字が違うのはなぜですか。 A. バージョンの違い（オリジナルとVerifiedなど）、reasoning effortやツール使用可否といった実行条件の違い、メーカー自社発表と第三者評価の違いが主な原因です。数字だけでなく、どの条件で測ったかまで確認すると、食い違いの理由が分かります。
Q. パーセントではないスコアは、どう読めばいいですか。 A. LMArenaのようなスコアは、単体の数値ではなく他のモデルとの差で読みます。差を勝率に変換する式を使えば、100点差でおよそ勝率64%、200点差でおよそ勝率76%というように、直感的な数字に翻訳できます。
Q. 昔から有名なMMLUは、もう見なくていいのですか。 A. MMLUは上位モデルが90%超に達していて、いまのモデル同士の差を測る指標としては役割を終えつつあります。新しいモデルを比べる場面では、まだ飽和していない指標（AA-Omniscienceなど）や、自分の用途に近い指標を優先して見る方が実情に合います。
Q. メーカーが自分で発表した数字は信用できますか。 A. 発表そのものが虚偽というわけではありませんが、テスト条件を自社に有利な形で選んでいる可能性はあります。可能な限り、第三者機関が独立に評価した数字と突き合わせて確認する習慣をつけると安心です。
Q. エンジニアではないのですが、ベンチマークを見る意味はありますか。 A. あります。この記事で扱った5つの確認項目は、コードを読む必要がなく、数字の見方だけで使えます。自分の仕事に近い試験を選び、部分点の有無とバージョンを確認するだけで、ツール選びの精度は上がります。
次回から、名前を1つずつ
この回では、あえて指標の名前をほとんど出さんかった。MMLU、GPQA、そのほかの個別の名前は、次回からになる。
第2回では、知識と推論を測る8つの指標を、この回で覚えた読み方を使いながら1つずつ開けていく。「何の割合か」「部分点はあるか」「どのバージョンか」。この3つの質問を持って、次に進んでや。
