Claude Codeで調査と実装を進めていると、午前中の会話を開いたまま昼休みに入り、午後もその続きを頼みたくなります。作業の流れは残したい。でも、古いログや途中の試行錯誤まで毎回抱える必要があるのかは気になるところです。
2026年10月15日時点で確認した公式変更履歴には、ターミナルのidle compactionが記載されています。長い会話を、操作していない時間に要約する仕組みです。見るべき点は「放置すれば安くなる」という期待より、会話を短くした後も、正しい前提で作業を再開できるかだと考えています。
この記事では公式に確認できた条件を先に示し、そのうえでSEの作業に取り入れる確認手順を提案します。筆者環境での消費量比較や節約率の実測は行っていません。後半の業務例とチェック表は、導入を検討するための例です。
idle compactionで確認できたこと
公式CHANGELOGの2.1.299欄では、ターミナルで200Kトークン以上の会話を約54分間アイドルにすると、1時間のプロンプトキャッシュが切れる前に会話を圧縮する、と説明されています。また、最小トークン数を変える環境変数CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENSと、無効化する"idleCompaction": falseが示され、これらにはv2.1.290以降が必要とされています。
ここでの200Kは20万トークンです。20万文字ではありません。約54分という記載も、どの環境でもストップウォッチどおりに動く保証として扱わないほうがよさそうです。まずは手元のバージョンと、ターミナルで使っているかを確認するところから始めます。確認元はAnthropic公式CHANGELOGです。
会話の要約とキャッシュは、何が違うのか
考え方をつかむには、打ち合わせの記録を想像すると分かりやすいです。毎回、録音の文字起こしを全部読み直すのか。前に読んだ部分を再利用するのか。それとも、決定事項を短い議事メモにまとめ直すのか。このうち、前に処理した入力の再利用に当たるのがプロンプトキャッシュ、会話を短くまとめるのがコンパクションです。
キャッシュは、会話から情報を選んで短くする作業とは異なります。Anthropicのプロンプトキャッシュの公式説明では、繰り返す入力を再利用する仕組みと、キャッシュの有効期間が説明されています。利用する経路や設定によって条件があるため、「Claude Codeなら必ず1時間」と一般化するのは避けたいところです。
一方、コンパクションは要約です。読者の仕事に置き換えるなら、長い障害調査の経緯を「原因候補、否定できた条件、残っている確認」にまとめるイメージです。短いメモで再開できれば便利ですが、途中で出た細かい注意点まで同じ密度で残るとは考えないほうが安全です。
idle compactionを評価するときは、この二つを分けます。入力の再利用ができたかだけでなく、要約後に必要な判断材料が残ったかまで見る。費用と品質を別々に確認できると、機能名に期待しすぎず判断できます。
昼休みを挟むAPI修正なら、何を残したいか
たとえば、社内の問い合わせ管理APIで日付フィルターを修正する場面を考えます。午前中に仕様書を読み、該当コードを探し、いくつかのテストを試した。その後、別の打ち合わせで1時間ほど席を離れる。これは説明用の仮想例ですが、長い会話を再開する難しさが出やすい流れです。
午後に「続けて」とだけ頼むと、どの状態から進めるのかが曖昧です。調査だけが終わったのか、ファイル変更まで済んだのか。落ちているテストは今回の変更によるものか、作業前からなのか。こうした区別が曖昧なまま進むと、要約が上手でも判断を誤る余地があります。
私なら、休憩前に次の四つを短い作業メモへ残す運用から試します。
- 目的：日付フィルターの境界条件を修正する。
- 確定事項：終了日の扱いは既存仕様を維持する。
- 現状：修正済みファイルと、実行済みテストの名前を記録する。
- 次の一手：日付が切り替わる境界のテスト結果を確認し、差分をレビューする。
これはClaude Codeの特別な設定ではなく、人間側の作業整理です。自動要約の内容を想像して補うより、原本となるコード、仕様、テスト結果を明示するほうが再開時に確かめやすくなります。会話は説明の履歴、リポジトリと検証結果は判断の根拠、と役割を決めておきます。
最初に見るのはバージョンと利用経路
使い始める前に、ターミナルで次のコマンドを実行し、表示されたバージョンを控えます。これはClaude Codeのバージョン確認です。モデル名や契約プランの確認とは別です。
claude --version同じ端末でも、通常のターミナルとIDE内のターミナルで起動している実体が違う可能性があります。比較をするなら、実際の仕事で使う起動場所を一つ決めて記録します。会社の端末では更新ルールに従い、比較の途中でアプリや設定を変えないようにします。
次に、契約内の利用なのか、APIキーなのか、別のクラウド経由なのかを区別します。記事にある時間条件だけを見て、すべての接続先で同じ動作になると判断しないためです。組織で設定が管理されている場合は、個人の設定ファイルだけで全体を説明しようとしないことも大切です。
いきなり環境変数やしきい値を調整すると、変化の理由を追いにくくなります。最初は現在の構成を記録し、その構成のまま再開時の挙動を観察する。調整が必要だと分かってから、一項目ずつ変更する流れを勧めます。
トークン消費を見るときに混同しやすい数字
Claude Codeの費用管理の公式ドキュメントでは、/usageに表示されるセッションのトークン情報、プロンプトキャッシュの情報、契約プランの利用状況が説明されています。セッションの費用表示は請求の確定額と同一視できず、サブスクリプション利用者とAPI利用者で読み方も変わります。
そのため、画面のドル表示が小さくなったことだけで「月額料金が下がる」とは書けません。逆に、再開の一回に消費があったことだけで、機能全体が無駄だとも決められません。比較の単位は、依頼してから同じ作業を終えるまでにします。
たとえば、短い依頼で再開できても、前提が落ちて修正をやり直したなら、その時間も含めて評価します。要約時点の消費、再開後の応答、やり直し、レビューの負担を一つの作業として見ると、「数字は改善したが仕事は遅くなった」という見落としを減らせます。
利用上限の残量、入力の量、キャッシュの状態、実際の請求は、同じ意味の指標ではありません。スクリーンショットを残す場合も、それぞれ何を表す数字なのかをメモしておくと、後から別の指標を並べて比較する失敗を防げます。
要約しても失いたくない情報を分けておく
Claude Codeの動作原理の公式説明は、会話を圧縮する過程で、初期の細かな指示が失われる可能性に触れています。継続して守るルールはCLAUDE.mdに置くという案内もあります。自動要約を使うなら、会話にしか存在しない重要事項を減らす考え方が役立ちます。
ただし、何でも永続ルールへ移せばよいわけではありません。今回の障害だけの仮説、まだ合意していない設計案、直後に消す予定の検討メモを、プロジェクト全体の規則に混ぜると、後の作業に誤った前提を持ち込みかねません。
| 情報 | 置き場所の提案 | 再開時の確認 |
|---|---|---|
| プロジェクト共通の開発ルール | レビューしたCLAUDE.mdなど | 今の作業にも適用するか |
| 今回の作業目的と未完了事項 | タスクごとの短いメモ | 目的が変わっていないか |
| 実装とテスト | リポジトリ内の原本 | 差分と結果が説明に合うか |
| 調査中の推測 | 仮説だと明示した検討メモ | 確定事項へ化けていないか |
この表は本記事の運用提案です。機能の必須設定を列挙したものではありません。小さな案件なら、タスクメモ一枚とGit差分で十分なこともあります。メモを保守する負担まで含め、自分の仕事に合う小ささから始めたいところです。
休憩後に送る依頼文は、短く具体的に
再開時には「全部覚えているよね」と確認するより、次に使う根拠を示したほうが話が進みます。先ほどのAPI修正なら、次のような依頼文を試せます。これは一般的な作業指示の例であり、専用コマンドではありません。
日付フィルター修正の続きを進めてください。まず現在のGit差分とタスクメモを確認し、修正済み箇所、未完了の確認、次に行うテストを短く示してください。今回の変更対象以外を直す必要が出たら、理由と範囲を先に説明してください。
狙いは、長い背景説明を最初から貼り直すことではありません。今の状態を読み直して、どこから再開するかを揃えることです。差分がないのに「実装済み」と説明していれば、そこで止めて確認できます。テストが未実行なら、成功したものとして扱わずに済みます。
認識がずれていた場合も、会話全体をやり直す前に、誤っている前提を一つずつ直します。「終了日を含むという条件は維持する」「この失敗は作業前から存在した」といった具体的な訂正のほうが、漠然とした再指示より確認しやすくなります。
小さな比較で、費用と仕事の進み方を確かめる
効果を確かめるなら、顧客データや本番操作を含まない検証用リポジトリから始めます。比較のためだけに20万トークンへ会話を膨らませると、測定したい節約より準備の消費が大きくなりかねません。普段の作業で条件を満たす場面が来たときに、記録を取る方法が現実的です。
記録したいのは、バージョン、利用経路、モデル、休憩前の作業状態、休憩時間、再開後の最初の依頼、完了までの追加作業です。可能なら同じ種類のタスクを複数回観察し、一度の結果だけで結論を出さないようにします。
- 休憩前：何を完了し、何を未完了にしたかを残す。
- 再開直後：要約などの表示と、利用状況の見方を記録する。
- 作業中：前提の誤り、再読込、指示のやり直しを数える。
- 完了時：同じ受け入れ条件を満たしたか、人間がレビューする。
ここで成果と呼べるのは、単なる短い返答ではなく、要求した修正が終わり、必要な確認が通った状態です。トークン量が減っても、見落としが増えたら運用は見直します。逆に大きな差が出なくても、再開の手間が減るなら、費用以外の価値があるかもしれません。その判断は実測後に分けて行います。
導入を急がなくてもよいケース
短い会話で小さな修正を終え、その都度作業を区切っている人は、まず今の進め方を維持してよいと思います。機能の条件に近づけるためにセッションを長くする必要はありません。目的は長い会話を育てることではなく、必要な仕事を確実に終えることです。
また、厳密な承認記録が必要な仕事では、会話の要約を承認の原本にしない運用を検討したいところです。設計の承認や公開の許可は、チームで決めた場所へ残し、再開後のAIの説明だけで「承認済み」と判断しない。これはidle compactionの不具合を示す話ではなく、記録と実行を取り違えないための実務上の提案です。
長い調査を同じ会話で続け、会議や休憩を何度も挟む人には、観察する価値があります。ただ、最初の改善は設定の調整よりも、休憩前に残す作業メモを整えることかもしれません。機能の動作が変わっても、そのメモは次の担当者への引き継ぎに使えます。
次の休憩で試すなら、この三つから
idle compactionは、長い会話をそのまま持ち続ける運用を見直すきっかけになります。とはいえ、要約機能だけに仕事の継続性を任せるより、現在の実装と作業メモで再開地点を確かめる習慣を組み合わせたいところです。
- 手元のClaude Codeのバージョンと利用経路を記録する。
- 休憩前に、目的・確定事項・現状・次の一手を短く残す。
- 再開後は差分と根拠を確認し、完了までの消費とやり直しを見る。
「どれだけ安くなるか」は、その後に測れます。まず確かめたいのは、席を離れた後も、正しい条件で仕事へ戻れるか。その土台があれば、新しい自動化も落ち着いて評価できます。
参考情報
確認日：2026年10月15日。変更履歴の掲載内容と、実際の配信状況・手元の動作は分けて確認してください。数値による節約効果は未検証です。
コメント