会話 UX をどう測るか —— LLM エージェントと人間の対話を評価する、構造・内容・体験と決定論の地図

はじめに —— 「モデルの賢さ」では会話の良し悪しは測れない

LLM の評価といえば、まず思い浮かぶのはベンチマークでしょう。MMLU、GSM8K、SWE-bench など、モデルがどれだけ「賢いか」を測る尺度は数多くあります。ところが、賢いモデルをバックエンドに据えた会話エージェントを実際にユーザーへ届けると、ベンチマークでは説明できない「会話の良し悪し」が問題になります。

正答率の高いモデルでも、次のような壊れ方をすることがあります。

• 同じことを延々と聞き返してループに陥る
• 質問とは微妙にずれた、長すぎる答えを返す
• 自信満々に嘘の規約を語る
• 内容は正しいのに、どこか見下したような冷たい応答をする

逆に、モデル単体の性能は控えめでも、テンポよく、的確で、感じの良い会話を提供できるプロダクトもあります。会話 UX の良し悪しは、モデル単体の賢さとは別に評価する必要があります。

本記事では、会話 UX の良し悪しを感覚ではなく体系的に測るために、次の 3 つの問いを扱います。

1. 評価軸を、MECE（漏れなく・重複なく）なルールセットとしてどう設計するか
2. それぞれを、決定論的に測れるものと測れないものに分けてどう計測するか
3. テキストチャットと音声対話で、軸の重みがどう変わるか

結論から言えば、会話 UX は 3 つの品質軸と 1 つの制約軸で捉えられます。

最初の 3 軸（S・C・G）は「会話の質」を測る互いに分離可能な次元で、一般に「会話の良し悪し」と感じるものの中身です。ただし LLM エージェントは行動し、第三者に影響を及ぼすため、欠陥を MECE に網羅するには、品質とは性質の異なる第 4 の軸として Safety が必要です。

以下では 4 軸をサブルールまで分解し、各ルールをどこまで決定論的に測れるか（決定論の地図）に沿って並べます。

I. 軸モデル —— Structure / Correctness / Goodness（＋Safety）

なぜこの軸なのか

会話に起こりうる欠陥は、性質の違う 4 つの問いに分けられます。はじめの 3 つが「会話の質」を、最後の 1 つが「許容可能性」を問います。

• 「そもそも会話が会話として成立したか」（Structure）—— ターンが噛み合い、応答があり、ループせず、形式が整っているか。意味を理解しなくても、ログとタイムスタンプだけで判定できます。
• 「言っている中身は正しいか」（Correctness）—— 事実に合致し、質問に関連し、矛盾せず、タスクを達成しているか。意味を理解しないと判定できません。
• 「その体験は良かったか」（Goodness）—— 役立ち、語調が適切で、自然で、満足できたか。主観を測らないと判定できません。
• 「その応答は無害で許容できるか」（Safety）—— 有害・不公平でなく、PII を漏らさず、インジェクションや脱獄に耐えるか。他の 3 軸が満点でも独立に崩れうる制約です。

はじめの 3 つは、それぞれ形式（form）・内容（content）・体験（experience）という分離可能な次元に対応します。次の図は、4 軸とそのサブルールの全体像です。

なぜ Safety を独立の軸にするのか

LLM エージェントの評価で広く使われる枠組みに HHH（Helpful・Honest・Harmless；Askell et al., 2021）があります。このうち Helpful は Goodness（G1 有用性）に、Honest は Correctness（C1 事実正確性）に含まれます。しかし Harmless はどこにも入りません。

流暢で（S◎）、事実にも合致し（C◎）、口調も丁寧な（G◎）応答でも、他人の個人情報を漏らしたり、有害な手順を教えたり、プロンプトインジェクションで乗っ取られたりすることがあります。毒性は語調の問題ではなく、脱獄は関連性の問題でもないので、Goodness や Correctness に押し込むのは不自然です。そこで Safety を独立の制約軸として立てます。サブルールは H1 無害性・H2 公平性・H3 プライバシー・H4 インジェクション耐性・H5 行動安全（不可逆行動への慎重と、良識的な要求を拒否しすぎないこと）です。

Safety を「拒否権軸（veto axis）」と呼ぶのは、他の 3 軸がどれだけ高点でも、不安全な応答はそれだけで許容できないからです。品質の足し算の一項ではなく、掛け算のゼロ項として振る舞います。なお、Safety が「品質に直交する」というときの「直交」は、統計的に無相関という意味ではなく、品質とは種類の異なる次元だという意味です。後述する S・C・G 間の「分離可能だが正に相関する」関係とは区別します。

軸は「別々の問い」（分離可能だが、独立ではない）

これらの軸は、互いに分離して判定できる別々の問いです。1 つの軸が満点でも、他の軸は崩れえます。

• S◎ C✗：完璧に整形された JSON で、自信満々に嘘の返品規約を返す。構造は満点、内容は零点。
• S◎ C◎ G✗：形式も内容も正しいのに、見下した冷たい語調でユーザーを責める。構造と内容は満点、体験は零点。
• S◎ C◎ G◎ H✗：整形され、事実に基づき、口調も丁寧なのに、他人の個人情報を漏らす。品質 3 軸をすべて通過しながら不安全。
• S✗：そもそも無応答だったり、同じ発話を反復してループする。

ただし、分離できる軸も統計的に無相関（直交）なわけではなく、実際には因果的に順序づけられ、正に相関します。下位軸の故障は上位軸に伝播しやすく、ハルシネーション（C✗）は信頼（G）を削り、長い沈黙（S✗）は体験（G）を壊します。そのため本記事では、軸を「分離して測れるが、故障は下から上へ伝播する」ものとして扱います。各軸は別々の網で、前の網を通り抜けた欠陥を次の網で捕まえます。Goodness だけは欠陥がないことではなく程度のある積極的な品質なので、その網は欠陥を捕らえるよりも良さを採点する役割に近くなります。

次のインタラクティブデモでは、同じ会話をさまざまな形で壊し、そのたびにどの軸が劣化し、どの決定論バンド（II 章）で検知できるかを示します。

軸には「順序」がある（分離可能だが対等ではない）

品質 3 軸は分離可能な測定次元ですが、ユーザーへの影響の上では順序があります。

Structure（土台）→ Correctness（価値）→ Goodness（体験）
   会話が成立して      中身が正しくて        初めて
   初めて              初めて               「良い体験」を語れる

無応答（S✗）なら、内容の正しさも体験も意味をなしません。Structure は会話 UX が乗る土台です。中身が嘘（C✗）なら、どれだけ感じが良くても価値はマイナスなので、Correctness は価値の条件です。両者が満たされて初めて、Goodness という体験の質を語れます。

Safety はこの順序の外側にある拒否権軸です。品質の各階層が揃っていても、H に違反した時点で応答全体が許容できなくなります（例：完璧に丁寧で正確な応答が、1 件の PII を漏らす）。

この順序は、VII 章で計測パイプラインの優先順位を決めるときにも使います（安い網から先に張る）。

MECE であること —— 帰属のルール

ルールセットを分類体系として使うには、漏れなく（網羅的）・重複なく（排他的）分類できる必要があります。本フレームワークでは、二重計上を避けるための分類規約として、次の帰属ルールで MECE 性を担保します。

帰属ルール（tie-break）：ある欠陥を、それを定義・検知できる最も安いレイヤーに帰属させる。 0. 安全上許容されない欠陥（有害・不公平・PII漏洩・脱獄・危険な行動）→ Safety（他のどの軸を通過しても拒否権が勝つ）

1. トランスクリプトとログだけで、意味を理解せずに定義できる欠陥 → Structure
2. 意味・事実・タスク目標を理解しないと定義できない欠陥 → Correctness
3. 主観的な体験の質を測らないと定義できない欠陥 → Goodness

このルールによって分類が排他的になります。たとえば「自信満々のハルシネーション」は形式的には完璧で Structure を通過するので、Correctness の失敗に一意に分類されます。「ループ」は意味を見なくても反復として定義できるので Structure、「冷たい語調」は主観判断が必要なので Goodness、「PII 漏洩」は事実としては正確でも許容できないので Safety です。どの欠陥も、4 つのうちちょうど 1 つの軸に入ります。

帰属は、その現場にどんなルールがあるかによって変わります。例えば「丁寧に」という明示的なポリシーがあれば、無礼な応答は機械チェック可能な C5（制約遵守）違反にもなりえますが、なければ G2（トーン）の問題です。そのため MECE は固定の真理としてではなく、チームで合意した分類規約として運用するのが実践的です。

網羅性は、「会話に起こりうる観測可能な欠陥は、(a) 理解ぬきで分かる形式・フローの欠陥、(b) 意味・真偽・目標の欠陥、(c) 体験・情緒の欠陥、(d) 許容できない安全上の欠陥のいずれかである」という四分割（起きたか / 正しいか / 良かったか / 安全か）で保証します。

II. 決定論の地図 —— 測れる/測れないを分ける

評価を体系化するには、評価軸に加えてもう 1 本の座標軸として「どこまで決定論的に測れるか」が必要です。これを 3 つのバンドに分けます。

• ① 決定論的（rule-checkable）：ログとタイムスタンプから固定ルールで計算する。モデル不要で、同じ入力なら常に同じ結果になる。再現性 100%、コストはほぼゼロ。
• ② 参照ベース（reference-based）：正解データや参照応答と比較する。計算は自動だが、正解の用意と指標選択が必要。
• ③ 判断的（judgmental）：人間評価または LLM-as-judge。ビット単位では再現せず、品質は「人間との相関」と「評価者間一致率」で担保する。

3 つのバンドはコストが桁違いに異なり、再現性と使いどころも違います。

②も、固定した参照に対する BLEU/WER/F1 ならビット単位で再現でき、その意味では①と同じく決定論的です。②の弱点は参照の網羅性と妥当性で、正解が不完全なとき、正解が複数ありうるとき、正解が古くなったときに崩れます。

経験則として、品質 3 軸は決定論バンドと対角線上に並びます。Structure は大半を①で測れ、Correctness は①②③にまたがり、Goodness は③が中心です（①の代理指標で補助）。Safety はこの対角線に乗らず、全バンドを横断します（ブロックリストは①、レッドチーム集合は②、分類器・人手は③）。ここから、「Structure を全件ゲートで守り、Correctness を参照テストで回帰監視し、Goodness をサンプル判断で観測する」という階層的な計測戦略が導かれます。

III. 評価方法論の土台（共通言語）

評価設計では、次の 5 つの設計上の選択が繰り返し出てきます。いずれも、どの評価軸とも独立に選べます。

• オフライン vs オンライン：固定データセットでの回帰評価か、本番トラフィックでの観測か。
• ターンレベル vs 対話レベル：1 応答を見るか、会話全体を見るか。ループや一貫性、そして長期対話の劣化（→ IV-8）は対話レベルでしか見えない。
• 参照あり vs 参照なし：正解と比べるか、応答単体の性質を測るか（reference-free）。
• 点数付け vs ペア比較：絶対評価（1〜5）か、A/B のどちらが良いか。ペア比較のほうが評価者間一致が高い傾向。
• 誰が判定するか：ルール / 人間 / LLM-judge。

先行研究との対応

会話評価には 30 年近い蓄積があります。本フレームワークは、これらの成果を評価軸と決定論の地図の上に配置し直したものとも言えます。

• PARADISE（Walker et al., 1997, ACL）：タスク指向対話の古典。ユーザー満足度 ≈ タスク成功（κ係数）− 対話コスト（ターン数・経過時間・修復発話の数など）を線形回帰で重み付けして説明する。Correctness（タスク成功）と Structure（コスト）を 1 つの満足度（Goodness）に結びつけた最初期の試み。
• USR（Mehri & Eskenazi, 2020, arXiv:2005.00456）：参照不要のオープンドメイン対話評価。理解可能性・自然さ・文脈維持・興味深さ・知識活用といった複数の解釈可能な下位指標を教師なしで測る。Topical-Chat でターンレベル相関 0.42、PersonaChat で 0.48。
• FED（Mehri & Eskenazi, 2020, arXiv:2006.12719）：DialoGPT を使い、18 個のきめ細かな対話品質をターン単位・対話単位で参照なしに測る。Goodness の下位構造を細分化した先駆け。
• DBDC（Dialogue Breakdown Detection Challenge）（Higashinaka et al., LREC 2016）：システム発話を NB（崩壊でない）/ PB（崩壊の可能性）/ B（崩壊）の 3 ラベルで多数の評価者が注釈し、発話ごとに 1 つのラベルとラベルの分布を予測するタスク。Structure（対話の崩壊）を独立した検出問題として定式化した。
• LLM-as-judge：MT-Bench（Zheng et al., 2023, arXiv:2306.05685）や G-Eval（Liu et al., 2023, arXiv:2303.16634）。人手に代わって大量の判定を任せられるが、位置バイアス・冗長性バイアス・自己増強バイアス（self-enhancement bias）を持つことが知られ、人間評価との較正が前提になる。

LLM-as-judge の注意点：判定者に LLM を使うと③のコストは大きく下がりますが、判定は確率的で、決定論ではありません。人間との一致率は、尺度に合った統計量（2 名の名義尺度なら Cohen's κ、順序尺度なら Krippendorff's α など；§VII）で必ず測り、位置バイアス対策として A/B を入れ替えて両方向で評価します。判定の根拠（rationale）を出させてから点数を出させる（CoT）と、判定が安定します。

IV. テキストチャットの評価

IV-1. Structure（構造的正しさ）—— ほぼ全件、決定論で守れる

Structure は、意味を理解せずに、ログだけで全件チェックできます。本番の各ターンに常時かけられる「ゲート」になります。

これらは決定論的なコードで書けます。たとえば応答性・形式・ループの 3 つを検査する Structure ゲートは次のようになります。

type Turn = { role: "user" | "agent"; text: string; ts: number };
 
// 直近2つのエージェント発話の3-gram Jaccard 類似度（ループ検知）
function trigramJaccard(a: string, b: string): number {
  const grams = (s: string) =>
    new Set(
      [...s].slice(0, -2).map((_, i) => s.slice(i, i + 3))
    );
  const A = grams(a), B = grams(b);
  const inter = [...A].filter((g) => B.has(g)).length;
  const union = new Set([...A, ...B]).size;
  return union === 0 ? 0 : inter / union;
}
 
function checkStructure(turns: Turn[], budgetMs: number) {
  const failures: string[] = [];
  const agent = turns.filter((t) => t.role === "agent");
  const last = agent.at(-1);
 
  // S2 応答性
  if (!last || last.text.trim() === "") failures.push("S2: empty/no response");
  const prevUser = turns.at(-2);
  if (last && prevUser && last.ts - prevUser.ts > budgetMs)
    failures.push("S2: latency over budget");
 
  // S3 形式適合（例: JSON を要求している場合）
  // try { JSON.parse(last.text) } catch { failures.push("S3: invalid JSON") }
 
  // S4 ループ検知
  if (agent.length >= 2) {
    const sim = trigramJaccard(agent.at(-1)!.text, agent.at(-2)!.text);
    if (sim > 0.9) failures.push(`S4: repeated turn (sim=${sim.toFixed(2)})`);
  }
 
  return { pass: failures.length === 0, failures };
}

このようなチェックは安く、全件に回せます。Structure 違反は品質面で最も深刻な「会話が壊れた」というシグナルなので、Structure ゲートは本番のガードレールとして最優先で実装します。

注意：S4 の「ループ」には、表層の反復だけでなく、言い回しを変えて同じことを繰り返す意味的ループもあります。表層 n-gram で取りこぼす分は、埋め込みのコサイン類似度（参照ベース②寄り）や対話レベルの状態追跡で補完します。ここが Structure と Correctness の境界線です。

IV-2. Correctness（内容的正しさ）—— ①②③にまたがる

Correctness には、決定論で測れる部分と、参照や判断が要る部分が混在します。

RAG を伴うエージェントでは、Correctness はよく「RAG トライアド」（TruLens が広めた枠組み）に分解されます。(1) 文脈の関連性（検索が適切か）、(2) groundedness／忠実性（応答が検索文脈に根拠づくか）、(3) 応答の関連性（応答が質問に答えるか）の 3 つです。(1) は検索の precision/recall（②）、(2)(3) は含意判定や LLM-judge（②③）で測ります。

C4 のタスク達成は、正解（ゴールの状態やアクション）を定義できれば、②参照ベースで決定論に近づきます。たとえば「航空券予約」なら、最終的に正しい便・人数・日付でツールが呼ばれたかを正解と照合できます（多段の軌跡評価は IV-7 で扱います）。C5 の一部（フォーマット制約・長さ・禁止語）は①決定論でゲートできます。

一方、C1 の事実性や C2 の関連性は、開放的なドメインでは正解が一意に定まらないため、③判断が必要です。ここで LLM-judge を使う場合も、「根拠 → 判定」の順で出力させ、人間との一致率を測ります。

C6 は、答えが正しいかではなく、自分の答えをどの程度の確信で述べてよいかをモデルが把握しているかを問います。冒頭に挙げた「自信満々に嘘の規約を語る」例では、内容の誤り（C1✗）に加えて、誤りうることを伝えなかった点も問題です。較正されたモデルは、根拠がなければ「確証はありませんが…」とヘッジするか、「分かりません／確認します」と棄権して、C1 の失敗を正直で回復可能な失敗に変えます。較正は、HHH の Honest が求める「知らないことを断定しない」性質を測るもので、C1 を補完します。指標は ECE・Brier（Guo et al., 2017; Kadavath et al., 2022「Language Models (Mostly) Know What They Know」）、risk–coverage 曲線、棄権正解率など。

IV-3. Goodness（主観的良し悪し）—— ③が中心、①の代理指標で補助

Goodness は本質的に主観で、しかも聞き手によって変わります。専門家には簡潔な回答が「良い」が、初心者には手厚い説明のほうが「良い」ので、同じ応答でも評価が反転しえます。直接測るには③（人間評価）が基本ですが、スケールしません。そこで①の代理指標と③のサンプル評価を組み合わせます。

代理指標は便利ですが、Goodhart の法則に注意が必要です。「再質問率」を下げるために回答を曖昧にしたり、「文長」を縮めるために必要な情報を削ったりと、代理指標を最適化目標にした時点で、その指標は本来の品質を反映しなくなります。代理指標は監視に使い、最適化の本来の目的（CSAT など）とは分けて扱います。

G2〜G4 を LLM-judge で測るなら、ルーブリックを明示した評価プロンプトが有効です。

あなたは会話品質の評価者です。以下のエージェント応答を Goodness の観点で採点してください。
各項目を 1〜5 で、まず根拠を述べてから点数を出すこと。
 
[トーン・共感 G2] 場にふさわしい語調か。ユーザーを責めていないか。共感はあるか。
[明瞭さ G3]     構成は明快か。冗長すぎ/不足はないか。
[自然さ G4]     機械的でなく自然か。
 
会話文脈: {context}
エージェント応答: {response}
 
出力(JSON): {"G2":{"rationale":"...","score":N}, "G3":{...}, "G4":{...}}

IV-4. Safety（テキスト）—— 分類器とレッドチームの層

テキストでも Safety は品質 3 軸とは独立に評価し、しかも全件ゲートで止める運用が前提です（不安全な応答は、たとえ整形され正確でも出してはいけない）。

H5 が示すように、安全性は「危険を断る」と「無害な要求を断らない」の両立です。過剰拒否はそれ自体が UX を壊すため、安全側に振り切るだけでは足りません。レッドチーム集合（既知攻撃）は②で回帰監視でき、未知の攻撃面は人手・自動レッドチーム（③）で継続的に探索します。

IV-5. テキストでの決定論の到達範囲

テキストチャットでは、Structure はほぼ全件①で守れ、Correctness は②に寄せられる部分が多く、Goodness は③に依存します。Safety は、全件ゲート（①の正規表現・ブロックリストと③の分類器）、既知攻撃の回帰（②）、継続的なレッドチーム（③）で守ります。決定論で覆えるのは、Structure のほぼ全体、Safety のうち正規表現・ブロックリストと既知攻撃の回帰、Correctness の半分ほどで、Goodness にはほとんど届きません。どこまで届き、どこから届かないかが分かれば、全件ゲート・回帰セット・サンプル評価のどれにどれだけ手間をかけるかを決められます。

IV-6. 修復・エラーリカバリー —— 軸をまたぐ「回復」次元

ここまでのルールは会話の欠陥を分類するものでしたが、実際の会話 UX は、欠陥が起きた後にどう立て直すか（修復、repair）にも左右されます。会話分析では修復は古典的な構造現象であり（Schegloff, Jefferson & Sacks, 1977）、対話評価でも FED の 18 品質に「error recovery」が含まれます。本記事のデモの最終シーン（90日→30日の訂正）も修復の例です。修復は単一の軸に収まらず、品質 3 軸にまたがります。

• 検知（Structure 寄り）：ユーザーの訂正・言い直し（「いや、そうじゃなくて」）を検出し、修復シーケンスに入るか。表層パターンは①で部分的に取れる。
• 訂正の正しさ（Correctness）：訂正後の内容が実際に正しいか（C1/C4）。
• 修復の所作（Goodness）：誤りを認め、適切に謝り、過剰に謝らず前進するか（G2）。

修復は、軸は分離できるが失敗は下から上へ伝播する、という本記事の見方をよく示す例です。欠陥分類（MECE）を壊さずに、回復の次元を別建てで足せます。計測は修復成功率（訂正要求後にエラーが解消したターンの割合）や time-to-repair（修復までのターン数）で近似します。

IV-7. エージェントのツール利用と多段タスクの評価 —— C4 を「軌跡」へ広げる

本記事は「エージェント」を冠していますが、C4 の「正しい関数呼び出し」だけでは、ツールを使い多段のタスクをこなすエージェントの評価には足りません。エージェント評価は最終結果だけでなく、そこに至る軌跡（trajectory）にも及びます。これも欠陥分類を壊さず、Correctness と Safety を縦断する形で足せます。

評価では、最終状態（end-state）と軌跡（trajectory）を分けて採点します。τ-bench（Yao et al., 2024, arXiv:2406.12045）は、ドメイン API とポリシーを与えたエージェントと、LLM でシミュレートしたユーザーとの対話を、会話終了時のデータベース状態を正解状態と照合して採点し、さらに複数試行での一貫性を pass^k で測ります（gpt-4o のような最先端の関数呼び出しエージェントでもタスク成功率は 50% 未満、retail の pass^8 は 25% 未満）。軌跡そのものは、正解ツール列との完全一致・順序一致・順不同一致や、ツール呼び出しの precision/recall で近似します。

不可逆行動（送金・削除・予約確定）の安全性は、C4 の「達成」ではなく H5 の「行動安全」で捕まえます。「正しい行動」と「取り返しのつく行動」は別問題だからです。確認を挟むべき行動の前に確認したか、過剰拒否（over-refusal）に陥っていないかを、全件ゲートと回帰集合で監視します。

IV-8. マルチターン／長期対話の劣化 —— 「ターンが増えると壊れる」を測る

§III で「ターンレベル vs 対話レベル」を区別しました。会話が長引くにつれて現れる劣化は 1 ターンを見るだけでは捉えられないため、対話レベルの現象として独立に測る必要があります。

• ゴールのドリフト（Correctness 寄り）：ターンを重ねるうちに当初の目的からずれる。サブゴール達成を追跡し、最終目標との整合を対話単位で評価する。
• 文脈・記憶の喪失（Correctness／Structure）：序盤で確定した制約（名前・日付・好み）を後半で忘れる・取り違える。「既出情報の保持率」を対話単位で測る。
• 「Lost in the Middle」（Correctness）：長い文脈の中央に置かれた情報の利用率が、先頭・末尾に比べ顕著に下がる U 字現象（Nelson F. Liu et al., 2023「Lost in the Middle」, arXiv:2307.03172）。関連情報を文脈内のさまざまな位置に置いて正解率を測る評価が有効。
• マルチターン指示の減衰（Correctness）：「以降は敬語で」のような初期指示が、ターンが進むと無視され始める。指示注入からの経過ターン数に対する遵守率で測る。
• 対話レベルの一貫性・整合（Goodness／Correctness）：ペルソナ・口調・主張がターンをまたいで一貫するか。ターン間の自己矛盾を検出する。

長期劣化はターンレベル指標の平均には現れません。そのため評価セットには長い会話を含め、対話単位（dialogue-level）で採点する必要があります。多くのベンチマークが短いやり取りに偏る点には注意が要ります（たとえば MT-Bench（Zheng et al., 2023）は 2 ターン構成で、長期の劣化は射程外）。本番では会話長とエラー率の相関を監視し、必要なら要約・メモリー機構の有効性を回帰でテストします。

V. 音声対話の評価

音声は、テキストに時間と音響という次元を足したものです。そのため評価は「トランスクリプト上のテキスト評価（前章すべて）＋ 音声ネイティブな下位層」という二階建てになります。さらに V-5 で見るように、軸の重みも変わります。

V-1. なぜ音声では「タイミング」が支配的になるか —— 人間の会話の認知科学

人間の会話では、話者の交替が数百ミリ秒の精度で起きます。会話分析の古典（Sacks, Schegloff & Jefferson, 1974）以来の知見と、その後の計測（Levinson & Torreira, 2015, Frontiers in Psychology 6:731）から、次のことが分かっています。

• 話者交替のギャップ（floor transfer offset、FTO）は平均で約 200ms、最頻値は 0〜200ms の範囲にある。
• ところが言語産出のレイテンシーは単語 1 つで約 600ms かかる（Indefrey & Levelt, 2004 の picture-naming メタ分析）。2〜3 語で 740〜900ms（Schnur et al., 2006）、文レベルの発話では約 1500ms に達する（Griffin & Bock, 2000；いずれも Levinson & Torreira, 2015 が総説）。
• この矛盾の解決策は「予測（projection）」——聞き手は相手の発話の終わりを予測し、相手が話し終わる前に自分の応答を組み立て始めている。
• 10 言語の横断研究（Stivers et al., 2009, PNAS；極性［yes/no］質問への応答を計測、視覚的応答も含む）でも、平均応答オフセットは日本語の約 7ms からデンマーク語の約 469ms までと幅はあれど、ギャップと重なりを最小化する傾向は普遍的だった。
• 700ms を超えるギャップは「何か問題がある」というシグナルとして解釈される（不同意・困惑・拒否の前触れ）。300ms を超えると、留保のない受諾の確率が下がり始める（いずれも人間どうしの対話で測られた閾値であり、エージェントへの適用は作業仮説）。

つまり人間は「予測で先回り」して ~200ms を実現しているのに対し、素朴な音声エージェントのパイプラインは「無音を待ってから」直列処理するため、構造的にこの規範を破ります。

無音待ち（エンドポインティング）→ ASR 確定 → LLM の最初のトークン → TTS の最初の音声、と直列に積むと、1.5〜2 秒を超えることは珍しくありません。これは人間規範（~200ms）の 7.5〜10 倍、「問題シグナル」の閾値（~700ms）の 2〜3 倍です。応答が正しくても（C◎）、この沈黙だけで体験は崩れます（G✗）。音声で Structure-タイミングが支配的になるのは、このためです。

注記（2024 年以降の SOTA）：この 1.5〜2 秒は素朴な直列パイプラインのベースラインで、最新の構成はこれより大幅に速くなっています。ネイティブな音声対音声（speech-to-speech）やフルデュプレックス構成は応答を ~300〜500ms まで縮め、人間規範（~200ms）との差をほぼ埋めつつあります。「沈黙の壁」は、アーキテクチャ（逐次 ASR・意味的エンドポインティング・音声トークンの直接生成）で動かせる設計変数です。とはいえ p95 レイテンシーと割り込み時の振る舞いは、依然として第一級の評価対象であり続けます。

V-2. Structure（音声）—— タイミングは決定論で測れる

タイミングと音声フローに関する項目は、ほぼすべて音声タイムスタンプから決定論的に測れます。音声 Structure はテキストの S1〜S5 に加え、次の音声ネイティブなルールを持ちます。

これらは音声 UX への影響が最も大きく、しかも最も決定論的に測れる項目なので、少ない手間で大きな改善が見込めます。レイテンシー分布（特に p95）を SLO として監視し、エンドポインティングの早すぎ/遅すぎをトレードオフとして調整するのが一般的です。

エンドポインティングのジレンマ：閾値を短くすると「ユーザーがまだ話している途中で割り込む」（早すぎ）、長くすると「沈黙が伸びて問題シグナルになる」（遅すぎ）。人間が予測でこれを解いているように、最新の音声システムは意味的エンドポインティング（発話の意味的完了を予測）やフルデュプレックス（聞きながら話す）で、この決定論的トレードオフを動かそうとしています。

V-3. Correctness（音声）—— ASR と TTS が誤差を注入する

音声の Correctness は、テキストの C1〜C6 に加えて、音声 ↔ テキスト変換の正確性が前段と後段に入ります。

• 前段：ASR の正確性。エージェントが正しく聞き取れたか。標準指標は WER（Word Error Rate）= (置換 + 削除 + 挿入) / 参照語数。これは参照書き起こしがあれば②参照ベースで決定論的に測れます。ASR の誤りは下流の LLM にそのまま伝播する（複合誤差）ので、エンドツーエンド評価では ASR を切り分けて測ることが重要。なお WER は話者のアクセント・方言・背景雑音・コードスイッチングで大きく変動するため、集団間の WER 差は H2（公平性）の観点でも監視する。
• 後段：TTS の発話正確性。正しい内容を正しく発音したか。とくに数字・固有名詞・日付・単位の読み上げは誤りやすい（"1/2" を「2 分の 1」か「1 月 2 日」か）。これは「内容は正しいが音声化で壊れる」典型で、テキスト評価では捕まりません。

ASR の WER がよくても、句読点・話者分離・固有名詞で崩れると LLM の入力が歪みます。そのため音声 Correctness は、「ASR 層」「LLM 層」「TTS 層」を分離して測ります。

V-4. Goodness（音声）—— 「自然さ」と、タイミングという代理指標

音声の Goodness には、テキストにない音響的な体験価値が加わります。

音声では、Structure の決定論指標（レイテンシー）が、Goodness（テンポの快適さ）のよい代理指標になります。人間規範 ~200ms に近いほど、テンポがよく感じも良いと受け取られると考えられます。声の自然さそのものは、MOS（被験者が 1〜5 で主観評価する ITU-T 標準。クラウドソーシング版は P.808）という③判断指標で測るのが標準的です。

V-5. 音声では軸の重みが変わる

テキストでは、遅い応答は「やや苛立たしい」程度（軽い G の劣化）です。音声では、700ms を超える沈黙は「何か問題がある」と積極的に解釈されるため、Structure-タイミングの失敗がそのまま Goodness の失敗になります。

テキスト:  Correctness と Goodness（内容と語調）が体験を支配
音声:      Structure-タイミング が体験を支配し、
           内容が正しくても沈黙ひとつで台無しになりうる

音声エージェントの評価では、レイテンシー分布（p95）を第一級の指標とし、Correctness（WER + 内容）と同等以上に重く扱う必要があります。同じ品質 3 軸でも、チャネルによって重みづけが変わります。

VI. ルールセットを 1 枚にまとめる

ここまでの 4 軸 × 決定論バンドを、テキストと音声をまたいで 1 枚の表にまとめます。この表がそのまま、評価パイプラインに組み込めるルールセットになります。

左の列ほど安く・全件・自動で測れ、右の列ほど高く・サンプル・主観になります。軸ごとに主に使うバンドを決め、左の列から順に評価を組み込みます。

VII. 計測の実務 —— 3 層パイプライン

軸と決定論の地図を計測アーキテクチャに置き換えると、決定論バンドに対応した 3 層になります。安い検査は全件に、高い評価はサンプルにかけます。Safety はこの 3 層すべてにまたがります（ゲートでブロックし、回帰で監視し、サンプルでレッドチームする）。

• ① ゲート層：Structure と Safety を全件・本番でチェック。違反は即座にアラート・応答ブロック・フォールバック。Structure は純粋な決定論、Safety ゲートは正規表現（決定論）＋分類器（自動・確率的）のハイブリッド。
• ② 回帰層：Correctness と Safety をラベル付きの回帰集合で参照評価。モデル更新やプロンプト変更のたびに走らせ、退行（タスク成功の低下・新しい脱獄の成功）を検出。
• ③ 判断層：Goodness と Safety をサンプリングして人間 / LLM-judge で評価。全件は無理なので、層別サンプリング（失敗ケース・新規ドメインを厚めに）する。

オフラインとオンライン

• オフライン：固定データセットでの回帰スイート（②中心）。決定論ゲート（①）と LLM-judge（③）も流す。リリース前の品質保証。
• オンライン：本番トラフィックで、①をガードレールとして常時、③の代理指標（離脱率・エスカレーション・音声ならレイテンシー p95）と、利用者の明示的な評価（👍/👎）を監視。異常検知とビジネス指標の接続。

計測を壊さないための原則

1. 安い検査から始める：Structure ①を最優先にする。無応答やループを見逃したまま Goodness を議論しても意味がない。
2. Safety は妥協しない：Safety は拒否権軸。他の軸のスコアと平均せず、独立のゲートとして手前に置く。H 違反は他が満点でもリリース不可。
3. 層を分離して測る：音声なら ASR / LLM / TTS を切り分ける。複合誤差を 1 つの数字に潰さない。
4. LLM-judge は較正してから使う：人間との一致率（尺度に合った統計量で；下記「統計的厳密性」）を測り、位置バイアス対策（A/B 入替）を入れる。
5. 代理指標を最適化目標にしない：Goodhart の法則を避けるため、代理指標は監視に使い、本来の目的（CSAT 等）は別に管理する。
6. ペア比較を活用する：絶対評価より A/B 比較のほうが評価者間一致が高い傾向がある。モデル選定はペアで。

統計的厳密性 —— サンプルサイズ・信頼区間・一致統計量

判断層（③）の数字は確率変数です。「A のほうが良い」と言うには、統計的な裏づけが要ります。

• サンプルサイズと検定力：検出したい効果量に対し、必要な評価件数を事前に見積もる（検定力分析）。少数サンプルでの「勝った/負けた」は偶然と区別できない。
• 信頼区間と有意差検定（A/B）：スコア差は点推定だけでなく信頼区間で報告する。2 モデルの勝率比較は、ブートストラップ信頼区間や二項検定／McNemar 検定（対応ありのペア比較）で有意性を確かめる。多数の指標を同時に比べるなら多重比較補正（Bonferroni 等）を入れる。
• 状況に応じた一致統計量：評価者間一致は、データの性質で使い分ける。
  • 2 名・名義尺度 → Cohen's κ（κ が想定するのは厳密に「2 評価者・名義」）。
  • 3 名以上・名義尺度 → Fleiss' κ（固定人数の評価者へ一般化。厳密には Cohen's κ ではなく Scott's π の一般化）。
  • 順序尺度（1〜5 など） → Krippendorff's α（任意人数・順序/間隔も扱える）、重み付き κ（2 名・距離で不一致を加重）、または Spearman の ρ（順位相関）。1〜5 を名義として κ にかけると、「4 と 5 の食い違い」と「1 と 5 の食い違い」を同罪にしてしまう。

LLM-judge の検証も、この区別に従います。1〜5 のルーブリック採点なら人間との一致は Krippendorff's α か Spearman で、A/B のペア判定なら一致率（と κ）で報告します。§III と本章で繰り返した「人間との一致を測る」とは、尺度に合った統計量で測るという意味です。

おわりに

会話 UX は「なんとなく良い/悪い」で語られがちですが、3 つの品質軸と 1 つの制約軸に分解できます。会話として成立しているか（Structure、ほぼ決定論で全件守れる）、言っていることは正しいか（Correctness、参照ベースに寄せられる部分が多い）、その体験は良かったか（Goodness、代理指標とサンプル評価で測る）、そしてその応答は無害か（Safety、品質とは独立の拒否権軸で、分類器とレッドチームで守る）です。

4 軸は、最も安いレイヤーに帰属させるという分類規約によって排他的に、「起きたか / 正しいか / 良かったか / 安全か」の四分割で網羅的に切り分けられます。ただし品質 3 軸は統計的に独立（直交）ではなく、分離して測れても、失敗は下から上へ伝播します。これを決定論の地図に重ねると、何を全件ゲートし、何を回帰テストし、何をサンプルで判断するかが決まります。

チャネルによって軸の重みも変わります。テキストでは内容と語調が体験を左右しますが、音声ではタイミングが左右します。人間が予測によって ~200ms のギャップで話者を交替している以上、音声エージェントにとっての基準は厳しく、正しい答えでも沈黙が長ければ体験は損なわれます。良い会話 UX とは、品質 3 軸がそのチャネルに合った重みで揃い、かつ Safety の一線を越えない状態のことです。