席を離れて戻ると会話に要約が差し込まれていた

v2.1.299 の更新履歴を読んでいた朝、「200K トークン超の会話を約54分放置すると、キャッシュが切れる前に圧縮される」という一行で手が止まりました。昼休みや打ち合わせのあと、同じセッションへ戻って続きを頼むことは、私自身の個人開発でも毎日のようにあるからです。

最初にお伝えしたいのは、これは不具合ではなく仕様だということです。ただし、戻ってきた直後の Claude が「さっき決めたはずの前提」を覚えていないように見えたら、まず疑うべきはモデルの調子ではなく、この圧縮かもしれません。

何が起きているのか

更新履歴(v2.1.299)には、ターミナルで 200K トークン以上の会話を約54分放置すると、1時間のプロンプトキャッシュが切れる前に圧縮される、と書かれています。次のメッセージで会話全体を再処理せずに済ませるための仕組みです。

つまり目的は、戻ったときの待ち時間とコストを抑えることにあります。代わりに、会話の細部は要約という形に置き換わります。

整理すると、次の三点がそろったときだけ起きます。

条件	内容
場所	ターミナルの会話
大きさ	200K トークン以上(既定の下限)
放置時間	約54分(1時間のキャッシュが切れる前)

短い会話や、こまめに話しかけているセッションでは起きません。長く育てた会話ほど対象になる、という点が厄介です。

起きたかどうかを見分ける

圧縮が走ると、戻ったときに通知が表示されます。v2.1.302 からは、この通知に「止め方」も添えられるようになりました。見落としたときは、次の兆候を確認します。

戻った直後の返答に、直前まで共有していた固有名詞・ファイル名・採用しなかった案が出てこない
会話の途中に、自分では書いていない要約らしき文章が見える
Claude Code の版が v2.1.290 より古い(この設定が使えない版です)

版と設定は、次のスクリプトでまとめて確かめられます。設定ファイルが複数の階層にあるので、一つずつ開く手間を省くための確認用です。

#!/bin/bash
# アイドル圧縮の設定を、ユーザー設定とプロジェクト設定の両方から拾う
echo "version: $(claude --version 2>/dev/null)"
for f in "$HOME/.claude/settings.json" ".claude/settings.json" ".claude/settings.local.json"; do
  [ -f "$f" ] || continue
  # idleCompaction が未設定なら "unset"(= 既定で有効)と表示する
  v=$(jq -r 'if has("idleCompaction") then .idleCompaction else "unset" end' "$f")
  m=$(jq -r '.env.CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS // "unset"' "$f")
  echo "$f -> idleCompaction=$v, min_tokens=$m"
done

unset と表示されたら、既定どおり有効です。「どの階層で効いているか」を一度見ておくと、あとで設定を足すときに迷いません。

原因の切り分けは三段で

「前提が抜けた」と感じたとき、私は次の順で確かめます。順番を決めておくと、慌てて設定を触らずに済みます。

まず、離席した時間を思い出します。約54分に届いていなければ、アイドル圧縮ではありません。通常のコンパクションか、そもそも指示の書き方の問題を疑います。

次に、会話の大きさです。200K トークンに届かない会話は対象外ですので、ここで原因から外せます。

最後に、上のスクリプトで設定を確かめます。idleCompaction が false なら、圧縮が走らない構成です。その場合は別の要因を探すことになります。

三つとも当てはまったときだけ、アイドル圧縮を第一候補にします。手順を踏まずに「圧縮のせいだ」と決めつけると、本来の原因を見逃してしまいます。

止めるか、残すか

止め方は二つあります。

settings.json に "idleCompaction": false を書く(v2.1.290 以降)
/config の「Idle compaction」行でオフにする(v2.1.302 以降)

反対に、閾値だけを引き上げる手もあります。CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS で 200K の下限を変えられます。

{
  "idleCompaction": true,
  "env": {
    "CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS": "400000"
  }
}

なぜ閾値の調整から入るのかというと、全部止めると、放置後の最初の一通でキャッシュ切れの再処理を丸ごと支払うことになるからです。長い会話ほど、その一通が重くなります。圧縮を止めるのは、要約で失われる細部のほうが高くつく作業だけに絞る、というのが私の線引きです。

本当の対策は、消されて困る前提を会話の外へ出すこと

設定をいじる前に、もう一つ疑ってみていただきたい点があります。要約に消されて困る情報が、会話の中にしか存在していないのではないか、ということです。

私は、次の三種類だけは必ず会話の外へ出すようにしています。

採用しなかった案と、その理由(戻ってきたときに同じ案を再提案されないため)
触ってはいけないファイル・ディレクトリ
作業の現在地(どこまで終わり、次は何か)

これを CLAUDE.md の末尾に作業メモとして置きます。恒久ルールとは分け、日付の入った小さな節にしておくと、片付けるときに迷いません。

## 作業メモ(2026-10-20・終わったら削除)
- 採用しない: ビルドごとの全ファイル再生成(理由: 差分だけで足りる)
- 触らない: scripts/legacy/ 配下
- 現在地: ログ出力の整形まで完了。次は失敗時のリトライ上限

離席前に「いまの作業メモを CLAUDE.md の末尾に書き出して」と頼むのが、いちばん手間のかからない方法です。CLAUDE.md の置き場所や粒度については、CLAUDE.md の設計で整理しています。

キャッシュとの関係を押さえておく

アイドル圧縮は、プロンプトキャッシュの寿命(1時間)に寄せた機能です。キャッシュの扱いを細かく設計したい方は、プロンプトキャッシュの TTL とディレクトリ単位の判断も合わせてご覧ください。v2.1.300 では OpenTelemetry の api_request に cache_creation_5m_tokens と cache_creation_1h_tokens が加わり、キャッシュ書き込みを寿命別に集計できるようになっています。

私はまだ、自分の作業で「止めたほうが得だった」と言い切れるだけの記録を持っておりません。ですので、設定を変えるなら変える前後で同じ作業を数日続け、戻った直後の一通の待ち時間と、抜け落ちた前提の数を手元に書き留めておくことをお勧めします。

まとめにかえて

消されて困る前提は、会話ではなくファイルに置く。 この一文だけは、圧縮を止める日も止めない日も守るようにしています。

まずは今日、離席する前に作業メモを一つだけ CLAUDE.md に書き出してみていただければと思います。

席を離れて戻ると会話に要約が差し込まれていた — アイドル圧縮の見分け方と、消したくない細部の残し方