Context Rot

Context Rotとは何か、「コンテキスト上限を超える」ことと同じですか？

違う。Context Rotとは、入力の長さが増えるにつれてモデルの出力品質が徐々に低下していく現象を指す——会話がモデルが謳うコンテキストウィンドウ（例えば100万トークンのウィンドウのうち5万トークンしか使っていない場合）を全く満たしていなくても、品質の低下はすでに始まっている。これは「上限を超える」こととは全く別のことだ。上限超過は容量の問題であり、モデルが物理的にそれ以上の内容を受け付けられなくなる。Context Rotはソフトで段階的な品質劣化であり、モデルは正常に動作し続け、応答を生成し続けているが、その応答自体が徐々に信頼できなくなっていく。

この用語はChromaチームが2025年の技術レポートで正式に提唱し命名したもので、Claude 4、GPT-4.1、Gemini 2.5を含む18の主要モデルをテストした結果、免れたモデルは1つもなかった——これはContext Rotが特定モデル固有の欠陥ではなく、すべての大規模言語モデルが長い入力を処理する際に共通して見られる挙動パターンであることを意味する。

なぜContext Rotが起きるのか、モデル設計上の欠陥なのですか？

欠陥というより、大規模言語モデルが情報を処理する根本的な仕組みがもたらす必然的な結果と言える。モデルは各ターンの会話を処理する際、人間のように現在の入力とは独立した持続的な記憶を持つのではなく、履歴全体を毎回改めて読み直している。同時に、モデルが入力内の各テキストに向ける注意は均等ではなく、この「注意の予算」は入力の長さが増えるにつれてどんどん薄く配分されていく。冒頭や中盤に近く、現在の生成位置から遠い内容ほど、受け取る注意はより希薄になる。

Chromaの研究では直感に反する現象も見つかっている。構造が整然としており論理的に一貫した文書の方が、シャッフルされた雑然とした内容よりもモデルの性能を悪化させたのだ——これは「コンテキストは整理されているほど良い」という一般的な仮定が思ったほど信頼できないかもしれないことを示唆している。注意機構自体が論理的に一貫した長文に対して特殊な悪影響を示すようであり、詳細なメカニズムはまだ研究中である。

Context Rotは実際の使用でどのように現れるのですか？

いくつかのよくある具体的な症状がある。会話の早い段階で設定したルール（フォーマット要件、命名規則など）をモデルが静かに無視するが、無視していることは決して伝えない。回答内の正確な定義が徐々に曖昧な近似表現に置き換えられていく。長時間のデバッグセッションでは、モデルが同時に3つの異なる失敗した試み、各試みのエラーメッセージ、そしてある方法を放棄するようにという指示を、すべて同じコンテキストの中に積み重ねて見ていることがある。こうした矛盾する情報をすべて同時に処理しなければならず、その結果、この混乱したコンテキストを引きずるより、最初から考え直す方が簡単になることが多い。

さらに厄介なのは、このプロセスには通常明確な警告サインがないことだ。モデルはエラーを出したり回答を拒否したりせず、自信を持って出力を生成する。ただしその出力は、最初に設定した仕様から静かにずれてしまっている。目視で結果と元の要求を突き合わせて初めて、問題がしばらく前から起きていたことに気づくことになる。

ユーザーとして、Context Rotの影響を減らすために何ができますか？

いくつかの実用的な方法がある。本当に重要なルールは、会話の冒頭で一度言っただけで永久に有効だと思い込まず、それが実際に効力を発揮すべき箇所の近くで改めて言い直す。繰り返しに聞こえても、はるか前に埋もれて自然に薄まっていく運命に任せるよりはるかに信頼できる。Claude Codeのようなツールを使っているなら、会話を圧縮するコマンド（/compactなど）に注意を払い、会話が明らかに長くなったが品質がまだ目に見えて落ちる前に自主的に整理する。すでにモデルが当てずっぽうで動いている段階まで待たない。繰り返し使うルールについては、毎回口頭で言い直すより、CLAUDE.mdに書き込むかSkillとしてパッケージ化し、毎回のセッション開始時に確実に読み込まれるようにする方が根本的な解決策になる。

また、もしChromaの発見が正しいなら——雑然とした構造の内容が、整然とした内容よりも良い結果を出すことがある——これはユーザーがコンテキストを「きれいに整理する」ことに過度にこだわる必要がないことを示唆している。本当に注目すべきは、内容が本当に必要な場所で見られているかどうかであり、フォーマットの体裁ではない。