Claude Codeを/clearせず9時間動かした日、コンテキストはどこで腐り始めたのか

ある日、Claude Codeを朝から晩まで、/clearを一度も押さずに使い続けました。9時間です。一つのセッションで、リファクタからテスト追加、ドキュメント更新まで全部やろうとしました。

夕方になって、様子がおかしくなりました。CLAUDE.mdに「テストはvitestで書く」と明記してあるのに、jestで書き始める。午前中に「この関数はもう使っていないから消した」と合意したはずの関数を、夕方には「念のため残しておきましょう」と復活させようとする。同じファイルを3回読み直す。

最初、私は「今日のClaudeは調子が悪いな」と思いました。これが間違いでした。調子が悪かったのはモデルではなく、9時間ぶん膨れ上がった私のコンテキストのほうです。

この現象には名前がついています。context rot(コンテキストの腐敗)です。

context rotは「ウィンドウが満杯になる前」に始まる

context rotという言葉を形式化したのは、Chromaが2025年に出した研究です。18の最前線モデルを系統的にテストし、入力が長くなるほど全モデルの出力品質が下がることを示しました。例外はゼロです。重要なのはここで、200Kトークンのウィンドウを持つモデルでも、5万トークンあたりで目に見えて劣化が始まるという点です。

つまり「ウィンドウに入るかどうか」と「ちゃんと使えるかどうか」は別の問題でした。私はずっと前者しか気にしていませんでした。「まだ半分も埋まってないから大丈夫」は、まったく根拠のない安心だったわけです。

この発見の源流は、2023年のLiuらの論文Lost in the Middleです。コンテキストが埋まってくると、モデルは入力の先頭と末尾のトークンを重視し、真ん中のトークンが「迷子」になる。私の9時間セッションでは、午前中の決定事項がちょうど真ん中に沈んでいました。だから夕方のClaudeは、午前中の自分を覚えていなかったのです。

ある調査では、2025年のエンタープライズAI障害の約65%が、複数ステップ推論の途中で起きたコンテキストのドリフトや記憶喪失に帰着するとされています。これはモデルが賢くないからではありません。長くなったコンテキストを賢く使えていないからです。

私のセッションで起きた4つの症状

拙著のContext Engineeringの本では、長期対話で起きる障害を4つのモードに分けています。9時間セッションで、私はその4つを順番に踏み抜きました。

1. Context Distraction(散漫)。 無関係な情報が増えすぎて焦点がぼける。午後のClaudeは、午前中に一度だけ読んだ設定ファイルの細部を延々と気にしていました。もうどうでもいい話なのに。

2. Context Confusion(混乱)。 リファクタとテストとドキュメントを1セッションに混ぜたせいで、複数のトピックが混在し、文脈を取り違える。テストの話をしているのにドキュメントの口調で返事が来る、という珍事が起きました。

3. Context Clash(衝突)。 矛盾する情報が共存する。「関数を消す」と「関数を残す」が同じウィンドウに同居して、回答が不安定になりました。

4. Context Poisoning(汚染)。 序盤に紛れた一つの誤解が、以降の回答をじわじわ歪めていく。これが一番こわい。一度ハルシネーションした前提を、本人は「確定事項」として扱い続けます。

新人に例えるなら、朝礼から残業まで一度も席を立たず、メモも取らず、休憩もせずに働かせ続けた状態です。夕方に判断が雑になるのは、その人が無能だからではありません。

圧縮が走るのが遅すぎる問題

ここで運用の落とし穴があります。Claude Codeにはauto-compactという自動圧縮機能があり、コンテキストが約95%(残り25%前後)に達したときに発動します。2026年初頭にはバッファが約33Kトークンに調整されました。

問題は、劣化が始まるのが50K付近なのに、圧縮が走るのが190K付近だということです。腐り始めてから圧縮までに、広大な「すでに性能が落ちているのに何もしていない」ゾーンが横たわっています。私の9時間セッションは、ずっとこのゾーンを走っていました。

Claude CodeチームのThariq Shihipar氏は、容量の50〜60%で能動的に/compactを打つことを勧めています。auto-compactを待つのは/compactの使い方として間違っている、と。私はずっと間違って使っていました。「自動でやってくれるなら任せよう」と。任せた結果が、jestで書き始めるClaudeでした。

/clearと/compactは別物です。/clearは会話履歴を完全に消して新品の状態に戻す。/compactは会話を要約して、その要約を新しいコンテキストとしてプリロードする。重要なコード変更やファイルの状態、決定事項は残り、中間のデバッグ出力や解決済みの議論は刈り取られます。

では、どう運用するか

9時間セッションの反省から、私のいまの運用はこうなりました。

対策	やること	効きどころ
タスクで区切る	リファクタ・テスト・ドキュメントを別セッションに分ける	Confusion(混乱)を断つ
50〜60%で先回りcompact	auto-compactを待たず、能動的に/compactを打つ	劣化ゾーンに入る前に圧縮
節目で/clear	タスクが完全に切り替わるときは要約より全消し	Poisoning(汚染)を断ち切る
CLAUDE.md再読込	長いセッションでは「CLAUDE.mdをもう一度読んで」と明示	真ん中に沈んだ規約を末尾に持ち上げる
サブエージェント委譲	調査や一括処理は別エージェントに切り出す	メインのウィンドウを汚さない

一番効いたのは、実は一番単純な「タスクで区切る」でした。1セッション1目的。これだけで、夕方のjest事件は起きなくなりました。

「真ん中に沈んだ規約を末尾に持ち上げる」というのも地味に効きます。Lost in the Middleが先頭と末尾を重視するなら、大事な規約を末尾に置き直せばいい。CLAUDE.mdの再読込は、まさにそれをやっています。

まとめ: 「まだ埋まってない」は安心材料ではない

9時間セッションが私に教えたのは、context rotはウィンドウが満杯になってから起きるのではない、ということです。Chromaの計測では50K付近、つまりウィンドウの4分の1で、もう劣化は始まっています。

そして次のアクションは拍子抜けするほど簡単です。長いセッションで「あれ、雑になったな」と感じたら、まず自分を疑う前にコンテキストを疑う。 そして/compactを打つか、いっそ/clearして、CLAUDE.mdから入り直す。モデルが急に賢くなったように見えるはずです。賢くなったのではなく、見ているものが綺麗になっただけですが。

腐るのはモデルではなく、こちらが渡し続けたコンテキストのほうでした。

---

5戦略、RAG実装、動的コンテキスト選択、Memory設計までを通しで扱った LLM を「嘘つき」から「専門家」へ変える Context Engineering 実践ガイド を Zenn と Kindle で公開しています。本記事で触れた4つの障害モードとメモリアーキテクチャは、同書の第9章にあたります。