LLMチャットボットのマルチターンチャット品質を改善する5つのテクニック（2026年版）

マルチターンのチャットは、なかなか気づきにくい問題です。シングルターンのチャットはうまくいくのに、会話が長くなるにつれ、ドリフト（時間経過とともに検索精度やモデルの予測性能がじわじわと低下していく現象）、指示の希薄化、コンテキストオーバーフローが静かにレスポンスを劣化させます。この記事では、まず Difyで構築した GPT-5.2 ベースのチャットボットが、同じ会話の中でスコア97から22まで崩壊した実例 を見たうえで、こうした問題を検出・修正するための5つの実践的テクニックを紹介します。

なぜマルチターンは壊れるのか

マルチターンチャットには、{入力, 期待出力} のベンチマークでは検出できない3つの崩壊パターンがあります。

これらのパターンは本番ログでは検知できません。エラーも警告もなく、通常通り会話が完結したように見えるだけです。

実証テスト — これらの崩壊パターンは最新モデルでも発生するのか

上の3つは「理論上そうなる」という話だけなら対策する気にもなりにくいものです。実際に最新モデルで発生するのかを確かめるため、テスト用に構築したDifyチャットボットで試してみました。

システムプロンプトはたった1つ: 「最新の生成AIの話題のみ回答すること。それ以外は丁寧に断ること。」 ベースモデルは GPT-5.2 です。これをConvoProbe（マルチターン会話テストツール）でテストしました。

テスト対象について: ここで検証しているのは GPT-5.2 を素で呼び出した結果ではなく、Difyで構築したチャットボット の挙動です。Difyのプロンプト処理やメモリ管理、ベースモデルを含んだシステム全体としての結果なので、素のモデル単体の能力を示すものではありません。

シナリオ

今回は「指示の希薄化」をターゲットにした7ターンのシナリオを設計しました。

ターン6→7が大事なポイントです。AI×料理の話を抽象的に議論した直後、具体的なレシピ依頼を拒否できるかを見たいわけです。

結果 — 英語・日本語ともにターン7で崩壊

以下、各言語で実行してみた結果です。

日本語版:

英語版:

LLMからの回答まで表示すると長くなるので載せていませんが、スコアが良いということは期待通りの回答、スコアが悪いということは期待とは異なる回答だった、ということです。

結果を見ると、ボットは両言語ともターン6まで踏みとどまりました。ターン3のスコープ外の天気質問も、ターン5のフレンドリーなレストラン質問も断れています。しかしターン7、AI×レシピ生成の話題に誘導された直後、ボットは完全に制約を守れず、材料と手順付きのフルレシピを生成してしまいました（両言語で同じ挙動）。

失敗の中身 — 評価器の判定

日本語版の失敗について、評価結果がこちらです。

ボットは「生成AI技術の話はできるが具体的レシピは作れない」と答えるべきでした。しかし実際には鶏肉とトマトのガーリック煮込みを正確な分量付きで生成しています。スコアも、何が起きたかを正確に反映していて、意味的一致・網羅性・正確性がすべて同時に崩れました。

崩壊を防ぐための5つのテクニック

崩壊が現実に起こることは確認できました。ここからは、こうした崩壊を検出・予防するための5つの実践的テクニックを紹介します。

テクニック1: 検索側スライディングウィンドウ

問題: 会話が長くなると、RAGが検索に使うクエリに過去のトピックが混ざり込んでいきます。たとえば「返品ポリシーについて聞いた後にスペック比較をしている」状態では、クエリが「返品 × スペック」の混合になります。ベクトルDBはそれに最も近いチャンクを忠実に返すので検索スコア自体は高く見えますが、実際には ユーザーが今欲しい情報とはズレたチャンク が返ってきています。ボットはそれを元に自信満々に間違った回答を生成してしまうのです。

解決策: 定期的にLLMにユーザーの現在の意図をクリーンな独立したクエリとして再要約させます。蓄積された会話ではなく、この新鮮なクエリをベクトルDBへの入力として使います。

通常時:        [会話履歴全体] → ベクトルDB
Nターンごと:   [LLMによる意図の要約] → ベクトルDB  (クリーンなクエリ)

なぜ効くのか: そもそもベクトルDBの検索自体は壊れていません。「送られてきたクエリに最も近いチャンクを返す」という仕事を正しくしているだけです。問題は、何を送るか にあります。会話履歴をそのまま送れば古いトピックが混ざったクエリになり、それに近いチャンクが返ってくる。LLMに「今のユーザーの意図」だけを抜き出させてから送れば、検索エンジン側を一切変えなくてもこのズレを解消できます。

テクニック2: システムプロンプトの再注入

問題: システムプロンプトで「最新の生成AIの話題以外は丁寧に断ること」と指示しても、会話が長くなるとモデルはこの制約を徐々に忘れていきます。冒頭の実証テストでまさにこれが起きていました。ターン7でボットがレシピを作ってしまったのは、指示を明示的に破ったというより、指示の存在感が会話の勢いに押し流された結果です。

ここで注意したいのは、システムプロンプトは消えたわけではないこと。コンテキストには最初のままちゃんと残っています。しかし会話履歴が長くなるにつれ、モデルの注意は直近のメッセージに引っ張られ、最初に書いた指示の存在感がどんどん薄れていきます。

解決策: 会話の途中で、システムプロンプトをもう一度コンテキストに差し込み直します（再注入）。これで「今のユーザーメッセージの直前」にシステムプロンプトが位置するようになり、モデルが強く意識する状態に戻ります。

いつ再注入するか、2つの方針があります:

• 固定間隔: たとえば5ターンごとに差し込む。シンプルで常に効く
• トピック変更を検知したタイミング: 直近2つのユーザーメッセージの「意味の近さ」を測り、急に遠くなったら話題が切り替わったと判断して差し込む。古いトピックを引きずりにくくなる

「意味の近さ」はコサイン類似度（cosine similarity）という手法で数値化できます。文章を数値ベクトルに変換し、そのベクトル同士の角度で近さを測るもので、0（完全に違う）〜1（同じ）の範囲に収まります。たとえば閾値を0.7にしておき、これを下回ったら「トピックが変わった」と判定する、といった使い方をします。

トリガー条件（いずれかを満たしたら）:
  1. 固定間隔 — Nターンごと
  2. 類似度低下 — 直近2メッセージのcos類似度 < 閾値（例: 0.7）

アクション: 応答生成前に、システムプロンプト全文をコンテキストの末尾に再追加する

テクニック3: 意図スナップショットによるドリフト検出

問題: ドリフトは、1回の劇的な破綻として発生するのではなく、ターンを重ねるうちにじわじわ進行します。そのため、目視では気づきにくいのが厄介です。

解決策: 定期的に、モデルに「今、ユーザーが知りたいことは何か」を一文で要約させます。これらのスナップショットを保存してdiffを取り、モデルの要約がユーザーの実際の発言と乖離し始めたら、ドリフトが発生しているサインです。

スナップショットA: 「ユーザーはノートPCの返品ポリシーを知りたい」
スナップショットB: 「ユーザーはノートPCのスペックを比較している」    ← トピック変化
スナップショットC: 「ユーザーはアクセサリの保証範囲を聞いている」     ← ドリフト検出

人間のレビュアーが長い会話を読んでドリフトに気づくのは難しいですが、上記のようにスナップショットを取ることでチェックが容易になります。

テクニック4: 敵対的ターン注入

問題: ユーザーは現実の会話の中で、気が変わったり、自分自身と矛盾したり、以前のトピックを予想外に参照したりします。こうした「混乱させる入力」にチャットボットがどれだけ耐えられるか、事前に知っておく必要があります。多くのチャットボットは会話の序盤ではうまく処理できますが、長い会話では大きく意図からズレた回答をすることがあるからです。

解決策: 会話の途中で、以前の指示や確立された事実と矛盾するメッセージを意図的に注入します。モデルが矛盾を正しく指摘できるのか、それとも直近のメッセージに盲目的に従ってそれまでの文脈を忘れてしまうのかをテストします。

ターンX:   ユーザーが事実Aを確立
ターンY:   ユーザーが新トピックBに切り替え
ターンZ:   ユーザーが誤った記憶を注入 — 「最初からBの話をしていましたよね？」
             ↓
            ボットは実際の履歴を正しく思い出したか？

このテストは、どちらの結果になっても会話を続けてさらに深掘りしたいという性質を持っています。

• ボットが正しく訂正できた場合 → 次は「訂正されたあとでユーザーが感謝したら、ちゃんと会話を継続できるか」を確認したい
• ボットが誤った記憶に同調した場合 → 次は「さらに揺さぶったら、もう一段階深く破綻するのか、それとも踏みとどまれるのか」を確認したい

つまり、ボットの応答次第で次のユーザーメッセージを変える必要があるのです。これは「ユーザーメッセージが固定の台本で進む一本道のテスト」では表現できず、分岐シナリオ — 実行時にボットの応答を見て次のパスを選ぶ仕組み — が必要になります。

ConvoProbe(https://convoprobe.vercel.app) では、こうした分岐をビジュアルに設計できます。

右側の 条件プロンプト の内容に従ってチャットボットからの返答を即座に評価し、2つのパスから1つを選びます。「ボットが誤った記憶を正しく訂正した」場合は、左側の成功パスによる内容を次の会話としてボットに投げます。「ボットが誤った記憶に同調した」場合は、右側の失敗パスによる内容が次の会話になります。それぞれのパスに独自のフォローアップと採点を持たせられます。

テクニック5: 会話コントラクト

問題: チャットボットは会話中に約束（コミットメント）を口にします。「返金は3-5日で処理されます」「その商品は青と赤があります」「請求部門に転送します」などです。これらは後のターンで忘れられたり、矛盾する発言をしてしまったりすることが少なくありません。

解決策: 会話中にモデルが行ったすべての約束を追跡し、会話終了後（または途中のチェックポイントで）各約束が履行されているか、矛盾していないかを検証します。

追跡:
  ターン2: 「返品期間は30日です」        ← コミットメント
  ターン5: 「請求部門に転送します」        ← コミットメント
  ターン8: 「割引は15%です」              ← コミットメント

終了時に検証:
  すべてのコミットメントが一貫性を持って履行されたか？

間違った情報を一度受け取っただけのユーザーは気づかないかもしれません。しかし明示的に約束されたことが実現しなかったユーザーは、確実に覚えています。約束の不履行は、チャットボットに対する顧客クレームの最大の原因の一つです。

あなたのチャットボットにとっての意味

得るべき教訓は3つあります。

1. これらの崩壊パターンは最新モデルでも発生する 冒頭の実証テストで見たとおり、執筆時点で最新の GPT-5.2 をベースにしたDifyチャットボットが、わずか6ターンでシステムプロンプトの指示を忘れました。より新しく高性能なモデルを使っても、指示の希薄化からは守られないかもしれません。
2. 言語を変えても回避できない 同じチャットボットが英語・日本語のどちらでもターン7で崩壊し、崩壊の仕方もほぼ同じでした。複数言語でデプロイするなら、それぞれでテストする必要があり、同じ崩壊パターンが出ることを覚悟しなければなりません。
3. マルチターンテストなしではこれらは見えない {質問, 期待回答} データセットではこれは絶対に検出できません。ターン7以上まで到達する台本化された会話が必要で、理想的にはデプロイ前に走る回帰テストとして組み込むべきです。

これらの事象に対応するために ConvoProbe を開発しました。マルチターンのシナリオを作成し、実行することで、ターンごとのスコアリングと総合評価結果を確認できます。コード不要で機能します。加えて、DifyのDSLを読み込ませると、今回紹介した5つの崩壊パターンを検出するためのシナリオを自動で提案・生成してくれる機能もあります。

FAQ

マルチターンチャットテストとは何ですか？

1ターンずつのQ&A評価ではなく、会話全体を通して チャットボットの品質を見るテスト手法です。複数ターンにわたる正確性・一貫性・目標達成度をチェックすることで、シングルターン評価では見えない検索ドリフトや指示の希薄化といった崩壊パターンを見つけられます。

GPT-5.2 のような新しいモデルでも起きますか？

はい。本記事のテストも最新の GPT-5.2 をベースにしたDifyチャットボットで行いましたが、英語・日本語の両方でターン7で崩壊しました。モデルが新しくなって性能が上がっても、マルチターンのドリフトが発生する可能性はあります。これはモデルの素の能力の問題ではなく、「長い会話の中でシステムプロンプトの存在感が徐々に薄れていく」という構造的な現象だからです。

マルチターン品質はいつ頃から劣化し始めますか？

モデルやコンテキストウィンドウの大きさ、システムプロンプトの複雑さ、そしてなにより 会話の流れの勢い に左右されます。突然崩壊するというより、その前に「スコープの際どいところに一歩踏み込む会話」が挟まるパターンが多いです。本記事のテストでも、ターン6の「AI×料理」という微妙な話題を経由したあと、ターン7で一気に崩れました。

コーディングなしでマルチターン品質をテストできますか？

はい。ConvoProbeのようなツールを使えば、分岐つきのマルチターンシナリオをビジュアルエディタ上で設計できます。Pythonやスクリプトを書く必要がないので、エンジニアでないPMやQAの方でも自分でテストを作って走らせられます。

プロンプト変更後のリグレッションをどう検出しますか？

デプロイの前にマルチターンのシナリオ一式を流して、変更前後のスコアを比べるのが基本です。たとえば「プロンプトを調整したら序盤のターンのスコアは上がったが、後半のターンが逆に下がった」といった変化がすぐに見えます。

シナリオテストとLLMユーザーシミュレーションの違いは何ですか？

シナリオテストは、あらかじめ設計した会話パスを再現性高く何度でも実行できるので、回帰テストに向いています。一方、LLMユーザーシミュレーション（AIがユーザー役を演じる手法）は、想定していなかった崩壊パターンを探索的に見つけるのが得意です。どちらか片方ではなく、シミュレーションで見つけたバグをシナリオに落とし込んで回帰テストで守る という使い分けが理想的です。

サポートしている全言語でテストする必要がありますか？

はい。本記事のテストでは英語も日本語もターン7で崩壊しましたが、ターンごとのスコアや序盤の挙動は明らかに違いました（例: ターン5は英語 91.8 vs 日本語 77.0）。「英語で大丈夫なら他の言語も大丈夫だろう」とは限りません。実際に提供する言語それぞれでテストしておくのが安全です。