7月14日、Towards Data Scienceが「Context Rot: Why Claude Code Sessions Decay, and How to Govern Them」と題した記事を公開した。Claude Codeを使い込んでいると、セッション開始直後は的確だった応答が時間とともにズレていく——この現象には名前がある。Context Rot（コンテキストの腐敗）だ。記事はその構造的な原因を解剖し、ユーザーがコントロールできる対処法を具体的に示している。

Context Rotの2種類の原因

記事はContext Rotを2つのカテゴリに分類する。

1. Intrinsic Rot（内在的腐敗）：モデルのアーキテクチャに起因する、避けようのない性能の限界。

2. Content Rot（コンテンツ腐敗）：セッション中に蓄積される、古い・誤った・矛盾した情報。こちらはユーザーがコントロールできる。

なぜモデルは「忘れる」のか

LLMはターンをまたいで内部状態を保持しない。毎回、セッション全体（プロンプト、レスポンス、ファイル読み込み、ツール出力）を1本のトークン列として処理し直す。アテンション機構がこの処理の核心だが、そこには構造的な制約がある。

アテンションのスコアはsoftmax関数を通過する。softmaxはスコアの合計を1に強制するため、注意の予算は固定だ。そして「どのトークンのシェアも正確にゼロにはなれない」という性質がある。つまり、無関係なコンテキストは無料ではない。関係のないトークンであっても、常に注意の予算を奪い続ける。

さらに位置の影響も大きい。長いコンテキスト上での情報の検索精度はU字型を描くことが知られている（Liu et al., 2024）。先頭と末尾は精度が高く、中間部が最も低い。数時間にわたるセッションでは、実際の作業内容のほとんどがこの「危険な中間部」に埋まる（詳細な引用は元記事を参照）。

記事が強調するのは、「コンテキスト上限に達するまでは安全」という思い込みは危険という点だ。劣化は上限の手前から徐々に始まる。

Content Rotの4つの失敗パターン

記事はDrew Breunigによる分類を元に、コーディングセッションで起きる具体的な失敗を4つ挙げる。

1. スコープへの過剰ロード（混乱）
MCPサーバーやスキルを大量に有効化すると、ツール選択の精度が下がる（Kate et al., 2025）。使っていないツールの定義でさえ、毎ターンアテンション予算を消費し続ける。対応する対処法は「不要なMCP/スキルの無効化」だ（後述）。

2. デバッグの迷走が「定説」になる（衝突）
モデルは早期に形成した仮説に固執する傾向がある。間違った診断を指摘しても、新しい観察をその仮説に合わせて曲解しようとする。一度に渡せば解けるタスクを、同じ情報がターンをまたいで断片的に届くと失敗する、という測定結果もある（Laban et al., 2025）。このパターンへの対処は、定期的なゴールのリフレッシュだ（後述）。

3. 広い検索が「それらしいもの」を引き込む（気散り）
agentがgrepで広範囲を検索すると、テストフィクスチャ、廃棄実装、似た名前の別モジュールの関数が一緒に入り込む。モデルはコンテキストをオプションの参考資料として扱わず、無関係であっても確実に取り込む（Shi et al., 2023）。関係のある囮が1つあるだけで、性能が測定可能なレベルで落ちる（Mirzadeh et al., 2024）。このパターンへの対処は、ファイルの直接指定だ（後述）。

4. 誤情報が「真実」として定着する（汚染）
長期タスクでagentがNOTES.mdに記録した内容が間違っていた場合、チャットで訂正してもファイル自体は更新されない。その後ファイルが再読み込みされると、古い誤情報が復活する。モデルが書いたノートは証拠ではなく、未検証の主張だ。

そして最も厄介なのは、これら4つが連鎖する点だ。誤ったノートが不要な検索を引き起こし、検索が紛らわしいコードを引き込み、それが新たな誤診断を生む。しかもモデルは劣化しながらも自信満々に見える。外部からの監視がなければ、出力が壊れるまで気づけない。

実践的な対処法

上記の4パターンを踏まえて、記事はClaude Codeを前提とした具体的なプラクティスを紹介している。

セッション開始前の整備

• CLAUDE.mdは「新入りエンジニアが初日に最低限読むべきもの」として書く。コードを読めばわかることは書かない。/initで雛形を作り、徹底的に削る。これは「汚染」パターンに対する予防策だ。
• 常時ロードするコンテキストはミニマルかつ高品質に保つ。汎用知識はモデル自身が持っているので書かない。
• /mcpや/skillsで、今のタスクに不要なサーバー・スキルは無効化する。「混乱」パターン——ツール過剰ロードによる選択精度の低下——への直接的な対処だ。
• 関連ファイルがわかっているなら@path/to/fileで直接指定する。agentに広範な検索をさせないことで「気散り」パターンを抑制する。
• 複数ファイルにまたがる作業は/planでプランを立ててから着手する。

作業中のクリーンアップ

長いコンテキストの中間部はモデルの想起精度が最も低い。長期タスクでは定期的に目標をリフレッシュし、仮説の固着（「衝突」パターン）が進行していないかを意識的に確認する。agentが書いた中間ノートは随時レビューし、誤記があればファイル自体を更新する習慣をつける。

記事の結論は明快だ：コンテキストはストレージではなく、アクティブな入力だ。 セッションに何を入れるかは、書くコードと同じくらい慎重に選ぶべきだ。

詳細はContext Rot: Why Claude Code Sessions Decay, and How to Govern Themを参照していただきたい。