はじめに

本記事は、Claude Code のプロンプトキャッシュが切れたあとの再開にどれだけ費用がかかるかを数え、その再開を新しいセッションへの引き継ぎに置き換えた記録です。
数字は、25 日分（2026-09-29〜10-23）の自分のセッション記録から出しました。

この記事では、

プロンプトキャッシュの寿命と料金の仕組み
寿命が切れたあとの再開で何が起きるか
自分の環境で数えた、再開の書き込みの量と金額
再開の代わりに、新しいセッションへ作業を引き継ぐ steering スキル
steering スキルで再開したときに、書き込みがどれだけ減ったか
並行する作業を見渡すための status

といった点を中心に書いています。

環境

項目	内容
エージェント	Claude Code（デスクトップアプリと CLI）
プランとモデル	Claude の Pro プラン、モデルは主に Claude Opus 5.5
集計の範囲	1 つのワークスペースのセッション記録（メイン 225 セッション、応答 9,835 回）
仕様の確認日	2026-10-24（公式ドキュメント）

キャッシュの仕組み

プロンプトキャッシュとは

Claude Code は、毎回のリクエストでシステムプロンプト・ツール定義・それまでの会話をまとめて送ります。
プロンプトキャッシュは、この送る内容を一度書き込んでおき、次のリクエストでは同じ部分を安く読み直す仕組みです。
読み直しは安い一方、書き込みは通常の入力より高くつきます。

Opus 5.5 の単価（100 万トークンあたり）は次のとおりです。

種類	単価	読み取りとの比
1 時間枠の書き込み	8 USD	40 倍
5 分枠の書き込み	5 USD	25 倍
読み取り	0.20 USD	1
出力	20 USD	100 倍

Opus 5.5 と Sonnet 5.5 は読み取りが入力の 0.05 倍と安いぶん、書き込みとの差が大きくなります¹。

寿命は 1 時間か 5 分か

キャッシュには寿命（TTL）があり、使うたびに延びます。
Claude Code のメインの会話は、定額プランの範囲で使っていれば 1 時間、API キーで使う場合は 5 分です。
サブエージェントや compaction などの補助の要求は、定額プランでも 5 分です。

対象	寿命
メインの会話（定額プランの範囲）	1 時間
メインの会話（API キー・クラウド・上限を超えたあとのクレジット）	5 分
サブエージェント・compaction など	5 分

寿命は、応答が終わった時刻ではなく、キャッシュを読み書きしたリクエストの開始から数えます。
設定の promptCacheTtl（メイン）と subagentPromptCacheTtl（その他）で、5m か 1h に変えられます。

切れると何が起きるか

寿命を過ぎたあとの最初のリクエストは、キャッシュを読めず、送った内容を改めて書き込みます。
会話が長いほど、この 1 回が重くなります。

自分の環境で数えた

セッション記録（~/.claude/projects/ の JSONL）から、応答ごとの usage を集計しました。
同じ応答がブロックごとに複数行に記録されるので、requestId で重複を除いています。
金額は、同じ使い方を API で払った場合の目安です²。

書き込みの半分以上は、放置のあとの再開

メインの会話の書き込みを、いつ出たかで 3 つに分けました。
メインの会話の書き込みは、すべて 1 時間枠でした。

いつ	回数	書き込み	金額	1 回あたり
セッションの最初の応答	168 回	911 万	73 USD	0.43 USD
1 時間以上あけたあとの最初の応答	120 回	2,843 万	227 USD	1.90 USD
それ以外（作業中の増分）	8,775 回	1,419 万	114 USD	0.013 USD

1 時間以上あけた再開は、回数では 1% ほどなのに、書き込みの金額の半分以上（227 USD）を占めました。
作業中の 1 応答の書き込みは 0.013 USD ほどで、再開の 1 回はその 150 倍近くになります。
同じ 2,843 万トークンを、1 時間以内に戻って読み取りで済ませていれば、約 6 USD でした。

60 分を境に跳ね上がる

直前のリクエストからの間隔ごとに、1 応答あたりの平均の書き込みを並べました（単位は万トークン）。

60 分までは千トークン前後なのに、60 分を超えると 20 万トークン前後に跳ねます。
1 時間以上あけた 133 回のうち、会話の部分まで読めたのは 2 回だけでした³。
離れる時間が 59 分か 61 分かで、次の 1 回の費用が 100 倍以上変わることになります。

steering スキルで、再開を引き継ぎに変える

なぜ引き継ぎの仕組みが要るか

ここまでの数字から言えるのは、1 時間以上あけたら、同じセッションを再開するより新しいセッションで始めたほうが安い、ということです。
ただ、新しいセッションは前の会話を覚えていません。
何を決めて、どこまで進み、何を聞いていたのかを説明し直したり、エージェントに調べ直させたりすると、その分の手間とトークンがかかります。
そこで、作業の状況をセッションの外のファイルに残し、次のセッションがそれを読んで続きから始められるようにしたのが steering スキルです。

標準のコマンドとの違い

Claude Code にも、会話を軽くしたり区切ったりするコマンドがあります。

コマンド	すること	引き継ぎに使うときの注意
`/compact`	会話を要約して置き換える	要約なので、あとで要る情報まで落ちることがある。冷えてから行うと、要約の要求が会話の全部を書き直す
`/clear`	会話を消して新しく始める	前の会話の中身は何も持ち越さない
`/rewind`	会話を前の時点まで戻す	戻す位置を選ぶ必要があり、使いどころを選ぶ

どれも便利ですが、「何を次に渡すか」は自分で決めることになります。
使いどころは、公式ドキュメントで仕様を確かめてから決めるのがおすすめです。

モデルの切り替えには注意が要ります。
キャッシュはモデルごとに別なので、/model で途中からモデルを替えると、それまでの会話がまるごと書き込み直しになります。
放置のあとの再開と同じ重さの書き込みが、離れていなくても起きます。

steering スキルとは

steering スキルは、作業に要る情報を会話から抜き出して、作業ごとのファイルに書き出しておくスキルです。
書籍『実践Claude Code入門』のサンプル⁴を元に、業務で使っています。
会話のすべてを次のセッションへ持ち越すのではなく、やりたいことに必要な情報だけを、物理的なファイルとして残すのがポイントです。

進め方は、次の順です。

requirements に、何をしたいかを書く
design に、それを具体的にどう行うかを、詳細な計画として書く
tasklist に作業を分け、その順に実装・作業を進めながら、済んだものに印を付ける
summary に、ここまでを整理したまとめを書く

計画を立ててから、タスクリストどおりに進めるので、どこまで進んだかは常にファイルに残ります。
新しいセッションは、会話の履歴ではなく、このファイルを読んで続きから始めます。

4 つのファイルの中身

ファイル	中身	出どころ
`requirements`	何をしたいか（目的・やること・やらないこと）	サンプル
`design`	具体的にどう行うか（方針・手順・決めたこと）	サンプル
`tasklist`	タスクの一覧と進み具合	サンプル
`summary`	整理したまとめ。振り返りや作業の結果の報告に使う	足した

summary は、requirements から tasklist までを整理し直したものです。
作業の振り返りや、結果の報告をそのまま書き起こせるようにしています。

この記事を書いた作業を例にすると、中身はたとえば次のようになります。

requirements の例

# 要求
## 目的
Claude Code のキャッシュが切れたあとの再開の費用を、記録で数えて記事にする
## やること
- 公式の仕様（寿命・料金）を確かめる
- セッション記録から、再開の書き込みを数える
## やらないこと
- 定額プランの請求額の推定

design の例

# 設計
## 方針
- 金額は API の単価で換算した目安として書く
- 再開は「直前のリクエストから 1 時間以上あいた最初の応答」と定義する
## 手順
1. ~/.claude/projects/ の JSONL から usage を集める（requestId で重複を除く）
2. 書き込みを「開始・再開・作業中」に分けて数える
3. 間隔ごとの平均の書き込みを出し、60 分の前後を比べる

tasklist の例

# タスク
- [x] 公式ドキュメントで寿命と単価を確かめる
- [x] 集計スクリプトを書いて流す
- [ ] 骨子を作って確認をもらう
- [ ] 本文を書く

summary の例

# まとめ
## 結果
- 1 時間以上あけた再開は 120 回で、書き込みの金額の半分以上（227 USD）
- 60 分を境に、1 応答の書き込みが千トークン前後から 20 万前後に跳ねる
## 振り返り
- 再開の定義を最初に決めておけば、集計のやり直しが減った

ここに挙げた例は、中身のイメージをつかむための簡単な記載例です。
実際の開発業務で使うときは、要求仕様や機能設計を具体的に書くので、どのファイルもこれよりずっと詳細になります。

同じ考え方のプランモード

Claude Code にも、実行の前に計画を立てるプランモードがあります。
先にやりたいことを明確にして計画を立て、実行はそれに沿って進める、という考え方は steering スキルと同じです。
ただ、プランモードの計画は会話の中に置かれます。
セッションを離れたあとに続けるには、結局その会話をまるごと引き継ぐことになり、再開の費用を抑えたい今回の目的には合いません。

steering で再開した結果

この記事も、返事待ちで止めたセッションを、翌日の昼と夜に、新しいセッションから 2 回再開して書いています⁵。
その 2 回を、引き継ぎ元のセッションをそのまま再開した場合と比べました。

	1 回目	2 回目
離れていた時間	16.5 時間	8.9 時間
引き継ぎ元の文脈（再開したら書き直す量）	27.6 万	16.2 万
steering で始めた直後の文脈	10.1 万	9.2 万
始めた直後の書き込み	3.5 万	9.2 万
金額（そのまま再開 → steering）	2.21 → 0.32 USD	1.30 → 0.75 USD

steering で始めた直後の文脈は、システムプロンプトとツール定義に steering.md を足した分で、引き継ぎ元の 3〜6 割に収まりました。
2 回目は、先頭（システムプロンプトとツール定義）も読めずに全部を書き込んだので、差が小さくなっています⁶。
文脈が小さく始まるので、そのあとの応答の読み取りも、引き継ぎ元を再開した場合より軽くなります。

まだ 2 回だけなので、目安として集計の 120 回に当てはめてみます。
再開の書き込みは中央値で約 19 万トークン（1.5 USD）で、steering で始めた 2 回の平均（約 6.4 万トークン、0.5 USD）に置き換えると、227 USD が 60 USD ほどになる計算です。
新しいセッションが必要なファイルを読み直す分は入っていないので、実際の差はこれより小さくなります。

status で並行する作業を見渡す

ここまでのファイルがあれば、status が無くても作業は引き継げます。
ただ、作業が複数になると、ある作業を離れて別のことを始め、そのまま放置してしまうことが増えます。
そこで私の版では、status という概念を新しく足し、並行している作業がそれぞれどういう状況なのかを、横断して整理できるようにしました。

status は、作業ごとの状況を端的にまとめた小さな JSON です。
state は、作業中・返事待ち・一区切り・終了のような状態で、状態ごとに書く項目が少し変わります。

status の例（作業中・返事待ち・一区切り）

{
  "task": "20261024-prompt-cache-article",
  "purpose": "プロンプトキャッシュの記事を書く",
  "state": "working",
  "next": "本文を書き直してサイトに載せる",
  "progress": "3/4",
  "updated": "2026-10-25T23:08:00+09:00"
}

{
  "task": "20261025-usage-unreported-count",
  "purpose": "使用量の集計で、レポートにならなかった作業が大きい理由を調べる",
  "state": "waiting",
  "asking": "振り返りの提案 3 件を反映するか、TODO に残すか",
  "next": "返事を受けて反映し、コミットする",
  "progress": "0/1",
  "updated": "2026-10-25T21:14:00+09:00"
}

{
  "task": "20261025-recipe-page-layout",
  "purpose": "レシピページの手順の書き方をそろえる",
  "state": "idle",
  "next": "スマホで通知が届くかを確かめてもらう",
  "progress": "0/1",
  "updated": "2026-10-25T10:08:00+09:00"
}

返事待ちなら asking に聞いていることを、どの状態でも next に次の一手を書いておきます。
作業の数だけ tasklist を読まなくても、status を集めれば、作業がいくつあってそれぞれどこで止まっているかを一覧できます。

形がそろっているので、HTML にして一覧に並べることもできます。
私は、終えていない作業を状態の札と一緒に並べ、開くと聞いていることと次の一手が出る、簡単な一覧で運用しています。

どの作業から手を付ければよいかが一目で分かるので、次のセッションを始めやすくなります。

開いた作業の「再開をコピー」を押すと、status から作った再開用のプロンプトがコピーされます。
返事待ちの作業なら、次のような文です。

/steering resume 20261025-usage-unreported-count
前のセッションは「振り返りの提案 3 件を反映するか、TODO に残すか」の返事待ちで止まっています。回答：

新しいセッションに貼り、「回答：」の後に返事を書き足して送れば、steering スキルが作業のファイルを読み、続きから始めます。
返事待ちでない作業なら、2 行目は「次は「（次の一手）」から。」になります。

これはごく簡単な例です。
開発の業務などで並行する作業が増えてくるなら、状態ごとに列を分けたかんばんボードや、ダッシュボードのような形で可視化したほうが、整理しやすいと思います。

おわりに

Claude Code のキャッシュは、定額プランのメインの会話でも 1 時間で切れます。
切れてからの再開は、1 回で作業中の応答の 150 倍近い書き込みになり、記録では書き込みの金額の半分以上を占めていました。

離れるなら作業に要る情報をファイルに残し、戻ったら新しいセッションで始める、という形にすると、その書き込みを小さくできます。
steering スキルはその引き継ぎのための仕組みで、status を足すと、並行している作業のどれから手を付ければよいかも見えるようになります。

ただ、status は書き忘れると役に立ちません。
いまは、Claude が毎ターンの回答の末尾に状況を書き、Stop hook がそれを読んで status に反映する形を試しています。
一方で、毎ターン状況を書かせると、そのぶん出力のトークンが増えます。
hook で試しながら、コストをかけずに status の書き忘れを防げる仕組みを、試行錯誤しているところです。

参考

読み取りが入力の 0.1 倍のモデルでは、書き込みは読み取りの 12.5 倍（5 分枠）〜20 倍（1 時間枠）です。 ↩
定額プランの請求額ではなく、同じ使い方を API で払った場合の目安です。金額は Opus 5.5 の応答だけを 2026-10-24 時点の単価で換算しました。 ↩
2 回のうち 1 回は 60.2 分で、期限を過ぎてもすぐには消えないという公式の説明で説明がつきます。もう 1 回（88.7 分）は、原因を確かめられていません。 ↩
GenerativeAgents/claude-code-book-chapter8（MIT ライセンス） ↩
プライベートの環境では、4 つのファイルの要点を 1 つのファイル（steering.md）にまとめた版を使っています。 ↩
同じディレクトリで並行して動くセッションは、互いのキャッシュの先頭を読めます。1 回目は、ほかのセッションが先頭を温めていたと考えられます。 ↩