[AIコンテキスト #3] /clear と /compact の選び方

前の2回で診断は終わりました。コンテキストウィンドウには上限があり（第1回）、埋めればすべて使われるわけでもなく、長くなるほどむしろ性能が落ちます（第2回）。処方箋は明確です。コンテキストを管理する必要があります。そのための最も基本的なツールが、Claude Codeをはじめとするコーディングエージェントの/clearと/compactです。

どちらのコマンドも「コンテキストを減らす」点は同じです。そのため適当に使ったり、残量警告が出るまで使わなかったりしがちですが、動作原理はまったく異なります。状況に合わない使い方をすると、作業の文脈を丸ごと失ったり、逆に汚れたコンテキストを引きずり続けたりします。今回は、各コマンドが内部で何をしているのかを確認し、使い分けの基準を定めます。

/clear：履歴を消して白紙から始める

/clearの動作は単純です。それまでの会話履歴をすべて破棄します。次のターンのモデルは、システムプロンプトとCLAUDE.mdのような常時ロードされるファイル、そして直前に入力した新しいメッセージだけを持って開始します。第1回で見た構造を思い出せば意味は明確です。会話の実体は毎ターン履歴全体を再送することなので、履歴を消すとはモデルに送るパッケージを初期化することです。

失うのは会話コンテキスト全体、得るのはクリーンなコンテキストです。第2回で見たlost in the middleも、古いファイル版や失敗ログによる混乱も、履歴が消えれば同時に消えます。トークンの残量は最大まで回復し、毎ターン再送する入力も減るため、応答は速くなりコストも下がります。

つまり/clearは作業の境界で使うものです。バグを修正してコミットまで終えたなら、次の機能作業に以前のバグのスタックトレースや試行錯誤は不要です。混ぜると害になるだけです。作業が終わるたびに/clearで区切るだけで、セッション後半の品質低下をかなり防げます。

/compact：履歴を要約に置き換える

/compactは別の方法を取ります。履歴を捨てる代わりに、これまでの会話をモデルに要約させ、その要約で元の履歴を置き換えます。数万トークンの履歴が数千トークンの要約に縮まり、残量を回復しながら作業の大筋を残せます。

重要なのは、これが不可逆の圧縮だという点です。要約はモデルが「重要そうなもの」を選ぶ過程であり、何が残るかをユーザーは制御できません。ファイルパス、試してやめたアプローチ、エラーメッセージの正確な文言など、具体的な細部は要約でぼやけやすくなります。compact直後のエージェントが直前まで触っていたファイルを読み直すのも、要約だけでは正確な状態が分からないためです。

幸い、制御手段がないわけではありません。Claude Codeの/compactには後ろに指示を付けられます。「/compact 今回のマイグレーションで確定したスキーマ変更と残りのファイル一覧を中心に残して」のように書けば、要約の焦点を指定できます。何が重要かはユーザーが最もよく知っているので、圧縮を任せる場合でも方向は示しましょう。

選択基準：引き継ぐコンテキストがあるか

基準は一つの質問に集約できます。次のターンのエージェントは、ここまでの文脈を知る必要があるか。

• 作業が終わり、次の作業は別物だ → /clear。迷う必要のないデフォルトです。
• 同じ作業が続いているが残量が足りない → /compact。ただし、残すものを指示で指定します。
• 同じ作業なのにエージェントが迷走し始めた → 意外にも/clearのほうが適しています。試行錯誤で汚染されたコンテキストは、要約しても汚染が濃縮されるだけです。現在の状態と次にやることをファイルに整理させ、/clear後にそのファイルから再開するほうがクリーンです。

3つ目のケースがヒントになります。clearとcompactの間には第三の道があります。コンテキストから残したい内容をファイルに書き出すのです。「ここまでの決定事項と残りの作業をPLAN.mdに整理して」と依頼してから/clearし、新しいセッションでPLAN.mdを読ませれば、要約の不確実性なしに必要な文脈だけを正確に引き継げます。残す内容が目に見えるファイルとして存在するため、要約をモデルに任せる/compactと違って検証も修正もできます。この「外部化」パターンは、第6回でメモリを扱う際に詳しく掘り下げます。

auto-compactを待ってはいけない理由

Claude Codeは残量がしきい値に達すると自動でcompactを実行します。安全装置としては優秀ですが、これに依存するのは別の問題です。

auto-compactの発動時点はトークン残量が決めます。作業の流れとは無関係です。リファクタリングが半ばで、5つのファイルを修正中、テストも壊れているという最悪のタイミングで圧縮される可能性があります。その時点の要約は中途半端な状態をひとまとめにし、その後のエージェントは微妙にずれた理解で作業を続けます。第2回で見たcontext poisoningが、要約を経路にして起きるわけです。

だからこそ、熟練者ほど残量表示をゲージのように管理します。コミット、テスト通過、決定の確定といった論理的な区切りごとに状態をファイルへ整理し、残量が20〜30%になったら区切りを付け、自分で/clearや/compactのタイミングを決めます。圧縮を避けられなくても、いつ、どのように圧縮するかは制御できるのです。

まとめ

• /clearは履歴の削除、/compactは要約への置き換えです。前者はコンテキストを捨てて残量を最大まで回復し、後者は細部を失う代わりに文脈の大筋を残します。
• 基本は作業の境界ごとに/clearです。引き継ぐ文脈があるときだけ/compactを使い、残す内容を指示で指定します。
• エージェントが迷走したら、要約ではなく状態をファイルに整理させ、/clearで再開するほうがクリーンです。
• auto-compactは安全装置にすぎません。圧縮のタイミングは作業の区切りに合わせて自分で決めるのがよいでしょう。

ここまでが会話履歴の管理です。ただし、/clearを実行しても消えず、毎ターン送られるコンテキストがあります。システムプロンプト、CLAUDE.md、ツール定義などの常時ロード領域です。次回は、この固定コストを設計する方法を扱います。CLAUDE.mdに何を入れ、何を外すかが核心です。

あわせて読みたい

• AIエージェントのメモリ設計：コンテキストの外に置く技術（計画ファイル・メモリ・RAG）
• [エージェント設計 #1] ハーネスエンジニアリングとは？プロンプトの次に来るもの