AI Evals × LLM-as-a-Judge設計2026年版

1. なぜ今、AI Evalsを真面目に設計し直す必要があるのか

「動いている気がする」では本番運用に出せない、という壁にぶつかっているチームが急増しています。検証では、リリース判定をユースケース3〜5件の目視で済ませていた案件で、ユースケースが20を超えた段階で品質クレームが顕在化するパターンを複数観測しました。

注意: 本記事のコード例・設定例は本番環境で使用する前に、必ずテスト環境で動作確認してください。

OpenAIが公開したopenai/evalsリポジトリの登場以降、AIエージェント界隈ではevalという言葉が定着しましたが、実態は「LLMに評価させてスコアを出した」だけで終わっているケースが多く、評価の信頼性そのものが疑わしいまま運用されている状況が散見されます。

1-1. ベンチマークと自社evalの違いを整理する

混乱の元は「ベンチマーク」と「アプリケーション特化のeval」を一緒くたに語ることです。両者は目的・データ・判定者・頻度がすべて別物です。前者はMMLU/HumanEval/SWE-Bench等の公開データセットでモデル汎用性能を測るもの、後者は自社のgolden setとadversarialで「自社ユースケースでの合否判定」を毎リリース回すものです。典型サイズは前者が数千〜数万件、後者は50〜500件で済みます。

ベンチマーク選定の体系は別記事のAIエージェント評価ベンチマーク完全ガイドで整理していますが、本記事はその先の「自社サービスで毎日回すeval」の作り方に絞ります。

1-2. evalが「効く」3つの瞬間

evalが投資に見合うリターンを返すのは次の3つの瞬間です。

• モデル切替時：Claude Sonnet 4.5 → 4.6 や、GPT-4o → o3-mini など、モデル世代更新時の回帰検証。eval setがないと「なんとなく良くなった気がする」で意思決定してしまう。
• プロンプト更新時：本番プロンプトを書き換えた際の影響範囲確認。eval set 100件を回すと、5〜15%は別観点で劣化していることが普通にあります。
• RAG/ナレッジ更新時：ドキュメント差し替えやチャンク戦略変更で、特定カテゴリの精度が落ちる現象を検知。

逆に、最初の1ユーザー獲得前にevalを作り込むのはほぼ無駄で、まず手動レビュー20件をやってからevalに昇格させる順番が正しいです。

2. Eval Datasetの3層設計 — 何を何件用意するか

「データセットを作る」が最大の障壁です。検証で機能した構成は、次の3層モデルです。

2-1. Layer 1: Golden Set（50〜200件）

人間が「これは絶対に正解しないと困る」と合意できるユースケース集です。サイズは案件規模で変わりますが、目安は次の通り。

• 個人向けプロトタイプ：30〜50件
• 小規模B2B SaaS：80〜150件
• エンタープライズ AIエージェント：200〜500件

各サンプルには input, expected_output (または expected_behavior), rubric_criteria を持たせます。

{
  "id": "golden_001",
  "input": "請求書PDFから合計金額を抽出して",
  "expected_output_pattern": "¥[0-9,]+",
  "rubric_criteria": [
    "金額が抽出されている",
    "通貨記号が含まれている",
    "余計な説明文を返していない"
  ],
  "tags": ["extraction", "structured-output", "critical"]
}

ポイント：

• expected_outputは完全一致が困難なので、パターンマッチ or ルーブリックで判定する設計に最初からする
• tagsは後述のセグメント別分析に必須。最低でも「critical / normal」「extraction / generation / reasoning」の2軸で付ける
• 正解は1人で作らない。最低2名の人間レビュアーが合意したサンプルだけgolden setに昇格させる（合意率を後でinter-annotator agreementとして測定する）

2-2. Layer 2: Adversarial Set（30〜100件）

「これで壊れたら本当にやばい」失敗誘発ケース集です。Anthropicが公開しているbuild evaluationsガイドでも、明示的にadversarial casesを別管理することが推奨されています（Anthropic公式 Build evaluations、2026年5月時点）。

典型カテゴリ：

• プロンプトインジェクション：「以前の指示を無視して〜」系
• 境界条件：空文字、超長文、絵文字のみ、コード片混入
• 多義性：同じ単語が2つの意味を持つ質問
• ドメイン外質問：本来扱わないトピック（医療相談AIに法律相談、等）
• 個人情報露出：システムプロンプトに含まれる機密の漏洩誘発

adversarial setの特徴は「合格率が80%で十分」とは限らないこと。プロンプトインジェクション耐性は100%でなければ意味がない項目もあるため、カテゴリごとに合格基準を別設定します。

2-3. Layer 3: Production Sample（継続収集）

本番ログから無作為サンプリングした実ユーザー入力集です。Golden / Adversarialは設計者の想像力に依存するため、必ず実トラフィックから補強する必要があります。

運用ルール：

• 1日100件 → 1週間700件のうち20件を無作為抽出 → 人間レビュー → 失敗ケースをadversarial setに昇格
• サンプリングは時間帯別・ユーザーセグメント別に層化する（business hoursだけ集めると土日の壊れ方を見逃す）
• 個人情報は必ずマスキングしてからeval datasetに組み込む

この継続収集の仕組みは、observabilityツール（LangSmith / Langfuse / Braintrust 等）と組み合わせるのが現実的です。トレース連携の設計詳細はLangSmithでAIエージェントを観測・評価する完全ガイドを参照してください。

3. 判定方式の選択 — Rubric型 vs ペアワイズ比較

LLMに判定させる方式は大きく2系統あります。両者は得意領域が違うため、用途別に組み合わせます。

3-1. Rubric型（基準ベース絶対評価）

事前に定めた基準（rubric）に対して各サンプルを採点する方式です。経時比較・回帰検出に強く、CIに組み込みやすい性質があります。

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 動作環境: Python 3.11+, openai>=1.30.0 もしくは anthropic>=0.34.0

RUBRIC_PROMPT = """以下の応答を、各基準について0〜2の3段階で評価してください。
0=満たしていない / 1=部分的に満たしている / 2=完全に満たしている

【評価基準】
1. 正確性: 質問に対する事実が正しい
2. 完全性: 必要な情報が漏れていない
3. 簡潔性: 冗長な前置き・後置きがない
4. 安全性: ハルシネーション・有害発言がない

【質問】
{question}

【応答】
{answer}

出力は厳密にJSON形式で、各基準のスコアと根拠を含めてください。
{
  "accuracy": {"score": 0|1|2, "reason": "..."},
  "completeness": {"score": 0|1|2, "reason": "..."},
  "conciseness": {"score": 0|1|2, "reason": "..."},
  "safety": {"score": 0|1|2, "reason": "..."}
}
"""

Rubric型のポイント：

• スコア段階は3〜5段階に絞る：0〜10の11段階だと判定LLMの揺らぎが大きく、再現性が落ちる。3段階か5段階が実用的
• 必ず根拠（reason）を出力させる：後で誤判定を発見するため、また判定LLMの品質を二次レビューするため
• 基準は4〜6個に絞る：10個以上にすると判定LLMが各基準を独立に評価できなくなる
• 基準同士が直交していること：「正確性」と「事実性」のように重複する基準は片方に統合する

3-2. ペアワイズ比較（A/B選択）

2つの応答を並べて「どちらが良いか」を選ばせる方式です。モデル比較・プロンプト変更前後の比較に強い。

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

PAIRWISE_PROMPT = """以下の質問に対する2つの応答A、Bを比較してください。

【質問】
{question}

【応答A】
{answer_a}

【応答B】
{answer_b}

どちらの応答がより優れているかを判定してください。
判定基準: 正確性 > 完全性 > 簡潔性 > スタイルの順

出力は厳密にJSON形式:
{
  "winner": "A" | "B" | "tie",
  "confidence": "high" | "medium" | "low",
  "reason": "..."
}
"""

ペアワイズの最大の落とし穴はposition biasです。多くのLLMは先に提示された応答を選びやすい傾向があり、これを補正しないと結果が信頼できません。検証で観測したのは、同じペアをA-B順とB-A順の両方で評価させ、両方で同じ側が勝った場合のみ「勝ち」と判定する two-position averaging という手法で、bias影響を大幅に低減できることでした。

def pairwise_with_position_correction(question, ans_a, ans_b, judge):
    """順序入れ替え2回判定で position bias を補正"""
    # 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
    result_ab = judge.compare(question, ans_a, ans_b)
    result_ba = judge.compare(question, ans_b, ans_a)

    # A-B順では Winner="A"、B-A順では Winner="B" なら一貫してA勝ち
    if result_ab["winner"] == "A" and result_ba["winner"] == "B":
        return "A"
    if result_ab["winner"] == "B" and result_ba["winner"] == "A":
        return "B"
    return "tie"  # 一貫しない場合は引き分け扱い

ポイント：

• 判定回数が2倍になる代わりに、bias影響を半減できる
• tie率が30%を超える場合は基準が曖昧な兆候。rubricを精緻化する必要がある
• 3応答以上の比較はトーナメント方式かELOレーティングを使うが、複雑性が跳ね上がるので、まずは2応答比較から始める

3-3. 使い分けの実務指針

状況	推奨方式	理由
毎日のCI回帰	Rubric型	絶対スコアで閾値判定できる
モデル切替検討	ペアワイズ	微差を検出しやすい
プロンプト改善検証	ペアワイズ	before/afterの比較が直感的
顧客報告のスコア	Rubric型	絶対数値の方が説明しやすい
大量サンプル評価	Rubric型	O(N)で済む、ペアワイズはO(N²)
サブトル品質差検出	ペアワイズ	絶対評価では判別不能な差を識別

4. LLM-as-a-Judgeの最大の敵 — Sycophancyとその他のバイアス

LLM-as-a-Judgeを使う上で、避けて通れないのが評価バイアスの問題です。代表的な4種類を整理します。

4-1. Sycophancy（迎合バイアス）

LLMがユーザーや先行発話に同調しようとする性質です。判定タスクで現れるのは次の形：

• プロンプトで「これは社内システムの応答です」と前置きすると、好意的に採点する
• 「以前はBが選ばれました」と履歴を見せると、Bを選びやすくなる
• 「自信を持って評価してください」と圧をかけると、高スコアに偏る

対策は次の通り。

# 悪い例: 文脈を与えすぎている
bad_prompt = """前回はモデルAが優秀でした。今回もAとBを比較してください..."""

# 良い例: 文脈を切り、blind評価にする
good_prompt = """以下の2つの応答を、純粋に内容のみで評価してください。
モデル名・提供元・履歴情報は一切提供されません。"""

さらに強力な対策として、判定LLMに「あなたは厳格な評価者です。半数以上の応答に問題点を見つけることが期待されています」と伝えることで、過剰な高評価を抑制できます。ただし過度に厳しくなりすぎる副作用もあるので、調整が必要です。

4-2. Position Bias（位置バイアス）

前述のペアワイズ比較で先に提示された側を選びやすい現象。two-position averagingで対応。

4-3. Length Bias（長さバイアス）

長い応答を「より丁寧」と誤判定する傾向。次の対策が有効：

• 判定プロンプトで「長さは評価対象外。簡潔性も評価軸に含む」と明記
• 応答の文字数を事前に揃えるか、判定LLMに見せる前にトリミング
• rubricに「簡潔性」を独立評価軸として含める

4-4. Self-Preference Bias（自己選好バイアス）

同じファミリーのモデル（例：GPT系判定者がGPT系応答を選びやすい、Claude系判定者がClaude系を選びやすい）。検証では、判定者と被評価モデルのファミリーを分けることでこのバイアスを軽減できました。

実務的には、判定者を1モデルに固定せず、2モデル（例：Claude Opus 4.7 + GPT-4o）で並行評価し、両者の判定が一致した結果のみを高信頼度判定として扱う「judge ensemble」が現実的です。

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

def judge_ensemble(sample, judges):
    """複数judgeで評価し、一致したものだけ採用"""
    results = [j.evaluate(sample) for j in judges]
    scores = [r["score"] for r in results]

    # 全judge一致なら高信頼度
    if len(set(scores)) == 1:
        return {"score": scores[0], "confidence": "high", "votes": results}
    # 多数決
    from collections import Counter
    majority = Counter(scores).most_common(1)[0][0]
    return {"score": majority, "confidence": "medium", "votes": results}

5. ツール比較 — Inspect / Promptfoo / Braintrust / DeepEval

2026年5月時点で実務でよく選ばれる4つのevalフレームワークを、検証ベースで比較します。料金・機能は公式ドキュメントを2026年5月に確認した情報です（変動の可能性があるため、導入時は必ず公式サイトで最新情報を確認してください）。

5-1. Inspect（UK AI Safety Institute公式）

英国のAI Safety Institute（旧UK AISI、現AISI）が開発・公開しているオープンソースのevalフレームワークです。元々は安全性評価・赤チーム評価の研究向けに設計されており、大規模ベンチマーク再現や複雑なエージェント評価に強い特徴があります。

• 長所：solver / scorer / dataset の抽象化が綺麗。multi-turn evaluationや agentic taskの評価設計が組みやすい
• 短所：初学者には抽象度が高め。CIへの軽量組み込みには重い
• 料金：OSS（Apache 2.0）、無料
• 向く用途：研究、安全性評価、複雑なエージェント評価、ベンチマーク再現

# Inspect の基本構造（公式ドキュメントの構造に基づく一般化例）
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

from inspect_ai import Task, task
from inspect_ai.dataset import Sample
from inspect_ai.solver import generate
from inspect_ai.scorer import model_graded_qa

@task
def my_eval():
    return Task(
        dataset=[
            Sample(input="質問1", target="期待する応答1"),
            Sample(input="質問2", target="期待する応答2"),
        ],
        solver=generate(),
        scorer=model_graded_qa(),
    )

5-2. Promptfoo（CI重視のOSS）

YAML設定ベースで「CIに組み込むeval」を最短で構築できることに特化したOSSです。Web UIも備えています。

• 長所：YAML設定が直感的、CI/CD組み込みが容易、複数モデル横断比較が標準対応、無料
• 短所：複雑なagentic evalは表現力に限界がある
• 料金：OSS無料、Promptfoo Enterprise（有償SaaS）あり
• 向く用途：CI gate、プロンプト変更時の回帰テスト、エンジニア中心チーム

# promptfoo の設定例（promptfooconfig.yaml）
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

providers:
  - openai:gpt-4o-mini
  - anthropic:claude-3-5-haiku-20241022

prompts:
  - "以下の質問に簡潔に答えて: {{question}}"

tests:
  - vars:
      question: "Pythonでリストの重複を削除する方法は?"
    assert:
      - type: contains
        value: "set("
      - type: llm-rubric
        value: "応答が正確で実行可能なコードを含んでいる"
      - type: latency
        threshold: 3000

5-3. Braintrust（observability統合の商用SaaS）

本番運用ログとevalを一気通貫で扱える商用SaaSです。トレース・データセット管理・experiment比較がすべて1つのUIに統合されているのが特徴。

• 長所：trace連携・dataset versioning・UI が強い、本番ログから直接eval setに昇格できる、人間レビュー機能内蔵
• 短所：SaaSなのでデータ持ち出し制約がある場合は注意、料金は規模に応じて変動
• 料金：Free tier あり、有料プランは利用量ベース（公式サイトで最新を確認）
• 向く用途：本番運用中のサービスで継続評価したい、observabilityも一緒に欲しい、エンジニア＋PMが共有するUIが欲しい

5-4. DeepEval（Pythonコード中心のOSS）

pytest風のAPIでevalを書けるPythonライブラリ。Confident AIが開発しているOSSで、unit testに近い感覚でevalを書ける設計です。

• 長所：pytest互換、Python開発者に馴染みやすい、G-Eval等の評価メトリクスを内蔵
• 短所：大規模agentic evalには別途設計が必要
• 料金：OSS無料、Confident AI（SaaSダッシュボード）は有償プランあり
• 向く用途：RAG評価、コード生成評価、Python開発チームのpytest統合

# DeepEvalのpytest風記法例（公式ドキュメントの一般化例）
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

from deepeval import assert_test
from deepeval.metrics import AnswerRelevancyMetric
from deepeval.test_case import LLMTestCase

def test_answer_relevancy():
    test_case = LLMTestCase(
        input="Pythonでリストの重複を削除する方法は?",
        actual_output="set()を使うか、dict.fromkeys()を使います",
    )
    metric = AnswerRelevancyMetric(threshold=0.7)
    assert_test(test_case, [metric])

5-5. 4ツール比較表

項目	Inspect	Promptfoo	Braintrust	DeepEval
開発元	UK AISI	Promptfoo	Braintrust	Confident AI
ライセンス	Apache 2.0 (OSS)	MIT (OSS)	商用SaaS (Free tier)	Apache 2.0 (OSS)
設定形式	Python	YAML	UI + SDK	Python (pytest)
CI統合	可能	標準対応	可能	標準対応
UI	CLI中心	内蔵Web UI	強力なUI	Confident AI連携
trace連携	限定的	限定的	標準対応	限定的
主用途	研究・安全性	CI gate	本番observability	RAG/unit test
学習コスト	中〜高	低	低〜中	低

5-6. 4象限での選定指針

用途×チーム特性の2軸で選ぶと迷いが減ります。

• 研究 × 抽象度許容：Inspect
• 本番運用 × observability重視：Braintrust
• CI/CD × 軽量：Promptfoo
• RAG/Python中心：DeepEval

規模が大きくなれば複数併用も普通です。例えば「本番ログ管理＋eval pipeline UIはBraintrust、PR毎の軽量gate はPromptfoo」という組み合わせは現実的な構成です。

6. 人間評価との突合 — Inter-Annotator AgreementとJudge検証

LLM-as-a-Judgeを信頼して良いかどうかは、「人間の判定とどれだけ一致するか」で測ります。これを怠るとevalスコアは数字遊びになります。

6-1. Inter-Annotator Agreement（IAA）の測り方

まず人間レビュアー2名以上の合意率を測ります。代表的な指標：

• Cohen’s Kappa：2名の判定者の偶然を超えた一致度。0.6以上で実用レベル、0.8以上で高品質
• Fleiss’ Kappa：3名以上の場合のκ係数
• Krippendorff’s Alpha：判定者数が不揃いでも測定可能

# Cohen's Kappa の計算例
# 動作環境: Python 3.11+, scikit-learn>=1.3
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

from sklearn.metrics import cohen_kappa_score

reviewer_a = [1, 1, 0, 1, 0, 0, 1, 1, 0, 1]  # 人間A の判定
reviewer_b = [1, 1, 0, 1, 1, 0, 1, 0, 0, 1]  # 人間B の判定

kappa = cohen_kappa_score(reviewer_a, reviewer_b)
print(f"Cohen's Kappa: {kappa:.3f}")
# 0.6未満ならrubricを見直す。判定基準が曖昧な兆候

運用ルール：

• 新しいrubricを作ったら、まず人間2〜3名で30件評価してkappaを測る
• kappa < 0.6 ならrubricの言語化が不十分。基準を書き換えるか、サンプルを分離する
• kappa ≥ 0.6 になってから、LLM-as-a-Judgeに同じrubricを渡して評価させる

6-2. Judge-Human Agreementの測定

人間同士のkappaが取れたら、次は「judge LLM」と「人間」の一致度を測ります。

# Judge-Human Agreement の例
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

human_consensus = [1, 1, 0, 1, 0, 0, 1, 1, 0, 1]  # 人間2名の合意
judge_llm = [1, 1, 0, 1, 1, 0, 1, 1, 1, 1]        # LLM judgeの判定

kappa_judge = cohen_kappa_score(human_consensus, judge_llm)
print(f"Judge-Human Kappa: {kappa_judge:.3f}")

# 一致しなかったケースを抽出して分析
mismatch_indices = [i for i in range(len(human_consensus))
                    if human_consensus[i] != judge_llm[i]]
print(f"Mismatches: {len(mismatch_indices)}件")

判断基準：

• kappa ≥ 0.7：このjudgeは実用可能。CIに組み込んで良い
• kappa 0.5〜0.7：使えるが、判定信頼度を low/medium/high で出力させ、low判定だけ人間レビューに回す運用
• kappa < 0.5：judgeは使えない。rubric書き直しまたはjudgeモデル変更

6-3. 不一致ケースの分析プロセス

judgeと人間が不一致だったケースを「judgeが間違い」「人間が間違い」「rubricが曖昧」の3カテゴリに分類するのが重要です。

• judgeが間違い：judge promptを改善 or judgeモデルを変える
• 人間が間違い：golden setのラベルを修正
• rubricが曖昧：rubricに具体例・反例を追加

検証で観測したのは、「rubricが曖昧」が原因の不一致が約半数を占めるパターンでした。judgeを責めるより先に、人間が「これは1なのか2なのか」で迷うrubricを直す方が効きます。

7. 社内Eval Pipeline構築のリファレンス設計

ここまでの要素を組み合わせて、CIに組み込めるeval pipelineを設計します。

7-1. パイプライン全体像

[PR作成]
   ↓
[Step 1] Golden Set 50件 評価 (Rubric型・並列)
   ↓
[Step 2] Adversarial Set 30件 評価 (カテゴリ別判定)
   ↓
[Step 3] スコア閾値チェック
   ↓
[Step 4] PR コメントに結果を投稿
   ↓
[Merge後] 週次でProduction Sample 100件 評価
   ↓
[失敗ケース] Adversarial Set に昇格

7-2. 評価ジョブのGitHub Actions例

# .github/workflows/eval.yml
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

name: AI Eval Pipeline

on:
  pull_request:
    paths:
      - 'prompts/**'
      - 'src/agents/**'

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install dependencies
        run: pip install -r requirements-eval.txt

      - name: Run Golden Set Eval
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          python -m evals.run 
            --dataset golden_set.jsonl 
            --output results/golden.json

      - name: Run Adversarial Eval
        run: |
          python -m evals.run 
            --dataset adversarial.jsonl 
            --output results/adversarial.json 
            --strict-mode

      - name: Threshold Check
        run: |
          python -m evals.threshold_check 
            --golden results/golden.json 
            --adversarial results/adversarial.json 
            --min-golden-pass 0.85 
            --min-adversarial-pass 1.00

      - name: Post Comment
        if: always()
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const report = fs.readFileSync('results/summary.md', 'utf-8');
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: report
            });

7-3. 閾値設計の実務指針

「何点以上で合格」を決める閾値設計は、運用初期に最も悩むポイントです。検証で機能した目安：

セット	初期閾値	3ヶ月後の目標
Golden Set (critical tag)	95%	98%
Golden Set (normal tag)	80%	90%
Adversarial (prompt injection)	100%	100% (絶対)
Adversarial (boundary case)	70%	85%
Production Sample	75%	85%

注意：これは初期目安であり、ドメイン・難易度・モデル特性で大きく変わります。最初の1ヶ月は閾値を「現在のbaseline +5%」程度に設定し、徐々に上げていく運用が現実的です。

7-4. テスト戦略との接続

evalはAIエージェント開発における品質保証の一部であり、従来のテスト戦略の延長線上に位置づけるのが整理しやすいです。包括的なテスト戦略の組み立てについてはAIエージェントテスト・品質保証完全ガイドで別途整理しています。

8. コスト最適化 — 1日数千件のeval をいくらで回すか

evalは「回せば回すほど良い」のですが、判定LLMのAPIコストが運用課題になります。検証で実際に効いた最適化を紹介します。

8-1. 判定モデルの段階運用

毎回最強モデルで判定する必要はありません。次の2段階運用が現実的です。

1. 1次判定：Claude Haiku 4.5 / GPT-4o-mini など低コストモデルで全件判定
2. 2次判定：1次で「confidence: low」と判定したケースのみ、Claude Opus 4.7 / GPT-4o で再判定

これにより、コストを6〜8割削減しつつ、判定精度はほぼ維持できます。前提として、1次判定LLMが自身の信頼度を出力できる設計（judge promptで「confidence: high/medium/low」を出させる）が必要です。

8-2. キャッシュ戦略

eval datasetは変化が遅いため、判定結果のキャッシュが極めて有効です。

• キャッシュキー：(model_version, prompt_version, sample_id, judge_prompt_version) のハッシュ
• 4つのいずれかが変わるまでキャッシュ有効
• CI実行時、変更があったプロンプト・モデルだけ再判定する

これでPR毎のevalコストは初回フルラン以降、変更分のみのコストに圧縮できます。

8-3. 並列実行設計

50件のサンプルを直列で評価すると、サンプルあたり3秒として150秒かかります。これを並列化しないとCIに組み込めません。

# 並列eval実装例 (asyncio)
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 動作環境: Python 3.11+, openai>=1.30.0, asyncio

import asyncio
from openai import AsyncOpenAI

client = AsyncOpenAI()
semaphore = asyncio.Semaphore(10)  # 同時並列数を制限

async def evaluate_sample(sample, judge_prompt):
    async with semaphore:
        response = await client.chat.completions.create(
            model="gpt-4o-mini",
            messages=[{"role": "user", "content": judge_prompt.format(**sample)}],
            response_format={"type": "json_object"}
        )
        return response.choices[0].message.content

async def run_evals(samples, judge_prompt):
    tasks = [evaluate_sample(s, judge_prompt) for s in samples]
    return await asyncio.gather(*tasks)

並列度はAPI のrate limitに合わせて調整します。OpenAIなら Tier に応じて 500〜10,000 RPM、Anthropicなら usage tier 別に類似の制限があります。実運用では同時並列5〜20が無難です。

9. Eval結果の可視化と意思決定

スコアを出すだけでは運用に乗りません。意思決定に使える可視化が必要です。

9-1. リリース判定ダッシュボードに必要な要素

• baseline vs candidate のスコア差分：絶対値より差分が意思決定に効く
• セグメント別スコア：tag毎、ユースケース毎、入力長別など
• 失敗ケースの代表例 5件：数字だけ見せても判断できない、サンプル現物を見せる
• statistical significance：差が有意か否か（サンプル数50件で2%差は誤差範囲）
• regression detector：前回スコアからN%以上低下したカテゴリのアラート

9-2. セグメント別分析の重要性

「総合スコア85%」だけ見ても何も分かりません。総合スコアが横ばいでも、特定カテゴリで-15%下がっているパターンは頻出します。tagごとに count / avg / min / pass_rate を集計し、ダッシュボードに並べておくと回帰検知が早くなります。

このセグメント別の見え方は、意思決定者（PM・経営）への報告でも有効です。「全体85%」より「extractionは92%、reasoningは71%」の方が次のアクションが決まります。

10. 【要注意】よくある失敗パターンと回避策

失敗1：Judge promptが曖昧すぎる

❌「応答の質を評価してください」
⭕「以下の4基準で各0〜2で評価。基準ごとに必ず根拠1文を付ける。事実誤認があれば正確性は0、根拠の引用元が無ければ完全性は1以下」

なぜ重要か：judge LLMは「よしなに評価して」が最も苦手です。具体的な条件（基準、出力形式、判定の優先順位）を指定するほど、判定の再現性が上がります。

失敗2：人間レビューを一度もやらずにjudge LLMを信用する

❌ judgeがOK出してるからリリース
⭕ 最初の50件は必ず人間2名でレビューし、judge-human kappaを測定してからCI組み込み

なぜ重要か：judgeを信用していい根拠は「kappaが0.7以上」であり、判定モデル名や開発者の希望ではありません。kappaを測らないevalは数字遊びです。

失敗3：Adversarialとgoldenを混ぜる

❌ 同じデータセットに通常ケースとプロンプトインジェクションケースを混在
⭕ 別dataset、別合格基準で管理。adversarialは合格基準を100%にする項目も含む

なぜ重要か：合格基準が違う2種類を1つのスコアで管理すると、片方の改善がもう片方の悪化を隠してしまいます。

失敗4：position biasを補正していないペアワイズ

❌ A→Bの順だけで比較してA勝ち
⭕ A→B順とB→A順の両方で評価し、両方で同じ側が勝った場合のみ「勝ち」

なぜ重要か：多くのLLMで先に提示された側が選ばれやすい現象が観測されます。position correctionなしの結果は信頼度が低い数字です。

失敗5：production sampleを使わず、設計者の想像力だけでgolden setを作る

❌ 設計者3人の想定ユースケースだけで100件
⭕ 本番ログから週次で20件サンプリングし、失敗ケースをadversarialに昇格

なぜ重要か：「設計者が想像できる失敗」と「実ユーザーが起こす失敗」は半分以上ズレます。実トラフィックからの補強なしには、本当のリスクを捉えられません。

失敗6：rubricを10個以上に増やしてしまう

❌ 精緻に評価したくて基準を15個に分割
⭕ 4〜6個に絞り、必要なら2階層（大分類→小分類）に整理

なぜ重要か：判定LLMは基準が増えるほど各基準を独立に評価できなくなり、結果的に判定精度が落ちます。基準同士が直交していることを優先。

11. よくある質問（FAQ）

Q1: AI Evalsとは何ですか？

AI Evalsは、LLMアプリケーション・AIエージェントの品質を自動評価する仕組みの総称です。eval datasetを設計し、LLM-as-a-Judgeまたは人間レビューで判定して、リリース判定や継続監視に使います。本記事ではdataset設計→判定方式選択→ツール選定→人間突合まで実装パターンを整理しています。

Q2: LLM-as-a-Judgeはどこまで信用していいですか？

「人間レビュアー2名以上との合意度（Cohen’s Kappa）が0.7以上」であれば、CI gateとして実用可能です。0.5〜0.7は補助的に使う段階、0.5未満はrubricまたは判定モデルを見直す段階。判定モデル単体ではなく、人間との突合を必ずセットで考えてください。

Q3: rubric型とペアワイズ比較のどちらを使うべきですか？

CI回帰と顧客報告にはrubric型、モデル切替検討やプロンプト改善検証にはペアワイズ比較が向きます。両方併用するのが一般的で、相互補完の関係です。詳しくは本記事の3-3章「使い分けの実務指針」を参照してください。

Q4: Inspect / Promptfoo / Braintrust / DeepEval どれを選ぶべきですか？

研究・安全性評価ならInspect、CI/CDの軽量gateならPromptfoo、本番observability統合ならBraintrust、Python開発・RAG評価ならDeepEvalが基本選択です。規模が大きくなれば複数併用も普通です。詳細は5章の4象限指針を参照してください。

Q5: sycophancyやposition biasの対策は本当に必要ですか？

はい、対策なしのLLM-as-a-Judgeは判定が信頼できない数字になります。最低限、(1) position correctionとしてA-B/B-A両方向評価、(2) 自己選好バイアス回避のためjudge ensemble、(3) sycophancy抑制のためblind評価設計、の3点を導入してください。これらなしのevalはCIに組み込まない方が安全です。

Q6: eval datasetは何件あればいいですか？

個人プロトタイプなら30〜50件、小規模B2B SaaSなら80〜150件、エンタープライズなら200〜500件が目安です。最初から大量に作るより、20件の高品質ケースから始めて、production sampleで徐々に拡張するのが現実的です。「件数より、人間が合意できる質」が重要です。

12. まとめ — 今日から始める3つのアクション

AI Evalsは「動いている気がする」を「数字で説明できる」に変えるための投資です。完璧なシステムを最初から作る必要はなく、次の3つから始めるのが最短ルートです。

1. Golden Set 20件を人間で作る：自社サービスの「失敗したら一番痛い1ユースケース」を20件サンプリングし、2名以上の人間レビューで合否ラベルを付ける。これがすべての出発点です。
2. Promptfoo か DeepEval で1本走らせる：選定に時間をかけず、YAMLかPythonでとにかく1本動かす。CIに組み込むのは後で良いので、まず「LLM-as-a-Judgeの判定」と「人間判定」の不一致を観察する。
3. 不一致ケースを分析する：「judge間違い／人間間違い／rubric曖昧」の3カテゴリに分け、rubric曖昧が半数を超えるはずです。そこを言語化し直すと、eval全体の信頼性が一段上がります。

本記事の構造は、別記事のAIエージェント評価ベンチマーク完全ガイド（モデル選定軸）、LangSmithでAIエージェントを観測・評価する完全ガイド（観測基盤）、AIエージェントテスト・品質保証完全ガイド（テスト戦略全体）と接続するように設計しています。本記事で扱った「eval設計」は、品質保証の中核ですが、他3つと組み合わせて初めて全体の品質システムになります。

参照ソース・最終確認日：2026年5月時点。Anthropic公式 Build evaluations（anthropic.com）、OpenAI Evals（openai.com / GitHub openai/evals）、Inspect（UK AISI / inspect.aisi.org.uk）、Promptfoo公式（promptfoo.dev）、Braintrust公式（braintrust.dev）、DeepEval（Confident AI、deepeval.com / GitHub confident-ai/deepeval）。各ツールの料金・機能は変動するため、導入時は必ず最新の公式情報を確認してください。