LLMアプリケーションの評価フレームワーク――オフライン評価とA/Bテスト

LLMアプリケーションの品質評価は、従来のソフトウェアテストの常識が通用しない領域です。本記事では、結論から言うとオフライン評価(テストセット)→ A/Bテスト(本番トラフィック)→ 継続的評価(プロダクション監視)という三段構成を提案します。単体テストがPASS/FAILで判定できた時代から、「0.87の精度と0.91の精度、どちらが良いのか」を議論する時代になりました。本記事では、その議論を曖昧な主観から再現可能な数字へと変えるための枠組みをまとめます。

LLMアプリの評価はなぜ特殊か

LLMアプリの評価が特殊なのは、従来のソフトウェアテストのように「期待する出力」を1対1で定義できない点にあります。例えば「日本の首都は?」という質問には「東京です」「東京」「Tokyo」「日本の首都は東京都です」など、正解の表現が無数に存在します。さらに、要約や生成系タスクでは「どちらも正しい」という出力が複数存在し得ます。

加えて、LLMは非決定的です。同じ入力でも温度パラメータやサンプリングによって出力が変動します。このため、評価指標は「一発合格/不合格」ではなく「母集団に対する成功率の分布」で議論する必要があります。さらに品質・コスト・レイテンシは相互にトレードオフの関係にあり、「精度を1%上げるためにコストを2倍にする価値があるか」というビジネス判断が常につきまといます。評価フレームワークは、この判断をデータで支えるための装置です。

オフライン評価の設計

オフライン評価は、本番トラフィックを流す前の事前検証フェーズです。評価用のテストセットを準備し、新しいプロンプトやモデルを試すたびに自動で回します。評価手法は大きく3つに分類できます。

手法	精度	コスト	スケーラビリティ	適した場面
ルールベース(完全一致・BLEU等)	低〜中	極小	高	分類・抽出タスク
LLM-as-a-Judge	中〜高	中	中	生成・要約・対話
人間評価	高	高	低	最終品質判断・ゴールドデータ作成

テストセットの作成が評価の品質を決めます。おすすめは本番ログから多様なサンプルを抽出し、人手で正解を付けたゴールドデータセットを作ることです。最低でも100件、できれば500〜1000件あれば、プロンプト変更の有意差を検出できます。以下はオフライン評価パイプラインの骨格です。

import json
from statistics import mean

def run_offline_eval(test_set_path: str, model_fn, judge_fn):
    results = []
    with open(test_set_path) as f:
        cases = [json.loads(line) for line in f]
    for case in cases:
        prediction = model_fn(case["input"])
        score = judge_fn(
            input=case["input"],
            expected=case["expected"],
            actual=prediction,
        )
        results.append({
            "id": case["id"],
            "score": score,
            "input": case["input"],
            "prediction": prediction,
        })
    pass_rate = mean([1 if r["score"] >= 0.8 else 0 for r in results])
    return {"pass_rate": pass_rate, "avg_score": mean([r["score"] for r in results]), "cases": results}

オンライン評価(A/Bテスト)の設計

オフライン評価で有望な候補を絞り込んだら、次は本番トラフィックでのA/Bテストです。オフライン評価は優秀な予測子ですが、ユーザーの実際の反応を測る唯一の方法はA/Bテストです。

チェック項目	推奨値・基準
実験対象のトラフィック割合	10〜30%(リスクに応じて)
最小サンプル数	各群500件以上(希少イベントの場合はさらに増やす)
統計的有意水準	p < 0.05(二項検定・t検定など)
主要指標	タスク成功率・満足度・コスト・レイテンシ
ガードレール指標	エラー率・幻覚率・不適切表現率
実施期間	最低1週間(曜日効果を吸収)

A/Bテストでは主要指標(primary metric)が改善していても、ガードレール指標が悪化していないか必ず確認してください。「成功率は上がったがコストが2倍」「満足度は上がったが不適切表現が増えた」といった副作用は日常茶飯事です。

import hashlib

def assign_variant(user_id: str, exp_name: str, split: float = 0.2) -> str:
    h = hashlib.md5(f"{user_id}:{exp_name}".encode()).hexdigest()
    bucket = int(h[:8], 16) / 0xFFFFFFFF
    return "treatment" if bucket < split else "control"

def handle_request(user_id: str, query: str):
    variant = assign_variant(user_id, "prompt_v2")
    prompt = PROMPT_V2 if variant == "treatment" else PROMPT_V1
    response = llm_call(prompt, query)
    log_event(user_id=user_id, variant=variant, query=query, response=response)
    return response

評価ツールの比較

自前で評価基盤を作る前に、既存のOSS・SaaSツールを検討する価値があります。2026年時点で存在感のある代表的なツールは次の通りです。

ツール	提供形態	強み	注意点
promptfoo	OSS(CLI中心)	CI/CD統合が容易、宣言的YAMLで評価設計	大規模ダッシュボードは別途必要
DeepEval	OSS(Pythonライブラリ)	Pytestライクな書き味、評価メトリクス豊富	複雑なシナリオ評価は自前拡張が必要
Braintrust	SaaS(有償)	ゴールドデータ管理、人手レビューUIが強力	コスト・データ持ち出し要検討
Langfuse	OSS+SaaS	トレース・評価・プロンプト管理の統合	セルフホスト時の運用工数

初期段階ではpromptfooを用いたCI組み込みから始めるのが現実的です。規模が拡大してくると、評価ログの集約、人手レビュー、ダッシュボードといった要件が出てくるため、LangfuseやBraintrustのような統合プラットフォームの導入を検討するフェーズに入ります。

継続的評価の仕組み

評価はリリース前の一度きりではなく、本番稼働後も継続的に回す必要があります。理由は3つあります。第一にLLMベンダー側のモデル更新です。OpenAIやAnthropicは定期的にバージョンを上げており、同じプロンプトでも出力特性が変わります。第二にデータドリフトです。ユーザーの質問内容は時間とともに変化し、数か月前には想定していなかった入力が増えます。第三にプロンプト・インジェクション等の攻撃で、悪意ある入力に対する耐性は継続的にテストする必要があります。

具体的には、本番ログから定期的にサンプリングしてゴールドデータに追加し、週次または日次でオフライン評価を自動実行します。指標が閾値を下回った場合はSlack/PagerDutyに通知し、人間が原因調査に入ります。この「評価CI」を回せるかどうかが、LLMアプリ運用の成熟度を決める分水嶺になります。

まとめ

LLMアプリの評価は、オフライン・オンライン・継続的評価の三段構成で設計するのが基本です。重要なのは「評価は一度作って終わり」ではなく、評価データセットと評価指標自体も継続的に改善していくという姿勢です。関連記事としてLLM評価方法、RAG評価メトリクス、モデルA/Bテスト、LLMオブザーバビリティもあわせてご参照ください。

よくある質問(FAQ)

Q1. LLMアプリの品質をどう測定すべきですか?

A. オフライン評価(テストセットによる事前検証)とオンライン評価(A/Bテストによる本番検証)の2段階で測定します。自動評価と人間評価を組み合わせ、精度・レイテンシ・コストの3軸で総合判断してください。単一の指標に頼ると局所最適化に陥るリスクがあります。

Q2. A/BテストでLLMのプロンプト変更を検証するには?

A. トラフィックの一定割合(10〜30%)を新プロンプトに振り分け、タスク成功率、ユーザー満足度、コストの3指標で比較します。統計的有意性を担保するために、十分なサンプル数(通常数百〜数千件)が必要です。また、曜日効果を吸収するため最低1週間の実施期間を設けることが望ましいです。

Q3. LLM-as-Judgeの評価は信頼できますか?

A. 人間評価との相関が高いことが複数の研究で示されていますが、位置バイアスや長文優遇バイアスといった弱点もあります。評価プロンプトの設計、複数の評価基準の設定、定期的な人間評価との突合せで信頼性を維持してください。Judgeモデル自体も定期的にチューニングする運用が理想です。