マルチターンLLM評価：5つの指標、3つのフレームワーク、1つのワークフロー

マルチターンLLM評価：5つの指標、3つのフレームワーク、1つのワークフロー

マルチターンLLM評価は、8ターン目の記憶喪失バグを検知できる唯一の方法です。ユーザーが3ターン目に注文番号を伝えたのに、ボットがもう一度それを聞いてくる。個々のターンはすべて単体で合格しているのに、会話は失敗している。DeepEval 4.0とRAGAS 0.4はまさにこの問題のために専用のは会話評価APIを搭載しました。Techsyの自社パイプラインで2回の評価インシデントを経験した私たちが、5つの指標、3つのフレームワーク、1つのワークフローとしてお伝えします。

主なポイント

• マルチターン評価は、孤立した入出力ペアではなく、会話全体をスコアリングします。
• シングルターンベンチマークでトップのモデルでも、会話ターンが進むと測定可能なほど性能が低下します。
• まず4つの指標から始めます：完全性、知識保持、役割遵守、ターン関連性。
• DeepEval、RAGAS、Langfuseはマルチターン評価に異なるアプローチで解決します。下のフレームワーク比較表を参照してください。

シングルターンスコアはなぜ嘘をつくのか？

シングルターン評価は一度に1つの入出力ペアをスコアリングするため、ターンをまたいで初めて現れる失敗（忘却、矛盾、ドリフト）を検知できません。モデルがベンチマークで高いスコアを出しても、実際の会話では文脈を見失うことがあります。Labanらの論文LLMs Get Lost In Multi-Turn Conversation（被引用数353）はこれを裏付けています。シングルターンの結果が健全に見えても、マルチターン環境では性能が劣化するのです。

根本的な問題は非決定性です。n番目の応答はそれ以前のn-1ターンすべてに依存するため、同一プロンプトでも履歴によって挙動が変わります。孤立したペアのデータセットでは、この依存性を決して検証できません。arXivのサーベイ論文Evaluating LLM-based Agents for Multi-Turn Conversations（約250件のソースを対象としたPRISMAレビュー）は、この分野を「何を評価するか」（コンテキスト管理、計画、一貫性）と「どう評価するか」（指標、LLMジャッジ、人間レビュー）に分類しています。シングルターンのテストスイートには、この両軸が欠けています。

だからといって、シングルターンのスタックが無意味になるわけではありません。BLEU、ROUGE、G-Evalなどのシングルターン指標を運用しているなら、それらが得意とするもの（フォーマット準拠、有害性、固定プロンプトでの事実再現）には引き続き有効です。ただし、ユーザーが実際に触れる会話のヘルスチェックとして読むのはやめてください。

これらの研究を一行で要約すると：

シングルターン評価は「回答」を測り、マルチターン評価は「会話」を測る。1ターン目で満点のモデルが、5ターン目には迷子になっていることがある。

マルチターンLLM評価とは？2つの評価モード

マルチターンLLM評価とは、孤立したプロンプト応答ペアではなく、会話全体またはその中のウィンドウをスコアリングする手法です。モデルがコンテキストを維持したか、役割を守ったか、ターンを通じてユーザーの問題を解決したかを問います。評価モードは2つ：会話レベルのスコアリングとスライディングウィンドウのターンレベルスコアリングで、ほとんどのチームは両方を運用しています。

会話レベルのスコアリングは、ジャッジに全文トランスクリプトを渡し、1つの質問をします：この会話は成功したか？早期終了や未解決ループを検知できます。スレッド全体でなければ、ユーザーが返金を受けられなかったことは分からないからです。弱点は粒度です。12ターンのスレッドで「失敗」と出ても、どこで壊れたかは分かりません。

スライディングウィンドウのターンレベルスコアリングは、Nターンのウィンドウをトランスクリプト上でスライドさせ、ウィンドウごとに1つの判定を出します。10ターンの会話にウィンドウ3を適用すると8つの判定が得られ、チャットの領域に紐づきます。「失敗」に座標が付くのです：6〜8ターン目で壊れた、と。この記事の冒頭の図は、1つのスレッドで両モードを示しています。会話判定のブラケットと、ウィンドウ別判定のスライディングフレームです。

会話レベルのスコアリングをゲートとして使い、トリップしたときにウィンドウスコアリングで失敗箇所を特定してください。DeepEvalのマルチターン評価ガイドは、作業単位を入出力ペアではなくシナリオ（ConversationalGolden型）として定義しています。テストしているのは質問ではなく状況です。

説明用の例（合成データ。実際の結果ではなく仕組みを示すもの）：8ターンの返品リクエストチャットにスライディングウィンドウ3を適用。

Turn 1  user:      I want to return an order that arrived damaged.
Turn 2  assistant: Sorry about that. Can you share the order number?
Turn 3  user:      It's #4471.
Turn 4  assistant: Got it. Damaged on arrival, or after use?
Turn 5  user:      On arrival. The screen was cracked.
Turn 6  assistant: Understood. Replacement or refund?
Turn 7  user:      Refund. How long does that take?
Turn 8  assistant: 3-5 business days. Can you share the order number again?

会話レベルの判定：不合格。6つのウィンドウのうち5つが合格したのに、スレッドは知識保持で壊れました。まさにシングルターンのテストスイートが決して表面化させない失敗です。

どのマルチターン指標が重要か？本当に必要な5つ

まず4つの指標を運用します：会話の完全性、知識保持、役割遵守、ターン関連性。5つ目としてカスタム基準（DeepEvalのG-Eval、RAGASのAspectCritic）を追加し、プロダクトとして絶対に間違えられないことをカバーします。最初の4つはプロジェクト間で移植できます。5つ目にこそ、あなたの失敗モードが宿ります。

1. 会話の完全性。 ユーザーのゴールは解決されたか、ボットが早期に勝利宣言していないか。早期終了の検知器です。
2. 知識保持。 モデルはスレッド内で先に述べられた事実を覚えているか。8ターン目の記憶喪失バグは知識保持の失敗です。
3. 役割遵守。 アシスタントはペルソナの内側にとどまり、スコープ外のリクエストを拒否しているか。コンプライアンス境界がある場合に不可欠です。
4. ターン関連性。 各応答は直前のターンを踏まえてトピックに沿っているか。ドリフトとループを検知します。
5. カスタム基準。 ドメイン固有のルールを1つの平文で：「価格表と異なる金額を引用しない」。DeepEvalではConversationalGEval、RAGASではAspectCriticとして実装します。

DeepEvalの指標ガイドは実行可能なクラス付きで各指標を定義していますが、概念はフレームワーク非依存です。ジャッジを自作する場合でも、この表は有効です。

カスタム基準は1つの文のように書けます：

criterion "price_accuracy":
  question: Does the assistant quote prices matching the official
            list, and self-correct when the user flags a mismatch?
  scale: 0 (wrong, no correction) to 1 (correct throughout)
  verdict: pass if score >= 0.5

同じルールをDeepEvalの実際のコードで書くと：

from deepeval.metrics import ConversationalGEval
from deepeval.test_case import LLMTestCaseParams

price_accuracy = ConversationalGEval(
    name="Price Accuracy",
    criteria=(
        "Does the assistant quote prices that match the official "
        "price list, and correct itself immediately when the user "
        "points out a discrepancy?"
    ),
    evaluation_params=[
        LLMTestCaseParams.INPUT,
        LLMTestCaseParams.ACTUAL_OUTPUT,
    ],
    threshold=0.5,
)

DeepEval vs RAGAS vs Langfuse：どのフレームワークが合うか？

3つともマルチターン会話を評価できますが、評価の単位が異なります。DeepEvalはシナリオをオフラインでシミュレートし、RAGASは既存の会話をアスペクトごとにスコアリングし、Langfuseは実際の本番トレースを評価します。機能数ではなく、会話データがどこから来るかで選んでください。

まずフレームワーク非依存のロジックを示すので、以下のベンダーコードは移植可能です：

for scenario in scenario_set:
    transcript = run_chatbot(scenario, max_turns=10)
    for window in sliding_windows(transcript, 3):
        scores.append(judge(window, criteria))
    scores.append(judge(transcript, completeness))
fail_if(mean(scores) < baseline - tolerance)

DeepEval：シナリオとフル装備のシミュレーター

DeepEvalは、一級の会話シミュレーターを持つ唯一のフレームワークです。シナリオとペルソナを記述すると、ボットに対してユーザー役を演じます。そのマルチターンガイドは、ペアではなくシナリオというパターンの標準的なリファレンスです。Confident AIはホスト型ダッシュボードを販売しています。有料レイヤーが何を追加するかは、私たちのConfident AIレビューでカバーしています。

from deepeval.dataset import ConversationalGolden
from deepeval.synthesizer import ConversationSimulator
from deepeval.metrics import (
    ConversationCompletenessMetric,
    KnowledgeRetentionMetric,
)
from deepeval import evaluate

scenario = ConversationalGolden(
    additional_context="Customer wants to return a damaged order",
    user_persona="Impatient customer, second contact this week",
)
simulator = ConversationSimulator(model="gpt-4o-mini", max_turns=10)
test_case = simulator.simulate(scenario, your_chatbot_fn)

evaluate(
    test_cases=[test_case],
    metrics=[
        ConversationCompletenessMetric(threshold=0.7),
        KnowledgeRetentionMetric(threshold=0.7),
    ],
)

RAGAS：エラー分析駆動、アスペクト別スコアリング

RAGASは既存の会話から出発し、アスペクトごとにスコアリングします。そのマルチターンHow-toは手動エラー分析と組み合わせて使います。失敗したチャットを読み、失敗モードごとにAspectCriticを書き、スコアリングする。この流れです。

from ragas.dataset_schema import MultiTurnSample
from ragas.metrics import AspectCritic
from ragas.llms import llm_factory

user_input = [
    {"role": "user", "content": "Can I return a damaged order?"},
    {"role": "assistant", "content": "Yes, within 30 days."},
    {"role": "user", "content": "It arrived broken. Do I pay shipping?"},
    {"role": "assistant", "content": "No, we cover it."},
]
sample = MultiTurnSample(user_input=user_input)

critic = AspectCritic(
    name="policy_consistency",
    definition="Does the assistant stay consistent with the stated return policy across all turns? Answer yes or no.",
    llm=llm_factory("gpt-4o-mini"),
)
score = await critic.multi_turn_ascore(sample)  # binary 0 or 1

Langfuse：実際トレースに対するN+1評価

Langfuseは逆のアプローチを取ります。トレーサーファーストです。そのN+1 cookbookは、各ターンのトレースと会話全体を、シミュレーションではなく本番トラフィックで評価します。オブザーバビリティレイヤーをまだ選定中なら、私たちのLangfuse vs LangSmith比較記事がその判断に役立ちます。

私たちの結論は、あいまいさを排して明確にします。新しいチャットボットプロジェクトなら、DeepEvalから始めてください。シミュレーターがあれば、本番トラフィックが存在する前、つまりテストが最も必要な時期にリグレッションをゲートできます。実際のスレッドが存在するようになったらLangfuseを追加し、チームが失敗した会話を読んで発見をコード化するスタイルを好むならRAGASに手を伸ばしてください。

エラー分析から自動化へどう移行するか？

順序立てて進めます。実際の会話を20〜30件読み、失敗モードを手動でラベリングし、明白なものには二値の合格/不合格チェックを書いて自動化し、その後に初めて主観的な残余にLLMジャッジ指標を追加します。Hamel Husainもまさにこの順序を主張しています。まず手動エラー分析と二値判定。説明できるチェックは、説明できないスコアに勝るからです。

ジャッジの前に二値：私たちを救った順序づけ

これはチャットボットのベンチマークではありません。私たち自身のコンテンツパイプライン内の同じパターンの解釈です。このパイプラインでは、プロンプトやツールのすべての変更に対して評価ゲート付きリグレッションチェックを実行しています。2つのインシデントが、この順序づけを私たちに証明しました。

2026-06-13、再公開バグが新しいローカライズ済みslugを発行し、54件の重複ライブドキュメントを出荷してしまいました。2026-07-05に発見して非公開化しました（バックアップはtechsy.io/seo-reports/2026-07-05/deleted_docs_backup.json）。修正はより賢いモデルではなく、決定論的な公開前チェックでした。作成前にcanonical postと言語で既存ドキュメントを解決する。二値ゲートです。

2つ目のインシデント：翻訳LLMがUnicodeではなくASCIIを出力し、「karşılaştırma」が「karsilastirma」になることがありました。ジャッジは不要です。grepゲートで検知できます：

grep -cP '[çşğüöıİŞÇĞÜÖ]' file.md   # must be > 0

両方とも、1セント未満のコストで失敗理由を正確に表示するチェックで捕捉されました。これをマルチターン評価に当てはめると、「ボットがユーザー既に伝えたフィールドを再質問したか？」はトランスクリプトに対する文字列マッチであり、ジャッジ呼び出しではありません。安価な決定論的ゲートを先に実行してください。高価なジャッジが動く前に、厄介な失敗を捕捉できます。

LLMジャッジが本当に正しいツールであるとき

ジャッジがトークンコストに見合うのは、ルールに還元できない基準に対してです。「トーンは適切に謝罪的だったか？」「解決策は状況に合っていたか？」アサーションを書けるなら、アサーションを書いてください。判断の連続で埋まったルーブリックは、ジャッジの領分です。

私たちが何度も立ち返る一線：

チームメイトに説明できる二値の合格/不合格チェックから始め、ルールに還元できないものにだけLLMジャッジを追加する。

会話を大規模にシミュレートする方法と、ジャッジコスト

エクスポートしたログではなく、シナリオからシミュレートしてください。シナリオは「起こりうること」をテストします。ログは「現在のシステムが既に許容したこと」しか示しません。DeepEvalのガイダンスは、過去の会話はそれを生成したシステムによって形作られているため、それに対するベンチマークは現状を固定化すると警告しています。

トランスクリプトではなくシナリオ

各シナリオはゴールとペルソナで記述します。「破損した注文を返品するせっかちな顧客」「予約途中で気が変わるユーザー」。最大ターン数制限（10が妥当）と停止条件を設定します：ゴール到達、ユーザー離脱、または上限。DeepEvalは主要ユースケース、エッジケース、失敗しやすい状況を含む最低20件の多様なシナリオを推奨しています。それを下回ると、テストスイートは逸話を測っているに過ぎません。

敵対的ペルソナ

ボットを壊そうとするペルソナを含めてください。エスカレートする怒ったユーザー、自己矛盾する混乱したユーザー、4ターン目に命令を滑り込ませるインジェクションユーザー。マルチターンインジェクションはそれ自体が1つの分野です。私たちのLLMガードレールガイドは、これらのテストと対になる防御レイヤーをカバーしています。Langfuseのシミュレーションcookbookはユーザーシミュレーターループを示しています。

100件の評価済み会話にかかるコスト

以下の数値はすべて、記載のトークン数と公開価格からの推定値であり、私たちが実測したものではありません。重要なのは計算方法です。自分の数字に置き換えてください。

100件のフルジャッジ会話で1ドル未満です。より高価なジャッジなら10〜50倍になり、私たちのLLM APIコスト削減ガイドの戦術が適用できます。基準テキストをキャッシュする、ウィンドウをバッチ処理する、二値ゲートには安価なモデルを使う。

6ステップのマルチターン評価ワークフロー

ループはこう回ります。実際の失敗からシナリオを定義し、4つのコア指標と1つのカスタムを選び、最低20シナリオをシミュレートし、現行バージョンのベースラインを記録し、CIでリグレッションをゲートし、本番の失敗をシナリオセットにフィードバックする。

1. 失敗からシナリオを定義する。 20〜30件のトランスクリプトを読む（ローンチ前ならサポートチケットから作成）。各シナリオにゴール、ペルソナ、最大ターン数の上限を設定。担当者：あなた自身とHamelのエラー分析優先メソッド。
2. 4つの指標と1つのカスタムを選ぶ。 完全性、知識保持、役割遵守、ターン関連性、そしてドメイン固有の高コストなミスに対するConversationalGEvalまたはAspectCriticを1つ。
3. シミュレートする。 敵対的セットを含む最低20シナリオを実行。担当者：DeepEvalのConversationSimulator、またはLangfuseのシミュレーションcookbook。
4. 現行バージョンのベースラインを記録する。 モデルは非決定的で単一実行はノイズなので、3回の実行で指標ごとの平均を記録。担当者：あなたの評価スクリプト。結果はリポジトリにコミット。
5. CIでリグレッションをゲートする。 指標ごとに閾値を設定し、許容範囲を超えるリグレッションでビルドを失敗させる：

# ci/multi-turn-eval-gate.sh
set -euo pipefail
python eval/run_multi_turn.py --scenarios eval/scenarios.yaml --out results.json
SCORE=$(jq -r '.aggregate.completeness' results.json)
BASELINE=0.82
TOLERANCE=0.03
if (( $(echo "$SCORE < $BASELINE - $TOLERANCE" | bc -l) )); then
  echo "FAIL: completeness $SCORE below baseline $BASELINE"
  exit 1
fi

1. 本番スレッドを監視する。 ライブトレースをスレッドでグループ化し、非同期で評価し、失敗したすべてのスレッドを新しいシナリオに変換する。担当者：Langfuseまたはあなたのトレーサー。本番環境でのAIエージェント評価とAIオブザーバビリティのガイドが監視の半分をカバーします。

スイートが完成することはありません。ステップ6がステップ1にフィードバックし、捕捉した本番の失敗ごとにシナリオセットは成長します。

言語をまたいでトーンをどう評価するか？

英語データでチューニングした役割遵守指標は、ネイティブスピーカーが無礼と感じるトルコ語や日本語のトランスクリプトに合格してしまいます。丁寧さのレジスターは言語固有だからです。英語のルーブリックには、それを表現する言葉がありません。修正方法：レジスターの期待ごとに1つのアスペクト基準を、言語ごとに書く。グローバルなトーン指標を1つだけ持つのは間違いです。

レジスターごとに1つの基準

RAGASのAspectCriticパターンに対する私たちの解釈です。23言語パイプラインの運用から拡張したものであり、公開されたテスト結果ではありません：

English:  "Is the assistant's tone friendly but professional?"
Turkish:  "Does the assistant use formal 'siz' address consistently,
           and avoid casual verb forms with an upset customer?"
Japanese: "Does the assistant keep keigo (polite form) throughout,
           including the apology at the resolution turn?"

各基準は、同じトランスクリプトに対する個別の二値クリティックです。私たちは言語横断のトーンスコアを公開していませんし、ルーブリックなしにそれを出力する記事は信頼しません。パイプライン運用からの知見：失敗は謝罪ターンとエスカレーションターンに集中します。レジスターが最初に崩壊する場所です。

著者について

Mert BaturはTechsy.ioのCo-Founderであり、チームはB2Bクライアント向けにAIエージェント、自動化システム、音声/SDRパイプラインを出荷しています。Techsyチームが実際に本番環境で使用しているLLMツールスタックについて執筆しています。経歴：Techsy.io Co-Founder。LinkedInでつながってください。

よくある質問

マルチターン会話LLMとは何ですか？

n番目の応答が最新のプロンプトだけでなく、それ以前のすべてのターンに依存する言語モデルです。スレッド全体を条件とするため、会話履歴によって挙動が変わります。このコンテキスト依存性こそ、シングルターンテストでは検証できず、マルチターン評価がスコアリングするために存在するものです。

LLM評価とはどういう意味ですか？

定義された基準に対して出力品質を、感覚ではなく自動的かつ再現可能に測定することです。シングルターン評価は、BLEUやLLMジャッジなどの指標に対して孤立したプロンプト応答ペアをスコアリングします。マルチターン評価はそれを会話全体に拡張し、プロンプトごとではなくターンをまたいだコンテキスト保持とゴール達成をスコアリングします。

マルチターンLLM性能をどうベンチマークしますか？

ゴールとペルソナを持つシナリオを最低20件構築し、モデルに対してシミュレートし、会話レベル指標とスライディングウィンドウチェックでスコアリングします。非決定性を吸収するために複数回のベースラインを記録し、CIで各新バージョンをベースラインと比較します。本番トレースは後でベンチマークを拡張します。

LLMを評価する最良の方法は何ですか？

順序立てます。まず手動エラー分析、次にルールに還元できるものすべてに対する二値の合格/不合格ゲート、そしてトーンや解決品質のような主観的基準にはLLM-as-a-judge。二値チェックは安価で、デバッグ可能で、ドリフトしません。ジャッジは、安価なゲートを通過した後に、本当に判断を要する基準に限定してください。

どのマルチターン評価指標から始めるべきですか？

会話の完全性、ターン関連性、知識保持。これらはあらゆるチャットプロダクトで最も一般的な失敗（未解決ゴール、ドリフト、忘却）を検知します。ボットにコンプライアンス境界があるなら役割遵守を追加し、ビジネスとして許容できないミスに対してカスタムG-EvalまたはAspectCritic基準を1つ追加してください。

LLM-as-a-judgeのコストは会話あたりいくらですか？

10ターンにスライディングウィンドウ5、加えて会話レベル呼び出し1回の場合、会話あたり7回のジャッジ呼び出しになります。GPT-4o-miniで呼び出しあたり約2,000入力トークンとして、この記事の計算では100会話あたり約$0.29です。プレミアムジャッジモデルなら10〜50倍になります。

マルチターン評価でDeepEval vs RAGAS：どちらを選ぶべきですか？

組み込みの会話シミュレーターでオフラインリグレッションテストをしたいならDeepEval。特に本番トラフィックが存在する前に有効です。実際の失敗した会話を読むことから始め、各失敗モードをAspectCriticとしてコード化するワークフローならRAGAS。一般的な分担：CIにはDeepEval、本番ログにはRAGASスタイルのクリティック。

マルチターン評価スイートにシナリオは何件必要ですか？

最低20件。主要ユースケース、エッジケース、失敗しやすい状況をカバーします。この閾値はDeepEvalの公開ガイダンスに由来し、私たちの経験とも一致します。20件未満では、合格率がどのシナリオが含まれたかに左右されます。本番の失敗ごとにセットを成長させてください。

マルチターン評価をCI/CDで実行できますか？

はい。固定のシナリオセットをリポジトリに保持し、プロンプトやモデルの変更ごとに実行し、指標がベースラインに対して許容範囲を超えて低下したらビルドを失敗させます。モデルは非決定的なので、正確な閾値ではなく、許容範囲（私たちは0.03を使用）付きで3回実行の平均を比較してください。

本番環境でマルチターン会話をどう評価しますか？

トレースを会話スレッドでグループ化し、各スレッドを非同期でスコアリングして評価が応答をブロックしないようにし、失敗したスレッドをレビューキューにルーティングします。確認されたすべての失敗がオフラインスイートの新しいシナリオになり、監視とリグレッションテストのループが閉じます。

まとめ

• シングルターンスコアは会話の失敗を検知できません。研究は、健全なベンチマークにもかかわらずターンごとにモデルが劣化することを示しています。
• 会話レベルのスコアリングをゲートとして、スライディングウィンドウのスコアリングを壊れた箇所の特定に使います。
• 4つのコア指標と1つのカスタム基準で、ほとんどのチャットプロダクトをカバーできます。常にジャッジの前に二値チェック。
• シミュレートリグレッションテストにはDeepEval、エラー分析駆動クリティックにはRAGAS、本番トレースにはLangfuse。
• ジャッジコストは小さい（ミニモデルなら100会話あたり1ドル未満）。コストがブロッカーになることはまれです。

より広いツールランドスケープについては、LLM評価ツールランキングで全分野をランク付けしています。評価パイプラインを誰かと一緒に構築したい方は、Techsyチームの無料相談をご利用ください。