LLM選定のために自作の比較評価テストを組んだのに、候補モデルが軒並み満点になって優劣がつかない——という経験をしたエンジニアは多いと思います。この現象と解決の全体像（8ステップ）は公開ベンチマークだけでLLMを選んでいませんか？——判別力のある評価テストを自作する方法（amanity.co.jp）で「どう考えるか」中心に解説しました。

本記事はその実装編です。概念だけでは再現できない部分——正解データを独立ロジックで検算するコード、LLM-as-judgeを"雰囲気採点"に戻さないための構造化出力の強制、天井効果の自動検出、そしてOllamaのnum_ctxが実際にどう挙動するかの実測ベースの対策——をコードで解説します。

全体構成

評価ハーネスは大きく4つのコンポーネントに分解できます。

1. テストデータ生成器   → 仕掛け（異常値・トラップ・季節性）を混ぜたデータを作る
2. 正解キー生成器       → 生成器とは独立したロジックで正解を計算し直す
3. 実行ランナー         → 候補モデル全部に同一条件でプロンプトを投げる
4. 採点器（judge）      → 正解キーの項目ごとに機械的にYes/Noを判定する

ポイントは、2の「正解キー生成器」を1の「テストデータ生成器」からコード上も分離することです。同じモジュール内で計算すると、リファクタ時に誤って設定値を共有してしまい、生成バグがそのまま正解バグになる事故が起きます。

実装1: テストデータと正解キーを別ロジックで作る

売上異常検知タスクを例にします。生成器には「本物の異常値」「季節性による見せかけの増加」「値上げイベント」を意図的に混ぜます。

import random
from dataclasses import dataclass

@dataclass
class Row:
    month: str      # "2025-07"
    product: str    # "A" / "B"
    units: int
    unit_price: int

def generate_dataset(seed: int = 42) -> list[Row]:
    random.seed(seed)
    rows: list[Row] = []
    base_price = {"A": 1000, "B": 1500}
    for year in (2024, 2025):
        for m in range(1, 13):
            month = f"{year}-{m:02d}"
            for product, price in base_price.items():
                units = random.randint(80, 120)
                if m == 12:                                  # 季節性トラップ（毎年12月は伸びる）
                    units = int(units * 1.2)
                if month == "2025-07" and product == "A":     # 本物の異常値
                    units *= 3
                unit_price = price
                if product == "B" and year == 2025 and m >= 4:  # 値上げイベント
                    unit_price = int(price * 1.15)
                rows.append(Row(month, product, units, unit_price))
    return rows

正解キーは、このrows（生成済みデータ）だけを入力にして、生成時のパラメータ（seedや倍率の1.2・3・1.15）には一切触れずに計算し直します。

def revenue_of(rows: list[Row], product: str | None = None, month_prefix: str | None = None) -> int:
    return sum(
        r.units * r.unit_price for r in rows
        if (product is None or r.product == product)
        and (month_prefix is None or r.month.startswith(month_prefix))
    )

def true_anomaly_months(rows: list[Row], z_threshold: float = 2.5) -> list[str]:
    """月別出荷数のzスコアで異常値を検出する。季節性(12月)は月次パターンとして
    z計算の母集団に含めるため、単発の異常値とは自然に区別される"""
    import statistics
    from collections import defaultdict

    by_product: dict[str, list[tuple[str, int]]] = defaultdict(list)
    for r in rows:
        by_product[r.product].append((r.month, r.units))

    anomalies = []
    for product, series in by_product.items():
        values = [v for _, v in series]
        mean, stdev = statistics.mean(values), statistics.stdev(values)
        for month, v in series:
            if stdev and abs(v - mean) / stdev >= z_threshold:
                anomalies.append(f"{month}:{product}")
    return anomalies

def build_answer_key(rows: list[Row]) -> dict:
    return {
        "total_revenue_jpy": revenue_of(rows),
        "revenue_by_product": {p: revenue_of(rows, product=p) for p in ("A", "B")},
        "true_anomaly_months": true_anomaly_months(rows),
    }

revenue_ofとtrue_anomaly_monthsはrowsしか受け取らないため、生成器のバグ（例えば倍率を書き間違える）があっても、正解キーは「できあがったデータの通りの答え」を返し続けます。これがテスト自体の信頼性の土台になります。

CIに乗せる場合は、この独立性を壊さないことをテストで固定しておくと安全です。

def test_answer_key_does_not_depend_on_generation_params():
    """generate_dataset のパラメータを変えても、
    revenue_of が rows 以外の情報源を参照していないことを保証する回帰テスト"""
    import inspect
    src = inspect.getsource(revenue_of)
    assert "random" not in src and "seed" not in src

実装2: LLM-as-judgeを"雰囲気採点"に戻さない

採点をLLMに任せる場合の失敗は、たいてい「自由記述のプロンプトで採点させ、返ってきたテキストをreでざっくりパースする」実装から生まれます。これだと採点役のLLM自身が通読による印象判定に流れやすく、フリーテキストのパース失敗にも気づきにくくなります。

対策は、採点役の出力形式をスキーマで強制し、パース段階でバリデーションエラーにできるようにすることです。

from pydantic import BaseModel, ValidationError

class JudgeItem(BaseModel):
    item: str
    verdict: bool
    quote: str  # 出力のどの記述を根拠にしたか（引用必須にすることで裏取りを強制する）

class JudgeResult(BaseModel):
    items: list[JudgeItem]
    fabrications: list[str]  # 正解キーにない記述(捏造)の指摘

JUDGE_PROMPT = """\
あなたは公平な採点者です。以下の「正解キーの項目」を1つずつ、
「モデルの出力」と機械的に照合し、各項目についてverdict(true/false)と
根拠quote(出力からの引用)を判定してください。一読しての印象では判定しないこと。

## 正解キーの項目
{answer_key}

## モデルの出力
{model_output}

出力は指定されたJSONスキーマに厳密に従うこと。
"""

def judge(answer_key: dict, model_output: str, judge_client) -> JudgeResult:
    raw = judge_client.structured_complete(
        prompt=JUDGE_PROMPT.format(answer_key=answer_key, model_output=model_output),
        response_schema=JudgeResult,   # tool use / JSON schema 制約で構造を強制する
    )
    try:
        return JudgeResult.model_validate(raw)
    except ValidationError as e:
        # 構造が壊れた出力は「採点失敗」として扱い、無理にパースしない
        raise RuntimeError(f"judge出力がスキーマ不適合: {e}") from e

def score(result: JudgeResult) -> float:
    if not result.items:
        raise ValueError("採点項目が0件。judgeモデルの応答が壊れている可能性")
    return sum(i.verdict for i in result.items) / len(result.items)

ここでの実装上の勘所は2つです。

quote（根拠の引用）を必須フィールドにする。引用元を書かせることで、judgeモデル自身にも「通読しての印象」ではなく項目ごとの裏取りを強制できます
採点役には評価対象と別系統の高性能モデルを使う。候補モデル自身に自己採点させると評価が甘くなりやすいため、judge_clientは候補モデルのプールとは別に固定します

実装3: 天井効果を自動検出してバージョンをエスカレーションする

候補モデルが軒並み満点になる「天井効果」は、人間が表を見て気づくのではなく、コードで機械的に検出できるようにしておくとハーネスとして回しやすくなります。

def has_ceiling_effect(scores: dict[str, float], threshold: float = 0.95, spread: float = 0.05) -> bool:
    """全モデルが高スコアかつ横並び(差が小さい)なら天井効果と判定する"""
    values = list(scores.values())
    return min(values) >= threshold and (max(values) - min(values)) <= spread

def run_versioned_harness(versions: list[str], run_one_version) -> None:
    for version in versions:
        scores = run_one_version(version)  # {"gemini-2.5-flash": 0.98, "gemini-2.5-pro": 1.0} など
        print(f"[{version}] scores={scores}")
        if not has_ceiling_effect(scores):
            print(f"[{version}] 判別力あり。ここで確定")
            break
        print(f"[{version}] 天井効果を検出 → 次バージョンへ")

難易度を上げる3方向（ノイズ・トラップ・複数ステップ推論）は本家記事で解説した通りですが、実装上重要なのは「v1を消さずに残す」ことです。v1は「これすら落とすモデルは論外」という最低ライン確認用の回帰テストとして再利用できるため、versionsリストに["v1", "v2", "v3"]のように積み上げていく設計にしておくと、後から追加した候補モデルのふるい落としにもそのまま使えます。

実装4: Ollama `num_ctx` の罠を実測で潰す

ローカルLLM（Ollama）特有の罠として、ollama showが返す「モデルが対応できる最大コンテキスト長」と、実行時に実際に使われるコンテキスト長は別物です。後者はVRAMから自動算出された、もっと小さい値になっていることがあります。

まず、モデルの最大値と実行時デフォルトの候補を確認します。

# モデルカードの最大コンテキスト長を確認（例: qwen2.5系は32768）
curl -s http://localhost:11434/api/show -d '{"name": "qwen2.5:7b"}' \
  | jq '.model_info["qwen2.context_length"], .parameters'

parameters側に明示的なnum_ctxが設定されていなければ、実行時はVRAMに応じた自動値（環境によっては4096程度）で動きます。これを信用してはいけません。num_ctxは呼び出し側で明示指定し、実行後に実際の消費トークン数を必ず裏取りします。

import requests

def call_ollama(prompt: str, model: str, num_ctx: int) -> dict:
    resp = requests.post(
        "http://localhost:11434/api/generate",
        json={
            "model": model,
            "prompt": prompt,
            "stream": False,
            "options": {"num_ctx": num_ctx},  # 自動算出値に任せず明示指定する
        },
        timeout=120,
    )
    resp.raise_for_status()
    return resp.json()

def call_with_truncation_check(prompt: str, model: str, num_ctx: int = 8192) -> str:
    result = call_ollama(prompt, model=model, num_ctx=num_ctx)
    consumed = result["prompt_eval_count"]
    if consumed >= num_ctx:
        # 消費トークンがnum_ctxに張り付いている = プロンプトの先頭側が
        # 切り捨てられた疑いが強い。無言で結果を採用しない
        raise RuntimeError(
            f"prompt_eval_count={consumed} が num_ctx={num_ctx} 以上。"
            f"num_ctx を引き上げて再実行すること"
        )
    return result["response"]

評価ハーネスに候補モデルとしてOllamaを組み込む場合は、このcall_with_truncation_checkのようなラッパーを経由させ、切り捨てが起きた実行結果はスコアに混ぜずにエラーとして弾く運用にしておくと、「モデルの実力不足」なのか「単に入力が切り捨てられていただけ」なのかを取り違えずに済みます。

まとめ: 実装チェックリスト

正解キー生成関数は、テストデータ生成関数のパラメータ（seed・倍率等）を一切参照していないか
LLM-as-judgeの出力はフリーテキストではなく、スキーマ（pydantic等）で構造を強制しているか
judgeの各項目に根拠の引用(quote)フィールドを必須化しているか
天井効果の判定（has_ceiling_effect相当）をコードで自動化しているか
難易度を上げた新バージョンを追加しても、旧バージョン（v1等）は回帰テストとして残しているか
Ollama利用時、num_ctxを明示指定し、prompt_eval_countで切り捨てをチェックする処理を挟んでいるか

評価テストの「考え方」は本家記事、「実装」は本記事、という組み合わせで読むと、実際に自分の環境でハーネスを組む際の迷いが減るはずです。

元記事

公開ベンチマークだけでLLMを選んでいませんか？——判別力のある評価テストを自作する方法 — amanity.co.jp

「どう考えるか」の全体像（8ステップ）や、実際にGemini 2.5 Flash/Pro・ローカルLLMで検証した結果は元記事をご覧ください。