すべてのリクエストが同じ10,000トークンのシステムプロンプトを送っています。同じコーディング標準。同じfew-shot例。同じツール定義。そのすべてに全額の入力価格を支払っています。GPT-5.5を入力$5/Mで毎日500リクエストなら、1日$25——月$750——それはモデルがすでに500回処理したコンテンツのためだけに。
プロンプトキャッシュでこれを月$75に下げられます。同じコンテンツ。同じ出力品質。コード変更は1箇所。プロンプトキャッシュは、コスト最適化ウォークスルーで扱う12戦略の1つです——そして最小のコード変更で最高のROIを実現します。
この記事は、4大プロバイダーすべてでのキャッシュの仕組み、実装の正確なコード、ワークロードがキャッシュ向きかどうかの診断方法を扱います。これはTokSpanブログ全体のプロンプトキャッシュの権威あるリファレンスです——他の記事は詳細な実装のためにここにリンクしています。
プロンプトキャッシュの仕組み（そして銀の弾丸でない理由）
プロンプトをLLMに送ると、モデルはすべてのトークンを処理します——何百回も見たことのあるトークンでさえも。計算はすべてのリクエストで繰り返されます。それらのトークンをキャッシュすれば、モデルは冗長な計算をスキップします。
仕組み： プロンプトの一部をキャッシュ可能としてマークします。プロバイダーはその部分をハッシュします。同じプレフィックスを持つ後続リクエストでは、プロバイダーは再計算する代わりにキャッシュ済み計算を取り出します。キャッシュ済みトークンには割引レートを支払います——一部のプロバイダーでは、キャッシュ部分に推論コストがかかりません。
キャッシュできるもの： システムプロンプト（最も一般的で最高ROIのユースケース）。ツール定義——リクエスト間で同一。few-shot例。静的ドキュメントコンテキスト——製品ドキュメント、ナレッジベース記事、コーディング標準。最新メッセージまでの会話履歴——履歴は最新のユーザーメッセージまで同一。
キャッシュできないもの： ユーザーの新しいメッセージ——プロンプトの末尾にあり、リクエストごとに一意。非決定的プレフィックス——リクエスト間で変わるもの。プロバイダーの最小キャッシュ長（通常1,024トークン）未満のコンテンツ。
注意点： キャッシュは失効します。TTLは5分（Anthropic、OpenAI）から設定可能な時間（Google）まで。リクエスト間隔がTTLを超えると、キャッシュはコールドになり、全額を支払います。キャッシュはプロバイダー固有・モデル固有でもあります——OpusからSonnetに切り替えるとキャッシュが無効になります。
プロバイダー別実装
Anthropic——90%オフ、業界最高、明示的制御。
Anthropicは業界最高のキャッシュ経済を提供します：キャッシュ済み入力トークン90%オフ。Anthropicのプロンプトキャッシュドキュメントがキャッシュブレークポイント、TTL動作、価格を詳細に説明しています。キャッシュ書き込みは基本入力価格よりわずかに割増です（下の価格内訳参照）。損益分岐：キャッシュ書き込み1回あたり約1.3総リクエスト——キャッシュ済みプレフィックスを共有するリクエストが2つだけでも約32.5%節約。大半の本番ワークロードでは、数十回になります。キャッシュ付きAnthropic SDKの設定の完全ウォークスルーは、Claude API開発者ガイドをご覧ください。
import anthropic
client = anthropic.Anthropic(
base_url="https://api.tokspan.com/anthropic",
api_key="ts-your-key-here"
)
response = client.messages.create(
model="claude-opus-4-8",
max_tokens=1000,
system=[
{
"type": "text",
"text": "You are a code reviewer. Here are our 10,000-token coding standards...",
"cache_control": {"type": "ephemeral"} # Cache this
}
],
messages=[{"role": "user", "content": "Review this PR."}]
)キャッシュブレークポイント。 メッセージ全体に複数のcache_controlブロックを配置できます。それぞれが、そこまでのプレフィックスがキャッシュされるポイントをマークします。戦略的な配置：システムプロンプトをキャッシュ（常に）。最後のユーザーメッセージを除く会話履歴をキャッシュ（履歴は静的、新しいユーザーメッセージは動的）。ツール定義をキャッシュ（めったに変わらない）。
最小キャッシュ長： Opus 4.5+（Opus 4.8/4.7/4.6/4.5含む）とHaiku 4.5は4,096トークン；Sonnet 4.6は2,048トークン。これより短いプロンプトはキャッシュされません——キャッシュ管理のオーバーヘッドが計算節約を上回るからです。
OpenAI——50%オフ、自動、ゼロ労力。
OpenAIのプロンプトキャッシュは1,024トークン超のプロンプトで自動です。コード変更不要。cache_controlブロック不要。プロバイダーが繰り返しプレフィックスを検出し、黙って割引を適用します。トレードオフ：Anthropicの90%に対して50%割引、そしてキャッシュヒットの保証なし——キャッシュするかはプロバイダーが決めます。
# No special code needed. OpenAI automatically caches repeated prefixes.
response = client.chat.completions.create(
model="gpt-5.5",
messages=[
{"role": "system", "content": "Your 5,000-token system prompt here..."},
{"role": "user", "content": "User message here."}
]
)
# If the system prompt was cached, you pay 50% less for those input tokens.
# Check response.usage for cache status.Google Gemini——コンテキストキャッシュ、明示的、TTL設定可能。
Googleのアプローチは異なります：明示的なTTLを持つ「cached content」リソースを作成します——Googleのコンテキストキャッシュドキュメントが設定と価格を説明しています。TTLは数分から24時間まで。リクエストでキャッシュ済みコンテンツを参照します。キャッシュは複数リクエスト・複数ユーザーにわたって持続します。最適：複数ユーザーが照会する静的コンテンツを持つ文書Q&A。
DeepSeek——キャッシュヒット$0.0036/M、自動、絶対最安。
DeepSeekのキャッシュヒット価格は100万トークンあたり$0.0036——すでに安い基本レートより40倍安い。キャッシュは自動（OpenAIと同様）。明示的制御なし。しかしこの価格では、繰り返しコンテンツを持つほぼすべてのワークロードで経済的に有利です。
キャッシュ価格：実際の節約
| プロバイダー | キャッシュ書き込み | キャッシュ読み取り | ベース入力比 | TTL | 自動? |
|---|---|---|---|---|---|
| Anthropic | ベース価格の1.25倍 | ベース価格の10% | 90%割引 | ~5 min | なし（明示的） |
| OpenAI | — | ベース価格の50% | 50%割引 | 5–60 min | はい |
| Google Gemini | TTLにより変動 | TTLにより変動 | 最大75%割引 | 設定可能 | なし（明示的） |
| DeepSeek | — | $0.0036/M | 約97%割引 | ~5 min | はい |
選択ガイド。 素の価格だけでなく、各プロバイダーのキャッシュ実装にはアーキテクチャ上のトレードオフがあります。Anthropicは明示的制御と最大の割引を提供します——ただし25%のキャッシュ書き込み割増を払い、ブレークポイント配置を自分で管理する必要があります。OpenAIはfire-and-forget：ゼロコード、50%節約、キャッシュヒットの保証なし。Googleの設定可能TTLは唯一無二：製品ドキュメントに24時間キャッシュを設定し、1つのキャッシュ済みリソースに対して数千のユーザーにサービス提供できます。DeepSeekの絶対価格下限（キャッシュ済みトークン100万あたり$0.0036）は、キャッシュヒット率の最適化をほぼ無関係にします——その価格では、10%のヒット率でもお金を節約できます。
| プロバイダー | 最小キャッシュ長 | 工数 | 最適な用途 | 注意点 |
|---|---|---|---|---|
| Anthropic | 4,096 tokens (Opus 4.5+, Haiku 4.5); 2,048 (Sonnet 4.6) | 3行追加 | システムプロンプト、ツール定義、few-shot | 書き込みコスト1.25倍; 5分TTL |
| OpenAI | 1,024 tokens | なし | あらゆるワークロード、手軽な節約 | ヒット保証なし; 50%割引のみ |
| Google Gemini | モデルにより変動 | リソース作成 | ドキュメントQ&A、長いTTLニーズ | 長いTTLほどコスト高 |
| DeepSeek | ~1,024 tokens | なし | 高ボリューム、価格重視 | 自動のみ; 予測可能性は低め |
節約計算機。 1日500リクエスト、10,000トークンのキャッシュ済みシステムプロンプト、500トークンのユーザーメッセージ、Claude Opusを入力$5/Mで使用するワークロード：
- キャッシュなし：500 × (10,000/1,000,000 × $5) = キャッシュ対象コンテンツだけで1日$25
- キャッシュあり：500 × (10,000/1,000,000 × $0.50) = キャッシュ対象コンテンツで1日$2.50
- 年間節約：$8,212——そのコンテンツで$821。 コード変更は1箇所。
隠れたキャッシュ書き込みコスト。 Anthropicはキャッシュ書き込みに基本入力価格の1.25倍を請求します。損益分岐はキャッシュ書き込み1回あたり約1.3総リクエスト——つまりキャッシュ読み取りが1回だけでも（同じプロンプトを共有する2リクエスト）キャッシュなしと比べ約32.5%節約。すべてのリクエストで同一のシステムプロンプトとツール定義には、これは問題になりません。ほとんどのリクエストが一意（キャッシュ読み取りなし）のコンテンツでは、25%の書き込み割増を支払い、相殺する節約はゼロです。キャッシュヒット率を監視してください。>80%を目標に。
あなたのワークロードはキャッシュ向きですか？
キャッシュに最適なワークロード：
- 長いシステムプロンプトを持つチャットボット——プロンプトはすべてのユーザー・会話で同一。キャッシュヒット率：ほぼ100%。
- 静的ドキュメントコンテキストを持つRAGアプリケーション——ナレッジベースコンテンツは、それに対するすべてのクエリで同じ。キャッシュヒット率：照会する文書数によるが高い。
- few-shotプロンプトタスク——例はリクエスト間で同一。キャッシュしましょう。
- 長い履歴を持つマルチターン会話——最新メッセージまでの履歴は静的。最後のユーザーターン以外をすべてキャッシュ。
- ツール定義を持つコーディングエージェント——ツールスキーマは静的。キャッシュしましょう。
キャッシュに最悪のワークロード：
- 一回限りのプロンプト——すべてのリクエストが一意。繰り返しプレフィックスなし。キャッシュヒット率：0%。
- リクエストごとに一意な文書——すべてのクエリが別の文書に対するものなら、キャッシュするものがない。
- 非常に短いプロンプト（1,024トークン未満）——ほとんどのプロバイダーの最小キャッシュ長未満。
- 高ランダム性生成——すべての応答が創造的で制約なしなら、出力はキャッシュ不可（キャッシュは入力トークンについて）。
簡単な診断。 1日分のすべてのAPIリクエストの最初の2,000文字をログに記録します。同一の数を数えます。リクエストの>50%が1,000トークン超の共通プレフィックスを共有するなら、プロンプトキャッシュで大幅に節約できます。<20%なら、明示的キャッシュの実装労力を正当化するほどの節約はありません（自動キャッシュは受動的な節約を提供しますが）。
キャッシュヒット率診断：5分スクリプト
本番コードに触れる前に、ワークロードがキャッシュ向きか検証しましょう。直近1,000件のAPIリクエストに対してこのスクリプトを実行します。各リクエストのキャッシュ可能部分をハッシュし、重複率——少なくとも1つの他のリクエストとプレフィックスを共有するリクエストの割合——を報告します。
import hashlib
import json
from collections import Counter
# Load your request log —adapt the path and format to your setup
with open("api_requests.jsonl") as f:
requests = [json.loads(line) for line in f]
def get_cacheable_prefix(req):
"""Extract the static portion of each request.
For most applications this is the system prompt + any messages
before the final user turn."""
messages = req.get("messages", [])
prefix = messages[:-1] if len(messages) > 1 else messages
return json.dumps(prefix, sort_keys=True)
prefixes = [get_cacheable_prefix(r) for r in requests]
hashes = [hashlib.md5(p.encode()).hexdigest() for p in prefixes]
counts = Counter(hashes)
total = len(requests)
unique = len(counts)
most_common = counts.most_common(1)[0] if counts else (None, 0)
dup_rate = (total - unique) / total * 100 if total else 0
print(f"Total requests analyzed: {total}")
print(f"Unique prefixes: {unique}")
print(f"Most-repeated prefix: {most_common[1]} occurrences")
print(f"Duplication rate: {dup_rate:.1f}%")
if dup_rate > 70:
print("=> Cache-friendly. Implement explicit caching —high ROI.")
elif dup_rate > 40:
print("=> Borderline. Caching helps, but audit write costs first.")
else:
print("=> Not cache-friendly. Skip caching; use other optimizations.")数字があなたの請求に意味すること。 1日500リクエストの70%重複率、10,000トークンのシステムプロンプト、入力$5/Mなら、350リクエストがキャッシュの恩恵を受けます。Anthropicの90%割引で、キャッシュ済みトークンは$5/Mではなく$0.50/M——そのブロックだけで1日$15.75節約。OpenAIの自動50%割引なら、コード変更なしで1日$8.75節約。40%の重複率でも重要です：1日200リクエスト・10,000トークンでAnthropicでは1日$9節約。
リクエストログにアクセスできない？ LLMプロバイダーのダッシュボードは総リクエスト数とリクエストあたりの平均トークンを示します。アプリのMAUと照合します。固定5,000トークンのシステムプロンプトで100人のDAUにサービス提供していれば、100個の同一プレフィックスがあります。各ユーザーがセッションごとに一意の20ページ文書をアップロードするなら、重複率はほぼゼロ。ログを1行もスクレイピングせずに、ダッシュボードがあなたの属するバケットを教えてくれます。
プロンプトキャッシュがお金を食うとき
ほとんどの場合、プロンプトキャッシュはお金を節約します。しかし間違った条件では逆——多く払って何も得られません。キャッシュ制御を追加する前によく考えるべきシナリオを示します。
低ヒット率ワークロードでのAnthropicの書き込み割増。 Anthropicはキャッシュ書き込みごとに基本入力価格の1.25倍を請求します。キャッシュヒット率が20%を下回ると、書き込み割増が読み取り割引を上回ります。$5/M基本の10,000トークンキャッシュブロック：キャッシュ書き込みは$0.0625（1.25x）、キャッシュ読み取りは$0.005（0.1x）。損益分岐にはキャッシュ書き込み1回あたり約1.3総リクエストが必要——つまりキャッシュ読み取りが1回だけでも（同じプロンプトを共有する2総リクエスト）約32.5%節約。3リクエストごとにシステムプロンプトをローテーションするサポートボット（書き込み1＋読み取り2）はキャッシュなしと比べ約52%節約。Anthropicのusageレスポンスでcache_read_input_tokens対cache_creation_input_tokensを監視します。読み取り対書き込み比が0.5:1未満（書き込み2回あたり読み取り1回未満）なら、キャッシュブロックを削除します。
ストリーミング多用・一回限りワークロード。 リアルタイム文字起こし、一回限りのコード生成、創作——すべてのプロンプトが設計上一意。一意プロンプトのストリームにcache_controlブロックを追加すると、全リクエストにブロックあたり約20トークンが加わり、キャッシュヒットは決して返りません。OpenAIの自動キャッシュはこれらを黙ってスキップします（ヒットなし、課金なし）。しかしAnthropicの明示的cache_controlブロックは最初の出現で常に書き込みコストを発生させます。一意ワークロードでは、すべてのリクエストが最初の出現——相殺する節約ゼロで毎回25%割増を支払います。
最小閾値ちょうど下のプロンプト。 AnthropicはOpus 4.5+とHaiku 4.5に4,096トークン、Sonnet 4.6に2,048トークンを要求します。OpenAIは1,024トークン。Opusでcache_controlブロック付きの1,500トークンシステムプロンプトは、なしと同じコスト——4,096トークン最小値未満のため、プロバイダーは黙ってキャッシュ指示を無視します。cache_controlブロック1つで約20トークン追加。月500万リクエスト・入力$5/Mなら、その20トークンの無駄は月$500。キャッシュ制御を追加する前に、プロバイダーのトークナイザーで実際のトークン数（文字数ではなく）を確認しましょう。
クイックルール。 明示的キャッシュに投資するのは次のときだけ：(a)キャッシュ可能プレフィックスが1,024トークン超、(b)リクエストの50%超に出現、(c)リクエスト間隔の中央値がプロバイダーのTTL未満。いずれかの条件が失敗したら、自動キャッシュに任せるか、キャッシュを完全にスキップしてコスト最適化プレイブックの別の戦略を選びましょう。
キャッシュ戦略ガイド
階層。 明示的・高頻度キャッシュの最大節約はAnthropic。高ボリュームワークロードの絶対最安キャッシュ読み取りはDeepSeek。長時間TTLの文書キャッシュ（最大24時間）はGoogle。ゼロ労力の自動節約はOpenAI。
マルチプロバイダーキャッシュ戦略。 静的コンテンツは最良のキャッシュ経済を持つプロバイダー（Anthropic、90%オフ）でキャッシュします。キャッシュ向きトラフィックをそのプロバイダーにルーティング。一意リクエストはユースケースに最良の基本価格のプロバイダーにルーティング。これは高度な最適化です——最初に基本キャッシュを実装し、ルーティングは後で調整します。
プラットフォームレベルキャッシュ。 一部の集約プラットフォームはプロバイダーキャッシュの上に独自のキャッシュを重ねます。プラットフォームはAPIゲートウェイレベルでレスポンスをキャッシュします——プラットフォームキャッシュから提供される同一リクエストはプロバイダーに到達しません。繰り返しクエリパターンを持つ高ボリュームアプリケーションでは、節約が2倍になります。TokSpanのプロンプトキャッシュドキュメントは、キャッシュヒット分析とプロバイダー別節約追跡を含むプラットフォームレベルキャッシュの設定を説明しています。
FAQ
プロンプトキャッシュで実際にいくら節約できますか？
入力トークンで50〜90%、プロバイダーとワークロードによります。Anthropic（90%オフ）で入力トークンの80%がキャッシュされれば：実効入力コストは約72%低下。月$1,000の入力支出なら、月$280——月$720の節約。
コードを変える必要がありますか？
OpenAIとDeepSeek：いいえ、キャッシュは自動です。Anthropic：はい、cache_controlブロックを追加します（3行）。Google：はい、cached contentリソースを作成します。実装労力は節約に比例します——Anthropicは最もコードが必要ですが最高の割引を提供します。
キャッシュはどれくらい持ちますか？
Anthropic：約5分。OpenAI：5〜60分（変動、保証なし）。Google：TTL設定可能（数分から24時間、長いTTLほど高コスト）。DeepSeek：OpenAIと同様。リクエスト間隔が5分未満のアプリケーションでは、キャッシュは自動で機能します。頻度の低いアクセスパターンでは、Googleの設定可能TTLだけが役立ちます。
同じプロバイダーの別モデル間でキャッシュを共有できますか？
一般的にはいいえ。キャッシュはモデル固有です。OpusからSonnetに切り替えるとキャッシュが無効になります。本番では特定のモデルバージョンに固定して、キャッシュヒット率を最大化しましょう。
会話の途中でキャッシュが切れたらどうなりますか？
影響を受けるトークンは全額価格に戻ります——エラーなし、中断なし、その1リクエストのコストが高くなるだけ。ユーザー体験は影響を受けません。キャッシュ失効はコストイベントであり、信頼性イベントではありません。低リスク、高リターン。
プロンプトキャッシュは、ほぼコードなしで最大90%の節約を実現します——インフラにおける珍しい無料の昼食。しかし無料の昼食は値付けされる歴史があります。キャッシュがあらゆるプロバイダーで標準になるにつれ、本当の問いは、今日の割引が次の価格サイクルを生き残るか、それとも節約がより高い基本レートに静かに組み込まれる一方、マーケティングは同じままか、です。
割引ウィンドウが閉じても、問いはキャッシュ実装の価値があったかではありません——90%オフの入力トークンを6か月でも節約できれば、有効化に使った3行のコードを十分に正当化します。TokSpanでプロンプトキャッシュを設定し、経済性がこれほど有利なうちに、全プロバイダーの組み込み割引の上にプラットフォームレベルキャッシュを重ねましょう。