ClaudeCodeの/clearは「正論」なんだけど… 現実の「あと少し」を救う、たった1行の設定

はじめに

深夜1時。ClaudeCodeで分析レポートのスコアリングロジックを書いていました。

6つの因子の重み付け計算、トレンド推定、在庫データとの突き合わせ――ここまで3時間、プランモードで設計してそのまま実装に入って、順調に進んでいたんです。

残りは配送リスクの計算ロジックだけ。あと2ステップ。

そのとき、画面の端にチラッと表示されたのが「auto-compact」の通知。

……え、もうコンテキスト使い切った？

プロンプトを打つ。
返ってきたコードが、さっきまで書いていた関数名を間違えている。
存在しない関数を堂々と呼んでいる。

指摘したら今度は引数の型が全然違うコードが返ってきて、「あ、もうこのセッションのClaude、私の書いたコードのことを半分忘れてるな」と。

3時間かけて積み上げた文脈が、目の前で溶けていく感覚。

あの「お腹の底がスーッと冷たくなる」感じ、Claude Codeをガッツリ使っている方なら覚えがあるんじゃないでしょうか？

だから後日、公式ドキュメントを全部読みました。「なんとなく」でやっていたことに、ちゃんと根拠が欲しかったんです。

で、たどり着いた答えがこれでした。

# ~/.zshrc に追記
export CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=80

Claude Codeがコンテキストを自動圧縮するタイミングを、デフォルトの95%から80%に早める設定です。

たった1行。でもこの1行が「なぜ効くのか」を理解するには、少し遠回りが必要でした。

/clear が正しいのは分かってる。でも現実は違う

公式のBest Practicesを読むと、コンテキスト管理の王道は `/clear`です。

さらにこうも書かれています。

同じ問題で2回修正に失敗したら、`/clear` して学んだことを組み込んだプロンプトでやり直せ、と。

…正論です。

圧縮を繰り返すと詳細が失われていく。失敗した試行錯誤の履歴が残っていると、むしろ判断を曇らせる。だから `/clear` でまっさらにしてやり直すのが一番きれい。

分かってます。分かってるんですけど。

「あと2ステップで終わるのに /clear してやり直せ」は、深夜1時には無理なんですって…🥺

実際に一番多いのは、タスクの残りがあと1〜2ステップなのにコンテキストがギリギリという状況。

ここで `/clear` してゼロから文脈を構築し直す？ また3時間？

無理ですよね…😥

だから現実的には `/compact`（圧縮して続行）を選ぶ。そしてそれは、公式ドキュメントの文脈を正しく読めば、間違った判断ではないんです。

/compact で乗り切りたい。ならauto-compactが味方になる

Claude Codeには、コンテキストが一定量に達すると自動で圧縮してくれる「auto-compact」機能があります。

手動で `/compact` を打たなくても、勝手にやってくれる。「あと少しで終わる」場面では、これが頼りになります。

ただし――ここが問題なんですが。

デフォルトは95%、これが遅すぎる

公式の設定ドキュメントには「auto-compact」機能についてこう書いてあります。

95%。コンテキストウィンドウのほぼ限界です。

ここで公式のBest Practicesにある、もうひとつの重要な記述を見てください。

コンテキストが埋まるほど性能が劣化する。95%時点ではもう劣化が進んでいる。

つまり、95%で自動圧縮が走っても、劣化した状態のコンテキストを圧縮しているにすぎない。もっと早い段階で――まだClaudeがしっかりコードを覚えている段階で圧縮した方が、圧縮後の品質は高いはずです。

この問題に対する答え＝環境変数1行で閾値を下げる

ここでようやく冒頭のコードに戻ります。

# ~/.zshrc に追記
export CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=80

`CLAUDE_AUTOCOMPACT_PCT_OVERRIDE` は、auto-compactが発動するコンテキスト使用率の閾値を変更する環境変数です。公式の設定ドキュメントに記載されています。

これを80に設定すると、コンテキストの80%を使った時点で自動圧縮が走ります。

なぜ80%なのかー

正直に言うと、最適な数値が何%なのかは公式ドキュメントには書かれていません。公式の例示は `50` ですが、これだと頻繁に圧縮が走りすぎる可能性があります。

私が80%にしているのは、実体験からの判断です。

• 95%（デフォルト）: 冒頭の事故が起きた。関数名の取り違え、存在しないimport。圧縮が走った時点で手遅れ感がある

• 80%（現在の設定）: まだClaude Codeがコードの文脈をしっかり保持している段階で圧縮される。圧縮後も関数名や引数を正しく扱える

• 50%（公式の例示値）: 試したことはありますが、短いセッションでも頻繁に圧縮が走って、ちょっと煩わしかった

80%が万人にとってのベストかは分かりません。でも少なくとも、95%よりはずっといい。

「いつ壊れるか分からない」から「まだ余裕がある段階で備える」への転換。たった1行で。

この1行で何が変わったか

設定を入れてから、あの深夜みたいな「突然コンテキストが溶ける」事故がなくなりました。

80%の時点で圧縮が走るので、「あ、そろそろだな」と心の準備ができる。圧縮後のClaudeも、ちゃんと私が書いた関数名を覚えている。「あと少し」を安心して続行できるようになった。

たった1行の環境変数で、開発中の「いつ切れるか分からない」という地味なストレスが消えた。
コードに集中できるようになった。

これは正直、かなり大きかったです。

さらに効果を上げるために

環境変数の閾値調整だけでも十分効果はありますが、合わせてやっておくと安心感が増すことを2つだけ紹介します。

1.プランファイルを「引き継ぎ書」にしておく

プランファイル（`.claude/plans/xxx.md`）はファイルシステム上に保存されるので、コンテキストの圧縮の影響を受けません。

ここに「どのファイルの何行目をどう変えるか」まで書いておけば、万が一セッションが壊れても、新しいセッションからすぐ復帰できます。

私がプランに必ず含めているのはこの4つです。

• 変更対象ファイルのパスと具体的な変更内容

• 再利用する既存関数・ユーティリティの場所

• ステップごとの完了チェックボックス（`- [x]` / `- [ ]`）

• 実装中に判明した注意点・却下した代替案

正直ちょっと面倒です。でもこれがあるとセッションが切れても怖くない。保険ですね。

2.サブエージェントでコンテキストを節約する

公式ドキュメントでは、サブエージェントを使うことでメインのコンテキスト消費を抑制できると説明されています。

調査やテストの実行をサブエージェントに任せれば、メインのコンテキストには結果だけが返ってくる。そもそもコンテキストを使い切りにくくなるので、auto-compactが走る回数自体が減ります。

まとめ

長くなったので、この記事で伝えたかったことを整理します。

1. /clear が正しいのは分かっている

公式ドキュメントの推奨は `/clear`（リセット）。圧縮を繰り返すと詳細が失われる。これは事実。

2. でも「あと少しで終わる」場面では /compact で乗り切りたい

深夜1時に「やり直せ」は無理。現実的には圧縮して続行する。

3. auto-compactのデフォルト95%は遅すぎる

公式ドキュメント自身が「コンテキストが埋まるほど性能が劣化する」と書いている。95%ではすでに劣化が進んでいる。

4. だから閾値を下げる。たった1行で。

export CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=80

まだClaudeがしっかりコードを覚えている段階で圧縮する。これだけで「あと少しなのに」問題がかなり減ります。

5. 保険としてプランファイルを書いておく

圧縮されないファイルに情報を置く。万が一セッションが壊れても、復帰コストが低い。

数字もプランも、正直に記録しておけば、あとで必ず助けてくれますよ。

それでは、今日も開発進めていきましょう！