Claude Code の /clear と /compact を使い分ける — 長時間作業を止めない切り替え術

Claude Code を半日続けて使っていると、ある瞬間にこう感じることはないでしょうか。「このセッション、もう一度仕切り直した方がいい気がするけれど、ここまでの文脈は捨てたくない」。そういうときに頭をよぎるのが /clear と /compact という2つのコマンドです。

私自身、この2つの使い分けで何度か失敗しました。/compact で大事なファイルパスの記憶が消えて作業が振り出しに戻ったり、逆に /clear で全部リセットすればよかったのに /compact で曖昧な情報を残し続けて、判断が鈍ったセッションを延命させてしまったり。今回はその経験から見えてきた使い分けの判断軸を、できるだけ具体的に書き残しておきます。

/clear と /compact が混乱しやすい理由

両者の説明だけ並べると似たように見えるのが、混乱の入り口です。

/clear: 会話履歴を完全に消去します。次のターンからは「初対面」の状態に戻ります。CLAUDE.md は再度読み込まれるので、プロジェクトのコンテキストはゼロから再構築されます。
/compact: 会話履歴を要約して保持します。長くなった履歴を1〜2ページの要約に圧縮し、その続きとして対話を続けます。

ここで誤解しやすいのは、「/compact なら情報が残るんだから常に /compact の方が安全」という思い込みです。実際には /compact で残るのは「Claude が要約した情報」であって、原文ではありません。元のコードスニペットや具体的な数値は、要約の精度次第で消えてしまいます。

つまりこの2つは「情報量を絞る」という方向性は同じでも、残し方の質が違います。残し方の質を読者が選ばないと、思わぬところで作業の足を引っ張られます。

/clear が向くシーン — 文脈の汚染をリセットしたい時

私が /clear を選ぶのは、こういう状況です。

試行錯誤で間違った方向に行ってしまったとき: 例えばライブラリの選定を 5 往復ぐらい議論した結果、結局採用しないと決めた選択肢が会話履歴に残り続けると、Claude がそれを引きずって妙な提案をしてくることがあります。
タスクが完全に切り替わったとき: 朝はバックエンドのリファクタリングをしていて、午後から UI の調整に入る。このように対象が変わるときは、過去の文脈が残っていてもむしろノイズになります。
エラーメッセージのデバッグループから抜けたいとき: 同じエラーで 3 回以上往復したら、Claude の頭は「このエラーは難しい」という前提で固まっています。/clear で別の角度から見直してもらう方が早く解けることが多いです。

/clear を選ぶときの安心材料は CLAUDE.md です。プロジェクト固有の前提（使用言語・ディレクトリ構造・コーディング規約）は CLAUDE.md に書いておけば、リセット後も自動的に読み直されます。CLAUDE.md の設計については CLAUDE.md 設計と生産性 — プロジェクトの DNA を伝える書き方でまとめています。

/compact が向くシーン — 連続性を保ったまま余白を作りたい時

逆に /compact を選ぶのは、こういう状況です。

長い設計議論の途中でトークンが逼迫したとき: アーキテクチャの方向性を 30 ターンかけて詰めてきた直後に「あと 5 ファイル分の実装を頼みたい」というシーン。ここで /clear をすると議論の結論まで消えてしまいます。
複数ファイルにまたがる修正の中盤: ファイル A・B・C を順に編集していて、まだ D・E が残っているとき。「これまで何を変更したか」のコンテキストは Claude にも残しておきたい情報です。
テスト駆動で「赤→緑→リファクタ」を回しているとき: テストの意図と実装の進捗状況がセットで保たれていないと、リファクタフェーズで意図が読めなくなります。

/compact の良い点は、要約後も Claude 自身がその要約を読み返してから次の応答を返してくれる点です。つまり、要約の質が悪ければ Claude もそれを認識します。要約直後に「この要約に抜けている重要な点はありますか？」と聞いてみるのは、私の習慣です。

/compact の落とし穴 — 圧縮で失われる情報の見極め方

/compact を使うときに私が痛い目を見たのは次のようなケースでした。

具体的なファイルパスや関数名が抽象化される: src/lib/auth/sessionStore.ts の validateRefreshToken 関数を直していたのに、要約では「認証関連のリフレッシュトークン処理」とだけ残ることがあります。続きの作業で「あのファイル直してください」と頼むと、別のファイルを開かれて時間を溶かします。
数値・閾値が丸まる: 「タイムアウトは 8000 ms に設定する」と話していたのに、要約では「適切なタイムアウト」になることがあります。
議論の中で却下した案が再浮上する: 「A 案は性能上の理由で却下、B 案で進める」と決めたとき、要約には結論しか残らず、却下した理由が消えると Claude が再び A 案を提案してきます。

これに対する私の対策は、/compact する前に重要な決定事項を箇条書きで明示してから走らせることです。

このあと /compact します。要約に必ず含めてください:
- 採用したアーキテクチャ: イベントソーシング + CQRS
- 却下した案: 単純な REST + DB 直書き（理由: 監査ログ要件を満たせない）
- 編集中のファイル: src/domain/order/aggregate.ts
- 残作業: events.ts のテスト、infra/eventStore.ts の実装

このひと手間で、要約品質は明らかに変わります。

私の使い分け基準 — 3つの判断軸

迷ったときに私が自問する判断軸は、次の3つです。

議論の前提は今後も活きるか: 活きるなら /compact、活きないなら /clear。
CLAUDE.md にプロジェクト前提が十分書かれているか: 書かれているなら /clear のリスクが下がります。書かれていないなら /compact の方が安全です。
同じ話題で 3 回以上ループしていないか: ループしているときは /clear の方が効きます。

3つ目の「ループ判定」は、自分のセッションを客観的に見るための問いです。私は最近、ループに入ったと感じたら一度離席して、戻ってきてから判断するようにしています。離席せずに延命すると、たいてい同じ場所をもう一周します。

トークン管理の観点から /compact の発火タイミングを最適化したい方は Claude Code のトークン使用量を可視化する — 利用上限の管理術も合わせて読むと、/compact の出番がよりはっきり見えてきます。

CLAUDE.md と組み合わせる「自動再構築」テクニック

/clear を気軽に使えるようになるには、CLAUDE.md の質が決定的に重要です。私が実戦で効いていると感じている工夫はこの3つです。

「現在進行中のタスク」セクションを CLAUDE.md に持たせる: 例えば ## 現在の作業ブランチ: feat/payment-v2 のように、その日の文脈を明示しておきます。/clear してもこの情報は失われません。
コーディング規約を「これは絶対」「これは推奨」で分ける: 絶対のルールが先頭にあると、Claude は /clear 直後でも迷わず守ります。
過去の意思決定の記録を別ファイルに分けて参照させる: 例えば _decisions.md に重要な設計判断を残し、CLAUDE.md からリンクします。Claude は必要なときだけそれを開きます。

CLAUDE.md と長時間セッションの整合性については Claude Code の長時間セッションでコンテキストを健全に保つ方法でも実例を交えて掘り下げています。

/clear と /compact は、どちらが正解ということはありません。今日の自分のセッションが「ノイズが溜まりすぎているか」「価値のある文脈が積み上がっているか」を見極めるだけです。次のセッションで迷ったら、この記事の3つの判断軸を一度だけ自問してみてください。判断にかかる時間が、ぐっと短くなるはずです。