Claude Codeの/compactコマンド解説｜トークン80%削減のコンテキスト管理術【2026年】

Claude Codeを使っていて、セッション後半になると急にレスポンスが劣化する。同じことを何度も聞き返してくる。さっき決めたコーディング規約を無視する——心当たり、ありませんか？

原因はほぼ確実にコンテキストウィンドウの圧迫です。Claude Codeの200Kトークンウィンドウは広大に見えますが、ツール定義やCLAUDE.md、会話履歴を合わせると、2時間のセッションで簡単に150Kを超えます。そしてその状態で作業を続けると、古い会話が押し出されて「文脈が消える」現象が起きます。

/compactコマンドは、この問題に対する公式の解決策です。会話履歴を要約に圧縮し、トークン使用量を80%以上削減できます。実測値では150Kトークンが20〜30Kまで圧縮された例（How Do I Use AI）や、70Kトークンが約4Kまで縮んだ（94%削減）ケースもあります。

この記事では、/compactの仕組み・使いどころ・注意点を実データベースで解説します。「なんとなく使ってる」を「戦略的に使いこなす」に変えましょう。

/compactの仕組み——何が起きているのか

/compactを実行すると、Claude Codeは現在の会話履歴全体をLLMに渡し、要約文を生成します。その要約文で既存の会話履歴を丸ごと置き換える——これがコンパクションの実態です。チャットログの「圧縮」というよりは、「長い議事録を要点メモに差し替える」イメージが近いでしょう。

v2.0.64以降では圧縮処理が大幅に高速化されました。以前は数十秒待たされることもありましたが、現在はほぼ瞬時に完了します。

自動トリガーと手動実行

Claude Codeには自動コンパクション機能が組み込まれています。コンテキストウィンドウの約83.5%（200Kウィンドウで約167Kトークン）に達すると自動的に発動します。

ただし、ここに落とし穴があります。83.5%まで引っ張ると、要約を生成するための「余白」が少なくなり、要約の質が下がります。公式ドキュメントでも80%を超えたら/compactを実行することが推奨されています（Claude Code Best Practices）。現場のベストプラクティスとしては、60%前後での手動実行がより安全です。余裕があるうちに圧縮したほうが、要約に含められる情報量が多くなるからです。

カスタム引数で要約の精度を上げる

/compactには引数を渡せます。これがかなり便利です。

/compact Focus on the database schema changes

/compact エラーハンドリングのパターンを保持して

引数を指定すると、要約生成時にその内容が優先的に保持されます。何も指定しないと、LLMが「重要そうなこと」を自動判断するため、あなたにとって重要な文脈が落ちる可能性があります。特に複雑なリファクタリングや、特定のアーキテクチャ上の決定を追いかけている最中は、引数指定が必須と言っていいでしょう。

圧縮の実測データ——どれだけ減るのか

「80%削減」と書きましたが、もう少し具体的に見てみましょう。公開されているデータを集めると、圧縮率にはかなり幅があります。

58.6%〜98%と幅が広いのは、会話の内容やツール呼び出しの量で圧縮効率が変わるためです。ツール呼び出し（ファイル読み込みやBash実行）のログは冗長なので圧縮率が高くなり、人間の指示中心の会話は要約しづらいぶん圧縮率が低めになります。

実運用では70〜85%の削減を期待するのが妥当なラインです。

/compact vs /clear——どっちを使うべきか

ここで混同されがちな/clearとの違いを整理しておきます。

判断基準はシンプルです。同じタスクを続けるなら/compact、別のタスクに移るなら/clear。

よくある失敗パターンとして、タスクAのデバッグ中に/compactして、そのまま無関係のタスクBに突入するケースがあります。要約にタスクAの文脈が残っているため、タスクBの応答にタスクAの前提が混入する——いわゆる「コンテキスト汚染」が起きます。タスクを切り替えるなら、迷わず/clearを使いましょう。

コンパクション後に何が消えるのか——ここが最大の注意点

/compactは万能ではありません。圧縮によって確実に失われる情報があります。ここを理解せずに使うと「Claudeが急にバカになった」と感じる原因になります。

生き残るもの

• システムプロンプト: 毎回ゼロから読み込まれるので影響なし
• ルートのCLAUDE.md: プロジェクトルートに置いた設定ファイルは再注入される
• auto-memory（.claude/memory.md）: ディスクから毎回読み込まれるので安全

失われるもの

• パススコープのCLAUDE.mdルール: paths:ディレクティブで特定ディレクトリに限定したルールは、コンパクション後に消えます（okhlopkov.com解説）
• ネストされたCLAUDE.md: サブディレクトリに置いたCLAUDE.mdの内容が要約から漏れる可能性があります
• SKILL.mdの後半部分: スキル定義ファイルの末尾に書いた内容は、圧縮時に切り捨てられることがあります（wmedia.es）
• 直近の編集の詳細: ファイルの具体的な変更内容は、要約では「○○を修正した」程度に丸められます

特にSKILL.mdの切り捨ては気づきにくい。重要なルールほどファイルの先頭に書く——これが鉄則です。

「コンパクション後にバカになる」問題

Doltのエンジニアリングブログでは、コンパクション後にClaude Codeが「リポジトリの構造を忘れる」「最近の編集を把握していない」「ルールを無視し始める」といった劣化現象が報告されています（DoltHub）。

これは要約の品質問題です。200Kトークンの会話を数万トークンに圧縮する以上、情報の損失は避けられません。前述のカスタム引数を使うこと、そして83.5%まで待たずに早めにコンパクションすることで、この問題はかなり軽減できます。

成功事例と失敗事例——現場のリアル

成功と失敗の両方を知っておくことで、自分の使い方を最適化できます。

成功事例

LP改修＋SEO記事14本を1セッションで完了——note.comの開発者tajimaさんは、LP改修とSEO記事14本の生成を1つのClaude Codeセッション内で完了させています。途中で/compactを活用してレート制限を回避し、セッション断絶なしで大量タスクを処理しました（note.com）。

90%以上のトークン削減——あるエンジニアは、/compactに加えてカスタムHooksやコンテキスト管理ツールを組み合わせることで、トークン使用量を90%以上削減しています。ポイントは「/compactだけに頼らず、CLAUDE.mdの最適化やMCPサーバーの絞り込みと組み合わせた」こと（Medium）。

失敗事例

2時間超セッションでの「コンテキスト腐敗」——長時間セッションで自動コンパクションが複数回走ると、要約の要約が生成される「多段圧縮」状態になります。結果として、初期の設計判断が完全に消失し、同じ質問を繰り返したり、以前のコードと矛盾する修正を提案し始めます（Coding Nexus）。

自動コンパクション＋/compact失敗バグ——GitHub Issue #6616では、コンテキストの86%が空いているにもかかわらず「Context low」警告が出て、/compactの実行自体が失敗するバグが報告されています（GitHub）。v2系の特定バージョンで発生していた問題で、アップデートで解消されましたが、こうした不具合が存在しうることは覚えておくべきです。

パススコープルールのサイレント消失——コンパクション後に、特定ディレクトリ向けのCLAUDE.mdルールが黙って消える現象が報告されています（wmedia.es）。通知が一切ないため、気づかないまま作業を続けてルール違反のコードを量産してしまうリスクがあります。

ベストプラクティス7選——実践的な使いこなし術

これまでの情報を踏まえて、/compactを最大限活かすための実践ルールをまとめます。

1. 60〜80%で手動コンパクションする

自動トリガーの83.5%を待たないでください。60%前後で手動実行するのがベストです。余裕があるうちのほうが要約の質が高く、重要な文脈が保持されやすいです。Claude Codeのステータスバーでトークン使用量を確認しながら作業するクセをつけましょう。

2. カスタム引数を毎回指定する

引数なしの/compactは使わないくらいの気持ちで。

/compact エラーハンドリングパターンとAPI設計の決定事項を保持

「何を残すか」を明示的に指示することで、要約の精度が劇的に上がります。

3. 重要ルールはルートCLAUDE.mdに書く

パススコープのルールや深い階層のCLAUDE.mdはコンパクション後に消える可能性があります。プロジェクト全体に適用したいルールは、必ずプロジェクトルートのCLAUDE.mdに記載してください。これはコンパクション後も再注入されます。

4. SKILL.mdは先頭に重要事項を書く

SKILL.mdの末尾は圧縮時に切り捨てられるリスクがあります。「絶対に守ってほしいルール」「必須の前提条件」はファイルの先頭に配置しましょう。

5. タスク切り替え時は/clearを使う

前のタスクの要約が次のタスクに悪影響を与える「コンテキスト汚染」を防ぐには、タスク切り替え時に/clearを使うのが確実です。「ちょっと関連あるかも」程度なら/compact、まったく別件なら/clear——迷ったら/clearを選びましょう。

6. --no-auto-compactを検討する

自動コンパクションのタイミングを自分で制御したい場合は、--no-auto-compactフラグでClaude Codeを起動できます（nathanonn.com）。ただし、手動でのコンテキスト管理が必須になるため、上級者向けの設定です。

claude --no-auto-compact

7. 長時間セッションは分割する

2時間を超えるセッションでは、多段圧縮による品質劣化が顕著になります。大きなタスクは最初からサブタスクに分割し、各サブタスクの完了時にTodoやメモに進捗を書き出してから/clearする——この方が結果的に品質が高くなります。

ONIのような業務自動化ツールでは、こうしたセッション管理をワークフローに組み込めます。「Claude Codeでの作業が一定時間を超えたら通知を出す」「タスク完了時に自動で進捗をファイルに書き出す」といった仕組みを作っておけば、コンテキスト管理の負担を減らせます。

コスト面のインパクト——/compactで財布も助かる

トークン削減は、そのままコスト削減に直結します。特にAPI従量課金で使っている場合、/compactの効果は無視できません。

Sonnet 4.6の入力トークン単価は100万トークンあたり$3。150Kトークンのセッションを/compactで30Kまで圧縮すれば、次のターンの入力コストが$0.45から$0.09に——約80%のコスト削減です。セッション全体で見れば、圧縮しない場合と比べてAPI費用が数分の一になるケースも珍しくありません。

サブスクリプション（Max 5x・Max 20x）を使っている場合でも、トークン消費の削減はレート制限の回避に効きます。同じ月額でより多くの作業をこなせるようになるため、実質的なコスパが改善します。

ONIを併用して定型作業をローカルで処理し、Claude Codeは判断や生成が必要な部分に集中させる——この切り分けと/compactの組み合わせで、トークン消費をかなり抑えられます。コスト管理の詳細についてはClaude Codeの料金・コスト管理ガイドも参考にしてください。

まとめ——/compactは「使い方を知っている人」の武器になる

/compactは単なるトークン節約コマンドではありません。コンテキストウィンドウという有限リソースを戦略的に管理するためのツールです。

ただし、使い方を間違えるとかえって品質を落とします。自動に任せて83.5%まで放置する、引数を指定しない、パススコープルールの消失に気づかない——こうした「知らない落とし穴」を踏むと、圧縮によるメリットよりデメリットのほうが大きくなりかねません。

この記事で紹介した実践ルール、特に「60%で手動実行」「カスタム引数の指定」「重要ルールのルートCLAUDE.md配置」の3つだけでも徹底すれば、セッション品質は明らかに変わります。コンテキスト管理は地味ですが、Claude Codeの出力品質を左右する最も重要な変数のひとつです。上手く付き合っていきましょう。

出典・参考リンク

• What Does /compact Do in Claude Code — How Do I Use AI
• Tool Use: Automatic Context Compaction — Claude Cookbook
• Compaction — Claude Docs
• Claude Code Best Practices — Anthropic
• Claude Code Compaction Explained — okhlopkov.com
• Claude Code /compact: What Survives — wmedia.es
• Claude Code Gotchas — DoltHub Blog
• Claude Code Context Recovery — Coding Nexus（Medium）
• How I Cut Claude Code Token Usage by 90% — Medium
• LP改修＋SEO記事14本の事例 — note.com
• Never Auto Compact — nathanonn.com
• GitHub Issue #6616 — claude-code