Claude Code プロンプトキャッシュで費用を抑えるQ&A

この記事の要点
- Claude Code は毎回会話全体を送り直すが、前回と同じ先頭部分はキャッシュから安く速く読み直す。自動で動くので設定は不要
- モデルの切り替え・考える深さの変更・fast mode・MCP の付け外し・/compact などで、次の1回だけ遅く高くなる
- 保持時間は5分か1時間。/usage の Prompt cache (main) でヒット率と、外れた理由の見当を確かめられる
Claude Code を使っていて、「モデルを替えた直後だけ返事が遅い」「休憩から戻った最初の1回が重い」と感じたことはないでしょうか。その多くは プロンプトキャッシュ の仕組みで説明できます。
この記事では、公式ドキュメント「How Claude Code uses prompt caching」(2026年11月1日確認)にもとづいて、よくある疑問をQ&Aの形で整理します。
Q1. プロンプトキャッシュとは何ですか?
前回と同じ部分を「読み直し済み」として再利用し、速く・安くする仕組みです。 AIは前のやりとりを覚えていないので、Claude Code は毎回、システムの指示・プロジェクトの情報・これまでの会話・新しい依頼をまるごと送り直します。新しい内容は末尾に足されるだけなので、送る中身の大部分は前回と同じです。その同じ部分を、キャッシュから割安の料金で読み直します。
Claude Code では 自動で使われる ので、ふだん設定する必要はありません。
Q2. どこまでが「同じ」と判定されるのですか?
先頭から完全に一致している部分だけです。 途中のどこか1か所でも変わると、そこから後ろはすべて計算し直しになります。ファイルごと・部分ごとのキャッシュはありません。
そこで Claude Code は、変わりにくいものほど前に並べて送っています。
| 層 | 中身 | 変わるとき |
|---|---|---|
| システムの指示 | 基本の指示、道具の定義 | 読み込む道具の定義が変わったとき |
| プロジェクトの情報 | CLAUDE.md、自動メモリ、範囲指定のないルール | 開始時、/clear や /compact のあと |
| 会話 | 依頼、返事、道具の結果 | 毎回 |
会話の層が変わっても前の2層はキャッシュに残りますが、いちばん前のシステムの指示が変わると全部がやり直しになります。この「会話の枠」に何が入るかは コンテキストウィンドウの記事 で詳しく解説しています。
Q3. どんな操作でキャッシュが外れますか?
次の操作のあと、1回だけ遅く高い返事になります。 その後は新しい先頭部分がキャッシュされるので元に戻ります。
| 操作 | なぜ外れるか |
|---|---|
/model でモデルを替える | モデルごとにキャッシュが別だから |
| 考える深さ(effort)を替える | 多くのモデルで深さごとにキャッシュが別。Opus 5.5・Sonnet 5.5・Haiku 5.5・Fable 5.1 を APIキー かサブスクリプションで使う場合は保たれる |
| fast mode の入り切り | 速度ごとにキャッシュが別 |
| MCP サーバーの追加・削除 | 道具の定義が変わる(道具を後から読み込む方式なら影響しない) |
| 道具をまるごと禁止する | 道具の定義が消える(同上) |
/compact | 会話を要約に置き換えるため |
| 画像をたくさん貼る | 上限に近づくと古い画像がまとめて外されるため |
| Claude Code の更新 | 指示や道具の定義が変わるため。更新は次回の起動時に当たる |
fast mode は、会話の途中で初めて入れると、それまでの会話をキャッシュなしで fast mode の料金で読み直します。入れるならセッションの最初がおすすめです。詳しくは Claude Codeのfast mode で解説しています。
Q4. 逆に、キャッシュを崩さない操作は?
会話の末尾に足すだけの操作は、キャッシュを崩しません。
- リポジトリのファイルを編集する(変わったことの通知が末尾に足される)
- CLAUDE.md を途中で編集する
- 権限モードを切り替える(
opusplanで計画モードに出入りする場合を除く) - 出力スタイルを替える
- スキルやコマンドを呼ぶ(frontmatter で別のモデルを指定している場合はモデル切り替えになる)
/recapで要約を表示する/rewindで前に戻る- サブエージェントを呼ぶ
Q5. CLAUDE.md を書き換えたのに効かないのはなぜ?
プロジェクト直下と自分用の CLAUDE.md は、セッション開始時に1回だけ読まれるからです。 途中で書き換えてもキャッシュは崩れませんが、その代わり書き換えた内容も反映されず、開始時の版のまま動きます。新しい内容は、次の /clear・/compact・再起動のときに読み込まれます。
Q6. /compact は高くつくのですか?
作業の途中ならそれほどでもなく、長い休憩のあとだと高くつきます。 /compact は要約を作るための依頼を別に送りますが、キャッシュが温かいうちなら会話の大部分をキャッシュから読めます。一方、保持時間を過ぎたあとだと、要約のために会話全体をキャッシュなしで読み直します。
公式ドキュメントのおすすめは、作業の区切りで自分から /compact する こと、そして進んだ道を丸ごと捨てたいときは /compact ではなく /rewind で前に戻ることです。戻した先はすでにキャッシュ済みだからです。
Q7. キャッシュはどのくらいの時間残りますか?
使っていない時間が続くと消えます。保持時間は5分と1時間の2種類です。 キャッシュに当たるたびに時計は巻き戻るので、作業を続けている間は残ります。1時間のほうは休憩をはさんでも残りますが、書き込みの料金が高くなります。
| 依頼の種類 | サブスクリプション(プランの範囲内) | 追加の使用量・APIキー・クラウド経由 |
|---|---|---|
| メインの会話 | 1時間 | 5分 |
| それ以外(サブエージェント、要約など) | 5分(一部の補助の依頼は1時間) | 5分 |
自分で決めたいときは、メインの会話は promptCacheTtl、それ以外は subagentPromptCacheTtl に 5m か 1h を指定します(v2.1.242 以降)。APIキーやクラウド経由で1時間にしたいなら、promptCacheTtl を 1h にします。
Q8. キャッシュがちゃんと効いているか確かめるには?
/usage を実行し、Prompt cache (main) の行を見るのがいちばん手軽です。 この行には、セッションのヒット率・外れた回数・今キャッシュが温かいかが出ます。外れた理由の見当がつくときは、likely cause: tool definitions changed のように理由も表示されます。
もっと細かく見たいときは、ステータスラインで次の2つの数を表示します。作り方は Claude Codeのステータスライン で解説しています。
| 項目 | 意味 |
|---|---|
cache_creation_input_tokens | この回にキャッシュへ書き込んだ量(書き込みの料金) |
cache_read_input_tokens | この回にキャッシュから読んだ量(割安の料金) |
読んだ量が書き込んだ量より十分多ければ、うまく効いています。書き込みが毎回多いままなら、先頭部分のどこかが毎回変わっています。
Q9. 費用を抑えるために、今日からできることは?
モデルと考える深さはセッションの最初に決め、途中ではなるべく替えない。これがいちばん効きます。 あわせて次の3つを意識します。
- fast mode を使うならセッションの最初に入れる
/compactは作業の区切りで自分から実行する- 進んだ道を捨てたいときは
/rewindで戻る
まとめ
- プロンプトキャッシュは 前回と同じ先頭部分を安く速く読み直す 仕組み。自動で動く
- モデル・考える深さ・fast mode・MCP・
/compactなどの変更で、次の1回だけ 遅く高くなる - 保持時間は5分か1時間。
/usageの Prompt cache (main) でヒット率を確かめる
出典
この記事はAIを使って下書きし、著者が事実確認・加筆しています。ツールの機能や料金は変わることがあるため、最新の情報は各社の公式ページでご確認ください。


