コンテキストエンジニアリングで考えるContext Rot：長い会話でAIの精度が落ちる理由と対策

コンテキストエンジニアリングの課題であるContext Rot（コンテキストロット）は、入力が公称のコンテキストウィンドウ内に収まっていても、エージェントの精度を下げることがあります。18の言語モデルを対象としたChromaの研究では、入力の長さによって信頼性が変わることが確認されました。実務での対策は、次のアクションに必要な根拠を残し、関係のない履歴を減らすことです。

AIのContext Rotとは何ですか？

Context Rot（コンテキスト劣化）とは、言語モデルに渡す情報が増えるにつれて、応答の信頼性が低下する現象です。 必要な事実の見落とし、情報の誤った結び付け、すでに決まった方針を守らない回答といった形で現れます。長い会話をモデルが受け付けられても、その内容を正確に活用することは難しくなりえます。

コンテキストウィンドウは、モデルがリクエストを処理するときに使える作業領域です。指示、会話履歴、文書、ツールの実行結果などが入ります。トークンはモデルが処理する内容の単位で、多くの場合は単語の一部分に相当します。何がこの領域を使うのかは、コンテキストウィンドウの解説で説明しています。

障害対応の作戦室を想像してください。壁には現在の対応方針と一緒に、棄却した仮説、更新前の時系列、古いログが貼られています。壁を広げれば、もっと多くの資料を残せます。しかし、それだけでは次に入ってきた担当者に、どの判断が今も有効なのかは伝わりません。

エージェントをデバッグするときは、この違いを見極める必要があります。必要な事実がモデルにリクエストを渡す前に削られていたなら、入力の切り詰めや検索を調べます。事実が入力に含まれていたのに見落とされた、あるいは誤用されたなら、モデルが渡されたコンテキストをどう扱ったかを調べます。どちらの症状も、それだけで入力の長さに起因する問題だとは断定できません。

ドキュメントの確認日：2026年10月24日。 以下で紹介する提供元のガイダンスは、Anthropicの公開ドキュメントで確認しています。ワークフローの例は設計案であり、本番運用で得られた結果の報告ではありません。

ChromaのContext Rot研究で何が分かったのか

2025年7月14日に公開されたChromaのレポートでは、意味をより深く読み取らないと正解に結び付かない課題や、関連がありそうに見える紛らわしい情報があると、長い入力から必要な情報を取り出す信頼性が下がりました。条件を制御した課題から得られた有用な知見ですが、自分たちのエージェントの性能を示すベンチマークではありません。研究の原文。

Chromaは、データを整理した会話ベンチマークLongMemEvalで、平均約113,000トークンの306件のプロンプトと、必要な情報に絞った平均約300トークンの入力を比較しました。評価対象のモデルでは、情報を絞った入力のほうが高いスコアを得ました。ただし、この短い入力は、関連箇所としてラベル付けされた文章と手作業による調整で作られています。検索システムが自動で必要箇所を選べるかを評価したものではありません。研究の方法と結果。

Chromaの研究結果から言えることには限界があります

このレポートは、現象の根本的な仕組みや、どのモデルにも通用する安全なトークン数を明らかにしたものではありません。また、同じテキストを繰り返す実験では、入力とともに出力も長くなっています。この点は、短い回答を求める情報検索のテストとは異なります。研究の限界と課題の説明。

開発者が問うべきなのは、自分たちのシステムが必要な根拠を見つけ、それを保持できるかどうかです。慎重に選んだ根拠と全履歴を比較したグラフだけでは、検索インデックス、フィルター、要約処理がその根拠を正しく選べるかは分かりません。選別の精度は、別途評価する必要があります。

コンテキストが長いと、なぜ情報を使いにくくなるのか

関連する情報は、周囲の情報から見分けられる必要があります。 古いデプロイ計画は、無関係な文書よりも現在の計画に似ていることがあります。問題は、必要な一文が見つからないことだけではありません。今の状況に、別の一文を誤って適用してしまうこともあります。

Anthropicのコンテキストエンジニアリングのガイダンスは、アーキテクチャ上の制約や、学習に使われる系列が主に短いことを、長いコンテキストを扱いにくくする要因として挙げています。また、ある境界を越えると突然能力が失われるのではなく、精度が徐々に下がると説明しています。これらは考察の手掛かりになる説明ですが、因果関係の全体像が証明されたわけではありません。

初期診断、うまくいかなかった回避策、後から確認された修正方法が履歴に残っているサポートエージェントを考えてみます。その後のツール呼び出しで古いトラブルシューティングガイドが返ってきた場合、次の回答では、時系列とどの情報を正とするかの両方を整理しなければなりません。ユーザーの質問は同じでも、テキストが増えたことで判断が複雑になっています。

この整理を明示的に行います。現状を特定し、初期診断は棄却済みだと示し、採用した修正方法を裏付ける情報源を残します。目指すのは、必要な根拠が十分にあり、それぞれの情報の扱いが明確な状態です。ひたすら短いプロンプトを作ることではありません。

開発者と運用担当者が最初に確認すべきこと

モデルに原因を求める前に、同じ判断を異なるコンテキストで比較します。 開発者は、アプリケーションが実際に組み立てたリクエストを記録する必要があります。画面に見える会話履歴には、モデルに渡されたシステム指示、検索結果、ツールの応答が表示されていないことがあります。

運用担当者は、見落とされた要件や誤ったアクションを具体的に特定します。「会話の質が落ちた気がする」では調査が難しくなります。「障害記録ですでに棄却した回避策を勧めた」なら、再現して調べられます。

保存した事例を使い、次の順序で診断します。

1. 1

   判断の条件を固定する

   質問、モデルの設定、求める結果を固定します。元の入力と、判断の根拠となる正しい情報を保存します。再実行によって事例の状況が変わらないよう、外部へのアクションは実行せずに比較します。

2. 2

   必要な根拠が届いていたかを確認する

   実際のリクエストに必要な文章が含まれているかを探します。なければ、まず検索、入力の切り詰め、状態の読み込みを修正します。代わりに古い情報源が届いていたなら、情報源の選び方と鮮度を見直します。

3. 3

   必要な情報に絞った比較用の入力を作る

   タスクの指示と回答に必要なすべての根拠を維持し、無関係な履歴や古くなったツール結果を取り除きます。期待する答えを入力に加えたり、タスクを簡単にしたりしてはいけません。代表的な事例を再実行し、正確さ、情報源の使い方、制約を守れているかを比較します。

4. 4

   失敗の原因に応じて修正方法を選ぶ

   情報を絞った入力で改善するなら、コンテキストの選別と整理を調べます。どちらの入力でも失敗するなら、タスク、指示、根拠の質、モデルの能力を見直します。要約後から失敗するなら、要約で何が失われたかを確認します。

この比較は診断のためのものであり、長さだけがエラーを引き起こした証拠にはなりません。情報を取り除くと、その構成も変わるためです。長さの影響をより厳密に調べるには、関連する根拠とその配置を一定に保ったまま、無関係な情報を追加します。たまたまうまくいった再実行の結果を一般化してはいけません。

履歴が増えるたびに防げたはずのミスが繰り返されるなら、チームは対策に着手すべきです。一方、範囲が限定された短いワークフローで、正確性のチェックを満たしているなら、シンプルな設計を維持できます。失敗の原因から必要性が明らかになったときに、処理の分担や連携の仕組みを加えます。

コンテキストエンジニアリングでContext Rotを抑えるには

問題を起こしている情報に合わせて、対策を選びます。 コンテキスト圧縮は蓄積した履歴を管理し、検索は根拠を選び、サブエージェントは調査の範囲を分離します。情報の並べ方はタスクを明確にし、簡潔なツール応答は不要な入力を減らします。これらは互いを補う手段ですが、それぞれ異なる失敗の仕方があります。

履歴を圧縮しても、作業の状態は残す

コンテキスト圧縮とは、古い会話内容を、作業を続けるための短い記録に置き換えることです。 Anthropicの公開中のコンパクションのドキュメントは、アクティブなコンテキストを小さく保つ重要性について、**「会話が長くなるにつれて、応答の品質は低下します」**と説明しています。APIでは、アプリケーションから要求する圧縮と、設定したトークン数のしきい値をきっかけに行う圧縮の両方を利用できます。

引き継ぎの内容は、次のアクションに何が必要かを軸に設計します。障害対応の例なら、現在の目標、確認済みの原因、棄却した回避策とその理由、残る不確実性、情報源の場所、次のアクションを残します。正確さを保つために必要なら、識別子や文章は原文どおりに保持します。

「問題を調査し、進展があった」という引き継ぎでは不十分です。「回避策は必要な動作を損なうため棄却した。採用した修正方法は障害対応文書に記録済み。検証はまだ終わっていない」と書けば、調査の経緯を最初から説明し直さなくても、作業を続けられます。

注意点： 要約では、後から重要になる詳細を捨ててしまうことがあります。元の記録にアクセスできる状態を保ち、再開後のエージェントが、その詳細を必要とする質問に答えられるかを評価します。永続的な状態を保存することと、何を再び読み込むかを選ぶことは、別の作業です。この違いはエージェントのメモリの解説で扱っています。

必要になった時点で根拠を検索する

大きな情報源は参照先を保持し、必要な部分を必要なときに読み込みます。 Anthropicはこれをジャストインタイムのコンテキストと説明しています。エージェントはファイルパス、クエリ、リンクなどを保持しておき、必要に応じて情報を取得できます。コンテキストの検索に関するガイダンス。

障害対応エージェントなら、まず現在の障害記録と、対象サービスに適用されるドキュメントから始めます。診断上必要になったときに、過去の障害記録を取得します。取得した文章には、情報源と、分かる場合はバージョンや日付を添えます。例外条件を解釈できるよう、前後の文脈も十分に含めます。

注意点： 検索では、判断を左右する一節が抜けたり、もっともらしいものの古い情報が返ったりすることがあります。回答の品質を測る前に、必要な根拠が揃っているかをテストします。抜粋だけでは判断できない場合に、エージェントが検索範囲を広げたり、情報源の全文を読んだりできるようにします。

検索結果を少なくすることが有効なのは、判断に必要な情報が残っている場合だけです。「すべてを詰め込まず、検索で取得する」は情報を選ぶ方針であり、都合の悪い文脈を隠す指示ではありません。

サブエージェントには、範囲を絞ったタスクと独立したコンテキストを渡す

メインエージェントが生の調査結果を必要としない探索は、別のコンテキストで行います。 AnthropicのClaude Codeサブエージェントのドキュメントでは、サブエージェントが独自のコンテキストウィンドウで動作し、メインの会話に結果を返す仕組みが説明されています。

ログを調べる担当には、具体的な質問、関連するサービスの情報、ログの参照先を渡します。返す内容は、分かったこと、その裏付けがある場所、不確実な点、未解決の依存関係です。メインエージェントは、調査過程のすべてを抱えずに、その結果を利用できます。

注意点： コンテキストを分離すると、共有される知識も減ります。担当に必要な制約を渡し、結論には根拠を添えるよう求めます。利用しているオーケストレーションのフレームワークが、実際にどの情報を担当へ渡すのかを確認してください。親の履歴を丸ごとコピーしていたら、分離する目的を果たせません。各担当の会話記録をすべて親へ貼り戻せば、親のコンテキストが再び雑多になります。

この方法は、切り離して進められる調査に適しています。共通の記録に依存し、各要素が密接に関わる判断では、メインのコンテキストで必要箇所を検索するほうが扱いやすい場合があります。

文書と現在の質問を、意図して配置する

現在のタスクと、その参考資料を見分けやすくします。 Anthropicの長いコンテキスト向けのプロンプト作成ガイダンスでは、長い文書をプロンプトの前方に置き、情報源を区別し、その後に質問を置くことを推奨しています。また、文書に関する質問に答える前に、関連する引用箇所を見つけることも勧めています。

アプリケーションでは、動作を規定する指示を、本来の指示用チャネルに置きます。タスク入力の中では、現在の障害記録と過去のメモを別々にラベル付けし、質問と求める出力を明確に示します。検索で取得した文章は、配置を変えたからといって、動作を規定する指示として扱ってはいけません。

注意点： 並べ替えても、読み込まれていない根拠は戻ってきません。また、どのモデルやタスクでも確実に効く配置はありません。自分たちの事例で配置を比較します。現在のタスクを簡潔に示せば足りる場面で、毎ターン規則集の全文を繰り返すことは避けます。

ツールの出力は必要な部分に絞り、全文へ戻れるようにする

次の判断に必要な結果を返し、元の成果物全体を確認するための参照先を添えます。 Anthropicのツール設計のガイダンスは、意味のある応答と、フィルタリング、ページ分割、切り詰めなどの制御を推奨しています。また、コンテキスト編集のドキュメントでは、古いツール結果を会話履歴から削除する仕組みを別途説明しています。

チェックが失敗した場合は、失敗の内容、関連するエラーの抜粋、保存したレポートの場所を返します。検索なら、関連する文章とその情報源を返します。操作が成功した場合は、ステータスと、作業を続けるために必要な識別子を返します。ツールがレポートを生成したというだけの理由で、その全文を埋め込まないようにします。

注意点： 内容を見ずに切り詰めると、決定的なエラーや適用条件が失われることがあります。省略があると分かるようにし、エージェントが追加の情報を要求できるようにします。後で調査に必要になる全文は、アクティブなコンテキストの外に保存します。

これらの制御は、リクエストを組み立てる処理に実装します。指示、メモリ、ツール、検索で取得した情報をどう組み合わせるかは、コンテキストエンジニアリングの総合ガイドで説明しています。

Context Rotについて、過大に語られていることは？

すべてのエージェントに共通する「このメッセージ数でリセットする」「ウィンドウをこの割合まで使ったらリセットする」という基準はありません。 大きすぎるリクエストを防ぐしきい値は、容量の設定です。特定のワークフローで信頼性が低下し始める地点は、実際のタスクに照らして測る必要があります。

また、長い会話で悪い回答が出たからといって、すべてがContext Rotの証拠になるわけではありません。根拠の欠落、矛盾する指示、壊れたツール、対応できないタスクでも、似た症状が起きます。役立つ障害報告には、どの判断に失敗したのかと、モデルが何を受け取ったのかを記録します。

コンテキスト圧縮は情報を完全には保持できず、外部メモリに保存した情報が自動的に関連情報になるわけでもありません。 どちらも、出力を検証すべき構成要素として扱います。誤った結論を効率よく保持すると、ワークフローが一貫して間違えるようになることもあります。

最後に、キャッシュは別の対策です。KVキャッシュはアテンション計算を再利用する仕組みであり、どの文書が重要かを選んだり、古い履歴を取り除いたりするものではありません。キャッシュが有効に働いているリクエストでも、次の判断に不適切な情報が含まれている可能性はあります。

今週取り組めるチェックリスト

同じ失敗を繰り返すエージェントで、次を実施します。

• 判断に失敗した時点の実際の入力を保存し、必要だった根拠を特定します。
• 要件は変えずに、根拠を絞った入力でタスクを再実行し、代表的な事例で正確さを比較します。
• 最もノイズの多いツール応答を、関連箇所の抜粋と、成果物全体の参照先に置き換えます。
• 決定事項、棄却した方法、制約、情報源、未完了の作業を保持できる、圧縮時の引き継ぎ内容を定義します。
• 探索の過程で雑多な情報が増えているなら、切り離せる調査を独立した担当のコンテキストに分離します。
• 再開後のワークフローが必要な事実を保持し、対象の失敗を改善できる場合にだけ変更を本番へ反映します。以前の動作に戻せるようにしておきます。

まず、再現できる失敗から始めます。そうすれば、単に「コンテキストを減らせたか」を成功の指標にせず、変更を受け入れる明確なテストを設けられます。

Context Rotに関するよくある質問

Context Rotは今も起きるのですか？

Anthropicの現在のコンパクションのドキュメントにも、会話が長くなるにつれて応答の品質が低下すると明記されています。これは引き続きコンテキストを管理する根拠になりますが、現在のすべてのモデルの性能を示すものではありません。導入するモデルとワークフローを評価してください。

Context Rotを避けるにはどうすればよいですか？

現在有効な指示と必要な根拠を残し、古い情報や重複した情報を取り除きます。履歴は慎重に圧縮し、詳細は必要になったときに検索します。雑多な情報を生む付随タスクは、必要に応じて分離します。どの変更でも、次のアクションに必要な事実が残っているかを確認してください。

Context Rotの原因は何ですか？

コンテキストの長さ、周囲の情報の関連性、情報の提示方法は、信頼性に影響しえます。元の研究は、単一の根本原因を特定したものではありません。エージェントでは、対策を選ぶ前に、実際に渡された根拠と作業の状態を確認してください。

AIワークフローの開発と運用に役立つ実践ガイドをお届けします。ニュースレターに登録する。