AIエージェントが出力したコードや推論を、どうやって正確に採点するか。この問いにStanfordとUC Berkeleyの研究チームが新たな答えを出しました。
この記事でわかること
- LLM-as-a-Judgeの限界と、なぜ粗い評価が問題になるか
- LLM-as-a-Verifierの3つのコアコンポーネント
- Terminal-Bench 2とSWE-Bench Verifiedでの具体的な改善幅
- GitHubで試す手順と必要な環境
https://github.com/llm-as-a-verifier/llm-as-a-verifier
従来手法の問題：「27%がタイ」の評価では使えない
LLMの出力を別のLLMに採点させる「LLM-as-a-Judge」は、コスト面で人間評価の代替として広く使われてきました。しかし問題が2つあります。
1つ目は粒度の粗さです。多くの実装では、正解か不正解かの2値で判断するため、わずかに惜しい出力と完全に的外れな出力が同じ扱いになります。2つ目は一貫性のなさです。同じ入力でも実行のたびに異なるスコアが出やすく、27%のケースで「引き分け（タイ）」が発生するという報告があります。これでは複数の候補出力から最良のものを選ぶ「テスト時スケーリング」が機能しません。
LLM-as-a-Verifierの3つのコンポーネント
Stanford AI LabとUC Berkeley Sky Computing Labの研究チームが発表した「LLM-as-a-Verifier」は、この問題を3つの仕組みで解決します。
スコアリング粒度のスケーリング
2値評価の代わりに、G個のスコアトークン（例：1〜20の連続値）を使います。各トークンにモデルが割り当てる対数確率を加重平均することで、より細かいスコアを算出します。
繰り返し検証
同じタスクに対してK回独立に評価を実行し、平均を取ります。1回の評価で生じるランダムな揺れを打ち消す狙いです。
評価基準の分解
「タスク要件を満たしているか」「出力フォーマットは正しいか」「エラーシグナルはないか」などC個の独立した軸に分けて採点し、それらを統合します。
報酬スコアは次の式で定義されます。
R(t, τ) = (1/CK) Σ_c Σ_k Σ_g p_θ(v_g | t, c, τ) · φ(v_g)
CとKとGを大きくするほど評価の精度が上がりますが、APIコストも増えます。デフォルト設定（G=20、K=4、C=3）で実験した場合の結果が下記です。
ベンチマーク結果
2つの主要なソフトウェアエンジニアリングベンチマークで評価しています。
Terminal-Bench 2
| 手法 | スコア | 正解率 |
|---|---|---|
| Pass@1 | 72.8/89 | 81.8% |
| LLM-as-a-Verifier | 76.9/89 | 86.4% |
| Oracle（Bo5） | 80/89 | 89.9% |
SWE-Bench Verified
| 手法 | スコア | 正解率 |
|---|---|---|
| Pass@1 | 380.3/500 | 76.1% |
| LLM-as-a-Verifier | 389.0/500 | 77.8% |
| Oracle（Bo3） | 422/500 | 84.4% |
ベースラインのPass@1と比べて、Terminal-Benchで4.6ポイント、SWE-Benchで1.7ポイントの改善です。Claude Opus 4.6やGPT-5.4といったフロンティアモデルを上回る精度を達成しています。
Oracle（理想的な選択）と比較するとまだ差はありますが、LLM-as-a-Verifierは人間によるラベルなしに自動で最良の候補を選べる点が強みです。
複数候補からの選択：ラウンドロビントーナメント
N個の候補トラジェクトリから最良を選ぶ際は、ラウンドロビン方式を使います。すべてのペア（i, j）に対してスコアを計算し、最も多くの「対戦勝利」を得たトラジェクトリを採用します。これにより1対多の比較バイアスを避けられます。
試す方法
https://github.com/llm-as-a-verifier/llm-as-a-verifier
評価器にはGeminiモデルを使います。Vertex AI APIキーが必要です。
pip install google-genai tqdm
echo "VERTEX_API_KEY=your_key_here" > .env
Terminal-Benchで評価する場合は次のコマンドを実行します。
python scripts/run_terminal_bench.py --granularity 20 --n-verifications 4 --criteria 3
リポジトリにはTerminal-Bench 2の89タスク（5トラジェクトリ×89問）とSWE-Bench Verifiedの500インスタンス（3ラン）が付属しているため、追加データ収集なしに再現実験が可能です。
テスト時スケーリングへの示唆
LLM-as-a-Verifierが示す本質は「より賢いモデルを使わなくても、評価の仕組みを改善するだけで性能が上がる」という点です。
推論コスト削減のために複数の軽量モデルを並列実行し、その中から最良を選ぶアーキテクチャは今後増えていきます。その際、選択の精度が最終的な出力品質を決めます。粒度・反復・基準分解という3つのアイデアは、そのまま他の評価タスクにも転用できます。