Prompt Cachingコストガイド：キャッシュヒット、プレフィックス、および実際のAPI利用料金

プロンプトキャッシングのコストは、プロンプトのうちどれだけが再利用可能なプレフィックスであるか、そのプレフィックスがキャッシュの有効期間内にどれだけ頻繁に繰り返されるか、そして各プロバイダーがキャッシュ書き込みとキャッシュヒットをどのように価格設定しているか、という3つの変数に依存します。これら3つの数値を正しく把握すれば、反復的なワークロードにおいて入力トークンの請求額を大幅に削減できます。逆に誤れば、一度も再利用されないキャッシュに対して書き込みプレミアムを支払うことになりかねません。

本ガイドでは、プロバイダーが文書化している内容、公開されているAPIインターフェースで検証可能な内容、そして本番環境の支出をキャッシュ戦略にコミットする前にテストすべき内容を整理します。

重要なポイント

• プロンプトキャッシングのコストには、書き込みコスト（通常、新しいキャッシュエントリが作成される際に発生）とヒットコスト（通常、リクエストがそのエントリを再利用する際に発生）の2つの要素があります。Anthropicのドキュメントでは、この書き込みとヒットの区別が明示されています。コストをモデル化する前に、ドキュメントページで現在の倍率を確認してください。
• キャッシュヒットには、定義されたブレークポイントまでの完全一致またはほぼ完全一致のプレフィックスが必要です。システム指示、ツール定義、またはFew-shotの例をそのブレークポイントより前に並べ替えると、キャッシュは無効になり、強制的に再書き込みが発生します。
• キャッシュエントリは、プロバイダーが定義した有効期間（TTL）を過ぎると期限切れになります。特定のプレフィックスに対するリクエストボリュームが少なすぎてこの期間内に収まらない場合、ヒットによる節約分を蓄積する代わりに、繰り返し書き込みコストを支払うことになります。
• OpenRouterのドキュメントでは、プロンプトキャッシングの動作と価格は基盤となるプロバイダーやモデルによって異なると指摘されています。そのため、あるバックエンドでコストを削減できるキャッシュ戦略が、別のバックエンドにそのまま適用できるとは限りません。想定される節約額に基づいてトラフィックをルーティングする前に、モデルごとのサポート状況を確認してください。

プロンプトキャッシングで実際に課金されるもの

プロンプトキャッシングを利用すると、APIプロバイダーはプロンプトプレフィックスの処理済み表現を保存できるため、同じプレフィックスを共有する後続のリクエストでは冗長な計算をスキップできます。これに伴う課金モデルは「キャッシュされたトークンは無料」というものではありません。「キャッシュされたトークンは再利用時に安くなるが、最初の書き込みは標準の入力トークンよりもコストがかかる」という考え方に近いです。

Anthropicのプロンプトキャッシングに関するドキュメントでは、この構造が直接的に示されています。新しいキャッシュエントリを作成するリクエストは、既存のエントリにヒットするリクエストとは異なる課金がなされます。正確な倍率は時間経過やモデルによって変化するため、この記事を含むブログ投稿で見かける数値は、固定された定数ではなく、最新のドキュメントと照らし合わせて検証すべきものとして扱ってください。

実用上の意味合いとして、プロンプトキャッシングは「再利用への賭け」です。システムプロンプト、ツールスキーマ、または取得したコンテキストブロックが一度送信されて二度と繰り返されない場合、キャッシュはヒットによる節約効果なしに書き込みプレミアムを追加するだけになります。同じブロックがキャッシュの有効期間内に何百回も送信される場合、ヒットによる節約額は書き込みコストを大幅に上回る可能性があります。

キャッシュヒットの仕組み：プレフィックスとブレークポイント

キャッシュヒットは、曖昧な意味でのコンテンツベースではなく、プレフィックスベースです。プロンプトのキャッシュされた部分は、キャッシュ境界（ブレークポイントと呼ばれることもあります）が設定されている地点まで、受信リクエストとトークン単位で完全に一致している必要があります。Anthropicのドキュメントでは、これは開発者がプロンプトのどの部分をキャッシュ対象とするか（通常は呼び出し間で変更されない安定したシステム指示、ツール定義、長い参照ドキュメントなど）を明示的にマークする仕組みとして説明されています。

これには直接的なエンジニアリング上の影響があります。キャッシュブレークポイントの前に配置するものは、空白や順序を含め、リクエスト間でバイト単位で同一である必要があります。よくある間違いは、リクエストごとの変数（タイムスタンプやユーザーIDなど）をキャッシュ境界より前のシステムプロンプトに混在させることです。そのたった一つの変数がプレフィックス全体のキャッシュを無効にしてしまい、ヒットを蓄積する代わりに、呼び出しのたびに書き込みコストを支払うことになります。

修正方法は簡単です。真に静的なコンテンツ（ツール定義、ハウススタイルの指示、大規模な参照ドキュメント）はキャッシュされたプレフィックスに保持し、リクエスト固有のものはすべてキャッシュされないサフィックス（通常はユーザーメッセージ）に押し出してください。

キャッシュの寿命は、プレフィックスの設計と同じくらい重要です。Anthropicのドキュメントでは、デフォルトのキャッシュ期間が分単位で設定されており、必要に応じてより長い期間のオプションも利用可能であると説明されています。共有プレフィックスを数分おきに送信するようなトラフィックパターンの場合、次のリクエストが到着する前にキャッシュが期限切れになり、結果として繰り返し書き込みコストを支払うことになります。低頻度で散発的な呼び出しよりも、高頻度のワークロード（チャットセッション、エージェントループ、連続して実行されるバッチパイプライン）の方がはるかに適しています。

実際のAPI支出をモデル化する：実践的なアプローチ

節約率を断定するのではなく、以下の形式で独自のワークロードをモデル化してください。この例はリクエスト構造を概念的に示したものです。実装する前に、プロバイダーのドキュメントで正確なフィールド名と現在の価格を確認してください。

{
  "model": "claude-sonnet-5",
  "system": [
    {
      "type": "text",
      "text": "You are a support agent. Full policy document follows...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    { "role": "user", "content": "What is the refund window for order 48213?" }
  ]
}

システムブロックの cache_control マーカーは、このコンテンツがキャッシュ候補であることを示します。セッション内の最初の呼び出しでは、そのブロックの書き込みコストが発生します。キャッシュの有効期間内に同じプレフィックスを再利用する後続のすべての呼び出しでは、それらのトークンに対して完全な入力レートではなく、ヒットレートが適用されます。

これがサービスに実装する価値があるかどうかを見積もるには、独自のログから以下の4つの数値を収集してください。

1. プレフィックスサイズ：キャッシュする予定の安定したコンテンツ（システムプロンプト、ツールスキーマ、参照ドキュメント）のトークン数。
2. TTLウィンドウ内の呼び出し頻度：キャッシュの有効期間内に、その正確なプレフィックスを再利用するリクエストが何回あるか。
3. 書き込みレートとヒットレート：記憶に頼らず、現在のプロバイダーのドキュメントから取得したもの。
4. サフィックスの変動性：キャッシュされない部分がキャッシュされる部分に対して小さいかどうか。節約額は、プロンプト全体のどれだけがキャッシュブレークポイントの後ろにあるかに比例するためです。

プレフィックスが大きく、TTLウィンドウ内の呼び出し頻度が高く、サフィックスが小さい場合、キャッシングによって支出が削減される可能性が高いです。これら3つの条件のいずれかが弱い場合は、広範囲にキャッシングを導入する前に、比較コストを算出してください。TokenLabのAI APIコスト削減ガイドでは、モデル選択やバッチ処理など、キャッシング以外のより広範なレバーについても解説しています（/blog/cut-ai-api-costs-30-percent）。

意思決定テーブル：プロンプトキャッシングが効果を発揮するケース

ワークロードパターン	キャッシュが有効か	備考
セッション内の多くの呼び出しで再利用される長いシステムプロンプトやツールスキーマ	はい	典型的なケース。書き込みコストがヒットによって償却される
短いフォローアップ質問のバーストで再利用される大きな取得済みドキュメント	はい（TTL内に収まる場合）	再利用ウィンドウを想定する前に、現在のドキュメントでTTLを確認すること
繰り返しトラフィックのない単発のプロンプト	いいえ	相殺するヒットがないまま書き込みプレミアムが発生する
「安定した」セクションが頻繁に変更される高変動プロンプト	いいえ	ブレークポイントより前の変更はすべてキャッシュを無効にする
多くのターンでツール定義が繰り返されるエージェントループ	はい	ツールスキーマはキャッシュの主要な候補
キャッシュTTLを超えて間隔が空く低頻度のバッチジョブ	いいえ	再利用前にキャッシュが期限切れになり、毎回書き込みコストが発生する
一部のバックエンドのみがキャッシングをサポートするマルチプロバイダールーティング	モデルごとに検証	キャッシングサポートがプロバイダー間で引き継がれると想定しないこと

このテーブルは最終的な答えではなく、開始時のチェックリストとして使用してください。使用予定の特定のモデルについて、プロバイダーのドキュメントでTTL、書き込み/ヒット価格、ブレークポイントの仕組みを確認してください。これらの詳細はモデルファミリーによって変更・差異があるためです。

コミット前に検証すべきプロバイダー間の違い

プロンプトキャッシングはどこでも同じように実装されているわけではありません。複数のプロバイダーやモデル間でトラフィックをルーティングする場合、これは重要です。OpenRouterのプロンプトキャッシングに関するベストプラクティスのドキュメントでは、キャッシングのサポートや動作は基盤となるプロバイダーによって異なると指摘されています。つまり、あるモデルのキャッシュメカニズムに合わせて調整された戦略が、別のモデルに切り替えたり別のバックエンドを経由したりしたときに自動的に適用されるわけではありません。

アーキテクチャでコストを制御するためにモデルルーティングを使用している場合（例：日常的な分類タスクをDeepSeek V4 Flash、GLM-5.2、Gemini 3.5 Flashのような低コストモデルに送信し、より困難な推論タスクのためにClaude Sonnet 5やGPT-5.5を予約するなど）、ルーティングテーブル内の各モデルについて個別にキャッシングサポートを確認する必要があります。あるモデルのドキュメントで検証されたキャッシング戦略を、別のモデルに安全に適用することはできません。TokenLabのランキングページでは、開始時の参照ポイントとして使用できるモデルレベルの違いを追跡しており（/models/rankings）、ルーティングベンチマーク分析（/blog/ai-model-routing-benchmark-cost-per-task）では、ルーティングの決定がタスクごとのコストとどのように相互作用するかをカバーしています。これはキャッシングの決定を置き換えるものではなく、複合的に作用するものです。

本分析の制限事項

本ガイドは、Anthropicによって文書化され、OpenRouterによって参照されている時点でのプロンプトキャッシングの一般的なメカニズムを説明しています。正確な書き込み/ヒット倍率、正確なTTL期間、モデルごとの価格は含まれていません。これらの数値はモデルによって変化し、異なるためです。本番環境のトラフィックのコストモデルを構築する前に、サードパーティのコンテンツ（本記事を含む）に記載されている固定数値に頼るのではなく、上記のプロバイダーのドキュメントから直接最新の数値を取得してください。推論指向モデル、マルチモーダルプロンプト、非常に長いコンテキストウィンドウのキャッシング動作は、ここで説明した一般的なプレフィックスキャッシングパターンとは異なる場合があります。使用予定の特定のモデルのドキュメントと照らし合わせて検証してください。

FAQ

プロンプトキャッシングは常にAPI支出を削減しますか？ いいえ。安定したプレフィックスがキャッシュの有効期間内に書き込みコストを相殺するのに十分な頻度で再利用される場合にのみ、支出を削減します。散発的または非常に変動の激しいプロンプトでは、キャッシングを有効にするとかえってコストが高くなることがよくあります。

何がキャッシュヒットを壊しますか？ キャッシュブレークポイントより前のプロンプトコンテンツに対するあらゆる変更（空白、トークンの順序、または静的なシステムプロンプトに挿入された単一の変数など）が該当します。一致はブレークポイントまで完全である必要があります。

プロンプトキャッシングはすべてのプロバイダーで同じように実装されていますか？ いいえ。Anthropicは、定義された書き込みおよびヒット価格を伴う明示的なキャッシュ制御メカニズムを文書化しています。OpenRouterのドキュメントでは、キャッシングのサポートと価格は基盤となるプロバイダーとモデルによって異なると指摘されているため、サポートが引き継がれると想定するのではなく、モデルごとにサポートを確認する必要があります。

プロンプトキャッシング、モデルルーティング、またはその両方の組み合わせがトラフィックパターンに適しているかどうかを評価している場合は、TokenLabを使用して、本番環境の支出をコミットする前にモデルのオプションとコスト構造を比較することから始めてください。