9月4日、Haoyuan ZhuとJie Zhangが「Clean Engineering, Unstable Measurement: A Preregistered Reliability Failure of Black-Box LLM Observers on Shared Endpoints」と題した論文をarXivで公開した。LLMをジャッジ（評価器）として使う際、共有エンドポイント上では同一モデル名への同一リクエストが再現性のある結果を返さないという、信頼性の根本的な失敗を5万件超のリクエストで検証した内容だ。
LLMジャッジという「測定器」の前提が崩れている
LLM（大規模言語モデル）を評価器として使う手法——いわゆる LLM-as-a-Judge——は、ここ数年で急速に普及した。Zheng et al. (2023) の MT-Bench / Chatbot Arena 論文がその基盤を築いて以降、訓練データのフィルタリング、生成結果のスコアリング、リーダーボードの順位付けなど、あらゆる場面でLLMが「ジャッジ」として機能している。
この手法が成立するには、暗黙の前提が必要だ。「同じモデル名に同じリクエストを送れば、明日も同じ結果が返ってくる」というものである。本論文はその前提を正面から検証した。
52,988リクエストで何が起きたか
研究チームは事前登録（preregistered）という手法を採用した。これは、すべての閾値や判定基準を実験開始前に固定し、後から条件を調整する「都合のいい解釈」を排除するものだ。心理学・医学分野では標準的な手続きだが、LLM評価研究への適用は珍しい。2回のキャンペーンを実施したが、どちらも評価器（測定器）の検証段階で失敗した。
具体的な数字を見ると深刻さがわかる：
- 同一ウィンドウ内での繰り返しランキングのSpearman相関：0.400（要求水準は0.90）
- バイト完全一致の翌日リプレイでのSpearman相関：0.78（要求水準は0.99）
Spearman相関係数は順位の一致度を示す指標で、1.0が完全一致、0が無相関を意味する。ここで求められる0.90や0.99という閾値は「測定器として信頼できる水準」として事前に設定されたものだ。実際の値はその水準を大きく下回っており、まったく同じ入力を送っても、同じセッション内ですら順位付けがバラバラになることを示している。翌日に再現しようとすればさらに悪化する。合計52,988リクエストを費やしても、測定器として使える水準に達しなかった。
なぜズレるのか：3つのメカニズム
論文は再現性の崩壊を引き起こす3つのメカニズムを特定している。
1. ラベルと意味のマッピングのバイアス
スコアリングに使うラベル（例：「良い」「悪い」といった出力形式）が、測定したいシグナルと同程度かそれ以上に強くランキングを歪める。ラベル設計そのものが測定ノイズになる。
2. 候補間のギャップが測定器のノイズフロアを7桁下回る
評価対象のモデル間の差分が極めて微小な場合、LLMジャッジ自身のノイズが信号を完全に覆い隠す。測定器の精度が対象の差異に対して根本的に不釣り合いである。
3. バイト完全一致の入力が異なるランキングを返す
同一の入力（バイト列レベルで完全一致したもの）を送っても異なる出力が返ってくる。この挙動により、順列検定（exact-permutation test）——「同じ入力には同じ出力が返る」という仮定に基づいてランダム性を統計的に評価する手法——においてノイズが増幅され、検定そのものが成立しなくなる。
「待つ」「プロバイダーを変える」は解決策にならない
研究チームは複数の回避策も検証した。結果はいずれも芳しくない：
- 時間を置く（waiting）：サンプリングした日において効果なし（0.805 vs 0.800、さらに5日間にわたって再現）
- プロバイダーを変える：4つのプロバイダーを試したが、中央値は0.74〜0.88の範囲に留まり、いずれも閾値を満たさなかった。プロバイダーが公開するメタデータフィールドからこの差は予測できなかった
- セルフホスティング（バッチ不変カーネル）：サーバーが静穏な状態のときのみ有効。負荷がかかると崩れる
- サンプリング数の変更・指標の代替：テストしたグリッドの範囲では修復できなかった
また、既知のギャップを持つ構築済みエラーで検証したところ、ジャッジのスコアはエラーの大きさではなくエラーの種類に追随することが示された。測定器が「何を測っているか」自体が疑わしい。
実務への示唆：3段階ラダーと8つの設計ルール
論文は知見を以下のかたちで整理している：
- 3レベルの「スナップショット同一性ラダー」：共有エンドポイントにおけるモデルの安定性をどのレベルで仮定できるかを段階的に示す
- 8つの設計ルール：LLMジャッジを測定器として使う際の設計上の原則
- 報告チェックリスト：評価結果を公開する際に開示すべき項目
また、本研究のコール量の約2%に相当するパイロット実験を事前に行っていれば、到達不可能だった2つのゲートを事前に検出できたと述べている。事前の測定器検証がいかに重要かを示す知見だ。
「モデル名は凍結された測定器ではない」
論文の結論は明快だ。共有エンドポイント上では、モデル名は凍結された測定器ではない。事前登録された評価においては、いかなるゲートも固定する前に、まず測定器自体を測定しなければならない。なお本論文はarXivで公開されたプレプリントであり、現時点では査読を経た知見ではない点は留意が必要だ。
LLM-as-a-Judgeを評価パイプラインに組み込んでいる開発者・研究者にとって、この論文が提起する問題は避けられない。自分たちのベンチマークが「何を測っているか」を問い直す必要がある。
詳細はClean Engineering, Unstable Measurement: A Preregistered Reliability Failure of Black-Box LLM Observers on Shared Endpointsを参照していただきたい。
