Prompt Cache の書き込みコスト：1.25x はいつ元が取れるか
目次
Prompt Cache への書き込みは、TTL 内で一度再読されれば元が取れる。書き込みは input 単価の 1.25x、読み出しは 0.1x で課金されるため、2 回の call の合計は、一度 hit するだけで 25% の割増から 32.5% の削減に変わる。それでも、agent suite の 5 つの scenario のうち 1 つでは、同じ割増によって実測で 6% の損失が出た。差を決めるのは traffic の read:write 比率という 1 つの数値だ。この記事では、請求書が届く前にその比率を測る方法を扱う。以下の結果はすべて Synthorai gateway 経由で、実際の billing meter を使って測定した。agent の数値は 150 episode の suite、TTL と clustering の結果は salt を付けた専用 probe によるものだ。
TL;DR
- 明示的な cache 書き込みは 1.25x（5 分 TTL）または 2x（1 時間）で課金される。GPT-5.6 の breakpoint も同じ 1.25x／0.1x に収束しており、一度再読されれば損益分岐点を超える。
- agent suite 全体では、割増分の正味の効果が +6%（RAG、read:write 0.2）から -83%（batch、15.7）まで開いた。
- cache hit は Claude の TTL を無料で更新する。traffic が途切れなければ、書き込み料金が発生するのは TTL の window ごとではなく、idle gap ごとに一度だけだ。
- 暗黙的 caching の hit 率には大きな差がある。GPT-5.5 は 1 回の priming 後に 8 回中 7 回の hit を維持した一方、Gemini は clustering しても 12 回中 1〜3 回だった。どちらも書き込みの割増はない。
cache 書き込みには実際いくらかかるのか？
比較対象の provider には 3 種類の pricing 方式があり、そのうち 2 種類は書き込みに課金する。Claude の明示的 caching では、cache 作成が標準の 5 分 TTL なら input 単価の 1.25x、1 時間 tier なら 2x で、読み出しは 0.1x になる。GPT-5.6 は明示的な breakpoint に移行したが、書き込み 1.25x、読み出し 0.1x と同じ multiplier を採用している。業界最大の明示的な実装 2 つは、同じ pricing になった。3 つ目は暗黙的 caching（Gemini、Kimi、5.6 より前の OpenAI model）だ。書き込みの割増はなく、provider 側で hit した読み出しだけが割引される。
明示的な書き込みの損益分岐は簡単に計算できる。P token の prefix を cache しない場合、通常単価で P かかる。cache すると最初の call は 1.25P となり、TTL 内の再読は毎回 P ではなく 0.1P になる。一度再読されれば、2 回の call の合計は cache なしの 2P に対して 1.35P となり、32.5% の削減になる。それ以降は hit のたびに prefix コストを 90% 削減できる。risk は割増自体ではない。一度も再読されない block を書き込むことだ。この risk は workload の特性によって決まる。
書き込みの割増で損をするのはいつか？
prefix の繰り返しより変更のほうが速い場合だ。5 つの agent scenario で read:write token 比率を測定した。model と marker の付け方はすべて同一である。そのうえで、書き込み 1.25x、読み出し 0.1x として caching の正味の効果を計算した。
| Scenario | Read:write ratio | Net effect vs no caching |
|---|---|---|
| Batch（固定の instruction、多数の job） | 15.7 | prefix 支出を -83% |
| 長い chat（増え続ける history） | 6.8 | -75% |
| Tool loop／tooling | 5.4 | -72% |
| RAG（取得した document を prefix に配置） | 0.2 | +6%：caching のほうが高い |
| Suite 全体 | 3.5 | -64% |
特に押さえるべきなのは RAG の行だ。取得する document は query ごとに異なるため、各 call が次の call では再利用できない prefix を毎回書き直していた。読み出した token 1 に対して書き込んだ token は 5 で、1.25x の割増が積み重なり、最終的に損失となった。設定ミスではない。この workload では、書き込みコストを回収できないだけだ。対策は caching 自体をやめることではなく、layer を分けることだ。query 間で固定される system prompt と tool definition に mark を付け、取得した document は最後の breakpoint より後ろに置いて mark を付けない。同じ考え方は、timestamp、user name、request ごとの context など、変化しやすい内容すべてに当てはまる。prefix を暗黙に無効化する設定にも注意が必要だ。turn 間で output_config.effort を変更すると prompt が再描画されて cache が無効になるため、cache を使う session 内では effort を一定に保つ必要がある。LangChain の調査でも、framework 側で同じ失敗を確認した。正しい箇所だけでなく、すべてに簡単に mark を付けられる builder が原因だった。
書き込み料金は実際にはどの頻度で再発生するのか？
TTL の window ごとではなく、idle gap ごとに一度だ。hit が TTL を無料で更新するためである。Claude Opus 4.8 に salt 付きの 4,981-token prefix を送り、この挙動を確認した。
| Call | Timing | Cache write | Cache read |
|---|---|---|---|
| 1 | t=0 | 4,981 | 0 |
| 2 | +3 min | 0 | 4,981 |
| 3 | +6 min | 0 | 4,981 |
| 4 | +9 min | 0 | 4,981 |
| 5 | after 7 min of silence | 4,981 | 0 |
call 4 は最初の 5 分 TTL を大きく過ぎているが、問題なく読み出せている。call 2 と 3 がそれぞれ無料で window を更新したためだ。再書き込みが必要になったのは、7 分間 traffic が途切れた後だけだった。実運用では、request 間隔が TTL を下回る route なら、書き込みの割増は一度しか発生しない。5 分 tier は実質的に無期限の cache として動作する。1 時間 tier は別の traffic 向けだ。gateway 経由の billing で、2x の書き込みが専用の ephemeral_1h_input_tokens bucket に入ることも確認した。1.25x を繰り返し払う代わりに 2x を一度だけ払うため、再書き込みを 1 回でも回避できれば有利になる。idle gap が 5 分から 1 時間の route に適している。1 時間を超えて traffic が途切れる場合は、どちらの tier でも次の run まで cache は残らない。scheduled job は 1 run の内部で何が起きるかを基準に見積もる。1 request だけ送る cron は、書き込んでも効果がない。同じ prefix で多数の request を fan-out する cron は batch と同じであり、caching の挙動も同じになる。
traffic の形を変えれば暗黙的 caching を改善できるか？
provider によって異なる。best-effort の hit 率には大きな差がある。良好だった GPT-5.5 の automatic caching は、安定した仕組みとして機能した。1 回 priming すると 2 秒後には entry を読み出せた。試した両方の salt で、最初の probe が hit した。その後の burst では、5,170-token prompt のうち 4,864 token が 8 probe 中 7 回 cache から読み出され、書き込みの割増は一切発生しなかった。純粋なコスト削減であり、同じ prefix を 2 回送る以外に何も必要ない。反対側に位置するのが Gemini 3.6 Flash だ。明示的 caching が Claude の input token の 77〜78% を処理した同じ agent suite で、Gemini の暗黙的 cache が処理したのは 4%だった。実際に prefix が繰り返される workload での結果である。
hit 率が低い側を traffic shaping で改善できるかも試した。同じ prefix の call をまとめて送り、provider の cache が warm な間に処理させる方法だ。Gemini 3.6 Flash に 12 回連続で call したところ、hit は 1 回だけだった。call 10 が hit し、call 11 は再び miss した。3 分間隔で 8 回送った場合は、hit が 0 回だった。偶然の可能性を考え、別の独立した request path と Gemini 3.5 Flash でも clustered arm を再実行した。結果はそれぞれ 12 回中 3 回と 1 回の hit で、長く連続することはなかった。ただし、一度 cache された block は、両方の path で同じ 4,073 token として返った。仕組みの動作には一貫性があるが、hit の確率は安定しない。
miss の一部は ingestion lag によるもので、その長さは provider ごとに異なる。GPT-5.5 の entry は prime から 2 秒後に読み出せたが、Gemini は構築に数十秒かかる。そのため、最初の call の直後に burst を送ると cache の構築が間に合わない。すべての測定で、Gemini が 4 回目の call より前に hit した arm はなかった。prefix を一度 prime し、45 秒待ってから burst を送ると 8 回中 3 回 hit し、traffic shaping では最高の結果となった。一方、90 秒待つと 8 回すべて miss した。戻った時点ですでに entry が消えていた。数日前に同じ model で長めの warm-up sweep を実行した際は hit が続いたため、時間や load によって hit 率自体も変動する。構築の遅さ、短い lifetime、hit 率の変動を考えると、低調な実装で clustering を使う効果は、1 回より 3 回 hit するほうがましという程度だ。（testing 上の注意として、暗黙的 cache の probe では call に間隔を空け、prime-and-wait arm も用意する。post-prime ladder で構築時間自体も測る必要がある。連続した probe で測っているのは cache ではなく request rate だ。）
実用上の判断は mechanism 単位ではなく、provider 単位で行うべきだ。利用中の provider の暗黙的 cache が GPT-5.5 型なのか、Gemini 型なのかを測る。GPT-5.5 型なら prime 後は信頼できる。Gemini 型なら、hit は rebate として扱う。Kimi K3 はその中間にある。割増はなく、小さな最低条件があり、設定なしでもinput の 57〜62% が cache から処理された。どちらの方式が優位かを示す事例もある。測定した中で最も優秀な暗黙的 cache を持っていた OpenAI でさえ、GPT-5.6 では明示的な breakpoint に移行した。provider 側の運に左右されない rebate から、customer が制御できる mark に切り替えたことになる。
どの workload なら割増を回収できるか？
read:write 比率と idle gap を基準に判断する。どちらも導入前に自社の usage record から確認できる。
| Workload | Verdict | Why |
|---|---|---|
| Multi-turn agent session | Cache する | turn ごとに history を再読する。suite 全体の実測 R:W は 3.3〜3.6 |
| 共通の system prompt、安定した QPS | Cache する、5m tier | request 間隔が TTL 未満なら書き込みは一度だけで、その後は無料で更新される |
| 5〜60 分の gap がある burst 型 session | Cache する、1h tier | gap ごとに 1.25x を払うより、2x を一度払うほうが安い |
| 同じ instruction を使う batch job | Cache し、job を cluster 化する | 実測 R:W 15.7、-83%。clustering で window を warm に保てる |
| 変化する document を使う RAG | layer を分ける | instruction／tool だけに mark を付け、document は最後の breakpoint より後ろに置く |
| run ごとに 1 request の scheduled cron | 使わない | run の間隔が数時間あるため、書き込みは毎回未読のまま失効する |
| run ごとに多数の request がある scheduled cron | run 内で Cache する | run は batch と同じ。最初の request が書き込み、残りが読み出す。hit により run 中は TTL が維持される |
| cache 最低条件未満の prompt | 使わない | model ごとの cache 最低条件を下回ると、そもそも cache されない |
meter から得られた結論は 2 つある。1 つ目は、caching の効果を体感上の hit 頻度ではなく、自社の usage 内訳にある cache_read と cache_creation で判断することだ。RAG scenario は cache と相性が良さそうに見えたが、実測値は 0.2 だった。2 つ目は、比率が良好なら割増は誤差に埋もれるということだ。suite 全体の read:write 比率 3.5 では、支払ったすべての書き込み料金を含めても、prefix 支出は 64% 減少した。
FAQ
RAG で Prompt Cache を使う価値はあるか？
取得した document にはない。測定では、RAG は読み出し 1 token に対して 5 token を書き込み、1.25x の割増によって正味 6% の損失となった。固定 layer である system prompt と tool definition だけを cache し、取得した content は最後の breakpoint より後ろに置く。caching の完全ガイドで prompt の layer 分けを詳しく説明している。
5 分と 1 時間の cache TTL はどちらを使うべきか？
session の長さではなく idle gap で決める。hit は 5 分 TTL を無料で更新するため、request 間隔が 5 分未満の route は再書き込みが発生せず、安価な tier が実質的に無期限で動作する。idle gap が 5 分から 1 時間の場合だけ、書き込み 2x の 1 時間 tier を使う。1.25x の再書き込みを 1 回回避するだけで有利になる。gap が 1 時間を超えるなら、cache なしとして予算を組む。
暗黙的 caching に書き込み料金はかかるか？
かからない。構造上、かけることもできない。書き込みの割増は caller が明示的に opt-in する場合にしか成立しないため、割増があるのは明示的 caching だけだ。具体的には Anthropic の 1.25x／2x multiplier、GPT-5.6 の breakpoint、Gemini の token-hour 単価のように storage rent を課す明示的 cached-content API が該当する。測定したすべての暗黙的実装（Gemini、Kimi、5.6 より前の OpenAI）と、主要な公開 rate card（DeepSeek、Qwen、Grok）では、暗黙的 caching は割引された読み出しだけに課金される。異なるのは信頼性だ。GPT-5.5 の暗黙的 cache は、prime 済み probe 8 回中 7 回の hit を維持した。一方、Gemini が agent suite で処理した input は 4% で、clustering を使ってもほとんど改善しなかった。確実に受け取れる割引に割増がないなら、それが最良だ。ランダムにしか得られない割引は、自分で制御できる小さな割増より価値が低い。
2026-07-25 から 2026-07-29 に Synthorai gateway 経由で測定：scenario の read:write 比率は、call ごとの cache 内訳を取得した Claude arm の agent episode 150 件から算出（Gemini と Kimi の比率はそれぞれの suite run による）。TTL 更新と 1 時間 bucket の probe は claude-opus-4-8 で実施（salt 付きの 4,981-token および 3,742-token prefix）。暗黙的 cache の probe は gemini-3.6-flash と gemini-3.5-flash（salt 付きの約 6,800-token prefix、clustered、spread、prime-and-wait の各 arm）、および gpt-5.5（salt 付きの 5,170-token prompt、primed burst）で実施。正味の効果は、実測比率に書き込み 1.25x／読み出し 0.1x の multiplier を適用して算出した。rate と cache の挙動は変わる可能性があるため、自社の usage record で確認すること。