LLMベンチマーク：リーダーボードの見方（MMLU、Arena、 SWE-bench)

#ベンチマークがなぜ重要なのか（そしてなぜ誤解を生むのか）

LLMベンチマークとは、答えが既知の質問セットをモデルに提示し、正解した数を数えるものです。結果はスコアです。パーセンテージ、Eloレーティング、解決率などです。これは、数時間かけて自分でテストせずに2つのモデルを比較できる唯一の共通言語であり、そのため誰もがこれを使用しています。

問題はベンチマークの考え方そのものではなく、スコアが示すことと、そこから読み取ってしまうことの間にある隔たりです。MMLUで90％を記録するモデルは、「知能が90％ある」わけではありません。学術的な知識を問う選択式テストの問題の90％に正しく答えるということです。それだけでは、指示に従えるか、正しいフランス語を書けるか、あなたの専門分野でハルシネーションを起こさないか、10ターンの会話を続けられるかについては何も分かりません。ベンチマークは、実験室の条件下で限定された能力を測るものです。

ベンチマークは、測定対象が異なり、取り扱い方も異なる 3 つの主要なカテゴリに分類できます：学術的なベンチマーク（知識と推論の多肢選択式問題）、実際のタスクのベンチマーク（実際のバグの修正、ツールの使用）、そして人間の好みに基づくアリーナ（人間が最良の回答に投票する）。順番に検討していきましょう。

#学術ベンチマーク：MMLU、GPQA、MATH

これは昔からある種類のベンチマークで、モデルのリリースページに掲載されるスコア表でよく見かけるものです。正解を検証できる問題の集合で、多くは選択式であり、自動採点されます。強みは再現性ですが、弱点はスコアが頭打ちになりやすく、評価データが学習データに混入しやすいことです。

MMLU

Massive Multitask Language Understanding：法律、医学、歴史、数学など57科目にわたる約14,000問の選択式問題で構成されています。最もよく引用される知識評価ベンチマークです。現在はほぼ飽和しており、優秀なモデルは88〜90％を超え、モデル間の差はノイズの範囲に収まります。

MMLU-Pro

MMLUの難易度を高めた版です。選択肢は4個ではなく10個で、より難しくなるよう問題を選び直し、より多くの推論を求めます。MMLUではトップモデル間の差を判別できなくなったことを理由に作られました。

GPQA (Diamond)

「Google-Proof Q&A」：生物学、物理学、化学の博士課程レベルの問題で、Google 検索だけでは解けないように設計されています。「Diamond」サブセットが最も難しいものです。最先端の科学的推論能力を測るよい指標です。

MATH / AIME

数学の問題（MATH：高校／コンテストレベル、AIME：米国の数学オリンピック）。正解が一意の数値なので、採点が容易です。複数の段階を踏んで考える「推論」モデル（reasoning）の指標となっています。

IFEval

検証可能な指示に従う能力を測定します（「ちょうど3つの箇条書きで答えて」「文字eを使わないで」）。実際の用途では、知識を問う選択式問題よりも実力がよく分かることが多い指標です。

HLE（Humanity's Last Exam）

比較的新しく、意図的に極めて高い難易度に設定されたベンチマークです。複数の分野にまたがる専門的な問題で構成され、長期にわたって難問であり続けるよう設計されています。最も優れたモデルでも、依然として低いスコアにとどまっているため、2026年時点でモデルの性能差を見分けるのに適しています。

#実際のタスクに対するベンチマーク：SWE-bench およびエージェント

この種類のベンチマークは比較的新しく、不正にスコアを上げるのがはるかに難しくなっています。単に質問をするのではなく、結果を客観的に検証できるタスクを最初から最後まで遂行するよう求めるからです。実際のGitHubのチケットを解決する、テストスイートを通す、コードリポジトリを探索するといったタスクです。当サイトのコードベンチマーク専用ガイドで詳しく説明していますが、ここでは要点を紹介します。

SWE-bench Verified

GitHub上の実際の問題500件（issueと期待されるパッチ）からなるサブセットで、OpenAIが手作業で、解決可能で仕様が明確であることを検証しています。モデルは、リポジトリのテストを通過するパッチを生成しなければなりません。実際の開発条件でコードを評価するための定番となっており、HumanEval（現在は96〜98％で飽和）よりも、はるかに実力が分かりやすい指標です。

SWE-bench（full / Lite）

完全版（約2,300タスク）と、素早く試行を繰り返すための軽量版があります。公表スコアは「ハーネス」（モデルの動作を制御するエージェント）に大きく依存します。同じモデルでも、周辺のツール構成によってスコアが15ポイント上がることがあります。

Tau-bench / エージェント機能

複数ターンにわたってツールを使うエージェントのベンチマークです（関数呼び出し、API、業務ルールの遵守）。単に回答するだけでなく、「実際に行動するアシスタント」として使う際の信頼性を測定します。

LiveCodeBench

公開日が記録された競技プログラミングの問題を継続的に収集しています。モデルの学習日より後に公開された問題だけを採点対象にすることができ、評価データの汚染への直接的な対策になります。

#LMArena：人間の好みに基づくランキング

LMArena（LMSYSの旧「Chatbot Arena」）は、異なる仕組みを採用しています。名前を伏せた2つのモデルが、実際のユーザーが出した同じ質問に回答し、そのユーザーがより良い回答に投票します。数百万回の対戦をもとに、Eloスコア（チェスと同じ方式）を計算します。「人々が実際にどのモデルを好むのか」という問いに最も近いベンチマークです。

正確に測定できる点

自由な会話で感じられる品質です。口調、構成、全体的な有用性、心地よい回答を返す能力などが含まれます。実際に使ったときの満足度と非常に強い相関があります。

測定が不十分な点

事実の正確さ。投票者は、長く、体裁が整い、自信に満ちた回答を高く評価しがちです。内容が間違っていても同様です。ユーザーに「おもねる」モデルは、正確さが向上していなくてもランキングを上げることがあります。

Eloはパーセンテージではありません

Elo 10〜20 ポイントの差は統計的なノイズです。常に表示される信頼区間を確認してください。表の同じ行にない場合でも、2 つのモデルが「同点」とみなされることがあります。

カテゴリ別ランキング

LMArenaには、コード、数学、長文回答、スタイル制御といったカテゴリーがあります。「hard prompts」や「style control」の個別ランキングは、すべてを混在させた総合ランキングよりも参考になることが多いです。

#第1の落とし穴：データ汚染

データ汚染とは、ベンチマークの問題（またはその回答）が、意図的かどうかにかかわらずモデルの学習データに含まれてしまうことです。そうなると、モデルは推論するのではなく、覚えた回答をそのまま再現します。公開ベンチマークはウェブ、GitHub、Hugging Faceで広く流通しているため、必然的に事前学習用のコーパスに入り込みます。その結果、スコアは水増しされ、未知の問題に対する性能をまったく予測できなくなります。

これは、内容が固定された公開ベンチマークすべての弱点です。ベンチマークが古く、有名であるほど、リスクは高くなります。注意すべき兆候には、次のようなものがあります。

バージョン間の差

MMLUでは好成績を収めるのに、MMLU-Pro（同じ科目で新しい問題を使用）では成績が大きく落ちるモデルは、理解よりも暗記に頼っている可能性がうかがえます。

モデルの規模に比べて異常に高いスコア

特定の 1 つのベンチマークにおいてのみ 70B を上回る 7B の小型モデル：警戒が必要です。多くの場合、このテストセットに対するターゲットを絞った学習（「benchmaxxing」）によるものです。

日付付きのベンチマーク

「ライブ」評価（LiveCodeBench、タイムスタンプ付きの質問）は、この問題を回避します。モデルの学習データのカットオフ日より後のものだけを評価対象にするためです。

不自然な記憶の抜け

一部のテストでは、暗記した内容をそのまま再現しているかどうかを検出するために、カナリア文字列（「canary strings」）を使った変形や、言い換えを組み込みます。元の質問と言い換えた質問で結果に大きな差があると、データ汚染が露呈します。

#落とし穴2：飽和

ベンチマークの飽和とは、上位モデルのスコアが非常に高くなり、そのベンチマークではモデル間の差を区別できなくなることです。どのモデルも96～99％に達すると、残りの3ポイントは、実際の能力差というよりも測定上のノイズ（曖昧な質問、ラベル付けの誤り）になります。HumanEval（コード）とMMLU（知識）はその典型例です。かつては非常に有用でしたが、ランキング上位のモデルの優劣を判断するには、もはや役立ちません。

そのため、より難しい新しいベンチマークが次々と登場しています。MMLU-ProがMMLUに代わり、推論ではGPQA DiamondとHLEが後を引き継ぎ、コードではSWE-bench VerifiedがHumanEvalに代わっています。ベンチマークには有効に使える期間があります。平均的な性能が一定の水準を超えたら、判断基準から外す必要があります。

#ランキング表に惑わされずに読み解く

モデルの発表資料に掲載されたものでも、公開ランキングに掲載されたものでも、あらゆるスコア表を読む際に使う方法を紹介します。

1. 01
   誰が公開しているかを特定してください

   モデルの宣伝に使われるグラフはマーケティングです。有利なベンチマークや有利なプロトコルを選択（cherry-picking）しています。信頼性の高い第三者のレーダーボード（Open LLM Leaderboard、LMArena、SWE-benchの公式ページ）は、発表スライドよりも信頼性があります。
2. 02
   プロトコルを確認してください

   0-shot か few-shot か？chain-of-thought は使うか？エージェント機能にはどのハーネスを使うか？スコアは方法が同一の場合のみ比較可能です。「self-reported」（自己申告）のアスタリスクは、第三者によって再現されたスコアよりも価値が低いです。
3. 03
   信頼区間を確認してください

   LMArena では、Elo スコアの差が約 15 ポイント未満ならノイズです。サンプル数の少ないベンチマーク（GPQA Diamond、198 問）では、数問の正解でスコアが数ポイント変わります。誤差の幅が示されていないランキングは、慎重に受け止める必要があります。
4. 04
   複数のベンチマークを比較

   一つの数値だけで判断してはいけません。実力のあるモデルは、一つだけ突出した結果を出すのではなく、さまざまなテスト群で良い結果を示します。一つだけ異常に高い結果がある場合は、むしろ特定のテストに合わせた最適化が疑われます。
5. 05
   ご自身の用途に応じて重み付けしてください

   コーディングが目的ですか？MMLU ではなく、SWE-bench と LiveCodeBench を確認してください。フランス語で使いますか？これらのベンチマークはいずれもフランス語での評価ではありません。フランス語の評価を探すか、自分でテストしてください。会話が目的ですか？LMArena を優先してください。「平均で」最も優れたモデルが、あなたにとっても最適とは限りません。

#自らのタスクでローカルモデルを評価する

ここまでの結論は明快です。あなたにとって最も信頼できるベンチマークは、あなた自身のものです。自分の質問はウェブ上にないため汚染されず、難しいケースで調整するため飽和せず、必要なものを正確に測定できます。重いインフラは不要で、代表的な例を約20件使えば2つのモデルを比較できます。

1. 01
   小規模なテストセットを作成してください

   実際の用途から15〜30個のプロンプトを集めてください（メールの作成、情報の抽出、ドキュメントに関する質問、コードの断片など）。それぞれについて、良い回答に含まれるべき内容を記録してください。長期的にモデルを比較できるよう、このテストセットは非公開にし、内容を一定に保ってください。
2. 02
   比較するモデルをインストールしてください

   Ollamaで候補のモデルをダウンロードしてください。Ollamaはhttp://localhost:11434でOpenAI互換APIを公開しているため、呼び出しを自動化できます。
3. 03
   呼び出しを自動化

   小さなスクリプトで各プロンプトを順に処理し、各モデルの回答をファイルに並べて記録します。これにより、モデル名に左右されず、落ち着いて比較できます。
4. 04
   どのモデルの回答かを知らずに採点してください

   どのモデルがどの回答を生成したか分からない状態で、回答を読み直してください（順番を入れ替えます）。正確さ、指示への忠実さ、フランス語の質、事実の捏造がないことなど、自分の基準で採点してください。これが自分専用の「Arena」です。
5. 05
   実際のコストも測定してください

   品質だけがすべてではありません。速度（トークン/秒）とVRAM使用量も記録してください。RTX 4070に収まり、素早く応答するQ4_K_Mの14Bモデル（約9GB）は、理論上は「より優れている」ものの手元の環境ではまともに使えない70Bモデル（約40GB）を上回る選択肢になり得ます。

# Récupérer deux candidats via Ollama
ollama pull qwen3:14b
ollama pull gemma3:12b

# Vérifier qu'ils répondent (API locale sur le port 11434)
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:14b",
  "prompt": "Résume ce texte en 3 puces : ...",
  "stream": false
}'

import json, requests

OLLAMA = "http://localhost:11434/api/generate"
MODELES = ["qwen3:14b", "gemma3:12b"]

# Vos prompts réels — la clé d'une éval qui vous ressemble
prompts = [
    "Rédige un mail de relance poli à un client en retard de paiement.",
    "Extrais les dates et montants de ce texte : ...",
    "Explique la différence entre Q4_K_M et Q8_0 en 2 phrases.",
]

def interroger(modele, prompt):
    r = requests.post(OLLAMA, json={
        "model": modele, "prompt": prompt, "stream": False
    }, timeout=120)
    return r.json()["response"].strip()

resultats = []
for p in prompts:
    ligne = {"prompt": p}
    for m in MODELES:
        ligne[m] = interroger(m, p)
    resultats.append(ligne)

# À relire en aveugle, sans regarder la colonne du modèle
with open("comparaison.json", "w", encoding="utf-8") as f:
    json.dump(resultats, f, ensure_ascii=False, indent=2)
print("OK — comparaison.json généré, notez les réponses à froid.")

#さらに詳しく

以下のガイドでは、ここで取り上げた概念をさらに掘り下げ、専門的なベンチマークやローカルモデルの具体的な選び方を解説します。

コードのベンチマーク詳細

「HumanEvalはもう過去のもの：2026年のLLMコードベンチマークを理解する」では、SWE-bench、LiveCodeBench、コードの評価スコアの読み方を詳しく解説しています。開発の観点から、このガイドの内容をさらに掘り下げる記事です。

量子化の選択

「2026年のGGUF量子化：Q4_K_M vs Q5_K_M vs Q6_K」では、量子化が品質に与える実際の影響を測定する方法を紹介しています。独自の評価を具体的なケースに適用した例です。

包括的なモデルテスト

「Qwen 3をローカルで使う：徹底テストと実測ベンチマーク」では、特定のモデルを例に、ローカルでの評価方法（トークン/秒、フランス語の品質、VRAM）を示しています。