Claude Codeを10時間放置で実測：177k再読は空ターン何回分か

関連記事としては BlogClaude Code の新effortモード徹底解説｜max・ultracode・autoと『呪文ultrathink』の正体Claude Code の /effort に増えた max・ultracode・auto と、プロンプトに紛れ込ませる呪文 ultrathink を、公式が明言した『ultracode は API の effort レベルではない』を起点に解剖。overthinking・自律ワークフロー・永続性と優先順位の罠まで、誤解されやすい論点を一次情報で正します。→ もあわせて読むと、今回の論点とのつながりを把握しやすくなります。

この方法が効くのは、数百kトークンまで育ったセッションを、数時間以内に同じ状態で再開したい人です。APIの従量課金なら、空ターンを55分ごとに送っても、冷えたキャッシュを1回書き直すより安くなる計算です。

一方、Max / Proのサブスクでは、空ターンが利用枠をどれだけ消費するか公開されていません。数十k程度のセッションなら、冷えてもAPI換算で1ドル未満です。したがって、通常の作業セッションを守るために常時温めるのは過剰です。枠を使ってでも守りたい長大なセッションだけ、回数を限定して使うのが現実的です。

なお、この記事ではプロトタイプを作りません。計算上の損得と設計案までは示しますが、自動送信の実装を検証していないため、実際の枠消費や停止処理には実装リスクが残ります。

前回の記事（Blogeffort を途中で変えるとキャッシュはどうなる？ Fable 5.1 と Opus 5 で実測したFable 5.1 の値下げはキャッシュ読みだけ。Claude Code が TTL を決める仕組み、キャッシュを壊す操作と壊さない操作、effort 切替時の再書き込みを Fable 5.1 と Opus 5 の usage で実測しました。→）で、Claude Code のメイン会話はサブスクの枠内なら1時間キャッシュだと確認しました。裏を返せば、1時間を超えて席を外すとキャッシュは消え、戻った最初のターンで履歴全部を読み直すことになります。

実例を1つ。約200kトークンまで育ったセッションを、日付が変わるまで約10時間放置してから再開したときの usage です。

システムプロンプト冒頭の約26kは別セッションと共有されていたので読めましたが、177kトークンが1時間キャッシュの書き込み単価（$20/MTok）で再書き込みされました。API換算で約 $3.54。その次のターンの creation は628トークンなので、この1ターンだけが突出して高いことが分かります。

resume時に「要約から再開しますか」と聞かれるのも同じ理由です。公式 docs は「長いセッションに戻る最初の1ターンが最も高いリクエストになり得る」と説明しています。

そこで出てくる発想が「1時間経つ前に空ターンを送ってキャッシュを温め直せば、冷えた再読を避けられるのでは」です。この記事は、それをClaude Codeのスキルとして作る価値があるかを、作る前に計算します。

APIには正式な手段があります。前回と同じリクエストを max_tokens: 0 で送ると、モデルは出力を生成せずにプレフィックスだけ処理し、キャッシュのタイマーがリセットされます。課金はキャッシュ読みだけ（出力トークン0）です。

公式 docs はFable 5.1について、はっきりこう述べています。「キャッシュ読みが $0.25 になったので、5〜60分の間隔なら1時間TTL（書き込み2倍）を払うより、5分TTLのままキープアライブを送る方が通常は安い」。理由は単純で、ミスの代償（再書き込み）に対して読みが極端に安くなったからです。

制約として、stream: true・構造化出力・強制 tool_choice・Batchとは併用できません。また、これは自分でAPIを叩いている人の話です。Claude Codeのユーザーがこの手段を直接使うことはできません。

⚠️ 危険ポイントと戻し方: max_tokens: 0 はClaude Codeにそのまま移植できません。Claude Codeの内部リクエストを無理に書き換える構成は、更新で壊れたり、意図しない課金を招いたりします。API側で試す場合も、まず1回だけ実行して usage の cache read と output が想定どおりか確認し、不要になったキープアライブのジョブを停止します。

promptCacheTtl: "1h" は、使用クレジット課金中やAPIキー利用時に1時間を維持する設定です。ただし、放置が1時間を超えた場合の再書き込みを防ぐものではありません。

つまりClaude Codeで「温め続ける」には、本物のターンを定期的に送るしかありません。APIのキープアライブと違い、次の3点が付いてきます。

1. 短くても応答が生成される
2. その往復がコンテキストに積まれる
3. サブスクの枠を消費する

Fable 5.1の単価は、キャッシュ読み $0.25/MTok、1時間キャッシュ書き込み $20/MTok、出力 $50/MTokです。Claude Codeの空ターン1回は「全履歴のキャッシュ読み＋新規の数百トークン書き込み＋数トークンの出力」なので、ここではほぼ読みの費用として計算します。

冷えた再読1回の費用（1時間TTLの書き込み単価）

書き込み $20 ÷ 読み $0.25 = 80なので、コンテキスト量に関係なく空ターン80回分で冷えた再読1回と同額です。55分おきに送るなら、80回は約73時間分に相当します。つまり、約3日以内に戻る前提なら、API単価だけでは温め続ける方が安いという判断になります。

放置時間別（150kの例）

この表の「温め続ける」は、55分ごとに送った空ターンの回数から計算したAPI定価での試算です。実際のClaude Codeサブスクで、キャッシュ読みが利用枠上どの程度割り引かれるかを測ったものではありません。

上の表はAPIの従量課金の話です。Max / Proのサブスクでは、ドルではなく週間・5時間の利用枠が減ります。ここが計算を難しくします。

• 空ターンでもAPIリクエストは発生し、枠の消費に数えられます。枠の消費量がキャッシュ読みでどれだけ割り引かれるかは公開されていません。「読みは安いから枠もほぼ減らない」とは断定できません
• 枠を使い切ると使用クレジット課金に移り、メイン会話のTTLは5分に落ちます。温め続けるつもりで枠を減らし、かえって5分キャッシュに追い落とされる逆転が起こり得ます
• 空ターンの往復はコンテキストを消費します。1回数百トークンとしても、放置中に何十回も積むと、その後の全ターンの読み取り量が増えます
• サブスク枠の「キャッシュ読み」に対する具体的な消費割引率は不明です。そのため、APIの $0.25/MTok をそのままサブスクの利用枠へ換算することはできません

したがってサブスクでの判定は「ドルで安いか」ではなく「枠を減らしてまで守る価値のあるセッションか」です。数十kのセッションなら冷えてもAPI換算で $1未満。守る価値があるのは、数百kまで育った作業セッションを数時間以内に再開する場面に限られます。

結論を先に。API単価では作る価値があり、サブスクでは条件付きです。作るなら次の設計に絞ります。

1. 間隔は55分 1時間TTLの少し手前に設定します。5分TTLに落ちていたら意味がないので、/usage のPrompt cache行がwarmかを見て動かします。
2. 無操作時のみ 人が作業中はキャッシュが勝手に温まるため、空ターンは不要です。
3. 上限回数を決める 例として3回、約3時間まで。さらに長い放置は「戻るとき要約から再開」の方が合理的です。
4. 最小プロンプトにする 「返答不要」に近い1行にして、コンテキストの増加を数十トークンに抑えます。
5. 枠の残量を見て止める 週間枠が逼迫しているなら、キャッシュを守るより温めるのを諦めます。
6. 1回目で実測してから増やす 送信前後の /usage とセッション記録を確認し、枠の減り方が許容範囲か分からないまま連続実行しません。

やめた構成

常時稼働のデーモンとして、すべてのセッションを55分ごとに無条件で温める構成は採用しません。短いセッションまで対象にすると、冷えた再読を避ける利益より、枠の消費・コンテキストの膨張・停止忘れのリスクが大きくなります。

また、この記事ではプロトタイプまでは作りません。自動でターンを送る仕組みは、意図しない枠の消費や放置中の予期しない操作につながり得ます。実装前に、対象セッションのサイズ、再開までの予定時間、利用枠の残量を確認する必要があります。

今も残る不満

APIには max_tokens: 0 という、出力を増やさずにキャッシュだけ維持する手段があります。それに対してClaude Codeでは、同じことをするために本物のターンを送らなければなりません。

その結果、サブスク枠の消費割引率が分からず、APIの損益分岐をそのまま適用できません。さらに、空ターンの返答がコンテキストに積み上がります。「キャッシュだけを維持し、会話履歴も枠も増やさない」という利用者にとって自然な操作が、Claude Codeにはまだありません。

根本的には、API側に「Claude Codeから max_tokens: 0 相当を送る」機能が入れば、この記事の計算はすべて不要になります。Fable 5.1のキャッシュ読み値下げでAPI側は公式にキープアライブを推奨し始めたので、Claude Codeに同等機能が来る可能性は十分あります。changelogを追うのが一番の近道です。

• APIプロンプトキャッシュ（キープアライブの公式説明・価格）: https://platform.claude.com/docs/en/build-with-claude/prompt-caching
• Claude Codeのプロンプトキャッシュ（TTLバケツ・promptCacheTtl・resumeの再読）: https://code.claude.com/docs/en/prompt-caching
• Claude Code changelog（2.1.243のTTL設定、2.1.251のPrompt cache行）: https://code.claude.com/docs/en/changelog
• 前提となるFable 5.1の価格: https://www.anthropic.com/claude/fable

検証日: 2026-09-03。Claude Code v2.1.258、Maxプラン、Fable 5.1。再開時の再読トークン数はセッション記録の usage の実測値、金額はAPI定価での換算です。試算では、冷えた再読を cache creation の単価、空ターンを cache read の単価で計算し、サブスク枠の消費量については実測値がないため結論を出していません。

• BlogClaude Code の新effortモード徹底解説｜max・ultracode・autoと『呪文ultrathink』の正体Claude Code の /effort に増えた max・ultracode・auto と、プロンプトに紛れ込ませる呪文 ultrathink を、公式が明言した『ultracode は API の effort レベルではない』を起点に解剖。overthinking・自律ワークフロー・永続性と優先順位の罠まで、誤解されやすい論点を一次情報で正します。→
• BlogClaude Code の /effort 完全ガイド｜low〜maxの使い分けと『コストが増える本当の理由』Claude Code の /effort（low〜max・ultracode・auto）は「賢さ」ではなく「トークンの気前よさ」のレバー。モデル別の推奨スタートと、Opus 4.8 でコストが増えた気がする原因を『トークナイザ』と『effort』の2軸に切り分ける考え方を、公式一次情報と v2.1.156 の実機確認で解説します。→
• BlogAnthropicリーク2連発：Claude MythosとClaude Code流出で見えたKAIROS、BUDDY、Undercover Modeの正体Anthropicの2週間で2回のリークを整理。Claude Mythosの位置づけ、Claude Code流出の中身、KAIROS/BUDDY/Undercover Modeの意味を分けて読む。→

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！