メインコンテンツへスキップ
Dev Tools 24分で読める

Claude Codeアイドル圧縮の止め方｜放置54分で要約されるidle compactionを無効化

#Claude Code#Claude#Anthropic#プロンプトキャッシュ#コンパクション#コスト最適化#AI開発ツール

「コーヒーを淹れているあいだに会話が要約されないよう、ターミナルまで走って戻らなきゃいけないなんておかしい」。

100万トークンまで扱える1Mコンテキストの25%程度しか使っていないのに圧縮されるのはおかしい、と訴えるユーザー kengulick が、GitHubにそう書き込んだのは2026年10月14日だ（出典: anthropics/claude-code issue #98747、原文は英語、日本語は筆者訳）。同じ日、Anthropicは問題の機能をv2.1.299のチェンジログに初めて正式に載せた。

機能の名前は idle compaction（アイドル圧縮、アイドル時のコンパクション）。長い会話を放置すると、プロンプトキャッシュが切れる直前にClaude Codeが自分で会話を要約する。節約のための機能なのに、最初に届いた反応の多くは怒りだった。何が起きているのか、残すべきか切るべきかを整理する。

この記事はこんな人におすすめ
  • Claude CodeをPro / Maxプランのターミナル版で使い、長いセッションを抱えたまま離席することがある方
  • 戻ってきたら「Compacted while idle, before the prompt cache expired」と出ていて驚いた方
  • 長時間のデバッグで、Claudeに細かい経緯を覚えておいてほしい方
  • 利用枠の減りが気になっていて、設定で節約できる余地を探している方
結論（忙しい人向け）
  • 何が起きるか: ターミナル版で20万トークン以上の会話を約54分放置すると、1時間のキャッシュが切れる前に自動で要約される
  • いつから: チェンジログ上はv2.1.299（2026年10月14日UTC公開）。ユーザー報告ではv2.1.286の頃から告知なしで動いていた
  • 切り方: /config の「Idle compaction」をオフ（v2.1.302以降）、または settings.json に "idleCompaction": false（手順はこちら）
  • 中間の選択肢: CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS で発動下限を引き上げる
  • 対象外: APIキー利用（既定のキャッシュ寿命が5分のため）。デスクトップアプリでは発動しないとの報告あり
  • 筆者の判断: 既定のまま残し、細部が命の長いデバッグ中だけ下限を50万に上げる

「Compacted while idle」とは？アイドル圧縮で起きること

Claude Codeは、毎回のリクエストで会話全体をAPIに送り直している。量は「トークン」（文章を細かく刻んだ単位）で数え、料金も利用枠もこれで決まる。それでも毎回フル料金にならないのは、前回と同じ先頭部分をサーバー側が一時保存（プロンプトキャッシュ）して再利用するからだ。

このキャッシュには寿命（TTL）がある。公式ドキュメントによると、Claudeのサブスクリプションをプラン内で使っているとき、メインの会話は1時間、それ以外（APIキー、クラウドプロバイダ、枠超過後の従量課金であるusage credits利用時）は5分が既定になる（出典: Claude Code Docs - How Claude Code uses prompt caching）。

寿命を過ぎてから「続きをお願い」と1行送ると、会話全体が読み直される。キャッシュの書き込みは1時間TTLの場合で通常入力の2倍、読み込みは0.1倍という料金倍率だ（出典: Claude Platform Docs - Prompt caching）。なお同じ料金ページによると、Opus 5.5とSonnet 5.5の読み込みは0.05倍とさらに安い。以下の試算は標準の0.1倍で計算する。

アイドル圧縮は、この差を突く。キャッシュがまだ生きている（本記事では「温かい」と呼ぶ）うちに要約を作っておけば、読むのは安い0.1倍の側で済み、戻ってきたときに読み直す量は要約分だけになる。v2.1.299のチェンジログはこう書いている。

20万トークン以上の会話を約54分放置すると、1時間のプロンプトキャッシュが切れる前に圧縮する。次のメッセージで全体を再処理せずに済む（出典: Claude Code CHANGELOG 2.1.299、筆者訳）

54分という数字は、1時間の約9割にあたる。キャッシュ切れのぎりぎり手前を狙っているわけだ。

発動条件のまとめ

条件内容
実行環境ターミナル版（CLI）。デスクトップアプリは対象外と報告されている
会話の大きさ20万トークン以上（CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS で変更可）
放置時間約54分
キャッシュ寿命1時間TTLの会話のみ。既定で該当するのはサブスクリプションのプラン内利用
PCの状態Claude Codeのプロセスが動いている必要がある。スリープ中は走らないとみられる

そもそも自分のキャッシュは1時間？5分？

アイドル圧縮が動くかどうかはキャッシュ寿命で決まる。確認方法と切り替え設定をまとめた。

キャッシュ寿命を確認する

発動下限の最小値は10万トークンだという情報がある。ただしこれはユーザーがバイナリを解析して報告したもので（issue #98747 の John-Rood のコメント）、公式ドキュメントには記載がない点に注意したい。

誤解しやすいが、これは「キャッシュの延命」ではない。issue #66115 で yurukusa が指摘したとおり、圧縮はキャッシュを温かく保つわけではなく、いずれ来る冷えた読み直しを小さくするだけだ（出典: anthropics/claude-code issue #66115）。

実測：27万トークンが1万3千トークンに

日本語圏で実際に観測した記録がある。Zennの「おじさんAIラボ」は、27万トークンを超える会話を約55分放置して挙動を追った（出典: Zenn - Claude Codeの会話を55分放っておいたら、272,422トークンが13,522に圧縮されていました、2026年10月19日）。

  • 272,422トークンが13,522トークンに圧縮された
  • 最後のリクエストから圧縮まで55.6分、要約にかかった時間は約1分46秒
  • 圧縮後、直近に読んでいた5本のファイルを自動で読み直していた
  • 過去ログにも同様の例が3件あり、73万トークン超の会話が約1万5千トークンになったケースもあった

著者は、機能を切った場合との比較はできていないこと、サンプルが4件しかないことも明記している。

この数字を使って、料金倍率から試算してみる。27万トークンの会話で、通常入力1トークンを「1」と数える。

再開のしかた入力側の負担（概算）
放置して1時間超え、キャッシュ切れで再開27万 × 2倍 ＝ 約54万
アイドル圧縮あり読み込み 27万 × 0.1倍 ＋ 要約の書き込み 1.35万 × 2倍 ＝ 約5.4万

おおむね10分の1だ。要約の生成にかかる出力トークンはこの表に入っていないし、サブスクリプションの枠がトークンとどう換算されるかは公開されていない。あくまで公開料金からの概算として見てほしい。

issue #66115 の dthinkr は、142回の圧縮を集計して「要約後のサイズは元の約2割」という比率を出している。上のZennの例は5%程度なので、要約の縮み方は会話の中身によってかなり幅があるようだ。

もう1つ、Zennの観測で見落とせない点がある。圧縮から約65分後に1行送ったところ、合計94,798トークンのうち57,161トークンが通常入力だった。圧縮後の短い会話にも1時間の寿命があり、それを過ぎればまた冷える。圧縮は1回きりの保険だと理解しておくとよい。

なぜ「節約機能」が反発を招いたのか

告知なしで既定オンだった

issue #98747 の報告者 natefosterwarner によると、この挙動はv2.1.286の頃から始まっていた。npm上の公開日は2026年9月30日（UTC）で、そのバージョンのチェンジログにアイドル圧縮の記載はない。報告者は約20本の並列セッションのうち7本が一晩で圧縮されたと書いている。しかもどれもコンテキスト上限には近くなかった。

当時のトランスクリプトには、/compact を打っていないのに trigger: "manual" と記録されていた。フック（圧縮などのイベント時に自作スクリプトを走らせる仕組み）で圧縮を検知していた人ほど混乱しただろう。

コメント欄は荒れた。jlacroix42 は「破壊的な機能を既定で有効にして出荷するのが理解できない」と書き、執筆時点で16件の賛同を集めている。rkhamilton は「自動で圧縮されて、しかもファイルを読み直さないので作業の流れが壊れる」と訴えた（いずれも筆者訳）。

Anthropicの対応は早かった

Anthropic側の担当者とみられる blois は10月2日に「設定は用意する。今は20万トークン以上の大きなコンテキストだけが対象だ」と返答し（筆者訳）、こう続けている。

圧縮がもっと邪魔にならない状態に持っていく必要がある（筆者訳）

10月5日公開のv2.1.290で idleCompaction 設定が入った。blois の10月6日のコメントによれば、トリガー表記も auto に直ったという。v2.1.299でチェンジログに正式に記載され、v2.1.302では /config から切り替えられるようになった。約2週間で「告知なし・設定なし」から「画面で切れる」まで来た計算だ。

ファイルの読み直しについては、上のZennの観測（10月19日）では直近の5本を読み直していた。rkhamiltonの不満が出た時点から改善されたのか、条件によって違うのかは、自分には判断できない。

周辺ツールとの相性問題

ターミナルをまとめて管理するツール側でも影響が出ている。Orcaでは、アイドル圧縮が走るとターンが実行されていないのにワークスペースが「未読」になる不具合が報告された（出典: stablyai/orca issue #28712、2026年10月14日）。報告時点の回避策は、idleCompaction を切ることだけだった。

デスクトップアプリでは動かない

デスクトップアプリのCodeタブでは、20万トークンを超える会話を1時間以上放置しても圧縮されなかったという報告がある（出典: anthropics/claude-code issue #103189）。適用を求める要望は issue #103040 にまとまっている。Claude Code Desktopの大型アップデート以降、デスクトップで長いセッションを回す人は増えているはずなので、ここは今後の対応を待ちたい。

アイドル圧縮（idleCompaction）を無効にする3つの方法

1. /config から切る（v2.1.302以降）

ターミナルで /config を開き、「Idle compaction」の行をオフにする。いちばん手軽だ。圧縮後に出る通知にも、切り方が表示されるようになった。

2. settings.json で切る（v2.1.290以降）

{
  "idleCompaction": false
}

~/.claude/settings.json に書けば全プロジェクトに効く。チームで統一したいなら、リポジトリの .claude/settings.json に置く手もある。

3. 発動下限を上げる

完全には切らず、もっと大きな会話だけを対象にしたい場合は環境変数を使う。

{
  "env": {
    "CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS": "500000"
  }
}

issue #98747 では tylerlaprade が「50万〜60万あたりを閾値にしたい」と要望していた。1Mコンテキストで長く作業する人には、このあたりが落としどころになりそうだ。

自分で圧縮したほうがいい場面

アイドル圧縮の要約は、何を残すかをこちらが指定できない。離席が事前にわかっているなら、/compact テストの失敗ログと変更したファイル名を優先して残して のように指示を付けて自分で畳むほうが確実だ。公式ドキュメントも、/compact は自動に任せず作業の区切りで実行することを勧めている（出典: Claude Code Docs - Manage costs effectively）。

まったく別の作業に移るなら、/rename で名前を付けてから /clear で新しい会話にすればよい。/clear そのものはトークンを使わない。

自分（電脳狐影）ならこうする

自分は既定のオンのまま残す。理由は単純で、離席は予定どおりに来ないからだ。会議が延びる、急な電話が入る、昼食が長引く。そういうときに27万トークンの会話を冷やして戻ってくると、上の試算どおりなら再開1発目の入力側の負担は約10倍になる。9月の週次制限変更で枠に余裕がなくなった今、保険としての価値は大きい。

ただし、2つの場面では設定を変える。

1つ目は、原因不明のバグを何時間も追っている最中だ。どの仮説を潰したか、どのログが怪しかったかという経緯そのものが資産になる。ここで要約されると、同じ仮説をもう一度試し始めかねない。この期間だけ CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS を50万に上げておく。

2つ目は、圧縮をフックで監視している自動化の環境だ。issue #98747 の報告者も指摘しているように、フックの trigger からは、上限による自動圧縮とアイドル圧縮を区別できない。区別が必要な仕組みを組んでいるなら、いったん切って様子を見る。

一方で、Anthropicの出し方には苦言を呈したい。ユーザー報告を見る限り、会話を要約に置き換える機能が、告知なしで既定オンのまま配られていた。PMの目線で見れば、機能の中身より、この順番のほうが信頼を削っている。節約になるのは確かなので、最初からチェンジログに書いて /config の行と一緒に出していれば、反応はまったく違ったはずだ。

使い分け早見表

あなたの使い方おすすめ
サブスクのターミナル版で、離席が多い既定のまま（オン）
1Mコンテキストで長時間の調査・デバッグ下限を50万前後に引き上げ
フックで圧縮を検知する自動化を組んでいる一時的にオフ、挙動を確認
Orcaなど外部のターミナル管理ツールで未読表示が乱れる修正が出るまでオフ
APIキー利用、デスクトップアプリ通常は発動しないので対応不要
確認しておきたいこと
  • claude --version で自分のバージョンを確認する。/config の行はv2.1.302以降、idleCompaction 設定はv2.1.290以降
  • 戻ってきたときに「Compacted while idle, before the prompt cache expired」が出ていないか見る
  • /usage の「Prompt cache (main)」の行で、キャッシュの状態と、圧縮などによる再構築（expected rebuild）の回数を確認できる
  • usage creditsで追加課金に入るとメインの会話は5分TTLに切り替わるため、ドキュメントの条件から読む限り、その状態ではアイドル圧縮は働かない

放置後の再開1発目で枠を溶かさない

使用量リミットで止まったセッションの自動継続と、再開時のキャッシュミスの罠を整理した。長時間の放置運用をする人向け。

記事を読む

関連記事

免責事項

  • 本記事の情報は2026年10月21日時点のものです。Claude Codeは頻繁に更新されるため、最新の仕様は公式チェンジログとプロンプトキャッシュのドキュメントを参照してください。
  • バージョンの公開日はnpmレジストリの公開日時（UTC）に基づきます。日本時間では日付がずれる場合があります。
  • v2.1.286頃からの挙動、trigger: "manual" の記録、発動下限の最小値10万トークンは、GitHub上のユーザー報告・解析に基づく情報であり、Anthropicの公式ドキュメントには記載されていません。
  • 節約効果の試算は公開されている料金倍率からの概算で、筆者による実測値ではありません。サブスクリプションの利用枠の換算方法は公開されていません。
  • GitHub、Zennからの引用は各投稿者の環境における報告で、筆者が再現検証したものではありません。英語の引用は筆者による翻訳で、意訳を含みます。
  • 設定変更は公式ドキュメントと自身の環境を確認したうえで行ってください。本記事の情報に基づく設定変更で生じた損害について、筆者は責任を負いません。
  • 本記事はAnthropic社およびその関連会社と提携・提供関係にあるものではなく、内容は筆者独自の見解です。本記事にアフィリエイトリンクは含まれません。

※ 記載の会社名・製品名は各社の商標または登録商標です。

Share