LLM チャットボットの「ブレ」をどう測るか —— 出力差異の 7 層分類と応答品質の評価設計

はじめに —— LLM の「正しさ」は 1 回の出力では測れない

LLM をバックエンドにしたチャットボットは、カスタマーサポート、社内ナレッジ検索、ドキュメント作成支援、開発者向けエージェント、音声アシスタントなど、多くのプロダクトでユーザーが直接触れる部分になりつつある。ユーザーが使うのはモデル単体ではなく、モデルの出力を含む会話システムである。

従来のソフトウェアなら、同じ入力に同じ出力が返ることを前提にテストを書ける。LLM では、モデル、パラメーター、システムプロンプト、ユーザープロンプト、検索結果、ツール定義を固定しても、出力が変わることがある。

ある回では箇条書きで丁寧に答え、次の回では同じ意味を短く述べ、別の回では根拠の一部を省く。数値・固有名詞・条件・結論の向きが変わることもある。

本稿では、生成結果の差異を次の 2 つに分けて定義する。

ブレ：生成条件を同一にしたとしても発生する生成結果の差異。

ドリフト：生成条件の変化によって発生する生成結果の差異。

生成条件には、利用モデル、モデルバージョン、推論パラメーター、システムプロンプト、ユーザープロンプト、ツール定義、検索インデックスのスナップショット、参照文書、実行時ポリシー、バックエンドの system fingerprint などを含める。モデルの更新、検索結果の変化、プロンプトの書き換えによる差分は、ブレではなくドリフトとして扱う。

実務では、両者を簡単には分離できない。API の背後でモデルが更新されることがあるため、ブレに見える差分が実際には隠れたドリフトかもしれない。そのため評価ログには、できる限りモデル ID、バージョン、推論パラメーター、seed、プロンプト、検索結果、ツール応答、system fingerprint、セッション状態、メモリー、ユーザープロファイル、時刻・タイムゾーン、キャッシュ状態、副作用を持つ外部状態、ランタイムの識別子を残す必要がある。

seed を指定できる環境では、評価を次の 2 つのモードに分ける。

同じ seed で反復すると、モデルの確率的な出力分布をサンプリングするというより、再現性やバックエンドの非決定性をテストすることになる。2 つのモードを混ぜると、ブレの評価値を読み違える。

ブレ測定でも、観測された fingerprint が異なる実行は同じ母集団に混ぜない。隠れたドリフトとして分けるか、fingerprint ごとのグループに分けて分析する。

完全一致だけを見れば、無害な言い換えまで失敗扱いになる。埋め込み類似度だけを見れば、数値の違いや否定の反転を見落とすことがある。LLM 判定だけに頼れば、評価者自身のブレを品質評価に混ぜてしまう。

したがって、出力が「なんとなく違う」で止めず、何が違うのかを層に分けて測る必要がある。

1. 評価対象を「1 出力」から「出力分布」へ移す

生成条件を $c$、プロンプトまたは評価ケースを $p$ とする。同じ $c$ と $p$ で $n$ 回生成した出力を、次のように置く。

従来のテストは、単一の出力 $y$ を Ground Truth $g$ と比べることが多い。ブレを評価するには、1 つの $y$ ではなく、同一条件下の出力分布 $Y_{p,c}$ を評価の対象にする。

この分布に対しては、少なくとも 2 種類の比較が必要になる。

対 Ground Truth 比較だけでは、「たまたま 1 回だけ良かった」のか「安定して良い」のかが分からない。出力間比較だけでは、「安定して間違っている」ケースを見逃す。したがって、正解からの距離と同一条件内の散らばりの両方を測る。

最小限の評価プロトコルは次のようになる。

1. 評価ケース $p$ と生成条件 $c$ を固定する。
2. 同じケースを $n$ 回実行する。実務上はコストに応じて $n=5$ から $30$ 程度のスクリーニングから始める。
3. すべての出力を保存する。最終テキストに加えて、ツール呼び出し、検索結果、拒否理由、トークン使用量、レイテンシーも残す。
4. 各出力を Ground Truth と比較する。
5. 出力同士を相互比較する。
6. 平均に加えて、最悪値、分位点、合格率、クラスター数を見る。

$n=5$ から $30$ という範囲は、信頼性を精密に推定するためではなく、危険なブレを早く見つけるための探索的な目安である。合格率は pass_count / n のように分母と一緒に報告し、できれば Wilson 区間や Jeffreys 区間で二項比率の不確実性も示す。これらの区間は、固定した二値ゲートに対する各試行を独立な Bernoulli 試行とみなす近似に依存する。実際の LLM API では、キャッシュ、共有バックエンド状態、レート制限、judge の使い回しによって試行が相関することがある。

リリース判定に使うなら、事前に「下側信頼限界が 0.95 を超えること」や「失敗率の上側限界が 1% 未満であること」のような基準を決める。30/30 の成功でも、稀な失敗がないことは証明できない。独立 Bernoulli 近似のもとでも、30 回無失敗のときの片側 95% 上側失敗率は約 10% である。高リスクの安全ゲートや意味ゲートでは、少数試行の 9/10 や 29/30 を「安定」と読みすぎず、より大きなサンプルと境界ケースの集中テストを用意する。

具体的には、独立試行で失敗が 0 件だったときに片側 95% の上側失敗率を 1% 未満にしたいなら、$n \ge \log(0.05) / \log(0.99)$、つまり約 299 回の無失敗が必要になる。この概算は、少数のサンプルでは本番の安全性をほとんど示せないことを表している。実際の評価では、スライス（権限変更や返金条件など、評価ケースを領域ごとに分けた部分集合）ごとのリスクや、試行間の相関も考慮する。

ブレが常に悪いわけではない。自然言語には正しい答えが複数ある。説明文では、表現の多様性が望ましい場合もある。一方、医療判断、契約条項、見積金額、権限操作、運用手順では、小さなブレが重大なリスクになる。ブレをどこまで許容できるかは、タスクによって変わる。

2. ブレの分類 —— 何が変わったのかを分ける

文字、語彙、語順、情報の選び方、意味、会話上の行為のどれが違うかで、品質への影響は大きく異なる。

ブレを次の 7 層に分ける。

1 つの出力ペアは、複数の層で同時に違うことがある。大幅な言い換えは、文字も語彙も構造も変える。誤った数値は、表層的には小さな差でも意味的には大きな差になる。

そのため、7 層は応答ペアに 1 つだけ付けるラベルではない。主に何を観測しているかで、重複や漏れができるだけ少なくなるように分けた診断次元であり、実際の失敗は複数の層にまたがりうる。たとえば必須 claim の欠落は情報選択ブレであると同時に、タスクによっては意味の不完全性でもある。安全でない推奨は語用ブレとして観測できるが、安全ゲートでは独立に拒否される。最終判定では、1 つのラベルに押し込まず、各層のスコアをベクトルとして組み合わせる。

この分類は、最終的な自然言語の応答を中心にしている。ツール実行やエージェントの行動を含むチャットボットでは、同じ考え方を行動ブレに広げる必要がある。対象は、呼び出したツール名、引数スキーマ、引数値、呼び出し順序、リトライ、外部副作用の種類、ツール結果への依存関係である。たとえば最終的な回答文が同じでも、裏側で権限変更ツールを呼んだ実行と、案内文を返しただけの実行は、同じ品質とは扱えない。副作用を持つツールでは、テキストの意味ゲートより前に、行動の契約ゲートと安全ゲートを置くべきである。

次の 2 つの出力を Ground Truth と比べる。

Ground Truth: 返金は購入日から30日以内に申請できます。
Output A: 購入後30日以内であれば返金申請が可能です。
Output B: 返金は購入日から60日以内に申請できます。

Output A は表層・語彙・構造が違うが、意味はほぼ同じである。Output B は文字列としては Ground Truth にかなり近いが、返金期限が変わっており、利用者に誤った条件を伝える。完全一致や編集距離だけでは、この 2 つを正しく区別できない。

3. 意味の近さを含意関係で分ける

LLM 評価で特に危険なのは、「意味が近い」を 1 つの数値で片づけることだ。

埋め込みのコサイン類似度は、大幅な言い換え、順序の違い、語彙の違いを吸収できる。しかし、似た文脈に現れる否定・数値・固有名詞・条件の違いを過小評価することがある。

A: この薬は妊娠中に使用できます。
B: この薬は妊娠中に使用できません。

この 2 文は語彙の大半を共有し、埋め込み空間でも近くなりやすい。しかし内容は正反対である。そこで意味ブレは、少なくとも次の 4 種類の関係に分けて見る。

この区別には Natural Language Inference（NLI）や LLM-as-judge が使えるが、数値、単位、日付、固有名詞、条件節、例外規定では、NLI モデルも LLM-as-judge も誤りやすい。リスクの高い領域では、意味を判定する前にエンティティーやスロットを抽出して比較する。

返金ポリシーの回答なら、文全体の類似度より先に、次のようなスロットを比較する。

期限スロットが違うので、文章全体がどれだけ似ていても失敗と判定できる。

4. 指標は「何を見ているか」で選ぶ

これらの指標に優劣の順位はない。銀行振込の金額 JSON を評価するなら、完全一致やスキーマ検証が最も強い。FAQ の自然文回答なら、埋め込み類似度や NLI が役に立つ。接客チャットの丁寧さなら、人間評価か較正済みの LLM-as-judge が必要になる。

良い評価設計とは、強い指標を 1 個選ぶことではなく、壊れ方に対応する複数の弱い指標を正しい順序で並べることである。

指標の値は、実装の細部にも左右される。正規化一致なら、大小文字、全角半角、Unicode 正規化、句読点、空白をどう扱うかを固定する必要がある。token F1、BLEU、ROUGE-L は、tokenizer や日本語の分かち書き器で値が変わる。評価結果を比較できるようにするには、normalizer、tokenizer、辞書、ライブラリーのバージョンを評価ログに残す。

5. Ground Truth との差分を読む評価決定木

次に、出力と Ground Truth の差をどの種類の差として扱うかを決める決定木を作る。

決定木の入力は、複数の指標からなるベクトルである。

raw_exact
normalized_exact
char_edit_distance
token_overlap
rouge_l
embedding_cosine
nli_g_to_y
nli_y_to_g
contradiction
slot_diff
speech_act_diff
safety_policy_diff

このベクトルを、計算コストの低い指標から高い指標へ順に読む。

実装では、以下で使う「高い」「中程度」「低い」「極小」といった言葉を、設定ファイルの値として定義する必要がある。

たとえば、cosine が高くても禁止 claim が見つかったら fail にする。ROUGE-L と cosine が食い違い、slot 差分も不明なら needs_review に送る。決定木は、しきい値・優先順位・エスカレーション先を含む設定として管理する。

しきい値は calibration set で調整し、別に凍結した holdout / regression set で結果を報告する。同じ評価セットを見ながらしきい値を何度も動かすと、評価器そのものがそのセットに過学習する。高リスクのスライスでは、全体平均に加えてスライスごとの結果を固定セットで追う。

5-1. 契約を先に見る

意味を見る前に、出力が契約を満たしているかを確認する。

if no_output or timeout:
  return "無応答・実行失敗"
 
if expected_json and not valid_json:
  return "形式違反"
 
if required_language != detected_language:
  return "言語制約違反"
 
if length > budget:
  return "長さ制約違反"

契約違反は、意味が正しくてもユーザー体験を壊すことがある。たとえば下流のプログラムが JSON を期待しているなら、意味的に正しい自然文でも失敗である。

5-2. 表層差を分離する

次に、正規化によって消える差を分ける。

多くのケースは、この段階で判定が終わる。たとえば「3,000円」と「3000 円」を別回答として扱うべきかは、タスク次第である。決済金額の文字列なら厳密に見るべきだが、FAQ の説明文なら正規化で吸収してよいかもしれない。

5-3. 構造差と言い換えを分ける

表層では一致しないが、token overlap や ROUGE-L が高ければ、構造は近い。

ROUGE-L は「同じ単語が同じ順序で出てくるか」を見ている。したがって、箇条書きの順序が重要な手順書では有効だが、順序が自由な要点列では過剰に厳しくなる。

5-4. 省略・追加・矛盾を分ける

意味が近そうに見える場合でも、次に情報選択と命題関係を見る。

省略が常に悪いわけではない。短いチャット回答では、根拠を省くほうが良い場合もある。一方、法務・医療・金融・運用手順では、省略された例外条件が事故につながる。

NLI を使う場合は、向きに注意する。標準的な NLI は premise / hypothesis の順序付き分類であり、1 つの nli_relation だけでは「同義」「より具体的」「より一般的」を確実には区別できない。少なくとも g -> y と y -> g の両方向を評価する。両方が entailment なら実質同義、y -> g だけなら出力がより具体的または追加 claim を持つ、g -> y だけなら出力がより一般的または省略している、と読む。

情報選択ブレは、情報が「多い/少ない」ではなく、必須 claim の coverage（網羅率）と根拠のない claim や不要な claim の intrusion（混入率）として測るのがよい。

coverage = included_required_claims / all_required_claims
intrusion = unsupported_or_unwanted_claims / all_output_claims

coverage が低ければ省略、intrusion が高ければ過剰追加またはハルシネーションの疑いがある。実装では、出力 claim が 0 件の場合の分母を明示し、禁止 claim は intrusion の割合に埋め込まずハードゲートとして扱う。また、返金期限や禁忌のような重大 claim には、例示や補足より大きな重みを持たせるべきである。

ただし、claim / slot 抽出器も評価器の一部であり、完全な測定器ではない。ルールで抽出する場合は schema と ontology を versioning し、モデルで抽出する場合は人間ラベル付き claim に対する precision / recall を測る。抽出 confidence を保存し、境界ケースや重大 claim は監査対象にする。抽出器が claim を見落とすと（false negative）、実際の失敗が隠れてしまう。

5-5. 語用差を見る

最後に、意味だけでは説明できない差を見る。

Ground Truth: その操作は権限が必要です。管理者に依頼してください。
Output A: その操作は権限が必要です。管理者に依頼してください。
Output B: 権限を回避する方法を試してみましょう。

Output B は、関連語も意味領域も近いかもしれない。しかし会話行為としては、許容できない提案をしている。これは語用ブレである。

語用ブレには、次のようなものが含まれる。

この層は人間評価や LLM-as-judge が必要になりやすい。ただし、全件を人間に見せる必要はない。契約や意味のチェックを先に通し、語用ブレはサンプリング評価や高リスクケースの集中評価に回すのが現実的である。

6. ブレの「大きさ」だけでなく「方向」を見る

多くの類似度指標は、差分を 1 次元の距離として返す。品質評価では、距離に加えて、どちら向きにずれたかも必要になる。

同じ距離でも、次の 2 つは意味が違う。

Ground Truth: パスワードは8文字以上にしてください。
Output A: パスワードは12文字以上にしてください。
Output B: パスワードは4文字以上にしてください。

どちらも数値が違う。しかし A はより厳しい方向、B はより弱い方向である。セキュリティー要件なら、おそらく B のほうが危険である。一方、ユーザーに過剰な負担をかけるという観点では A も問題になる。

そこで、「数値が違う」という判定に加えて、制約の向きを抽出する。

語用の差にも向きがある。拒否が強くなったか弱くなったか、確信度が上がったか下がったか、ユーザーに行動を促すようになったか保留を促すようになったか、である。

差分は、次の 3 つの観点で記述すると扱いやすい。

許容可能性は、この 3 つの組み合わせで決まる。

7. 人間にとっての許容可能性はスコアの合成で決まる

ある出力 $y$ の品質は、単一スコアではなく次のようなベクトルで表現できる。

ここで $C_0$ は契約、$S_1$ は表層、$L_2$ は語彙、$R_3$ は構造、$I_4$ は情報選択、$M_5$ は意味、$P_6$ は語用の評価値である。

人間の許容判断は、おそらくこのベクトルの非線形な関数である。

ここで $task\_risk$ は、ドメインのリスクである。雑談なら語彙・構造ブレはほぼ問題にならない。FAQ なら情報選択と意味が重要になる。金融・医療・法務・セキュリティーなら、数値、条件、拒否方針の小さなブレが許容不可になる。

実務上は、全ケースを 1 つのしきい値で切るより、次のようなゲートに分けるほうがよい。

この設計なら、完全一致では落ちるが人間には許容できる応答を合格にしつつ、文字列は近いが意味的に危険な応答を不合格にできる。

8. 出力間のブレを集計する

Ground Truth との比較に加えて、同一条件内の出力間ブレも重要である。10 回生成して 9 回は正しく、1 回だけ危険な回答をするモデルは、平均スコアでは高く見えるが、本番ではその 1 回がユーザーに届く。

出力間ブレは、次の指標で見る。

pass rate は最も重要な安定性指標だが、全ケースをまとめた 1 つの数字に潰してはいけない。920/1000 pass は見栄えがよくても、権限変更・医療・返金条件・セキュリティーポリシーのような高リスクのスライスが壊れていれば、その数字は失敗を隠してしまう。ケースごとの pass rate、スライスごとの pass rate、macro average、リスク重み付き summary、worst-slice の結果を併記する。信頼区間や bootstrap も、単純な生成単位だけでなく case / slice でクラスター化して考える。

出力間の比較には統計上の注意点もある。$n$ 個の出力から作る $n(n-1)/2$ 個のペアは独立ではない。同じ出力が多くのペアに参加するからである。contradiction rate を報告するとき、ペア数をそのまま独立サンプル数として信頼区間を作ってはいけない。より安全なのは、距離関数、クラスタリング方法、しきい値を明記し、必要なら出力単位で bootstrap することである。「少なくとも 1 つの他出力と矛盾した出力の割合」のような per-output 指標も併記する。cluster count も、距離指標としきい値に強く依存するため、設定込みで解釈する。

Case A: 10/10 pass, 表現だけが散らばる
Case B: 8/10 pass, 2 回は必須条件を省略
Case C: 9/10 pass, 1 回は危険な行動を提案

平均類似度だけなら A, B, C の差は小さく見えるかもしれない。しかし運用上の扱いは大きく違う。A は許容しやすい。B はプロンプトや検索コンテキストの改善対象で、C は安全ゲートまたはデプロイ停止の候補である。

また、出力同士をクラスタリングすると、モデル内部の「迷い」が見えることがある。

Cluster 1: 返金可能と答える
Cluster 2: 返金不可と答える
Cluster 3: サポートに問い合わせるよう促す

このようなクラスターが同一条件で現れるなら、表現が多様なのではなく、知識、方針、検索結果の使い方、プロンプトの拘束力のどこかが不安定になっている。

9. 評価セットは「ブレやすい点」を狙って作る

ランダムに集めた質問だけでは、ブレの危険部分は見えにくい。評価セットは、モデルが迷いやすい境界を意図的に含めるべきである。

この評価セットを作るとき、Ground Truth は「模範回答文」だけでは足りない。自然文の 1 つの正解に固定すると、許容できる言い換えまで落としてしまう。

よりよい Ground Truth は、次の複数の層で持つ。

模範回答文は、この Ground Truth の 1 つの実現例にすぎない。

Ground Truth 自体にも出所の記録（provenance）が必要である。RAG（検索拡張生成）、FAQ、規約、ポリシー評価では、required/forbidden claim に source ID、引用 span、有効日、claim weight、許容される言い換え、注釈者、adjudicator、レビュー状態を持たせる。高リスクな claim は 2 名以上で注釈し、不一致を裁定する。Ground Truth が誰のどの版の判断なのかを追えないと、評価は別の不安定な意見に置き換わるだけになる。

RAG では、Ground Truth の provenance だけでなく、出力側の groundedness も見る。重要な output claim は取得された source span に対応づけ、unsupported-claim rate、citation precision、citation recall、source-version mismatch を報告する。正しい claim を含んでいても間違った文書を引用していれば、監査可能性やユーザー信頼の観点では失敗になりうる。

10. LLM-as-judge を使うなら、評価者のブレも測る

LLM-as-judge は、語用、トーン、安全性、複合的な許容可能性の判定で、人間評価に近い判断を低コストで大量に行える。ただし、生成モデルを評価者に使う以上、評価者自身にもブレがある。

最低限、次を確認する。

単純な一致率（raw agreement）だけでは不十分である。失敗例が少ないデータでは、ほとんど全部 pass と言うだけで高い一致率に見える。安全・意味ゲートでは、failure class ごとの混同行列、fail ラベルの precision / recall、重大 failure の false negative rate を見る。高リスクのスライスは裁定済みの人間ラベルを基準にし、judge model/version/fingerprint、judge prompt、rubric version、temperature/seed、JSON parser や post-processor の version も評価条件として固定する。

LLM-as-judge は、できれば二値判定だけでなく、理由とラベルを分けて出させる。

You are evaluating whether the assistant answer is acceptable.
Assess only the following rubric items:
1. Required claims are present.
2. No forbidden claims are present.
3. The answer does not contradict the reference.
4. The recommended next action is safe.
 
Return JSON with:
- pass: boolean
- failed_items: string[]
- evidence: short quotes from the answer

ただし、judge の説明文は監査の手がかりであり、判定が正しいことの証明にはならない。

11. 実装上の評価パイプライン

実務で使うなら、評価は次の順序で流すのが扱いやすい。

1. ログ固定
   model, parameters, prompts, retrieval snapshot, tool outputs,
   session state, memory, user profile, clock/timezone, cache, side-effect state,
   judge/extractor/reranker versions and prompts
 
2. 契約チェック
   no output, timeout, schema, language, length
 
3. 正規化と表層比較
   exact, normalized exact, edit distance
 
4. 構造比較
   token overlap, ROUGE-L, outline/order comparison
 
5. claim / slot 抽出
   required claims, forbidden claims, numeric/entity slots
 
6. 意味関係判定
   NLI, QA-based check, calibrated LLM judge
 
7. 語用・安全性判定
   refusal, next action, tone, policy, human review sample
 
8. 集計
   pass rate, worst case, variance, clusters, contradiction rate

この順序では、安くて再現性の高いチェックを先に置いている。JSON が壊れている応答に LLM judge を呼ぶ必要はないし、必須スロットが明らかに違う応答について埋め込み類似度を解釈する必要もない。

評価レポートは、平均スコアに加えて次のような表で出す。

「モデルの平均点が 0.82」という報告と違い、この表からはどのケースで何を直せばよいかが分かる。

12. 結論 —— ブレは消すものではなく、管理するもの

自然言語を扱う以上、表現の多様性は避けられないし、しばしば価値でもある。評価で必要なのは、すべてのブレを消すことではなく、許容できるブレと許容できないブレを分けることである。そのためには、完全一致も、埋め込み類似度も、LLM-as-judge も、単独では足りない。

ブレは、契約（Layer 0）から語用（Layer 6）までの 7 層に分けられる。低い層ほど機械的に測りやすく、高い層ほど人間の許容判断に近い。

人間が「この応答は許容できる」と判断するとき、文字列の一致だけを見ているわけではない。意味が保たれているか、必要な条件を落としていないか、危険な次アクションを促していないか、タスクのリスクに対して十分に慎重か、といった複数の観点を、ほとんど瞬時に組み合わせて判断している。

評価設計の仕事は、その判断をできるだけ分解し、再現可能な測定に落とし、人間が見るべき箇所を減らすことだ。

LLM チャットボットの品質保証は、「正解文とどれくらい似ているか」から、「同一条件下の出力分布が、タスクにとって許容可能な範囲に収まっているか」へ移っていくべきだと思う。