Claude Codeで/clearと/compactをどう使い分けるか：会話が長くなったときの判断

三つの操作で何が起きるか

公式ドキュメントで確認できた違いは次のとおりです。

• /compact：会話を要約に置き換え、コンテキストの空きを作ります。/compact focus on the auth bug fix のように指示を付けると、何を要約に残すかを自分で寄せられます。指示なしでも、コンテキストが埋まりかけると自動で圧縮されます。
• /clear：無関係な作業に移るときに使う、会話の初期化です。公式は、古い会話が次に必要なファイルを押しのけ、以後のメッセージごとにトークンを消費することを理由に挙げています。後で戻りたければ、クリア前に /rename で名前を付け、/resume で戻れます。
• 新しいセッション：各セッションは独立しており、前のセッションの会話履歴を持たない新しいコンテキストで始まります。CLAUDE.md と auto memory は引き継がれます。

公式は、/clear も新しいセッションを開始すると説明しています。この記事では、/clear と新規セッションを「前の会話履歴を引き継がずに始める」という観点で比較します。

圧縮には注意点があります。公式は、要約は依頼内容や重要なコードを残す一方で、会話の序盤に出した詳細な指示は失われることがあると説明しています。また、/compact は要約対象の会話を読む処理なので、大きなコンテキストの圧縮自体が大きなリクエストになります。逆に /clear は追加コストがかかりません。

状況別の選択表

次の表は、上の仕様をもとにした編集上の判断基準です。公式がこの対応を定めているわけではありません。

• 同じ機能の実装中で、方針も決まっている。会話が長いだけ、選ぶ操作：/compact（指示付き）、理由：方針と進捗を要約に残したまま空きを作れる
• 調査や試行錯誤が長く、結論だけ必要、選ぶ操作：/compact、または /rewind の「Summarize from here」、理由：会話全体を要約するなら /compact。選択地点より前の指示をそのまま残し、そこから先を要約するなら「Summarize from here」
• 同じ指摘を何度も繰り返している。失敗案が会話に積み上がっている、選ぶ操作：引き継ぎメモを作って /clear、理由：誤った前提が要約に混ざるのを避けられる
• 別のバグ、別の機能に移る、選ぶ操作：/clear、理由：前の作業の文脈は次の作業に不要で、トークンも余計にかかる
• 一晩空けて翌日続きをする、選ぶ操作：引き継ぎメモ＋新規セッション、または /resume、理由：前日の会話全体を持ち越す必要があるかで決める
• 圧縮しても自動圧縮がすぐ再発する、選ぶ操作：巨大なファイルや出力を会話から外し、/clear で出直す、理由：公式は、大きな出力が原因で圧縮を繰り返すと自動圧縮が停止してエラーになると説明している
• 「このルールを毎回守ってほしい」が抜け落ちる、選ぶ操作：操作ではなくプロジェクトルートの CLAUDE.md に書く、理由：会話内の指示は圧縮で薄れうる。ルートの CLAUDE.md は圧縮後にディスクから再投入される。サブディレクトリの CLAUDE.md は必要に応じて再読み込みされる

「序盤の指示が抜けた」と感じたときは、圧縮か初期化かを選ぶ前に、その指示が会話にしか存在しないのかを疑います。常に守らせたいルールはプロジェクトルートの CLAUDE.md へ、というのが公式の案内に沿った方法です。

圧縮前に残すべき事項のメモ例

圧縮をClaudeの判断に任せると、何を残すかは自動パスの推測になります。公式も、指示付きの /compact なら要約に自分で選んだ内容を残せるとしています。残す項目は次の7つが目安です。

1. 作業の目的と完了条件
2. 決定済みの方針と、却下した案（理由つき）
3. 変更済みのファイルと、まだ触っていないファイル
4. 実行したテストコマンドと直近の結果
5. 未解決の問題・エラーメッセージ
6. 守るべき制約（互換性、触らない範囲など）
7. 次にやること

以下は説明用の例です。実際のプロジェクトのものではなく、実行して検証した結果でもありません。

/compact 次の項目を必ず要約に残してください。
目的: 注文一覧APIにページネーションを追加する（既存の画面は変更しない）
決定: オフセット方式ではなくカーソル方式を採用。理由は件数増加時の速度低下を避けるため
却下: 全件取得後のフロント側分割（データ量が大きいため）
変更済み: api/orders.ts, api/orders.test.ts
未着手: docs/api.md の更新
テスト: npm test の最新結果と、失敗していた2件のエラーメッセージ
制約: レスポンスの既存フィールド名は変更しない
次の作業: 失敗2件の原因調査から再開する

この指示の項目名は、自分の作業に合わせて書き換えてください。毎回同じ内容を使うなら、公式が案内している「Compact Instructions」の考え方に沿って、CLAUDE.md に圧縮時の方針を書いておく方法もあります（例：「圧縮時はテスト出力とコード変更を優先して残す」）。

会話の一部だけを圧縮したいときは /rewind から Summarize from here / Summarize up to here を選べます。要約してもディスク上のファイルは変わらず、元のメッセージはセッションの記録に残ると説明されています。

/clearに進むときの引き継ぎ手順

初期化を選ぶなら、消える前に必要事項を会話の外へ出します。

1. Claudeに依頼する。「これから会話を初期化します。上記7項目を handoff.md にまとめてください。推測と確認済みの事実は分けて書き、APIキーなどの秘密情報は含めないでください」
2. 自分で handoff.md を読み、間違いや抜けを直す。
3. /rename で現在のセッション名を付けてから /clear を実行する。
4. 新しい会話で「handoff.md を読み、次の作業から再開してください。最初に理解した内容を3行で言ってください」と依頼する。

同じプロセス内で /clear を実行した場合は、/rewind のメニューにクリア前のセッションへ戻る項目が表示されます。ただしこの項目は、プロセスを終了するか、別のセッションを再開すると表示されなくなるため、メモの作成を省く理由にはなりません。

人が確認すること

要約もメモもClaudeが作る文章です。任せてよいのは下書きまでで、次の点は人が見ます。

• 却下した案と制約が、実際の合意どおりに書かれているか。ここが欠けると、再開後に同じ失敗案が提案されやすくなります。
• 「テスト通過」「修正済み」といった記述が、実際のコマンド結果に基づいているか。疑わしければ、再開後に自分でテストを走らせます。
• 圧縮・初期化の後、最初の返答で目的と次の作業を言い直させ、認識がずれていないか。
• メモや要約に、顧客データ、認証情報、社内の機密が入っていないか。共有するメモは、説明用データに置き換えます。

なお、ファイルの編集は /rewind で戻せますが、チェックポイントは Git の代わりではなく、Bash コマンドだけで変更されたファイルなどは追跡されません。大きな初期化や方針転換の前には、コミットや退避で現状を保存しておくと安心です。