初めに
会話履歴も、参考資料も、ツールの実行結果も、全部LLMに渡す。
情報が多いほど回答が正確になると思いがちですが、必要な情報を見落とすことがあります。
この問題を考えるときに出てくるのが、**コンテキストの腐敗（Context Rot）**です。
1. Context Rotは、長い入力で情報の活用が不安定になる現象
コンテキストとは、回答を生成するときにモデルへ渡す情報です。指示、会話履歴、資料、ツール結果などが含まれます。
Context Rotは、コンテキストが長くなるにつれて、必要な情報を取り出し、活用する性能が低下する現象を指します。
Chromaの2025年の研究では、18のLLMを評価し、単純なタスクでも入力が長くなると性能が不安定になることを報告しています。影響の大きさは、モデルやタスク、入力内容によって異なります。
「腐敗」は比喩です。保存したデータや、モデルの重みが壊れるという意味ではありません。
2. 入力できる量と、正確に使える量は違う
コンテキストウィンドウは、モデルが一度に受け付けられるトークン量の上限です。
ただし、上限以内なら、すべての情報を同じ精度で使えるとは限りません。Context Rotは、上限に達する前でも問題になります。
たとえば、問い合わせ対応で次の情報を渡す場合です。
| コンテキストの内容 | 回答に必要か |
|---|---|
| 現在の質問 | 必要 |
| 対象製品の最新仕様 | 必要 |
| 別製品の過去の検索結果 | 今回は不要 |
| 解決済みの問い合わせ履歴 | 今回は不要 |
不要な情報に加え、似た製品の仕様などが混ざると、根拠を取り違える可能性もあります。
Chromaの研究でも、正解と関連するが答えにはならない情報の影響を調べています。
3. 対策は、毎回必要なコンテキストを組み立てること
実装では、「全部残す」よりも、今回の処理に必要な情報を選ぶ設計が役立ちます。
| 対策 | 実装例 |
|---|---|
| 必要時に取得する | 資料全文を常駐させず、検索して取得する |
| ツール結果を絞る | 大量のログから、判断に必要な箇所を抽出する |
| 履歴を整理する | 決定事項・制約・未完了作業を要約する |
| 状態を外部保存する | 進捗や出典をファイル・DBに保存する |
| 処理を分割する | 次の段階に必要な結果だけを渡す |
Anthropicも、長時間動くエージェント向けに、コンテキストの圧縮や構造化したメモを紹介しています。
Prompt chainingでも、毎回すべての履歴を引き継ぐと入力は増え続けます。段階ごとの入出力を決めることが大切です。
4. 要約では、残す情報を決めておく
会話を短くするだけでは、必要な条件まで失うことがあります。
たとえば、次の形式で状態を残します。
目的：製品Aの問い合わせに回答する
制約：最新版の仕様を根拠にする
確認済み：資料ID spec-a-v3 を取得済み
未確認：契約プランによる機能差
次の処理：対象プランを確認する
正確な引用や数値が必要な場合は、原文や参照先も保持します。要約は、原文を再確認できる形にすると扱いやすいです。
5. 短くした結果は、実際の質問で評価する
短いコンテキストが常に正しいわけではありません。必要な根拠を削れば、回答品質は下がります。
同じ質問に対して、履歴を全部渡す場合と、選別・要約した場合を比較します。正答率、根拠の一致、制約の遵守を確認すると、削ってよい情報を判断しやすくなります。
Context Rotへの対策は、単なる文字数削減ではなく、必要な情報を残して、使いやすく渡す設計です。