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

こんにちは。暦の上では秋でも、昼間はまだ暑さが残っていて、PC の前を離れてひと息つく時間がつい長くなる頃ですね。今回は、その「席を外している間」に Claude Code のキャッシュ（一度読んだ会話を安く読み返すための一時保存）が消えてしまう問題を、お金と利用枠の両方から計算した話です。

答えを先に書くと、この温め直しが効くのは、数百kトークンまで育ったセッションを、数時間以内に同じ状態で再開したい人です。API の従量課金なら、約3日以内に戻る前提で、55分ごとに空ターンを送っても、冷えたキャッシュを1回書き直すより安くなる計算です。一方、Max / Pro のサブスクでは、空ターンが利用枠をどれだけ減らすのかが公開されていません。数十k程度のセッションなら、冷えても API 換算で1ドル未満です。普段の作業セッションまで常に温めておくのは過剰で、枠を使ってでも守りたい長大なセッションだけ、回数を決めて使うのが現実的だと思います。

なお、この記事ではプロトタイプを作っていません。計算上の損得と設計案までは示しますが、自動送信の仕組みそのものは検証していないので、実際の枠の減り方や止め方には実装上のリスクが残ります。

前回の記事（Fable 5.1 のキャッシュ経済学）で、Claude Code のメイン会話は、サブスクの枠内なら1時間キャッシュだと確かめました。裏を返すと、1時間を超えて席を外すとキャッシュは消え、戻った最初のターンで履歴を丸ごと読み直すことになります。

実際の例を1つ挙げます。約200kトークンまで育ったセッションを、日付が変わるまで約10時間放置してから再開したときの usage（1回ごとの使用量の記録）です。

cache read はキャッシュから安く読めた量、cache creation はキャッシュを新しく書き込み直した量です。システムプロンプト冒頭の約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のままキープアライブを送る方が通常は安い」。TTL はキャッシュの保存期間のことです。読み取りが極端に安くなったぶん、取りこぼしたときの代償（書き込み直し）の方が重く見える、という単純な理屈です。

ただし、stream: true・構造化出力・強制 tool_choice・Batch とは一緒に使えません。そしてこれは、あくまで自分で API を叩いている人の話です。Claude Code の利用者がこの手段を直接使うことはできません。

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

Claude Code 側で使える手段を並べると、こうなります。

紛らわしいのは 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 リクエストは発生するので、枠の消費に数えられます。そのときキャッシュ読みでどれだけ割り引かれるのかは公開されていません。「読みは安いから枠もほとんど減らない」とは言い切れず、API の $0.25/MTok をそのまま利用枠に置き換えて考えることもできません。

次に、逆転の恐れがあります。枠を使い切ると使用クレジット課金に移り、メイン会話の TTL は5分に落ちます。温め続けるつもりで枠を削った結果、かえって5分キャッシュに追い落とされる、ということが起こり得るわけです。

もう1つ、空ターンの往復はコンテキストも食います。1回は数百トークンでも、放置中に何十回も積み重なれば、その後のすべてのターンで読み取る量が増えていきます。

なので、サブスクで考えるべきなのは「ドルで安いか」ではなく、「枠を減らしてまで守る価値のあるセッションか」です。数十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分ごとに無条件で温める構成は採りません。短いセッションまで対象にすると、冷えた再読を避ける得よりも、枠の消費・コンテキストの膨らみ・止め忘れのリスクの方が大きくなるからです。

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

「キャッシュだけ保つ」操作が、Claude Code にはまだ無い

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

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

根本的には、API 側に「Claude Code から max_tokens: 0 相当を送る」機能が入れば、この記事の計算はすべて要らなくなります。Fable 5.1 のキャッシュ読みの値下げで、API 側は公式にキープアライブを勧め始めました。Claude Code に同じ機能が来る可能性は十分あると思っていて、changelog を追うのがいちばんの近道です。Claude Code の設定まわりでは、Claude Code の新effortモード徹底解説｜max・ultracode・autoと『呪文ultrathink』の正体 もあわせて読むと、今回の話とのつながりがつかみやすいと思います。

• 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 の単価で計算し、サブスク枠の消費量については実測値がないため結論を出していません。

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