この記事についてClaude（Anthropic）との共同編集により作成されました。
要約
- Claude Code で調査資料を育てながら作業していて、区切りで
/compactを打ったら、会話では「書く」と合意していたはずの内容が資料から抜けていた。/compactに残すものの指示を付けても、一度漏れた- 今は、コマンドを打つ前に自然文で「これから
/compactする。資料の記載漏れを確認して、足りなければ書いてから宣言して」と宣告するのを必須にしている。これで漏れが止まった- 効いているのはコマンドではなく、文脈がまだ全部見えているうちに、モデルへ最後の点検ターンを1回渡していること。
/clearも/compactも CLI 側の処理で、モデルが「最後に資料を見直す」ターンはどこにもない- 同じ型の小技は公式・コミュニティの両方にある。消す前にディスクへ落とす／圧縮を steer する／圧縮後に読み直させる／フックでゲートするの4系統に整理した
- 宣告は製品機能ではなく運用の話。ただしメカニズムは公式のコマンド仕様と整合していて、
PreCompactフックで機械化する道もある
Claude Code で調査資料を書かせながら会話を続けていると、コンテキストがだんだん重くなる。区切りのいいところで /compact を打つ、というのはたぶん誰でもやっている。
私の場合、それをやった直後に資料を開いて固まった。会話の中で「これも資料に足しておこう」と合意していた項目が、資料に無い。要約のほうには「足す」と書いてあったのかもしれないが、圧縮後のセッションはそれを覚えていないし、私も何を落としたか正確には思い出せない。
しかも一回ではなかった。/compact にフォーカス指示を付けて「資料の未記載を残せ」と書いてやったときも、漏れた。指示付きなら安全だと思っていたので、これはちょっと堪えた。
で、いま落ち着いた運用がこれだ。コマンドを打つ前に、自然文で宣告する。
これから /compact する。資料に書くと言ってまだ書いていないことがないか確認して、足りなければ書いてから「準備できた」と言ってClaude が資料を直し、準備できたと返してから /compact を打つ。これを必須にしてから、記載漏れは起きていない。
この記事では、なぜこれが効くのかを Claude Code の仕組み側から整理して、同じ型に属する小技を公式ドキュメントとコミュニティの運用記事から集めた。宣告そのものは私の運用上の発見で、公式の推奨リストにあるものではない。ただ同じ考え方の手は公式側にもいくつかあって、それを知っておくと宣告の位置づけがはっきりする。
なぜ宣告が効くのか
/clear と /compact は、普通のメッセージとは違う。CLI が会話を消すか要約するかの処理に入り、モデルに「最後に資料を見て直して」と頼むターンが残らない。
/clear は会話履歴を空にする。プロジェクト直下の CLAUDE.md やディスク上のファイルは残るが、会話の中だけで合意した「あとで書く」は消える1 2。
/compact は履歴を要約で置き換える。公式ドキュメントも損失があると明記していて、序盤の細かい指示は落ちることがある3 4。自動圧縮に至っては、コンテキストが上限に近づいた瞬間に走るので、作業の区切りとは無関係だ。Anthropic のセッション管理の解説では、長いデバッグのあとに「さっき見た別の警告も直して」と頼むと、要約側がデバッグの話だけ残して警告のほうを落としていた、という失敗例を挙げている5。
だから宣告は、コマンドを遅らせているだけではない。まだ全部見えているうちに、モデルへ最後の点検ターンを渡している。フォーカス指示付きの /compact でも漏れたのは、要約を作る側が「何を残すか」を判断するのであって、「資料にまだ書いていないものは何か」を調べて書く作業はしないからだと思っている。前者は圧縮のパラメータで、後者はもう1ターンぶんの仕事だ。
資料作成のように「会話にしかない未記載」が多い作業では、git diff だけを見るサブエージェントより、今のセッション自身に漏れを聞かせるほうが当たる。差分に現れないものは、差分から探せない。
もうひとつ大事なのは、点検結果を会話に置いたままにしないことだ。宣告して漏れを指摘させただけだと、その指摘は会話に残り、そのあと /clear するとまた消える。漏れを直したファイル、あるいは後述する HANDOFF.md まで書いてからコマンドを打つと、点検が残る。私の宣告文に「書いてから」と入っているのはそのためだ。
同じ型の小技7つ
ここから先は、宣告と同じ「消す前に、残っている文脈でディスクへ落とす／点検させる」系統だけを書く。一般的な Claude Code tips の総覧ではない。公式が推しているものとコミュニティの運用習慣を混ぜているので、どちらかは都度明記する。
1. 消す前に HANDOFF.md を書かせる（コミュニティ）
宣告のディスク版。コミュニティでいちばん繰り返されている型は、リセット前に状態を Markdown へ書かせ、目視してから /clear するか /compact するか決める、というものだ6 7。
書かせる項目の型はだいたい同じになる。
- 今のゴールと受け入れ条件
- 触ったファイルと、触った理由
- 採用した判断と、捨てた案
- 試して失敗したこと
- 残作業と、次の一手
ykdojo の tips 集では、ファイルパスだけを次のセッションへ渡す運用まで落としている8。Plan Mode を使って「次のエージェントは他の文脈を持たない」と明示し、計画をディスクに残したうえでコンテキストを捨てるやり方もある。公式のコンテキストウィンドウ解説では、Plan Mode で書いた計画は圧縮後にディスクから再注入される、とある9。
宣告との違いは、点検結果の置き場所だ。宣告は「資料本体を直させる」、HANDOFF.md は「資料に入らない作業状態を別ファイルに残す」。両方やる場面もある。
2. /compact に残すものを書く（公式）
手動の /compact にはフォーカス指示を付けられる。自動圧縮にはこの引数がない3 4。
/compact 資料の未記載、採用した判断、次に書く節を残す。探索ログと繰り返しのコマンド出力は捨てるCLAUDE.md に Compact Instructions を書いておくと、手動でも自動でも同じ保持方針が乗る。公式の例は「変更ファイルの一覧とテストコマンドを必ず残す」という短い一文だ3。KEEP / SUMMARIZE / DROP を並べる長いテンプレはコミュニティ側の拡張で、公式の必須項目ではない6。
冒頭に書いたとおり、私はこれだけでは漏れた。指示は「残すもの」を選ばせるだけで、「まだ書いていないもの」を書かせはしない。宣告の代替ではなく、宣告のあとで圧縮するときの補助として使っている。
会話だけで伝えた「サブエージェントは直列だけ」のような制約も、CLAUDE.md に無いと圧縮後に消えることがある。Nathan Onn の記事は、その制約が消えて並列エージェントが一度に十本立ち上がった、という失敗談を出発点にしている6。
3. /rename してから /clear する（公式）
/clear は会話を空にするが、transcript 自体は残る。/rename してから消すと、あとで /resume や claude --resume で戻れる1。
戻るつもりがないなら rename は不要だ。戻るかもしれない作業を名前のないまま消すと、後から拾いにくい。宣告と組むなら、点検させて資料を直す → /rename → /clear の順になる。
4. 圧縮のあと、ディスクを読み直させる（公式）
圧縮後に確実に戻るのは、プロジェクト直下の CLAUDE.md、auto memory、Plan Mode の計画、システム側の再注入分だ。サブディレクトリの CLAUDE.md と paths: 付きルールは、対象ファイルを再度読むまで戻らない。会話の途中でフックが足した文脈は、要約に巻き込まれる2 9。
2026年9月時点の公式ドキュメントでは、圧縮後に直近で読んだ・編集したファイルを最大5つまで再読する、とも書いている。5000トークンを超えるファイルは中身を再読せず、パス参照になる9。バージョンで変わりうる挙動なので、この数字は目安として見てほしい。
だから圧縮直後に「資料と今の git diff を読んでから続けて」と一度言ったほうが安定する。公式の hooks ガイドは、同じことを SessionStart フックの compact matcher で機械化できる、と説明している。標準出力に出した文言が、圧縮後のコンテキストへ入る10。
5. 失敗した分岐は圧縮せず /rewind する（公式）
間違った実装を「ダメだった、別案で」と会話に積み上げると、失敗の痕跡が要約へ混ざる。公式の勧めは、ファイルを読んだ直後まで戻して、学んだ制約だけを新しいプロンプトに書くことだ。Esc 二回、または /rewind3 5。
rewind メニューには Summarize from here / Summarize up to here もある。会話の一部だけを要約し、残りは全文のまま残す。Anthropic はこれを、未来の自分から過去の自分への申し送り、と表現している5。
「直して」を二回以上繰り返したあとは、公式ベストプラクティスも /clear して学んだことを最初のプロンプトに書き直すほうを勧めている。長い訂正履歴より、短い正しい依頼のほうが勝つ、という整理だ3。
6. 調査と検証はサブエージェントへ出す（公式）
メインの会話に残したいのは結論だけで、途中のファイル読みは残したくない、というときにサブエージェントを使う。Anthropic の判断基準は「このツール出力を後でもう一度見るか、結論だけあればよいか」だ5。公式は、仕様ファイルを渡して検証させる、別リポジトリの実装を要約させて本体で再現する、git の差分を見てドキュメントを書かせる、を例にしている5。
ただし資料作成では使い分けがある。git に現れた差分の説明ならサブエージェントで足りる。会話の中にしかない「書くと言ったのにまだ書いていない」は、今のセッション自身に確認させたほうが拾える。宣告が効いたのは、こちらの漏れだった。サブエージェントは親の会話を持っていないので、親の会話にしかない約束を探せない。
7. コンテキストメーターを常時出す（公式＋コミュニティ）
/context は、今のウィンドウを何が何トークン使っているかを出す9。ステータスラインに使用率を出す設定もあり、私は以前の記事で書いた構成をそのまま使っている。数字を見てから区切りを探す、という運用になる。
コミュニティ記事には「30%で区切りを意識、60%超で大きな新規作業を始めない」といった帯がある6。これは Nathan Onn 個人の経験則で、公式の閾値ではない。公式が言っているのは、自動圧縮を待たず、作業の区切りで手動圧縮するか、無関係なタスクなら /clear する、という分岐だ3 5。
ただ、私はこの帯を目安として気に入っている。公式の「作業の区切りで」は正しいが、区切りがどこかは打ってみないと分からない。30%を越えたらそろそろ宣告して圧縮する場所を探す、60%を越えたら新しい調査や実装を始めずに今の作業を畳みにいく、と数字で決めておくと、ステータスラインの数字を見た瞬間に次の手が決まる。閾値そのものより、「数字を見たら何をするか」が先に決まっていることに価値がある。
1M コンテキストでも context rot（窓が広いほど注意が散り、古いノイズが今の作業を邪魔する）は残る。長いから放置してよい、という意味ではない5。
公式の分岐表と、その前に足す一段
Anthropic のセッション管理の解説が置いている分岐は、上の小技を選ぶときの軸になる5。
| 今の状態 | 手 | 理由 |
|---|---|---|
| 同じ作業で、今の文脈がまだ効いている | 続ける | 作り直すコストのほうが大きい |
| 方針を間違えた | /rewind | 失敗を要約に残さない |
| 同じ作業の途中だが、探索ログが重い | /compact に指示を付ける | 何を残すかを自分で決める |
| 本当に別の作業へ移る | /clear | 古い文脈を持ち込まない |
| 途中出力は不要で結論だけ欲しい | サブエージェント | ノイズを子の窓に閉じる |
資料を育てながら作業しているセッションでは、この表の前に一段足す。コマンドを打つ前に、自然文で宣告して記載漏れを確認させる。必要なら HANDOFF.md も書かせる。それから表の手を選ぶ。
宣告をフックで固定する
宣告は毎回の手間だ。同じ漏れを何度も踏むなら、フックに落とせる。
公式の PreCompact フックは圧縮の直前に走り、圧縮をブロックできる。matcher は manual と auto11。コミュニティの handoff プラグインには、新しい HANDOFF.md が無い圧縮を止めて「先に /handoff せよ」と返す実装がある12。同種の handoff ツールは他にも公開されている13。
圧縮後の再注入は、前述の SessionStart + compact matcher が公式の例だ10。PostCompact フックもあるが、こちらはブロックできない11。
カスタムスラッシュコマンドや skill で /handoff を自作するやり方もある。既存の HANDOFF.md を読んで更新し、ゴール・進捗・うまくいったこと・失敗・次の一手を揃える8。宣告を忘れやすいなら、コマンド名自体を点検儀式にするほうが続く。
ただしフックは、例外なく動かしたい処理向けだ。公式も、CLAUDE.md は助言、フックは決定的、と分けている3。毎回の資料点検までフックにすると、短い作業でもゲートに引っかかる。私はまだ手で宣告している。漏れが再発する作業だけ機械化する、で今のところ足りている。
会話に残さず、ディスクに残すもの
圧縮や clear のあとで残したい指示は、ディスクへ置く。公式の切り分けははっきりしている2 4。
- 残るもの: プロジェクト直下の CLAUDE.md、スコープなしの rules、auto memory、Plan Mode の計画
- 残りにくいもの: 会話だけの指示、
paths:付きルール、サブディレクトリの CLAUDE.md、フックが途中で足した文脈
ここで CLAUDE.md にタスクの途中経過を書きたくなるが、それは毎セッションの固定コストになる。公式は「広く当てはまることだけ書け。外してもミスが増えない行は削れ」と繰り返している3。途中経過は HANDOFF.md か、その作業用の資料本体へ置く。
まとめ：資料を育てるセッションでの手順
私が今やっている順番はこうだ。
- 「これから
/clear（または/compact）する。資料の記載漏れを確認して、足りないところを書いてから宣言して」と打つ - Claude が資料を直す。必要なら HANDOFF.md も残す
- 戻るつもりなら
/rename - 別作業なら
/clear。同じ作業を続けるなら、残したいものを書いた/compact - 圧縮した直後は、直した資料と git diff を読み直させてから次の作業へ入る
1の宣告をいつ打つかは、ステータスラインのコンテキスト使用率で決めている。30%を越えたら区切りを探し始め、60%を越えたら新しい作業を始めない。
実装セッションで探索ログが太いときは、4の前にサブエージェントへ調査を逃がす。失敗した実装は compact せず rewind する。
宣告を CLAUDE.md の常設ルールにするか、/handoff コマンドにするか、PreCompact で強制するかは、まだ決めていない。漏れの頻度を見てからでいいと思っている。今の実感が「宣言すると解消された」なら、まず手の宣告を型として固定するほうが先だ。
参考文献
- Claude Code sessions https://code.claude.com/docs/en/sessions
- Claude Code memory（
/compact後に指示が消える場合を含む） https://code.claude.com/docs/en/memory - Best practices for Claude Code https://code.claude.com/docs/en/best-practices
- How Claude Code works https://code.claude.com/docs/en/how-claude-code-works
- Using Claude Code: session management and 1M context https://claude.com/blog/using-claude-code-session-management-and-1m-context
- Never Let Claude Code Auto-Compact Again (Nathan Onn) https://www.nathanonn.com/claude-code-never-auto-compact/
- Continuum Code, Claude Code context window https://continuumcode.ai/guides/claude-code-context-window/
- ykdojo/claude-code-tips（Tip 8: Proactively compact / handoff） https://github.com/ykdojo/claude-code-tips/
- Explore the context window https://code.claude.com/docs/en/context-window
- Hooks guide（圧縮後の再注入例） https://code.claude.com/docs/en/hooks-guide
- Hooks reference（PreCompact / PostCompact） https://code.claude.com/docs/en/hooks
- mehmeteminduran/claude-session-handoff-plugin https://github.com/mehmeteminduran/claude-session-handoff-plugin
- Sonovore/claude-code-handoff https://github.com/Sonovore/claude-code-handoff