Claude Codeコンテキスト管理入門: /context・/compact・/clearの使い分け

夕方、料金ページのテストを直している最中に「さっき決めた命名ルールでお願い」と頼んだら、Claude Codeが平然と別のルールでコードを書き始めました。

朝はあんなに察しがよかったのに、急にポンコツになった。最初は「モデルが劣化した?」と疑いました。違いました。劣化したのはモデルじゃなくて、会話の作業机だったんです。

3時間ぶんのファイル読み込みと失敗ログで机が埋まり、肝心の命名ルールが書類の山に埋もれていた。それだけの話でした。

この記事の要点

• Claude Codeが長い会話で急に精度を落とすのは、頭が悪くなったからではなくコンテキストウィンドウ(作業机)が散らかっているから。
• 使う道具は4つだけ。/contextで散らかり具合を見る、/compactで要約して続ける、/clearで机を片づける、CLAUDE.mdに消えてほしくないルールを逃がす。
• 同じ話題を続けるなら/compact、別タスクに移るなら/clear。この一線を引けるだけで安定感が変わる。
• 会話に直接言った指示は要約で落ちやすい。長く使うものはCLAUDE.mdかファイルへ逃がすのが鉄則。
• まずは「読むファイルを絞る・終わったら検証結果を残す・別タスクなら切る」の3つでいい。

flowchart TD
  A["回答がずれ始める"] --> B["/context で使用量を確認"]
  B --> C{"同じタスクを続ける?"}
  C -->|はい| D["引き継ぎレシートを残す"]
  D --> E["/compact で要約して続行"]
  C -->|いいえ| F["/clear で新しい会話を開始"]

コンテキストウィンドウは「作業机」だと思え

コンテキストウィンドウというと身構えますが、要はClaude Codeがその瞬間に見渡せる作業机の広さです。机の上には、これまでの会話、読み込んだファイル、コマンドの出力、CLAUDE.md、auto memory、読み込まれたルールやスキルが全部のっています。

机が広いうちは余裕です。でも作業が進むほど、参照したファイルと失敗ログが書類みたいに積み上がる。すると重要な仕様や制約が下に埋もれて、Claude Codeから「見えなく」なる。これが、急にトンチンカンな返事をする正体です。

何が机を圧迫するのか、整理するとこうなります。

机に積まれるもの	重くなる原因	片づけ方
会話履歴	長い相談と脱線	タスクごとに区切る
ファイル	巨大ファイルの丸読み	検索して必要な範囲だけ渡す
ツール出力	長いログと失敗リトライ	要約してファイルに残す
メモリ	長すぎるCLAUDE.md	rulesやdocsへ分ける

ポイントは、コンテキスト管理は「ケチって節約する話」じゃないということ。机がきれいなほど、提案も実装も記事本文も筋が通る。節約術ではなく品質管理です。

/context・/compact・/clear・/memoryの使い分け

道具は4つだけ覚えれば足ります。役割がそれぞれ違うので、そこだけ押さえてください。

• /context … いま机に何がのっていて、どれが重いかを表示する。まず疑ったらこれ。
• /compact … これまでの会話を要約して、同じ流れのまま続行する。話題は変えたくないけど机が重い、というときに使う。
• /clear … 机を一度まっさらにして、新しい会話として始める。別タスクに移るときはこれ。
• /memory … CLAUDE.mdやauto memoryがちゃんと読み込まれているかを確認する場所。

/context
/compact 変更ファイル・失敗テスト・決めた方針・未解決の論点を残して
/clear
/memory

迷いやすいのは/compactと/clearの境目です。判断はシンプルで、「さっきまでの作業の続き」なら/compact、「ぜんぜん別の作業」なら/clear。同じバグを追い続けるなら要約して持ち越す。別の機能に手をつけるなら、前のログはノイズにしかならないので捨てる。この一線を引けるだけで、体感がかなり変わります。

なお利用状況を見たいときは/usageです。現在の公式コマンド一覧では、セッションコスト、プランの利用上限、利用状況をまとめて表示し、/costと/statsはそのエイリアスです。実際の請求額は、認証方法に応じてClaude Console、Bedrock、Vertex AI、Microsoft Foundryなどの請求画面で照合してください。

Claude Codeに任せる範囲と、人が判断する範囲

Claude Codeに任せるのは、関連ファイルの検索、差分の要約、テスト実行、引き継ぎレシートの下書きです。大量のログをそのまま会話へ戻さず、「変更ファイル・失敗したテスト・原因候補・次の1手」へ圧縮させます。

人が判断するのは、タスクを続けるか切り替えるか、どの仕様を正とするか、権限・本番・請求・個人情報を伴う操作を承認するかです。Claude Codeが「続き」と判定しても、別の売上施策や別機能へ移るなら、人が/clearを選びます。

判断	Claude Codeに任せる	人が見る・決める
調査	関連コードとテストの候補を絞る	調査範囲が目的に合うか
要約	差分・失敗・次の手順を短くする	捨ててはいけない仕様
実行	承認済みコマンドを実行する	本番、権限、請求、顧客データ
区切り	引き継ぎレシートを作る	/compactか/clearか

始める前に「コンテキスト予算」を決める

散らかってから片づけるより、最初から散らかさないほうが速い。僕は作業を始める前に、Claude Codeへ4点だけ先に渡します。目的・触るファイル・完了条件・実行する検証コマンドです。

逆にやらないのは、関係ないログを貼ることと、ディレクトリを丸ごと読ませること。「とりあえず全部読んで把握して」は一番机を汚します。Claude Codeに探索させる前に、こちらで検索範囲を絞って渡すだけで消費量はガクッと減ります。

# Claudeに読ませる前に、こちらで探索範囲を絞る
rg -n "getUserById|User not found|auth middleware" src tests
git diff --stat
npm test -- --runInBand

rgで当たりをつけ、git diff --statで変更の全体像だけ渡し、テストは関連分だけ流す。これで「巨大ファイルの丸読み」が机を埋める事故が起きません。

コピペで使えるプロンプトと動く確認コード

長い修正や記事制作に入る前、僕がそのまま貼っているテンプレがこれです。コツは2つ。最初に成功条件を書くことと、終盤で検証レシートを作ること。これがあると、途中で/compactしても話の芯がぶれません。

## このタスクの設計図
- 目的:
- やること(スコープ内):
- やらないこと(スコープ外):
- 触りそうなファイル:
- 完了条件(これが満たせたら終わり):
- 検証コマンド:

## 引き継ぎレシート
- 変更したファイル:
- 実行したコマンド:
- 結果:
- 残っているリスク:
- 次にやるべきこと:

上半分は着手前に、下半分は区切るときに埋めます。とくに下の「引き継ぎレシート」を5行残してから/compactすると、要約の質まで上がる。Claude Codeに何を残してほしいかを、こちらが先に言語化しているからです。

/compact後に「残るもの・消えるもの」

ここを誤解している人がいちばん事故ります。/compactすれば何でも残る、は嘘です。

/compactの後も、ルートのCLAUDE.mdとauto memoryは再注入されます。サブディレクトリのCLAUDE.mdやパス単位のルールも、該当ファイルをもう一度読んだタイミングで戻ってきます。一方で、会話のなかで口頭で伝えただけの重要指示は、要約のときに落ちやすい。冒頭の「命名ルール無視」事故は、まさにこれでした。

だから、長く効かせたいルールは会話に置きっぱなしにせず、CLAUDE.mdへ逃がす。/compactの挙動そのものを、こんなふうに指示で固定しておくのも効きます。

# CLAUDE.md

## Compact時の指示
- いまのビジネス目的と収益化の仮説は必ず残す。
- 変更ファイル、検証コマンド、デプロイ状態、ブロッカーを残す。
- 生ログは捨ててよい。ただし原因を説明している1行は残す。
- 記事作業が進行中なら、slug・対象言語・残った品質課題を残す。

3つのUse case

机の散らかり方は、作業の種類で変わります。僕の現場での分け方はこうです。

Use case 1: 大規模リファクタ

入力: 対象ディレクトリ、変更しないAPI、失敗中のテスト、完了条件。

出力: 関連ファイル一覧、変更差分、通過・失敗したテスト、次に確認する1点。調査はサブエージェントや別セッションへ出し、メイン会話には判断に必要な要約だけを戻します。

人の確認: 公開APIを変えてよいか、移行期間を設けるか、本番へ出すかを判断します。

Use case 2: 記事制作

入力: 狙う検索意図、読者の困りごと、公式URL、公開前チェックリスト。

出力: MDX本文、内部リンク候補、コードの検証結果、CTA案。ネタ帳や検索メモはObsidian、公開ルールはCLAUDE.md、本文はMDXへ分けます。

人の確認: 実体験として書ける範囲、誤解を招く主張、価格・セキュリティ・製品仕様の最終表現を確認します。

Use case 3: 問い合わせ導線の改善

入力: 対象ページ、現状のクリック数、CTAの文言、変更しない観測期間。

出力: 分析・仮説・修正・検証を1枚にした短いチケットと、次回の起点になる引き継ぎレシート。

人の確認: CTAを変える日、成約とみなす条件、個人情報を扱うフォームの公開可否を決めます。

共通しているのは、1つの会話に全部の判断を抱えさせないこと。本文品質の判断と収益施策の判断を同じ机に並べると、必ず干渉します。

Pitfall: よくある失敗の原因と直し方

正直に言うと、ここに挙げる3つは全部、僕がやらかした失敗です。

1. /compactすれば何でも残ると思い込む 原因: 会話履歴は選択的に要約されるため、1度しか出てこない制約は落ちます。 直し方: 残したいルールをCLAUDE.mdか仕様ファイルへ書き、compact指示にも含めます。
2. 調査で大量のファイルを読ませてから実装に入る 原因: 実装時にも古い調査ログがコンテキストを占有します。 直し方: 調査結果を短いメモへ圧縮し、実装ではそのメモと対象コードだけを読みます。
3. auto memoryをチーム共有ドキュメントだと思う 原因: auto memoryは同じリポジトリのworktree間では共有されても、別PCやチーム全体には自動共有されません。 直し方: チームで守る規約はリポジトリのCLAUDE.md、rules、docsへ置きます。

Obsidianとの役割分担で「捨てていい机」を増やす

コンテキスト管理がうまい人は、そもそも机にのせない情報を持っています。その置き場がObsidianです。

流入キーワード、読者の悩み、内部リンク候補、長い調査メモ。こういう「いつか使うけど今は要らない」ものは、全部Obsidianや分析メモに置く。MDXを書くセッションには、今回のslug・読者像・必須リンク・品質ゲートだけを渡す。コンテキストを細くするほど、導入文やCTAの改善に集中できます。

置き場所の住み分けは、この表のとおりに決めています。

置き場所	向いている情報
CLAUDE.md	毎回必要な短い規約
Obsidian	長い調査、仮説、記事ネタ
MDX / docs	公開本文、仕様、引き継ぎ
auto memory	ローカルな好みと繰り返し学習

長い調査が必要なときは、調査と実装を同じ会話に詰め込まない。調査結果をdocs/handoff-YYYY-MM-DD.mdのような短いファイルにまとめ、実装セッションではそのファイルと対象コードだけを読ませる。これで古い検索結果が実装判断に混ざりません。

この考え方は、CLAUDE.mdの書き方、トークン最適化、プロンプト設計とセットで効きます。ナレッジ管理まで含めるならClaude CodeとObsidian連携も読んでみてください。

よくある質問

Q. Claude Codeが急に的外れな返事をします。モデルの問題ですか? ほとんどの場合は違います。まず/contextを打って、会話が重くなっていないか確認してください。長い会話で精度が落ちるのは、机に書類が積もって肝心の指示が埋もれているサインです。

Q. /compactと/clearはどう使い分ければいいですか? さっきの作業の続きなら/compact(要約して持ち越す)、まったく別のタスクに移るなら/clear(机を片づける)。同じバグを追い続けるか、別の機能に移るかで判断すると間違えません。

Q. /compactしたら、決めたルールが消えました。なぜ? 会話で口頭で伝えただけの指示は、要約のときに落ちやすいからです。CLAUDE.mdに書いたものは/compact後も再注入されます。長く効かせたいルールは会話に置かず、CLAUDE.mdかファイルへ逃がしてください。

Q. コストを確認するコマンドはどれですか? /usageです。セッションコスト、プラン上限、利用状況を確認でき、/costと/statsはエイリアスです。最終的な請求額は、Claude Consoleまたは利用しているクラウドの請求画面で照合してください。

Q. 初心者ですが、何から手をつければ? 3つだけで十分です。「読むファイルを絞る」「終わったら検証結果を残す」「別タスクなら/clearで切る」。これだけでClaude Codeは同じ性能でも段違いに扱いやすくなります。

次にやること

まず/contextを実行し、重い項目を1つだけ減らしてください。そのうえで、インストール、CLAUDE.md、権限、MCP、コンテキスト管理まで順番に整えたい場合は、Claude Code設定ガイド（500円）を使えます。

実際に試した結果

冒頭の「命名ルール無視」事故のあと、僕は作業前に必ず/contextを見る癖をつけました。重かったら、引き継ぎレシートを5行書いてから/compactする。別タスクなら迷わず/clear。たったこれだけで、長時間作業の「急にバカになる」現象はほぼ消えました。

記事改善バッチのような反復作業では効果がさらにはっきり出ます。前回の分析結果を全部持ち越すのではなく、次に直すslug・狙う検索意図・確認するコマンドだけを残す。すると本文の質も検証速度も上がりました。良い指示を書く力と同じくらい、良いタイミングで文脈を捨てる力が効いてくる、というのが今の実感です。

書き直しにあたって、/context・/compact・/clear・/memory・/usageの役割、compaction後に再注入される情報、auto memoryの保存範囲を公式資料で照合しました。出典: context window、commands、memory、sessions。

まず今日のセッションで/contextを実行し、最も重い項目を1つ確認してください。同じタスクなら引き継ぎレシートを書いて/compact、別タスクなら/clearを選ぶところまで試すと、次に何を削るべきか判断できます。