Claude Codeのauto-compact(自動圧縮)が動かない・止まる——原因別に公式changelogとGitHub Issueで確認した対処法
Claude Codeのauto-compactが100%に達しても発動しない、サードパーティAPI経由だと止まる、長時間セッションで固まる——症状別に公式changelogとGitHub Issueの一次情報から原因を特定し、アップデート・手動/compact・ダウングレードまで対処法をまとめた。
エンジニアのゆとです。
長時間Claude Codeにコードを書かせていると、ステータスバーの端に出ている「context left until auto-compact」の数字がどんどん減っていく。0になったら勝手に会話が圧縮されて続く……はずなのに、減り切ったところで何も起きず、次のメッセージがエラーで弾かれる。あるいは急にターミナルが数秒固まって、フリーズしたのかと思ってCtrl+Cを押しかけて、実は裏でちゃんと動いていた——という経験をした人、たぶん自分だけじゃないと思う。
「auto-compact」で検索すると、GitHubのIssueとRedditの投稿がずらっと並ぶ。海外では相当報告されているのに、日本語でこの現象を整理した記事がほぼ見当たらなかったので、公式changelogとAnthropic自身のGitHub Issueトラッカーを一次情報として、症状別に何が起きているかを整理した。
結論 — まず自分の症状がどれに当てはまるか確認する
| 症状 | 状態 | 原因 | 今すぐできる対処 |
|---|---|---|---|
ANTHROPIC_BASE_URLをBedrock/Vertex/カスタムゲートウェイに向けているとauto-compactが一切発動しない | 未修正（v2.1.163時点でOpen） | v2.1.161で追加された内部の認証判定がサードパーティ利用者を弾いていた | 手動で/compactを実行。どうしても自動化したいならv2.1.150へのダウングレードも選択肢 |
| コンテキストが100%に達してもauto-compactが起動せず、セッションがそのまま止まる | 未修正（長期化しているOpen Issue） | 明確な原因は未特定。回帰バグとして12バージョン以上前から報告が継続 | 100%になる前に手動で/compactを打つ習慣にする。CLAUDE.mdへの指示は効果なしと報告あり |
| 32MBを超える巨大な会話でauto-compactが何度もリトライを繰り返す | v2.1.214で修正済み | 画像やドキュメントを削れずAPIの32MB上限を超え続け、無限にリトライしていた | アップデートすれば1回失敗して明確なメッセージが出るようになる |
| 長時間セッションでときどき数秒間ターミナルが固まる、再開が遅い | v2.1.216で修正済み | メッセージの正規化処理コストがターン数に対して二次関数的に増加していた | アップデートで解消。古いバージョンなら/clearで会話をリセットして回避 |
| 圧縮中に画面が止まったように見えて不安になる | v2.1.221で改善済み | 進捗表示がプログレスバーのみで、リトライ中かどうか分からなかった | アップデートすればリトライのカウントダウンと停止ヒントが表示される |
| 1Mコンテキスト対応モデルなのに200Kで圧縮がかかる／未知のモデルIDで挙動が変わった | v2.1.223で仕様変更 | CLAUDE_CODE_DISABLE_1M_CONTEXTの適用範囲が全モデルに拡大され、未知のモデルIDにも推定コンテキスト幅が強制されるようになった | 意図した挙動なら対処不要。以前の挙動に戻したいなら環境変数で復元可能（後述） |
自分の症状が分かったら該当の見出しまで飛んで構わない。
ケース1: サードパーティAPI経由だとauto-compactがそもそも発動しない
一番深刻なのがこれ。Bedrock、Vertex AI、Zhipu AI（智谱）、AWS Foundry、あるいは自前のANTHROPIC_BASE_URLゲートウェイ経由でClaude Codeを使っているユーザーから、v2.1.161以降でauto-compactが完全に止まったという報告がまとまっている。
このIssueが興味深いのは、報告者がClaude Codeのバイナリを実際に逆解析して、原因の関数まで特定していること。v2.1.150時点ではauto-compactの発動判定にGrowthBook（機能フラグ管理の仕組み）の値をそのまま使っていたのが、v2.1.161で「リモート環境かどうか」「ファーストパーティ認証かどうか」というチェックが新たに挟まった。この新しいチェックが、ANTHROPIC_BASE_URLをAnthropicの公式エンドポイント以外に向けている＝サードパーティ扱いのユーザーを弾いてしまい、機能フラグが取得できずデフォルト値のfalseにフォールバックしていた、という流れだ。
v2.1.150までは約153kトークンで自動的に圧縮が走っていたのに、v2.1.161以降は何トークン貯めても発動しない。手動の/compactは問題なく機能するので、応急処置としてはこちらを使うしかない。Issue内ではCLAUDE_CODE_ENABLE_AUTO_COMPACTのような環境変数での明示的な制御が提案されているが、あくまで提案段階で、この記事を書いている時点ではまだ実装されていない（実装済みかどうかはclaude --versionを上げたうえでcode.claude.com/docs/en/changelogで確認するのが確実）。
どうしても自動圧縮を復活させたい場合、v2.1.150への一時的なダウングレードも技術的には可能。ただし他の修正（後述するケース3・4など）も同時に失うことになるので、まずは手動/compactの運用で様子を見るのが無難だと思う。
ケース2: コンテキストが100%に達してもauto-compactが起動しない
こちらはサードパーティAPIに限らない、より広く報告されているパターン。
このIssueでは、コンテキストウィンドウが100%に達してもauto-compactが動かず、Claude Codeが自分から処理を止めてしまう挙動が報告されている。CLAUDE.mdに「コンテキストが減ったら自動で圧縮して」という指示を書き加えても改善しないという報告もあり、これはプロンプトで制御できる領域の話ではなく、内部のトリガー判定そのものの問題であることを示唆している。報告では「過去のバージョンでは動いていた」という回帰（リグレッション）判定がついており、単発のバグではなく一定期間にわたって発生し続けている状態だ。
明確な修正版がchangelogに見当たらない以上、現状でできる対処は「100%になる前に自分で/compactを打つ」運用でカバーすることになる。ステータスバーのcontext left until auto-compactの数字を横目に見ておいて、10%台まで減ってきたら自分から圧縮をかける、というのが実質的な回避策になる。
# 手動でコンテキストを圧縮する
/compactケース3: 32MBを超える巨大な会話が無限リトライしていた（修正済み）
ここからは実際にchangelogで修正が確認できているケース。v2.1.214のchangelogにはこうある。
Fixed conversations whose messages alone exceed the API’s 32 MB request limit retrying compaction when no images or documents can be stripped; they now fail once with a clear message
長時間のセッションで画像添付や大きなドキュメントを何度もやり取りしていると、メッセージ本体だけでAPIのリクエスト上限である32MBを超えてしまうことがある。この状態で自動圧縮が走ろうとすると、削れる画像やドキュメントがすでに残っていないため、圧縮を試みては失敗し、また試みては失敗する、というループに陥っていた。v2.1.214以降はこのループが解消され、1回失敗した時点で「なぜ自動圧縮でこのプロンプトを回復できなかったか」を明示するメッセージが出るようになっている。以前は/compactを促すだけの曖昧なエラーだったのが、原因まで説明されるようになった点も地味に助かる変更だ。
ケース4: 長時間セッションで謎の数秒フリーズ（修正済み）
「フリーズはしていないはずなのに、たまに数秒間だけ入力を受け付けなくなる」という症状に心当たりがあるなら、これが該当する可能性が高い。v2.1.216のchangelogから。
Fixed a slowdown in long sessions where message normalization cost grew quadratically with the number of turns, causing multi-second stalls and slow resumes
ターン数（やり取りの往復回数）が増えるほど、メッセージを正規化する処理のコストが線形ではなく二次関数的に増えていた、という不具合。会話が長くなればなるほど、1ターンごとの処理時間がじわじわ伸びていき、セッションを再開するときにも同じ処理が走るため「resumeがやたら遅い」という体感にもつながっていた。v2.1.216で解消済みなので、アップデートしていれば長時間セッションでも処理コストは一定に近い状態を保てる。
ケース5: 圧縮中に「止まった」ように見えるだけ（改善済み）
これは厳密にはバグというより、UIの分かりにくさが原因の勘違いに近い。v2.1.221のchangelogから。
Improved compaction progress: the retry countdown and stall hint now appear during compaction instead of only a progress bar
以前のバージョンでは、圧縮処理中に表示されるのはただのプログレスバーだけだった。裏でリトライが走っていても、画面上はプログレスバーが動いているのか止まっているのか判別しづらく、「固まった」と誤解してCtrl+Cを押してしまう人が一定数いたと思われる。v2.1.221以降はリトライのカウントダウンと、処理が滞っていることを示すヒントがその場に表示されるようになっている。見た目の情報が増えただけで実際の圧縮処理自体が速くなったわけではないが、「今何が起きているか分からず不安になる」という体験は大きく改善されている。
1Mコンテキストモデルの罠 — v2.1.223で挙動が変わった
Sonnet系・Opus系の1Mコンテキスト対応モデルを使っている場合、v2.1.223で仕様が変わっている点も押さえておきたい。changelogにはこう書かれている。
Changed
CLAUDE_CODE_DISABLE_1M_CONTEXTto hold every Claude model with a native 1M window to 200K via auto-compaction, not just a fixed list; a startup warning now appears when auto-compaction isn’t holding the session to 200K
CLAUDE_CODE_DISABLE_1M_CONTEXTという環境変数自体は以前から存在していたが、これまでは決め打ちのモデルリストにしか適用されていなかった。v2.1.223以降は、ネイティブに1Mコンテキストを持つモデル全般に対して「auto-compactで200Kに抑える」という挙動が一律で適用されるようになった。「1Mコンテキストのはずなのに、体感的にすぐ圧縮がかかる」と感じたら、この環境変数が有効になっていないか確認するといい。
もう一つ、同じバージョンで未知のモデルID（社内プロキシ経由などでClaude Code側が認識していないモデル名を使っている場合）に対する挙動も変わっている。
Changed auto-compact to keep sessions on unrecognized model IDs within the assumed context window instead of letting them grow past it; set
CLAUDE_CODE_DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT=1to restore the previous behavior
以前は未知のモデルIDだとコンテキストウィンドウの制限を無視して際限なく会話が伸びていたが、v2.1.223以降は推定されるコンテキスト幅の中に強制的に収めるようになった。カスタムゲートウェイ経由で独自のモデル名を使っている人がこれまでと違う挙動に戸惑ったら、CLAUDE_CODE_DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT=1を設定すれば旧挙動に戻せる。
「context left until auto-compact」は何を表しているのか
ステータスバーに出るcontext left until auto-compactは、現在のコンテキストウィンドウの使用量と、auto-compactが発動するまでの残り容量を示す表示だ。この数値がゼロに近づいた状態で放置していると、ここまで見てきたケース1・2のような「発動しないバグ」を踏んだ場合にそのまま処理が止まってしまう。バグの有無に関わらず、この数字を定期的に確認する癖をつけておくこと自体が、実質的な保険になる。
自分の状況を確認する手順
パニックになって再実行やCtrl+Cを連打する前に、次の順番で確認するといい。
1. バージョンを確認する
claude --versionここまでのケースはすべて対応バージョン以降で解消しているか、変更が入っている。まず自分がどのバージョンにいるかを把握する。
2. アップデートする
claude updatenpm経由のグローバルインストールならこちらでも上げられる。
npm update -g @anthropic-ai/claude-code
3. サードパーティAPI経由かどうかを確認する
echo $ANTHROPIC_BASE_URL何か値が設定されていて、かつauto-compactが発動しないなら、ケース1の可能性が高い。設定を外して公式エンドポイント直結で再現するか試すと切り分けになる。
4. それでも解決しない場合
アップデートしても、環境変数を見直しても改善しない場合は、ケース2のように現時点で未修正のバグを踏んでいる可能性がある。同じ症状の報告がないか検索してから、なければ新規に報告するのが確実。
FAQ
auto-compactが動かないとき、手動の/compactだけでどうにかなる？
なる。自動発動が止まっているだけで、手動コマンド自体は正常に機能しているケースがほとんど。長時間セッションになりそうだと分かっている作業では、ステータスバーの残量を見ながら早めに自分で/compactを打つ運用に切り替えるのが実務上は一番手堅い。
CLAUDE_CODE_DISABLE_1M_CONTEXTはどんな時に使うべき？
1Mコンテキストを使い切る前に品質が落ちる体感がある場合、あえて200Kで区切って圧縮を挟んだほうが安定することがある。逆に長大なコードベース全体を一度に読ませたい場合は無効のままにしておくべきで、万能な設定ではない。
ダウングレードは推奨される対処法？
積極的には勧めない。ケース1のサードパーティAPI問題を回避できる代わりに、ケース3・4・5で直っている改善もまとめて失うことになる。まずは手動/compactの運用でしのぎつつ、changelogを定期的にチェックして該当の修正が入ったタイミングでアップデートするのが良いと思う。
まとめ
「auto-compactが動かない」という一言でも、中身は最低5パターンに分かれている。サードパーティAPI経由なら内部の認証判定が原因で発動自体がブロックされている可能性が高いし、100%到達後に止まるなら現状まだ未修正の回帰バグを踏んでいる。一方で巨大な会話での無限リトライや長時間セッションでの謎フリーズは、すでにchangelog上で直っている。
自分の症状がどれに当てはまるかをclaude --versionとここまでの表で突き合わせてから対処すれば、意味もなくダウングレードしたり、原因不明のまま/compactを連打したりする無駄を減らせるはずだ。
