auto-compact stuck at 0%の意味と対処 — Claude Code

Claude Codeで「Context left until auto-compact: 0%」という表示のまま進まなくなり、ツールが実質使えなくなる不具合が2025年8月に報告されました。GitHub issue #5385がこの症状をまとめており、/clearや再インストールでは直らないという報告が複数寄せられています。本記事は、このissueに書かれた発生条件とAnthropicのコメント、その後のバージョンでどう変わったかを扱います。

「auto-compact stuck at 0%」とは何を指すか

「auto-compact stuck at 0%」とは、Claude Codeが表示する残りコンテキストの割合(auto-compactまでの残量)が0%近くから動かなくなる状態を指す通称です。issue #5385のタイトルは「[CRITICAL] Context auto-compact stuck at 0% - Tool Unusable」です。報告者の環境はClaude Code 1.0.71、macOS 15.6、ターミナルはWarpでした。claudeをどのプロジェクトで起動しても、メッセージを送った直後から「Context left until auto-compact: 0%」という警告が表示され続けたとあります。この状態が続き、開発作業を進められなくなったと記載されています。

このissueはGitHub Actionsのbotによって、既存の類似issue(#1168、#3375、#2283)と重複している可能性が高いと判定されました。コメントが付かなければ3日後に自動closeされる運用で、duplicateラベルが付きました。2025年8月29日に一度closeされたあとも2026年1月までコメントが付き続け、同年2月に無活動でbotが自動closeしています。単発の誤検知ではなく、複数ユーザーが独立に遭遇した不具合でした。

どんな環境で起きたか

環境情報が明記されているのは報告者本人の1件だけですが、コメント欄には複数の独立した追随報告があります。NetDevAutomateさんは~/.claudeを削除しても改善せず、小規模なコードベースでも数分で0%近くまで落ちたと報告しました。benlrichardsさんはClaude Codeを完全に削除して再インストールしたあとも、MCPサーバーの有無にかかわらず同じ症状が出たとコメントしています。

最初の報告は8月8日から8月16日に続き、報告者本人の環境はv1.0.71でした。その後のコメントにはv1.0.85〜1.0.90の報告も続きます。特定のOSやターミナルに限定される再現条件ではなく、複数の環境で共通して踏まれていたことがコメントから分かります。

Vaibhav-api-codeさんは、新しいセッションを開始した直後からコンテキストを使い切る速度が明らかに変わったと報告しています。「compactツール自体が壊れたのか、それともコンテキストウィンドウ自体が縮小されたのか」という疑問も投げかけました。この時点でユーザー側から原因を切り分ける手段はほとんどなく、issueのコメント欄が実質的な情報交換の場になっていました。

効果がなかった対処

報告者のbrandontanさんをはじめ、コメント欄では次の対処が試されましたが、いずれも症状は改善しなかったと報告されています。

• /clearを実行する
• Claude Codeを完全に削除して再インストールする
• ~/.claudeディレクトリを削除する
• ローカルの設定値(コンテキストの上限やcompactのしきい値)を独自に調整する
• 当時新しく追加されていた「microcompact」機能に切り替える
• 1Mトークンのコンテキストウィンドウが自動的に使われることを期待する

brandontanさんは、microcompactへの切り替えでも改善しなかったことと、1Mコンテキストが有効になることを期待していたが実際には発動しなかったことの両方をコメントで報告しています。

ローカル設定の調整には、もう一つ注意があります。issueに書かれた項目名(maxContextTokensやcompactionThresholdなど)は、現在の公式ドキュメントの設定一覧にありません。現行の設定名はCLAUDE_CODE_AUTO_COMPACT_WINDOWやCLAUDE_AUTOCOMPACT_PCT_OVERRIDEなどです。

Anthropicのsid374さんのコメントから分かること

2025年8月13日、Anthropicのsid374さんがissueにコメントを付けました。ログを確認したところ、報告者のMCPサーバーが大きなレスポンスを返しており、compact後にも同じ大きなファイルを何度も読み直していた、という2点を指摘しています。

報告者が貼ったログには、885行のJSONファイルが5本記録されていました。production-criteria/FAR-140-CHECKIFEXISTS-FIX.jsonなどで、圧縮のたびに繰り返し読み込まれています。compactが会話履歴を要約しても、次のターンで同じ大きなファイル群を毎回読み直せば、コンテキストはすぐにまた埋まります。これがsid374さんの言う「compact後に大きなファイルを再度読み込んでいる」状態の具体例です。

MCPサーバーを複数繋ぐとツール定義そのものがコンテキストを圧迫することは、MCPのツール定義はなぜコンテキストを圧迫するのかで扱った通りです。8月13日の指摘はツール定義ではなく、ツールの実行結果とファイル再読み込みが大きかったケースです。ただし想定より多くのトークンがコンテキストに繰り返し流れ込む点は共通しています。

sid374さんは、次に同じ症状が出たときは/bugコマンドでフィードバックを送り、Feedback IDを共有するよう依頼しています。brandontanさんは8月14日に実際にFeedback IDを送っています。

この不具合はその後どう扱われたか

issue #5385自体は、重複ラベルが付いたまま無活動の自動closeになりました。

8月22日にはsid374さんが、/contextがMCPツールと組み込みツールを少なく数えていた問題は1.0.88で修正済みと書いています。残る原因候補として挙げたのは、大きなCLAUDE.md、エージェントやMCPツールのdescription、フックが注入する大量のコンテキストです。8月29日には報告者が、1.0.96でMCPの占有が50%から0%に戻ったと書いています。

重複先とされた#1168・#2283・#3375はいずれも#5385より若い番号で、同じ症状がそれ以前にも複数回報告されていたことになります。公式changelogを追うと、issue #5385が報告された後、コンテキスト表示やcompact周りにいくつかの修正が段階的に入っています。ただし下の表の各行について、issue #5385の症状に直接対応すると明言した記述はなく、関係の強さは行ごとに異なります。

このうちv2.1.89だけが、issue #5385で報告されていた「compactが終わった直後にまた埋まり、延々とループする」症状と型が一致します。ただしこれも根本原因を取り除く修正ではなく、同じ状態を検知してエラーで止める変更です。ほかの行はコンテキスト表示やcompact周りの別系統の修正で、#5385の症状に対応すると書かれたものはありません。v2.1.117の詳細はClaude Code v2.1.117のリリースノートにまとめています。コンテキストを圧迫している原因そのものを絞り込む手段は変わっていません。/contextの内訳確認が引き続き有効で、具体的な手順はClaude Codeのコンテキストウィンドウを可視化して中身を確認する方法で扱いました。

今この症状が出たときにまず試すこと

まず実行中のバージョンを確かめ、古ければ更新します。それでも止まる場合の復旧手順は、公式トラブルシューティングの「Auto-compaction stops with a thrashing error」節にあります。残量が100%になっても圧縮が走らない症状は、auto compactが100%で止まるときの対処で扱っています。

claude -v

Autocompact is thrashing: the context refilled to the limit...というエラーは、compact自体は成功しているのに、ファイルやツール出力が直後にコンテキストを何度も埋め直したときに出ます。Claude Codeは無駄なAPI呼び出しを避けるため、そこで再試行をやめます。復旧の流れは次のとおりです。

/clearのあとでも再発するとき

/clearの直後に同じエラーが出るなら、/contextを開いてMessagesの行をほかの行と比べます。公式の切り分けは次の2通りです。

原因が自分のカスタマイズにあるかを見るには、claude --safe-modeで起動します。CLAUDE.md・skills・プラグイン・フック・MCPサーバーなどを無効にした状態でセッションが始まるので、症状が消えれば原因はそのどれかです。認証・モデル選択・組み込みツール・権限は通常どおり動きます。

claude --safe-mode

/doctorはインストール・設定・拡張機能・コンテキスト使用量の自動チェックで、直せるものは確認のうえで修正案を適用できます。Claude Codeが起動しないときは、シェルからclaude doctorを実行します。

sid374さんのコメントにあるように、MCPサーバーの応答が大きい、同じ大きなファイルを繰り返し読み込んでいる、大きなCLAUDE.mdやエージェントのdescriptionがある、フックが大量のコンテキストを注入している、のどれかに心当たりがあるなら、MAX_MCP_OUTPUT_TOKENSでMCPツールの出力上限を絞る方法も切り分けの候補です。それでも変わらないときは、/bugでフィードバックを送り、表示されるFeedback IDを添えて報告します。issue内でsid374さんが案内していた手順です。

表示の「%」は、どの窓を基準にしているか

自動compactの窓(どこまで埋まったらcompactするか)は、現在のClaude Codeでは利用者が変えられます。「0%」や「100%使用」の表示を読むときは、設定が窓をどう動かしているかが前提になります。v2.1.289のclaude --helpには、次の行があります。

--autocompact <auto|tokens>           Auto-compact window size (auto, or
                                      100k–1M tokens)

窓を決める経路は4つあり、優先順位がはっきり決まっています。

値は100Kから1Mトークンの範囲で、/autocompactと--autocompactは500kや1Mの書き方も受け付けます。環境変数だけは500000のような素の整数しか受け付けず、500kと書くと500と読まれて下限の100Kに丸められます。--autocompactフラグはv2.1.221以降で使えます。

読み間違えやすい点が2つあります。CLAUDE_CODE_AUTO_COMPACT_WINDOWを設定すると、ステータスラインのused_percentageはモデル本来のコンテキストウィンドウ全体に対する割合のままなので、その数字からcompactの発動時点は読み取れなくなります。もう一つは既定の窓で、ネイティブ1Mのモデル(Sonnet 5やFableなど)は、窓が埋まる前の約967Kトークンでcompactします。CLAUDE_CODE_DISABLE_1M_CONTEXT=1を設定すると、同じモデルでも200Kの境界でcompactする側に変わります。

表示が想定した窓と合わないときは、窓を動かす設定が入っていないかを先に見ます。自動更新の直後に窓の表示が200Kへ戻り、「100%使用」と誤表示される不具合は、先の表のv2.1.208で直っています。

まとめ

切り分けは、バージョン、thrashingエラーの有無、/contextの大小、--safe-modeの順に進めます。CLAUDE_CODE_AUTO_COMPACT_WINDOWなどで窓を動かしているときは、「%」の表示がcompactの発動時点を表さないので、先に設定を外して見比べます。

同種のループがエラーとして検知されるようになったのは、2026年4月公開のv2.1.89からです。