著者 Claudeプロンプトキャッシュの損益分岐点を計算
Claudeのプロンプトキャッシュは書き込み1.25倍、読み取り0.1倍以下です。5分キャッシュが2回目で元を取る理由を、API料金と計算式で検証します。
節約前に把握すべきプロンプトキャッシュのコスト
プロンプトキャッシュを使うと、Claude はプロンプトの先頭部分を毎回読み直さずに再利用できます。判断の基準は、モデルの基本入力料金に対する 2 つの倍率です。2026 年 10 月時点では、すべてのモデルで、キャッシュへの書き込みに 5 分間の有効期間なら基本入力料金の 1.25 倍、1 時間の有効期間なら 2 倍がかかります。キャッシュからの読み取りは、ほとんどのモデルで 0.1 倍です。ただし、読み取り倍率はモデルによって異なります。Claude Fable 5.1 と Claude Mythos 5.1 では 0.025 倍です。これらのモデルは 2026 年 9 月 1 日に、この料金で提供開始されました。Claude Opus 5.5 と Claude Sonnet 5.5 では 0.05 倍です。Sonnet 5.5 は 2026 年 10 月 7 日に、0.1 倍からこの料金へ引き下げられました。以下の計算例では、標準の 0.1 倍の読み取り料金を使用します。読み取り料金が安いモデルでは損益分岐点がやや有利になります。次のセクションで、その差を示します。
この仕組みでは、現在の追加料金と後続リクエストの割引を比較します。最初に 1 回、プレフィックスを保存するための追加料金を支払います。その後、まったく同じバイト列で始まるリクエストでは、その部分の入力料金が通常の 10 分の 1 になります。上記のモデルでは、さらに安くなります。有効期間内に一度も再利用されないプレフィックスには、25 パーセントの追加料金だけが発生します。
損益分岐点を代数で一行に示す
キャッシュを使わずに送信した場合のプレフィックスの基本入力コストを B とします。キャッシュなしでは、N リクエストのコストは N × B です。5 分間のキャッシュでは、最初のリクエストが 1.25B でプレフィックスを書き込み、残りの N - 1 リクエストが 0.1B で読み取ります。両者を等しくすると、0.9N = 1.15 となり、N = 1.28 が得られます。2 回目のリクエストの時点で、キャッシュなしよりすでに安くなります。
1 時間キャッシュの書き込みコストが 2 倍になる場合も同じように計算すると、0.9N = 1.9 となり、N = 2.11 です。長時間キャッシュは損益分岐点に達するまでに 2 回の読み取りが必要です。そのため、デフォルトの選択肢ではありません。
読み取りコストが低くなると損益分岐点は移動しますが、大きくは変わりません。読み取りコストが 0.05x の場合、5 分間キャッシュでは 0.95N = 1.2 となり、N = 1.26 です。0.025x の場合は 0.975N = 1.225 となり、こちらも N = 1.26 です。1 時間キャッシュでは、それぞれ N = 2.05 と N = 2.03 になります。実用上の結論はどのモデルでも同じです。5 分間キャッシュは 2 回目のリクエストから有利になり、1 時間キャッシュは 3 回目のリクエストから有利になります。
以下のグラフでは、Claude Opus 5 の 20,000 token のプレフィックスを基準に価格を計算しています。2026 年 10 月時点の基本入力料金は 100 万 token あたり $5 で、8 月から変更されていません。Opus 5 は現在ではレガシーモデルですが、引き続き利用できます。後継の Claude Opus 5.5 は、0.05x の読み取りで 100 万 token あたり $4 です。そのため、同じプレフィックスの書き込みコストは $0.10、読み取りコストは $0.004 です。標準の 0.1x 読み取りで 100 万 token あたり $3 のモデルでは、すべての数値を 0.6 倍してください。曲線の形状は変わりません。
このグラフのデータ
[
{
"requests": 1,
"uncached_usd": "0.10",
"cached_5m_usd": "0.125",
"cached_1h_usd": "0.20"
},
{
"requests": 2,
"uncached_usd": "0.20",
"cached_5m_usd": "0.135",
"cached_1h_usd": "0.21"
},
{
"requests": 3,
"uncached_usd": "0.30",
"cached_5m_usd": "0.145",
"cached_1h_usd": "0.22"
},
{
"requests": 5,
"uncached_usd": "0.50",
"cached_5m_usd": "0.165",
"cached_1h_usd": "0.24"
},
{
"requests": 10,
"uncached_usd": "1.00",
"cached_5m_usd": "0.215",
"cached_1h_usd": "0.29"
},
{
"requests": 20,
"uncached_usd": "2.00",
"cached_5m_usd": "0.315",
"cached_1h_usd": "0.39"
}
]1 回だけのリクエストでは、キャッシュなしのコストが $0.10、キャッシュありのコストが $0.125 です。そのため、1 回しか使わないプロンプトをキャッシュすると、完全に損になります。2 回目のリクエストでは、5 分間キャッシュが $0.135 となり、キャッシュなしの $0.20 を下回ります。1 時間キャッシュはこの時点ではまだ不利で、$0.21 に対して、同じ $0.20 です。キャッシュなしのコストを下回るのは 3 回目のリクエストからで、$0.22 に対して $0.30 となります。20 回のリクエストでは、差額は $2.00 に対して $0.315 です。
キャッシュヒットが発生するとエントリも更新されます。そのため、公開されている料金表では、この列をキャッシュヒットおよび更新として示しています。したがって、リクエストの多いエンドポイントでは、5 分間のエントリが読み取り料金で無期限に維持されます。一方、1 時間の有効期間で書き込みコストが 2 倍になるのは、トラフィックに実際の空白期間がある場合だけです。
低いヒット率のコスト
実際のトラフィックではキャッシュミスが発生します。キャッシュミスでもブレークポイントを含むリクエストは書き込みとして課金されるため、コストはヒット率の関数としてモデル化するのが適切です。以下のグラフは、同じ 20,000 token のプレフィックスを含む 1,000 件のリクエストを対象にしています。
このグラフのデータ
[
{
"hit_rate_percent": 0,
"cost_5m_usd": "125.00",
"cost_1h_usd": "200.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 25,
"cost_5m_usd": "96.25",
"cost_1h_usd": "152.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 50,
"cost_5m_usd": "67.50",
"cost_1h_usd": "105.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 75,
"cost_5m_usd": "38.75",
"cost_1h_usd": "57.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 90,
"cost_5m_usd": "21.50",
"cost_1h_usd": "29.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 95,
"cost_5m_usd": "15.75",
"cost_1h_usd": "19.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 99,
"cost_5m_usd": "11.15",
"cost_1h_usd": "11.90",
"uncached_usd": "100.00"
}
]ヒット率が 0 パーセントの場合、料金は $125.00 となり、キャッシュなしの $100.00 より高くなります。さらに、1 hour cache では請求額が 2 倍になり、$200.00 になります。1.25 - 1.15h = 1 を解くと、5 minute cache が費用を削減し始めるヒット率は約 22 パーセントです。そのため、25 パーセントでもすでに $96.25 になります。2 倍の書き込みコストで同じ計算をすると、1 hour cache の損益分岐点は約 53 パーセントです。したがって、ヒット率が 50 パーセントでも料金は $105.00 となり、キャッシュなしの線を上回ります。90 パーセントでは、それぞれ $21.50 と $29.00 になります。99 パーセントでは、短いキャッシュの料金は $11.15 まで下がり、キャッシュなしの価格の 10 分の 1 という下限に近づきます。
0.05x read のモデルでは、損益分岐点は 5 minute cache で約 21 パーセント、1 hour cache で約 51 パーセントに下がります。0.025x read では、約 20 パーセントと 51 パーセントになります。read の価格が下がると下限も下がり、キャッシュなしのコストの 20 分の 1 または 40 分の 1 になります。
プレフィックスサイズを固定した後に制御できる唯一の入力値がヒット率であるため、計測すべき指標はヒット率です。
ブレークポイントを設定する価値があるプレフィックス
1 回のリクエストには、最大 4 個のキャッシュブレークポイントを設定できます。では、どのブロックに設定すべきでしょうか。候補は、リクエスト間でバイト単位に完全一致し、かつ効果が出る十分な大きさを持つブロックです。以下のグラフは、5 分間のキャッシュでヒット率 90 パーセントの場合に、一般的な 4 つの構成を 1,000 リクエストで比較したものです。
このグラフのデータ
[
{
"label": "System prompt",
"prefix_size_tokens": "2,000",
"uncached_usd": "10.00",
"cached_usd": "2.15",
"saved_usd": "7.85"
},
{
"label": "System plus tools",
"prefix_size_tokens": "8,000",
"uncached_usd": "40.00",
"cached_usd": "8.60",
"saved_usd": "31.40"
},
{
"label": "Policy document",
"prefix_size_tokens": "25,000",
"uncached_usd": "125.00",
"cached_usd": "26.88",
"saved_usd": "98.12"
},
{
"label": "Codebase context",
"prefix_size_tokens": "120,000",
"uncached_usd": "600.00",
"cached_usd": "129.00",
"saved_usd": "471.00"
}
]2,000 トークンのシステムプロンプトだけでも、キャッシュを使わない場合の $10.00 に対して、1,000 リクエストあたり $7.85 を削減できます。大量に処理すれば実際の金額になりますが、キャッシュの面白さはそこではありません。ツール定義を追加すると、8,000 トークンとなり、削減額は $31.40 です。すべてのリクエストで質問の対象になる 25,000 トークンのポリシードキュメントでは、$98.12 を削減できます。アーキテクチャを変えるのは最後の行です。コードベースまたはトランスクリプトのコンテキスト 120,000 トークンは、キャッシュを使わない場合に $600.00、キャッシュを使う場合に $129.00 かかり、$471.00 を削減できます。
削減額はプレフィックスのサイズとヒット率に比例します。それ以外の要因には左右されません。このため、プロンプトに何を含める価値があるかも変わります。Claude の 100 万トークンに実際にかかる費用は、1 回を超えて送信するデータであれば、表示価格の 10 分の 1、読み取り料金が安いモデルではそれ以下になります。
月額請求での見え方
以下のグラフでは、上で示した 8,000 トークンのプレフィックスに、システムプロンプトとツール定義を加え、90 パーセントのヒット率で月間リクエスト数に換算しています。
このグラフのデータ
[
{
"label": "10k requests",
"uncached_usd": "400.00",
"cached_usd": "86.00",
"saved_usd": "314.00"
},
{
"label": "100k requests",
"uncached_usd": "4,000.00",
"cached_usd": "860.00",
"saved_usd": "3,140.00"
},
{
"label": "1M requests",
"uncached_usd": "40,000.00",
"cached_usd": "8,600.00",
"saved_usd": "31,400.00"
}
]月間 10,000 件のリクエストでは、$314.00 を節約できます。これは、$400.00 と $86.00 の差額です。100,000 件では $3,140.00 の節約になります。100 万件では、キャッシュなしの入力料金が $40,000.00 となり、そのうち $31,400.00 がキャッシュによって削減されます。ここで示しているのは入力トークンの料金だけです。出力は別途課金され、キャッシュによる影響もありません。誰かに請求額を 90 パーセント削減できると約束する前に、この点を覚えておいてください。キャッシュは、VPS 上で AI エージェントの請求額を管理するための、より広い運用上の習慣と併用するものです。
キャッシュが機能していることを確認する方法
設計を信用するだけでは不十分です。レスポンスの usage ブロックを確認してください。すべての Messages API (application programming interface) の応答には、書き込んだキャッシュ済みトークン数、読み込んだキャッシュ済みトークン数、処理が必要だった新規トークン数が記録されます。
from anthropic import Anthropic
client = Anthropic()
resp = client.messages.create(
model="claude-opus-5",
max_tokens=512,
system=[
{
"type": "text",
"text": POLICY_DOCUMENT,
"cache_control": {"type": "ephemeral"},
}
],
messages=[{"role": "user", "content": question}],
)
u = resp.usage
print("write:", u.cache_creation_input_tokens)
print("read: ", u.cache_read_input_tokens)
print("fresh:", u.input_tokens)同じドキュメントと異なる質問を使って、2 回実行します。1 回目の呼び出しでは cache_creation_input_tokens が 0 ではなく、cache_read_input_tokens は 0 になります。2 回目は、プレフィックスが見つかるため、この結果が逆になります。input_tokens は最後のブレークポイントより後にあるトークンだけを数えます。そのため、正常な 2 回目の呼び出しでは小さい値になり、通常は新しい user message だけが対象です。Claude API には無料枠がないため、どちらの呼び出しにも料金が発生します。ただし、上記の 20,000 token のプレフィックスでは、2 回分の料金は約 14 セントです。
保存済みのリクエストボディを request.json に対して使用し、shell から同じ確認を行う場合は次のようにします。
curl -s https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d @request.json | jq '.usage'正常な 2 回目の呼び出しでは、次のような内容が出力されます。
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}1 行が事実を示します。呼び出しを繰り返しても cache_read_input_tokens が 0 のままなら、毎回 1.25x の書き込み料金を支払っているにもかかわらず、キャッシュから何も取得できていません。
1 hour の有効期間では、ブレークポイントに time to live (TTL) が設定されます。
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}自動キャッシュも利用できます。リクエストのトップレベルに cache_control フィールドを 1 つ指定すると、API が会話の進行に応じてブレークポイントを管理します。これは 4 つあるブレークポイントスロットのうち 1 つを使用します。まずはこれを使ってください。境界を正確に決める必要がある場合は、明示的なブレークポイントに切り替えます。
ヒット率を低下させる順序のルール
キャッシュは、リクエストの先頭からバイト単位でプレフィックスを照合します。リクエストは、tools、system、messages の順に固定された順序で組み立てられます。どの階層でも変更があると、その階層と後続のすべてが無効になります。1 つのツールの説明を編集すると、変更していない system prompt とメッセージ履歴全体も無効になります。
ここから、例外のない 1 つのルールが導けます。呼び出しごとに変わるものは、変わらないものより後に置く必要があります。
典型的な原因は timestamp です。system prompt の先頭に Current time: 2026-08-03T14:07:11Z と読む行があると、ヒット率は 0 パーセントになります。呼び出しごとにプレフィックスハッシュが変わるため、それより前のエントリが一致することはありません。これを末尾の user message に移します。セッション識別子やリクエストごとの nonce も同じようにキャッシュを破壊するため、同じ方法で修正します。リクエストごとに異なる取得済みドキュメントも、キャッシュ済みブロックの後に置く必要があります。そうしないと、安定したトークンがすべて、移動する境界の後ろに押し出されます。
2 つ目の原因は、変更されるブロックにブレークポイントを置くことです。キャッシュへの書き込みはブレークポイントで行われます。そのため、そのブロックが毎回異なると、安定した内容が保存されません。lookback で見つかるのは、過去のリクエストがそれぞれ異なるブレークポイントに書き込んだエントリだけです。リクエスト間で内容が同一である最後のブロックに cache_control を置きます。
3 つ目は、prompt の内容だと考えていなかったパラメータの変更です。モデルが異なると、キャッシュも異なります。tool_choice を変更すると、tools と system prompt はキャッシュされたままですが、メッセージ履歴は無効になります。ツールを追加または削除すると、すべてが無効になります。
最小プレフィックスと、通知されない何もしない動作
モデルの最小長より短いプレフィックスはキャッシュされません。これを知らせる表示もありません。エラーも警告も発生しません。リクエストは成功し、両方のカウンターは 0 になります。2026 年 10 月時点で公開されている最小値は次のとおりです。
- Claude Opus 5、Claude Fable 5、および新しい Opus 5.5、Sonnet 5.5、Fable 5.1、Haiku 5.5 では 512 tokens
- Claude Sonnet 5 と Claude Opus 4.8 では 1,024 tokens
- Claude Haiku 4.5 では 4,096 tokens
キャッシュされるはずのリクエストで両方のカウンターが 0 になった場合は、まずプレフィックスの長さを確認してください。これが、キャッシュを使用する処理では最安のモデルが必ずしも最も安価とは限らない理由でもあります。Haiku 4.5 でキャッシュを有効にするには、Opus 5 の 8 倍の長さのプレフィックスが必要です。そのため、2,000 tokens のシステムプロンプトは一方ではキャッシュされますが、もう一方では通知なく無視されます。
Claude Code がキャッシュする範囲と、できないこと
Claude Code は自身のプレフィックスをキャッシュします。システムプロンプトとツール定義はすべてのリクエストの先頭にあり、変化しないため、1 回だけ書き込まれ、その後のセッションでは読み戻されます。そのため、長時間のセッションでは、1 ターンあたりのコストがコンテキストサイズから想定される値を大きく下回ります。この動作は、Claude Code がトークン使用量を報告する方法で説明するカウンターにも現れます。
コンテキストの先頭付近を変更しても、キャッシュは役立ちません。会話履歴は追記専用であるため、通常の新しいターンでは、すでにキャッシュされたプレフィックスが拡張されます。セッションの早い段階で読み込んだファイルを編集しても、以前の読み込み結果を書き換えるのではなく、ファイルが変更されたという注記を Claude Code が追記するため、この仕組みは壊れません。一方、モデルを切り替えると各モデルが独自のキャッシュを持つため、キャッシュが無効になります。ツールがプレフィックスに読み込まれる MCP server への接続でも無効になります。会話の compact でも同様です。これらの操作を行うと、次のターンでプレフィックスが再度書き込まれます。長時間アイドル状態にしても同じです。エントリの有効期限が切れ、次のターンで全体を書き込む必要があるためです。これはバグではありません。いずれも、プレフィックスの規則どおりの動作です。
自分でクライアントを作成する場合は、後から対応するのではなく、最初のリクエストからこの配置を適用してください。VPS 上で最初の Claude API アプリを作成する方法と同じように、安定したブロックを先に置き、変動するブロックを最後に配置して呼び出しを構築します。
障害のパターンと確認できる内容
すべての呼び出しが write になる。 すべてのリクエストで cache_creation_input_tokens が non-zero になり、cache_read_input_tokens は 0 のままです。ブレークポイント以前のどこかで、呼び出しごとに内容が変化しています。組み立てた prefix の先頭 200 文字を連続する 2 回のリクエストで出力し、目視で比較してください。
両方のカウンターが 0 になる。 prefix がモデルの最小長に達していないか、cache_control フィールドが API に到達していません。まず prefix のトークン数を数え、次に実際に送信したリクエスト本文をログに記録してください。
読み取りが機能した後に停止する。 ヒットが連続し、その後に write が発生し、再びヒットします。リクエスト間の間隔が有効期間を超えています。write を受け入れるか、ヒット率が 53 percent を超えることを確認したうえで 1 hour TTL に変更してください。read が 0.05x または 0.025x のモデルでは、目安は約 51 percent です。
デプロイ後にヒット率が低下する。 ツールの説明を編集したか、モデルを変更しています。どちらの場合も prefix 全体が無効になります。プロンプトに影響するデプロイのたびに、コストの高い write が 1 回分発生すると考えてください。
キャッシュを有効にした後、請求額が増えた。 ヒット率が損益分岐点を下回っています。5 minute cache では約 22 percent 未満の場合、prefix をキャッシュせずに送信するほうが安価です。1 hour cache では約 53 percent 未満の場合も同様です。read が安価なモデルでは、その境界は約 20 to 21 percent と 51 percent です。
FAQ
プロンプトをキャッシュして採算が取れるのは、何回再利用した場合ですか？
5 minute キャッシュなら、1 回です。書き込みは通常、ベース入力の 1.25 倍で、読み取りは多くのモデルで 0.1 倍です。そのため、N 回のキャッシュなしリクエストは N のコストになります。一方、N 回のキャッシュ付きリクエストは、1.25 + 0.1 × (N - 1) です。両者が交差するのは N = 1.28 なので、2 回目のリクエストですでに有利になります。読み取りが 0.05 倍または 0.025 倍のモデルでは、交差点は N = 1.26 です。結論は同じです。1 hour キャッシュは書き込みが 2 倍で、交差点は N = 2.11 です。読み取り料金が安いモデルでは約 2.05 なので、2 回の読み取りが必要です。
cache_read_input_tokens が常に 0 なのはなぜですか？
まずプレフィックスの長さを確認します。モデルの最小長未満の場合、2026 年 10 月時点では Claude Opus 5 が 512 tokens、Claude Haiku 4.5 が 4,096 tokens で、キャッシュは暗黙にスキップされ、両方のカウンターが 0 になります。プレフィックスが十分に長い場合は、ブレークポイント以前またはその位置に、呼び出し間で変化する内容がないか確認します。例えば、system prompt 内の timestamp や session identifier です。カウンターが動作していたのに停止した場合は、リクエスト間の間隔がキャッシュの有効期間を超えています。
プロンプトキャッシュによって Claude の回答は変わりますか？
いいえ。キャッシュには、すでに送信した tokens の処理済み形式が保存されます。モデルが受け取る prompt は、キャッシュの有無にかかわらず同じです。これは動作を変える機能ではなく、料金とレイテンシーに関する機能です。そのため、動作している prompt に有効化しても、評価を再実行する必要はありません。
1 hour キャッシュに料金を払うべきですか？
5 分を超える空白がトラフィックにあり、ヒット率がなおおよそ 53% を超える場合に限ります。読み取り料金が安いモデルでは、約 51% が目安です。キャッシュミス時の 2 倍の書き込み料金は、1.25 倍の書き込み料金の 4 倍です。1 hour キャッシュへの書き込みがキャッシュミスになると、プレフィックスのベース入力料金全額が無駄になります。一方、5 minute キャッシュへの書き込みで無駄になるのは、その 4 分の 1 だけです。5 minute のエントリはヒットするたびに有効期間が更新されます。そのため、安定したトラフィックがあれば、より長い有効期間の料金を支払わずに、読み取り料金だけでキャッシュを維持できます。