Claude Codeのコンテキストが壊れた時の復旧 — /clear・/compact・/rewindの使い分け

結論

なぜコンテキストが壊れるのか?

Claude Codeにとって、いま開いている会話(コンテキスト)は最も重要な資源です。モデルはその時点でウィンドウに載っている情報だけを見て次の一手を決めるので、ここが汚れると判断が崩れます。

汚れ方には典型パターンがあります。

• 無関係なタスクの混在: 1つのセッションでAの実装、Bの調査、Cのデバッグを次々やると、古い話題の残骸が新しい指示の邪魔をします。
• 失敗ログの蓄積: 同じエラーを何度も貼り、何度も失敗した試行が履歴に積もると、モデルは「うまくいかない前提」を学習したように振る舞います。
• 指示の上書き合戦: 「やっぱりこうして」を繰り返すと、初期の指示と矛盾する指示が同居し、どれを優先すべきか曖昧になります。

ここで多くの人がやりがちなのが、効かない指示をさらに強く言い直すことです。しかし汚染が原因の場合、積み増しは逆効果です。誤った文脈が残ったまま新しい指示が足されるので、机の上の散らかった資料がさらに増えるだけになります。

/clear・/compact・/rewind は何を消して何を残すのか?

3つはどれも「コンテキストを整える」コマンドですが、消す対象がまったく違います。ここを取り違えると、残したかった文脈まで失います。

それぞれの挙動を、もう少し具体的に見ていきます。

/clear — まっさらに戻す

/clear は現在の会話履歴を破棄し、ほぼ新規セッションの状態に戻します。前のタスクの文脈は引き継がれません。

/clear

無関係なタスクへ移るときの基本です。「さっきのデバッグの残り香」を完全に断ちたいときに使います。プロジェクトのファイルや設定(CLAUDE.md など)は消えませんが、会話で積み上げた一時的な合意事項は消えるので、必要なら次の指示で改めて伝えます。

/compact — 要点を残して圧縮する

/compact は履歴を捨てずに要約へ圧縮し、文脈の要点を残します。同じ作業を続けたいが履歴が重くなってきた、というときに向きます。

/compact 認証まわりの実装方針と未解決のテスト失敗だけ残して

このように指示を添えると、何を要点として残すかを誘導できます。ただし圧縮は情報の取捨選択なので、細部は落ちます。失敗ループの最中に /compact すると、失敗の記憶ごと要約に残ってしまうことがある点に注意してください。汚染を断ち切りたい局面では /clear の方が確実です。

/rewind — 時間を巻き戻す

/rewind(Esc を二回)は、会話とコードをチェックポイント時点へ巻き戻します。戻す対象は「会話だけ」「コードだけ」「両方」から選べます。

直前のやり取りで意図しないファイル変更を入れられた、説明が脱線して破綻した、というときに、その手前の健全な地点へ戻せます。/clear が全消去なのに対し、/rewind は「どこまで戻すか」を選べるのが違いです。

症状別にどれを選ぶ?

迷ったら症状から逆引きするのが速いです。残したい文脈がどれだけあるかで決まります。

• 無関係なタスクが混ざってきた → /clear。前タスクの残骸を断ち切り、新しい机で始めます。
• 同じ失敗を3回ループしている → /clear してから要件を整理して出し直し。/compact は失敗の文脈を要約に残すので、汚染除去には不向きです。
• 続きの作業だが履歴が重い・薄めたい → /compact。要点を残して圧縮します。
• 直前の操作でコードや会話を壊された → /rewind。壊れる前の地点へ巻き戻します。

# 例: 無関係な調査が混ざった後、本実装に戻る
/clear
次は決済モジュールの実装に入る。CLAUDE.md の規約に従って…

要は、捨てるか・残すか・戻すか の3択です。捨てたいなら /clear、残したいなら /compact、時間を戻したいなら /rewind と覚えると間違えません。

壊さないための予防策は?

復旧コマンドはあくまで対症療法です。汚染を起こしにくい運用にしておくと、そもそも立て直しの回数が減ります。

調査はサブエージェントに逃がす。 「このライブラリの使い方を調べて」「このバグの原因箇所を特定して」といった探索作業は、結果だけ要約して戻る形にすると、本流のコンテキストに大量のログが流れ込みません。詳しくは Claude Codeのサブエージェント を参照してください。

タスクの切れ目で /clear する。 1つの機能が終わったら、次に進む前に一度机を片付けます。これだけで「前タスクの残骸が次の判断を狂わせる」事故が大きく減ります。

指示は積み増さず、出し直す。 言い直しを重ねるより、要件をいったん整理して1つのまとまった指示に書き直す方が、モデルにとって読みやすく汚染も少なくなります。

チェックポイントは git の代わりではない。 /rewind のチェックポイントは、そのセッション内で Claudeが加えた変更 を戻すための仕組みです。あなたが手動で編集したファイルや、セッションをまたいだ永続的な履歴は対象外です。確定させたい変更は必ず git でコミットしてください。チェックポイントをバージョン管理の代替にしてはいけません。

コンテキストの上手な使い方は、コストや速度にも直結します。送る情報を絞る考え方は APIコスト高騰を防ぐコンテキスト管理 でも整理しています。

よくある質問

/clearと/compactの違いは何ですか?

/clear は会話履歴を完全に消して新規セッション同然に戻します。/compact は履歴を要約に圧縮して文脈の要点だけ残します。無関係な話題を捨てたいなら /clear、続きの作業で要点を保ちたいなら /compact です。

Claude Codeが同じ失敗を繰り返す時はどうすればいいですか?

2回直して直らなければコンテキスト汚染を疑います。指示を積み増すほど誤った文脈が増えて悪化しやすいので、/clear で履歴を捨て、要件を整理して出し直すのが結局速いです。

/rewind(Esc二回)は何を戻せますか?

会話だけ、コードだけ、その両方を、過去のチェックポイント時点に戻せます。直前のやり取りでファイルを壊された時に、その前の地点へ巻き戻す用途に向きます。

チェックポイントはgitの代わりになりますか?

なりません。チェックポイントはそのセッション内でClaudeが加えた変更を戻すための仕組みで、手動編集や永続的な履歴は対象外です。確定したい変更は必ず git でコミットしてください。

関連記事

• APIコスト高騰を防ぐコンテキスト管理と節約設計
• Claude Code公式ベストプラクティス要点まとめ
• AIエージェント運用でよくある5つの失敗
• Claude Codeのサブエージェント活用