Claude Codeが急にバカになる原因はコンテキスト管理。/compactと/clearの使い分け

夕方、長いリファクタの最中に「さっき決めた命名ルールでお願い」と頼んだら、Claude Codeが平然と別のルールで書き始めました。

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

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

この記事の要点

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

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

コンテキストウィンドウというと身構えますが、要は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はそのエイリアス扱いになっているので、入口は/usageにそろえておくと混乱しません。ただし/usageに出る金額はあくまでローカル推定なので、正確な請求はClaude Console側で見てください。

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

散らかってから片づけるより、最初から散らかさないほうが速い。僕は作業を始める前に、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つ:開発・記事・収益導線で散らかり方が違う

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

1. 大規模リファクタ … 調査はサブエージェントや別セッションに出して、メイン会話には「要約」と「変更の判断」だけを戻す。調査ログを実装中の会話に混ぜると、机が一気に汚れます。
2. 記事制作 … ネタ帳や検索メモはObsidian、公開ルールと品質ゲートはCLAUDE.md、最終本文はMDX、と置き場所を分ける。こうするとPV改善のPDCAが回しやすい。
3. 問い合わせ導線の改善 … アクセス分析・仮説・修正・検証を1枚の短いチケットにまとめ、終わったら引き継ぎレシートを残して次回の起点にする。

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

よくある失敗と回避策

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

1. /compactすれば何でも残ると思い込む … 会話履歴は要約されるので、細かい制約は落ちます。残したいルールはCLAUDE.mdかファイルに書く。
2. 調査で大量のファイルを読ませてから実装に入る … 実装時には古い調査ログが机を占有します。調査結果は短いメモに圧縮してから、実装セッションに入る。
3. auto memoryをチーム共有ドキュメントだと思う … auto memoryは基本ローカルな学習メモです。チームで共有したい規約は、リポジトリのCLAUDE.mdに書く。

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を見る癖をつけました。重かったら、引き継ぎレシートを5行書いてから/compactする。別タスクなら迷わず/clear。たったこれだけで、長時間作業の「急にバカになる」現象はほぼ消えました。

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

書き直しにあたっては公式ドキュメントを確認し、/cost中心の古い説明ではなく/usage・/context・/compact・/memoryを使い分ける形に更新しています。出典: context window、commands、memory、common workflows。

もっと体系的に学びたい・チーム導入を相談したい方は、教材一覧と研修・相談もどうぞ。