AIがAIを採点すると、同じところで間違える。AgentJudgeBenchが示した評価の落とし穴
AIエージェントに仕事を任せたあと、その結果を別のAIに採点させる。人がすべての実行ログを読むより速く、評価件数も増やしやすい。いまの開発現場では、かなり魅力的な方法です。
ところが、採点役を6種類に増やしても、難しいツール呼び出しでは同じような点数に集まりました。正解の実行手順を見せない条件では、4つの生成モデルに対する採点結果が、おおむね77%から82%の狭い範囲へ収束したのです。6人の審査員を集めても、全員が同じ見落としをしていたら安心材料にはなりません。
ServiceNow AIの研究チームが公開したAgentJudgeBenchは、エージェントのツール呼び出しをLLM judgeに採点させるとき、どこで信頼性が崩れるのかを細かく調べたベンチマークです。結論を先に言えば、強いモデルを1つ置くだけでは足りません。採点項目を分け、機械的に確認できる部分は機械で確認し、AI同士の不一致を人へ戻す設計が必要です。
文章の上手さではなく、仕事の順番を採点する
一般的な文章評価なら、要約が読みやすいか、質問に答えているか、説明が自然か、といった観点で比べられます。しかし、ツールを使うエージェントの正しさは、文章の印象だけでは決まりません。
たとえば「障害チケットを読み、過去事例を検索し、影響範囲を確認してから対応案を出す」という仕事を考えてみます。見た目が立派な回答でも、検索条件が間違っていたり、確認より先に更新処理を走らせたり、依頼の一部を落としたりすれば失敗です。
AgentJudgeBenchは、この正しさを4つに分けました。
- 必要なツールを選べたか
- 引数の名前と構造は正しいか
- 依存関係に沿った順番で呼べたか
- ユーザーの依頼を漏れなく扱ったか
評価対象は3,808件です。15の企業業務領域から合成され、処理のつながりは6種類あります。一直線に進むlinear、複数の処理へ枝分かれするfan-out、枝を最後に合流させるfan-in、分岐と合流を含むdiamondなどです。質問文もeasy、medium、hardの3段階に書き換えられています。
ここで重要なのは、難しい質問ほど単に長くなるわけではない点です。easyでは必要な処理が明示され、hardでは依頼の意図から必要な手順を復元しなければなりません。実務でよくある「細かい手順は書かれていないが、目的は達成してほしい」に近い条件です。
5つの実行モデルを、6つの採点AIで評価した
実験では、4つのオープンウェイトモデルとGPT-5.4の計5モデルにツール呼び出し案を作らせました。その結果を、GPT-OSS-20B、QwQ-32B、GPT-OSS-120B、Claude Sonnet 4.5、Gemini 2.5 Pro、GPT-5.4の6種類が採点します。
各採点AIには2つの条件が用意されました。
1つは、正解となるツール呼び出し列を見せる条件です。採点AIは候補と正解を比較できます。もう1つは、正解を見せず、ユーザーの依頼と利用可能なツール定義だけから良し悪しを判断する条件です。
研究チームは、採点AIそのものを正解役にしませんでした。ツール選択、引数構造、順序、依頼の網羅性を規則で照合する、決定的なプログラムを基準にしています。別のLLMを正解役に置けば、「そのLLMの採点は正しいのか」という問題が1段上へ移るだけだからです。
最終的に、生成モデル、採点AI、難易度、レコードを組み合わせた321,648件の評価単位がそろい、それぞれで正解ありと正解なしを比較しました。公開コードには、データ準備、ツール呼び出し生成、LLM judge、プログラム採点、集計の処理が含まれています。Hugging Faceのデータセットも公開されており、結果を数字だけでなく構造から追える点は大きな強みです。
難しくなるほど、採点AIは一緒に迷う
全30通りの生成モデルと採点AIの組み合わせで、easyからhardへ進むほど一致率は単調に下がりました。しかも、正解を見せない条件の落ち込みは、正解を見せる条件のおよそ1.5倍です。
特にhardかつ正解なしでは、4つの生成モデルに対する6種類の採点AIが、77%から82%ほどの範囲へ集まりました。採点AIを束ねた6モデルのアンサンブルも79.5%で、最良の単独モデル79.8%と0.4ポイント以内です。
これは「6つ使えば多数決で安全になる」という期待に冷や水を浴びせます。誤りが独立していれば、複数モデルを組み合わせる意味があります。しかし全員が、暗黙の依頼から正しい手順を復元する同じ場所でつまずけば、多数決は同じ盲点を濃くするだけです。審査員を増やしたのに、会議だけ長くなる。ちょっと切ないやつです。
正解なしで採点AI同士の一致率が高くなる現象にも注意が必要です。平均一致率は正解ありの79.1%から、正解なしでは92.6%へ上がりました。ただし研究チームは、これを強い合意とは見ていません。難しい例で似た点数へ圧縮されるため、見かけ上そろっているだけだと分析しています。
つまり、採点AIが同じ答えを返したことと、正しく判断できたことは別です。監視画面に6つの緑色ランプが並んでも、その6つが同じセンサーを見ているなら、安心はできません。
正解を見せれば必ず良くなるわけでもない
では、期待するツール呼び出し列を採点AIへ見せれば解決するのでしょうか。
多くの場合、正解は助けになります。しかし全モデルで一様ではありませんでした。GPT-5.4は正解を見せたときに1.5ポイント、Gemini 2.5 Proは3.9ポイント、プログラム基準との一致率が下がりました。論文は、提示された正解へ引っ張られすぎるover-anchoringと整合する結果だと述べています。
これは実務でも起こり得ます。期待手順が与えられると、採点AIは「候補が正解に似ているか」へ注意を寄せすぎます。その結果、別の正しい方法や、正解側に含まれる不自然な点を十分に検討しない可能性があります。
研究では、正解を別レコードのものへすり替える追加実験も行われました。強い生成モデルでは、壊れた正解を見せても単純に全部従ったわけではありません。一方、プロンプトの初期値や生成モデルの品質によって影響の大きさが変わりました。ここから言えるのは、正解を見せるか見せないかを二択で決めるのではなく、両条件の差そのものを監視する価値があるということです。
効いたのは、長く考えさせることより採点表だった
LLMの評価精度を上げようとすると、まずchain-of-thoughtで長く考えさせたり、temperatureを調整したりしたくなります。AgentJudgeBenchでは、この2つの効果は小さなものでした。
chain-of-thoughtの差は24組の比較で最大0.3ポイント。temperatureの差も、1つ目の組み合わせで最大0.6ポイント、別の組み合わせでは最大0.25ポイントでした。
一方、4項目を個別に判定させる構造化ルーブリックは、ある組み合わせで自由形式の短い指示より4.8から6.5ポイント高くなりました。採点AIに「総合的に正しいか」と聞くより、ツール選択、引数、順番、依頼の網羅性を分けて答えさせるほうが効いたのです。
ただし、ここにも留保があります。2つ目の組み合わせでは、改善はeasyで3.88ポイント、mediumで2.35ポイントに縮まり、hardでは逆に0.83ポイント下がりました。構造化すれば必ず6.5ポイント良くなる、とは言えません。ルーブリックは有力な設計レバーですが、採点AI、評価対象、難易度ごとに確かめる必要があります。
人間を基準にすると、モデルの順位が変わった
プログラム採点は大量の評価を同じ規則で処理できます。ただし、その規則が人の判断と完全に一致するとは限りません。
研究チームはhardの120件を1人の訓練済みアノテーターに評価してもらいました。プログラムとの一致率は、4項目のうち3項目で92.5%から98.3%でしたが、引数構造では82.5%まで下がりました。プログラムは、型として許される余分なキーも厳しく減点する一方、人は受け入れることがあったためです。
この人の判定を基準に採点AIを見ると、Gemini 2.5 Proは68.0%、GPT-OSS-120Bは79.4%でした。プログラム基準で82.9%と首位だったQwQ-32Bは、人基準では74.3%で4位へ下がります。
この結果は「GPT-OSS-120Bが普遍的に最良」という証明ではありません。120件を1人が評価した小さな検証で、複数人の合意ではないからです。むしろ大事なのは、何を正解とするかでモデル順位が変わったことです。
厳密なスキーマ順守を守りたいのか、人が見て業務上許容できる柔軟性を重視するのか。評価基準の目的を決めずに、LLM judgeのランキングだけを選んでも、運用の正しさにはつながりません。
実務では、1つの点数を4層に分解する
ここからは論文の実験結果を踏まえた、AICompanyの実装提案です。論文が次の構成を本番環境で検証したわけではありません。
第1層は決定的な検査です。存在しないツール名、必須引数の欠落、JSON Schema違反、禁止された呼び出し、明白な順序違反は、LLMに聞く前にコードで落とします。再現できる失敗を、確率的な採点へ渡す必要はありません。
第2層は項目別のLLM judgeです。総合点を1つ返させず、ツール選択、引数、順番、依頼の網羅性を独立して判定させます。各項目には根拠となるログ位置も返させ、あとで確認できる形にします。
第3層は条件差の監視です。期待する実行手順を見せた採点と、見せない採点を比べます。正解ありだけが高い場合は参照への依存、正解なしだけが高い場合は期待手順側の過剰な厳しさを疑えます。
第4層は不一致の扱いです。採点AI同士が割れた例だけでなく、全員が0.5付近へ集まった例、機械検査とLLM judgeが衝突した例を人へ戻します。「全員一致だから自動承認」ではなく、「どの根拠で一致したか」を見る設計です。
この4層を使えば、LLM judgeを捨てずに、得意な部分へ限定できます。曖昧な意図や複数の妥当な手順を読む仕事はLLMに向いています。一方、型、必須項目、アクセス権、実行順序の一部はコードのほうが堅い。役割分担こそが、評価の信頼性を上げます。
まだ証明されていないこと
AgentJudgeBenchは大規模ですが、3,808件は実企業のログではなく合成データです。正解のツール列を大規模に用意するための合理的な選択ではあるものの、現場の壊れたスキーマ、古い説明文、途中で失敗したAPI、権限不足、曖昧な社内用語までは再現していません。
6つの主要な採点AIはすべて汎用モデルです。評価専用モデルPrometheus-2も追加されていますが、主要6モデルより20から30ポイント低く、別の集団として扱われました。この1モデルだけで、評価専用モデル全体を判断することはできません。
また、GPT-5.4は再現できないAzureのプレビュー版です。閉じたAPIとオープンウェイトモデルでは、temperatureなどの設定も完全にはそろっていません。公開コードは追えますが、AICompanyは複数の大規模モデルと有料APIを必要とする全321,648件の実験を再実行していません。
さらに、この研究が測ったのは評価時点の一致率です。LLM judgeの点数を学習報酬に使ったとき、モデル選択のゲートに使ったとき、本番の失敗率がどう変わるかは未検証です。採点精度の差が、そのまま製品品質の差になるとは限りません。
結論
AgentJudgeBenchが突きつけたのは、AIによる自動評価をやめるべきだ、という話ではありません。1つのLLM judgeが返す総合点を、客観的な正解だと思わないことです。
難しいツール呼び出しでは、モデルを大きくしても、審査員を増やしても、同じ場所で判断が圧縮されました。正解を見せることさえ、モデルによっては一致率を下げます。一方で、評価項目を分けた採点表は有力な改善策になりました。
エージェントを本番へ出すなら、見るべきは「何点だったか」だけではありません。どの項目で、どの根拠に基づき、正解ありと正解なしで判断がどう変わったか。その記録まで残して初めて、AIの採点を運用に使えます。