Claude Codeのコンテキスト枯渇対策｜劣化を防ぐ削り方

「Claude Codeのコンテキストが枯渇するのを防ぐ対策ってあるの？」
「長く使っていると急に指示を忘れるのをどうにかしたい！」

Claude Codeを1日使っていると、朝は的確だった応答が夕方には的外れになる、ということが起きます。
これはコンテキストが枯渇に向かうときの典型的な症状でした。

結論から言うと、コンテキストは「足りなくなってから足す」ものではなく、最初から削っておくものです。
この記事では劣化が起きる仕組みから、削る手順、1Mトークンの窓が来た後の考え方までを通しで整理しました。

Claude Codeでコンテキストが枯渇するとどうなるか

Claude Codeのコンテキストが枯渇したとき、最初に現れる症状は「動かなくなる」ではありません。

ここでは、枯渇に向かう過程で何が起きているのかを3つの角度から見ていきます。

コンテキストウィンドウに積まれているものの正体

コンテキストウィンドウというと、自分が打った指示とClaudeの返事だけを思い浮かべますよね。

ところが実際には、それ以外のものがかなりの割合を占めています。

Claude Code公式ドキュメントによると、セッション開始の時点で以下がすでに読み込まれた状態になっていました。

ここに、作業を始めてから読んだファイルの中身、コマンドの実行結果、フックの出力が積み上がっていきます。

大きなログファイルを1回読ませただけで、数万トークンが消えることも珍しくありません。

つまり枯渇は、会話が長引いたから起きるというより、読ませたものが多いから起きるんですよね。
ここを取り違えると「短く話しかければいい」という的外れな対策に走ってしまいます。

容量が尽きるより先に落ちるのは精度

コンテキストの話でいちばん誤解されているのが、「上限に当たるまでは問題なく動く」という前提です。

実際には、上限のずっと手前から応答の質が落ちていきました。

情報量が増えるほど、モデルが「いま本当に見るべき指示」に集中しづらくなるからです。
会議で資料が100ページ配られたら、最初の1ページの約束事を忘れてしまうのと同じ構造ですね。

私自身、長時間のセッションで「CLAUDE.mdに書いたはずのコーディング規約を守らなくなる」現象に何度もぶつかりました。

そのたびに指示を打ち直していたのですが、原因は指示が伝わっていないことではなかったんです。

指示は届いているのに、そのまわりに情報が積まれすぎて埋もれていた、というのが実際のところでした。
だから対策の順番は、足すのではなく削るが先になります。

自動コンパクトで残るものと消えるもの

コンテキストが上限に近づくと、Claude Codeは自動で会話を要約します。これが自動コンパクトです。

セッションが強制終了しないので助かる仕組みですが、要約である以上は情報が落ちますよね。

公式ドキュメントには、コンパクションのあとに何が残って何が消えるのかが表で示されていました。

ここが今回いちばん伝えたいところです。

プロジェクトルートのCLAUDE.mdは戻ってくるのに、サブディレクトリに置いたCLAUDE.mdは戻ってこない。

「長く作業していると急にルールを守らなくなる」の正体は、たいていこれでした。
絶対に守ってほしい規約は、ネストされた場所ではなくプロジェクトルートに置くのが正解です。

Claude Codeのコンテキスト消費を数字で把握する手順

削る前に、いま何にどれだけ使っているのかを見ておきます。

感覚で減らすと、効きの薄いところばかり削って肝心の重い部分が残ってしまうからです。

【ステップ1】contextコマンドで内訳を出す

最初にやるのは、セッション中に /context と打つことです。

/context

これだけで、いまコンテキストウィンドウの何％が埋まっているか、そして何がその容量を食っているかがカテゴリ別に表示されます。

システムプロンプト、CLAUDE.md、MCPツール、会話履歴、ファイル読み込みといった単位で内訳が出るので、犯人がすぐわかるんですよね。

私が初めて実行したときは、使ってもいないMCPサーバーの定義がコンテキストの1割近くを占めていました。

会話履歴が半分を超えていたら、それは削る対象というより切り替えの合図です。

逆にCLAUDE.mdやMCPが重い場合は、セッションを切っても毎回同じ重さで戻ってきます。
設定側を直さないかぎり、何度切り直しても同じところに戻るというわけです。

【ステップ2】ステータスラインに使用率を常時表示する

毎回 /context を打つのは、正直めんどうです。

そこでステータスラインに使用率を出しておくと、視界の端で常に把握できるようになります。

設定は ~/.claude/settings.json にステータスライン用のコマンドを登録する形でした。

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}

スクリプト側でコンテキスト使用率を出力すれば、プロンプトの下に常時表示されます。

自分でシェルスクリプトを書くのが面倒なら、Claude Code自身に「ステータスラインにコンテキスト使用率を出したい」と頼めば作ってくれますよ。

数字が視界に入るようになると、「そろそろ切ろう」という判断が自然にできるようになります。
私はこれを入れてから、compactの打ち忘れがほぼなくなりました。

【ステップ3】memoryコマンドで起動時の読み込みを確かめる

意外と見落とされるのが、起動した瞬間にすでに読まれているファイルです。

/memory を実行すると、いまのセッションでどのCLAUDE.mdと自動メモリが読み込まれたかが一覧で出ます。

/memory

ここで「そんなファイル置いた覚えがない」というものが出てきたら、それが固定費として毎セッション効いていました。

書き方そのものを整理したい場合は、Claude Code CLAUDE.mdの書き方の記事で階層ごとの役割分担をまとめました。

起動時に読まれるものを減らすのが、いちばん効率のいい削り方です。

会話は切ればリセットされますが、こちらは何度切っても毎回ついて回るからですね。

Claude Codeのコンテキストを削る5つの対策

内訳が見えたら、いよいよ削っていきます。

ここでは効果の大きい順に、5つの削り方を並べました。

【対策1】CLAUDE.mdを200行以下に保つ

いちばん効くのに、いちばん放置されているのがCLAUDE.mdの肥大化です。

公式ドキュメントでもCLAUDE.mdは200行以下に保つことが推奨されています。

理由は単純で、ここに書いたものはセッション開始時に必ず読み込まれるからでした。

PRレビューの手順やデータベース移行の段取りを書いておくと、まったく関係ない作業をしている間もそのトークンが居座り続けます。

私は自分のCLAUDE.mdが600行を超えていたとき、その3分の2をSkillsへ移しました。
体感でわかるほど初動が軽くなり、指示の通りもよくなったんですよね。

残すべきなのは、どの作業でも必ず守ってほしいことだけです。
判断に迷ったら、「この行が読まれなかったせいで事故が起きるか」を基準にしてみてください。
事故にならないものは、たいていCLAUDE.mdの外に出せますよ。

【対策2】長い手順はSkillsに逃がす

CLAUDE.mdから追い出した手順の行き先が、Skillsです。

Skillsは呼ばれたときだけ本体が読み込まれる仕組みになっていて、待機中は説明文の1〜2行しかコンテキストを使いません。

つまり「持っているけれど普段は重さゼロ」という状態を作れました。

.claude/skills/
  └── deploy-check/
        └── SKILL.md   ← 呼ばれたときだけ読み込まれる

さらに、自分で手動でしか呼ばないSkillなら、frontmatterに disable-model-invocation: true を書いておく手もあります。

こうするとClaudeが自動判断で使わなくなるかわりに、説明文すらコンテキストから外れました。

作り方そのものはClaude Code Skillsの使い方の記事にまとめてあるので、CLAUDE.mdからの引っ越し先として読んでみてください。

【対策3】重い調査はサブエージェントに投げる

コンテキストをいちばん豪快に食うのは、大量のファイル読み込みです。

「このコードベースで認証がどう実装されているか調べて」と頼むと、10ファイル20ファイルと読み込まれて一気に数万トークンが消えます。

ここで効くのがサブエージェントでした。

サブエージェントは自分専用の新しいコンテキストウィンドウを持ち、メインの会話とは完全に分離されています。

読み込んだファイルの中身はそちらに溜まり、こちらに返ってくるのは要約だけです。

調査に3万トークン使っても、メイン側の消費は数百トークンで済むという計算になりますね。
使い分けの考え方はClaude Codeのサブエージェントの記事で整理しました。

【対策4】使っていないMCPサーバーを止める

MCPサーバーは便利なのですが、つないだ数だけコンテキストの固定費になります。

現行のClaude Codeではツール定義が既定で遅延読み込みになり、実際に使うまではツール名だけがコンテキストに入る形へ改善されました。

とはいえ名前の一覧も無料ではないので、10個も20個もつないでいれば効いてきます。

/mcp

このコマンドで設定済みのサーバーが一覧表示されるので、直近1か月で使っていないものは思い切って無効化しましょう。

公式ドキュメントでは、CLIツールで代替できるものはMCPよりCLIを優先することが勧められています。

CLIならツール定義そのものが存在しないので、コンテキストの固定費がまるごとゼロになるからですね。
MCP側の設定を見直すならClaude CodeのMCP設定方法もあわせてどうぞ。

【対策5】フックで出力を絞ってから渡す

最後は、そもそもコンテキストに入る前に量を減らしてしまう手です。

フックを使うと、Claudeがコマンドの結果を見る前に中身を加工できます。

公式ドキュメントで紹介されているのが、テスト出力を失敗行だけに絞る例でした。

#!/bin/bash
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command')



if [[ "$cmd" =~ ^(npm test|pytest|go test) ]]; then
  filtered_cmd="$cmd 2>&1 | grep -A 5 -E '(FAIL|ERROR|error:)' | head -100"
  echo "{\"hookSpecificOutput\":{\"hookEventName\":\"PreToolUse\",\"permissionDecision\":\"allow\",\"updatedInput\":{\"command\":\"$filtered_cmd\"}}}"
else
  echo "{}"
fi

1万行のログをまるごと読ませるかわりに、エラー行だけを渡す。
これだけで数万トークンが数百トークンまで縮みます。

設定の書き方はClaude Code hooksの使い方にまとめました。

まずはテストとビルドのログから試すのが、いちばん効果を体感しやすいと思います。

Claude Codeのコンテキストが尽きる前に切り替えるコツ

削っても、作業を続けていればコンテキストは必ず埋まります。

ここでは、埋まりきる前に自分から切り替えるやり方を4つ紹介しますね。

clearとcompactの使い分け

この2つは似ているようで、役割がまったく違います。

/clear は会話履歴を捨てて新品の状態に戻すコマンドです。

いっぽう /compact は会話を要約に置き換えて、話の続きができる状態を保ちます。

迷ったら「この会話の続きが必要か」で判断すると外しません。

不要ならclearのほうが軽くて速いですよ。

修正を2回繰り返してもうまくいかないときも、粘るより一度clearしたほうが早く片づきました。
同じ間違いを含んだ履歴を抱えたまま直そうとすると、その履歴に引きずられてしまうからです。

focusを付けて残すものを指定する

compactを引数なしで打つと、何を残すかはClaude側の判断になります。

ここで自分から指定できるのが、focus付きのcompactでした。

/compact focus on the auth bug fix

日本語でも通じるので、実務では次のように書いています。

/compact 認証まわりの修正方針と決めた命名規則を残して、調査ログは捨てて

長い新しいタスクに入る直前にfocus付きで打っておくと、そのあとの精度がはっきり変わります。

逆に何も考えずに打つと、自分にとって大事だった判断の根拠が要約から抜け落ちることがありました。

圧縮は自動でやってくれますが、何を守るかまでは決めてくれません。
そこだけは自分で指定する、と考えておくと失敗しにくいです。

Compact Instructionsで要約の方針を固定する

毎回focusを書くのが面倒なら、CLAUDE.mdに方針を書いておく手があります。

プロジェクトルートのCLAUDE.mdに、次のようなセクションを足すだけでした。

# Compact instructions



コンパクト時は、テスト結果とコード変更、および決定済みの設計方針を優先して残してください。
調査中の試行錯誤のログは捨ててかまいません。

これは自動コンパクトが走るときにも使われます。

気づかないうちに圧縮されて肝心の決定事項が消える、という事故を防げるので入れておいて損はありません。

チームで使っているリポジトリなら、なおさら効きます。
誰のセッションでも同じ方針で要約されるので、引き継ぎのときの前提がそろうからですね。

引き継ぎメモを書き出してから切る

いちばん確実なのは、要約をClaudeに任せず自分で書き出してしまうことです。

切る前に「いまの状況と次にやることを handoff.md に書いて」と頼み、そのファイルを残してから /clear します。

新しいセッションではそのファイルを読ませるだけで、必要な文脈が最小のトークン数で復活しました。

要約は圧縮率が高いぶん、細かい判断の根拠が落ちやすいんですよね。

ファイルに書いておけば、そこは自分で選べます。

セッションをまたぐやり方はClaude Codeのセッション引き継ぎで4つの方法を比較しました。
/rename で名前を付けてから切り、あとで /resume で戻る流れも覚えておくと便利です。

Claude Codeが1Mコンテキストでも設計を要する理由

ここまで読んで「窓が広がれば全部解決するのでは」と思った方もいると思います。

実際に100万トークンのコンテキストは使えるようになりましたが、それでも削る設計は要りました。

100万トークンが使えるモデルと条件

まず前提を整理しますね。

公式ドキュメントによると、Fable 5・Sonnet 5・Opus 4.6以降・Sonnet 4.6が100万トークンのコンテキストウィンドウに対応しています。

Sonnet 5については、モデル名に [1m] を付けなくても最初から1Mで動く扱いになりました。

プランごとの扱いは変わりやすいので、契約前に公式の料金ページを見ておくのが確実です。

費用感を先に知っておきたい方は、Claude Codeの料金プランの記事で各プランの違いを比較しました。

なお1Mが使えるからといって、既定の状態で常に1M分を使うわけではありません。
あくまで「必要なときに入る余地がある」というだけの話です。

窓を広げても精度の劣化は消えない

ここがこの記事でいちばん言いたかったところです。

コンテキストウィンドウが5倍になっても、「情報が多いほど指示が埋もれる」という性質は変わりません。

むしろ入れられる量が増えるぶん、埋もれ方は派手になりました。

200KBの窓なら「そろそろ限界だな」と気づけたものが、1Mだと気づかないまま数時間走り続けてしまうんですよね。

私は1Mのつもりで大きなリポジトリをまるごと読ませたことがありますが、返ってきたのは的外れな要約でした。

読ませる量ではなく、読ませるものを選ぶ。
この原則は窓の大きさと関係なく残ります。

広げるほど増えるコストと待ち時間

もうひとつ現実的な話をします。

トークンのコストはコンテキストの大きさに比例して増えました。窓を目いっぱい使えば、1回のやり取りの単価もそのぶん上がります。

体感でわかりやすいのは、むしろ待ち時間のほうですね。

コンテキストが膨らむと、最初の応答が返ってくるまでの間がじわじわ長くなります。

1回あたり数秒の差でも、1日に何十回も往復すればまとまった時間になりますよね。

窓が広いのは保険であって、常時いっぱいまで使う前提の機能ではありません。
ふだんは小さく回し、どうしても必要なときだけ広く使う。この使い分けがいちばん快適でした。

Claude Codeのコンテキスト対策でつまずきやすい点

最後に、対策を始めてから実際にぶつかりやすいところをまとめます。

知らないと原因究明に時間を溶かしてしまうものばかりです。

自動コンパクトがthrashingエラーで止まる

まれに、自動コンパクトがエラーを出して止まることがあります。

公式ドキュメントでは thrashing エラーと呼ばれていて、原因もはっきりしていました。

単一のファイルやツール出力が大きすぎて、要約するたびにすぐまた満杯になってしまう状態です。

Claude Code側は無限ループを避けるため、数回試したところで自動コンパクトをあきらめてエラーを表示します。

数十MBのログやビルド生成物をうっかり読ませたときに出やすいです。

読ませる前に wc -l で行数を見る癖をつけておくと、そもそも起きなくなりますよ。

paths指定のルールはコンパクトで消える

これは知らないと本当にハマります。

frontmatterに paths: を書いたルールは、対象ファイルを読み込んだときに一緒に読み込まれる仕組みでした。

便利なのですが、コンパクションが走ると会話履歴と一緒にまとめられて失われます。

対象ファイルをもう一度読み直すまで戻ってきません。

そのため「午前中は守っていた規約を午後は守らない」という、いかにも気まぐれに見える挙動になります。
気まぐれではなく、圧縮のタイミングでルールが落ちていただけでした。

ルートのCLAUDE.mdはコンパクション後にディスクから読み直されるので、確実に生き残ります。

呼び出したSkillは上限で切られる

Skillsも、コンパクション後に自動で再注入されます。

ただし無制限ではありません。1つのSkillあたり5,000トークン、合計25,000トークンという上限が設けられています。

この枠を超えると、古く呼ばれたSkillから順に落ちていきました。

さらに、上限に収めるためのトリミングはファイルの先頭から残す方式でした。

長いSkillを書くときは、結論と禁止事項を先頭に、補足や具体例を後ろに置く構成にしておきましょう。

1つのSkillが5,000トークンに迫っているなら、そもそも2つに分けたほうが安全です。
分けておけば、片方が落ちてももう片方は残りますからね。

プランモードを飛ばして手戻りを増やす

最後は、対策というより習慣の話です。

複雑な作業をいきなり実装から始めると、方向がずれたときに調査と修正をまるごとやり直すことになります。

この手戻りで消えるコンテキストが、実はいちばん大きいんですよね。

方針を承認してから走らせるので、途中で「そうじゃない」と止める回数も減ります。

間違った方向に進んで溶かすぶんを、丸ごと節約できるわけです。

コンテキスト対策でいちばん効くのは、削ることより無駄に増やさないことでした。

Claude Codeのコンテキスト枯渇対策に関するよくある質問

ここでは、コンテキストの扱いで実際によく聞かれる疑問に答えていきます。

Q：コンテキストが枯渇すると作業は止まってしまいますか？

A：止まりません。上限に近づくとClaude Codeが自動でコンパクションを行い、会話を要約して領域を空けてくれます。

ただし要約の過程で、序盤に出した細かい指示は落ちることがあります。止まらないかわりに、いつのまにか前提が変わっている点に注意してください。

Q：compactは使用率が何％くらいのときに打つのがいいですか？

A：7割前後を目安にすると扱いやすいです。自動コンパクトが走るのを待つと、自分の意図と関係ないタイミングで圧縮されてしまいます。

作業の区切りで自分から打っておけば、focusで残すものも指定できます。ただし圧縮自体もトークンを使うので、こまめに打ちすぎるのは逆効果でした。

Q：CLAUDE.mdを削ったら、覚えていてほしいことが伝わらなくなりませんか？

A：消すのではなく、置き場所を移すのがコツです。特定の作業でしか使わない手順はSkillsへ、参照すれば済む情報はドキュメントのファイルへ移します。

CLAUDE.mdに残すのは、どの作業でも必ず守ってほしいルールだけにしましょう。呼ばれたときだけ読み込まれる形にすれば、内容は保ったまま固定費だけ下げられます。

Q：サブエージェントを使うと、トークンの総量はむしろ増えませんか？

A：総量としては増えます。サブエージェント側でもCLAUDE.mdやSkillsが読み込まれるためです。

それでもメイン側のコンテキストが汚れないので、長い作業では結果的に得になりました。逆に数分で終わる調べものなら、そのまま本体でやったほうが速くて安いです。

まとめ

Claude Codeのコンテキスト枯渇は、容量オーバーとして現れる前に精度の低下として先に来ます。

だから対策の順番は、/context で内訳を見る、固定費であるCLAUDE.mdとMCPを削る、重い読み込みをサブエージェントへ逃がす、という流れになりますね。

窓が1Mになっても、この設計は要ります。広い部屋を手に入れたからといって、荷物を全部床に出しておく人はいませんよね。

まずは /context を1回打ってみて、自分が何にコンテキストを使っているのかを見てみてください。
そこに、思っていたのと違う犯人がいるかもしれません。

Claude Codeを使いこなす力は、そのまま「AIを業務に組み込める人」の市場価値につながります。独学で埋めきれない部分を講座で補いたい方は、社会人におすすめの生成AI研修スクール｜スクール6校を比較が判断材料になります。