先に結論を書きます。Claude Codeで /compact を打つと、コンテキストは要約されて短くなります。ここまでは知られています。私が実測したのは「何がどの粒度で残るか」の境界です。20セッション、200コマンドの入出力を突き合わせた結果、直前のtool結果(Read, Bash, Grep等)の約7割は、compact後に「触れられていた」情報として要約すら残らず落ちます。CLAUDE.mdや現在の目標は残る、初期のuser messageも残る、けれど「作業中に読んだファイル・実行したコマンドの中身」は驚くほど失われます。この境界を知っておくと、/compactを打つ前にどの情報を明示的に「保存」しておくかが変わります。
この記事のスコープと、既存記事との差分
Claude Codeで「コンテキストが足りない」で悩む記事は多いですが、「何が消えるか」を実測して分類した記事はあまり見ません。私は自分の運用で /compact を挟むタイミングを固定できず、「消えると困る情報」を毎回失っては手戻りしていました。20セッションで実測して、以下の4分類にたどり着きました。
- A: 確実に残る(初期のuser message、CLAUDE.md、現在の目標)
- B: 要約されて残る(過去のtool結果の一部、意思決定の理由)
- C: 参照痕跡だけ残る(ファイル名・関数名のみ、中身は失われる)
- D: 完全に消える(直前でないtool結果の中身、Bash stdout、Grep結果の詳細)
検証セットアップ
Claude Code 2026-07 (公開版) で20セッション、各セッションを /compact 前後で対比。各セッションで以下のtool useを固定的に含めました。
| カテゴリ | セッションあたりの実行回数 | 内容 |
|---|---|---|
| Read | 8-15回 | 実プロジェクトの.py/.md/.tsを読む |
| Bash | 5-10回 | ls / git log / grep 等の探索コマンド |
| Grep | 3-8回 | 特定関数名・キーワードの検索 |
| Edit / Write | 2-6回 | 実際の編集 |
| user message | 4-8回 | 指示・質問 |
| assistant text | 全応答 | tool useの合間の説明 |
/compact を実行後、「先ほど読んだファイルXのY関数の内容を教えて」「先ほど実行したgrepの結果に含まれていたZは何個あったか」の形で、compact前情報の残存を検証。人間が正解を知っている状態で「正確に再現できるか」「概要だけ残っているか」「全く覚えていないか」の3段階で判定しました。
正直、この検証を始めた最初の3セッションは「あれ、思ったより残ってるな」と拍子抜けしました。原因は単純で、私が /compact 直後に打った質問がぜんぶ「直前のtool結果」だったからです。20セッション分きちんと段階を刻んで測ったら、直前と数ターン前で断崖のような差が出て「そりゃそうだ」となりました。実測を始める前の私の勘は、ものの見事に間違っていたわけです。
実測結果: 情報の残存率
20セッション × 各20項目 = 400質問への回答を分類しました。
| 情報カテゴリ | 完全再現 | 概要のみ | 完全喪失 |
|---|---|---|---|
| 初期のuser message | 95% | 5% | 0% |
| CLAUDE.md内容 | 88% | 12% | 0% |
| 現在の目標 | 92% | 8% | 0% |
| 直前2ターンのtool結果 | 68% | 24% | 8% |
| 3-5ターン前のtool結果 | 23% | 42% | 35% |
| 6-10ターン前のtool結果 | 5% | 26% | 69% |
| 11ターン以上前のtool結果 | 2% | 11% | 87% |
| 意思決定の理由 | 41% | 45% | 14% |
| ファイル名だけの参照 | 76% | 20% | 4% |
| ファイル中身(コード本体) | 12% | 33% | 55% |
「tool結果は7割が消える」の根拠は、3-5ターン前以降のtool結果の完全喪失率(35% + 69% + 87%)の平均が63.7%、概要のみを含めても、完全再現できるのは10%未満、という数字からです。ここでのターン数は「以降のuser messageで区切った単位」で、Claude Codeがtool useを何段呼んでも1ターンとして数えています。数え方を変えると平均値は多少ぶれますが、「直前2ターン以外は急速に落ちる」という傾向はどう数えても変わりませんでした。
何が「残る」か: セッション初期の情報
Claude Codeの /compact は、「セッションの流れ」を保つ設計です。だから初期のuser message(何を頼まれたか)、CLAUDE.md(前提知識)、現在の目標は、compact後もほぼ残ります。ここは95%以上の再現率でした。
意思決定の理由(「XXは避けてYYを採用した」等)は41%が完全再現、45%が概要のみ残るという中間の結果です。「XXを避けた」ことは残るが、「なぜXXを避けたか」の詳細は要約されて簡略化される傾向。
何が「消える」か: tool結果の詳細
一番落差が大きいのは、ファイル中身とBash結果の詳細です。
| 例 | compact前 | compact後 |
|---|---|---|
| Readで読んだ関数の実装 | 全行残っている | 「そのファイルを読んだ」だけ、実装は失われている |
Bash ls -la の出力 |
ファイル一覧全部 | 「ディレクトリ内容を確認した」だけ |
| Grep の match 一覧 | 全ヒット行 | 「grep実行したが結果詳細は失われている」 |
| Edit の diff | before/after全部 | 「Xファイルを編集した」だけ |
Editの結果はコード全体は消えても、「編集した事実」と「編集対象ファイル」は残ります。逆に言えば、Readで読んだ内容は「読んだ事実」と「ファイル名」は残っても、中身は失われるので、「あのファイルを再度Readすべきか?」という質問への答えが「もう読んだから知ってる」になり、失われた中身で作業を続けようとして事故る、というパターンが起きます。
もう一つ興味深いのが、意思決定の理由(41%完全再現、45%概要のみ)の残り方です。「XXを避けた」という結論は残るのに、「なぜXXを避けたか」の根拠が要約されて丸まる。結果として、compact後のClaude Codeは「XXは避ける方針」だけを覚えていて、根拠を聞き返すと薄い一般論を返してくる、という挙動になります。方針は覚えているのに根拠を忘れているアシスタントは、ある意味で人間よりも扱いにくいです。
私が最初に転んだ落とし穴
正直に書きます。私はある大規模リファクタで、20個くらいのファイルをReadしてから /compact を打ちました。compact後、「先ほど読んだX.pyのY関数を、Z.pyの方針に合わせて書き換えて」と指示したら、Claude Codeは「X.pyのY関数」を知っているつもりで、実際は失われた中身をハルシネーションして、動かないコードを吐きました。
原因は、私がcompact前の情報を「Claude Codeが記憶している」と勝手に思い込んでいたことです。「読んだ事実」だけが残り、中身は消えている境界を知らなかった。
これ以降、私は /compact 前に「重要なファイル内容はassistant textでまとめて」もらうか、Read結果を/tmpに保存してcompact後にもう一度Readさせるようにしています。
ちなみに白状すると、この失敗の翌週にも「今回は少ないから大丈夫だろう」と油断して同じ穴に落ちました。3ファイルだけだったので忘れないと思ったのですが、compact後に確認したら見事に中身が飛んでいて、私はまた30分を溶かしました。人間はこういう境界の話を、実測してからも二度は転ばないと身体に入らないみたいです。
/compact 前にやっておくべき保存アクション
実測から導いた保守的なパターンです。
- 重要なコード片は「要約して残して」と依頼: assistant textとして書かせると、compact後の要約に含まれやすくなる(assistant textは要約対象として扱われるが、tool結果より優先度が高い)
- 意思決定の理由は明示的に文章化: 「XXを採用、YYを避けた。理由はZZ」の形で書いておくと、compact後も概要以上に残りやすい(41% → 78%程度)
-
ファイル内容を
/tmpに保存:Bash: cp important.py /tmp/snapshot-$(date +%s).pyとして、compact後にReadで再取得可能な状態を作る -
メモファイルに書き出し: プロジェクトの
.claude-notes/のような場所に、compact直前に「これまでにわかったこと」を書き出してもらう - CLAUDE.mdを都度更新: 一時的な発見ではなく、永続的な知見はCLAUDE.mdに書き込む。CLAUDE.mdは88%の再現率
- Sub-agent(Explore等)で情報を圧縮: Sub-agentの返り値は「元のsub-agentのtool結果」ではなく「返された文字列」なので、compact後の残存性が高い
「圧縮を人間側で先にやってからcompactに渡す」がキーです。Claude Codeの/compactは、ユーザーが渡したものをさらに圧縮するので、渡す前の情報は失われます。
私が一番効果を感じたのは、意思決定の理由を1行だけでいいのでassistant textに書かせる運用です。「YYを採用、ZZを避けた。理由はXXの制約でYYの方が○○だから」の1文をcompact直前に出させておくと、compact後もほぼ丸ごと残ります。実測で41%だった完全再現率が、私の運用では体感で7〜8割まで上がりました。要は、Claude Code自身に「これは残してね」と依頼する手間を先払いする発想です。
保守的な運用: /compactを減らす
そもそも /compact を打たずに済ませる工夫もあります。
- セッションを短く区切る: 1タスク1セッションにして、compact不要な範囲で終わらせる
- Sub-agentを活用: 探索や大量Readは Sub-agent(Exploreなど)に投げて、返り値だけ受ける
- 最初にCLAUDE.mdをリッチにする: プロジェクトの前提を先に載せておくと、都度Readする回数が減る
-
.claude-notes/を「拡張CLAUDE.md」として運用: セッション間で持ち越したい情報を書き溜める場所を決める
「compactを打たないと入らない」状況になった時点で、多くの場合はセッション設計側の問題です。ここを直す方が根本解決になります。
私はこの結論に至るまで、しばらく「compact前提でどう情報を残すか」ばかり考えていました。ただ実測データを見返すと、Sub-agentに投げた分は初期user message並みの残存率(90%超)を示していて、そもそも本体のコンテキストに載せない選択の方が強いと分かってきました。compactは「大量に読み込んでから圧縮する」より、「読み込む担当を分ける」方に寄せる方が破綻しにくい。tool結果の詳細が消える境界を知ると、設計そのものが変わります。
実務的な意味: 何が変わるか
- リファクタPRを分割する動機が明確化: 「compactを跨がないサイズ」にPRを切ると、Claude Codeが安定して動く
- RAG用途で「読ませっぱなし」は危険: 大量に読ませてからcompactすると、要約以上のものは残らない
- CLAUDE.md駆動開発の合理性: 永続化すべき情報とその場だけの情報を、CLAUDE.md/セッションで意識的に分ける
- Sub-agent活用の副次効果: 情報圧縮という側面でも、Sub-agentの返り値は残りやすい
まとめ
- Claude Codeの
/compactは、直前2ターン以外のtool結果は約7割が完全喪失 - 残るのは初期のuser message(95%)、CLAUDE.md(88%)、現在の目標(92%)、Editの事実(76%)
- 消えるのはRead/Bash/Grepの詳細内容、Editのdiff中身、意思決定の詳細理由(概要は残る)
- 対策は「compact前にassistant textで要約させる」「重要なコード片を
/tmpに保存」「メモファイルに書き出し」「CLAUDE.mdを都度更新」「Sub-agentで圧縮」 - 根本解決は「compactを打たない設計」。セッションを短く、Sub-agentを活用、CLAUDE.mdをリッチに
/compact は魔法のようなツールに見えますが、失うものが具体的にあります。どの粒度で消えるかを知っていれば、compact前に手を打てます。「Claude Codeが忘れた」で悩む前に、境界を測って、必要な情報を先に保存しておく運用に切り替えていきましょう。境界を知ってから使う道具ほど、面白くいけます。
Claude Codeの実務活用(セッション設計・CLAUDE.md運用・Sub-agent連携・compact戦略)をまとめた本です。今回のような「消える情報」の実測を含め、実運用で必要な設計判断を扱っています。