Claude Code /compactの正しい使い方｜頻発が逆効果になる理由とタイミング

まず、意外と知られていない事実から始めます。AI（Claudeのようなモデル）は、渡す情報が長くなるほど、答えの質が落ちます。

Claude Codeで作業を続けると、それまでのやり取り（会話の履歴やコマンドの実行結果）がどんどんたまっていきます。このAIに渡っている情報のかたまりを「コンテキスト」と呼びます。コンテキストが長くなるほど、AIは指示を取りこぼしたり、前に決めたことを忘れたり、見当違いのコードを書いたりしやすくなります。

ここで自然に浮かぶのが、「じゃあ/compactでこまめに会話を短くまとめ続ければ、質の低下を防げるのでは？」という発想です。/compactは、それまでの会話を要約して短く圧縮してくれるコマンドだからです。この記事で「頻発」と呼ぶのは、この/compactを短い間隔で何度も打ち続ける使い方のことです。

ところが、これは単純な解決策にはなりません。圧縮にも代償があるからです。/compactは会話を短くしてくれますが、そのたびに元の情報の一部が消えます。しかも繰り返すほど、消えた分が積み重なっていきます。つまり「コンテキストが長いとAIの質が落ちる」問題と、「圧縮するとAIに必要な情報が消える」問題を、両方いっぺんに抱えることになります。

この記事では、まず/compactが具体的に何をするコマンドなのかを整理し、そのうえで「なぜ頻発が逆効果になるのか」を順番に説明します。引数（何を残すか・消すかの指定）と、打つタイミングのコツは後半でまとめます。急ぐ方は引数のテンプレートから読んでも大丈夫です。

/compact が何をするコマンドか

/compactは、それまでの会話を要約して短く圧縮し、コンテキストを減らしながら、同じ会話をそのまま続けるためのコマンドです。

会話を続けたまま中身を圧縮する仕組み

使い方はシンプルです。引数なしで打つと会話全体をざっと要約し、引数を渡すと「何を重点的に残すか」を指定した要約になります。

/compact
/compact [残してほしいこと]

/compactを打つと、Claude Codeは中で次のことを順番にやっています。

1. これまでの会話（コマンドの実行結果も含む）を全部かき集める
2. それを別のAIに渡して、要約を作らせる
3. できた要約だけを残し、元の会話は丸ごと捨てる
4. CLAUDE.mdやスキルなど、ファイルに保存してある設定を読み直して、会話を続ける

要するに「長い会話の山を、短い要約1枚に置き換える」処理です。元のやり取りは、ここで消えてしまいます。

何もしなくても、コンテキストが一定量たまると自動で圧縮が走ります（これをオートコンパクションと呼びます）。発動するのは、20万トークン入るモデルなら約16.7万トークン（全体の8割ちょっと）を使ったあたりです。「9割を超えたら発動」と書かれていることもありますが、実際の発動ラインはこのくらいです。

似たコマンドに/clearがありますが、役割はまったく違います。/compactは要約して会話を続けるのに対し、/clearは会話をまっさらに消して、新しく始め直すコマンドです。同じ作業を続けるなら/compact、別の作業に切り替えるなら/clear、というのが基本の使い分けです。

ちなみに、100万トークンまで入る大きなモデルに変わってから、Claude Codeで自動圧縮が起きる回数は15%減ったというデータがあります。入れ物が大きいほど自動圧縮が走りにくく、圧縮による情報の取りこぼしも減る、という関係です。

圧縮したあと、何が残って何が消えるのか

圧縮しても自動でよみがえる情報があります。プロジェクトのいちばん上に置いたCLAUDE.mdは、ファイルから読み直されて戻ってきます。AIが自分用に書いておくメモ（MEMORY.md）も、毎回先頭200行が自動で読み込まれます。スキルも戻ります。

一方で、消えたまま戻らない情報もあります。サブフォルダの中に置いたCLAUDE.mdは、圧縮後に消えます（次にそのフォルダのファイルを開くまで戻りません）。特定のファイルにだけ効くルールも同じです。

会話の中だけで伝えた指示も、要約に残るかどうかはAIの判断しだいで、実際よく消えます。とくに消えやすくて、消えると困るのが次のような指示です。

消えやすい指示	消えると何が起きるか
「○○はやらないで」という禁止	禁止したはずの操作をAIがやってしまう
「pushする前に必ず確認して」	確認なしで勝手にコミットされる
「この案はボツ」と決めたこと	ボツにしたはずの案で実装が進む
名前の付け方やコードの書き方のルール	途中から書き方がバラバラになる
「このやり方は失敗した」という記録	同じ失敗をもう一度くり返す

「/compactを頻発すれば良いんじゃないの？」が通じない理由

/compactを短い間隔で何度も打ち続ける使い方は逆効果です。その理由は、以下の３つの問題が重なっているからです。

1. そもそもコンテキストが長いとAIの質が落ちる（だから圧縮したくなる）
2. ところが/compact自体がAIに必要な情報を壊す（圧縮すると別の問題が出る）
3. しかもくり返すほど劣化が積み重なる（頻発すると最初の要約からどんどん離れる）

この3つが噛み合っているせいで、「とにかく頻繁に圧縮すればいい」という単純な答えが成り立ちません。順に見ていきます。

長い会話はAIの答えの質を落とす

これは本題の前提なので、要点だけで十分です。コンテキストが長くなるほど、AIは正しく答えにくくなります。 情報が増えるとAIの「注意」が薄まり、特に会話の真ん中あたりが読み飛ばされやすくなるためです。感覚論ではなく、複数の研究で確かめられています（Lost in the Middle、Chromaの調査）。コードを直すタスクでは、入る限界まで情報を詰め込むと正解率が10分の1以下まで落ちた例もあります（LongCodeBench）。

つまり「たくさん入る＝賢い」ではありません。だから会話を短く保ちたくなる——その動機自体は正しいのです。問題は、その手段として/compactを頻発することにあります。

/compact 自体がAIに必要な情報を壊す

ここまでが「圧縮したくなる理由」です。ところが、圧縮そのものにも問題があります。あまり知られていませんが、公式ドキュメントには「圧縮は仕組み上、必ず情報が失われる（lossy by design）」とはっきり書かれています。つまり、情報が消えるのは不具合ではなく、そういう仕様なのです。

圧縮したあとに何が残るかを調べたテストがあります。「生き物の寿命」のような大まかな話は、3件中3件ともそのまま残りました。でも、細かい数字や計算結果は、3件中3件すべて消えました。要するに、話のざっくりした筋は残るけど、正確な細部は消える。これが圧縮の性質です。

会話のどの部分が消えやすいかというと、いちばん困るのが「設計の判断」です。「この案はこういう理由でボツにした」という判断が、理由ごとまるごと消えるため、ボツにしたはずの案をAIがまた提案してきて、同じ議論を一からやり直すことになります。次に消えやすいのが「こちらが出した指示」。「このやり方は使わないで」という禁止が静かに消え、禁止したはずの手法が使われ始めます。さらに「コードの細かい文脈」が消えると、実在しない関数があるつもりでコードを書き始め、「やったことの記録」が消えると、すでに確認したことをもう一度確認し直す、という無駄が出ます。

実例もあります。圧縮のあとにアクセス制限のルールが消えてしまったケースや、「サブエージェントを並列で起動するな」というルールが自動圧縮で消えた結果、AIが10個も同時に立ち上がってトークンを大量に無駄づかいしたケースが報告されています。

くり返すほど劣化が積み重なる

/compactは、元に戻せない処理です。一度要約したものをさらに要約すると「要約の要約」になり、打つたびに中身がどんどんざっくりしていきます。

たとえば、圧縮する前は「このファイルの98行目」「具体的なエラーの種類」「すでに試してダメだった仮説」まで覚えていた状態が、1回圧縮すると「Stripeの通知のリトライにバグ、チェックの追加が必要」という、たった1文に縮みます。さらに圧縮が重なると、その曖昧な1文をもとに見当違いのファイルを探し、間違った場所を直し、その間違いを含んだままさらに圧縮する——という悪循環に入ります。

この悪循環はやっかいで、一度はまると気づきにくいです。「なんか様子がおかしい」と感じても、何の情報が消えたせいなのかを突き止めるのが難しいからです。圧縮を何度も重ねた結果、最初はちゃんと守っていたプロジェクトのルールを、AIが完全に無視するようになった事例もあります。

さらに、自動圧縮にはタイミングの悪さもあります。オートコンパクションが走るのは、コンテキストをかなり使い切った段階です。つまり、AIの注意がもう薄まって判断力が落ちている状態で、その判断力が落ちたAI自身に要約を作らせることになります。当然、できあがる要約も質が低い。手動の/compactでも、8〜9割まで膨らんでから打つと、同じことが起きます。

圧縮するだけでもトークンを使う

もうひとつ見落とされがちなのが、コストです。圧縮はタダでコンテキストを減らしてくれるわけではありません。 /compactは中で「別のAI呼び出し」をするので、打つたびにトークンを消費します。

何にトークンを使うかというと、要約を作るためにそれまでの会話を全部いったんAIに読ませます。つまり「いま抱えている長い会話の全トークン分」を一度払い、さらに要約を書く分のトークンもかかります。公式の説明にも「会話全体を読ませて要約を作るので、追加で料金がかかる」と明記されています。

ここに、頻発が割に合わない理由がもうひとつあります。/compactは「コンテキストを減らす」コマンドなのに、減らすために「その時点の会話を全部いったん読む」コストがかかる。使用率が高い(=会話が長い)ほど、1回あたりのコストも大きくなります。こまめに圧縮を挟むと、そのたびに全部を読み直すことになり、トークンの効率ではかえって損をする場面が出てきます。

直前まで使っていた会話の多くはキャッシュに残っているので、コストの一部は割安で済むことが多いです。とはいえ「圧縮はタダじゃない」「会話が長いほど高くつく」という性質は変わりません。情報が消える点だけでなく、お金の面からも、やみくもな頻発は得になりません。

引数で「残す・消す」を指定する

/compactは、引数を渡すと「何を優先して残すか」を指定できます。ここで大事な注意点があります。引数で書いた内容は、もとの要約指示に付け足されるのではなく、まるごと置き換わります。 「これも残してね」と付け足すつもりで書くと、もともとあった「状態・次にやること・学んだことを残す」という指示が消えてしまう、ということです。引数を使うなら、残してほしいものを過不足なく書く必要があります。

引数なしで打つとどうなるか

引数なしの/compactは、「やっていること・今の状態・大事な発見・次にやること・引き継ぐ前提」の5つの枠に沿って、AIが自分の判断で要約します。

何を優先するかはAI任せです。今の会話でどうしても残したいもの——採用しなかった方針、守るべき制約、特定のファイル名など——が、引数なしで確実に残る保証はありません。大事な情報があるなら、引数ではっきり指定したほうが確実です。

「残す・要約・捨てる」を分けて書くテンプレート

いちばん細かく指定できるのが、「KEEP（そのまま残す）／SUMMARIZE（要約してよい）／DROP（捨ててよい）」の3つに分けて書く形です。

/compact
KEEP:
- 今の目標と、完了の条件
- 変更したファイルと、その理由
- 重要なコード上の判断と、ボツにした案
- 未解決のバグ、失敗中のテスト、試したコマンド
- 直近5往復のやり取り
SUMMARIZE:
- 序盤の調査
- 終わったデバッグの過程
- 雑談的なやり取り
DROP:
- くり返しのテスト出力
- もう関係ない長いログ
- すでに捨てたアイデア

デバッグの途中で圧縮せざるを得ないときは、デバッグに絞った指示が便利です。「元のバグ、再現手順、エラーの内容、試した仮説、調べたファイル、試した修正、今いちばん怪しい原因、次に確認すること」を残すよう書きます。引数は英語でも日本語でも動きますが、英語のほうが要約が安定しやすい傾向があります。

CLAUDE.md に書くか、その場で渡すか

「残してほしい指示」をどこに書くかは、その情報の性質で決めます。

情報の性質	書く場所
毎回必要な、ずっと使うルール	CLAUDE.mdに書く（圧縮後もよみがえる）
セキュリティなど、絶対に守るルール	CLAUDE.md または CLAUDE.local.md
その会話だけ残したい指示	/compact [引数] でその場で渡す
タスクの目標や、やりかけの引き継ぎ	HANDOFF.mdなど別ファイルと組み合わせる

公式の方法として、CLAUDE.mdに## Compact Instructionsという見出しを足すと、自動圧縮のときにも毎回その指示が効く、というやり方があります。ただ、筆者はこれをおすすめしません。むしろアンチパターンだと思っています。

理由は、CLAUDE.mdは毎ターンまるごと読み込まれるからです。だからCLAUDE.mdはできるだけ短く保ちたい。そこに「圧縮のときは何を残せ」という指示まで常駐させると、本来のルールがその分だけ埋もれて、コンテキストも余計に食います。圧縮のための指示が、毎回のコンテキストを重くしている——これは本末転倒です。

何を残すかを決め打ちしたいなら、その指示を自分用のスキル（スラッシュコマンド）として作っておくのがすっきりします。KEEP/SUMMARIZE/DROPのテンプレートをコマンド1つにまとめておけば、CLAUDE.mdに変な行を足さずに、圧縮したいときだけ呼び出せます。CLAUDE.mdは本来のルールだけに絞って、軽いまま保てます。この方法が効くのは手動で/compactを打つときだけですが、そもそも自動圧縮は質が落ちやすいので、次に説明する「自動を待たずに自分で打つ」運用と相性がいいです。

CLAUDE.md自体も、長くなりすぎると重要なルールが埋もれます。細かいルールは別ファイルに分け、CLAUDE.mdには入り口だけ残すのが実用的です。目安は200行以内です。

どのタイミングで打つか

/compactは、いつ打つかで要約の質が大きく変わります。コンテキストを使い切ってから打つと、もう判断力が落ちたAIに要約させることになり、質の低い要約しか出てきません。自分でタイミングを選べるなら、早めに動くのが正解です。

8割を超える前に、自分から打つ

いい要約が出やすいのは、使用率が6割くらいの段階です。この時点ならAIはまだ会話全体をちゃんと見られるので、要点を正しく拾えます。「7〜8割で」という人もいますが、どちらにしても共通しているのは「8割を超える前に、自分から打つ」という点です。

使用率は/contextコマンドで確認でき、claude codeの場合、/statuslineを設定すれば画面に常に表示できます。「自動圧縮まで残りわずか」という警告が出てから動くのでは遅いです。4割あたりから序盤の指示への注意が弱まり始め、6割を超えると答えの質の低下が目に見えてくる、という見方もあります。

作業の区切りで打つ

使用率だけでなく、作業の区切りも大事な目安です。機能を作り終えたとき、リファクタリングが一段落したとき、バグを直し終えたとき——こういう区切りで圧縮するのが理想です。作業の途中で圧縮が走ると、中途半端な状態を引き継ぐことになって、再開が面倒になります。ひと区切りついてから打つほうが、すっきり続けられます。

圧縮したあとは、「今の状況と次にやることをまとめて」とAIに聞いて、必要な情報が残っているか確かめると安全です。もし大事なことが消えていたら、/rewind（Escを2回）で前の時点まで巻き戻せます。

/compact と /clear の使い分け

コマンドを間違えると、かえって悪化します。判断はシンプルです。

状況	選ぶコマンド
同じ作業の途中で、会話が長くなった	/compact [残す指示]
関係ない別の作業を始める	/clear
同じ問題を2回以上直してもらった	/clearして、指示を直して始め直す
「同じミスのくり返し」に入った	/clear
長い仕様決め・計画が終わった	仕様をファイルに書き出し/clear→それを読んで実装

表に出てくる「/clear」と「新しい会話を始める」は、ほぼ同じ意味です。/clearが会話を空にして、その場で新しい会話に切り替えるコマンドだからです（消した会話は/resumeで戻せます）。「別の作業に移るときは会話を一度まっさらにする」と覚えておけば十分です。

ひとつ注意があります。/clearは会話を全部消すので、長い仕様決めや計画のあとにそのまま/clearすると、せっかく固めた内容まで消えてしまいます。だから「仕様や計画をいったんファイル（仕様書のMarkdownなど）に書き出させてから/clearし、新しい会話でそのファイルを読み込んで実装に入る」という順番にします。会話の中身は消えても、ファイルに残した仕様は残るので、まっさらな状態から実装を始められます。この「ファイルに書き出してから/clear」のやり方は、あとのそもそも圧縮に頼らない作り方でくわしく扱います。

同じ問題を2回以上直してもらう状況になったら、その会話はもう失敗した試みで散らかっています。/compactで引きずるより、/clearして、学んだことを反映した具体的な指示で始め直したほうが、たいていうまくいきます。

なお、デバッグの最中に/compactを打つと、AIが積み上げてきた考えの流れが切れてしまうことがあります。デバッグ中に変な方向へ進み始めたときは、/compactより/rewindで巻き戻すほうが安全です。

そもそも圧縮に頼らない作り方

最新のAIでも、圧縮だけで長い作業を乗り切るのは難しいのが実情です。/compactはあくまで一手段で、CLAUDE.md・別ファイル・サブエージェントと組み合わせて、そもそも圧縮が要らない状態を作るのが現実的です。

ずっと使う知識は CLAUDE.md に集める

CLAUDE.mdは圧縮しても読み直されて戻ってくるので、会話をまたいで残したいことの置き場として使えます。残したいルールは、プロジェクトのいちばん上のCLAUDE.mdに集めるのが基本です（サブフォルダのCLAUDE.mdは圧縮後に消えるので、常設ルールには向きません）。

書く内容は「これを消したらAIがミスするか？」で判断し、ミスしないものは削ります。具体的で、守れたか確かめられる指示だけを残しましょう。AIが自分でメモを書いて次の会話に引き継ぐ仕組み（MEMORY.md）も使えます。先頭200行が毎回自動で読み込まれます。

「ファイルに書き出してから/clear」で続ける

複雑な作業では、/compactで圧縮するより「いったんファイルに書き出してから/clearする」ほうが、うまくいく場面があります。会話の進み具合や決めたことをファイルに書き出させ、/clearで会話を消して、新しい会話でそのファイルを読み込む、という流れです。

この方法のいいところは、何を残すかを自分で選べる点です。引き継ぎメモには「何を作ったか」「守るべき制約」「採用しなかった案とその理由」「分かっているバグ・未解決の問題」「次にやること」の5つを書いておくと、新しい会話でもそのまま続けられます。何度も圧縮を重ねるより情報がしっかり残り、/compactをまったく使わずこの方法だけでやっている人もいます。

長く続く設計の話し合いでは、圧縮よりこのファイル書き出しのほうが信頼できると個人的にも感じています。何が残るかが自分の手の中にあるからです。

ここまで読むと、「じゃあ/compactにも欠陥があるんだから、コントロールできる/clearに一本化でいいのでは？」と思うかもしれません。実際それはかなり正しくて、/compactを一切使わずこの方法だけでやっている人もいます。

それでも/compactが勝つ場面が、ひとつだけあります。見分ける鍵は、いまの状態をファイルにきれいに書き出せるかどうかです。

「書き出してから/clear」には隠れた前提があります。それは「いまの状態を言葉にできる」こと。これが成り立つのは、たいてい作業のキリがいいときです。仕様が固まった、フェーズが終わった——こういうときは状態をそのまま書き出せるので、いい引き継ぎファイルが書けるし、/clearで気持ちよく仕切り直せます。ここは「書き出してから/clear」の圧勝です。

問題は、キリが悪い"作業の途中"です。たとえば、あるバグを1時間以上追っていて、たくさんのファイルを読み、テストを何度も回し、いくつもの仮説を潰して、いままさに核心に迫っている——でも作業は終わっていない、という状況。ここで/clearするには、「潰した仮説と、その理由」「いまの最有力の筋」「正確なエラー文」を全部ファイルに書き出さないといけません。手間な上に、ひとつ書き漏らすと、潰したはずの仮説をまた一から歩くことになります。「書き忘れたら終わり」という弱点が、いちばん牙をむくのがこの"途中"なんです。状態がまだ頭の中で動いていて、きれいに言葉にできないからです。

この"途中"でこそ/compactが効きます。/compactは直近のやり取りはほぼそのまま残すので、いま頭にある推論の流れや正確なエラー文が生きたまま残ります。捨てられるのは古いコマンド出力のようなゴミ——あとでファイルを読み直せば取り戻せる、再生可能なノイズ——だけ。同じ息で作業を続けられます。

整理すると、両者は「どちらも欠陥のある同じ道具」ではなく、得意な場面が逆です。状態をきれいに書き出せるキリのいいところでは「書き出してから/clear」、まだ書き出せない作業の途中では/compact。「書き出してから/clear」の弱点が最大になる場所で、ちょうど/compactの弱点は最小になる(捨てるのが再生可能なノイズだけになる)——だから一本化ではなく、場面で選ぶのが現実的です。

サブエージェントで作業を切り離す

サブエージェントは、本体の会話とは別のところで動く「子のAI」です。子のほうでファイルを読んだり試行錯誤したりしても、その散らかりは子の中だけに収まり、本体には短い結果だけが返ってきます。

コードの調査、独立したチェック、並行作業など、途中で散らかりがちな作業を子に任せれば、本体の会話をきれいに保てます。「このコードを、抜け漏れがないかレビューして」のように、作った本人のクセに引きずられない第三者チェックにも使えます。子の調査コストが本体にたまらないのが、いちばんのメリットです。

「うまく使う」より「使わずに済ませる」

/compactは、問題が起きてから使う応急処置です。CLAUDE.mdが整理され、重い作業がサブエージェントに切り離されていれば、そもそも圧縮が必要になる回数自体が減ります。/compactを上手に頻発する方法を探すより、圧縮しなくて済む状態を先に作るほうが、長い目で見て効きます。

筆者自身、最初は引数なしで頻発していました。「何かおかしい」と感じて振り返ると、使用率が高い状態での引数なし圧縮が重なっていたのが原因でした。いまは、何を残すかを決めたテンプレートを自分用のコマンドにしておき、8割を超える前に手動で打つ。大きな区切りでは、仕様や進捗をファイルに書き出してから/clearする。この2つだけで、やみくもな頻発はほとんど要らなくなりました。