Claude Code idleCompactionとは|止め方
「長い会話を開いたまま昼休みに出て、戻ってきて1通送ったら、やけに待たされた」「Claude Codeの更新履歴に idleCompaction という設定が出てきたが、勝手に要約されるのは困るかもしれない」——Claude Codeで長い作業をしている人ほど、この2つの間で迷います。
結論から言うと、idleCompaction(アイドル時の圧縮)は、放置された長い会話を、1時間のプロンプトキャッシュが切れる直前に先回りして要約しておく機能です。2026年10月14日公開のClaude Code 2.1.299で更新履歴に載りました。ただし動く条件は5つあり、特に既定の下限「20万トークン」は、20万トークンの文脈窓で使っている会話には実質届きません。止めたいときは settings.json に "idleCompaction": false と1行書くだけです。
株式会社Fyveは、Claude Codeを毎日の業務と無人の自動処理の両方で回しています。この記事では、公式の更新履歴・設定リファレンス・配布されている本体の中身を照らし合わせたうえで、「自分の環境で動くのか」「止めるべきか」を判断できるところまで整理します。最後に、私たちの直近30日の会話記録で、この機能の条件に当てはまる場面が何回あったかも数えました。
idleCompactionとは|キャッシュが切れる前に、先に要約しておく機能
まず公式の更新履歴の原文です。2.1.299の項に次の2行があります。
Added idle compaction in the terminal: a 200K+ token conversation left idle for about 54 minutes is compacted before its one-hour prompt cache expires, so your next message doesn't reprocess it all
Added
CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENSto change idle compaction's 200K-token minimum;"idleCompaction": falsein settings.json turns it off. Both need v2.1.290 or later
日本語にすると「ターミナルで、20万トークン以上の会話を約54分放置すると、1時間のプロンプトキャッシュが切れる前に圧縮する。次のメッセージで会話全体を処理し直さずに済む」という内容です。npmへの公開時刻は2.1.299が2026年10月14日 00:23(UTC)、続く2.1.300が同日14:27(UTC)でした。
ここでいう「圧縮(compaction)」は、これまでの会話を要約に置き換える処理です。手で打つ /compact や、文脈が上限に近づいたときに自動で走る自動圧縮と同じ仕組みで、idleCompactionはそれを「席を外している間」に、キャッシュの寿命に合わせて走らせる点が新しいところです。
戻ってきたとき、会話には次の表示が出ます(設定リファレンスに記載の文言)。
Compacted while idle, before the prompt cache expiredこの表示が出ていれば、留守の間に要約が済んでいます。次に送る1通は、会話全体ではなく要約を前提に処理されます。
なぜ「54分」なのか|キャッシュが切れた後の1通目が重い理由
この機能の意味は、プロンプトキャッシュの寿命を知るとはっきりします。
Claude Codeは、送信のたびに会話全体をAPIに送っています。毎回すべてを読み直すと重いので、前回と同じ先頭部分はキャッシュ(一時保存)から読む仕組みになっています。公式ドキュメント(コストのページ)によると、このキャッシュの寿命は次のとおりです。
使い方 | メインの会話のキャッシュ寿命(既定) |
|---|---|
Claudeのサブスクリプション(プランの範囲内) | 1時間 |
サブスクリプションで使用量クレジット(追加課金)に入った後 | 5分 |
APIキー・クラウド事業者経由 | 5分(設定で1時間に変更可) |
寿命より長く席を外すと、キャッシュは消えます。公式ドキュメントは、その後の最初の1通について「キャッシュに当たらず、文脈全体を処理し直す」と説明しています。会話が20万トークンを超えていれば、その20万トークン超を一から読み直すことになります。
では、戻ってきてから /compact すればよいかというと、そうでもありません。プロンプトキャッシュのページには、要約そのものの費用について次の説明があります。
- キャッシュが生きているうちの
/compactは、会話をキャッシュから読むので、文脈の大きさから想像するよりずっと軽い - キャッシュが切れた後の
/compactは、会話全体をキャッシュなしで処理し直す。だから古いセッションを再開したときの要約が一番高くつく
つまり、要約するならキャッシュが生きているうちにやるのが安い。そこで「寿命の手前で自動的にやっておく」のがidleCompactionです。54分という数字は、1時間の寿命に対して少し手前で動かすための値です。私たちが配布されている本体(2.1.299)の中身を確認した範囲では、キャッシュの残り時間の9割の時点で動く作りになっており、60分の9割がちょうど54分です。
なお、キャッシュが効かない原因そのもの(1文字違い・階層・短すぎる先頭など)は別の記事で詳しく書いています。

動く条件は5つ|1つでも欠けると動かない
設定リファレンスの idleCompaction の項は、「次の条件をすべて満たす会話で、既定でオン」と書いています。5つを並べると次のとおりです。
条件 | 公式の記述 | 外れる典型例 |
|---|---|---|
① セッションの種類 | 対話型のターミナルセッション |
|
② キャッシュの寿命 | 1時間のプロンプトキャッシュ | APIキーで使っている、使用量クレジットに入った |
③ 機能フラグの取得 | Anthropicから機能フラグを取得できる | テレメトリを切っている、Bedrockなど他社クラウド経由 |
④ 会話の大きさ | 文脈が下限(既定20万トークン)に達している | 20万トークンの文脈窓で使っている会話 |
⑤ 放置の時間 | 最後のリクエストから約54分経ち、その時点でPCが起きている | ノートPCを閉じてスリープさせた |
ここから、読み飛ばすと「入れたのに動かない」「止めたつもりなのに動いた」になりやすい点を4つ取り上げます。

落とし穴1:既定の20万トークンは、20万トークンの文脈窓では届かない
一番見落としやすいのがここです。設定リファレンスは下限の変え方の説明で、次のように書いています。
At the default, a conversation on a 200K context window auto-compacts before it reaches 200,000 tokens.
文脈窓(一度に扱える会話の上限)が20万トークンのモデルで使っていると、会話は20万トークンに達する前に通常の自動圧縮で要約されます。だから既定の下限「20万トークン以上」には、そもそも到達しません。既定のままだと、idleCompactionが実際に動くのは100万トークンの文脈窓で長い会話をしている人が中心ということです。
20万トークンの文脈窓の会話も対象にしたいなら、公式の例どおり下限を15万トークンに下げます(設定方法は後述)。
落とし穴2:テレメトリを切っていると動かない
③の「機能フラグを取得できる」は地味ですが効きます。環境変数のページには、機能フラグの取得を止める設定として DISABLE_TELEMETRY・DO_NOT_TRACK・CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC・DISABLE_GROWTHBOOK が挙がっており、取得を止めたときに使えなくなる機能の一覧に「ターミナルのセッションが放置されている間に長い会話を圧縮する」がはっきり入っています。Amazon Bedrockなど他社クラウド経由のセッションや、Claude apps gatewayのセッションも、取得が止まる側に含まれます。
会社の方針でテレメトリを切っている環境では、設定を何も触らなくてもidleCompactionは動きません。逆に言えば、そういう環境では「止める設定」を急いで入れる必要もありません。
もう1点、同じページに「機能を追加した版へ更新した直後の最初のセッションでは、フラグで切り替わる機能が欠けることがある」とあります。更新した直後に試して動かなくても、次のセッションでは動くことがあります。
落とし穴3:「true」と書いても、オンにはならない
設定値の説明は、配布されている本体(2.1.299)に同梱の設定の説明文が一番はっきりしています。
Set to false to stop Claude Code from compacting a long conversation while the session is idle. Setting it to true does not turn idle compaction on.
「falseで止まる。trueにしてもオンにはならない」。つまり idleCompaction は止めるためだけのスイッチです。上の5条件を満たしていない会話を、trueで無理に対象へ入れることはできません。設定リファレンスの「既定 true」も、「止めていない状態」と読むのが正確です。
落とし穴4:使用量クレジットに入ると対象から外れる
サブスクリプションでも、プランの上限を超えて使用量クレジット(追加課金)に入ると、Claude Codeはメインの会話のキャッシュ寿命を5分に落とします(公式のプロンプトキャッシュのページ)。5分のキャッシュは②の条件を満たさないので、idleCompactionは動きません。月末に上限まで使い込んでいる人は、ちょうどその時期にこの機能が効かなくなる、という関係です。
自分の環境で動くかを確かめる3つの手順
手順1:版を確かめる
claude --version更新履歴に機能として載ったのは2.1.299です。一方で、公式は設定キーと環境変数について「v2.1.290以降が必要」と書いています。私たちの手元にある2.1.296の本体にも、戻ったときに出る「Compacted while idle, before the prompt cache expired」の文言がすでに入っていました。仕組み自体は更新履歴に載る前の版から入っていて、サーバー側の機能フラグで切り替えている作りと読めます。
npmの配布情報を見ると、2026年10月15日時点で最新版(latest)は2.1.300、安定版(stable)は2.1.292です。安定版を選んでいる人も、設定キーが効く版には届いています。
版の追い方で迷う人は、更新履歴を「新機能」ではなく「修正」の欄から読む方法を別の記事にまとめています。
手順2:キャッシュの寿命が1時間かを確かめる
対話中のセッションなら、/usage を開きます。Session欄の Prompt cache (main) の行に、いまキャッシュが温かいか冷えているかと、効いている寿命が出ます。公式ドキュメントの表示例はこうです。
Prompt cache (main): 14 requests · 91% of input tokens from cache · 2 misses (last 6m 10s ago, 310.2k tokens re-cached) · 1 expected rebuild (compaction or tool-result clearing) · warm (1h TTL, last activity 40s ago)末尾が warm (1h TTL, …) なら②を満たしています。5m TTL と出ていれば、この機能の対象外です。
コマンド1つで確かめたいときは、公式が案内している次の方法もあります。
claude -p "hello" --output-format json結果の usage.cache_creation に ephemeral_1h_input_tokens が出ていれば1時間、ephemeral_5m_input_tokens なら5分です。-p 自体は①の条件から外れますが、同じ契約・同じ設定でのキャッシュの寿命を見るには使えます。
手順3:会話の大きさを確かめる
④の「20万トークン」に届いているかは、同じく /usage や、スピナーの横に出るトークン数の表示で見当がつきます。100万トークンの文脈窓で使っていて、長い調査を1本の会話で続けている人は、届いていることが多いはずです。
2.1.299では /usage に警告も増えました。更新履歴には「max effort・ワークフロー・常に読み込まれる文脈・大きなツール結果」についての警告を足したとあります。会話が膨らむ原因を探すときの手がかりになります。
設定方法|止める・下限を変える
止める(全部の会話)
settings.json に1行足します。設定リファレンスでは、どの設定ファイルに書いてもよい種類の設定です(ユーザー設定・プロジェクト設定など)。
{
"idleCompaction": false
}このキーは2.1.290以降で効きます。それより古い版はキーを無視するので、古い版で止めたい場合は自動圧縮そのもの(autoCompactEnabled)をオフにする、と公式は案内しています。
止める(そのセッションだけ)
環境変数 DISABLE_AUTO_COMPACT=1 で起動すると、通常の自動圧縮と一緒にidleCompactionも止まります。手で打つ /compact は使えるままです。「この調査だけは要約を挟みたくない」というときの使い方です。
DISABLE_AUTO_COMPACT=1 claudeただし、通常の自動圧縮まで止まる点に注意してください。文脈が上限に近づいても自動では要約されないので、自分で /compact か /clear を打つ前提になります。
下限を変える
環境変数 CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS で下限を変えます。settings.json の env に書けば毎回効きます。公式の例は15万トークンです。
{
"env": {
"CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS": "150000"
}
}公式の説明では、正の整数だけを受け付け、それ以外の値は無視されます。10万より小さい値は10万に引き上げられ、10万トークンが一番低い下限です。「小さい会話も全部、放置したら要約してほしい」という使い方はできません。
逆に、下限を上げれば「本当に大きな会話だけ」に絞れます。たとえば100万トークンの文脈窓で、50万トークンを超えたときだけ動かしたいなら "500000" にします。

止めたほうがいい場面・残したほうがいい場面
idleCompactionは「要約する時期を、キャッシュに合わせて前倒しする」だけの機能です。要約で細部が落ちること自体は、通常の自動圧縮と変わりません。判断の軸は「戻ってきたとき、細部が要るか」と「そもそも戻ってくるか」の2つです。
残したほうがいい場面
- 会議や昼休みをはさんで、同じ作業の続きをする:戻った直後の1通が会話全体の読み直しにならない。この機能が想定している使い方そのものです
- 100万トークンの文脈窓で、長い会話を1本で続けている:放置後の読み直しが一番重い層です。既定の下限で対象に入ります
- どのみち途中で要約するつもりの会話:要約のタイミングが、自分で打つより安い時点に来るだけです
止めたほうがいい場面
- 細部が後で要る作業:長い調査の途中、エラーログやコマンドの出力を正確に参照しながら進めるデバッグなど。戻ったら要約になっていて、前に見た出力をもう一度取り直す、ということが起きえます
- 戻ってこない会話:放置したまま次の日に
/clearするつもりなら、留守の間の要約は使われずに終わります。要約は会話を読んで書く処理なので、キャッシュが温かくても1回ぶんのリクエストはかかります - 無人で回している自動処理:これは止める必要がそもそもありません。
claude -pやAgent SDKは①の条件から外れるので、設定に関係なく動きません
止めるなら、代わりに何を使うか
公式ドキュメントは、手動の操作の使い分けを次のように書いています。
/compact:作業の区切り(タスクとタスクの間など)で自分で打つ。自動圧縮が作業の途中で走るのを待つより、負荷のかかる時点を自分で選べる/rewind:捨てたい方向に進んでしまったときは、要約ではなく前の時点まで戻る。すでにキャッシュにある先頭部分まで巻き戻すので、新しく作り直す要約より軽い/clear:続きではなく新しく始めたいなら、こちらは費用がかからない
また、ProとMaxのプランでは、1時間以上放置した10万トークン超のセッションを再開すると、最初の1通の前に「要約から再開するか」を選ぶ画面が出ます(セッションのページ)。この場合はキャッシュが切れた後なので、どれを選んでも会話全体を1回は処理し直すことになります。idleCompactionは、その「1回」をキャッシュが切れる前に済ませておく機能、と位置づけると分かりやすいと思います。
自動圧縮が早く走りすぎていた過去の不具合と、その確かめ方は次の記事にまとめています。
私たちの環境では、条件に当てはまる場面が何回あったか
機能の説明だけでは「自分に関係あるか」が決まらないので、私たちが自動処理を回しているMacで、直近30日に更新されたClaude Codeの会話記録(2026年10月15日に集計)を数えました。各応答に記録されているトークン数と時刻から、「会話が20万トークン以上の状態で、54分以上次の応答が無かった」回数を拾っています。
項目 | 数 |
|---|---|
記録が残っているセッション | 423本 |
うち無人の自動処理( | 422本 |
うち対話型のターミナルセッション | 1本 |
キャッシュ書き込みの寿命 | すべて1時間(1時間の書き込みがあった応答 23,162件、5分は0件) |
会話が最大で20万トークン以上になったセッション | 42本 |
セッションごとの最大の大きさ(中央値) | 約8.7万トークン |
54分以上の空白 | 7回 |
うち空白の直前が20万トークン以上 | 6回(すべて対話型の1本の中・直前の大きさは約21万〜29万トークン) |
分かったことは3つです。
1つ目は、私たちの使い方では、無人の自動処理には関係が無いことです。会話が20万トークンを超えるセッションは42本ありましたが、自動処理は途中で1時間も止まりません。そもそも -p は対象外です。
2つ目は、関係があるのは対話型で長く開いておく会話だということです。対話型の1本では、20万トークンを超えた状態での空白が6回ありました。空白は短いもので約1時間20分、長いものは約67時間でした。1時間のキャッシュでは、6回とも戻ったときの1通目で20万トークン超の読み直しになっていた計算です。idleCompactionが今の形で動いていれば、この6回が対象になります(何日も空いたものも、要約が済んだ状態で戻る形になります)。
3つ目は、私たちの環境は⑤の「PCが起きている」を満たしやすいことです。自動処理用のMacはスリープさせずに動かしているので、54分の時点でPCが寝ていて動かない、ということは起きにくい。ノートPCで蓋を閉じて席を外す使い方とは、ここが違います。
この結果から、私たちは当面は既定のまま(止めない)で様子を見ます。止める設定を足すのは、細部を後で参照する長い調査を対話型でするときに、そのセッションだけ DISABLE_AUTO_COMPACT=1 で起動する、という範囲にとどめるつもりです。なお、戻った直後の1通目がどれだけ速くなったかの実測は、手元の版がまだ2.1.296でこの機能の挙動を確かめられていないため、この記事では書いていません。
同じ日に入った、関連する変更
2.1.299と2.1.300(どちらも10月14日公開)には、キャッシュや圧縮の周りで他にも変更があります。idleCompactionの効き方を見るときに役立つものを挙げます。
- OpenTelemetryでキャッシュ書き込みを寿命別に記録(2.1.300):
api_requestイベントにcache_creation_5m_tokensとcache_creation_1h_tokensが追加されました。社内で利用状況を集計している場合、1時間のキャッシュがどれだけ使われているかを分けて見られます /autocompactの警告の修正(2.1.300):自動圧縮の範囲を小さめに選んだとき、トークン使用量が多いという警告が出ていた不具合が直りました- フックが書き換えた入力の検査(2.1.300):PreToolUseとPermissionRequestのフックが返す
updatedInputが、Claude自身の入力と同じ基準で検査されるようになりました。知らないキーは捨てられ、ツールが受け付けない入力なら呼び出しが拒否されます。フックで入力を書き換えている人は動作を確認してください - エージェントフックの
model指定が効くように(2.1.300):これまで無視されていた指定が効くようになり、使えないモデルを指定したときは呼び出し元のモデルに戻ります(以前は動作を許可していた)
よくある質問
idleCompactionで料金や使用量は減りますか
公式が言っているのは「次のメッセージで会話全体を処理し直さずに済む」までです。キャッシュが切れた後に会話全体を読み直すより、切れる前に要約しておくほうが軽い、というのが公式ドキュメントの説明ですが、「必ず安くなる」とは書かれていません。戻ってこない会話では、要約の1回ぶんが余計になります。
要約されると、それまでの会話は消えますか
通常の自動圧縮と同じく、会話の履歴が要約に置き換わります。要約に何が残るかは公式の「圧縮で残るもの」の説明に従います。細部が必要な作業では、止めるか、そのセッションだけ DISABLE_AUTO_COMPACT=1 で起動してください。
VS Codeの拡張機能やデスクトップアプリでも動きますか
設定リファレンスの条件は「対話型のターミナルセッション」です。更新履歴も「in the terminal」と書いています。それ以外の画面での扱いは公式に明記がないため、この記事では断定しません。
settings.json に true と書けば、条件を満たさない会話でも動きますか
動きません。本体に同梱の説明文が「true にしてもオンにはならない」と明記しています。対象を広げたいなら、下限を下げる(最低10万トークン)のが唯一の調整手段です。
APIキーで使っていますが、対象にできますか
APIキーやクラウド事業者経由では、メインの会話のキャッシュ寿命が既定で5分です。公式ドキュメントは、APIキーで使う場合は promptCacheTtl を 1h にするとメインの会話が1時間のキャッシュになると案内しています。ただし1時間のキャッシュは書き込みの単価が高く、Bedrockなど他社クラウド経由では機能フラグの取得が止まる(③の条件)点にも注意が必要です。
54分の手前で戻ってきたら、どうなりますか
最後のリクエストから約54分経つ前に次の1通を送れば、その時点ではまだキャッシュが生きているので、要約は走りません。いつもどおり会話が続きます。
まとめ
- idleCompactionは、放置された長い会話を1時間のキャッシュが切れる直前(約54分)に要約しておく機能。更新履歴では2.1.299(2026年10月14日公開)に載った
- 動く条件は5つ:対話型のターミナル/1時間のキャッシュ/機能フラグを取得できる/会話が下限以上/約54分の放置とPCが起きていること
- 既定の下限20万トークンは、20万トークンの文脈窓の会話には届かない。対象にしたいなら
CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENSを15万などに下げる(最低10万) - 止めるのは
"idleCompaction": false。true にしても対象は広がらない。セッション単位ならDISABLE_AUTO_COMPACT=1 - 無人の自動処理(
-p)は対象外。私たちの直近30日でも、条件に当たったのは対話型の長い会話の6回だけだった
Claude Codeの設定は、版ごとに小さく変わり、そのたびに「自分の環境で動くか」の確認が要ります。株式会社Fyveでは、こうした確認を自社の運用の中で続けながら、Claude Codeを業務に入れる会社の環境づくりもお手伝いしています。
参考にした情報源
- Claude Code CHANGELOG(2.1.299・2.1.300)
- Claude Code Docs:Settings reference(idleCompaction)
- Claude Code Docs:Environment variables
- Claude Code Docs:Prompt caching
- Claude Code Docs:Manage costs effectively
- Claude Code Docs:Sessions
- npm:@anthropic-ai/claude-code(公開時刻・配布チャネル)
※2026年10月15日時点の情報です。設定名や既定値は版によって変わることがあるため、最新の公式ドキュメントで確認してください。
Claude Codeを「素のまま」使うな

設定で差がつく——CLAUDE.md・権限・スキルの実物を公開(全24ページ)
素のClaude Codeは"優秀な新入社員"。仕事を教えるほど、自分専用になります。覚えさせる4点セット——会社の説明書(CLAUDE.md)・権限の柵・手順書(スキル)・フォルダの地図——を、1人会社の実運用からコピペで使える型つきで公開します。
- そのまま書き換えて使えるCLAUDE.mdの型
- お金と送信をAIに触らせない「3段階の柵」
- 1回教えたら何度でも動く、手順書のコピペ雛形
- AIが迷子にならないフォルダ構造の3原則
メールアドレス登録で他にも様々な資料を閲覧できます








+8PDF 17点・合計440ページ + すぐ使えるzip素材 3点
どれも登録後の受け取りページから、まとめてダウンロードできます。
毎週配信の無料ニュースレター「AIネイティブ超研究」の購読特典です。メール登録後すぐ、受け取りページのご案内が届きます。そこにはこの資料に加えて、過去の特典もすべてまとめて置いてあります。あわせて、AI活用に関するお知らせやお役に立てそうなご案内をお送りすることがあります。解除はいつでも1クリック。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。