AI は会話が長くなるほど「迷子」になる — Microsoft × Salesforce の衝撃の研究

紹介ポスト: kosuke_agos 論文: LLMs Get Lost In Multi-Turn Conversation Microsoft Research: 公式ページ

はじめに

「AI と長く会話するほど、AI の知能が劣化する」— これは体感ではなく、Microsoft Research と Salesforce Research が 20万件以上の AI 会話を分析 して科学的に証明した事実である。

論文タイトルは “LLMs Get Lost In Multi-Turn Conversation”（LLM はマルチターン会話で迷子になる）。GPT-4.1、Claude 3.7 Sonnet、Gemini 2.5 Pro を含む 15 モデル全てで、会話が長くなるほど性能が劇的に低下することが明らかになった。

衝撃の数字

最も重要な発見: 高性能モデルも小型モデルも、同じように劣化する。

Claude 3.7 Sonnet、Gemini 2.5 Pro、GPT-4.1 といったトップモデルでも 30〜40% の性能低下が観測された。モデルの「賢さ」では回避できない、構造的な問題であることが判明した。

研究チームと手法

著者

テスト対象モデル（15種）

• OpenAI: GPT-4o-mini, GPT-4o, o3, GPT-4.1
• Anthropic: Claude 3 Haiku, Claude 3.7 Sonnet
• Google: Gemini 2.5 Flash, Gemini 2.5 Pro
• Meta: Llama 3.1-8B, Llama 3.3-70B, Llama 4 Scout
• その他: Microsoft Phi-4, AI2 OLMo-2-13B, Deepseek-R1, Cohere Command-A

Sharding（シャーディング）— 現実の会話を再現する手法

ユーザーは通常、最初から完璧な指示を出さない。

ターン1: 「Pythonで関数を作って」
ターン2: 「あ、入力はリストで」
ターン3: 「ソート済みで返してほしい」
ターン4: 「重複は除去して」

研究チームはこの現実のパターンを再現するため Sharding（シャーディング） を開発。完全な指示を分割し、会話のターンごとに1つずつ追加情報を与える。

テストしたタスク（6種類 + 1）

1. コード生成 — Python 関数（HumanEval, LiveCodeBench）
2. データベース — テキストから SQL（Spider）
3. 関数呼び出し — API アクション選択
4. 数学 — 算術問題（GSM8K）
5. テキスト生成 — 表からキャプション生成
6. 要約 — 複数文書の要約（引用付き）
7. 翻訳 — ドイツ語→英語（別途テスト）

AI が犯す4つの失敗パターン

研究チームは 20 万件以上の会話を分析し、劣化の根本原因を4つ特定した。

1. 早すぎる結論（Premature Solution Attempts）

不完全な情報の段階で最終回答を出してしまう。その後に追加情報が来ても、最初の回答に引きずられて軌道修正できない。

ユーザー: 「リストを処理する関数を作って」
AI: 「はい、こちらが完成した関数です！」  ← まだ要件の半分しか聞いていない
ユーザー: 「あ、ソートも必要で…」
AI: （最初の実装に無理やりソートを継ぎ足す → 破綻）

2. 過去の回答への依存（Over-reliance on Prior Responses）

自分が以前のターンで生成した（間違った可能性のある）回答を「正しい前提」として扱い続ける。自己強化的な誤りが蓄積する。

3. 中間情報の無視（Recency Bias）

最初のターンと最後のターンは覚えているが、途中のターンで与えた情報を忘れる。会話が長くなるほどこの傾向が強まる。

4. 回答の肥大化（Answer Bloat）

ターンが進むにつれ回答がどんどん長くなり、根拠のない仮定や余計な説明が混入する。推論モデル（o3, Deepseek-R1）は 33% 長い回答を生成したが、劣化パターンは同じだった。

技術的な対策は効かなかった

唯一の例外: 翻訳タスク

6つのタスクのうち翻訳だけは劣化がほぼなかった（-3%〜+5%）。翻訳は「前のターンの結果に依存しない独立した作業」だから。この発見が後述の「サブエージェント戦略」の根拠になる。

「Aptitude（適性）」と「Reliability（信頼性）」の分解

この研究の画期的な点は、性能を2つの軸に分解したことにある。

つまり「最高の結果」はそこまで悪化しないが、「結果のばらつき」が倍以上になる。同じ指示をしても、ある時は正しく、ある時はまったく間違える — この不安定さこそがマルチターンの本質的な問題。

単一ターンでは強いモデルほど安定していたが、マルチターンでは全モデルが同程度に不安定になった（約50ポイントの変動幅）。

実践的な対策 — 研究チームの推奨

エンドユーザー向け

1. 会話が行き詰まったら、新しいセッションをやり直す — 続けるより効果的
2. やり直す前に「ここまでの指示を要約して」と頼む — その要約を新しい会話の最初に渡す
3. 指示はできるだけ最初にまとめて渡す — 段階的な追加を減らす

開発者向け

1. マルチターンの信頼性を、単一ターンの性能と同等に重視する
2. エージェントフレームワークだけでは補えない — モデル自体のマルチターン対応が不可欠
3. 既存ベンチマークの Sharded 版を作り、マルチターン評価を標準化する

Claude Code のベストプラクティスが科学的に裏付けられた

この研究の発見は、Claude Code コミュニティで経験的に確立されたベストプラクティスと完全に一致する。

Plan Mode = 「完全な指示を最初に固める」

研究結果: 段階的な指示追加が劣化の主因。完全指示（Full）が最高性能。

→ Plan Mode で計画を固めてから実装することで、「あ、あとこの条件も」という段階的な指示追加を最小化できる。

サブエージェント = 「会話を短く保つ」

研究結果: 翻訳タスク（独立した作業）だけは劣化しなかった。

→ サブエージェント（Task）に独立したタスクを委譲することで、各エージェントの会話ターンを短く保てる。メインの会話が長くなっても、調査・分析は短い新しいコンテキストで実行される。

コンテキスト管理 = 「定期的にリセットする」

研究結果: 行き詰まったら新しいセッションでやり直す方が、続けるより効果的。

→ CLAUDE.md にルールを書いておくことで、新しいセッションでも同じ品質が維持される。コンテキストの汚染を恐れずにセッションをリセットできる。

この研究が科学的に証明したのは、「CLAUDE.md のベストプラクティス」は感覚的な Tips ではなく、AI の構造的な劣化を防ぐための合理的な対策 だったということ。

まとめ

1. AI は会話が長くなるほど確実に劣化する — これは全モデルに共通する構造的問題
2. Temperature 調整やプロンプト工夫では根本解決しない — モデル自体の改善が必要
3. 現時点で最も有効な対策は「会話を短く保つ」こと — Plan Mode、サブエージェント、セッションリセット
4. AI エージェント時代には「コンテキスト管理」が最重要スキル — いかに会話の汚染を防ぎ、必要な情報を構造化するか

AI を賢く使うとは、「長く会話する」ことではなく、「短く、的確に、必要な情報を最初に渡す」 こと。この研究はそれを 20 万件のデータで裏付けた。

参考リンク

• LLMs Get Lost In Multi-Turn Conversation（論文）
• Microsoft Research 公式ページ
• GitHub: Microsoft/lost_in_conversation（コード・データ）
• Windows Central: AI chatbots get dumber the longer you talk
• THE DECODER: AI chatbots become dramatically less reliable
• Claude Code の能力を10倍にする CLAUDE.md — 関連 Gist