LLM APIのプロンプトキャッシュでコストを削る｜割高になりやすい設定と最適化のコツ

プロンプトキャッシュとは、繰り返し送る入力の先頭をサーバー側に保持し、再送時の課金を割り引く仕組み。

キャッシュを有効にしたのに請求書の金額が下がらない。あるいは、入れる前より高くなった。LLM APIを本番で回していると、この逆転は起こり得ます。原因は「キャッシュ＝安くなる」という思い込みと、AnthropicやGPT-5.6以降のOpenAIではキャッシュ書き込みが通常入力より割高だという事実のズレにあります（OpenAIでもGPT-5.6より前は書き込みの追加料金はありません）。書き込みだけ払って読み出しの割引を取り逃す構造を放置すると、削減どころか割高化するわけです（プロバイダが誤って多く請求しているのではなく、正規料金の結果としての設計上のコスト増です）。

本記事のコードや料金・仕様は概念理解のための最小例です。料金体系とトークン閾値は更新が速いため、実装時は各社の公式ドキュメントで最新値を必ず確認してください（この注記は以降繰り返しません）。数値はAnthropicとOpenAIの公式ドキュメントの2026年7月時点の記載に基づきます。

プロンプトキャッシュを入れたのに請求が下がらない症状

まず、どういう見え方になるか。ダッシュボードのトークン消費は増えていないのに、月末のAPI請求だけが想定より膨らむ。あるいはキャッシュ対応のコードを入れた直後から、1リクエストあたりの単価がわずかに上がった。ログを見るとキャッシュへの書き込みは発生しているのに、読み出しがほとんど記録されていない。こういう状態が典型的な症状です。

芯にあるのは、キャッシュ書き込みが通常の入力トークンより高い単価で課金される点。Anthropic公式によれば、5分間有効の書き込みは基本入力単価の1.25倍、1時間有効なら2倍。読み出しは0.1倍と大きく下がります。つまりキャッシュは「書いた瞬間に割高分を先払いし、後から読み出しで回収する」構造。読み出し（ヒット）が十分に発生しない使い方だと、割高な書き込み分だけを払い続けることになります。

「○%も無駄に払っている」といった具体的な削減率・割高率は出所が定まらないものも多く、本記事では核にしません。確かなのは公式の料金体系そのもの。書込は割高、読出は割安、そして両者の比率とTTLで採算が決まる、という機構を押さえておけば、自分の請求ログだけで判断できます。

キャッシュを「使うか使わないか」の二択で考えると、この非対称を見落とします。正しくは「再利用が見込める入力にだけ、正しい構造で効かせる」。ここを外すと、善意で入れた最適化が請求を押し上げる皮肉な結果になります。

キャッシュ課金の仕組み ― 書き込みと読み出しで単価が違う

課金の全体像を、Anthropic・OpenAI・Googleそれぞれの公式仕様で整理します。3社ともキャッシュの基本発想は同じですが、有効化の方法と料金の見せ方が違います。

キャッシュ対象になるには最小トークン数の条件があります。Anthropicの最小キャッシュ長はモデルと利用基盤で異なり、2026年7月17日時点の公式仕様では512〜4,096トークンです。Claude APIではFable 5が512、Sonnet 5・4.6・4.5とOpus 4.8が1,024、Opus 4.7が2,048、Opus 4.6・4.5とHaiku 4.5が4,096（Amazon BedrockではFable 5が1,024）。これを下回る短いプロンプトは、キャッシュ指定を書いてもキャッシュされず通常課金で処理されます。OpenAIのドキュメントでは、自動キャッシュの対象は1,024トークン以上。Googleは暗黙キャッシュの最小トークン数をモデル別に公開しており、2026年7月22日時点の公式ドキュメントではGemini 3.5 Flashと3.1 Pro Previewが4,096、2.5 Flashと2.5 Proが2,048（3.6 Flashと3.5 Flash-Liteはこの表に未掲載）。短い問い合わせを大量に投げるワークロードでは、そもそもキャッシュが1件も成立していない、という事態が起こり得ます。使うモデルの最小値は公式の料金・仕様ページで必ず確認してください。

Anthropic方式（自動／明示のキャッシュ指定とTTL）

Anthropicには2つの指定方法があります。1つはリクエスト最上位にcache_controlを置き、最後のキャッシュ可能ブロックを自動でキャッシュする自動方式。もう1つは、プロンプト内の区切り（ブレークポイント）にブロック単位でcache_controlを付け、そこまでを1つのキャッシュ単位として扱う明示方式です。TTLは標準の5分と、追加コストのかかる1時間から選べます。ブレークポイントは最大4個まで置けます。なお最上位cache_controlの自動方式はClaude API・Claude Platform on AWS・Google Cloud・Microsoft Foundryで使え、Amazon Bedrockでは明示方式を使います。

書き込みが割高なぶん、有効化する場所を選ぶ設計が前提。「毎回変わらない大きな塊」にだけ付けるのが基本です。明示指定は次のような形になります（messages.create()にはmax_tokensが必須です）。

# システム指示や共通コンテキストの末尾にブレークポイントを置く
message = client.messages.create(
    model="claude-sonnet-4-5",   # 利用中の対応モデルに置き換える
    max_tokens=1024,             # 必須
    system=[
        {
            "type": "text",
            "text": long_system_instructions,   # 毎回同じ大きな塊
            "cache_control": {"type": "ephemeral"}   # ここまでをキャッシュ
        }
    ],
    messages=[{"role": "user", "content": user_input}],  # 可変部は末尾
)

末尾の可変ブロックに自動でブレークポイントが置かれる自動方式は、毎回末尾が変わる構造だと書き込みだけが増えることがあります。その場合は、上のように固定部分の末尾へ明示ブレークポイントを置く方が適切です。

1時間TTLを使う場合は"cache_control": {"type": "ephemeral", "ttl": "1h"}のように指定します。呼び出し間隔が5分を超えるワークロードで、失効による書き直しを避けたいときの選択肢。ただし1時間TTLは書き込みが2倍単価になるため、割高分を回収できるだけの読み出し回数が見込めるかが判断基準になります。

OpenAI方式（自動キャッシュと世代別の課金）

OpenAIは基本的に開発者側の指定が要りません。1024トークン以上のリクエストで、過去に計算済みのprefix（先頭部分）と一致すれば自動でキャッシュが効きます。ただし料金と制御はモデル世代で分かれます。読み出し割引はモデル別で、GPT-5.6系など現在の主要テキストモデルでは通常入力の0.1倍＝90%引きが中心です（かつて案内された「約50%割引」は2024年のGPT-4o導入時の値で、現行の一般値ではありません）。書き込み料金も世代別で、GPT-5.6より前は追加の書き込み料金なし、GPT-5.6以降はキャッシュ書き込みが通常入力の1.25倍で課金されます。固定率で覚えず、使うモデルの料金表を参照してください。

制御方法も広がっています。自動キャッシュは引き続き標準ですが、GPT-5.6以降は明示ブレークポイント方式も使えます。ここは役割が分かれる点に注意が必要です。prompt_cache_optionsはリクエスト全体のmodeやttlを指定するもので、これだけではブレークポイントは置けません。実際のブレークポイントは、キャッシュしたい固定部分の末尾のコンテンツブロックにprompt_cache_breakpoint: {"mode":"explicit"}を付けて配置します。prompt_cache_keyは同じprefixを共有するリクエストのルーティングを安定させる補助です。explicitモードにしてもブロック上にブレークポイントが1つも無ければ、キャッシュの読み書き自体が発生しません。

# OpenAI GPT-5.6 以降の明示ブレークポイント（Responses API）
# ブレークポイントは message 直下ではなく input_text 等の content ブロックに付ける
resp = client.responses.create(
    model="gpt-5.6",
    prompt_cache_options={"mode": "explicit", "ttl": "30m"},   # リクエスト全体のモード/TTL
    prompt_cache_key="chat-assistant-v1",                      # 省略可。高信頼マッチングには必要
    input=[
        {
            "type": "message",
            "role": "system",
            "content": [
                {
                    "type": "input_text",
                    "text": long_system_instructions,          # 毎回同じ大きな塊
                    "prompt_cache_breakpoint": {"mode": "explicit"},  # ここまでを1キャッシュ単位に
                }
            ],
        },
        {
            "type": "message",
            "role": "user",
            "content": [{"type": "input_text", "text": user_input}],  # 可変部は後ろ
        },
    ],
)

ブレークポイントは、メッセージ直下ではなくinput_text／input_image／input_fileなどのcontentブロックに付けます（対応しない場所に付けると公式仕様上400 invalid_request_error）。また、ブレークポイントまでのレンダリング済みprefixが1,024トークン未満なら、配置が正しくてもキャッシュされません。一致は先頭からのprefixで判定され、旧世代モデルでは128トークン単位で伸びる方式でした（現行ガイドは全モデル共通仕様としては128単位を明記しておらず、GPT-5.6以降は明示ブレークポイント方式が案内されています）。いずれにせよ「先頭を安定させる設計」を開発者が担う点は変わりません。

Google方式（暗黙キャッシュが既定・明示は別API）

Googleは3社の中で開発者側の作業が最も少ない設計です。公式ドキュメントには「Implicit caching is enabled by default for all Gemini 2.5 and newer models」とあり、Gemini 2.5以降のモデルでは暗黙キャッシュが既定で有効。リクエストの先頭部分が以前と一致すればヒットした分の割引が自動で適用され、有効化のための記述は要りません。公式も「We automatically pass on cost savings if your request hits caches. There is nothing you need to do in order to enable this.」と明記しています。

読み出し割引は通常入力の0.1倍＝90%引きで、AnthropicやOpenAIの主要モデルと同水準です。有料枠のStandard料金では、Gemini 3.6 Flashが入力1.50ドルに対してキャッシュ済み入力0.15ドル、3.5 Flash-Liteが0.30ドルに対して0.03ドル（いずれも100万トークンあたり、2026年7月22日時点）。なお無料枠での扱いはモデルで分かれ、3.6 Flashと3.5 Flashは「Free of charge」、3.5 Flash-Liteは「Not available」と表示されます。モデル間の割引率は同じでも入力単価そのものが5倍違うため、どのモデルに寄せるかで総額は変わります（Gemini 3.6 Flash・3.5 Flash-Lite・3.5 Flash Cyberの違いで、3モデルの料金と使い分けを整理しています）。

注意点は、明示キャッシュの扱いがAPIによって違うことです。キャッシュ対象を自分で作って保持する明示キャッシュはgenerateContent API側の機能で、Interactions APIは暗黙キャッシュのみ対応と公式ドキュメントに明記されています。料金ページに併記されている保存料（100万トークンあたり1時間1.00ドル）はこの明示キャッシュを保持する場合の料金で、暗黙キャッシュに任せる構成では発生しません。トークン量に比例するため、長い履歴を明示キャッシュで持ち続ける設計では見積もりに入れておく必要があります。

ヒットしたかどうかはusage.total_cached_tokensで確認します。公式が挙げるヒット率を上げるコツは2点で、大きく共通する内容をプロンプトの先頭に置くことと、似たprefixのリクエストを短い間隔で送ること。前者はAnthropic・OpenAIと同じ「先頭を安定させる」設計方針で、3社に共通する原則です。一方でTTLについては、暗黙キャッシュの保持時間が公式ドキュメントに明記されていません。呼び出し間隔が空くワークロードでヒット率が落ちる場合は、TTLを前提に設計するのではなく実測で確かめる形になります。

キャッシュが当たらない・逆に高くなる設定パターン

逆効果を生む設定には、いくつかの決まった型があります。症状と原因をセットで見ていきます。

再利用の少ないプロンプトにキャッシュを効かせる。これが典型例。1回しか使わない大きなコンテキストにAnthropicのcache_controlを付けると、割高な書き込み分だけを払い、読み出しが発生しないまま失効します。キャッシュは「同じ先頭を何度も送る」前提でだけ元が取れる仕組み。単発リクエストには向きません。

可変データを先頭に置く。ログ用のタイムスタンプ、リクエストID、ユーザー名などをプロンプトの冒頭に差し込むと、prefixが毎回変わります。OpenAIの自動キャッシュもAnthropicのブレークポイントも、変更位置を含むより長いprefixの一致は失われます（ただし変更位置より前に独立したブレークポイントがあり、そのprefixが一致していれば、そこまでのキャッシュは再利用できます）。「システム指示は固定なのにキャッシュが当たらない」という症状は、固定部分の手前に可変データが1行混ざっているのが典型的な原因です。

TTLの選択ミスも割高化の元。Anthropicの標準TTLは5分。バッチ処理などで呼び出し間隔が5分を超えると、毎回キャッシュが失効し、そのつど割高な書き込みが走ります。逆に、数十秒〜数分間隔で継続してアクセスされるなら、ヒットのたびにTTLが更新される5分キャッシュで十分です。この用途で1時間TTL（書込2倍）を選ぶと、同じ効果に対して余分な書込コストを払う可能性があります。呼び出しの実際の間隔にTTLを合わせるのが原則です。

最小トークン閾値の見落としも見積もりを狂わせます。最小キャッシュ長（OpenAIは1,024トークン、Anthropicはモデル・基盤別に512〜4,096）を下回るプロンプトはキャッシュされないのに、割引が効く前提でコストを計算していると、実際の請求と合いません。短いプロンプトを多投するなら、キャッシュ以外の削減策（モデル選択やバッチ化）を先に検討する方が現実的でしょう。

ここまでで機構上言えるのは「こういう設定だと割引が効かない／書込だけ払う」まで。「何%増える」といった数値は、ワークロードごとに変わるため断定しません。判断は自分の請求ログで、という原則は後半で扱います。

コストを削るプロンプト構造の組み替え

対処の中心は、プロンプトの並び順を組み替えること。難しいライブラリは要りません。「固定を前、可変を後」に徹底するだけで、両プロバイダ共通でヒット率が上がります。

静的コンテンツを前方に固める

キャッシュが当たる条件は、先頭からのprefixが一致すること。だから、リクエストをまたいで変わらない要素を可能な限り前に集めます。システム指示、few-shotの例示、共通の参照ドキュメント、ツール定義。これらは固定です。逆に、ユーザーの質問・現在時刻・セッション固有の値は末尾へ。

並べ替えのイメージを構造で示します。

[固定・前方に固める]
  1. システム指示（役割・出力形式・制約）
  2. few-shot例（毎回同じサンプル）
  3. 共通コンテキスト（参照ドキュメント・スキーマ）
  ── ここまでを1つのキャッシュ単位にする ──
[可変・末尾に置く]
  4. ユーザーの入力
  5. タイムスタンプ・リクエスト固有の値

Anthropicなら、固定部分の末尾（上の区切り位置）にcache_controlを1つ置きます。OpenAIは指定不要ですが、この並び順にしておくことで自動キャッシュのprefix一致が最大化されます。設計の考え方はどちらも同じ。「変わらないものを、変わるものの手前に集める」に尽きます。

few-shotの例示を毎回わずかに変えている場合は要注意。例の順番をシャッフルしたり、区切り文字を動的に生成したりすると、それだけでprefixが崩れます。固定したい塊は、文字レベルで完全に同一にするのが条件です。

キャッシュ指定とTTLの選び方

Anthropicでブレークポイントを置く位置は、「これ以降は毎回変わる」という境界。システム指示とfew-shotまでを固定とみなせるなら、その直後に置きます。複数のブレークポイントを段階的に置くこともできますが、まずは「大きな固定塊の末尾に1つ」から始めると管理しやすいはずです。

TTLは呼び出し間隔に合わせます。判断の目安を整理します。

まず、対話アプリのように数十秒〜数分間隔で連続アクセスがあるなら、標準の5分TTLで十分。書込1.25倍で済みます。次に、定期バッチや間欠的なジョブで間隔が5分を超えるなら、1時間TTL（書込2倍）を検討。ただし割増を回収できる読み出し回数があるかを先に見積もること。最後に、1日1回のような低頻度なら、キャッシュ自体が失効して無駄になりやすいので、キャッシュに頼らない構成の方が安く付く場合があります。

効果は計測して確かめる ― 一度の設定で終わらせない

キャッシュ最適化は、一度設定して終わりにできません。ワークフローが失敗する原因は最終工程でなく数手前に潜む、という診断的な見方があります。キャッシュの採算も同じで、設定した「つもり」と実際に効いているかは別物。請求ログで確認する反復が要ります。

判定材料はAPIレスポンスのusageにあります。Anthropicは書き込みをcache_creation_input_tokens（5分・1時間の内訳も持つ）、読み出しをcache_read_input_tokensで返します。OpenAIは読み出しをcached_tokensで返しますが、位置がAPIで異なり、Chat Completionsはusage.prompt_tokens_details.cached_tokens、Responses APIはusage.input_tokens_details.cached_tokensです。さらにGPT-5.6以降は書き込みが同じdetails内のcache_write_tokensに記録されます。ここを毎回記録し、リクエスト単位でなく同一モデル・prefix・期間で累積するのが出発点です。

# Anthropic の採算はリクエスト単位でなく、同一モデル・prefix・期間で累積する。
# 初回は write>0/read=0、ヒット時は write=0/read>0 になるため、
# 1リクエストの read/write 比だけ見るとヒットを取りこぼす。
# 通常入力を1.0倍とし、TTL別の書込倍率(5分1.25/1時間2.0)・読出0.1倍で差額を出す。
write_5m = totals["cache_creation_5m"]   # 5分書込の合計
write_1h = totals["cache_creation_1h"]   # 1時間書込の合計
read     = totals["cache_read"]          # 読出の合計

# 通常入力として処理した場合との差額。負なら削減。
cost_delta = 0.25 * write_5m + 1.00 * write_1h - 0.90 * read
if cost_delta < 0:
    print("キャッシュにより入力コストを削減できている")
else:
    print("キャッシュ書込コストをまだ回収できていない")

「読出が書込を上回れば黒字」という単純な比較は正確ではありません。損益分岐はTTLで変わります。式にすると削減量＝(1−読出倍率)×読出 −(書込倍率−1)×書込で、Anthropicの場合は「0.9×読出 − 0.25×5分書込 − 1.0×1時間書込」。したがって5分キャッシュは同じ長さの読出が1回あれば元が取れ、1時間キャッシュは1回では赤字、2回で黒字になります。書込合計を一括で「1.25倍または2倍」と扱わず、cache_creation内の5分・1時間の内訳を分けるのがポイント。数字を見てから並び順を直し、また測る——この反復で詰めます。

計測を「見る」ことと「減らす」ことは別の作業です。汎用のモニタリングツールやオブザーバビリティ基盤の選定は本記事の範囲外。ここで扱うのは、あくまで自分のAPI請求を削るための最小限の指標に絞っています。まず生のusageを記録する、そこからで十分です。

なお、コーディング支援ツールのように継続課金と実行環境の両方でコストが乗るケースでは、API課金だけでなく実行側の費用も合わせて見る必要があります。ローカル実行やハードウェア側の費用対効果については、姉妹サイトの解説記事「GitHub Copilot 推奨スペック｜AI推論用GPUは通常不要・効くRAMと固有の注意点」も判断材料になります。

キャッシュ読出が0のまま当たらないときの切り分け

「読み出しが記録されない」という症状に絞って、原因を順に潰します。ベースになるのはprefix一致とTTLと最小トークン、この3点の確認です。

先頭が毎回変わっていないか。もっとも多い原因がこれ。プロンプトの冒頭からの数百トークンを、2回のリクエストで文字列比較してみてください。1文字でも差があれば、その位置以降はキャッシュ対象外です。タイムスタンプ、ランダムな挨拶、動的に生成した区切り文字が犯人になりがち。

呼び出し間隔がTTLを超えていないか。前回のアクセスから5分（標準TTL）以上空くと、キャッシュは失効しています。失効後の初回は必ず書き込みになり、読み出しは0。ログのタイムスタンプで実際の間隔を確認し、必要なら1時間TTLへ切り替えます。

プロンプトが最小トークン未満でないか。最小キャッシュ長（OpenAIは1,024トークン、Anthropicは利用モデル・基盤ごとに512〜4,096）に満たないプロンプトは、指定してもキャッシュされません。トークン数を数えて閾値を上回っているか確認します。固定部分が短すぎる場合は、そもそもキャッシュの適用対象ではないと割り切る判断も必要です。

ブレークポイントの位置が適切か（Anthropic）。cache_controlを置いた位置より後ろに固定コンテンツが残っていると、その部分はキャッシュされません。逆に、可変部分をブレークポイントより前に含めてしまうと、prefixが崩れて全体が当たらなくなります。区切り位置が「固定と可変の境界」に正しく置かれているかを見直してください。

なお、キャッシュ関連のエラー名や例外はプロバイダやSDKごとに異なります。特定のエラー文字列を主題に据えるより、上の3点（prefix・TTL・最小トークン）を機械的に確認する方が、原因の切り分けは速く進みます。

まとめ

プロンプトキャッシュの課金は、書き込みが割高になるモデル（Anthropic、GPT-5.6以降のOpenAI）では、書込が割高・読出が割安という非対称で成り立っています。Anthropicは書込1.25倍（5分）／2倍（1時間）・読出0.1倍で、最小キャッシュ長はモデル・基盤別（512〜4,096）、指定は自動（最上位cache_control）と明示の両対応。OpenAIは1,024トークン以上で自動キャッシュが標準で、読出はモデル別（GPT-5.6系など主要テキストモデルは0.1倍）、書込はGPT-5.6より前では追加料金なし・GPT-5.6以降では通常入力の1.25倍。この機構を外して「入れれば安くなる」と考えると、書き込み分だけ払って請求が上がる逆転が起きます。

対処の軸は3つ。まず、システム指示・few-shot・共通コンテキストといった固定要素を前方に固め、可変データは末尾に置いてprefixを安定させること。次に、呼び出し間隔に合わせてTTLを選び、失効による無駄な書き直しを避けること。そして、cache_read／cache_creation（Anthropic）やcached_tokens／cache_write_tokens（OpenAI）をusageから記録し、TTL別の書込倍率と読出倍率を適用した累積差額がマイナス（＝削減）になっているかを自分の請求ログで確認すること。「読出が書込を上回ればよい」という単純比較ではなく、5分キャッシュは同じ長さの読出1回・1時間キャッシュは2回で回収、という損益分岐で見ます。設定は一度で終わらせず、計測して直す反復で詰めていくのが確実です。

よくある質問

Q. プロンプトキャッシュは必ずコスト削減になりますか？

なりません。書き込みが割高なモデル（Anthropic、GPT-5.6以降のOpenAI）では、Anthropicで基本入力の1.25倍（5分）〜2倍（1時間）、GPT-5.6以降のOpenAIで1.25倍が書き込みに課金されます（OpenAIのGPT-5.6より前は書き込みの追加料金なし）。同じ先頭部分を何度も再利用して読み出し（0.1倍）が発生して初めて元が取れます。単発リクエストや再利用の乏しいプロンプトでは、書き込み分だけ払って逆に高くなる場合があります。

Q. キャッシュは自分で有効化が必要ですか？

プロバイダで異なります。Anthropicは最上位にcache_controlを置く自動方式と、プロンプト内にブロック単位でcache_controlを置く明示方式の両方に対応します。OpenAIは1,024トークン以上のリクエストで自動的にキャッシュされ、基本は設定不要（GPT-5.6以降はprompt_cache_optionsによるモード／TTL指定、prompt_cache_breakpointによる明示ブレークポイント、prompt_cache_keyによるキャッシュルーティングの安定化も利用可能）。どちらも、先頭のprefixが一致しないとキャッシュが当たらないため、静的部分を前方に固める設計は必要になります。

Q. 何トークンからキャッシュされますか？

OpenAIは公式仕様で1,024トークン以上が対象です。Anthropicはモデル・利用基盤で異なり、2026年7月17日時点の公式仕様では512〜4,096トークン（Claude API例：Fable 5=512／Sonnet系・Opus 4.8=1,024／Opus 4.7=2,048／Opus 4.6・4.5・Haiku 4.5=4,096）。これを下回る短いプロンプトはキャッシュ指定を書いてもキャッシュされず、通常課金で処理されます。使うモデルの最小値は公式の料金・仕様ページで確認してください。短い問い合わせを多用するワークロードでは、キャッシュ以外の削減策を先に検討する方が現実的です。閾値の確認は「OpenAIは1,024トークン未満、Anthropicは利用モデル・基盤ごとの最低キャッシュ長未満になっていないか」を分けて見ます（OpenAIで明示ブレークポイントを使う場合も、そこまでのprefixが1,024トークン以上必要）。

Q. TTLはどう選べばよいですか？

実際の呼び出し間隔に合わせます。数十秒〜数分間隔で連続アクセスがあるなら標準の5分TTL（Anthropicで書込1.25倍）で足ります。間隔が5分を超えるなら1時間TTL（書込2倍）を検討しますが、割増分を回収できる読み出し回数が見込めるかを先に確認してください。1日1回のような低頻度では、キャッシュ自体が失効しやすく無駄になりがちです。

Q. キャッシュが当たっているかはどこで確認できますか？

APIレスポンスのusageで確認します。Anthropicはcache_read_input_tokens（読出）とcache_creation_input_tokens（書込）を返します。OpenAIの読出cached_tokensは、Chat Completionsではprompt_tokens_details、Responses APIではinput_tokens_detailsの配下にあり、GPT-5.6以降は書込cache_write_tokensも記録されます。これらを同一モデル・prefix・期間で累積し、TTL別の書込倍率（5分1.25／1時間2.0）と読出0.1倍で差額を出せば、採算に乗っているか判定できます。

参考資料

• Anthropic公式: Prompt caching（Claude Docs）
• Anthropic公式: Pricing（キャッシュ書込・読出の料金倍率）
• OpenAI公式: Prompt caching（API Guide）
• OpenAI公式: Prompt Caching in the API
• OpenAI公式: Prompt Caching 101（Cookbook）
• Google AI for Developers 公式: Context caching（暗黙／明示キャッシュと対応API）
• Google AI for Developers 公式: Gemini Developer API pricing（キャッシュ済み入力・保存料）