Claude Code を長時間使っていると、コンテキストが溜まって精度が落ちる。そのとき多くの人が頼る /compact、実はこれ自体が精度低下の原因になっている可能性がある。見えないところで何が起きているのか、毎日使い倒して気づいたことを共有します。
コンテキストが溜まると、何が起きるか
Claude Code にはコンテキストウィンドウの上限がある。会話が長くなるほど古い情報への注意が薄れて、「さっき言ったのに忘れてる」が増える。いわゆる「lost in the middle」問題で、真ん中あたりに埋もれた情報ほど拾われにくくなる。
自分の場合、特に影響が出やすかったのがルールの遵守だった。CLAUDE.md にトーンや禁止事項を細かく書いているんだけど、セッション冒頭では完璧に守っていたルールが、コンテキスト使用率70%を超えたあたりから抜け始める。返答の口調が変わったり、禁止パターンをうっかり出してきたり。
ここで選択肢が2つ出てくる。/compact で会話を圧縮して続けるか、ハンドオフメモを書いて /clear で仕切り直すか。
/compact が裏でやっていること
/compact は会話履歴をモデルに要約させて短くするコマンド。公式ドキュメントでも推奨されていて、60%くらいの段階で先手を打つのが定石とされている。一見「コンテキストを整理してくれる便利機能」に見える。
ただ、毎日使い込んでいて気づいたのは、compact は整理しているんじゃなくて、壊しているということだった。
何を捨てたか、誰にもわからない。
compact は会話を要約するけど、何を残して何を捨てたかの判断はモデル任せ。自分にとって重要だった設計判断の理由、微妙なニュアンスの合意、「こっちじゃなくてこっちにした」という経緯——こういう情報が、気づかないうちに消えている。/compact Focus on the API changes のように指示を添えることもできるけど、「何が消えたか」を確認する方法は存在しない。消えたことにすら気づけないのが怖いところで、compact 後に「さっき決めたよね？」が通じなくなるのはこれが原因。
使うたびに劣化が加速する。
compact を2回かけると、1回目の要約をさらに圧縮する「要約の要約」になる。情報は圧縮するたびに丸くなっていく。具体的な数値が「おおよその値」になり、判断の理由が「方針として決定済み」に化ける。3回目にはもう元の文脈は跡形もない。これは復元できない不可逆な劣化で、セッションが長くなるほどダメージが蓄積していく。
compact chain loop——セッションが死ぬ瞬間。
一番厄介なのがこれ。compact 直後にプロンプトキャッシュの再構築で大量のトークンが発生し、すぐにまた compact が必要になるループに入ることがある。実測では10分で3連鎖したケースがあった。こうなるとセッション自体が使い物にならない。新しい作業はほぼ進まず、compact の生成と再発火だけでトークンが消えていく。自分はこれで半日分の作業を丸ごとやり直した。
compact は「コンテキストを救う」ように見えて、実は静かに品質を削っている。それも、使っている本人が劣化に気づきにくい形で。「なんか最近 Claude の精度落ちたな」と感じたことがある人は、一度 compact の回数を疑ってみてほしい。
handoff→clear が精度で勝つ理由
もう一つの選択肢は、一旦手を止めてハンドオフメモを書き、/clear で完全にリセットする方法。
ハンドオフメモには「何が終わって、何が途中で、次に何をすべきか」を自分の言葉で書く。compact との最大の違いは、引き継ぐ情報を自分で取捨選択できるということ。モデルが勝手に要約するのではなく、本当に必要な文脈だけを残せる。
/clear 後は CLAUDE.md やルールファイルがフルで再ロードされる。セッション冒頭と同じクリーンな状態で、ハンドオフメモという厳選されたコンテキストだけを持って再開できる。ルールの遵守率が元に戻るのは、この「フルリロード」のおかげ。
しかもメモはファイルとして残るから、翌日でも翌週でも同じ精度で再開できる。compact の圧縮結果はそのセッション限りで消えるのとは対照的。
/clear しても「決めごと」は消えない
「/clear したら全部消えるのが怖い」——これが compact に頼りがちになる一番の理由だと思う。でも実際には、消えるのは生の会話ログだけ。セッション中に決めたこと、蓄積したルール、判断の経緯は、ファイルに書いておけば /clear しても残る。
Claude Code には会話ログとは別に、セッションをまたいで生き残る「永続レイヤー」がいくつかある。
CLAUDE.md——プロジェクトのルートに置くファイルで、毎セッション冒頭に自動で読み込まれる。コード規約、命名ルール、禁止事項、ワークフローの決まりごとなど、「毎回伝え直したくないこと」はここに書いておけば /clear しても消えない。/init コマンドで雛形が作れる。
メモリファイル（.claude/memory/）——Claude Code の auto memory 機能を使えば、セッション中の判断や学びを自動的にファイルへ蓄積できる。「この設計にした理由」「このライブラリを選んだ経緯」「この書き方はNGだった」といった文脈が、次のセッションでも参照される。
ハンドオフメモ——セッションの区切りに書く引き継ぎファイル。完了したこと、途中のこと、次にやることを数千字で残せる。「前回のメモ読んで」の一言で、新しいセッションにそのまま文脈が引き継がれる。
つまり、この3つを使えば /clear 後の再開で失うものはほぼない。compact が「溜まった会話をモデルに圧縮させる」のに対して、handoff→clear は「重要なことだけ自分で永続レイヤーに移してから、会話をゼロにする」という発想。決めごとを会話の中に閉じ込めず、ファイルという安全な場所に逃がしておくのがポイントになる。
使い分けの判断表
とはいえ、毎回 handoff→clear するのは手間がかかる。現実的にはこう使い分けている。
| 状況 | 判断 |
|---|---|
| あと1-2ターンで区切れる | そのまま走り切る（compact 1回まで許容） |
| まだ先が長い / 実装の途中 | handoff→clear |
| compact が既に1回走った | 即 handoff→clear（2回目は精度崩壊ライン） |
ハンドオフメモに書くのは最低限3つだけ。
- 完了したこと——検証済みか未検証かを明記する
- 着手中のこと——どこまで進んだか
- 次にやること——1つだけ書く。迷わせない
CLAUDE.md に /init で基本設定を書いておけば、再開時に「前回のメモ読んで続きやって」の一言で文脈が戻る。最初のセットアップだけ少し手間はかかるけど、一度作れば毎回のハンドオフは5分もかからない。
「何を捨てるか」を自分で決める
compact は便利なコマンドだし、短いセッションなら問題ない。ただ、精度を安定させたいなら handoff→clear の方が確実だった。理由はシンプルで、「何を捨てるか」を自分でコントロールできるから。
あと1-2ターンで終わるなら走り切る。まだ先があるなら、面倒でもメモを書いて仕切り直す。compact が2回走ったら、もう迷わず /clear。
コンテキスト管理は地味だけど、Claude Code を長く安定して使うための土台になる。手間をかけた分だけ、ちゃんと返ってくる部分だと思う。