Claude Codeが長時間作業で崩れる理由と/compactの使いどころ
※本記事にはプロモーション（広告・アフィリエイトリンク）を含みます。
Claude Code で大きめの改修を続けていると、途中から指示が通らなくなったり、さっき決めた方針を忘れたように振る舞ったりする。これは「長時間作業でコンテキストが崩れる」典型的な症状です。
この記事は、なぜ崩れるのかを公開情報と観測できる挙動から整理し、/compact をどこで使うと効くのかを判断できるようにするためのものです。体験談ではなく、根拠と限界を明示して論じます。
なぜ長時間作業でClaude Codeは崩れるのか
Claude Code は会話履歴・読み込んだファイル・ツール実行結果をすべて「コンテキスト」に積み上げていきます。モデルのコンテキストウィンドウには上限があります（公式ドキュメントによると、執筆時点のClaudeモデルは20万トークン級。ただしプランやモデルで異なり、変動します）。長時間作業では次の要因が重なります。
- ファイルの全読み・grep結果・ビルドログなど、1回のツール実行で数千トークン単位が積まれる
- 上限に近づくと自動圧縮（auto-compact）が走り、過去のやりとりが要約に置き換わる
- 要約は情報の間引きなので、初期に決めた前提・命名規則・却下した案などのディテールが落ちる
崩れの正体は「メモリ不足でクラッシュ」ではなく、この要約による情報の欠落だと考えられます。原理上、履歴が長くなるほど古い決定ほど要約に飲み込まれやすい。だから「崩れる前提でコンテキストを能動的に管理する」ことが対処になります。
/compact・/clear・auto-compactの違い
混同されやすい3つを整理します。
| 操作 | 何をするか | 履歴の扱い | 使う場面 |
|---|---|---|---|
/compact |
会話を要約に圧縮して継続 | 要約として残る | 続けたいが文脈が重い |
/compact <指示> |
残す観点を指定して圧縮 | 指定した点を優先的に残す | 重要な前提を守りたい |
/clear |
コンテキストを消去 | 消える | 別タスクへ切り替える |
| auto-compact | 上限接近で自動的に圧縮 | 要約として残る | 明示操作なしで発生 |
ポイントは /compact に指示を添えられることです。たとえば /compact 現在の実装方針と未解決のバグだけ残して のように、要約で何を優先させるかを渡せます。ここが自動圧縮との決定的な違いで、auto-compact ではタイミングも内容も選べません。書式や挙動はバージョンで変わりうるため、手元の /help で最新を確認してください（環境によって異なります）。
/compactの使いどころ
手動 /compact の狙いは「崩れる前に、自分の都合の良い区切りで要約させる」ことです。具体的な判断基準を挙げます。
- コンテキスト残量の表示が減ってきた（自動圧縮が走る前に、先回りする）
- 1つのサブタスクが終わり、次に移る直前
- 大きなファイルやログを読ませた直後で、それがもう不要になったとき
- 方針が固まった時点。以後は結論だけ残せば十分なとき
逆に避けたい場面もあります。デバッグの最中で、直前のエラー全文やスタックトレースが判断材料になっているときに圧縮すると、その詳細が要約で落ちて堂々巡りになりやすい。切りが悪いところでは圧縮しない、が原則です。
そもそもタスク単位で切れるなら、別セッションに分けて /clear する方が確実なこともあります。参考までに、筆者は記事生成を claude -p を Python の subprocess から呼び出して1本ずつ独立実行し、バッチ化しています。これは1タスク1プロセスにすることで、コンテキストが積み上がらない構成です。長い対話を1本で回すより、切れるものは切る方が崩れにくいと考えられます。
崩れにくくする運用
圧縮テクニック以前に、「要約されても困らない状態」を先に作っておくと復帰コストが下がります。
- CLAUDE.md に前提を書く: 命名規則・使う技術・やってはいけないことを常設で持たせる。圧縮で会話から消えても、再読込される情報に寄せておく。
- 1セッション1目的: 無関係なタスクを同じセッションに混ぜない。切り替えは
/clear。 - 参照は都度読む前提で: 「さっき読んだあのファイル」に依存しない。必要なら読み直させる。
- 確認作業はフックに逃がす: 毎回の定型チェックをコンテキストに積まず、仕組み側に持たせる。フックが動かないときはClaude Code PostToolUse フックが動かない：ログ確認とデバッグの手順を参照。
これらは崩れを完全には防げませんが、崩れたときに「何が失われたか」を最小化する発想です。
まとめ
長時間作業でClaude Codeが崩れるのは、コンテキスト上限に対する自動要約で情報が間引かれるためだと考えられます。対策は、自動圧縮に任せきりにせず、サブタスクの区切りで自分から /compact（必要なら残す観点を指示）を打ち、切れるタスクは /clear か別セッションに分けること。まず次のセッションから、キリの良いところで手動 /compact を1回入れる運用を試してみてください。なお、挙動やコンテキスト上限は執筆時点の情報で、バージョンにより変わります。
よくある質問
/compactと/clearはどう使い分ける？
作業を続けたいが文脈が重いときは要約して継続する/compact、別タスクに切り替えるときは履歴を消す/clearが基本です。同一目的の続きなら/compact、目的が変わるなら/clearと考えると分けやすいです。
auto-compactがあるなら手動/compactは不要では？
自動圧縮はタイミングも要約内容も選べません。手動/compactなら区切りの良い所で、かつ残す観点を指示して圧縮できます。デバッグ中の重要ログを守りたい場面などで差が出ます。
/compactすると何が失われる？
会話履歴が要約に置き換わるため、初期に決めた前提や却下案、エラー全文などのディテールが落ちやすいと考えられます。重要な前提はCLAUDE.mdなど再読込される場所に書いておくと安全です。
コンテキストの上限はどれくらい？
公式ドキュメントによると執筆時点のClaudeモデルは20万トークン級ですが、プランやモデルで異なり変動します。正確な値と最新の挙動は公式ドキュメントで確認してください。