レッスン4: LLM ジャッジ: ルーブリック、フォーマット、そして判定させてはいけないもの

学習目標:

• 自由記述テキストの出力に対する多次元ルーブリックを書き、各次元の問いを明確にし、1つの成功基準を評価しきるのに複数のルーブリックが必要になることを理解する
• ジャッジの出力をプログラムが扱える形に絞り込む。先に根拠、次にスコア、0.0–1.0 と合否の組み合わせ、そして別々の側面を複数のジャッジに評価させるより1回の呼び出しのほうが安定しやすい理由を説明する
• ジャッジの3つの失敗モード——自分の作業を採点する、問題を探せと言われたので必ず見つける、エージェントの自己申告だけを信じる——を認識し、それぞれに実行可能な緩和策を示す

前提: レッスン1〜3、「終状態優先」の評価と決定的検証の優先順位を理解していること | 前: << レッスン3 | 次: レッスン5 >>

レッスン3の天井と、LLM ジャッジの居場所

リサーチエージェントにタスクを渡しました。国内の EV 充電補助金がこの3年でどう変わったかをまとめ、2ページのブリーフにすること。15分間動き続け、検索ツールを呼び、PDF を取得し、1,800語を書き上げました。読んだ感じはもっともらしい。

さて検証したいのですが、レッスン3の決定的チェックはここでは1つも使えません。走らせるテストスイートはなく、読み取るビルドの終了コードもなく、output == golden_answer に渡す golden_answer も書けません——同じブリーフを2人のアナリストに書かせても、同一のテキストにはならないからです。

これは想像力の欠如ではありません。この種の出力とはそういうものです。Anthropic が自社のマルチエージェント・リサーチシステムを振り返ったとき、彼らははっきりこう述べています。リサーチの出力は自由記述テキストで、唯一の正解を持つことはまれなのでプログラム的に評価するのが難しく、こうした出力の採点には LLM が自然に適している¹。

ただし、そのブリーフを気軽に別のモデルに投げて「これどう？」と聞く前に、LLM ジャッジが公式のランキングのどこに位置するかを理解しておいてください。採点方法を選ぶ原則は "fastest, most reliable, most scalable"（最速・最も信頼でき・最もスケールする）です²。コードベースの採点は最も速く最も信頼でき、極めてスケールしますが、ルールベースの厳密さを緩める必要のある複雑な判断ではニュアンスを欠きます²。LLM ベースの採点は速く柔軟でスケールし、複雑な判断にも向いています——そして公式ガイダンスは同じ一文の中に前提条件を添えています。まず信頼できることを確かめるテストをしてから、スケールさせること²。人間による採点は最も柔軟で品質も高いものの、遅くコストがかかるため、可能なら避けます²。

真ん中の選択肢に付いているこの前提条件は、免責文ではなくハードな要件として扱ってください。LLM ジャッジは「より賢いチェック」ではなく、モデル呼び出しです。間違えることがあり、お金がかかり、同じ入力に対して実行のたびに違うスコアを出すこともあります。その価値はただ一点——決定的チェックが届かないところに届くことです。

だからこのレッスンは「モデルに出力を採点させる方法」の話ではありません。それは簡単です——どんなプロンプトでも数字は返ってきます。このレッスンの主題は、その数字を信頼に足るものにすることです。ルーブリックをどう構成するか、出力をどう制約するか、誰にジャッジを走らせるか、どう壊れるか、そしてそもそも聞くべきでないのはいつか。

ルーブリック: 「良い」を個別に答えられる問いに分解する

ルーブリックというと堅く聞こえます。平たく言えば採点表です。漠然とした「これは良いか」を具体的な問いに分解し、それぞれ個別に答え、個別にスコアを付けます。

なぜ分解するのか。「このブリーフは良いか」と聞けば、モデルは漠然とした賞賛か漠然とした批判を返します。「ブリーフ内のすべての主張が、引用元のソースに現れているか」と聞けば、モデルは主張を1つずつ確認できます。ほとんどのユースケースでは、複数の成功基準に沿った多次元の評価が必要です²。

Anthropic のリサーチエージェントは5次元のルーブリックを使っていました¹。各次元の背後には、実在の失敗モードがあります。

• 事実の正確性——主張はソースと一致しているか？ モデルが「2023年に補助金が30%減った」と書いたとき、引用された文書に本当にその数字があるか。この次元はハルシネーションを捕まえます。
• 引用の正確性——引用されたソースは主張と対応しているか？ 前の次元とは逆向きで、この2つを混同する人は多いです。前者は「この記述に裏付けがあるか」を問い、こちらは「この文に付いたリンクは、本当にこの話題を論じているか」を問います。よくあるエージェントの失敗は、主張自体は正しいのに、タイトルが関連ありそうに見えただけのソースが貼られている、というものです。
• 完全性——要求されたすべての側面をカバーしているか？ 「この3年」と言ったのに去年のことしか書いていない、「変化」と言ったのに現状しか書いていない。要求を1つずつ確認するのであって、文章がきれいかどうかを評価するのではありません。
• ソースの品質——一次ソースか、質の低い二次ソースか？ この次元が捕まえる問題が一番たちの悪いものです。Anthropic の人間テスターはこう見つけました。初期のエージェントは、学術 PDF や個人ブログのような権威はあるが検索順位の低いソースよりも、SEO 最適化されたコンテンツファームを一貫して選んでいた¹。出力は完全に普通に読めるのに、土台が腐っています。
• ツール効率——適切なツールを、妥当な回数で呼んだか？ 同じ答えに3回の検索でたどり着くのと30回かかるのとでは、コストが桁で違います。この次元が評価するのはプロセスの経済性であって、「私が指定した手順に従ったか」ではありません——後者が機能しないことはレッスン2で説明したとおりです。

この5次元はリサーチタスク向けのものです。タスクが違えば必要な組み合わせも変わります。持ち帰るべきなのは分解の方法です。「この出力が壊れるとしたら、どう壊れるか」から出発し、そこから次元を導き、失敗モード1つにつき次元1つを対応させます。もう1つ見落とさないでください。あるユースケース、あるいはそのユースケースの特定の成功基準1つですら、全体的に評価するには複数のルーブリックが必要になることがあります²。1枚の採点表ですべてを覆えると期待しないでください。

出力フォーマット: 1回の呼び出し、1つのスコア、1つの合否

まず判定の形から。 Anthropic は複数のジャッジに別々のコンポーネントを評価させる——コンポーネント1つにつきジャッジ1つ——という構成を試しました。結果は、単一のプロンプトによる単一の LLM 呼び出しで 0.0-1.0 のスコアと合否グレードを出力させる方式が、最も一貫していて人間の判断とも合致した、というものでした¹。

公平を期すなら、評価を複数の LLM 呼び出しに分割し、各呼び出しで1つの側面を評価するというやり方も、公式ガイダンスが記述してきた評価自動化のパターンそのものです³。どちらのアプローチも間違いではありません。違いは、「単一呼び出しのほうが良い」が Anthropic 自身の実システム上での比較から出てきた結論だという点です¹。推奨する進め方は、まず単一呼び出しから始め、分割したほうが精度が上がるという証拠が得られたときにだけ分割することです。

次に、出力をどれだけきつく縛るか。 ジャッジプロンプトに関する公式ガイダンスは "empirical or specific"（経験的または具体的）です。たとえば LLM に 'correct' または 'incorrect' だけを出力させる、あるいは1〜5のスケールで判定させる。純粋に定性的な評価は、素早く大規模に扱うのが困難です²。平たく言えば、ジャッジが「全体的な品質は許容範囲だが、一部の細部の扱いがやや粗い」と返してきても、あなたの手元には何も残りません——そういう回答を200件平均することはできず、今日が昨日より良いかも分からず、結局1件ずつ読むはめになります。それならジャッジに聞く意味は何でしょうか。

決定的なテクニック: 先に根拠を書かせ、次にスコアを出させ、根拠は捨てる。 公式ガイダンスはこれを明示しています。評価スコアを出す前にまず LLM に推論させ、その推論は捨てる——これは評価性能を高め、とくに複雑な判断を要するタスクで効きます²。「捨てる」は「見るな」という意味ではありません。推論はジャッジにとっての足場です——正確に判定するには、「3段落目の主張はトランスクリプトのどの部分に対応するか」を先に書き出す必要があります。ただしそのテキストが下流の集計に入ってはいけません。レポートが欲しいのはスコアと合否で、推論はログに送られ、スコアが怪しく見えたときにあなたを待っています。

主観的な次元はどうするか。 二値にできない次元もあります。たとえば「このブリーフのトーンは顧客に送るのに適切か」。公式ガイダンスは道具を1つ用意しています。LLM ベースのリッカート尺度で、主観的な態度や認識を LLM に判定させるものです²——リッカート尺度とは「強く反対 / 反対 / どちらでもない / 賛成 / 強く賛成」のような、目盛りが固定されたアンケート形式のことです（何段階にするかは調査設計上の慣習であって、公式が定めたものではありません）。原則は変わりません。目盛りを固定して与え、自由記述にさせないことです。

まとめると、ジャッジの出力はおおよそ次のような形になります（例は最初の3次元のみ。source_quality と tool_efficiency も同じ形なので、簡潔さのため省略しています）。プログラムが読むのは score と verdict で、reasoning はレビュー用に永続化します。

作業した本人にジャッジさせない

ここで魅力的な近道が見えてきます。最後にエージェント自身に採点させればいい。何をやったかは本人が一番よく知っている、と。

その誘惑は抑えてください。理由は2つです。1つめは公式の経験則です。 1つのモデルインスタンスがユーザーのクエリを処理し、別のインスタンスが不適切な内容や要求をスクリーニングするというガードレールの実装は、同じ LLM 呼び出しにガードレールと本体の応答の両方を担わせるより、うまくいく傾向があります³。この経験はもともとコンテンツモデレーション（一方が応答し、もう一方がスクリーニングする）を説明したものですが、「同じ呼び出しに2つの帽子をかぶらせない」という原則はここにも当てはまります。「同じ呼び出し」と言っている点に注意してください——問題は共有されたコンテキストであって、知能が足りないことではありません。2つめはメカニズムです。 Claude Code 公式ドキュメントは、まっさらなサブエージェントのコンテキストで動くレビュアーは差分とあなたが与えた基準しか見えず、その変更を生んだ推論は見えないため、結果そのものを独自の土俵で評価する、というプラクティスを記述しています⁴。

これを逆から読むと、自己採点が失敗する理由が見えます。出力を生んだ推論の連鎖が、まだコンテキストにぶら下がったままなのです。モデルはたった今「こう書くのが正しい」と自分を納得させたところで、あなたはすぐさま「これは正しいか」と聞く。返ってくるのは同じ理屈の繰り返しである可能性が高い。得られるのは独立した判断ではなく、自己反復です。

ジャッジが甘すぎる、あるいは厳しすぎるのが心配なら、公式ガイダンスがノブを1つ用意しています。あるコンテンツが不適切かどうかの評価では、複数のプロンプトに異なる側面を評価させたり、投票のしきい値を変えたりして、偽陽性と偽陰性のバランスを取ります³。検証のシナリオでは、偽陽性は「問題ないものを壊れていると報告する」ことで、誤報に悩まされ続けます。偽陰性は「壊れているものを通す」ことで、まずい成果物が出荷されます。3人のジャッジのうち2人が fail と言って初めて fail とするのは、1人が fail と言えば fail とするより甘い設定です——どちらを選ぶかは、あなたのシナリオでどちらの誤りのコストが高いかで決まります。

ジャッジはどう壊れるか

別インスタンスに切り替え、ルーブリックも書いた。それでもジャッジは壊れます。壊れ方には予測がつきます。

その1: 問題を探せと言われたレビュアーは、必ず問題を見つける。 最も直感に反し、最もコストが高い壊れ方です。公式ドキュメントは明確です。ギャップを探すよう指示されたレビュアーは、作業が健全であっても何かしら報告するのが普通です。そう指示されたのだから、というだけの理由で⁴。その帰結は「役に立たない提案が数件」では済みません。同じ箇所は、すべての指摘を追いかけると過剰設計につながると指摘しています——余分な抽象化レイヤー、防御的なコード、起こり得ないケースのためのテスト⁴。あなたのエージェントは自己エスカレーションのループに入ります。レビュアーが3つ提案し、あなたが直し、再レビューがさらに3つ提案し、コードは厚くなり、本当の問題は手つかずのまま残ります。

こういうレポートを見たことがあるはずです。「parseDate に空文字列への防御を追加することを推奨」——しかし上流がすでに非空を保証している。「この3つの定数を設定ファイルに切り出すことを推奨」——しかし3年間変更されていない。「ネットワークタイムアウトのリトライテストを追加することを推奨」——しかしこのパスにネットワーク呼び出しはない。3つとも間違いではなく、3つともやる価値はなく、しかしレビューレポートに混ざると本物の問題と見分けがつきません。

公式ガイダンスは緩和策を示しています。正しさや明示された要件に影響するギャップだけを報告するようレビュアーに指示し、それ以外は任意扱いにすること⁴。これをそのままジャッジプロンプトに書き、「その他の提案」の行き先も用意します——optional_notes フィールドを追加し、これは採点に関与しないと明記します。書く場所があれば、スタイルの好みを減点理由に押し込む必要がなくなります。

その2: エージェントの自己申告は証拠ではない。 近道として、エージェントの最終サマリーだけをジャッジに渡す人は多いです。「権威あるソースを3件取得し、相互チェックしたうえで補助金率を確定しました」。ジャッジはそれを読み、プロセスは堅実そうだと考え、高いスコアを付けます。しかしこの記述は証拠ではありません。ツール評価に関する公式ガイダンスがこの点を突いています。エージェントがフィードバックや応答で省略したことのほうが、含めたことよりも重要な場合が多い——LLM は必ずしも自分が意味することを口に出さない⁵。「3件のソースで相互チェックした」と書いていても、実際には検索を1回しか呼んでいないかもしれません。言及されないリトライの失敗、空の結果を受け取ってもなお捏造を続けたその瞬間こそ、あなたが最も見る必要のあるものです。解決策も直截です。生のトランスクリプト（ツール呼び出しとツールの応答を含む）をレビューして、エージェントの思考連鎖に明示されていない挙動を捕まえること⁵。解決策に翻訳すると、ジャッジの入力には自己申告だけでなく生ログを含めなければならない、ということです。とくに「ツール効率」の次元にはこれが要ります——実際の呼び出し回数と、その呼び出しが正しかったかを評価するのであり、その情報はログにしか存在しません。

その3: 問いそのものが曖昧である。 厳密にはこれはジャッジが壊れているのではなく、あなたが壊れた問いを与えているのです。評価設計に関する公式ガイダンスは、避けるべきカテゴリに名前を付けています。人間でも評価の合意に達するのが難しいような曖昧なテストケースです²。これはジャッジを検証しているときに見つかります。あなたと同僚が同じ出力を判定して、逆の結果になる。あわててジャッジプロンプトを直そうとしないでください——ジャッジが「不正確」なのは、この問いに正確な答えが存在しないからです。人間が合意できるところまで基準を精緻化するか、このケースを取り除くかです。これを使ってジャッジの一致率を計算しても、自分を欺く数字が出てくるだけです。

レビュー・修正ループを作るべきとき

ジャッジが終わったらそこで完了なのか、それともそのフィードバックをエージェントに戻して修正させ、もう一度ジャッジするのか。このループは魅力的で、そして簡単にトークンを燃やす永久機関になります。

公式ガイダンスは、このワークフローが本当に適合する場合の2つのシグナルを示しています³。1つめは、人間がフィードバックを言語化すると LLM の応答が明らかに改善すること。2つめは、その種のフィードバックを LLM 自身が提供できること。同じ箇所には前提も添えられています。このワークフローがとくに効くのは、明確な評価基準があり、反復的な洗練が測定可能な価値をもたらす場合です³。

この2つの条件を入場テストとして使ってください。やり方は単純です。まずあなたがジャッジになり、エージェントにフィードバックを書き、修正後に実際に良くなるかを見ます。人間が書いたフィードバックで動かないなら、LLM が書いたフィードバックではもっと動きません。その時点で直すべきなのはプロンプトかツールであって、レビュー層を足すことではありません。逆に人間のフィードバックが明らかに効くなら、2つめの条件を確認します——ルーブリックに照らして LLM にフィードバックを書かせ、あなたのものと比べます。両方通ったら、そのループは作る価値があります。

見合った使い方: ジャッジもまたモデル呼び出しである

レッスン3のランキングに戻ります。採点方法を選ぶ原則は最速・最も信頼でき・最もスケールすることであり²、コードベースの採点はその3つすべてで LLM ベースの採点より上位です²。つまりジャッジは、決定的チェックが届かないところに置くのであって、その置き換えではありません。同じブリーフに対する正しい階層はこうなります。

第1層（決定的、ミリ秒、コストゼロ）  JSON / Markdown として妥当か？ 長さは要求範囲内か？  引用リンクは到達可能か（HTTP ステータス）？ 引用数 >= 3 か？  1つでも落ちたら → 即 fail、ジャッジは呼ばない
第2層（LLM ジャッジ、秒オーダー、トークン課金）  5次元ルーブリックによるスコアリング + 合否  入力: タスク要件 + 出力 + 生ログ（ツール呼び出しと応答）
第3層（人間、遅くて高い、抜き取りのみ）  ジャッジは fail と言ったが腑に落ちない  ジャッジが pass と言ったものを無作為抽出し、系統的な甘さを監視する

第1層で捕まるものを第2層に送って料金を払わないでください——フォーマットとして妥当ですらない出力に、受け入れられないと教えてもらうためのモデル呼び出しは不要です。第3層は省けません。エージェントをテストする人間は、評価が見逃すエッジケースを見つけます¹。先ほどの「一貫してコンテンツファームを選ぶ」バイアスも、人間によるテストで見つかったものです¹。

このレッスンの境界: 評価セットをどう組むか、このジャッジを何件のケースに対して走らせるかはレッスン5です。ジャッジを繰り返し実行可能な評価ハーネスに組み込んでレポートを出すのはレッスン6です。このレッスンが解くのは、1回の判定をどう信頼に足るものにするかだけです。

💻 演習

まとめ

• 自由記述テキストの出力には唯一の正解がなくプログラム的な評価が難しいため、こうした出力の採点には LLM が自然に適しています¹。ただし LLM ベースの採点に対する公式の位置づけは「速く、柔軟で、スケールし、複雑な判断に向く——前提条件として、まず信頼できることを確かめるテストをしてからスケールさせる」です。人間による採点は最も柔軟で品質も高いものの、遅くコストがかかるので可能なら避けます²。
• ルーブリックは「良い」を個別に答えられる問いに分解します。リサーチタスク向けの出来合いの分解は5次元です。事実の正確性、引用の正確性、完全性、ソースの品質、ツール効率¹。あるユースケース、あるいはその中の1つの成功基準ですら、全体的に評価するには複数のルーブリックが必要になることがあります²。
• 出力の形については、単一のプロンプトによる単一の LLM 呼び出しで 0.0-1.0 のスコアと合否グレードを出す方式が、実測で最も一貫し人間の判断とも合致しました¹。LLM には 'correct' / 'incorrect' や1〜5を出力させること。純粋に定性的な評価は素早く大規模に扱うのが困難です²。評価スコアを出す前にまず LLM に推論させ、その推論は捨てる——これは評価性能を高め、とくに複雑な判断で効きます²。主観的な次元には LLM ベースのリッカート尺度が使えます²。
• 作業した本人にジャッジさせない。1つのモデルインスタンスがクエリを処理し別のインスタンスがスクリーニングするガードレールは、同じ呼び出しに両方を担わせるよりうまくいく傾向があります³。まっさらなコンテキストのレビュアーは出力とあなたの基準しか見えず、その出力を生んだ推論は見えないため、結果そのものを独自の土俵で判定します⁴。複数プロンプトによる評価と投票のしきい値は、偽陽性と偽陰性のバランスを取ります³。
• ギャップを探すよう指示されたレビュアーは、作業が健全でも何かしら報告するのが普通で、すべての指摘を追いかけると過剰設計につながります。対処は、正しさや明示された要件に影響するギャップだけを報告させ、それ以外は任意扱いにすることです⁴。
• ジャッジにエージェントの自己申告だけを渡さないこと。省略したことのほうが含めたことより重要な場合が多く、LLM は必ずしも自分が意味することを口に出しません⁵。生のトランスクリプト（ツール呼び出しとツールの応答）をレビューして、自己説明にない挙動を捕まえます⁵。
• レビュー・修正ループを作る価値があるかは2つのシグナルで決まります。人間がフィードバックを言語化すると LLM の応答が明らかに改善すること、そしてその種のフィードバックを LLM 自身が提供できることです³。
• ジャッジもまたモデル呼び出しであり、コストとノイズを伴います。採点方法を選ぶ原則は最速・最も信頼でき・最もスケールすることであり、コードベースの採点はその3つすべてで上位です²——決定的チェックで捕まえられるものをジャッジに送ってはいけません。自動評価の先には人間による抜き取りが依然として必要で、エージェントをテストする人間は評価が見逃すエッジケースを見つけます¹。

>> レッスン5: 評価セット: 現実のタスク20件から始める