Claude Codeのアイドル時コンパクションはキャッシュを維持するが、再開は要約から始まる

Claude Codeのアイドル時コンパクションでは、コンテキストウィンドウが埋まっていなくても、プロンプトキャッシュの有効期限が切れる前に大規模なセッションを要約できるようになった。この機能は、デフォルトで少なくとも20万トークンを含むセッションを対象とする。主なトレードオフは明確だ。Claudeはより安価で短いコンテキストに戻れる一方、元のすべてのターンではなく、生成された要約から作業を続行する。

Anthropicのエンジニア、Lydia Hallieは、2026年10月のidle compactionに関する投稿でこの挙動を説明した。ユーザーはClaude Codeの設定ファイルに"idleCompaction": falseを追加することで、この機能を無効にできる。また、CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENSによって最小コンテキストしきい値を変更することも可能だ。

この制御機能は、開発者が長時間実行セッションで予期しないコンパクションを報告した後に導入された。懸念されていたのはコンパクションそのものの存在ではない。Claude Codeはすでに、コンテキスト上限に近づいた会話を要約していた。争点は、キャッシュの有効期限切れ後に戻るコストを下げるため、アイドルタイマーがまだ利用可能なトランスクリプトを置き換えるべきかどうかだった。

Claude Codeのアイドル時コンパクションが変える「再開」の意味

再開されたセッションは同一性を保てる一方で、それを最初に成立させた逐語的な履歴を失う可能性がある。

Claude Codeはセッションメッセージをローカルに保存し、--continueまたは--resumeで再び開くことをサポートしている。この永続性により、セッションは持続的なワークスペースのように感じられることがある。しかし、モデルが推論できるのは現在のリクエストに送られたコンテキストであり、ディスクに保存されたすべての成果物ではない。

Anthropicのコンテキストウィンドウガイドによると、アクティブなコンテキストには、会話履歴、ファイル内容、コマンド出力、プロジェクト指示、メモリ、スキル、システム指示が含まれる。これらの情報が蓄積すると、Claude Codeは古いツール出力を削除し、最終的には会話を要約する。

コンパクションとは、古い会話素材を短い要約に置き換える行為である。セッション自体は利用可能なままで、Claudeは作業を続行できる。ただし、置き換えられた各ターンは、もはやモデルに一語一句そのまま渡されない。

新しいアイドル経路は、この置き換えが起こり得るタイミングを変える。従来の自動コンパクションは、コンテキスト予算の縮小に対応する。対してアイドル時コンパクションは、セッションが十分に大きい場合に、非アクティブ状態とプロンプトキャッシュのタイミングに応じて実行される。

ユーザーは、セッションを放置した後に「Compacted while idle, before the prompt cache expired」というメッセージが表示されたと報告し始めた。報告では、この展開はClaude Code 2.1.286と関連付けられているが、この挙動は一部でサーバーサイドのゲートによって制御されていた。つまり、特定のクライアントバージョンをインストールしただけでは、展開状況の全体が必ずしも明らかになるわけではなかった。

Hallieが報告し、Anthropicの公開リポジトリでも議論されたデフォルトの最小値は20万トークンである。この数値は適用対象となるためのしきい値であり、会話がちょうど20万トークンに達した時点でコンパクションが実行されるという保証ではない。

対象となるセッションには、該当するキャッシュ条件と十分なアイドル時間も必要だ。idle compaction issueでのコミュニティ調査では、タイマーが1時間のプロンプトキャッシュ期間の終わりに近づくことが確認された。ユーザーは、最後の操作からおよそ54〜56分後に可視のイベントを観測した。

これらの時間に関する詳細は、問題参加者がクライアントの挙動を調べ、ローカルテストを実行した結果に基づく。Anthropicの公開Claude Codeドキュメントは当初、アイドル時コンパクションの完全な仕様を示していなかった。したがって読者は、Anthropicによるコンパクションの説明、エンジニアの発表、実装詳細に関するコミュニティ分析という、3つの証拠レベルを区別すべきである。

それらの情報源を通じて確認できる製品上の帰結は明確だ。アイドル時コンパクションの後、Claudeは圧縮された会話状態から再開する。元のトランスクリプトはローカルに残っている場合があるものの、その完全な内容がモデルの作業コンテキストに自動的に含まれることはなくなる。

この区別は重要である。ローカル永続化とモデルの注意機構は、異なる問題を解決するためだ。保存されたトランスクリプトは監査と復旧を支援する。一方、アクティブコンテキストは、Claudeが次の応答で検討できる内容を決定する。

この機能はコンテキストの忠実性とキャッシュ効率を引き換えにする

アイドル時コンパクションは、繰り返されるコンテキスト処理を減らすために要約による情報損失を受け入れ、処理を冷えた復帰時から最後のウォームキャッシュ期間へ移す。

プロンプトキャッシュにより、繰り返し行われるリクエストは一致する入力プレフィックスを再利用できる。キャッシュヒットでは一般に、キャッシュエントリの期限切れ後に同じ大規模プレフィックスを再構築するよりも入力処理が少なくて済む。長いClaude Codeセッションでは、各ターンに過去のメッセージ、ツール操作、プロジェクト情報が含まれ得るため、再利用可能なプレフィックスが特に大きくなる。

Anthropicのプロンプトキャッシュに関するドキュメントでは、キャッシュの有効期間と、キャッシュ書き込みおよび読み取りに対する異なる扱いが説明されている。長いセッションがキャッシュ切れになると、ユーザーが戻った際にClaude Codeが大きなプレフィックスを再び処理する必要が生じる可能性がある。

アイドル時コンパクションは、その前に介入しようとするものだ。大きなプレフィックスがキャッシュに残っている間に、Claude Codeはモデルへその内容の要約を依頼できる。その後のリクエストは、短い要約と、Claude Codeが復元する指示またはプロジェクト情報から始まる。

この仕組みは、ユーザーが休憩後に大規模なセッションを再開するつもりでいる場合、効率性を優先する。古いコンテキスト全体で復帰する代わりに、ユーザーは処理するトークン数が少ない圧縮表現で戻ることになる。

その代償は情報の忠実性である。要約は選ばれた事実や決定を維持するが、すべての制約、却下された選択肢、テスト観測、会話上の修正を正確に保持することは保証しない。

Anthropicはコンテキストに関するドキュメントで、この一般的な限界を認めている。そこでは、リクエストと重要なコードスニペットはコンパクション中に保持される一方、以前の会話における詳細な指示は失われる可能性があるとされている。

この警告は、エージェント型コーディングセッションではより重大になる。微妙な指示が、許可される移行パスを規定している場合がある。却下された仮説は、Claudeが高コストな調査を繰り返すことを防ぐかもしれない。小さなテスト上の異常が、一見明白な修正が安全でない理由を説明することもある。

こうした詳細は要約器にとって二次的に見えても、次のコーディング手順を決定づける場合がある。要約はプロジェクトの大まかな目的を正確に説明できても、実装を制約した証拠を省くことがある。

リスクは、長く探索的なセッションほど大きくなる。開発者はClaudeに複数のモジュールを調査させ、競合する設計を比較させ、テストを実行し、2つのアプローチを放棄するよう依頼するかもしれない。最終的な方針は、コマンド出力や短い訂正に散在する否定的な結果に依存する可能性がある。

コンパクション後、Claudeはあるアプローチが選ばれたことを覚えていても、代替案が失敗したすべての理由を保持していないことがある。その結果、実際の調査とは異なるもっともらしい説明を再構築する可能性がある。

これは、コンパクションが本質的に欠陥のあるものだという意味ではない。有限のコンテキスト管理システムでは、無制限の履歴を逐語的に保持できない。争点はタイミングとユーザーの意図だ。

厳格なコンテキスト上限に近づいたとき、要約はセッションが停止するのを防ぐ。キャッシュの有効期限前であれば、セッションにまだかなりのコンテキスト容量が残っている可能性があるにもかかわらず、製品は効率を選択している。

これが本稿における主要な対立軸である。キャッシュ効率とコンテキストの忠実性の対立であり、Claude Codeと別のコーディングアシスタントの対立ではない。長時間稼働するエージェントはいずれも有限のコンテキストを管理しなければならないが、アイドルトリガーによってAnthropicの選んだ均衡は特に目に見えるものとなる。

開発者が自動要約に異議を唱えた理由

反発の中心は、コンテキスト圧縮そのものの存在ではなく、告知されない状態変化にあった。

開発者が手動で/compactを実行する際には、Claudeがそれまでの会話を要約することを認識している。このコマンドには、APIに関する決定や未解決のテスト失敗を保持するといった焦点を指定できる。その瞬間は自然なレビュー境界となる。

アイドル時コンパクションは、この即時の選択を取り除く。ユーザーは昼食を取りに行ったり、会議に出席したり、外部からのフィードバックを待ったりした後、アクティブな履歴が変化したセッションに戻る可能性がある。

最初のGitHubレポートでは、複数の作業セッションがアイドル状態でコンパクションされたと説明された。報告者は、要約から正確な指示、意思決定の根拠、以前に合意した方法が抜け落ちていたと述べた。他のユーザーも、設定したコンテキストしきい値に近づいていないにもかかわらず、同じ通知を見たと報告している。

これらはユーザーからの報告であり、要約の正確性を統制された形で測定したものではない。それでも、Anthropicのドキュメント自体がコンパクション中に初期の詳細が失われる可能性をすでに示しているため、信頼できる製品上のリスクを指摘している。

初期実装では、監視も複雑になった。問題内に記録されたテストによれば、初期のアイドル時コンパクションは、ユーザーが/compactを入力していないにもかかわらず、フックメタデータ内でmanualとして表示されていたようだ。

Claude Codeのフックでは、チームは定義済みイベントの前後に自動化を実行できる。誤解を招くトリガーラベルでは、意図的なユーザー操作とタイマー駆動の遷移を区別しにくくなる。

リポジトリ内のAnthropicコラボレーターによれば、Claude Code 2.1.290ではこのトリガーがautoに変更された。これにより、アイドル時コンパクションは明示的に実行された/compactと区別されるが、通常のしきい値ベース自動コンパクションとは完全に区別されない。

この曖昧さは、フックを用いて作業状態を保持するチームにとって重要だ。フックは、緊急のコンテキスト上限コンパクションの前と、キャッシュ駆動のアイドル時コンパクションの前で、異なるポリシーを適用したい場合がある。

問題の議論では、個別のidleトリガーが求められた。報告された2.1.290の挙動では、アイドルイベントとコンテキストしきい値イベントの両方がautoとして表示される可能性があった。ターミナル通知では人間向けにアイドルイベントが識別されたが、その通知が必ずしもフック入力に含まれていたわけではない。

より広範な製品上の教訓は、見えない最適化に関するものだ。開発者は通常、レイテンシやリソース使用量を変えても意味論を変えない最適化を受け入れる。要約は、次のモデルリクエストに異なる証拠が渡されるため、意味論を変え得る。

このためアイドル時コンパクションは、バックグラウンドのクリーンアップタスクというより、自動的な状態移行に近い。セッション識別子は安定したままだが、推論の基盤が変化する。

重大な移行、インシデント対応、または長期にわたるコードレビューを実施するチームには、この遷移を慎重に扱う理由がある。そうしたセッションには、個別には小さくても集合的には重要な制約が蓄積されることが多い。

短いセッションは最小しきい値を下回るため、影響を受けにくい。重要な状態をチャットトランスクリプト外に保持する、明示的な引き継ぎを中心としたワークフローもコストを抑える。

したがって、最も大きな負担を負うのは、1つの長いClaude Codeセッションを持続的なプロジェクトパートナーとして扱う開発者である。彼らは継続性から最も大きな利益を得るが、その継続性が意図的な境界なしに要約依存となったとき、最も多くを失うことにもなる。

idleCompaction設定は2つの異なる保護策を分ける

ユーザーは、コンテキスト上限に近いセッションを保護する自動コンパクションを無効にせず、アイドル時コンパクションだけを無効にできる。

公開された問題で回答したAnthropicコラボレーターによれば、Claude Code 2.1.290では専用設定が導入された。後にユーザーは、このオプションがバージョン2.1.291で機能したことを確認した。

基本的な設定は次のとおりです。

Claude Code は、ユーザー、プロジェクト、ローカルプロジェクト、管理ポリシーなど、複数のスコープで設定をサポートしています。Anthropic の settings reference では、それぞれの保存場所と優先順位が説明されています。

ユーザー全体に適用する設定は、個人用設定ファイルに記述できます。リポジトリのチームは、全員で同じ挙動を共有すべき場合、プロジェクト設定をバージョン管理下に置けます。ローカルプロジェクト設定では、リポジトリの共有設定を変更せずに挙動を上書きできます。

重要な違いは、idleCompaction と autoCompactEnabled の間にあります。前者は新しいタイマーベースの経路を対象とし、後者はより広範な自動コンパクションの挙動を制御します。

"idleCompaction": false に設定して無効化しても、バージョン 2.1.290 で説明された挙動に基づく、通常のしきい値到達時のコンパクションは維持されます。これは、コンテキストウィンドウ上限付近での保護は必要としつつ、休止中のキャッシュ駆動型要約は避けたい開発者に有用です。

この分離は、最も強いユーザー要望に直接応えるものです。専用スイッチが登場する以前は、より広範に自動コンパクションを無効化すると、セッションがコンテキスト上限に達するのを防ぐ保護機構まで失われる可能性がありました。

このキーが機能すると判断する前に、ユーザーはインストール済みのバージョンを確認すべきです。実行するコマンドは次のとおりです。

公開 Issue ではこの設定は 2.1.290 に含まれるとされており、あるユーザーは 2.1.291 で明示的に動作を確認しています。管理対象のインストール環境では、組織が管理するスケジュールで更新を受け取る場合もあります。

この機能にはサーバー側のゲートもあるため、注意が必要です。idleCompaction を true に設定しても、Anthropic がすべてのアカウントや環境でこの機能を有効化するとは限りません。他の適格性条件を満たす場合に、クライアント側の挙動を許可する設定です。

オプトアウトが必要なユーザーにとって重要な制御は、これを false に設定することです。チームはそれでも、自身のインストール環境、アカウント種別、ポリシー階層の下で挙動をテストする必要があります。

管理設定は、ユーザーの選択より優先される場合があります。中央集権的な設定を持つ組織には適していますが、ローカルファイルを一つ編集しただけでは期待どおりの結果にならない可能性があります。

最も安全な検証方法は、実際の挙動を確認することです。クライアントのバージョンを確認し、有効な設定を調べ、重要な作業でこのオプションに依存する前に、重要度の低いセッションでテストしてください。

ユーザーはまた、永続的な指示を会話履歴の外部に保持すべきです。Anthropic は、Claude Code がプロジェクトコンテキストとして読み込む CLAUDE.md に永続的なルールを置くことを推奨しています。通常の上限付近でのコンパクションは引き続き発生し得るため、この助言はアイドルコンパクションが有効か無効かを問わず適用されます。

検索可能な engineering knowledge base も、人間のチームにとって関連する役割を果たせます。意思決定、制約、調査結果を、単一のエージェントセッションだけに依存しない、復元可能な成果物として残せます。

200K のしきい値は調整可能だが、コンテキスト上限ではない

`CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS` は、セッションがアイドルコンパクションの対象となるタイミングを変更するものであり、モデルのコンテキストウィンドウの大きさを変更するものではありません。

Hallie 氏によると、最小値のデフォルトは 200,000 トークンです。ユーザーは Claude Code 設定の環境設定を通じて、別の整数値を指定できます。

例:

この例では、適格性のしきい値を 400,000 トークンに引き上げています。より大きなコンテキストウィンドウを与えるものでも、会話履歴用に 400,000 トークンを予約するものでも、その時点で直ちにコンパクションが実行されることを保証するものでもありません。

公開 Issue の分析では、下限は 100,000 トークンと報告されました。その下限未満の値は、100,000 に引き上げられると説明されています。議論が行われた時点では、Anthropic は公開 settings reference にこの環境変数を完全には文書化していなかったため、ユーザーは実装詳細がバージョンに依存するものとして扱うべきです。

しきい値を上げると、忠実性が優先されます。より多くの大規模セッションが要約されずにアイドル状態を維持できますが、キャッシュ有効期限後に戻る際には、より多くの入力処理が必要になる場合があります。

しきい値を下げると、キャッシュ効率が優先されます。より多くのセッションが有効期限前コンパクションの対象となり、ユーザーが完全な会話履歴ではなく要約に戻る可能性が高まります。

適切な値は、単純なモデル容量ではなく、ワークフローの形状に依存します。反復的なツール出力を含む長いセッションは、問題なく要約できるかもしれません。一方、より短いアーキテクチャ議論には、圧縮に適さない、密接に関連した高密度な意思決定が含まれる場合があります。

トークン数が測るのは大きさであり、意味的重要性ではありません。300,000 トークンのデバッグセッションには、不要なログ行が数千含まれる可能性があります。120,000 トークンのセキュリティレビューには、原文どおりに保持すべき多数の精密な脅威前提が含まれる可能性があります。

このため、設定可能な最小値は役に立つ一方で、根本的な緊張関係を解消するものではありません。チームはトレードオフが始まる地点を選べますが、数値しきい値は現在の会話を安全に要約できるかどうかを判断できません。

開発者は、セッションを離れる前に明示的なチェックポイントを作ることでリスクを減らせます。アクティブな目標、確認済みの調査結果、却下したアプローチ、変更したファイル、テスト状況、次に実行するコマンドを、リポジトリのノートに記録するよう Claude に依頼してください。

そのノートは、単にタスクを言い換えるものでは不十分です。会話全体を再構築せずに再開するために必要な証拠を記録すべきです。

永続的な制約は、CLAUDE.md または別の権威あるプロジェクトファイルに置くべきです。一時的な発見は、Issue、作業ログ、または引き継ぎ文書に置くべきです。そうすれば、生成された要約は唯一の記録になることなく、継続性を支援できます。

チームは /context を使い、アクティブなウィンドウを何が消費しているか確認することもできます。大容量のコマンド出力が支配的な場合、一般的な要約に重要事項の判断を委ねるよりも、その内容を消去または再構成する方が安全な場合があります。

手動の /compact は、自然な区切りで引き続き有用です。Anthropic によれば、ユーザーは焦点に関する指示を追加できるため、放置されたアイドルイベントよりも要約器に明確な保持目標を与えられます。

より大きな原則は単純です。可能な場合は、タスクの境界に合わせてコンパクションを選んでください。トークンしきい値は障害を防ぎますが、人間が定義する境界はエンジニアリング作業の構造をよりよく反映します。

Claude Code のコンパクションが保持するものと、保証できないもの

コンパクションが保持するのはセッションの作業用表現であり、推論履歴の完全な複製ではありません。

Anthropic の Claude Platform ドキュメントでは、コンパクションは古い会話ターンをモデルが作成した要約に置き換えるものと定義されています。compaction overview では、アプリケーションは、要約されたメッセージが以前あった場所に返却されたコンパクト化ブロックを置くことで継続すると説明されています。

Claude Code は、そのワークフローを製品内で処理します。Claude API を直接使用するアプリケーションとは正確な実装が異なりますが、概念上の結果は似ています。古い入力は生成テキストによって表現されます。

優れた要約は、ユーザーの依頼、現在の実装状態、重要なファイルパス、テスト結果、残作業を保持できます。また、後続ターンで送信する過去の情報量を大幅に削減できます。

ただし、すべてのやり取りを逐語的に保持することは保証できません。要約器は、より小さなトークン予算の中で情報を選び、整理し、表現する必要があります。

推論履歴には特有の課題があります。コーディングセッションには、しばしば除外の連鎖が含まれます。Claude は一つのファイルを調べ、仮説を立て、矛盾する出力を確認し、方向を変えます。

最終的な要約には、採用された説明が記録される一方、それを検証した経路は圧縮される場合があります。多くの場合それで十分ですが、次のモデルが結論を監査する能力は弱まります。

ツール出力も別の問題を生みます。ログ、コンパイラエラー、データベースプラン、テストトレースには、後になって初めて重要性が明らかになる細かな詳細が含まれることがあります。その後の発見より前に生成された要約には、どの行が重要になるかは分かりません。

ユーザーによる修正指示も重要度を失う可能性があります。「スキーマを変更しないでください」という指示が一度だけ現れ、その後に数百ターン続くことがあります。それが永続的な指示に昇格されなければ、コンパクションによって重要性が薄れたり、省略されたりする可能性があります。

Claude Code のドキュメントでは、存続すべきルールのために CLAUDE.md を明示的に推奨しています。また、「Compact Instructions」セクションもサポートしており、コンパクション中に保持すべき内容を要約器に指示できます。

こうした仕組みはリスクを減らしますが、要約を完全無欠にはしません。コンパクト指示は、選択を行うモデルに対するガイダンスにすぎません。プロジェクト指示ファイルは、Claude Code が権威あるコンテキストとして再度読み込めるため、より強力です。

したがって開発者は、セッション知識を三つの種類に分けるべきです。恒久的な運用ルールはプロジェクト指示に置きます。検証済みのエンジニアリング状態は、ファイルまたは追跡された作業記録に置きます。会話上の探索はトランスクリプト内に残し、いずれ生じる圧縮を受け入れて構いません。

このアプローチはコラボレーションも改善します。別のエンジニアは、プライベートなエージェント会話に含まれる文書化されていない細部を確実に引き継げません。簡潔な引き継ぎファイルは、人間とエージェントの双方に共有された復帰点を与えます。

実務上の問いは、要約が良いか悪いかではありません。ある特定の事実が、要約の中にだけ存在しても安全かどうかです。

詳細を失うことで危険な移行、繰り返されるインシデント、または無効な結果につながる場合は、セッションを離れる前に会話の外部へ記録してください。

アイドルコンパクションが信頼を得られるかを示す三つの兆候

次の検証点は、Anthropic がセッション継続性を予測不能にすることなく、効率化の利点を観測可能にできるかどうかです。

第一の兆候は公式ドキュメントです。ユーザーには、適格性、タイミング、サポート対象バージョン、しきい値の制限、設定の優先順位、プロンプトキャッシュポリシーとの相互作用について、安定した説明が必要です。

ドキュメントは、200,000 トークンというデフォルトがモデルやアカウントをまたいで一貫して適用されるかも明確にするでしょう。Anthropic が環境変数とその下限を文書化すれば、チームは Issue の発掘調査に頼らず設定できます。

その結果は、この機能への信頼を強めるでしょう。逆に、ソーシャル投稿やバイナリ調査への依存が続けば、明白な移行経路なしに文書化されていない制御が変更され得るため、信頼は弱まります。

第二の兆候は、明確に区別されたフックメタデータです。専用の idle トリガーがあれば、チームはタイマー駆動型コンパクションを、手動の /compact コマンドおよび上限付近での自動コンパクションの両方と異なるものとして扱えます。

組織はアイドルイベント前に状態をスナップショットし、用途に合わせたコンパクト指示を付加し、この機能がどの程度頻繁に作動するかに関するテレメトリーを記録できます。明確なイベント識別子は、インシデント調査も容易にします。

Anthropic が両方の自動経路を同じ auto ラベルの下に置き続ける場合、管理者はセッションがなぜ変化したのかを把握しにくくなります。それは、ターミナルでの体験と自動化インターフェースの間にある隔たりを残すことになります。

第三の兆候は、長いコーディングセッションにおける要約品質に関する証拠です。ユーザー報告では失われたニュアンスが指摘されていますが、公開議論では一般的な失敗率は確立されていません。

有用な評価では、要約が明示的な制約、却下された仮説、保留中のタスク、テスト失敗、ファイル参照、安全ルールを保持するかを測定します。また、一つの圧縮された状態が次の圧縮の入力になることでエラーが蓄積し得るため、繰り返しコンパクションもテストすべきです。

肯定的な結果は、Anthropic の効率性に関する主張を裏付けるでしょう。キャッシュ有効期限前の自動圧縮を正当化できるほど、ほとんどの適格セッションが十分な精度で再開できることを示すためです。

否定的な結果は、オプトインの挙動や、より高いデフォルトしきい値を求める根拠を強めるでしょう。また、古い情報を要約しながら直近のターンは逐語的に保持する、部分的なコンパクションへ Claude Code を向かわせる可能性もあります。

現時点で開発者には、実用的な選択肢があります。逐語的な継続性よりも再開時の負荷軽減を重視するなら、Claude Code のアイドル時コンパクションを有効にしておきます。非常に大規模なセッションでのみそのトレードオフが正当化される場合は、トークンしきい値を引き上げてください。

一時停止したセッションを既存のアクティブな履歴を保ったまま再開する必要がある場合は、"idleCompaction": false で無効にします。通常のコンテキスト上限によるコンパクションは、別の保護策として有効のままにしておけます。

どのポリシーを選ぶにしても、重要なエンジニアリング上の状態を長いチャットだけに記録しないでください。永続的な制約はプロジェクト指示に書き、検証済みの発見はファイルに残し、離席前に引き継ぎを作成しましょう。

Claude Code のアイドル時コンパクションは、コーディングエージェントに関する基本的な事実を明らかにします。セッションの継続性は、完全な記憶と同じではありません。次に長時間離席する前に、自分のワークフローが実際に必要とするものを決めてください。