LLM評価は「測るたびに揺れる」——事前登録された5万件の監査が暴いた、LLMジャッジの計測としての脆さ
はじめに：いま、LLMは「測定器」として使われている
「LLM-as-a-Judge（LLMジャッジ）」とは、LLM自身に他モデルの出力を採点・順位付けさせる評価手法だ。MT-BenchやChatbot Arena（Zheng et al., 2023）以降、リーダーボードの順位付けや学習データの選別、生成品質のスコアリングなど、評価のあらゆる場面に浸透している。その手軽さの裏で、ジャッジは「同じものを測れば同じ値を返す測定器」として扱われ、「同じリクエストを同じモデル名に送れば、明日も同じ結果が返る」という暗黙の前提が評価パイプラインを支えてきた。
2026年9月公開の論文「Clean Engineering, Unstable Measurement」（arXiv:2609.04198）は、事前登録（preregistration）という科学上もっとも厳格な手続きでこの前提を監査した。閾値を実行前に凍結し、5万件超の試行を2回のキャンペーンで完走した結果、測定器としてのLLMは想定外の揺れを見せた。本稿ではその内訳と、評価パイプラインを運用するエンジニアに向けた実務的な教訓を、3つのメカニズムに整理して解説する。
LLMジャッジの何が問題なのか：先行研究が積み上げた知見
LLMジャッジへの不信は、研究史の上で「バイアス」と「非決定性」の2系統に分かれる。前者は判定の傾向が特定の方向に偏ること、後者は同じ入力に対して出力が揺れることだ。バイアスでは、提示順を入れ替えるだけで判定が反転する位置バイアス（Wang et al., 2024；Shi et al., 2025）や、冗長性・自己選好バイアス（Zheng et al., 2023；Panickssery et al., 2024）が知られる。非決定性では、Rating Roulette（Haldar & Hockenmaier, 2025）が同じ入力の複数回評価の揺れを、Norman et al.（2026）は「信頼性と妥当性は別物」であることを大規模監査で示した。さらに、温度0でも再現しない「Deterministic設定の非決定性」（Atil et al., 2024）は、共有エンドポイントのバッチ化と、バッチサイズに依存する浮動小数点演算が原因とされる。本論文はこの流れを、事前登録で測定器を検証する形で継承する。
本論文がやったこと：5万件の「完璧な」実験が測定器の検証で2回とも失敗した
実験は2段パイプラインで構成される。答えが一意に決まる算術タスクについて、ジェネレータが推論トレース付きの4候補を生成し、外部のLLMオブザーバーが「部分的な見え方」だけから正解確率を推定して順位を付ける。このパイプライン全体を1つの「測定器」とみなし、全閾値を事前凍結、リクエストをSHA-256でハッシュ化、監査ログを追記専用にするなど監査チェーンを徹底した。
結果、2つの必須ゲートはどちらも失敗した。ゲートI-3S（同一時間窓内のリピート順位安定性）は、同じタスクを繰り返し測った際の順位相関（Spearman）の中央値が 0.400 で、閾値 0.90 に遠く及ばなかった。ゲートI-5R（翌日のバイト同一リプレイ）は、リクエスト本文をバイト単位で完全一致させて翌日再生した結果、完全順位一致が 78/100 = 0.78 で、閾値 0.99 に届かなかった。
対照的に、5万件超（52,988試行）の配送・スキーマ妥当性・ハッシュ一致・メタデータ定数はいずれも100%。エンジニアリング上の欠陥はどこにもなかった。つまり「全テストがグリーンで全ハッシュが一致する」ことは再現性の必要条件であって十分条件ではない——これが主主張C1である。「完璧な実験」だからこそ、揺れの原因が実装ではなくジャッジ自身にあると特定できた。
なぜ揺れるのか：3つのメカニズム（M1〜M3）
論文は観測された揺れを、ラベル設計・タスク設計・プラットフォームという異なる層に分解した。
M1：ラベルが意味を汚染する——「ラベル意味マッピングバイアス」
プロンプト内で「Aが正しい」と候補に付すラベルの向きによって評価が偏る現象だ。ラベルを反転させると順位相関の中央値は −0.632 と負になり、順位がほぼ完全に逆転した。ラベル方向への好みが中央値 0.250ロジット（95パーセンタイル1.391）と正解シグナルと同程度に強く、読み出しが「正しさ」と「ラベルの向き」を混同してしまう。対処は正・逆2方向の平均を取る対称化（D1-S）だが、バイアス自体は消えない。
M2：7桁小さすぎる差を、順位付けしていた——「検出限界以下」
確率値そのものの再現性は中央値|Δr|=0.0067で閾値0.03を4.5倍のマージンで合格したのに、順位の再現性はSpearman中央値0.400と壊滅的だった。原因は、オブザーバーのノイズフロアが約10^-3〜10^-2であるのに対し、候補間最小ギャップの中央値が 3.04×10^-10 と7桁下にあり、順位ゲートが解像不能な差を要求していた点にある。誤差を人為注入した3,060判定（追試A-S3）でも、読み出しは「誤差の大きさ」ではなく「誤差のタイプ」で分離し、この測定器は大小を測るメーターとして機能しなかった。
M3：バイト同一なのに結果が変わる——プラットフォームの非決定性
バイト単位で完全同一のリクエストでも結果が変わる。100件の翌日再生で22件が別の順位を返し、ドリフトは25タスク中16タスクに波及した。モデル文字列・システムフィンガープリント・終了理由はすべて定数のまま、出力だけが変わっていた。原因は共有エンドポイントのバッチ化だ。浮動小数点演算はバッチサイズに不変ではなく（Thinking Machines Lab, 2025）、同時刻の他リクエスト次第でバッチ構成が変わり、微小な数値の変化が順位反転まで増幅される。「待てば直る」も否定され、同日リプレイ0.805と翌日0.800の差は等価バンド（|d|<0.03）内。4プロバイダ（3法域）はすべて同水準のフロア（0.74〜0.88）を示し、フィンガープリントも安定性を予測しなかった。
逃げ道を探る：メトリクス変更・サンプリング増・プロバイダ変更・自己ホスト
「測り方を変える」「回数を増やす」「プロバイダを替える」「自前で立てる」のすべてを、論文は事前登録の枠組みのまま検証し、いずれも測定器のフロアを根本から下げられないことを示した。
同じ22件のドリフトを3通りの指標で読むと、完全順位一致0.78、Top-1一致0.95、ペアワイズ一致0.986となり、「ほぼ安定」と「決定的失敗」が同じデータから同時に読める。指標の選択は見出しを変えるだけで、不安定性そのものは消えない。採点回数をM=8から500に増やし最大74万8千コールをシミュレートしても、ゲート通過は500回中0回だった。平均化はノイズを縮めても、差がゼロ近くに退化したグループではコイン投げの精度を超えられない。自己ホスト＋バッチ不変カーネル（vLLM 0.11.0）は静粛時に完全順位一致0.9872と全構成中で最良だったが、並行負荷では0.8925に低下し不一致が8.4倍に増えた。安定性は測定器単体ではなく、測定器と運用条件の組み合わせで決まる。
実務への示唆：測定器を「測ってから」、閾値を凍結する
最初にやるべきことは「閾値を決める」ことではなく「測定器を測る」ことだ。論文はこの規律を8つの設計ルールに整理している。要点は、(1)スナップショットを固定する（L0=モデル名のみ→L1=提供者固定スナップショット→L2=自己ホスト＋バッチ不変カーネル）、(2)一度も測ったことのない量に閾値を凍結しない、(3)順位ゲートは原理的に解像できる候補ペアだけで構成する、(4)完全一致の離散ゲートより等価バンド付きの連続読み出しを選ぶ、(5)複数回の集約を測定の定義に含める、(6)被測定量を「存在する差」になるよう設計する、(7)固定チェックリストで報告する、(8)パースできない入力は拒否する、の8つだ。
とくにパイロットテストは重要だ。全体の約2%（約1,000コール、実費CNY 3）の事前計測で、本番で失敗した2つのゲート（I-3Sの0.90、I-5Rの0.99）がどちらも到達不能と分かった。加えて論文の24項目チェックリストは、温度やシードと同列に「スナップショット同一性レベル」を必須メタデータとし、ノイズフロア・ギャップ分布・フィンガープリント状態・実行監査ログの報告を求める。「モデル名＋温度0＋シード固定」だけでは、何が固定され何が揺れうるかが第三者に伝わらないからである。
よくある質問
LLMジャッジはもう使えないのでしょうか？
使えなくなるわけではない。候補が十分に分離されたタスクでは順位は機能し、失敗の多くはタスク設計に起因すると論文自身も認めている。求められるのは「やめる」ことではなく、ノイズフロア（最小で読み取れる変化量）・ギャップ分布・監査境界を測ったうえで使うことだ。
温度0・シード固定なら再現するのでは？
再現しない。温度0のグリーディー復号でも、共有エンドポイントでは同じリクエストの順位が揺れる（M3）。原因はバッチ化によるカーネル計算順序の変化で、メタデータがすべて同一でもこの非決定性は予測も保証もできない。完全な再現は、バッチ不変カーネルを有効にした自己ホスト（L2）でも「静粛時のみ」という条件付きだ。
複数回呼んで多数決を取れば安定するのでは？
本研究の測定範囲では、平均化（M=8〜500、最大74万8千コール）はゲート通過率を0のまま動かさなかった。差自体がゼロに近い候補グループの順位は、ノイズを縮めても救えないためだ。ただし候補を意図的に分離可能に設計すれば話は別で、その場合も事前のパイロット計測が前提になる。
どのプロバイダを選べば安全ですか？
「安全なプロバイダ」は今回の測定では見つからなかった。4プロバイダ（3法域）はすべて同水準のフロア（0.74〜0.88）で、安定性はメタデータでは予測できなかった。プロバイダ選定より、スナップショットの固定・負荷影響の測定・複数回集約の測定単位化が先決だ。
まとめ：モデル名は「凍結された測定器」ではない
この論文の主張は、一文で言えば「共有エンドポイント上で、モデル名は凍結された測定器ではない」ということだ。実行層の完全性が100%でも順位の再現性は閾値（0.90／0.99）を大きく下回り、閾値を凍結する前に測定器そのもの（ノイズフロア・ギャップ分布・メタデータの意味）を測らなければならない。
報告には、観測した時間窓（同日か翌日か）とスナップショット同一性レベル（L0/L1/L2）の併記が新しい標準になるだろう。ただし、これは「LLMジャッジの否定」ではない。候補を意図的に分離可能に設計すれば順位は機能する。求められるのは「やめること」ではなく、測定器の性能を測ってからその性能範囲内で使う「計量学としての扱い」だ。実務では、①同じ入力を数回投げて揺れ幅を測る、②順位ゲートならギャップ分布を先に測る、③報告にスナップショットレベルを添える、の3つを追加コスト約2%で始められる。測定器を「モノ」として信じるのをやめ、「測ってから」閾値を凍結する——それがLLMジャッジを現場で使い続けるための最低条件である。
参考資料
- Clean Engineering, Unstable Measurement: A Preregistered Reliability Failure of Black-Box LLM Observers on Shared Endpoints（arXiv:2609.04198）: http://arxiv.org/abs/2609.04198
- 同論文HTML全文: https://arxiv.org/html/2609.04198v1
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena（Zheng et al., 2023）: http://arxiv.org/abs/2306.05685
- Rating Roulette: Self-Inconsistency in LLM-As-A-Judge Frameworks（Haldar & Hockenmaier, 2025）: https://arxiv.org/abs/2510.27106
- Non-Determinism of "Deterministic" LLM Settings（Atil et al., 2024）: https://arxiv.org/abs/2408.04667
- Reliability without Validity: A Systematic, Large-Scale Evaluation of LLM-as-a-Judge Models（Norman et al., 2026）: https://arxiv.org/abs/2606.19544
- vLLM Batch Invariance（バッチ不変性の有効化方法・対応モデル）: https://docs.vllm.ai/en/latest/features/batch_invariance/
- Thinking Machines Lab「Defeating Nondeterminism in LLM Inference」: https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/
- breckbaldwin/llm-stability（Atil et al. 2024のコード）: https://github.com/breckbaldwin/llm-stability
- IAAR-Shanghai/xFinder（LLMを自動評価器として使う信頼性研究、ICLR 2025）: https://github.com/IAAR-Shanghai/xFinder
- RANDCorporation/judge-reliability-harness: https://github.com/RANDCorporation/judge-reliability-harness