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ラベルが付いてcloseされています。ただしclose後も2025年8月16日まで新しい報告が書き込まれ続けており、単発の誤検知ではなく複数ユーザーが独立に遭遇した不具合でした。

どんな環境で起きたか

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

報告のタイミングは2025年8月8日から8月16日に集中しており、いずれもv1.0.7x系のバージョンでした。特定のOSやターミナルに限定される再現条件ではなく、複数の環境で共通して踏まれていたことがコメントから分かります。

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

効果がなかった対処

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

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

brandontanさんは、microcompactへの切り替えでも改善しなかったことと、1Mコンテキストが有効になることを期待していたが実際には発動しなかったことの両方をコメントで報告しています。ローカル設定の調整については注意が必要です。変更した項目の名称は、公式ドキュメントが定義する設定名(CLAUDE_CODE_AUTO_COMPACT_WINDOWやCLAUDE_AUTOCOMPACT_PCT_OVERRIDEなど)と一致していません。当時のバージョンで実際に効果を持つ設定だったかは、issueの記述だけでは確認できません。

Anthropicの調査から分かること

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

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

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

sid374さんは、次に同じ症状が出たときは/bugコマンドでフィードバックを送り、Feedback IDを共有するよう依頼しています。brandontanさんは8月14日に実際にFeedback IDを送っていますが、issueのコメント欄にはその後の個別調査結果は記載されていません。

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

issue #5385自体は重複ラベルが付いたままcloseされており、「vX.Y.Zで修正」という公式なコメントは残っていません。重複先とされた#1168・#2283・#3375はいずれも#5385より若い番号で、同じ症状がそれ以前にも複数回報告されていたことになります。公式changelogを追うと、issue #5385が報告された後、コンテキスト表示やcompact周りにいくつかの修正が段階的に入っています。ただしこれらがissue #5385の症状に直接対応すると明言した公式コメントはなく、関係の強さは行ごとに異なります。

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

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

この症状が出たら、まず実行中のバージョンを確認し、古ければ更新するのが基本です。それでも解消しない場合に向けて、公式のトラブルシューティングガイドの「Auto-compaction stops with a thrashing error」節が具体的な復旧手順を示しています。

claude -v

claude --safe-mode

/doctorを実行すると、MCPサーバーやフックを含む設定・コンテキスト使用量の自動チェックが行われます。

/doctor

公式ガイドが挙げる具体的な復旧策は次の4つです。

1. 巨大なファイルを丸ごとではなく、行範囲や関数単位で読み込ませる
2. /compact keep only the plan and the diffのように対象を絞って手動/compactを実行する
3. 大きなファイルを扱う作業をサブエージェントに移し、別のコンテキストウィンドウで処理する
4. それ以前の会話が不要なら/clearで新しいセッションを始める

Anthropicの調査コメントが示すように、MCPサーバーの応答が大きい・同じ大きなファイルを繰り返し読み込んでいる、という心当たりがあるなら、MAX_MCP_OUTPUT_TOKENSでMCPツールの出力上限を絞る方法も切り分けの候補になります。

これでも改善しない場合は、/bugでフィードバックを送り、表示されるFeedback IDを添えて報告するのが、issue内でsid374さんが案内していた対処です。

まとめ

「Context left until auto-compact: 0%」から動かなくなる症状は、2025年8月にissue #5385としてまとめて報告されました。/clearや再インストールでは直らないケースが多く、Anthropicの調査ではMCPサーバーの大きなレスポンスが原因の一端として指摘されています。issue自体は重複判定でcloseされていますが、同種の「compact直後にまた埋まる」状態は2026年3月公開のv2.1.89で明示的なエラーとして検知されるようになりました。バージョンを更新しても解消しない場合、--safe-modeでMCPサーバーやフックを切り分けるのが公式トラブルシューティングガイドの案内で、それでも解決しなければissue内でsid374さんが案内した/bugでの報告に進みます。