AI は答え合わせはできても問題集は作れない — LLM 評価とモデル選択の論文を読む

LLM は OpenAI、Gemini、Anthropic をはじめ、OpenRouter や Hugging Face を使えば無数に選べます。性能も値段も、どの環境のどのプロバイダー経由で使うかによって変わります。選択肢は際限なくあります。

使う側がほしいものは 1 つです。自分のタスクに必要な性能を持つ、いちばん安くていちばん速いモデル。

どれがそれなのかは、試さないとわかりません。だから同じ問題を複数のモデルに解かせて、点を並べます。これがベンチマークです。公開されているものは山ほどあります。MMLU、GSM8K、SWE-bench、MT Bench。

ただし、手元の判断には足りません。公開ベンチマークが測るのは公開ベンチマークの問題で、自分のタスクではありません。学習データに入っている可能性もあります。そして 2 章で見るように、主要なベンチマークは上位のモデル同士の差をもう測れていません。点が横並びになり、順位はベンチマークを変えると入れ替わります。

だから自分のタスクで問題集を作ることになります。ここが一番難しいところです。詰まり方は 3 つあって、どれも性質が違います。

1. 易しい問題は何も測らない。 全モデルが正解すれば、点は並びますが差は出ません。分母になりません。

2. 難しい問題には正解がない。 自分で解けない難しさの問題を作れば、正解表のほうが疑わしくなります。そして問題集を AI に作らせるなら、出せる難しさの上限は作らせた AI の能力です。

3. 採点が当たらない。 文字列一致は「30 日以内です」と「30 日以内ではありません」を区別しません。AI に採点させれば柔軟になりますが、こんどは採点する側のバイアスが入ります。

この 3 つは、2026 年までにそれぞれ論文で測られています。1 と 2 が 1 章から 3 章、3 が 4 章から 7 章、実際に安いモデルへ振り分けるといくら安くなるかが 8 章、そして全部をいま使っている評価の仕組みのどこに当てるかが 10 章です。

引用した数字はすべて原典にあたって確認しました。

1. 出題と採点は、別の能力だった

いちばん直接この問題を測ったのが Judging Is Not Enumerating（2026 年 8 月）です。

いまモデルは、テストを解く側から、テストを作る側に回りつつあります。テストコード、正解表、採点基準、強化学習の報酬関数。どれもモデルに書かせるのが普通になりました。この論文は、その仕事がちゃんとできているのかを測っています。

比べているのは、同じモデルへの 2 つの頼み方です。

• 判定 — 候補を 1 件ずつ見せて「これは正解に入るか」を答えさせる（正解すべてと、紛らわしい誤答を混ぜて聞く）
• 作成 — 正解の一覧そのものを書き出させる

どちらも「何が正解か」を知っていればできる仕事です。そして結果は、判定のほうが一貫して上でした。

何を題材に測ったのか

ここは誤解しやすいところなので先に書きます。この論文はプログラミングの話だけではありません。 題材は 4 つあって、プログラミングはそのうちの 1 つです。

プログラミングの行だけが、書かせるものが「テスト」です。ほかの 3 つは 正解の一覧をそのまま書かせています。論文の題にある「列挙」はこちらのことで、判定は列挙ではない、が主張です。

なぜ 4 つもやるのか。 モデルが作った正解表をモデルに採点させると循環するからです。だから採点に AI を使わずに正解が決まる題材だけを選んでいます。そして 1 つの題材では疑いが残ります。辞書は不完全かもしれない、用意したテストが甘いかもしれない、条件が単純すぎるかもしれない。この 3 つの弱点は互いに別方向なので、同時には効きません。 性質の違う題材で同じ結果が出ることを根拠にしています。

モデルは Qwen2.5 の 30 億から 720 億を主に使い、Qwen3、Llama、gemma、Mistral、Phi-4 でも再現を確認しています。

先に F1 の説明

点数には F1 を使っています。知っている方はこの節を飛ばしてください。

本当の正解の集合と、モデルが書き出した集合を重ねて、3 つを数えます。

• 当たり — 両方に入っているもの
• 過剰 — モデルが書いたが、本当は正解ではなかったもの
• 漏れ — 正解なのに、モデルが書かなかったもの

この 3 つから 2 つの割合を作り、その調和平均を取ったものが F1 です。

適合率 = 当たり / (当たり + 過剰)    … 書いたもののうち、本当に正解だった割合
再現率 = 当たり / (当たり + 漏れ)    … 本当の正解のうち、書き出せた割合

調和平均の定義（値が 2 つの場合）は、逆数の平均の逆数
  F1 = 2 / (1/適合率 + 1/再現率)

分母を払うと、よく見る形になる
  F1 = 2 × 適合率 × 再現率 / (適合率 + 再現率)

いちど逆数にするので、小さいほうの値に強く引っ張られます。 たとえば本当の正解が 10 個あって、モデルが 4 個書いて 4 個とも正しかった場合、適合率は 1.0、再現率は 0.4。

F1 = 2 / (1/1.0 + 1/0.4) = 2 / 3.5 = 0.57

算術平均なら 0.7 になるところが 0.57 です。漏れている側が効きます。

判定の側も同じ数え方です。「入る」と答えたもののうち本当に入っていた割合が適合率、入るものを取りこぼさなかった割合が再現率になります。

誤りがどちら側に出るかが、この論文の肝です。 過剰が増えれば適合率が下がり、漏れが増えれば再現率が下がる。先に答えを言うと、出てくるのは漏れのほうです。

大きくしても縮まらない

上の表の 2 行目、整数リスト＋数値の条件での結果がこれです。

30 億から 720 億まで、モデルの大きさで 24 倍の幅があります。これが「24 倍」の意味で、学習時の設定などの話ではありません。

一覧を書く側も、大きくすれば上がります（0.660 → 0.787）。ただし 1 件ずつ判定させた側はほぼ満点なので、差は 0.2 前後のまま残ります。別の構成でも 0.34 から 0.29 へと、ほとんど縮まらないと報告されています。大きくすれば消える差ではない、ということです。

プログラミングで見ると、もっとはっきりする

ここは文字どおりプログラミングの話です。使っているのは HumanEval+ と MBPP+、「こういう関数を書け」という問題が並んだ問題集です。提出された実装が正解かどうかは、用意されたユニットテストを実行して決まります。これが基準になります。

同じモデルに 2 つの役をやらせた結果がこれです。

• 判定役 — 提出された実装を見て、仕様を満たしているかを答える → F1 0.74〜0.90。まあ使える
• テストを書く役 — その問題のユニットテストを自分で書く → そのテストは、基準が正解と認めた実装のうち 19〜42% しか通さない

「この実装は正しいか」と聞けば当たります。ところが同じモデルにユニットテストを書かせると、正しい実装の半分以上を落とします。 しかも落とす理由が、仕様に書かれていない要件を勝手に足してしまうことです。

AI にテストを書かせたことがあれば、心当たりのある失敗だと思います。

知識が足りないわけではない

対照実験でそれが分かります。「正解を全部書き出せ」ではなく「正解を定める条件を書け」と頼むと、同じモデルが F1 約 0.99。生成された条件はすべて実行可能で、自分が判定役をやったときの点すら上回りました。

ルールは知っている。ルールが指す範囲を書き出せない。 これが測られたことです。

誤りの型も一方に偏ります。圧倒的に「漏れ」、つまり再現率側です。そしてここが厄介で、漏れはレビューで見つかりません。

• 余計に入っているものは、レビュアーが指で差せるトークンとして存在する
• 漏れているものは「無い」ので、見つけること自体が作成と同じ難しさ

論文は植え込み実験でこれを測っています。わざと混ぜた過剰な項目（適合率側）は、わざと抜いた項目（再現率側）の 6〜7 倍の頻度で発見されます。実運用の 43,227 件では、漏れ側の失敗が 10 対 1 で多い。

検証器として強化学習に組み込むと、正確な解答表と比べて精度が 1.9 ポイント落ちます。

実務の読み方: 「AI に問題集を作らせる」は「AI に採点させる」よりはるかに難しい、と測られています。順番を逆にする余地があります。問題は人が出し、採点を AI に任せる。そして AI が書いた解答表を使うなら、既知の正答を 1 本通してから使う（論文はこの門が誤った不合格を減らすことも示しています）。

2. 「難しい問題」ではなく「差がつく問題」

評価の目的はモデルを分けることです。全員が正解する問題も、全員が不正解の問題も、分母になりません。

これを扱う枠組みが、心理測定の 項目応答理論（item response theory、IRT）です。人間のテストのために作られたものが、そのままモデルの評価に使われています。

言葉と式

3 つの量を、別々のものとして扱います。

• 能力（θ）— 受験者側。モデル 1 つにつき 1 つ
• 難易度（b）— 問題側。通るのにどれだけの能力が要るか
• 弁別力（a）— 問題側。能力の高い側と低い側をどれだけ分けるか

いちばん簡単な形（ラッシュモデル、パラメータ 1 つ）は、能力 θ の受験者が難易度 b の問題に正解する確率をこう置きます。

P(正解) = 1 / (1 + exp(-(θ - b)))

θ - b = -2  →  0.12
θ - b = -1  →  0.27
θ - b =  0  →  0.50
θ - b = +1  →  0.73
θ - b = +2  →  0.88

能力と難易度がつり合えば 0.5。上回れば上、下回れば下。ここに弁別力 a を入れた形がこれです。

P(正解) = 1 / (1 + exp(-a(θ - b)))

a は曲線の立ち上がりの急さです。 同じ難易度でも、a が違うと問題の価値が変わります。

a = 3 の問題は、能力が難易度を少し跨いだだけで正解率が 0.18 から 0.82 へ動きます。この 1 問で、そのモデルが b より上か下かがほぼ分かります。 a = 0.5 の問題は 0.44 から 0.56 しか動きません。何問並べても差が見えにくい。

欲しいのは a の大きい問題です。難しさだけ上げても、a が小さければ測れません。

具体例 — 平均が隠すもの

10 問のテストで、2 つのモデルを比べたとします。

• 8 問は、両方とも正解した
• 1 問は、両方とも不正解だった
• 残り 1 問だけ、A が正解して B が落とした

点は A が 9 割、B が 8 割。1 割の差がついて見えます。しかし差を作ったのは 1 問だけです。残りの 9 問は、どちらも同じ答えなので、順位について何も言っていません。

そしてその 1 問が、たまたま当たっただけだったら、順位は入れ替わります。これが「上位のモデル同士の差が測れていない」の中身です。点は出ます。点の差の根拠が、ほとんど無いというだけです。

主要なベンチマークを診断すると

Lost in Benchmarks?（2025 年 5 月）は、12 のモデルと 11 のベンチマークでこの枠組みを当てました。出発点は 2 つの症状です。

• 同じモデルの順位が、ベンチマークを変えると大きく入れ替わる
• 上位のモデル同士の差が、もう測れていない

2 つ目が、上の 10 問の例そのものです。モデルが実際に同じ性能だから横並びになるのではありません。そのベンチマークに、その水準で差がつく問題が残っていないからです。だから使う問題集を変えると順位が動きます。

論文は原因を 2 つに分けています。難易度の天井が足りないことと、問題が飽和していることです。

飽和の測り方はこうです。いちばん強いモデルの能力の位置で、上の正解曲線の傾きを見ます。傾きがほぼ 0 なら、そのモデルにとってこの問題は「もう必ず解ける」側に乗っていて、これ以上強くなっても点は動きません。余裕が残っていないということで、論文はこれを問題ごとに測っています。

• ARC-C、HellaSwag、HumanEval は相対的に易しくなっていて、多くの問題が高性能なモデルにすぐ解かれる
• MATH、とくに GSM8K は飽和がさらに進んでいる。高性能なモデルは、問題のかなりの部分で既に天井に達している
• GPQA Diamond、TheoremQA、Chinese SimpleQA は難易度が高く、まだ多くのモデルを落とせる。ただし余裕の絶対値は、それでも理想より小さい

もう 1 つ、冒頭の 1 と 2 をそのまま裏付ける測定があります。弁別力は、問題が易しすぎても難しすぎても落ちる。 a が大きくなるのは中間だけです。易しくすれば測れず、難しくすれば測れない、という冒頭の行き詰まりが、ここで数字になっています。

同じ分析では、正解率に対して不自然に高い「当て勘で当たる率」を持つ問題も見つかっていて、学習データへの混入の指標として使われています。

そして質の高い問題だけを選び直すと、より小さいベンチマークで人間の好みとの一致が高まり、上位モデル同士の差もつくようになりました。

問題を 10 問に減らして、点が復元できる

Item Response Theory for AI Safety（2026 年 8 月）は、8 本の安全性ベンチマークと 192 モデルで測った、この種の分析としては最大規模のものです。

• モデル間の差の大半を 3 つの因子で説明できる（拒否の厳しさ、真実性、文脈依存の有害性）
• 心理測定で選んだ問題は、同じ数のランダムな部分集合より誤差が小さい
• いくつかのベンチマークでは、適応的に選んだ 約 10 問で全体の点を復元できる。評価費用が 97〜99% 減る
• 加えて、わざと性能を低く見せる振る舞いや、API の裏でモデルが差し替わったことの検出にも使える

「適応的に選ぶ」は、人間の適応型テストと同じ考え方です。10 問を固定で決め打ちするのではなく、答えを見ながら次の問題を選びます。 1 問目で正解したら、次はもっと難しい問題を出す。そうすると、そのモデルの能力の近くにある、弁別力の高い問題だけを引けます。能力から遠い問題は、結果が分かりきっているので引く意味がありません。

実務にいちばん効くのはここです。弁別力で問題を選ぶと、ベンチマークは小さくなり、しかも精度が上がります。問題を増やすより、効いていない問題を外すほうが先です。

3. ただし、受験者の人数が足りない

枠組みを丸ごと持ってくる前に、Can We Trust Item Response Theory for AI Evaluation?（2026 年 7 月）を読む必要があります。

パラメータが増えると、必要な人数が増える

IRT のモデルは、問題ごとに推定する量の数で呼び分けます。

1 パラメータ  難易度 b だけ
              P = 1 / (1 + exp(-(θ - b)))

2 パラメータ  難易度 b ＋ 弁別力 a
              P = 1 / (1 + exp(-a(θ - b)))

3 パラメータ  ＋ 当て勘で当たる率 c（下限。4 択なら 0.25 あたり）
              P = c + (1 - c) / (1 + exp(-a(θ - b)))

推定する量が増えれば、必要なデータも増えます。人間のテストで推奨されている最小の標本数が、それを表しています。

• 1 パラメータ・2 パラメータ — 250〜500 人
• 3 パラメータ — 1,000〜3,000 人

AI のベンチマークは、条件が逆

行と列が入れ替わっています。受験者が少なく、問題が多い。推定法は逆を想定しています。

3 行目も効きます。モデルの能力は、きれいな釣鐘型になりません。最前線の数モデルが上に固まり、小型のモデルが下に固まる、といった形になりがちです。山が 2 つある分布は、正規分布を前提にした推定法が苦手な形です。

論文は 6 本のベンチマークから取った問題のパラメータを使い、3 つの IRT モデルと 4 つの推定法で 18,000 条件を模擬しました。結果は 2 つです。

• 古典的な推定法は、問題数が多い設定では計算が成立しない
• 計算が回る推定法は、モデル数が少ないか分布が正規から外れていると、問題ごとの推定と順位付けが信頼できなくなる

読み方: 枠組みと、問題ごとに集計するという考え方は使えます。10 モデルの結果から「この問題の難易度は 1.8」のような推定値を出すのは、検証されていない領域です。弁別力は「全員通った／全員落ちた／割れた」の集計として読み、推定されたパラメータとして語らないほうが安全です。

4. 採点する側も間違える

採点を AI に任せるなら、採点者の誤り方を知っておく必要があります。ここは測定がよく進んでいる領域です。

ルーブリックとは

この章で何度も出てくるので先に説明します。ルーブリックは、答えに点を 1 つ付けるのではなく、基準のリストに対して 1 つずつ○×を付ける採点形式です。

問い: 返品手続きを 3 行以内で説明してください

基準 1  3 行以内である                      → 満たす / 満たさない
基準 2  返品できる期限の日数に触れている      → 満たす / 満たさない
基準 3  電話番号を書いていない               → 満たす / 満たさない

基準 1 と 3 は機械で確かめられるので、採点にモデルは要りません。「説明が分かりやすいか」のような基準は、人かモデルが判断するしかありません。前者を機械で検証できる基準、後者を主観的な基準と呼びます。この違いが、以下の結果の読み方を変えます。

4.1 自分の答えに甘い

Self-Preference Bias in Rubric-Based Evaluation（2026 年 4 月）は、ルーブリック形式での自己優遇の最初の測定です。

測り方は 取り違え率です。生成側が実際には基準を満たしていない答えについて、採点側が「満たした」と付けてしまう割合です。これを 2 つの場合で比べます。

取り違え率 = 「満たした」と誤って付けた数 / 本当は満たしていない数

  (a) 自分、または同系統のモデルの出力を採点した場合
  (b) 他のモデルの出力を採点した場合

自己優遇 = (a) − (b)

使ったのは IFEval（指示に従えているかを機械で確かめられる問題集）と LiveCodeBench です。基準に主観の余地がありません。それでも差が出ました。

• 満たしていない答えを「満たした」と付ける確率が、自分や同系統の出力だと最大で 50% 高い
• 主観的な基準を持つ HealthBench（医療の対話）では、点が最大 10 ポイント動く。最前線のモデルを並べるときには順位が変わる幅。例として、GPT-5 は合議による採点に比べ、自分の成績を約 4 ポイント高く見ている
• 複数の判定者で合議すると緩和する。ただし消えない。そして合議は、どの基準が危ないかの予測にも使える
• 効きやすい基準の型がある。「〜を書いていない」という否定形、短すぎる基準、長すぎる基準。主題では、伝え方や緊急時の紹介が弱い

そして採点形式どうしの比較が、この論文のもう 1 つの結果です。 3 つを比べています。

「比較させるほうが安全」とよく言われますが、自己優遇に関しては逆でした。5 章でこの話に戻ります。

4.2 ただし、甘さの多くは正当だった

Do LLM Evaluators Prefer Themselves for a Reason?（2025 年 4 月）は、ここに重要な区別を入れます。

正解が客観的に決まるベンチマーク（数学、事実知識、コード生成）を使うと、自己優遇を 2 つに割れます。

• 正当な自己優遇 — 自分の答えのほうが、本当に優れていた
• 有害な自己優遇 — 客観的に劣る自分の答えを選んだ

結果はこうです。

• 強いモデルは自己優遇が強い。ただしその多くは正当だった
• 有害な部分は、判定者自身が生成者として間違えた場面に残る
• そして強いモデルほど、自分が間違えたときにそれを認めにくい
• 評価の前に長い思考を置くと、有害な部分は減る

3 番目が実務に効きます。「強い判定者を使えば安心」は成り立ちません。危ないのは、判定者が自分でも解けていない問題で、自分の答えを採点する場面です。

4.3 選択肢の位置で点が動く

Am I More Pointwise or Pairwise?（2026 年 2 月）は、ルーブリックによる採点が 選択肢から選ぶ問題と同じ構造であることを指摘します。

この答えは基準を満たしていますか。
  A  完全に満たす
  B  おおむね満たす
  C  部分的に満たす
  D  満たさない

このリストから選ばせると、中身とは別に、位置そのものの偏りが出ます。

• 向きはモデルごとに違う。先頭を選びやすいモデルと、末尾を選びやすいモデルがある。つまり一律の補正はできない
• 別の軸がもう 1 つある。1 回のプロンプトで複数の基準を採点させると、基準の並び順そのものが点を動かす
• 対策は選択肢の並べ替え。ごく少数のランダムな並べ替えで、ほとんどのモデルについて誤差が減る
• ただし人間の評価との相関が上がるのは、元々バイアスが強いモデルに限られる

4.4 判定の取り出し方で変わる

Improving LLM-as-a-Judge Inference with the Judgment Distribution（2025 年 3 月）は、採点の値をどう取り出すかの話です。

モデルは最後に「4」という 1 文字を返しますが、その手前では次のトークンの確率分布を持っています。たとえばこうです。

1: 0.02   2: 0.03   3: 0.10   4: 0.45   5: 0.40

最頻値（貪欲法で出てくる文字）         → 4
期待値（確率で重みを付けた平均）        → 4.18

期待値を取ったほうが、一貫して良い結果でした。 点ごと・2 つ比べ・並べ替えのすべての設定で。4 と 5 でほぼ迷っているという情報が、「4」という 1 文字では消えてしまうからです。

• リスク回避を入れた導出がさらに効くことがある
• そして、判定の前に思考を置くと分布の広がりが潰れ、性能を落とすことが多い

最後の行は 4.2 と逆を向いています。「点を出す前に考えさせる」は有害な自己優遇を減らしますが、判定分布を潰します。どちらを取るかは測って決める話で、既定で決まっていません。

5. 「比較がぶれる」は、必ずしも判定者の欠陥ではない

2 つの出力を比べさせる形は広く使われています。そして判定者の信頼性は、3 つの代用指標で測られるのが普通です。

• 位置バイアス — 先に見せたほうを選びやすい偏り
• 推移性 — A が B に勝ち、B が C に勝つなら、A は C に勝つか
• 一致率 — 同じ組をもう一度聞いて同じ答えになるか、または人の判断と合うか

Pair Difficulty Matters（2026 年 9 月）は、この測り方自体を批判します。

ブラッドリー・テリーとは

対比較の結果を 1 本の順位に直すときの標準的なモデルです。それぞれに強さ s を与えて、勝つ確率をこう置きます。

P(A が B に勝つ) = 1 / (1 + exp(-(s_A - s_B)))

強さの差 0    →  50%
強さの差 0.5  →  62%
強さの差 1    →  73%
強さの差 2    →  88%
強さの差 3    →  95%

差が小さい組では、勝率が 50% に近づきます。 どちらが勝ってもおかしくない、ということです。判定者がそこでぶれたとして、それは判定者の欠陥というより、その組にそもそも決着が無いという話になります。

だから代用指標は判定者の質を測れていない

上の 3 つの代用指標は、どれも実力が近い組に支配されます。近い組でぶれるのは当然で、しかも 1 つ 1 つの判定は、最終的な順位にほとんど寄与しません。順位の情報を運んでいるのは実力が離れた組ですが、そちらは代用指標をほとんど動かしません。

人手評価の 2 つのコーパスと模擬実験で確認しています。代用指標は、正解に対する順位の正確さとは弱い相関しかなく、予測力は離れた組に集中していました。

読み方は 2 つあり、どちらも効きます。

1 つ目。「この判定者は比較がぶれるから使えない」は早い判断です。論文は、そのせいで有能な判定者が候補から外されていると主張しています。判定者は、正解に対する順位の正確さで選ぶべきです。

2 つ目は逆向きで、設計の話です。隣り合う 2 つを比べて差を出す形は、そもそも信号が薄いところを測っています。安いモデルとその 1 つ上を比べるのは、まさにこの「近い組」です。差が出ないのはモデルが同じだからではなく、測っている場所のせいかもしれません。

そして 4.1 の結果と合わせると、比較形式は自己優遇もいちばん重く出ます。2 つを比べる形は、思っているほど安全な選択ではありません。

6. 文章の答えを採点する

選択式や文字列一致で測れる範囲は限られます。記述式に広げたくなりますが、そうすると採点のほうが難しくなります。

記述式の自動採点とは

記述式の自動採点（automated short answer grading、ASAG）は、問いと模範解答と学生の答えを並べて、答えにラベルを付ける仕事です。Estimating LLM Grading Ability and Response Difficulty in Automatic Short Answer Grading via IRT（2026 年 5 月）が使っているのは、科学分野の問いを集めた 2 つのデータです。ラベルは 5 つあります。

correct                       正しい
partially_correct_incomplete  部分的に正しいが、足りない
contradictory                 模範解答と矛盾する
irrelevant                    関係ない
non_domain                    そもそも分野の外

対象は 17 の公開モデル。内容の広さが違う 2 つのデータを使っています（1 つは電気・電子の入門に絞ったもの、もう 1 つは科学全般）。

これまでの測り方と、その限界

普通は全体の macro-F1 と κ で測ります。κ（コーエンのカッパ）は、一致率から「偶然でも一致してしまう分」を引いた指標です。

κ = (実際の一致率 - 偶然の一致率) / (1 - 偶然の一致率)

例: 実際の一致率が 0.70、ラベルの偏りから偶然の一致率が 0.40 なら
    κ = (0.70 - 0.40) / (1 - 0.40) = 0.50

ラベルが 5 つあると偶然の一致も起きるので、素の一致率だけ見ると甘く出ます。だから κ を使います。

ただし κ も F1 も、全体を 1 つの数に潰します。この論文は、2 章と同じ道具を採点者に当てました。答案ごとに 採点難易度、モデルごとに 採点能力 を置いて、別々に見ます。

分かったこと

• 全体の点がほぼ同じモデルでも、採点難易度が上がったときの落ち方が大きく違う。平均だけ見ていると同じに見える
• 間違え方に型がある。難しい答案での誤りは partially_correct_incomplete に偏る
• 採点が難しい答案の特徴は 3 つ。模範解答との意味的な近さが弱い、矛盾の信号が強い、埋め込み空間で孤立している

2 番目は、迷ったときに中間のラベルへ逃げるという現象です。「部分的に正しいが、足りない」は、どんな答案にもある程度は当てはまってしまうラベルです。判断に困ると、そこへ寄ります。中間のラベルを用意すると起きる、という読み方もできます。

3 番目の「埋め込み空間で孤立している」は、ほかのどの答案とも似ていないという意味です。似た答案が周りにあれば、それをなぞって判断できます。独特な書き方をした答案は、その手がかりがありません。

読み方: 記述式への拡張はできます。ただし「平均が同じ採点者は同じ」とは言えないので、難しい答案での落ち方を別に測る必要があります。そして 3 番目は実装に直接使えます。模範解答から意味的に遠い答案は、採点が当たらない側に寄ると分かっているので、そこだけ人が見るという振り分けができます。

7. なぜ採点のほうが易しいのか

ここまでの全体を支えている理屈に、名前が付いています。生成と検証のギャップです。

素朴な説明はこうです。生成は、語彙の中から次の 1 トークンを選ぶことを何百回も繰り返します。どこかで 1 つ外すと以降が崩れるので、誤差が積み上がります。検証は「正しい／正しくない」の 2 択です。選ぶ先の広さが、そもそも違います。

Variation in Verification（2025 年 9 月）は、参照解答なしで正しさを判定する「生成的検証」を測りました。12 のベンチマーク、14 の公開モデル（20 億〜720 億パラメータ）と GPT-4o。検証者は、考える過程を書いてから○×を出す形です。3 つの結果が出ています。

1. 易しい問題では、検証者は正答をより確実に認定できる
2. 弱い生成器の誤りは、強い生成器の誤りより見つけやすい
3. 検証の能力は検証者自身の解答能力と相関する。ただし関係は問題の難しさで変わる

2 番目は、安いモデルの答えを強いモデルで採点する設計にそのまま効きます。見つけやすい側を測っていることになります。

もう 1 つ、実務で効く結果があります。複数生成して検証器に選ばせる構成（1 つの問いに n 個答えさせて、検証器に良いものを選ばせる形）を挟むと、弱い生成器が強い生成器にほぼ並ぶ場合があります。論文は Gemma2 の 90 億と 270 億で、その差が 75.7% 縮んだ例を挙げています。

一方で、強い検証者が弱い検証者に対してほとんど優位を持たない場面も特定されています。そこは両方とも意味のある検証になっていません。検証者を上のモデルに替えれば良くなる、とは限らないということです。

8. 本題 — モデルを振り分けると、いくら安くなるか

ここまでが測る側の話です。測れたとして、実際にいくら安くなるのか。

定型の設計はこうです。問いごとに、軽い予測器が「安いモデルで足りるか」を当て、閾値を下回ったら高いモデルへ上げる。

RouteLLM の費用表

RouteLLM（2024 年 6 月）は、強いモデルと弱いモデルの 2 択を、人間の好みデータで学習した振り分け器で選びます。

まず前提の値段です。 論文の見積りで、百万トークンあたり GPT-4 が 24.7 ドル、Mixtral 8x7B が 0.24 ドル。約 100 倍の差があります。この差があるから振り分けが効きます。

比較の基準は「全件を GPT-4 に投げた場合」です。削減比 3.66 倍は、同じ品質を 1/3.66 の費用で達成したという意味になります。

ベンチマークによって 3.66 倍と 1.41 倍の差が出ているところが実務的に大事です。問いの分布次第で効きが変わります。 論文自身、MT Bench が学習に使った問いの分布に近かったことが、この差の説明だろうと書いています。

そしてもう 1 つ、いちばん使える結果が 転移 です。学習した振り分け器は、強いモデルと弱いモデルを入れ替えても再学習なしで効きました。学習データに入っていない Claude 3 Opus と Sonnet の組、Llama 3.1 の 700 億と 80 億の組でも性能を保っています。モデルが入れ替わるたびに振り分け器を作り直す必要はない、ということです。

解く前に、解けるかが分かる

LLMs Encode Their Failures（2026 年 2 月）は別の角度から入ります。生成する前の内部表現から、そのモデルがこの問題を解けるかを当てる、という論文です。

使うのは線形プローブです。モデルの中間層が出す数値のベクトルを入力に、1 層の線形分類器を学習させて「解けるか」を当てます。モデル本体は触りません。結果は、質問の長さや単語の重み付けのような表層の特徴を大きく上回りました。

面白いのはここです。モデルは 人間の難易度とは別の、そのモデル固有の難易度 を符号化しています。そして長い推論を使うほど、その 2 つの違いは大きくなります。人間が難しいと思う問題と、モデルが落とす問題は別物だということです。

これを使って複数モデルに振り分けると、最良の単体モデルを上回りながら、MATH で推論費用を最大 70% 削減しました。

まとめて投げる話と、組み合わせると難しくなる

Towards Cost-effective LLMs Routing with Batch Prompting（2026 年 5 月）は、振り分けと、複数の問いを 1 回の呼び出しにまとめるバッチ処理を同時に扱います。従来はどちらか片方だけでした。

合わせた問題は NP 困難 であることを示しています。厳密な最適解を現実的な時間で求める方法は見つかっていない、という意味です。だから論文も、費用と品質の釣り合いの良い組み合わせを貪欲に選ぶ方法を提案しています。最適化そのものを厳密に解こうとしないほうがよい、という実務的な示唆でもあります。

問いごとか、仕事ごとか

論文はほぼ問いごとに振り分けます。仕事の種類ごと（この機能はこのモデル、という形）に振るのは粗いですが、作るのははるかに易しく、まず効果を確かめるには十分です。

そして実務の報告で繰り返し挙がる不満は「各段の品質を検証する評価の負担」です。つまり本稿の 1 章から 7 章に戻ってきます。安くする仕組みを作るより、安くして大丈夫かを測るほうが大変、というのが現場の声です。

失敗の報告も読む価値があります。ルーターが 8 倍払って安いモデルと同じ答えを出した話 は、振り分けの判断自体にモデルを使ったときの素直な失敗例です。

なお、ここで引用した論文はどれも 費用 を測っていて、応答時間は主題になっていません。安さと速さは普通は同じ方向を向きますが、振り分け器自身の推論が 1 段増えることや、バッチにまとめると最初の 1 件の待ち時間が伸びることは、費用の表には出てきません。速さが要件なら、そこは自分で測る必要があります。

9. Anthropic のガイドと、そこに残る緊張

モデルを作っている側の指針も見ておきます。Define success criteria and build evaluations の要点です。

• 実際の仕事の分布を写すこと。端のケースを入れること。人間でも判断が一致しないような曖昧な事例も含める
• 自動採点できる形に問いを作ること（選択式、文字列一致、コードで採点、AI で採点）
• 量を質より優先すること。「信号が少し弱い自動採点の問題を多く」のほうが、「人手で丁寧に採点した問題を少なく」より良い
• ルーブリックには自動不合格の条件を具体的に書く
• 点を出す前に理由を書かせると、評価の性能が上がる。特に複雑な判断で

採点手段には順番があります。

「自動不合格の条件」は、ガイドが挙げている例がそのまま分かりやすいです。

悪い基準   答えが適切であること
良い基準   答えは最初の文で Acme Inc. に触れること。
           触れていなければ自動的に不正解とする

「適切」は判定者ごとにぶれますが、「最初の文に特定の語があるか」はぶれません。4 章で見たバイアスは、基準が曖昧なところに入り込みます。判定者を強いモデルに替える前に、基準文を書き込むほうが安い、という順番になります。

そして「細かい判断ができない」が、冒頭の 3 つ目です。コードでの採点はいちばん信頼できる手段ですが、信頼できるのは書いたとおりに動くことであって、測りたかったことが測れている保証ではありません。そこを埋めるために AI に採点させると、4 章から 6 章のバイアスが入ってきます。どちらかが正解という話ではなく、交換条件です。

残る緊張が 2 つ

どちらも、一方が間違っているという話ではなく、意識して選ぶべき分岐です。

1 つ目。量を優先するのか、質の門を厳しくするのか。 ガイドは量を推します。一方で 1 章の結果は、AI が作った問題には見つけにくい漏れが入ることを示しています。量を採るなら、入ってくる問題の質は落ちます。両方を最大にはできません。

2 つ目。点を出す前に考えさせるのか。 ガイドと 4.2 は考えさせる側、4.4 は判定分布が潰れるので逆です。自分の採点器で測って決めるしかありません。

10. 今の evals にどうつながるか

ここまで論文の話でした。では、いま動かしている評価の仕組みのどこに効くのか。promptfoo、DeepEval、Ragas、Braintrust、Langfuse といった道具の比較は別記事にあります。ここで言いたいのは道具選びの話ではありません。

結論から言うと、新しい道具は要りません。既にあるつまみの回し方が変わります。

いちばん安い一手を 1 つ挙げるなら 9 章です。判定者を強いモデルに替える前に、基準文へ自動不合格の条件を書く。4 章のバイアスは曖昧な基準に入り込むので、基準を締めるほうが効きます。

やらないほうがよい一手も 1 つあります。3 章の結果から、項目応答理論を手元に持ち込んで難易度や弁別力を推定することです。枠組みの考え方は使えますが、手元のモデル数では推定値が立ちません。

そして、この表のどの行も 評価の仕組みを変える話 で、本番のモデルを変える話ではありません。8 章の振り分けを入れるには、その前提としてこの表が要ります。順番は逆にできません。

まとめ

• 出題と採点は別の能力。 判定ははるかに得意で、作成は苦手。差は規模では縮まらない。誤りは「漏れ」に偏り、レビューで見つからない
• 問題は難易度ではなく弁別力で選ぶ。 適応的に選んだ 10 問前後で全体の点を復元できた例がある。ただし項目応答理論の推定値は、モデル数が 100 未満という条件では検証されていない
• 採点する側にも測定されたバイアスがある。 機械で検証できる基準でも自己優遇は残る。危ないのは、判定者自身が解けていない問題を採点する場面
• 比較がぶれることは欠陥とは限らない。 近い組でのぶれは期待される挙動で、順位の信号は離れた組が運ぶ
• 振り分けの効果は測られている。 品質 95% で費用 3.66 倍の削減、という表がある。そして振り分け器はモデルを入れ替えても転移する
• どれも、いま動かしている評価の仕組みのつまみに落ちる。 新しい道具は要らない（10 章）

読む順番を 1 つ提案すると、Judging Is Not Enumerating、Variation in Verification、RouteLLM の 3 本です。それぞれ「なぜ問題集が作れないのか」「なぜ採点なら動くのか」「それでいくら安くなるのか」に対応していて、残りはこの 3 本の精度を上げる話として読めます。

参照

出題と採点

• Judging Is Not Enumerating: Silent Omissions in LLM-Authored Acceptable Sets — arXiv:2608.01000、2026 年 8 月
• Variation in Verification: Understanding Verification Dynamics in Large Language Models — arXiv:2509.17995、2025 年 9 月

問題の選び方（項目応答理論）

• Lost in Benchmarks? Rethinking Large Language Model Benchmarking with Item Response Theory — arXiv:2505.15055、2025 年 5 月
• Item Response Theory for AI Safety — arXiv:2608.05086、2026 年 8 月
• Can We Trust Item Response Theory for AI Evaluation? — arXiv:2607.15190、2026 年 7 月
• Estimating LLM Grading Ability and Response Difficulty in Automatic Short Answer Grading via Item Response Theory — arXiv:2605.00238、2026 年 5 月

採点者の信頼性

• Self-Preference Bias in Rubric-Based Evaluation of Large Language Models — arXiv:2604.06996、2026 年 4 月
• Do LLM Evaluators Prefer Themselves for a Reason? — arXiv:2504.03846、2025 年 4 月
• Am I More Pointwise or Pairwise? Revealing Position Bias in Rubric-Based LLM-as-a-Judge — arXiv:2602.02219、2026 年 2 月
• Pair Difficulty Matters: Rethinking Pairwise LLM-as-a-Judge Evaluation and Consistency — arXiv:2609.37577、2026 年 9 月
• Improving LLM-as-a-Judge Inference with the Judgment Distribution — arXiv:2503.03064、2025 年 3 月

モデル選択

• RouteLLM: Learning to Route LLMs with Preference Data — arXiv:2406.18665、2024 年 6 月
• LLMs Encode Their Failures: Predicting Success from Pre-Generation Activations — arXiv:2602.09924、2026 年 2 月
• Towards Cost-effective LLMs Routing with Batch Prompting — arXiv:2605.28268、2026 年 5 月

指針

• Define success criteria and build evaluations（Anthropic） — 更新される文書。参照したのは 2026 年 10 月 22 日時点

関連記事

• AI エージェント評価 (eval) の最新サーベイ論文を読み解く
• AI で評価用テストペアを生成する手法サーベイ
• AI エージェントの evals 入門