なぜ長いセッションは高くなるのか。
なぜ切り替えたほうが安いのか。そして、なぜ切りすぎても損なのか。
Claude Code の費用構造を、仕組みから追います。
すべてはこの一点から始まります。
メッセージを送るたびに、Claude Code は新しい API リクエストを作ります。モデルはリクエストとリクエストの間で何も覚えていないため、システムプロンプト、プロジェクト文脈、これまでの全メッセージとツール結果、そして新しい発言を、毎回まとめて送り直しています。
50回目の発言では、あなたが打った1行だけでなく、それまでの全部をもう一度運びます。素朴に計算すると、費用はターン数の二乗で効いてきます。
| ターン | その時点のコンテキスト |
|---|---|
| 1回目 | 10K |
| 10回目 | 46K |
| 50回目 | 206K |
1ターンあたり4K増えるとすると、50ターンの累計処理量は約540万トークン。Opus 5 の入力単価5ドル/100万で計算すると約27ドルです。1セッションでこれは重い。
この構造をそのままにすると成立しないので、プロンプトキャッシュがそれを打ち消しています。以降はその仕組みの話です。
キャッシュは「先頭からの一致」で働きます。
API はリクエストの先頭部分（プレフィックス）を、最近処理した内容と照合します。通常のターンでは、プレフィックスは前回のリクエスト全体であり、新しいのは最後のやりとりだけです。
照合は完全一致です。プレフィックスのどこか1箇所が変われば、そこから後ろはすべて再計算されます。ファイルごと、区間ごとのキャッシュというものはありません。
この仕組みを最大限使うため、Claude Code は変わりにくい内容が先に来るようリクエストを並べています。
モデルとeffort（思考量）は、プロンプトの文章ではありませんが、どちらもキャッシュキーの一部です。
モデルごとに別のキャッシュがあり、切り替えると内容が同一でもリクエスト全体が再計算されます。effort も同じモデル内で水準ごとに別のキャッシュを持ちます。
キャッシュは、使い方を誤ると「使わないより高い」。
| 種別 | 倍率 | Opus 5（100万トークンあたり） |
|---|---|---|
| 基本入力 | 1.0倍 | 5.00ドル |
| 5分キャッシュ書き込み | 1.25倍 | 6.25ドル |
| 1時間キャッシュ書き込み | 2.0倍 | 10.00ドル |
| キャッシュ読み出し | 0.1倍 | 0.50ドル |
| 出力 | ─ | 25.00ドル |
ここが見落とされやすい点です。書き込みは素の入力より高い。読み出しに到達せず毎ターン書き直していると、1.25倍を払い続けることになります。
| 状態 | 50ターンの概算 |
|---|---|
| キャッシュなし | 27ドル |
| キャッシュが効いている | 2.7ドル |
| 毎ターン壊れている | 34ドル |
つまり「コンテキストが多いと高い」は半分だけ正しい。正確には ──
大きくても安定していれば0.1倍で済み、小さくても毎回壊れていれば1.25倍を払います。
Claude サブスクリプションでは利用がプランに含まれるため、上の金額がそのまま請求されるわけではありません。
ただし使用量の上限には効きます。壊れたキャッシュは、そのぶん枠を余分に消費します。金額として現れなくても、構造は同じです。
壊れると、次の1ターンが遅く高くなります。その後は新しいプレフィックスがキャッシュされます。
| 操作 | 内容 |
|---|---|
/model でモデル切替 | モデルごとに別キャッシュ。内容が同一でも履歴全体が再計算される |
opusplan 設定 | plan モードで Opus、実行時に Sonnet へ解決される。つまりplan モードの切替ごとにモデル切替が起きる |
/effort 変更 | モデルと並ぶキャッシュキー。会話開始後は確認ダイアログが出る |
| fast mode の有効化 | リクエストヘッダがキャッシュキーに入る。費用は会話につき1回だけ。深くなってから入れるほど高い |
| MCP の接続・切断 | ツールがプレフィックスに載っている場合のみ。既定の遅延読み込みなら壊れない |
| プラグインの有効化 | MCP サーバーを提供するプラグインのみ。スキル・コマンド・フック等は壊さない |
| ツール名そのものの deny | Bash のような裸の名前、Bash(*)、"*" のみ |
| Claude Code の更新 | 再起動後の最初のターンが未キャッシュになる |
更新後に古いセッションを再開すること。履歴が別のシステムプロンプトの後ろに来るため、全履歴がキャッシュ不一致で再処理されます。
費用は再開する会話の長さに比例します。長い会話に戻る最初の1ターンが、そのセッションで送る中で最も高いリクエストになりえます。
ここは誤解されやすい点です。対応モデルでの既定である遅延読み込みでは、サーバーの接続・切断・ツール一覧の変更は末尾に追記されるだけで、キャッシュ済みの部分を乱しません。
壊れるのはツール定義がプレフィックスに載っている場合で、これは tool search が使えない環境（Google Cloud の Agent Platform、独自ゲートウェイ経由など）や、alwaysLoad を指定した場合に起きます。
その状態では、こちらが何もしなくても壊れることがあります。stdio サーバーのプロセスが終了した、HTTP セッションが期限切れになった、一時的な失敗から自動再接続した、といった場合です。
なお MCP の設定ファイルを編集しただけでは変わりません。新しい設定は再起動時に反映され、そのときに接続・切断が起きます。
実用上は、こちらの一覧のほうが役に立ちます。
| 操作 | 挙動 |
|---|---|
| リポジトリのファイル編集 | 変更通知が末尾に追記されるだけ。過去の読み込み履歴は書き換わらない |
| CLAUDE.md の編集 | 壊さない。ただし反映もされない |
| 出力スタイルの変更 | 同上。壊さないが、反映もされない |
| 権限モードの切替 | 安全。ただし opusplan 使用時の plan モードだけは例外 |
| スキル・コマンドの呼び出し | 呼び出し地点にメッセージとして挿入される |
/recap | 履歴を置き換えず、出力として追記する |
/rewind | 過去のキャッシュに当たる |
| サブエージェント | 親のキャッシュは影響を受けない |
/advisor | 定義がキャッシュ区切りより後ろにあるため無傷 |
CLAUDE.md と出力スタイルは、セッション開始時に一度読まれてメモリに保持されます。途中で編集してもキャッシュは壊れませんが、Claude は開始時に読み込んだ版のまま動き続けます。
「CLAUDE.md を直したのに効かない」の正体はこれです。反映するには /clear、/compact、または再起動が必要です。
ただし例外があります。サブディレクトリの入れ子 CLAUDE.md や paths: 指定のルールは、該当ファイルが読まれた時点で読み込まれるため、読み込まれる前の編集は反映されます。
/compact は思ったより安い圧縮は履歴を要約で置き換えるので、会話層のキャッシュは設計上無効になります。しかし要約を作るリクエスト自体は、あなたの会話と同じシステムプロンプト・ツール・履歴を使うため、プレフィックスを共有して既存のキャッシュを読みます。
圧縮の時間のほとんどは要約の生成であって、キャッシュ不一致ではありません。直後のターンも、短くなった要約の分だけ作り直すだけなので、遅い部分ではありません。
/rewind という選択肢
進んだ方向を丸ごと捨てたい場合は、/compact ではなく /rewind です。
圧縮が新しいプレフィックスを作るのに対し、巻き戻しは既にキャッシュ済みのプレフィックスへ戻ります。残る履歴はその時点でキャッシュが作られた内容そのものだからです。しかも、それ以降の全ターンがそのプレフィックスを通して読んできたため、元のターンが TTL より前でもエントリは温かいままです。
「5分」という数字は、条件によって変わります。
| 認証方法 | TTL | 理由 |
|---|---|---|
| Claude サブスクリプション | 1時間（自動） | プランに含まれるため、長くしても追加費用がかからない |
| 上限超過で追加クレジット使用中 | 5分へ自動的に降格 | 課金対象になるため |
| API キー・Bedrock 等 | 5分（既定） | トークン課金のため。ENABLE_PROMPT_CACHING_1H=1 で変更可 |
| サブエージェント | 常に5分 | 自動の1時間は主会話にのみ適用される |
そして重要な点として、キャッシュに当たるたびにタイマーがリセットされます。「5分で切れる」のではなく「沈黙が5分続いたら切れる」です。作業を続けている限り、温かいまま保たれます。
席を立って戻ってきた最初の1ターンが目に見えて遅いのは、この期限切れが起きているためです。
Claude Code のキャッシュは、実質的に1台のマシンと1つのディレクトリに紐づいています。システムプロンプトに作業ディレクトリ、プラットフォーム、シェル、OS バージョンが埋め込まれるためです。
したがって別ディレクトリの2セッションは別のプレフィックスを作り、互いのキャッシュに当たりません。同一リポジトリの worktree も、それぞれ別の作業ディレクトリなので含まれます。
逆に、同じディレクトリで並行して動かすセッションは互いのキャッシュを読みます。連続するセッションは、起動時の git 状態のスナップショットが一致する限りプレフィックスを共有します。
応答のたびに2つの数値が返っています。
| 項目 | 意味 |
|---|---|
cache_read_input_tokens | キャッシュから供給されたトークン。標準入力の約10%で課金 |
cache_creation_input_tokens | そのターンで書き込まれたトークン。書き込み価格で課金 |
読み出しと書き込みの比率が高ければ機能しています。書き込みが毎ターン高いままなら、プレフィックスの中で何かが変わり続けています。第4章の一覧が原因の候補です。
コンテキストの内訳そのものは /context で確認できます。カテゴリ別の内訳と、どの CLAUDE.md や auto memory が読み込まれたかまで出ます。
ここまで費用の話をしてきましたが、逆側があります。しかも構造的に強い。
これが最大の利点です。キャッシュヒットはレート制限から差し引かれません。
つまり200Kの安定したコンテキストは、レート制限上ほぼ「無料で持ち歩ける」ということです。毎ターン200Kを運んでいても、枠を消費するのは新しく足された分だけ。上限に当たりやすくなるのはコンテキストが大きいときではなく、キャッシュが壊れているときです。
| 行為 | 30K トークンのファイル（Opus 5） |
|---|---|
| 読み込む（満額の入力） | 0.15ドル |
| 持ち続ける（キャッシュ読み出し） | 1ターンあたり0.015ドル |
個別のファイル1つで見れば、分岐点は10ターンです。10ターン以内にまた必要になるなら、消さずに持っているほうが安い。
ただしこれはファイル単位の話であって、セッション全体では別の計算になります。第8章で扱います。
文脈が足りないと、Claude は探索から始めます。grep して、候補を読んで、違ったのでまた読んで。この探索の1回1回が満額の入力です。
必要なファイルが既に載っていれば、この往復が丸ごと消えます。節約したつもりのコンテキストが、探索コストとして戻ってくるという構図です。
トークンの話より、こちらが本質かもしれません。文脈が足りないモデルは推測します。推測が外れたときのコストは、間違った実装 + デバッグ + やり直しの合計であり、最初から数ファイル多く読ませるコストを容易に上回ります。
サブエージェントは自分のコンテキスト窓で作業し、返ってくるのは最終結果だけです。6,100トークン読んでも、親には420トークンしか戻りません。
つまり「主コンテキストは安定させたまま、探索だけ外に出す」ができます。多いことと軽いことは両立可能です。
なお /rewind でセッションを分岐させる fork は、親のシステムプロンプト・ツール・履歴をそのまま受け継ぐため、最初のリクエストが親のキャッシュを読みます。
この資料で最も実用的な部分です。
両者は同じ土俵にありません。
持ち続けるコストは毎ターン発生します。「ターン数 × 全体量 × 0.1倍」。切り直すコストは1回だけ発生します。「読み直す分 × 1.0倍」。
片方は繰り返し費用、もう片方は一時費用です。この違いが効きます。
| 平均コンテキスト | 毎ターン | 再読込 | 合計 | |
|---|---|---|---|---|
| 持ち続ける | 100K | 0.05ドル | ─ | 3.00ドル |
| 20ターンごとに切る | 50K | 0.025ドル | 3回 × 15K | 1.73ドル |
前章で挙げた「10ターンで元が取れる」は個別のファイル1つを見た話であって、セッション全体では成り立ちません。持ち続ける費用は毎ターン積み上がるからです。
もう一点あります。同じディレクトリで git の状態が変わっていなければ、新しいセッションでもシステムプロンプト層とプロジェクト文脈層のキャッシュに当たります。
つまりスレッドを切っても、CLAUDE.md も MCP もスキル定義も満額で払い直すわけではありません。新しく満額になるのは、次の作業で読み直すファイルだけです。
条件は1つに絞られます。読み直す量が大きいときです。
深い探索の末にたどり着いた状態 ── 20ファイル読んで、grep を10回打って、ようやく原因が見えた ── これを捨てると、その探索を全部やり直すことになります。探索の1回1回は満額の入力です。
逆に、次の作業に必要なファイルが2〜3個なら、切ったほうが安い。
| 同じ作業を続けている | 別の作業に移る | |
|---|---|---|
| 持ち続ける | 正しい | 損。無関係な情報に毎ターン払い、精度も落ちる |
| 切る | 損。探索をやり直すことになる | 正しい |
軸は「頻繁に」でも「長く」でもなく、「関連性が切れたら」です。避けるべきなのは「同じ作業の途中で、サイズが気になって切る」という一点に絞られます。
作業が続いている以上、切った直後に同じファイルを読み直すことになりますし、探索の文脈が失われるので Claude は同じ試行錯誤を繰り返します。
費用とは別に、3つあります。長いコンテキストでは個々の情報への注意が薄まること。自動圧縮まで放置すると、要約が余裕のない状態で作られるので質が落ちること。そして一度誤った前提が入ると履歴に残り続け、後の判断を汚すこと。
3つ目が実務では大きいと思います。方向を間違えたセッションは、修正するより切ったほうが早い。ただしその場合は /clear より /rewind のほうが安く済みます。
| 状況 | 使うもの |
|---|---|
| 作業が終わり、別の対象に移る | /clear |
| 進んだ方向を捨てたい | /rewind |
| 続けるが、要点だけ残したい | /compact（焦点を指定して） |
押す前に確認する項目です。
| 項目 | 理由 |
|---|---|
| モデルを決める | 途中の /model は履歴全体を再計算させる |
| effort を決める | 同上 |
| fast mode を使うなら最初に入れる | 費用は会話につき1回。深くなってから入れるほど高い |
| CLAUDE.md を確認しておく | 途中の編集は反映されない |
| やること | 効果 |
|---|---|
| 大きな調査はサブエージェントへ | ファイルの中身が主コンテキストに入らない |
| プロンプトで対象を具体的に指定 | 読むファイルが減る。探索の往復が減る |
| 長く席を離れる前に区切る | TTL 切れの再構築を、意図した場所で起こす |
/context で内訳を見る | 何が場所を取っているかが分かる |
| 状況 | 操作 |
|---|---|
| 別の対象に移る | /clear |
| 方向を誤った | /rewind |
| 続けるが整理したい | /compact 認証まわりの修正に絞って のように焦点を指定 |
費用を決めているのは、コンテキストの大きさではありません。
安定しているか（プレフィックスが壊れていないか）と、関連しているか（今の作業に必要な内容か）の2つです。
大きくても安定していれば10分の1で運べます。小さくても壊れていれば1.25倍を払います。そして無関係な情報は、費用だけでなく精度も下げます。
第1部でシェルの原則、第2部で層の全体像、第3部で実例、第4部で Node と Next.js の内側、そして第5部で費用構造を見てきました。
通底しているのは同じ一点です。仕組みが分かっていれば、判断はその場で導ける。暗記する項目はほとんどありません。