Claude Codeのコンテキスト管理｜clear・compact・rewindの使い分け

まず/contextで、何が容量を使っているかを見る

会話が長くなったと感じたら、Claude Codeのセッションで/contextを実行します。現在の使用量を分類別に確認でき、読み込まれたCLAUDE.mdや自動メモリ、改善の候補も表示されます。公式のコンテキスト解説にも、この確認方法が載っています。

/context

総量だけでなく、増えた理由を見ます。作業開始直後から大きいなら、いつも読み込まれる指示や拡張機能を点検する。大量のログや資料を読んだ後なら、次の判断に必要な箇所を絞る。前の仕事のやり取りが中心なら、引き継ぎを残して別の会話へ移る。この順なら、容量が増えた原因に合う方法を選べます。

表示された割合を、成果物の正しさを測る点数にはしません。残り容量が多くても前提が違えば回答はずれますし、一定の割合を超えた瞬間に失敗するという共通の境界もありません。変更した設定、同じ作業の入力、確認できた結果をそろえて比較してください。

次の1ターンを送る前に、5つの選択肢を比べる

会話には依頼文だけでなく、ファイルを読んだ結果、検索結果、エラー出力なども入ります。同じセッションに別の案件を次々足すと、必要な前提がどれなのか分かりにくくなります。一方、毎回新しくすると、同じコードや仕様を読み直さなければなりません。区切ること自体を目的にせず、次の作業が必要とする情報から判断します。

これは操作の選び方を示す編集部の整理です。コンテキストを管理し、検証可能な目標を渡す考え方は公式のベストプラクティスも参考になります。

続行が向くのは、前の仕事の知識をすぐ使うとき

例えば、問い合わせ一覧の表示不具合を直した直後に、その変更の説明を書く場合です。原因、触ったファイル、確認した画面が会話内にそろっています。ここで履歴を消すと、説明に必要な事実まで調べ直すことになります。

続行する場合も、作業の範囲は短く言い直します。「今の修正について、利用者に見える変更、再現手順、確認した環境を、コード変更のレビュー依頼（PR）の本文にまとめて」と頼めば、すでにある文脈を何に使うのかが明確になります。別の機能の設計まで同時に足す必要はありません。

会話が長いことと、仕事が複雑なことを分ける

同じ不具合について必要な調査を重ねた長い会話と、無関係な雑談や別案件が混ざった長い会話は、同じ扱いにはできません。トークン数だけを見て区切ると、必要な根拠を落とすことがあります。回答の前提がずれる、終わった案を再提案する、といった変化があれば、目的と現在地を整理してから次へ進みます。

rewindでは、会話とファイルのどこまでを戻すか確認する

/rewindは、過去の地点から会話や対象のファイル変更をやり直すための機能です。失敗した方向の説明を何度も追加するより、分岐点へ戻ったほうが整理しやすい場面があります。復元の対象と制限はチェックポイントの公式説明で確認してください。

ただし、メール送信やデータベース更新など、外部へ実行した操作は取り消せません。ターミナルコマンドによる変更や、多くのサブエージェントによるファイル編集も、チェックポイントの復元対象外です。戻す前にgitの差分と外部サービスの状態を確認し、対象と例外は公式資料で確かめます。

別の方針を試す前に、現在の変更ファイルを一覧にしてください。
残すべき修正、戻す候補、外部サービスに実行した操作を分けてください。
その結果を見てから、どの地点へ戻すか決めます。

compactには「次にすること」を添える

要約には、何を残すべきかという判断が必要です。次の仕事が分からないまま圧縮すると、後で必要になる条件や例外が省かれる可能性があります。同じ案件を続けるなら、次の目的と、根拠があるファイルの場所を先に整理します。

/compact 次は問い合わせ一覧のエラー表示を直します。
再現条件、原因が確認できた箇所、試して否定された仮説、
変更ファイル、未実施のテストを残してください。
推測と確認済みの結果は分けてください。

この依頼文は編集部の例です。実際のファイル名と確認結果へ置き換えて使います。長いログの全文を要約に詰め込むより、ログを保存した場所と、判断に必要な行を示すほうが後から追えます。圧縮後は、未完了事項を短く復唱してもらい、抜けがあれば作業再開前に補います。

要約の前後で3条件を照合する例：請求明細の下書きなら、「通貨は円」「税込と税抜を混ぜない」「外部へ送信しない」を短い作業メモに残します。/compactには、この条件と次に扱う入力ファイルを添えます。要約後、次の依頼へ進む前に3条件と未処理の行を説明させ、元のメモと照合してください。1つでも抜けたら補ってから再開します。要約できたこと自体を、条件の保持に成功した証拠にはしません。

clearの前に残す引き継ぎは、5項目で足りる

案件が変わるなら、新しい会話に分けるほうが前提を整理しやすくなります。ただし、/clearを実行することと、作業記録を保存することは別です。次に再開できるよう、会話の外へ短い引き継ぎを残します。

継続的なプロジェクト規則はCLAUDE.mdなどに整理し、案件ごとの進行記録と混ぜないようにします。記憶ファイルの読み込み方は公式のメモリ説明で確認できます。「保存したから必ずすべて覚えている」とは考えず、再開時に必要な記録を指定します。

途中の出力が不要な調査は、結果を受け取る形にする

ライブラリの実装を大量に読んでも、親の会話に必要なのは「採用する方法と理由」だけ、ということがあります。その場合は調査範囲を分け、根拠の場所を付けて報告させる方法が使えます。サブエージェントの公式資料を確認したうえで、使えるツールや役割を設定します。

依頼には「結論、根拠ファイル、未確認点、次に確認すべきこと」の4項目を指定します。逆に、途中の試行錯誤を見ながら利用者が仕様を決めたい仕事は、親の会話で進めるほうが適しています。分担は文脈を整理する手段であり、増やすほど正しくなる仕組みではありません。

会話を区切る前に、再開に必要な情報を保存する

別の会話へ引き継ぐなら、まず「目的・決定事項・変更したファイル・検証結果・未完了・次の一手」をhandoff.mdなどのファイルへ保存するよう依頼します。これは編集部の運用例です。秘密や不要なログを丸ごと写す必要はありません。

ここまでの目的、決定事項、変更ファイル、検証結果、
未完了と次の作業を handoff.md に保存してください。
推測と確認済みの事実を分け、再開に必要な参照先を残してください。

保存内容を確認してから/clearで新しい会話へ移り、@handoff.mdを添えて再開を頼みます。新しい会話が引き継いだ前提と次の作業を確認してください。要約に書かれた「完了」をうのみにせず、必要な成果物や検証結果へ戻れる状態にしておきます。

よくある質問

一定のトークン数で必ず新しい会話にすべきですか？

いいえ。利用モデルや設定によって容量は異なり、仕事の内容も違います。現在の目的に不要な履歴が増えているか、必要な根拠を追えるかを判断材料にします。

compactすれば、記録を別ファイルに残す必要はありませんか？

重要な仕様、判断、検証結果は別に残します。圧縮された会話だけに依存すると、後日別の担当者が根拠を確認しにくくなります。

まとめ：区切る前に、何を引き継ぐか決める

続行、巻き戻し、圧縮、新規会話、分担。それぞれの役割を理解すると、会話が長くなったときにも選びやすくなります。まず今進めている1件について、目的・現在地・根拠・次の一手・制約を書き出してみてください。その記録が、どの方法を選んでも作業を続ける土台になります。