LLM-as-a-Judgeとは？評価プロンプトの書き方・3つのバイアス対策と人手との一致率の測り方

LLM-as-a-Judge（LLM as a Judge）は、LLMに別のLLMの出力を読ませて「どちらが良いか」「何点か」「基準を満たすか」を判定させる評価手法です。名前を広めたのは2023年のZhengらの論文（arXiv:2306.05685）で、GPT-4の判定は人間の判定と85%一致し、人間同士の一致率81%と同じ水準でした。ただしこの数字は「引き分けを除いた票」に限った条件付きの値で、同じ論文は回答の順番を入れ替えるだけでGPT-4の判定が35%の組で一貫しなくなることも報告しています。この記事では、評価方式の選び方、3つのバイアスと対策、ルーブリック評価、評価プロンプトとPythonの実装例、人手ラベルとの一致率の測り方までを一次情報の数値で整理します。

まとめ：LLM-as-a-Judgeを使う前に押さえる要点

• 評価方式は「ペア比較」「単一採点」「参照付き採点」の3つ。モデル同士の優劣はペア比較、合否の監視は単一採点かルーブリック、正解がある問題は参照付き採点が向きます。
• GPT-4と人間の一致率85%は、引き分けを除いた票での値です。引き分けと順番で結論が変わった票を含めると66%まで下がります（ランダムな判定者同士の一致率は33%）。
• 位置バイアスは順番を入れ替えて2回判定し、両方で勝った側だけを勝ちにすると抑えられます。冗長性バイアスは「長さで判断しない」指示と、長いだけの回答を混ぜた検証データで確かめます。
• 採点の項目を1つずつYes/Noで判定させるルーブリック評価は、OpenAIのHealthBenchが5,000会話・48,562基準の規模で採用しており、評価者LLMと医師の一致度を公開しています。
• 導入前に人手ラベルを作り、評価者LLMとの一致率とCohenのκを測ります。本記事では初期の試行として50〜100件を提案しますが、本番判断に必要な件数はタスクの多様性や許容誤差に応じて増やします。測らずに使うと、評価者の癖をモデルの性能と取り違えます。

LLM-as-a-Judgeの定義と従来指標（BLEU・ROUGE・人手評価）との違い

BLEUやROUGEは、生成文と参照文で単語の並び（n-gram）がどれだけ重なるかを数える指標です。言い換えに弱く、正解が1つに決まらない対話や要約では人間の評価と相関しにくいことが知られています。G-Evalの論文（Liuら、2023年・arXiv:2303.16634）も、BLEUやROUGEは創造性や多様性を求めるタスクで人間の判断との相関が低いと明記しています。一方で人手評価は精度が高いものの、モデルを1回直すたびに数百件を読み直す費用と時間がかかります。

LLM-as-a-Judgeはこの間を埋める手法です。評価基準を自然文で渡せるため、参照文が無いタスクでも「質問に答えているか」「事実と矛盾しないか」を判定でき、判定理由も文章で返せます。代わりに、評価者LLM自身の誤りや癖が評価結果に混ざります。

BLEUやROUGEの値が高くても、言い換えた正答が低く出る問題は残ります。評価指標全体の選び方はLLM評価の指標とデータセット設計を扱った総論にまとめています。

3つの評価方式：ペア比較・単一採点・参照付き採点

Zhengらの論文は、LLM-as-a-Judgeを次の3方式に分けています。組み合わせて使うこともできます。

論文が挙げる弱点もそれぞれ違います。ペア比較は比べる対象が増えると組み合わせが2乗で増え、単一採点は僅差の違いを見分けにくく、評価者モデルが変わると絶対点がぶれます。数学の採点では参照付きが効き、10問×2順序の20判定で、GPT-4が誤答を正しいと判定した回数は既定のプロンプトで14回、CoT（先に自分で解かせる）で6回、参照解答を渡すと3回まで減りました。正解が用意できる問題で評価者LLMに自力で正誤を判断させるのは避けてください。

人間の投票でモデルを順位付けする公開の仕組みとしては、Zhengらが同じ論文で発表したArena（旧Chatbot Arena）のリーダーボードがあります。LLM-as-a-Judgeはその人間の判定をどこまで代替できるかを確かめるために検証された手法です。

人間との一致率85%の条件：MT-Bench論文の数値の読み方

「GPT-4の判定は人間と80%以上一致する」という説明はよく引用されますが、論文の表5を見ると条件で値が大きく変わります。MT-Benchの第1ターンに対する専門家の投票での値は次のとおりです。

S1では、順番を入れ替えて結論が変わった票を引き分けとして数えています。85%はS2の値で、比較する両方の判定者が引き分け以外を選んだ票に限った一致率です。人間だけでなく、評価者LLM側の引き分けや順序入替で一貫しなかった判定も除かれます。自社の評価で同じ数字を期待すると、引き分けが多いタスクでは大きく外れます。読み取るべきなのは「GPT-4と人間の一致は、人間同士の一致と同じ水準だった」という相対的な結論で、85%という絶対値ではありません。また、2023年当時の評価者はGPT-4で、現在の評価者モデルで同じ値が出る保証はないため、一致率は自社のデータで測り直す前提で使います。

3つのバイアスと対策：位置・冗長性・自己強化

位置バイアスと順序入替による判定

位置バイアスは、内容ではなく提示された位置で勝敗を決める傾向です。論文の表2では、似た品質の回答2つを入れ替えて判定させたとき、結論が一貫したのはGPT-4で65.0%、GPT-3.5で46.2%、Claude-v1では23.8%でした。Claude-v1は75.0%の組で先に出た回答を勝たせています。

論文が採用した対策は、順番を入れ替えて2回判定し、両方の順序で同じ回答が選ばれたときだけ勝ちとし、結論が割れたら引き分けにする保守的な方法です。判定回数は2倍になりますが、比較の結論を出す用途では省略しないでください。few-shotの判定例を3つ入れるとGPT-4の一貫性は65.0%から77.5%に上がった一方、プロンプトが長くなりAPI費用は4倍になったと報告されています。

冗長性バイアスと長さで判断しない指示

冗長性バイアスは、内容が増えていなくても長い回答を高く評価する傾向です。論文は、回答の箇条書きを言い換えて水増しした「repetitive list」攻撃を23件の回答で試し、水増し版を勝たせてしまった割合はClaude-v1とGPT-3.5が91.3%、GPT-4が8.7%でした。評価プロンプトに「回答の長さで判断しない」と書くのは最低限の対策で、効いているかは、内容が同じで長さだけ違う回答の組を検証データに混ぜて確かめます。HealthBenchの論文も、モデルによる採点では長さのバイアスが既知の課題だとして、点数と回答長の関係を別に分析しています。

自己強化バイアスと評価モデルの分離

自己強化バイアスは、評価者LLMが自分の生成した回答を高く評価する傾向です。論文では人間の判定と比べて、GPT-4は自分の勝率を10%、Claude-v1は25%高く付けていました。ただし論文自身は、データ量が少なく差も小さいため、このバイアスがあるとは確定できないと書いています。この懸念への対策として、比較対象と異なるモデルを評価者にする方法があります。ただし、モデルを分けても他のバイアスや誤判定は残るため、人手ラベルとの一致を検証して採否を決めます。G-Evalの論文も、LLMによる評価者がLLMの生成した文章を好む可能性を懸念点として挙げています。

ルーブリック評価：HealthBenchに見る基準ごとのYes/No採点

HealthBenchの採点式と正負の配点

ルーブリック評価は、「良い回答か」を1回で聞くのではなく、満たすべき基準を項目に分け、項目ごとに満たすかどうかを判定させる方式です。OpenAIが2025年5月12日に公開したHealthBench（論文 arXiv:2505.08775）は、5,000件の医療相談の会話に、26の専門分野・60か国の診療経験を持つ医師262人が会話ごとの基準を書き、合計48,562件の基準で採点します。

各基準には−10から10までの点数が付いており、望ましくない行動（危険な断定など）には負の点数が割り当てられています。採点モデルは基準を1つずつ独立に判定し、満たしていれば全額、満たしていなければ0点を付けます。満たした基準の点数を合計し、取りうる最大点で割った値がその会話の得点です。負の基準を多く満たすと得点がマイナスになることもあります。1つの会話に付く基準数は中央値11件です。

論文が既定の採点モデルにしたのはGPT-4.1で、複数の医師の合意で検証した34の観点（HealthBench Consensus）の基準を使ったメタ評価で、医師の判定との一致度（マクロF1）は0.709でした。基準ごとの実際の該当率で無作為に「満たす」と答えるランダムな基準は0.50で、GPT-4.1は7つのテーマのうち5つで医師の平均を上回り、全テーマで医師の下位3分の1より上にいました。論文はこの結果から、データとメタ評価とプロンプトを丁寧に設計すれば、モデルによる採点は専門家の採点と同程度に信頼できると結論づけています。条件を外した採点まで医師並みになるという主張ではありません。

ルーブリック項目の書き方と粒度

HealthBenchが基準を1つずつ独立に判定させているのと同じく、ルーブリックの1項目は、評価者が文章を読んでYesかNoで答えられる粒度にします。「わかりやすい」は判定がぶれますが、「専門用語を使う場合は初出で意味を説明している」なら判定できます。書き分けの目安は次のとおりです。

• 1項目に1つの条件だけを入れる（「正確で簡潔」は2項目に分ける）。
• してほしくない行動は負の点数の項目として独立させる（例：根拠の無い数値を断定している＝−5）。
• 点数の重みは業務上の影響で決める。誤情報の項目を、文体の項目と同じ重みにしない。
• 項目を増やすほど評価者の呼び出し回数か入力トークンが増えるので、全会話共通の項目と会話ごとの項目を分ける。

評価プロンプトの書き方とPythonの実装例

単一採点のプロンプトテンプレート

評価プロンプトには、評価者の役割、評価基準、出力形式の3つを必ず書きます。G-Evalは、評価手順を先にLLMに書き出させてから点数を付けさせ（CoT）、出力された点数のトークン確率で加重平均を取る方法で、要約の評価で人間とのSpearman相関0.514を出しました。確率が取れないAPIでも、「理由を先に書き、最後に点数だけを決まった形式で出す」構成は流用できます。

あなたは社内FAQボットの回答を採点する評価者です。
次の基準ごとに、満たしていれば yes、満たしていなければ no と判定してください。
回答の長さや丁寧さの印象では判断しないでください。

[基準]
1. 質問に直接答えている
2. 参考資料に書かれていない数値や固有名詞を含まない
3. 手順を案内する場合、順番が参考資料と一致している

[質問]
{question}

[参考資料]
{context}

[回答]
{answer}

各基準の判定理由を1文ずつ書いた後、最後の行に次のJSONだけを出力してください。
{"1": "yes", "2": "no", "3": "yes"}

「最後の行にJSONだけ」と指定しておくと、理由の文章と判定結果を機械的に分けられます。論文の表2でも、出力形式を守らない「Error」がClaude-v1で最大3.8%出ています。パースに失敗した件数は捨てずに数え、増えたらプロンプトか評価モデルを見直します。

順序入替つきペア比較と一致率の計算

次のコードは、順番を入れ替えて2回判定する保守的なペア比較と、人手ラベルとの一致率・Cohenのκの計算をまとめたものです。call_judge は動作確認用に、入力のCRC32値を10で割った余りが7未満なら先頭を選ぶ決定的な偽の評価者にしてあり、実運用ではここを各社のAPI呼び出しに置き換えます。Python 3の標準ライブラリだけで動きます。

import json
import zlib

JUDGE_PROMPT = """あなたは公平な評価者です。ユーザーの質問に対する2つの回答を比較してください。
回答の順番や長さ、アシスタントの名前で判断を左右させないでください。
まず比較の理由を2〜3文で述べ、最後に次のJSONだけを出力してください。
{{"winner": "A"}}
winnerの値は "A"、"B"、"tie" のいずれか1つにしてください。

[質問]
{question}

[回答A]
{answer_a}

[回答B]
{answer_b}
"""


def call_judge(prompt: str) -> str:
    """実際はここでLLM APIを呼ぶ。動作確認用に「先に出た方を選びやすい」偽ジャッジを置く。"""
    picked = "A" if zlib.crc32(prompt.encode()) % 10 < 7 else "B"  # 入力ごとに結果が固定される判定
    return '理由は省略。\n{"winner": "%s"}' % picked


def parse_winner(text: str) -> str:
    lines = text.strip().splitlines()
    if not lines:
        raise ValueError("評価結果が空です")
    try:
        result = json.loads(lines[-1])
    except json.JSONDecodeError as exc:
        raise ValueError("最終行が有効なJSONではありません") from exc
    if not isinstance(result, dict) or result.get("winner") not in ("A", "B", "tie"):
        raise ValueError("winnerはA、B、tieのいずれかである必要があります")
    return result["winner"]


def judge_pair(question: str, x: str, y: str) -> str:
    """順番を入れ替えて2回判定し、両方で同じ側が勝ったときだけ勝ちとする。"""
    first = parse_winner(call_judge(JUDGE_PROMPT.format(question=question, answer_a=x, answer_b=y)))
    second = parse_winner(call_judge(JUDGE_PROMPT.format(question=question, answer_a=y, answer_b=x)))
    second = {"A": "B", "B": "A", "tie": "tie"}[second]  # 入れ替え前の向きへ戻す
    if first == second:
        return {"A": "x", "B": "y", "tie": "tie"}[first]
    return "inconsistent"  # 順番で結論が変わった＝位置バイアスの疑い


def cohen_kappa(a: list, b: list) -> float:
    if not a or len(a) != len(b):
        raise ValueError("ラベル列は空でなく、同じ長さである必要があります")
    labels = sorted(set(a) | set(b))
    n = len(a)
    po = sum(1 for i, j in zip(a, b) if i == j) / n
    pe = sum((a.count(l) / n) * (b.count(l) / n) for l in labels)
    if pe == 1.0:
        return float("nan")  # 両者が同じ単一ラベルだけを付けた場合、κは未定義
    return (po - pe) / (1 - pe)


if __name__ == "__main__":
    pairs = [("質問%d" % i, "回答x%d" % i, "回答y%d" % i) for i in range(20)]
    judge = [judge_pair(q, x, y) for q, x, y in pairs]
    print("順番で結論が変わった件数:", judge.count("inconsistent"), "/", len(judge))

    human = ["x", "y", "x", "x", "tie", "y", "x", "y", "y", "x", "x", "tie", "y", "x", "y", "x", "y", "y", "x", "tie"]
    llm = ["x", "y", "x", "y", "tie", "y", "x", "x", "y", "x", "x", "y", "y", "x", "y", "x", "tie", "y", "x", "tie"]
    agree = sum(h == l for h, l in zip(human, llm)) / len(human)
    print("一致率: %.2f  Cohenのκ: %.2f" % (agree, cohen_kappa(human, llm)))

実行すると次のように出力されます。κの値は scikit-learn の cohen_kappa_score で計算した0.6748と一致します。

順番で結論が変わった件数: 7 / 20
一致率: 0.80  Cohenのκ: 0.67

この偽の評価者では、20組中7組で順番により結論が変わりました。1回だけの判定なら、この7組はすべて「勝ち」か「負け」として集計されていたことになります。コードは診断用に inconsistent を残していますが、保守的な勝敗集計ではこの値を引き分け（tie）として数えます。後半の一致率とκは、ペア比較の結果ではなく、別に用意した固定のラベル列で計算した例です。一致率80%でもκが0.67に下がるのは、偶然の一致を差し引くためです。ラベルの偏りが大きいデータでは一致率だけを見ると高く見えるので、κを併記してください。

LLM-as-a-Judgeの導入手順：評価データ作成から一致率の検証まで

評価者LLMは、使う前に「自社のタスクで人間と同じ判断をするか」を確かめる必要があります。手順は次のとおりです。

1. 評価対象と基準を決める。「社内FAQの回答が参考資料と矛盾しないか」のように、1つの評価で測る対象を1つに絞ります。
2. 初期の試行用に、評価データを50〜100件程度集める。必要な件数はタスクの多様性や許容誤差に応じて増やします。本番ログから、良い回答・悪い回答・判断に迷う回答を混ぜて抜き出します。良い例ばかりだと評価者の弱点が見えません。
3. 人手でラベルを付ける。できれば2人で付け、人間同士の一致率も測ります。人間同士が一致しない項目は、まず不一致の原因を確認します。基準の曖昧さが原因なら書き直し、専門知識の差や複数の妥当な判断が原因なら、判定者の選定やラベルの扱いを見直します。
4. 評価プロンプトを作り、人手ラベルと突き合わせる。一致率とκを測り、不一致の事例を読んで、基準の文言か評価モデルを直します。
5. 本番に組み込み、定期的に人手で抜き取り検査する。評価モデルの版を変えたときと、生成側のモデルを変えたときは、手順4をやり直します。

RAGの回答なら、検索と生成を分けて評価すると原因を切り分けやすくなります。具体的な指標はRAG評価で検索と生成を分けて測る方法を、ツールの呼び出し順まで評価するときはAIエージェント評価の軌跡とツール呼び出しの測り方を参照してください。

LLM-as-a-Judgeを実装できるツールと評価モデル

評価者のプロンプトと集計を自前で書かなくても、主要な評価ツールにはLLM-as-a-Judgeの仕組みが入っています。2026年10月時点の主な選択肢は次のとおりです。

OpenAI Evalsは2026年6月3日に廃止が告知され、OpenAIの廃止予定一覧では10月31日に既存の評価が読み取り専用になり、11月30日にダッシュボードとAPIが終了する予定です。OpenAIは移行先としてPromptfooへの移行ガイドを案内しているので、これから組む評価基盤にEvalsを選ぶのは避けてください。設計の考え方は他のツールにも移せます。Evalsの採点器（grader）には、LLMが数値を返す score_model、決められたラベルから選ぶ label_model のほか、文字列一致の string_check、BLEUやROUGEを含む text_similarity、任意のPythonコードを実行する python があります。正解が文字列で決まる項目は string_check や python に任せ、LLMの採点は意味の判断が要る項目だけに使うと費用と誤判定の両方を減らせます。

Amazon Bedrockのモデル評価では、2024年12月にプレビュー、2025年3月20日に一般提供となったLLM-as-a-judge機能で、Correctness（正確さ）・Completeness・Faithfulness・Helpfulness・Logical coherence・Relevance・Following instructions・Professional style and tone・Harmfulness・Stereotyping・Refusalの11指標を選べ、独自の指標も定義できます（Bedrockのユーザーガイド）。AWS上でモデルを比較している場合は、指定形式の評価データをS3に配置し、必要なアクセス権限を設定したうえで、評価モデル・指標・出力先を指定して評価ジョブを作成します。

DeepEvalのGEvalはG-Evalの論文の方式（評価手順の生成と確率による加重）を実装した指標で、自然文で書いた基準をそのまま評価に使えます。DAGMetricは判定の分岐をグラフで固定する指標ですが、分岐ごとの判定はLLMが行うため、結果が完全に決定的になるわけではありません。RAGの評価に特化したRagasの使い方はRAGASの指標と0.4系の実装手順で解説しています。

Prometheus 2（arXiv:2405.01535）は評価専用に学習されたオープンモデルで、Mistral-7Bを基にした7B版とMixtral-8x7Bを基にした8x7B版があり、ユーザーが定義した基準による直接評価とペア比較の両方に対応します。モデルはApache-2.0で公開されています。評価対象のデータを外部APIに送れない場合の候補になりますが、自社のタスクで人手ラベルとの一致率を測る手順は省略できません。

LLM-as-a-Judgeを使うべきでない場面

評価者LLMは、判定に必要な知識や推論を評価者自身が持っている範囲でしか正しく判定できません。次の場面では、LLM-as-a-Judgeを主な評価手段にしないでください。

• 正解が機械的に決まる問題。数値計算、コードのテスト通過、JSONの形式、分類ラベルは、完全一致かユニットテストで判定します。論文でも、GPT-4は自分では解ける数学の問題でも、渡された誤答に引きずられて採点を誤っていました。
• 評価者が知らない最新情報や社内固有の事実の確認。参考資料を渡さずに「事実として正しいか」を判定させると、評価者の学習時点の知識で判定されます。参照付き採点にするか、人手で確認します。
• 人手ラベルとの一致率を測っていない段階での合否判定。一致率が分からない評価者の点数でリリースを止めたり通したりすると、評価者の癖がそのまま製品の判断になります。
• 医療・法務・採用など、誤判定の影響が大きい最終判断。評価者LLMの判定は、人間のレビューを絞り込む一次スクリーニングに留めます。HealthBenchのメタ評価が確かめたのはルーブリック採点が医師の判定と整合するかどうかで、最終判断を自動化してよいという結論ではありません。

LLM-as-a-Judgeが最も効くのは、正解が1つに決まらず、件数が多くて人手では読み切れない出力を、事前に一致率を確かめた基準で繰り返し評価する場面です。同じ入力を複数のモデルへ流して品質と費用を比べる場合の手順はAI比較の実装手順にまとめています。

よくある質問

LLM as a Judgeとは簡単に言うと何ですか？

LLMに採点者の役をさせ、別のLLMの回答の良し悪しや点数、基準を満たすかを判定させる評価手法です。2023年のZhengらの論文（MT-BenchとChatbot Arena）で、GPT-4の判定が引き分けを除く票で人間と85%一致したことから広く使われるようになりました。

LLM as a Judgeのプロンプトには何を書けばよいですか？

評価者の役割、評価基準、出力形式の3つです。基準はYes/Noで判定できる粒度に分け、「長さで判断しない」と明記し、判定理由を先に書かせてから最後の行に決まった形式（JSONなど）で結果を出させると、集計と検証がしやすくなります。

LLMのルーブリック評価（rubric）とは何ですか？

満たすべき基準を項目に分け、項目ごとに満たすかどうかを評価者に判定させ、配点を合計して得点にする方式です。OpenAIのHealthBenchは会話ごとに医師が書いた基準（−10〜10点）で採点し、満たした項目の合計を最大点で割って得点にしています。

評価者LLMの判定はどこまで信頼できますか？

自社のデータで測るまで分かりません。論文の一致率は特定のタスク・特定の評価者モデルでの値で、順番を入れ替えると結論が変わる組もあります。まずは50〜100件程度を初期試行の目安として人手ラベルと突き合わせ、一致率とCohenのκを人間同士の値と比較してください。本番利用の判断では、必要な評価件数、不一致の内容、重大な誤判定の頻度も確認します。

AWSでLLM as a Judgeは使えますか？

使えます。Amazon Bedrockのモデル評価に、2025年3月20日に一般提供となったLLM-as-a-judge機能があり、正確さ・忠実性・有害性など11の組み込み指標と独自の指標で評価ジョブを実行できます。

関連記事

• LLM評価とは？指標・データセット設計・評価ツールの選び方を実装視点で解説【2026年版】
• RAG評価とは？検索と生成を分けて測る指標・Ragasでの実装・運用への組み込み【2026年版】
• AIエージェント評価とは？軌跡・ツール呼び出し・タスク達成を測る指標と実装の進め方【2026年版】
• Arena（旧Chatbot Arena・LMArena）の使い方｜arena.aiの投票手順とリーダーボードの見方
• Chain of Thoughtとは？CoTプロンプトの書き方・推論モデルでの扱いと限界を実装目線で解説【2026年版】