Claude Codeで長時間セッションのコストが増える理由
長時間開いたセッションは、体感の作業量以上にプラン上限を消費することがあります。原因はキャッシュ切れやバックグラウンド処理など複数あり、クラウドセッションのクレジット消費にも触れます。
長時間セッションで何が起きているか
数時間開きっぱなしのセッションは、実際に打った指示の量から想像するより多くのプラン上限を消費することがあります。公式ドキュメントはこの現象を「usage climbs in a long session」として整理し、原因を複数挙げています。共通するのは、Claude Codeがリクエストのたびに会話全体を送り直すという設計です。
Claude Codeは1回のツール呼び出しごとに新しいリクエストを送り、その中に会話履歴とツール結果をまとめて含めます。プロンプトキャッシュが効いているあいだはキャッシュ済みトークンの単価で再読み込みされますが、それでも「1日中開いていたセッションでの一言質問」は会話全体ぶんの利用量として計上されます。跳ねる経路は4つあり、効く対策はそれぞれ違います。
原因1: プロンプトキャッシュが切れて全文を再処理する
キャッシュされたプレフィックスは、一定時間操作がないと失効します。休憩後の最初のリクエストはキャッシュを外れ、コンテキスト全体を再計算してキャッシュを作り直すため、離席明けの最初のターンだけ体感が重くなります。
このキャッシュがどれだけ長く生き残るかはTTL(生存時間)が決め、Claude Codeはリクエストの種類ごとに2種類のTTLを使い分けます。2026年3月にはこのTTLが一時的に1時間から5分へ切り替わる回帰が起きました。詳しい経緯はClaude CodeのキャッシュTTL回帰を参照してください。
| リクエストの種類 | サブスクリプション(プラン利用枠内) | 使用量クレジット / APIキー / クラウド経由 |
|---|---|---|
メイン会話(対話ターン、-p実行) | サブスクリプション(プラン利用枠内)1時間 | 使用量クレジット / APIキー / クラウド経由5分 |
| それ以外(サブエージェント・workflow・チームメイト・fork・圧縮など) | サブスクリプション(プラン利用枠内)5分(一部サーバー側の補助リクエストのみ1時間) | 使用量クレジット / APIキー / クラウド経由5分 |
プラン利用枠を使い切って使用量クレジットに切り替わると、メイン会話のTTLも5分に落ちます。1時間のTTLを維持したいなら、自分で指定できます。promptCacheTtl設定かCLAUDE_CODE_PROMPT_CACHE_TTL環境変数(Claude Code v2.1.242以降)を使います。
原因2: 待機中でも動くバックグラウンド処理
セッションを開いたまま何も打たずにいても、いくつかの仕組みは会話全体を送るリクエストを裏で発生させます。
入力がなくてもターンが走る4つの経路
スケジュールタスク
設定した間隔で発火し、セッションがアイドルでもそのたびにコンテキスト全体を送信します。
クロスセッションメッセージ
別セッションからのメッセージが、待機中のセッションに新しいターンとして届きます。
crossSessionInboundをholdにすると配信を保留できます。goalのチェックイン
バックグラウンド作業を待つgoalが有効な間、進捗確認のターンが起きます。v2.1.246以降は、プロンプトを送るまでの間に1つのgoalあたり最大3回です(v2.1.236〜v2.1.245は無制限)。
CLAUDE_CODE_GOAL_CHECKIN_MINUTESを0にすると止まります。チームメイト
Agent Teamsの各チームメイトは、終了するまでトークンを消費し続けます。プランモードで動く構成は通常セッションの約7倍で、各自が専用のコンテキストウィンドウを持つ別インスタンスだからです。
待機時間そのものは無料ではありません。
サブエージェントも別枠の消費源です。サブエージェント・workflow・fork・圧縮リクエストは「メイン会話」ではなく「それ以外」のバケットに分類され、サブスクリプションでも既定は5分TTLです。長時間セッションで調査系のサブエージェントを何度も呼ぶ運用は、都度キャッシュを作り直しやすい構造になっています。この側のTTLはsubagentPromptCacheTtl設定かCLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL環境変数(v2.1.242以降)で指定できます。
原因3: セッション中の操作がキャッシュを都度壊す
長く開いたセッションほど、意図せずキャッシュを壊す操作を重ねやすくなります。次の操作は、条件がそろうとプレフィックスを変え、次のリクエストを未キャッシュの全文再処理にします。
- モデル切り替え(
/model): モデルごとにキャッシュが別なので、切り替えた直後の1リクエストは必ずキャッシュを外れます。opusplan設定はplanモードと実行モードを行き来するたびにこの切り替えが起きます - effortレベルの変更(
/effort): Opus 5.5・Sonnet 5.5・Fable 5.1をAPIキーかサブスクで使う場合は維持されますが、それ以外のモデルや構成では全損です。組み合わせの詳細はプロンプトキャッシュと利用上限の関係の表にあります - fast modeのオン: 会話で最初にオンにした1回だけ、リクエストヘッダーの変化でキャッシュが切れます。セッションの後半で初めて有効にするほど、そのぶん長い履歴が未キャッシュ扱いになります。オフや再オンでは維持されます。
/clearと/compactはこの状態をリセットするので、その後の最初のオンは再び1回数えられます。使っているモデルがfast modeに未対応なら、オンにした時点でモデルも切り替わります - MCPサーバーの追加・無効化: ツール定義がプレフィックスに乗っている場合(tool searchが使えない環境など)、サーバーを新たに接続したり
/mcpで無効化したりするとキャッシュが崩れます。接続が切れた後の自動再接続では、原則として維持されます - ツール全体のdeny設定変更:
Bashのようなツール名まるごとの拒否ルールを追加すると、tool searchが無効・非対応の環境ではキャッシュが切れます。既定のtool searchが有効なら維持されます
いずれも単発では小さなコストですが、セッションが長引くほどこうした操作の回数が積み重なり、都度の再処理が合算されていきます。
逆にキャッシュを壊さない操作も知っておくと安心です。ファイルの編集・読み直し、/recap、/rewindでの巻き戻し、権限モードの切り替え(opusplanを除く)はいずれもキャッシュを維持したまま実行できます。CLAUDE.mdをセッション中に編集しても、その変更自体はキャッシュを壊しません。ただし反映は次の/clear・/compact・再起動まで持ち越されます。
原因4: 圧縮そのものが大きなリクエストになる
/compactは要約対象の会話をまるごと読んでから要約を作るため、大きなコンテキストを圧縮する行為自体が大きなリクエストになります。キャッシュが温かいうちは、この要約リクエストもキャッシュ済みプレフィックスから読めるので、実際のコンテキストサイズから想像するより安く済みます。
問題はキャッシュのTTLを過ぎた後の圧縮です。読み込むべきキャッシュが残っていないため、要約リクエストは履歴全体を未キャッシュのまま処理します。これが、長時間放置したセッションを再開したときの/compactが最も高くつく理由です。Pro・Maxプランでは、約1時間以上放置され10万トークンを超えたセッションを再開すると、最初のメッセージを送る前にダイアログが開きます。この時点でキャッシュは失効済みなので、どれを選んでも次のリクエストは全履歴を1回処理します。違いは、その後のリクエストが運ぶ量です。
再開ダイアログの3択
要約から再開
その場で
/compactが走ります。全履歴に対する要約リクエストが1回入り、履歴は要約・直近のやり取り・最近読んだ最大5ファイルに置き換わります。以後のリクエストは要約ぶんだけを運びます。全体をそのまま再開
詳細はすべて残ります。最初のメッセージで全履歴を再処理して再キャッシュし、以後はキャッシュが温かい間、読み取りで進みます。リクエストごとの単価は会話サイズに比例します。
今後は聞かない
全体を再開し、以後の再開でダイアログを出さなくなります。
要約に含まれなかった内容はもうClaudeのコンテキストにありません。前の作業の細部に依存するなら全体再開、区切りがついているなら要約再開、という分かれ方になります。
利用形態別にどれだけ影響が違うか
同じ「長時間セッション」でも、使い方によって影響の出方は変わります。
| 利用形態 | 対策の効き方 | 理由 |
|---|---|---|
| 数時間、離席を挟まず対話し続ける | 対策の効き方条件次第 | 理由キャッシュは温かいまま保たれやすいが、コンテキスト自体は伸び続ける |
| 1時間以上の離席を挟む(APIキー・クラウド経由・使用量クレジット時は5分以上) | 対策の効き方大きい | 理由離席のたびにTTLを外れて再処理が発生しやすく、TTL調整や/clearの効果が大きい |
| goalやスケジュールタスクを裏で走らせたまま放置 | 対策の効き方大きい | 理由チェックイン間隔や配信設定を絞ることで無駄打ちを直接減らせる |
| 単発の短いセッションだけを使う | 対策の効き方ほぼ影響なし | 理由キャッシュが切れるほどの空白が生まれる前にセッションが終わる |
状況別に、どの対処が効くか
原因ごとに効く対処は異なります。
原因から選ぶ対処
休憩をよく挟む
APIキー・クラウド経由・使用量クレジットでメイン会話を使っているなら、
promptCacheTtlを1hに指定するか、環境変数CLAUDE_CODE_PROMPT_CACHE_TTL=1hをセットして1時間TTLを固定します。サブスクリプションの枠内は、メイン会話が既定で1時間です。無関係な作業に移る
要約を待たず
/clearで会話ごと畳みます。/clear自体に費用はかかりません。goalやスケジュールタスクを裏で回している
goalは使い終わったら
/goal stopなどで止め、スケジュールタスクは必要な間だけ有効にします。モデルやeffortを途中で変えがち
モデルとeffortはセッション冒頭で決め、作業の途中で変えないようにします。
長く放置したセッションを再開する
要約から再開するか全体を再開するかは、原因4の再開ダイアログの選び分けが判断基準です。
プロンプトキャッシュの仕組み全体はPrompt Cachingを理解するに、プランの利用上限はClaude Pro制限の仕組みに、チーム単位の支出可視化はClaude Codeのコスト管理にあります。
クラウドセッションのクレジット消費は、ローカルと何が違うか
クラウドセッション(claude.ai/codeやスマホから動かすセッション)専用のクレジットはありません。クラウドセッションの利用量は、ローカルのClaude Codeやclaude.aiと同じプランの利用上限に合算されます。クラウド側のVMに別料金もかかりません。
原因1の表の「クラウド経由」は、Amazon BedrockやGoogle CloudのVertex AIなどを経由する利用を指し、claude.ai/codeのクラウドセッションとは別です。
クラウドセッションを長く走らせたときの増え方も、ここまでの原因と同じ理屈です。会話全体を送り直すターンが積み重なり、キャッシュが切れれば全文を再処理します。
プランの上限を使い切ると、有効にしていれば使用量クレジット(extra usage)に切り替わります。Pro・Maxでは、/usage-creditsで開くclaude.aiのSettings > Usageで、残高や今月の消費額、月の上限を確認できます。Team・Enterpriseでは、課金権限のある人はOrganization settings > Usageで確認し、権限がない人は管理者にリクエストを送ります。管理者が組織やメンバー単位の上限を設けている場合もあります。
クレジットに切り替わると、原因1の表のとおりメイン会話のキャッシュTTLも1時間から5分に落ちます。1時間を保ちたいときはpromptCacheTtlで指定します。
クラウドセッションの環境変数にCLAUDE_AUTOCOMPACT_PCT_OVERRIDEを追加しても、圧縮が走る位置は変わりません。環境側が同じ変数をすでに設定していて、そちらが優先されるためです。圧縮の窓を変えたいときは、環境変数のCLAUDE_CODE_AUTO_COMPACT_WINDOWか/autocompactを使います。
1Mコンテキストでは、圧縮が起きる位置を自分で下げられる
リクエストごとに全履歴を運ぶ以上、コンテキストが大きいほど1回あたりの消費は重くなります。対象は、ネイティブで1Mのコンテキストウィンドウを持つモデル(Sonnet 5・Fableシリーズ・Anthropic API上のOpus 4.7以降)です。これらは既定では約96.7万トークンに届くまで自動圧縮しません。何も設定しなければ、履歴はそこまで運ばれ続けます。
圧縮が起きる位置は--autocompactで変えられます。claude --help(v2.1.285)の出力は次のとおりです。
--autocompact <auto|tokens> Auto-compact window size (auto, or
100k–1M tokens)値は10万〜100万トークンで、200000のようなトークン数、500k・1Mのような接尾辞、100〜1000の数字(千単位。200は20万)を受け付けます。起動1回だけ効くのが--autocompact、保存して以後も効かせるのが/autocompact 500k(autoCompactWindowとして保存されます)、スクリプトやクラウドセッションの環境変数向けがCLAUDE_CODE_AUTO_COMPACT_WINDOWで、この環境変数だけはトークン数の数値しか受け付けず、設定されている間は他の指定より優先されます。/autocompact autoでモデル向けの既定に戻ります。
窓を小さくすると、コンテキストが伸びきる前に圧縮が走ります。ただし圧縮も要約リクエストという大きな処理で、放置後の冷えたキャッシュに当たれば全履歴を未キャッシュで処理します。1回あたりの単価を抑えるか、圧縮の回数と要約で失う詳細を抑えるかは、作業の性質で決まるトレードオフです。
実際に何が起きているかを/usageで確認する
原因を推測するより先に、自分のセッションでどれが実際に起きているかを/usageで確認できます。Claude Code v2.1.251以降では、メイン会話の最初の応答が返った後に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)この行は3つを教えてくれます。
- misses: キャッシュが外れて再処理が発生したリクエストの数と、直近のミスの時刻、ミスしたリクエストが書き戻したトークン量の合計です。キャッシュから読めたはずの量の5%超かつ2,000トークン以上を再処理したリクエストが、ミスとして数えられます
- expected rebuilds: 圧縮やツール結果のクリアでClaude Code自身が会話を書き換えた結果のミスで、原因4はここに現れます。原因3の操作によるミスはmissesのほうに数えられます(v2.1.260以降は
likely cause: tool definitions changedのように推定原因も表示されます) - warm / cold: 今このプレフィックスがTTL内かどうかで、coldならセッションがどれだけアイドルだったかも表示されます
Pro・Max・Team・Enterpriseプランでは、/usageがさらに「plan usage breakdown」を表示します。直近の利用量をSkills・サブエージェント・プラグイン・MCPサーバーごとの割合で示し、/loopやスケジュールタスクのうち重いものは実行回数・合計トークン・直近実行時刻つきで一覧できます。原因を切り分けたら、この内訳で該当する項目が実際に上位に出ているかを照合してください。この内訳は直近利用量の10%以上を占める挙動(長いコンテキストやキャッシュミスなど)を自動で洗い出し、それぞれに削減のヒントを添えて表示するため、原因の見当がつかないときの手がかりになります。
まとめ
長時間セッションの消費は、離席が長いのか、裏でターンが走っているのか、コンテキストが大きすぎるのかで打ち手が変わります。キャッシュ切れならTTLと/clear、裏のターンならgoalやスケジュールタスクの絞り込み、コンテキスト肥大なら圧縮位置の調整、という対応です。Messages APIを直接呼ぶ実装なら、圧縮の直後にレスポンスを一度止める設計でループ全体の消費に上限をかけられます。