この連載について

LLM（大規模言語モデル）を実務で使い倒すために知っておきたい「LLMのクセ」を全10回で解説する連載の第3回です。

ポチョムキン理解（第1回）
Lost in the Middle（第2回）
Context Rot ← 今回
Sycophancy（迎合）
Context Handoff
Prompt Distillation
Project化の罠
GPT化の罠
Instruction Drift
AI成果物の品質保証

「長く会話してるとAIがバカになっていく気がする」——使い込んでいる人ほど、この感覚を持っているはずです。結論から言うと、気のせいではありません。測定可能な現象です。今回はその正体、Context Rot（コンテキストの腐敗） を扱います。

現象：18モデル全てが、例外なく劣化した

出典はベクトルDB企業Chroma Researchが2025年7月に公開した技術レポート Context Rot: How Increasing Input Tokens Impacts LLM Performance。GPT-4.1、Claude 4、Gemini 2.5、Qwen3を含む18の最先端モデルをテストし、入力トークンが増えるほど出力品質が低下することを示しました。一部のモデルではなく、18モデル全てでです。

第2回のLost in the Middleとの違いを整理しておきます。

Lost in the Middle：情報の「位置」の問題。同じ長さのコンテキストの中で、どこに置くかで精度が変わる（U字カーブ）
Context Rot：コンテキストの「総量」の問題。位置に関係なく、入力が増えること自体がタスク全体の品質を蝕む

第2回が「空間の歪み」なら、今回は「量による腐食」です。

衝撃的なポイントが3つあります。

① 窓の限界よりずっと手前で始まる。 Context Rotはコンテキストウィンドウ溢れとは別物です。200Kトークンの窓を持つモデルでも、50Kトークン時点で顕著な劣化が観測されえます。劣化は崖ではなく連続的な坂で、1Mトークン級のモデルでも体感できる劣化は30〜40万トークンあたりから明確になるという報告があります。「窓が大きいモデルだから安心」は、容量と品質の混同です。

② 超単純なタスクですら劣化する。 Chromaの実験の巧妙な点は、「長い入力＝難しいタスク」という交絡を排除したことです。タスク難易度を固定して入力長だけを変えても劣化しました。「推論力の限界」ではなく、長さそれ自体が毒なのです。

③ 会話を重ねるほど悪化する構造がある。 長い会話には「訂正前の古い方針」「検討して捨てた案」「解決済みの話題」が蓄積し続けます。後述しますが、これらがまさに毒として働きます。たくさん議論した会話ほど賢くなっているはず、という直感と真逆のことが起きます。

なぜ・どうバカになるのか：4つの毒

「バカになる」の中身は1種類ではありません。4つの異なるメカニズムが複合しています。この切り分けが、対策を理解する鍵になります。

毒①：希釈（attention dilution）——単純に薄まる

第2回で説明した通り、attentionの重みはsoftmaxで計算され、合計が必ず1になります。トークンが増えるほど、1トークンあたりの取り分は数学的に必ず薄まります。1,000トークン時点で強く注目されていた情報が、10万トークンでは機能的に無視される水準まで薄まりえます。

症状：「さっき言ったよね？」が効かなくなる。序盤に伝えた重要な前提を、コンテキストには存在しているのに参照し損ねる。忘れたのではなく、注目の取り分が薄すぎて拾えない。

毒②：妨害（distractor interference）——似て非なるものに釣られる

Chromaの実験の最重要発見です。希釈だけでは説明できない劣化として、「正解に意味的に似ているが違う情報」（distractor）がコンテキストにあると、モデルは積極的にそちらに釣られることが示されました。distractorが1個あるだけで性能が落ち、4個ではさらに複合的に悪化しました。

症状：捨てたはずの案が突然復活する。旧方針と新方針を混ぜたハイブリッドな回答が出てくる。長い会話は試行錯誤の痕跡＝今の正解と意味的に似ているからこそ危険なゴミの密度が高く、これが毒として効き続けます。

毒③：散漫化（attention dispersion）——注目の解像度自体が壊れる

希釈がさらに進むと、質的に別の段階に入ります。コンテキストが長くなるほど、attentionの重み分布が全体的にのっぺりと均一化していくことが、attentionエントロピーの計測で示されています。「どこが重要か」のメリハリ自体が失われるのです。閾値まではなんとか保つが、超えると崩れ方が加速するという非線形性も報告されています。

症状：これが「全体的にぼんやりした返答になる」の正体です。特定の情報を取り違えるのではなく、回答全体の焦点が甘くなる。当たり障りのない一般論が増え、指示への追従が緩み、細部の詰めが雑になる。

毒④：干渉（proactive interference）——古い情報が新しい情報を邪魔する

2025年の研究で実証された、人間の記憶心理学と同名の現象です。先に入った情報が、後から入った関連情報の処理を妨害します。「Xの値は10」→（会話が進む）→「Xは25に変更」となったとき、古い「10」がコンテキストに物理的に残り続けるため、新しい「25」の定着を邪魔するのです。

症状：訂正したはずの誤りが復活する。「それさっき直したよね？」が起きる。人間の記憶は上書き保存ですが、LLMのコンテキストは全バージョンが並存したまま、どれを参照するかがattentionの綱引きで決まる。会話が長いほど古いバージョンの物量が増え、綱引きに負けやすくなります。

おまけの衝撃：綺麗な長文の方が毒性が高いことがある

Chromaの実験で最も直感に反する発見です。論理的に一貫した文書より、シャッフルされたバラバラの文書の方が、18モデル全てで成績が良かったのです。有力な解釈は、一貫した文脈は「もっともらしいdistractor」を大量に生む、というもの。内容が滑らかに繋がっているほど、間違い候補も滑らかに繋がって見えてしまう。「丁寧に書けば書くほど安全」とは限らない、という不気味な性質です。

毒	メカニズム	症状
①希釈	softmax予算の数学的な薄まり	序盤の前提を拾い損ねる
②妨害	似て非なる情報への誤誘導	捨てた案の復活、新旧方針の混合
③散漫化	注目分布ののっぺり化	回答全体の焦点が甘くなる、一般論化
④干渉	古い情報が新情報の処理を妨害	訂正したはずの誤りの再発

根本にあるのは「削除機能の不在」

4つの毒には共通の根っこがあります。LLMのコンテキストには**「さっきの無し！」ができないのです。人間は「その案は却下」と聞けば頭を切り替えられますが、LLMでは訂正は追記されるだけ**で、間違った情報も捨てた案も物理的に残り続け、attentionの予算を食い続けます。

これは必ず起きるのか？　構造的には不可避です。ただし進行速度は大きく変えられます。18モデル全てが劣化した通り、これは特定モデルのバグではなくTransformerという仕組みの性質です。しかし劣化は連続的な坂であり、進行速度は入力の質に強く依存します。ゴミが多いほど速く腐り、クリーンな入力なら同じトークン数でもずっと持ちます。老化と同じで、避けられないが生活習慣で進行は大きく変わる——これが正確なイメージです。

【重要な注意】「IDを指定して戻して」では戻らない

対策の前に、よくある誤解を1つ潰しておきます。

各返信にIDを振らせておいて（後述）、「R-014の時点まで戻って」とモデルに頼めばリセットできるのでは——と考えたくなりますが、戻りません。R-015以降の全情報は物理的にコンテキストに残り続けます。モデルは「戻ったつもりの演技」をするだけで、実際には腐ったコンテキストを全部抱えたままです。削除機能がないのだから、プロンプトでどう頼んでも削除は起きません。「忘れて」と頼んでも忘れられないのと同じです。

本物のリセットは、UIの編集機能（過去メッセージの編集・再送信）で、それ以降の履歴を物理的に切り落とす操作です。ChatGPTもClaudeも、過去の自分のメッセージを編集して送り直すと、それ以降の履歴が破棄された状態で再生成されます。「戻して」はUIでやるもの、モデルに頼むものではない——ここを混同すると、対策したつもりで対策できていない状態になります。

対処法：リセット系・予防系・監視系

4つの毒は全て「コンテキストに残り続けるものが悪さをする」という一点から発生しています。プロンプトの工夫は毒の効き方を緩和できても、毒そのものはコンテキストから除去できません。除去できるのは、コンテキストを物理的に編集できる立場——つまりUI操作か新セッションだけです。だから対策の本丸は「切る・移る・そもそも溜めない」に集約されます。対症療法はいろいろあるが、根治は切除しかない、という構造です。

【最重要原則】同じ話題は同じチャット、話題が変わったらチャットを変える

全ての対策の土台になる原則がこれです。理由は4つの毒から直接導けます。

別話題の履歴は、今の話題にとって100%ゴミ（毒①の希釈を無駄に進める）
しかも過去の話題は今の話題と意味的に似ていることが多い（だからこそ同じAIに聞いている）ので、distractor（毒②）として最悪の性質を持つ
話題Aでの決定事項が、話題Bの処理に干渉する（毒④）

「1つのチャットで何でも聞く」使い方は、毒を自分から盛り続ける行為です。逆に言えば、チャットの分割は最も簡単で最も効果的なContext Rot対策です。新しい話題を始めるとき、「新規チャットを開くひと手間」をかけるだけで、クリーンなコンテキストという最高の作業環境が手に入ります。

実践形：フェーズごとにチャットを切り、「成果物」だけを引き継ぐ

「話題が変わったらチャットを変える」と言われても、実務のプロジェクトでは「どこで話題が変わったことにするか」の線引きが意外と難しいものです。ここで使えるのが、開発プロセスのフェーズ構造をカットポイントにする運用です。

よく「学習フェーズ、要件定義フェーズ、とフェーズごとにかっちり進めるとよい」と言われますが、注意点があります。同じチャットの中で「ここから要件定義フェーズ」とラベルだけ切り替えていく運用では、Context Rotにはほぼ効きません。フェーズ見出しがランドマークとして多少の整理効果は持ちますが、前フェーズで検討して捨てた案も試行錯誤も全部物理的に残り続け、毒であり続けます。むしろフェーズが進むほど、前フェーズの大量の履歴がdistractor（毒②）として現在のフェーズに干渉してきます。

効くのは、フェーズの切り替わり＝チャットの切り替わりにする運用です。フェーズ構造には、単なる話題分割にない追加のボーナスがあります。フェーズの終わりには必ず成果物（要件定義書、設計書）が生まれることです。これがそのままcherry-pick／インクリメンタルセーブの受け皿になります。

要件定義フェーズのチャット → 成果物「要件定義書」を蒸留して確定 → 次のフェーズは新チャットで、会話履歴ではなく要件定義書だけを持って開始

引き継ぐのは「会話」ではなく「確定した成果物」。これで前フェーズの試行錯誤・捨て案・訂正の山（＝毒の本体）を一切持ち込まずに、結論だけをクリーンな環境に持ち込めます。ウォーターフォールの工程管理が、そのままContext Rot対策の設計図になっているという、綺麗な対応です。

実務でそのまま使えるプロンプトを2つ示します。フェーズの「出口」と「入口」でセットで使います。

プロンプト1：フェーズ終了時（成果物の蒸留）——現フェーズのチャットの最後に実行します。

このチャットでの要件定義フェーズを終了します。次の設計フェーズは新しいチャットで
開始するため、以下のルールで「フェーズ完了成果物」を出力してください。

# ルール
- 確定事項のみを含める。検討経緯・却下案・試行錯誤の過程は含めない
- 各項目は私が承認した文言をそのまま使う。あなたの解釈でまとめ直さない
- 各項目にIDを振る（REQ-001形式）
- 「確定していないこと」も別セクションとして明示する（未決事項の隠蔽が一番危険）

# 出力形式
## フェーズ完了成果物：要件定義
### 確定事項
REQ-001: ...
### 未決事項（次フェーズへの持ち越し）
OPEN-001: ...
### 前提・制約（このフェーズで判明したもの）
CONST-001: ...

プロンプト2：新フェーズ開始時（クリーンな引き継ぎ）——新チャットの最初に、プロンプト1の出力を貼り付けて実行します。

これから設計フェーズを開始します。以下は前フェーズ（要件定義）の完了成果物です。

# 引き継ぎルール
- この成果物に書かれていることだけを前提としてください
- 書かれていない背景・経緯を推測で補完しないでください。
  経緯が必要な場合は「REQ-XXXの決定経緯が必要」と私に質問してください
- 未決事項（OPEN-XXX)を確定事項のように扱わないでください

{ここにプロンプト1の出力を貼り付け}

まず、この成果物を読んで不明点・矛盾点があれば設計に入る前に指摘してください。

ポイントは3つあります。第一に、未決事項を明示させること。蒸留で一番危険なのは「決まっていないことが、書かれていないせいで決まったことのように扱われる」ことです。第二に、推測での補完を明示的に禁止すること。成果物に書かれていない経緯をモデルが勝手に創作するのを防ぎ、必要なら人間に質問させる回路を作ります。第三に、新フェーズの最初にレビューをさせること。クリーンなコンテキストは監査役としても最良の状態なので、設計に入る前に成果物自体の矛盾を検出させる一石二鳥です。

なお、フェーズ間で「成果物だけ」を引き継ぐということは、成果物に書かれていない暗黙の文脈（なぜその要件になったのかの経緯など）は毎回失われるということでもあります。これはこれで別の問題を生むのですが——それがまさに第5回で扱うContext Handoffのテーマです。

リセット系：腐ったら切る

①ブランチ切り（最善手）：会話の質が落ちてきたら、UIの編集機能で「腐る前の良かった地点」まで戻ってやり直す。Gitで言えばgit checkout <良かったcommit>してブランチを切る操作です。腐ったコンテキスト全体を一撃で物理的に捨てられる、事後リカバリの最速手段です。

このとき役立つのが返信IDです。会話の冒頭に仕込んでおきます。

これ以降、あなたの各返信の冒頭に [R-001] から始まる連番IDを付けてください。

IDの役割は「削除」ではなく「座標系」です。「R-014の方針で進めて」とピンポイント参照でき（曖昧な「さっきの案で」より遥かに混線しにくい）、腐敗が始まった地点を「R-020あたりからおかしい」と座標で特定でき、どこまで戻ってブランチを切ればいいかが一目でわかります。

②cherry-pick付きリセット：ブランチ切りの弱点は、戻った地点以降に得た「良い学び」も一緒に捨ててしまうことです。そこで、切る前に一手間かけます。

この会話で確定した結論・決定事項だけを箇条書きで出してください。
試行錯誤の過程や却下された案は含めないでください。

この蒸留物だけを持ってブランチ先（または新チャット)に移る。Gitで言えばcheckoutではなく**cherry-pick（良いcommitだけ拾って移植）**です。なお、Claude CodeなどのAIエージェント製品が実装している「コンパクション」（会話を要約して新しいコンテキストで再出発する機能）は、まさにこの操作の自動化版です。

予防系：そもそも溜めない・腐る前に保存する

③インクリメンタルセーブ：ここに重要な罠があります。「会話の最後にまとめて要約させて保存すればいい」と考えがちですが、腐った状態のモデルに要約させると、腐敗ごと圧縮されます。要約は「何が重要か」の判断をモデルに委ねる操作であり、ロットが進んだモデルはまさにその判断力が落ちています。混線した情報が混線したまま「確定事項」として書き出され、しかも圧縮によって「これは怪しい」と気づく手がかりの原文すら消える。腐った要約だけ持って移住したら、遡る先がないのです。

対策は、セーブを「腐ってから一括」ではなく「腐る前から都度」やること。決定が確定したその瞬間に記録させます。

今の結論を「DECISION-007: <内容>」の形式で記録してください。
あなたの解釈でまとめ直すのは禁止。私が承認した文言をそのまま使ってください。

各セーブデータがその時点の（まだ腐っていない）コンテキストで生成されるため、会話末尾の腐敗の影響を受けません。ゲームで言えば、ラスボス直前で一回だけセーブするのではなく、各ステージクリアごとにオートセーブする設計です。ポイントは要約（モデルの再解釈）ではなく原文の引用+IDにすること。モデルの言い換えは腐敗の混入点になります。

④用語統一（CONST）を冒頭から：同じ概念を「移行対象」「対象資産」「移行スコープ」と揺れた表現で呼んでいると、ロットが進んだときにモデルがこれらを別概念として扱ったり、逆に別概念を混同したりする温床になります。第2回で紹介したJSON CONST（用語定義体）を会話の冒頭に固定しておくことは、腐敗の進行速度を遅らせる予防としても機能します。腐敗は「曖昧さ」のある場所から進行するからです。

⑤ゴミを最初から入れない：長いログやエラー全文を毎回貼り続けない。要点だけ貼る。捨てた案は「この案は捨てた」と一行で済ませる。Anthropicのエンジニアリング指針でも、詳細な探索をサブエージェントに隔離し、本体には1,000〜2,000トークン程度に蒸留した要約だけを返す設計が、複雑なタスクの成績を大きく改善したと報告されています。

監視系：腐り始めを検知する

腐敗のサインは具体的です。同じ説明を繰り返し始める・以前訂正したはずの誤りが復活する・指示したフォーマットが崩れ始める——これらは毒②④が効き始めた症状です。第2回のチェックポイント機構（ID+反映内容の記載）を長い会話に適用しておけば、チェックポイントの通過率が落ち始めた地点＝腐敗の開始点として、データでも検知できます。

手遅れの場合：腐った要約は「監査対象」として扱う

インクリメンタルセーブを仕込んでいなかった、もう腐っている、ブランチも切れない——という最悪ケースでは、第1回の道具がそのまま使えます。吐き出させた引き継ぎメモを、新しいクリーンなセッションに「批判的再鑑者」としてレビューさせるのです。

この引き継ぎメモには、矛盾・重複・未解決のまま確定扱いされている項目が
混入している可能性があります。項目ごとに、相互矛盾がないか、根拠が
明記されているかを点検し、疑わしい項目にフラグを立ててください。

腐った要約を作ったのと同じコンテキストに検証させても意味がありません（自分の腐敗は自分で見えない——第1回で見た通りです）。クリーンな新セッションを監査役に使うのがポイントです。フラグが立った項目だけ人間が原会話を遡って確認すれば、全部読み直すよりずっと安く済みます。

まとめ

会話が長引くほどAIの品質が落ちるのは気のせいではなく、18モデル全てで確認された測定可能な現象（Context Rot）
劣化はコンテキストウィンドウの限界よりずっと手前から、連続的に始まる
正体は4つの毒の複合：希釈（取り分が薄まる）・妨害（似て非なる情報に釣られる）・散漫化（焦点のメリハリが壊れる）・干渉（古い情報が新情報を邪魔する）
根本原因は削除機能の不在。訂正は追記されるだけで、ゴミは残り続ける
だから対策の本丸は「切る・移る・溜めない」。プロンプトで「戻して」と頼んでも戻らない。物理的なリセットはUI操作でしかできない
最重要原則：同じ話題は同じチャット、話題が変わったらチャットを変える
実践形はフェーズごとにチャットを切り、会話ではなく「確定した成果物」だけを次フェーズに引き継ぐ運用。同一チャット内のフェーズラベル切り替えだけでは効かない
長期戦には、返信ID（座標系）＋インクリメンタルセーブ（腐る前の都度保存・原文引用）＋用語CONST（腐敗の減速）＋cherry-pick型リセット
手遅れの要約は信用せず、クリーンな新セッションに監査させてから使う

次回は、AIが「あなたの言う通りです！」と間違った方向に全力で同意してくる現象、Sycophancy（迎合） を扱います。壁打ち相手としてAIを使っている人ほど、静かに蝕まれているやつです👀

参考文献

Hong, K., Troynikov, A., & Huber, J. (2025). Context Rot: How Increasing Input Tokens Impacts LLM Performance. Chroma Technical Report.
Liu, N. F., et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. TACL.
Anthropic (2025). Effective context engineering for AI agents.