目次

Claude Code の /compact は、タイマーのように定期的に押すべきものではない。押すべきなのは作業の区切り——ひとつのタスクが終わり、次に取りかかる直前だ。公式ドキュメントもはっきりそう書いている。曰く、「作業の自然な区切り、たとえばタスクとタスクの間で /compact を実行する。タスクの途中で自動コンパクトが走るのを待つのではなく」（Claude Code 公式ドキュメント「Prompt caching」）。

「30分おきに押す」「文脈が70%を超えたら押す」といった時計や割合を基準にした運用は、狙いを外している。理由はこの記事で順に説明するが、要点を先に言えば、コンパクトの費用と損失は「いつ押したか」ではなく「何を捨てたか」と「キャッシュが温かいか」で決まるからだ。

📌 この記事の前提：本文中の仕様・バージョン番号・設定名は、2026年8月8日時点の Claude Code 公式ドキュメントおよびリリースノート（最新は v2.1.226／2026-08-08）で確認したもの。Claude Code は更新が速く、コンパクト周りは直近の版でも仕様が増えている（/autocompact は v2.1.221 以降）。手元の版は claude --version で確認してほしい。

1. 結論——「定期的に」ではなく「区切りで」押す

先に判断基準を表にする。「押す・押さない」を時間ではなく状況で決めるためのものだ。

✅ 押すべきとき

タスクを1つ終えて、次の長い作業に入る直前。文脈がまだ余っていても構わない。自動実行のタイミングを自分で前倒しして、作業の途中で割り込まれないようにするのが目的だ。

🟡 /clear の方が良いとき

次の作業が前の作業と無関係なとき。要約すら要らないなら、要約を作る費用も払う必要がない。公式は「継続ではなく仕切り直しが欲しいなら /clear は無料だ」と書いている。

🔵 /rewind の方が良いとき

進めた方向を丸ごと捨てたいとき。巻き戻しはすでにキャッシュ済みの地点まで切り詰めるので、新しい前置きを作り直すコンパクトより安い。

❌ 押さない方がよいとき

タスクの真ん中。まだ使う予定の詳細まで要約に潰される。「念のため」で押した分だけ、直後に同じファイルを読み直すことになる。

この4つを分ける軸はひとつだ。捨てようとしている内容を、この先まだ使うのか。公式ドキュメントの言い方を借りれば、「コンパクトが有利に働くのは、捨てる文脈がもう必要ないものであるときだ」。定期実行はこの判断を放棄する運用なので、当たるときも外れるときもある——そして外れたときの損失の方が大きい。

2. コンパクトは3段構え——公式が書いていること

「手動で押すべきか」を考える前に、押さなくても動いている仕組みを知っておく必要がある。Claude Code は文脈が埋まってきたとき、いきなり会話を要約するわけではない。公式ドキュメントはこう説明している。

「Claude Code は上限に近づくと自動で文脈を管理する。まず古いツール出力を捨て、必要なら会話を要約する。あなたの要求と重要なコード断片は保持されるが、会話の初期にあった細かい指示は失われることがある。永続的なルールは会話履歴に頼らず CLAUDE.md に置くこと」（How Claude Code works）

つまり段階がある。①古いツール出力の切り捨て → ②会話の要約（自動） → ③あなたが押す /compact の3段だ。

① ツール出力の切り捨て

会話は無傷のまま、古いツール結果だけが落ちる。あなたは何もしない。要約より先に、こちらが働く。

② 自動コンパクト

①で足りないとき、会話そのものを要約に置き換える。手動の /compact と同じ処理で、違うのは「いつ走るか」だけ。

③ 手動 /compact

②を自分の都合のいい時刻に前倒しするのが唯一にして最大の役割。加えて何を残すかを指示できるのが②との違いだ。

ここが「定期実行すべきか」の答えの核心になる。手動 /compact は、放っておいても起きることを前倒しする操作であって、回数を増やせば文脈が余分に節約されるという性質のものではない。押す価値があるのは「タイミングを自分で選ぶこと」に価値があるときだけだ。

⚠️ 用語について。①の段階を「マイクロコンパクト（micro-compact）」と呼ぶ解説記事が複数あるが、2026年8月8日に確認した範囲では、公式ドキュメントはこの呼称を使っていない。公式の説明はあくまで「まず古いツール出力を捨てる」という振る舞いの記述である。名前で検索して情報が見つからないときは、この違いが理由かもしれない。

3. 何が残り、何が消えるのか

コンパクトであなたのルールがどうなるかは、「どうやって読み込まれたか」で決まる。公式ドキュメントが仕組みごとの一覧を出しているので、そのまま整理する。

仕組み コンパクト後 実務上の意味
システムプロンプト・出力スタイル 変化なし 会話履歴の一部ではないため
プロジェクト直下の CLAUDE.md・スコープなしのルール ディスクから再注入 最も安全な置き場所。編集内容が反映されるのもここ（§8）
自動メモリ ディスクから再注入 セッションをまたいで残る仕組みなので当然生き残る
paths: 付きのルール 失われる（該当ファイルを再度読むまで） 残したいなら paths: を外すか直下の CLAUDE.md へ移す
サブディレクトリの CLAUDE.md 失われる（同ディレクトリのファイルを再度読むまで） 同上。最も見落としやすい欠落
呼び出したスキルの本文 再注入されるが上限あり 1スキル5,000トークン・合計25,000トークンで、古い順に捨てられる
フック 無関係 文脈ではなくコードとして動くため

この表から実務的な結論が3つ出る。

第一に、コンパクトを前提にするなら、消えては困るルールは「プロジェクト直下の CLAUDE.md」に置く。これは公式が繰り返し書いている一点だ。paths: 付きルールとサブディレクトリの CLAUDE.md は、便利さと引き換えにコンパクトのたびに落ちる——そして落ちたことは画面に出ない。

第二に、スキルは冒頭が命になる。再注入時の切り詰めはファイルの先頭を残す仕様なので、SKILL.md の重要な指示は上に書いておく必要がある。加えて公式の文脈解説によれば、セッション開始時に読み込まれるスキル一覧は /compact 後に再注入されず、実際に呼び出したスキルだけが保持される。

第三に、「何が失われたか」は自己申告されない。だからこそ、失われて困るものは会話ではなくファイルに置く、という原則が効いてくる。

4. コストは文脈の大きさでは決まらない

「文脈が大きいほど /compact は高い」と考えるのは自然だが、半分しか合っていない。実際に効くのはプロンプトキャッシュが温かいかどうかだ。公式の説明はこうだ。

「要約を作るために、Claude Code は同じシステムプロンプト・ツール・履歴に要約指示を末尾に足した別のリクエストを送る。キャッシュが温かいうちは、そのリクエストはあなたの前置きをキャッシュから読むので、文脈の大きさから想像するよりずっと安く済み、時間の大半は要約の生成に費やされる。（中略）キャッシュ寿命より長い休憩のあとは読むキャッシュが残っていないので、要約リクエストは履歴全体を未キャッシュの入力として処理し直す。これが、古いセッションを再開したときに /compact が最も高くつく理由だ」（Prompt caching）

この一文が、定期実行という発想を否定する最大の根拠になる。

作業中に押す（キャッシュ温）

前置きはキャッシュから読まれる。体感は「要約を書いている時間」だけ。ここでの1回は安い。

休憩明けに押す（キャッシュ冷）

履歴全体を読み直してから要約する。同じ操作が最も高くつく瞬間。「朝いちに整理しておこう」が最悪手になりうる。

押した直後のターン

短い要約だけでキャッシュを作り直すのでここは重くない。「コンパクト後に遅くなる」印象は、多くの場合ここではなく上の2つの差から来る。

キャッシュの寿命は認証方法で変わる。Claude のサブスクリプションでは1時間の TTL が自動で要求され、API キーやクラウド事業者経由では既定5分になる（ENABLE_PROMPT_CACHING_1H=1 で1時間に変更できる）。つまり「昼食から戻って最初に /compact」は、API キー運用ではほぼ確実に冷えた状態での実行になる。

なお /compact 自体が大きなリクエストである点は、コスト面の公式解説でも念を押されている。「/compact は要約する会話を読むので、大きな文脈のコンパクトはそれ自体が大きなリクエストになる。継続ではなく仕切り直しが欲しいときは /clear が無料だ」（Manage costs effectively）。トークン節約の観点から見ても、惰性の /compact より /clear の方が正解である場面は多い。

5. /compact・/clear・/rewind・/recap の使い分け

文脈を軽くする操作は /compact だけではない。目的が違うものを取り違えると、無駄に高い方を選ぶことになる。

コマンド 会話履歴 キャッシュ 選ぶ場面
/compact [指示] 要約に置き換える 会話層が無効化される 続きはやるが、履歴の細部はもう要らない
/clear [名前] 空にする 作り直し（要約の費用はゼロ） 次が無関係な作業。名前を付けておけば /resume で戻れる
/rewind 過去の地点まで切り詰める 過去のキャッシュに当たる 進めた方向ごと捨てたい。コードも一緒に戻せる
/recap 変えない（要約を表示するだけ） そのまま維持 「ここまでの整理」が読みたいだけのとき
/context [all] 変えない 維持 押す前に測る。何が場所を食っているかが色分けで出る

/recap の存在は覚えておく価値がある。「話が長くなってきたので一度まとめてほしい」という動機で /compact を押している人は少なくないが、その目的なら履歴を壊す必要がない。公式によれば /recap は要約をコマンド出力として末尾に追記するだけなので、キャッシュされた前置きは無傷のまま残る。

同じく /rewind の性質も効く。公式の説明では、巻き戻しは「その時点でキャッシュが作られたのと同じ内容」まで戻るため次のリクエストが過去のキャッシュに当たる。間違った方向に進んだときの正解は /compact ではなく /rewind だ——コンパクトは新しい前置きを作るが、巻き戻しは既にあるものへ戻るだけだからだ。チェックポイントと巻き戻しの詳細は専用記事で扱っている。

6. 自動コンパクトの窓は自分で決められる

「手動で押すか」を悩む前に確認しておきたいのが、自動で走る位置そのものを動かせるという事実だ。v2.1.221 以降、/autocompact コマンドで「文脈がどれだけ埋まったら自動コンパクトするか」を指定できる。

窓を 500K トークンに設定（ユーザー設定に保存され、以降のセッションにも効く）

/autocompact 500k

モデルに合わせた既定へ戻す

/autocompact auto

受け付ける値は100K〜1Mトークン。200000 のような素の数値、500k / 1M のような接尾辞付き、200 のような100〜1000の裸の数値（千単位と解釈）のいずれでもよい。設定は4か所から効き、優先順位が決まっている。

① 環境変数（最優先）

CLAUDE_CODE_AUTO_COMPACT_WINDOW。設定中はコマンドもフラグも設定ファイルも上書きする

② 起動フラグ

claude --autocompact 500k。その起動限りで、保存された設定を変えない

③ コマンド

/autocompact。ユーザー設定の autoCompactWindow に書き込まれる

④ 設定ファイル

autoCompactWindow。組織の管理設定が上位にあると、そちらが勝つ

⚠️ 環境変数だけ書式が違う。公式ドキュメントは CLAUDE_CODE_AUTO_COMPACT_WINDOW について「素の整数のみを受け付ける。500k のような値は 500 と読まれ、最小値100Kに丸められる」と明記している。コマンドと同じ書き方をすると意図の1000分の1を指定したことになり、丸められて逆に頻繁にコンパクトされる。

同じ箇所にもう一つ注意がある。ステータスラインの used_percentage は常にモデルの全文脈窓に対する割合を示すため、この環境変数を設定するとその％はもうコンパクトの発火時期を表さなくなる。「％を見て手動で押す」運用が壊れるのはここだ。

窓を明示しない場合の既定も公式に書かれている。何も設定しなければモデルの文脈上限に達した時点でコンパクトされるが、例外がある——クラウドセッションは上限に近づいた時点で早めに、拡張文脈なしの Sonnet 4.6 / Opus 4.6 は200Kの境界で、Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry 上で200K文脈で動く Opus 4.8 / Opus 5 も同様に、Sonnet 5 はそのモデル既定の閾値で走る。

自動コンパクト自体を止めることもできる。設定 autoCompactEnabled（既定 true、/config では「Auto-compact」）を false にするか、環境変数 DISABLE_AUTO_COMPACT を使う。ただし勧めない。止めれば文脈は上限にぶつかって止まるだけで、「Prompt is too long」エラーに変わるだけだからだ。自動コンパクトはあなたを守っている機能であって、邪魔をしている機能ではない。

7. 定期実行が逆効果になる3つの場面

ここまでの仕様を踏まえると、「とりあえず定期的に押す」が損になる場面がはっきりする。

① タスクの途中で押す

まだ使う予定の詳細が要約に潰れる。加えて paths: ルールとサブディレクトリの CLAUDE.md が落ちるので、直後の作業が微妙にルールを外し始める。原因が見えにくい種類の劣化だ。

② 休憩明けの一発目に押す

キャッシュが切れているので、履歴全体を読み直してから要約する。同じ /compact が最も高い瞬間で、しかも「整理してから始めよう」という善意ほどここに当たりやすい。

③ 短いセッションで押す

要約すべき履歴が無ければ Not enough messages to compact. が返るだけ。巨大な貼り付け1回で文脈が埋まった場合にも起こる——このときは要約ではなく /clear が正解になる。

逆に言えば、手動で押す価値が最も高いのは「長い作業をこれから始める直前」の1回だ。ここで押しておけば、その長い作業の最中に自動コンパクトが割り込む確率を下げられる。回数ではなく、押すタイミングに意味がある。

8. 実運用——押す前にやることの方が重要

/compact の運用で本当に効くのは、押し方ではなく「押す前に何をファイルへ落としておくか」だ。§3の表のとおり、プロジェクト直下の CLAUDE.md と自動メモリはディスクから再注入される。つまりそこに書いてあることは、何回コンパクトしても生き残る。

そしてもう一つ、見落とされがちな性質がある。セッション中の CLAUDE.md 編集は、その場では反映されない。公式ドキュメントは「編集はキャッシュを無効化しないが、編集自体も適用されない。新しい内容は次の /clear、/compact、または再起動で読み込まれる」と説明している。裏を返せば、/compact は「作業中に決めたルールを反映させる操作」でもあるということだ。

押す前のチェックリスト

  • このセッションで決めたルール・方針をファイルに書いたか（会話の中にしか無いものは要約で薄まる）
  • 残したいものを指示に書いたか——/compact 認証まわりの修正方針とテスト結果を残して のように焦点を渡せる
  • 次にやることは本当に地続きか。無関係なら /clear の方が安い
  • いまキャッシュは温かいか（長い休憩の直後は避ける）
  • 迷ったら /context で実際に何が場所を食っているか測る

そしてここが、手動実行を考えている人がいちばん取りこぼしやすい点だ。「勝手にコンパクトされて話が通じなくなるのが怖いから、先回りして自分で押している」という運用は珍しくない。だが公式ドキュメントは、自動コンパクトの説明の直後にこう書いている——「コンパクトで何が保持されるかを制御するには、CLAUDE.md に "Compact Instructions" セクションを追加するか、/compact に焦点を渡して実行する」（How Claude Code works）。

つまり焦点の指定は、自分で押したときだけの特権ではない。CLAUDE.md に書いておけば、席を外している間に自動で走ったコンパクトにも効く。先回りして手で押す運用の目的が「削られ方を決めること」なら、本命はこちらだ——手で押す運用は、あなたが見ているときしか効かないからだ。

書き方は難しくない。公式ドキュメントが例示しているのはこうだ。

CLAUDE.md に置く既定のコンパクト指示（公式ドキュメントの例）

# Compact instructions

When you are using compact, please focus on test output and code changes

当サイトの運用も参考までに書いておく。このブログのリポジトリの CLAUDE.md には、以前から2行のルールが入っている——「コンテキストが長くなったら /compact をユーザーに提案すること」「/compact 実行前に、ルール化すべき内容（フィードバック・方針決定など）をメモリに保存すること」。この記事自体、コンパクトを挟んだセッションの中で書かれている。実感として効いているのは前者ではなく後者だ。要約に何を残すかを頑張るより、残すべきものを先にファイルへ出しておく方が確実に効く。

文脈を減らす手段は /compact だけではない、という点も付け加えておく。公式のコスト解説は、大量の出力を伴う作業（テスト実行・ドキュメント取得・ログ処理）はサブエージェントに委譲せよと勧めている。サブエージェントは自分の文脈窓を持ち、戻ってくるのは要約だけなので、そもそも本体の文脈が膨らまない。コンパクトが要らない状態を作る方が、上手にコンパクトするより上等だ。

9. うまくいかないときの2つのメッセージ

実際に押したときに出うる、意味の分かりにくいメッセージが2つある。

メッセージ 意味 対処
Not enough messages to compact. 要約するだけの会話が無い。巨大な貼り付け1回で文脈が埋まった場合にも起きる /clear で仕切り直す
Autocompact is thrashing: the context refilled to the limit... コンパクトは成功したが、巨大なファイルやツール出力が直後に文脈を埋め直すのを数回繰り返した。無限ループを避けて停止した状態 右の4手（公式の推奨順）

後者の復旧手順は公式ドキュメントに順序付きで書かれている。①巨大ファイルを行範囲や関数単位で小分けに読ませる ②落としたい出力を指定してコンパクトする（例：/compact keep only the plan and the diff）③その作業をサブエージェントに移して別の文脈窓で走らせる ④以前の会話がもう不要なら /clear。①が先頭に来ているのが要点で、これは「コンパクトの問題」ではなく「読み方の問題」だと公式が言っているに等しい。

まとめ

/compact を定期的に手動実行する必要はない。自動コンパクトは放っておいても走り、しかも手動と同じ処理をする。手動で押す意味は「タイミングを自分で選べること」と「何を残すか指示できること」の2点だけで、この2点が効くのはタスクとタスクの間という一箇所に集中している。

費用の観点でも定期実行は不利だ。コンパクトの価格はキャッシュが温かいかどうかで決まるため、休憩明けの「整理してから始めよう」が最も高くつく。仕切り直しでよければ /clear は無料で、方向転換なら /rewind が既存のキャッシュに戻るぶん安く、要約を読みたいだけなら /recap は履歴を壊さない。目的別に4つを使い分けるのが、頻度を上げるより効く。

そして最も実務的な結論は、コンパクトの押し方の外にある。消えては困るものは、会話ではなくファイルに置く。プロジェクト直下の CLAUDE.md と自動メモリはディスクから再注入されるが、paths: 付きルールとサブディレクトリの CLAUDE.md は黙って落ちる。この非対称性を知っているかどうかが、長いセッションの品質を分ける。

FAQ

Q1. 結局、何分おきに /compact を押せばいいですか？

時間で決めるべきではありません。タスクが1つ終わって次の長い作業に入る直前が唯一の推奨タイミングです。公式ドキュメントも「作業の自然な区切り、たとえばタスクとタスクの間で」と書いており、時間や割合の基準は示していません。

Q2. 自動コンパクトに任せきりでも問題ありませんか？

自動と手動は同じ処理で、違うのは走るタイミングだけです。ただし自動はタスクの途中で割り込むことがあります。長い作業の前に一度手動で押しておくと、この割り込みの確率を下げられます。そして「何を残すか」は自動にも指示できます——CLAUDE.md に # Compact instructions の見出しで書いておけば、席を外している間に走ったコンパクトにも効きます（§8）。

Q2-2. 勝手にコンパクトされた後、指示が通らなくなった気がします

気のせいではありません。公式ドキュメントは「会話の初期にあった細かい指示は失われることがある」と明記しています。加えて paths: 付きルールとサブディレクトリの CLAUDE.md は該当ファイルを読み直すまで落ち、呼び出したスキルも合計25,000トークンを超えると古い順に捨てられます。内容が消えるというより、守っていたルールが静かに減るため、作業は続くのに精度だけ落ちます。対策は3つ——①永続させたいルールを直下の CLAUDE.md へ移す（再注入される） ②# Compact instructions で残すものを指定する ③/autocompact で発火位置を前倒しし、上限ぎりぎりで走らないようにする。

Q3. /compact と /clear はどちらを使うべきですか？

次の作業が前の続きなら /compact、無関係なら /clear です。公式のコスト解説は「継続ではなく仕切り直しが欲しいときは /clear は無料だ」と明記しています。/clear に名前を渡しておけば /resume の一覧から戻れるので、消える怖さもありません。

Q4. コンパクトすると CLAUDE.md のルールも消えますか？

プロジェクト直下の CLAUDE.md は消えません——ディスクから再注入されます。消えるのは paths: フロントマター付きのルールとサブディレクトリの CLAUDE.md で、これらは該当ファイルが再度読まれるまで戻りません。永続させたいルールは paths: を外すか直下の CLAUDE.md へ移してください。

Q5. 自動コンパクトを止められますか？

止められます（設定 autoCompactEnabled を false、/config の「Auto-compact」、または環境変数 DISABLE_AUTO_COMPACT）。ただし勧めません。止めても文脈が減るわけではなく、上限に当たってエラーになるだけです。「早めに走らせたい」のが目的なら、止めるのではなく /autocompact で窓を狭めるのが正しい操作です。

Q6. /compact はどのくらいトークンを消費しますか？

キャッシュが温かいかどうかで大きく変わります。作業中に押せば前置きはキャッシュから読まれ、公式の表現では「文脈の大きさから想像するよりずっと安く」済みます。逆にキャッシュ寿命を超える休憩のあとは履歴全体を未キャッシュで読み直すため、同じ操作が最も高くつきます。キャッシュ寿命はサブスクリプションで1時間、APIキーやクラウド事業者経由では既定5分です。

Q7. 残す内容を指定できますか？

できます。/compact に続けて指示を書けば、その焦点で要約されます（例：/compact 認証まわりの修正方針とテスト結果を残して）。毎回同じ指示でよければ、CLAUDE.md に # Compact instructions という見出しを作って書いておけば既定として効きます。

Q8. コンパクト直後に応答が遅くなるのはなぜですか？

コンパクト直後のターンは重くありません。公式によれば、その turn は短い要約だけでキャッシュを作り直すため「遅い部分ではない」とされています。遅さを感じるのは多くの場合要約を生成しているコンパクト実行中そのものか、キャッシュが切れた状態で押したケースです。

Q9. 「マイクロコンパクト」という機能はありますか？

その振る舞いは存在します——公式ドキュメントは「まず古いツール出力を捨て、必要なら会話を要約する」と説明しており、要約の前段に別の処理があることを明記しています。ただし2026年8月8日に確認した範囲では、公式ドキュメントは「マイクロコンパクト」という呼称を使っていません。この名称は解説記事側のもので、公式用語ではない点に注意してください。

関連記事