LLMのベンチマークスコアの読み方｜発表資料の数字を自社の判断材料にする前に確かめること

新しいモデルが出るたびに、発表資料には「〇〇ベンチで何%」という数字が並びます。表の一番上に自社モデルが来るように作られているのが普通で、それ自体は宣伝として自然なことです。問題は、その数字を社内の稟議や乗り換え判断にそのまま転記してしまうことです。この記事は、自社でevalを作る方法(別記事)でも、採点の仕組みの解説でもありません。公開ベンチマークの数字を読む側が、判断材料にする前に何を確かめるべきかに絞って整理します。

数字の読み方を具体的にするため、2026年11月7日時点で公式サイト・論文・報道から確認できた次の事実を起点にします。

• SWE-benchの元データは12のPythonリポジトリから集めた2,294件の課題で、2023年10月の初版では、正解のファイルを与える条件(oracle retrieval)でもClaude 2が4.8%、GPT-4が1.7%しか解けず、2024年4月のICLR 2024版では、最も成績のよいClaude 2でも解決率1.96%とされています(arXiv 2310.06770)。
• SWE-bench Verifiedは、そこから人手で確認した500件のサブセットです。公式サイトは、モデル同士を比べる枠で使うmini-SWE-agentのリリース1.x系と2.x系では行動の指定方法が違うため「結果は必ずしも比較可能ではない」と明記しています(温度の設定も、1.x系は0.0、2.x系は指定なしと異なります)。
• The Decoderが2026年2月23日に報じたところでは、OpenAIはSWE-bench Verifiedのスコア報告をやめ、SWE-bench Proを勧めると説明しました。理由として、課題の少なくとも59.4%に機能的に正しい解答を不合格にするテストの欠陥があったことと、課題と解答の一部が主要モデルの学習データに入り込んでいたこと(汚染)を挙げたとされます。OpenAI自身の発表文は確認できていないため、この割合が全件に対するものか、監査した一部の課題に対するものかは、ここでは断定しません。
• 第三者のArtificial Analysisは、現行の総合指数(Intelligence Index v5.0.1)を9つの評価で構成し、MMLU-ProやGPQA Diamond、AIME 2025、MATH-500などを「Legacy Evaluations」の欄に置いています。指数の中身は入れ替わるということです。

まず、ベンチマークの数字は何を測っているか#

ベンチマークは、決まった問題集を決まった手順でモデルに解かせ、決まった基準で採点した結果です。SWE-benchを例にとると、論文の説明では、実際のGitHubのissueとそれを解決したプルリクエストから課題を作り、モデルにコードベースとissueの説明を渡してコードを編集させ、その修正がテストを通るかで解決したかどうかを判定します。

この構造からわかるのは、スコアが「問題集」「解かせ方」「採点基準」の3つすべてに依存するということです。どれか一つが変われば、同じモデルでも数字は変わります。発表資料の表は、この3つのうち「モデル」以外の条件を脚注に小さく書くか、書かないことがよくあります。読む側は、その脚注を探すところから始めるのが確実です。

確かめること1: 測定条件は同じか#

最初に見るのは、数字がどんな設定で出たかです。最近のモデルは、推論にかける量(effortやreasoningの強さ)を段階で指定できるものが増えています。同じモデル名でも、推論を深くすればスコアは上がりやすく、そのぶん出力トークンと時間が増えます。発表資料や報道で、同じモデルについてeffort別の数字が並ぶのはそのためです。最上位の設定の数字と、自社が実際に使うつもりの設定の数字は別物です。

ほかにも、スコアを動かす条件はいくつもあります。

最後の「版」は見落とされやすい点です。SWE-bench Verifiedの公式サイトは、モデル同士を直接比べる枠として、mini-SWE-agentを使い、特別なツールを持たせない最小限のbash環境で評価すると説明しています。そのうえで、リーダーボードのリリース番号はmini-SWE-agentの版を指し、1.x系は出力文字列から行動を読み取り、2.x系はツール呼び出しで行動を指定する違いがあるため、両者の結果は必ずしも比較可能ではないと書いています。温度の設定も、1.x系は(対応するモデルなら)0.0、2.x系は指定なしと異なります。同じベンチ名でも、版が違えば別の物差しになりうるということです。

確かめること2: 自己申告か、第三者の計測か#

発表資料の数字の多くは、開発元が自社で測った値です。開発元は自社モデルに合った設定を選べますし、どのベンチを表に載せるかも選べます。不正という意味ではなく、構造としてそうなるという話です。そこで、同じモデルを第三者が同じ条件で測った結果と突き合わせます。代表的なものを、各サイトの説明で確認できた範囲で挙げます。

• Epoch AI: ベンチマーク結果のデータベースを公開しています。サイトの説明では、Epoch AIが自ら実施した評価と、外部から集めた結果の両方を含みます(2026年11月7日の閲覧時点で、追跡対象は425モデル・97ベンチマーク)。多くのベンチを一つの尺度にまとめたEpoch Capabilities Index(ECI)も出しており、2026年11月4日には不確かさの見積もりを改善するためベイズモデルを使う方式へ更新したと告知しています。
• Artificial Analysis: 方法論のページで、全モデルを同一条件で評価すること、例を与えないゼロショットの指示で評価すること、プロンプトのテンプレートや採点基準を開示することを原則に掲げています。温度は非推論モデルで0、推論モデルで0.6(開発元の推奨があればそれに従う)、採点は原則pass@1と明記しています。
• HELM(Stanford CRFM): 2022年の論文で提案された「総合的な評価」の枠組みです。論文の時点では、正確さだけでなく、較正・頑健性・公平性・バイアス・有害性・効率の計7つの指標を、16の中核シナリオで可能な限り測る多指標の構成で、プロンプトと出力をすべて公開する方針も示していました。現在のリーダーボードの構成は論文の時点から変わっている可能性があるため、使う際は最新のページで確かめてください。

第三者の計測にも読み方の注意があります。Epoch AIのように、自前の計測と外部から集めた値が同じ画面に並ぶ場合は、その数字がどちらなのかを確かめます。Artificial Analysisのように条件を統一している場合は、その統一条件が自社の使い方と同じとは限りません。第三者の数字は「開発元の数字が条件を変えても大きく崩れないか」を見る材料として使い、正解として扱わないのが穏当です。

確かめること3: 汚染と飽和が進んでいないか#

公開ベンチマークには、時間とともに効き目が落ちていくという性質があります。理由は二つです。

一つは汚染(コンタミネーション)です。問題と解答が公開されている以上、それがウェブ経由で学習データに混ざる可能性があります。混ざれば、モデルは解き方ではなく答えを覚えている状態でスコアを伸ばせます。もう一つは飽和です。上位のモデルが軒並み高得点になると、残った数ポイントの差が能力の差なのか、問題集の不備なのか区別しにくくなります。

SWE-bench Verifiedは、この両方が表に出た実例です。2026年2月23日のThe Decoderの報道によれば、OpenAIはSWE-bench Verifiedのスコア報告をやめると説明しました。課題の少なくとも59.4%に、特定の実装の細部を求めるなどの理由で機能的に正しい解答を不合格にしてしまうテストの欠陥があったこと、さらに複数社の主要モデルが元の修正の一部を記憶から再現できたことを挙げ、ベンチの伸びがコーディング能力より「見たことがあるもの」を反映するようになったと述べたとされます。代わりにSWE-bench Proを勧め、非公開のテストも作っていると報じられています。59.4%の分母(全件か、監査した一部か)は、OpenAI自身の発表文を確認できていないため断定しません。

なお、これはOpenAI側の分析です。勧められたSWE-bench Proも公開ベンチである以上、同じように汚染やテストの欠陥がないかを確かめる必要があります。どのベンチが正しいかを決めることより、「広く競われたベンチほど、ある時点から数字の意味が変わる」という一般則として受け取るのが実務向きです。

Artificial Analysisの方法論ページで、MMLU-Pro、GPQA Diamond、AIME 2025、MATH-500といった、かつて発表資料の常連だったベンチが現行指数の構成から外れ「Legacy Evaluations」に並んでいるのも、同じ流れの中で読めます(外した理由は評価ごとに異なりうるため、ここでは断定しません)。発表資料に古い定番ベンチの数字ばかりが並んでいたら、差がつきにくい物差しで比べている可能性を疑ってよいでしょう。

確かめること4: その名前は、どの母集団のことか#

ベンチマークには派生版がよくあります。SWE-benchでいえば、元の2,294件に対して、人手で確認した500件のVerifiedがあります。公式サイトの説明では、Verifiedは問題文が明確か、テストパッチが正しいか、与えられた情報で解けるかを人のアノテーターが確認したサブセットで、OpenAIとの共同で作られました。

母集団が違えば、難易度も分布も違います。元のSWE-benchで30%のモデルと、Verifiedで70%のモデルを比べても、どちらが上かは言えません。Verifiedは「解けない、または採点が不当な問題」を取り除いた集合なので、同じモデルでも元の集合より高い数字が出やすいと考えられます。さらに前節のとおり、人手で絞った集合でもテストの欠陥は残りえます。

確かめること5: コストと時間が書いてあるか#

業務で効いてくるのは、正答率と並んで、1タスクあたりいくらかかり、どれだけ待つかです。推論を深くしたりエージェントに何度も試行させたりすれば、スコアは上がりやすい一方で、トークン消費と所要時間も膨らみます。発表資料の表がスコアだけを載せていたら、その数字を出すのにどれだけの計算をかけたかは分かりません。

第三者の中には、この点を正面から扱うところがあります。Artificial Analysisは方法論のページで、総合指数を走らせるコストを正確に報告するため、各APIの提供元が返すトークン数を使い、キャッシュのヒット率も実測値と組み合わせると説明しています。スコアの横に「この評価を一通り回すといくらかかったか」が並ぶと、数ポイントの差を何倍の費用で買っているのかが見えてきます。

判断の場面では、次のように読み替えると整理しやすくなります。

確かめること6: 自社業務との距離をどう埋めるか#

ここまでの5点を確かめても、最後に残る問題があります。公開ベンチマークは、誰かが選んだ課題の集まりで、自社の業務そのものではありません。SWE-benchはPythonのオープンソースリポジトリの課題で、社内の古いJavaの基幹システムの改修とは違います。ベンチの数字は「似た種類の仕事が得意そうか」の目安にはなっても、自社で何割うまくいくかは教えてくれません。

この距離を埋める現実的な方法が、代表的な業務を数十件集めた小さな自社evalです。公開ベンチで候補を2〜3モデルに絞り、自社evalで同じ条件のまま比べる、という二段構えにすると、ベンチの数字に振り回されにくくなります。

評価データの集め方や採点の作り方は、別記事で詳しく扱っています。採点をLLMに任せる場合の注意も合わせて確認してください。

SWE-benchの課題数・リポジトリ数と解決率はarXiv論文(2310.06770)の初版(2023年10月)とICLR 2024版(2024年4月)、SWE-bench Verifiedの件数・作成の観点・評価方法・版の違いは公式サイト、Epoch AI・Artificial Analysisの方針や数値は各公式ページ、HELMの指標とシナリオは論文(2211.09110)で確認しました(いずれも2026年11月7日時点)。OpenAIがSWE-bench Verifiedの報告をやめた経緯と59.4%という数値は、The Decoderの記事(2026年2月23日)に基づく二次情報で、OpenAI自身の分析です。OpenAIの発表文そのものは確認できていません。第三者のサイトが示す数値や指数の構成は随時更新されます。

よくある質問#

まとめ#

公開ベンチマークは、モデルの得意分野をおおまかにつかむための有用な物差しです。ただし、その目盛りは「どの問題集を、どの条件で、どう採点したか」で決まり、時間とともにすり減っていきます。発表資料の数字は、条件を確かめ、第三者の計測と突き合わせ、費用と時間を横に並べたうえで、候補の足切りに使う。最終的な判断は、自社の代表タスクで測った小さな評価に任せる。この順番を守るだけで、ベンチマークの数字に振り回される場面はかなり減るはずです。