プロンプトキャッシング（プロンプトキャッシュ）とは？主要LLMの仕組みや料金、実装のコツを徹底解説

プロンプトキャッシング（プロンプトキャッシュ）とは、LLM APIに繰り返し送る共通プレフィックス（システムプロンプト・ツール定義・長文コンテキスト）をプロバイダー側で保持し、次回以降のリクエストで再計算せずに再利用する機能です。

2026年時点でAnthropic・OpenAI・Google・DeepSeek・xAI・AWS Bedrockなど主要プロバイダーがすべて実装しており、キャッシュヒット時のトークン単価は本記事で扱う現行主要モデルで通常入力の約2〜16%（約84〜98%オフ）まで落ちます（OpenAI旧世代はGPT-4o=50%、GPT-4.1=75%等モデル別）。

本記事では、プロンプトキャッシングの仕組みと料金構造、主要6社の実装比較、コスト削減の設計原則と導入判断を、2026年7月時点の最新情報で体系的に解説します。

プロンプトキャッシング（プロンプトキャッシュ）とは

プロンプトキャッシング（プロンプトキャッシュ、prompt caching）とは、LLM（大規模言語モデル） APIに繰り返し送られる共通プレフィックスをプロバイダー側で保持し、次回以降のリクエストで再計算せずに再利用する機能です。

同じシステムプロンプトや同じツール定義、同じ長文コンテキストを何度も送るワークロードで、入力トークンの処理コストとレイテンシを同時に削減できるのが本質です。

呼称はプロバイダーごとに揺れます。Anthropicは「Prompt Caching」、Googleは「Context Caching」、OpenAIやxAIは「Cached Input Tokens」と呼びますが、指しているものはすべて同じ「前方一致プレフィックスの再利用」機能です。

2026年時点で主要LLMプロバイダーのほぼすべてで利用可能な標準機能となっており、LLMコスト削減の第一手段として位置づけられます。

プロンプトキャッシングと呼ばれる理由

「プロンプトをキャッシュしている」というより、正確には「同じプロンプトを何度も送ったときの推論結果（KV cache）を再利用している」ため、他の一般的なキャッシュ（HTTPキャッシュ・データベースクエリキャッシュ等）とは動作原理が異なります。

キャッシュのルールは常に「先頭からの完全一致（前方一致・prefix match）」です。プロンプトの先頭から文字列レベルで同一である部分だけがキャッシュヒットし、途中で1文字でも変わると、そこから後ろは全部キャッシュミスとして再計算されます。

詳細は後段の「プロンプトキャッシングを効かせる設計原則」セクションで扱います。

---

プロンプトキャッシングの料金構造

プロンプトキャッシングの料金は、主要プロバイダー共通で「キャッシュ書き込み（write）」「キャッシュ読み込み（read）」「TTL（保持時間）」の3変数で決まります。

各社で単価倍率と実装方式は異なりますが、基本ロジックは同じです。以下の表で、料金構造の共通フレームを整理しました。

課金要素	定義	単価の相場
ベース入力トークン	キャッシュしない通常入力	各モデルの標準単価
Cache write（書き込み）	初回にキャッシュを作成するときのトークン	ベース入力の 1.0〜2.0倍
Cache read（読み込み）	2回目以降にキャッシュから取り出すトークン	現行主要モデルでベース入力の 0.02〜0.16倍（約84〜98%オフ、プロバイダ・モデル差あり）
ストレージ（一部プロバイダのみ）	キャッシュを保持する時間課金	1M トークンあたり時間 $1程度

この表を踏まえると、プロンプトキャッシングの経済性は「Cache readが何回発生するか」で決まります。

cache write課金なし（DeepSeek・xAI Grok・Gemini Implicit等）なら1回のread hitでも即プラス、cache write 1.25倍のAnthropic 5分TTLやOpenAI GPT-5.6でもAnthropic公式の説明どおり書き込み後1回の再ヒットで元が取れます。

Anthropic 1時間TTL（write 2倍）は2回の再ヒットが損益分岐点です。

Cache read割引の相場

Cache readの割引率はプロバイダにより幅があります。Anthropic・Google Gemini（2.5+ Explicit）・OpenAI GPT-5.6・AWS Bedrock（Claude）は「ベース入力の10%（90%オフ）」、xAI Grok 4.3は「ベース入力の約16%（約84%オフ）」、DeepSeek V4-Flashは「2%（98%オフ）」まで踏み込んでいます。

この割引率の差は、キャッシュヒット率が高いワークロードほど月額コストの桁を左右します。

仮に通常入力$3/Mのモデル（Anthropic Claude Sonnet 4.5相当）を想定して90%オフと98%オフを比較すると、同じ100万トークンで前者$0.30/後者$0.06、5倍の差になります（実際の差は各社の通常入力単価に比例）。

Cache write課金の変化

2026年時点で最も注目すべき変化は、OpenAI GPT-5.6ファミリー（2026年7月9日）で cache write が「無料」から「1.25倍課金」へ移行した点です。他社の現行課金構造は下記のとおりです。

• Anthropic
  従来から cache write は 5分TTLで1.25倍、1時間TTLで2倍を課金
  
  

• OpenAI
  GPT-5.6以前は cache write 無料、GPT-5.6（2026年7月9日発表）以降は1.25倍に変更
  
  

• AWS Bedrock
  Claude系は Anthropic直接同等で cache write 1.25倍、Nova系は cache write 追加課金なし
  
  

• Google Gemini
  Implicit cachingは自動で追加費用なし、Explicit cachingはストレージ課金あり
  
  

• DeepSeek / xAI Grok
  cache write 追加料金なし（完全自動キャッシュ）
  
  

OpenAIのGPT-5.6での有料化は、公式ドキュメントで「1.25× the uncached input token rate」と明記されており、書き込みコストを回収できるだけの読み込み回数が発生するかを設計時点で見積もる必要が出てきました。

TTLと課金の関係

キャッシュの保持時間（TTL）は、各プロバイダーで大きく異なります。

プロバイダ	デフォルトTTL	オプション	挙動
Anthropic Claude	5分（標準）	1時間TTL（cache write 2倍）	ヒットごとに自動延長（rolling TTL）
OpenAI GPT-5.6	30分（最小保証）	prompt_cache_options.mode で implicit/explicit を選択（TTLは30mのみ）	prompt_cache_breakpoint で境界指定、prompt_cache_key でルーティング安定化
OpenAI GPT-5.6より前の対応モデル	モデル・組織設定依存（GPT-5.5系は24hのみ、それ以前の対応モデルはZDR設定によりin_memory／24h）	公式ガイド参照	自動
Google Gemini	Implicit 自動、Explicit 手動指定	Explicitは TTL任意設定	Explicitはストレージ課金あり
DeepSeek V4	数時間〜数日	なし	自動、未使用は自動クリア
xAI Grok	自動（TTL詳細は公式未明示）	なし	自動

Anthropicは5分TTLを標準としつつ、1時間TTL（cache write 2倍課金）をオプションで提供しています。

間隔が空くワークロード（バッチ処理・低頻度API利用）は5分TTLだと再ヒットしにくいため、1時間TTLに切り替えるか、リクエスト頻度を上げて5分以内に再ヒットさせる設計に寄せるかの2択が現実的な打ち手になります。

---

プロンプトキャッシングの主要LLMプロバイダー横断比較

プロンプトキャッシングは主要6プロバイダーで実装されていますが、実装方式・単価・最小トークン数・キャッシュ制御の粒度が細かく異なります。

以下の表で、2026年7月時点の主要プロバイダー6社の実装差分を整理しました。

プロバイダ	実装方式	割引率	Cache write	最小トークン	制御粒度
Anthropic Claude	自動＋明示（cache_control）	90%オフ	5m=1.25x / 1h=2x	512〜4,096（モデル依存）	最大4ブレークポイント
OpenAI GPT-5.6ファミリー	自動＋明示	90%オフ	1.25x	1,024	prompt_cache_breakpoint / prompt_cache_options
OpenAI GPT-5.6より前の対応モデル	完全自動	モデル依存（GPT-4o=50%、GPT-4.1=75%、GPT-5.2=90%等）	無料	1,024	自動
Google Gemini	Implicit＋Explicit	90%オフ（2.5+）	Implicit追加料金なし / Explicitはキャッシュ入力単価＋ストレージ課金	2,048〜4,096	Implicit自動 / Explicit CachedContent API
DeepSeek V4	完全自動	98%オフ	無料	未公表	自動
xAI Grok 4.3	完全自動	約84%オフ	無料	未公表	自動
AWS Bedrock Claude系	InvokeModel/Messages APIは 「cache_control」、Converse APIは 「cachePoint」	90%オフ	1.25x	モデル依存	API・モデル別
AWS Bedrock Nova系	「cachePoint」	90%オフ	追加課金なし	モデル依存	cachePoint挿入

この比較から分かるのは、実装コストと制御粒度がトレードオフになっている点です。DeepSeek・xAI Grokの完全自動キャッシュは実装が最も楽ですが、キャッシュ対象を明示制御できません。

一方、Anthropicの明示的cache_controlやOpenAI GPT-5.6のprompt_cache_breakpointは、静的部分と動的部分を細かく分けたい大規模アプリで有利になります。

Anthropic Claude

Anthropic Claudeのプロンプトキャッシングは、Anthropic公式ドキュメントで仕様が公開されており、リクエストトップレベルの 「cache_control」 による自動キャッシュと、ブロック単位で明示的にキャッシュ境界を指定するブレークポイント方式の両方に対応しています。

主なパラメータと仕様は以下のとおりです。

• キャッシュブレークポイント
  tools・system・messagesの任意のコンテンツブロックに 「"cache_control": {"type": "ephemeral"}」 を付与し、1リクエストあたり最大4つまで設定可能
  
  

• TTL
  デフォルト5分（無料で自動延長）、「"ttl": "1h"」 で1時間TTL（cache write 2倍課金）
  1時間TTLは5分TTLより前に配置する必要あり
  
  

• 最小キャッシュサイズ
  Claude Opus 5・Fable 5：512トークン
  Opus 4.8・Sonnet 5・Sonnet 4.5：1,024トークン
  Haiku 4.5：4,096トークン
  
  

• 料金例（Claude Opus 5、100万トークンあたり）

ベース入力$5 / 5分書き込み$6.25 / 1時間書き込み$10 / キャッシュ読み込み$0.50 / 出力$25

キャッシュヒットは 「response.usage.cache_read_input_tokens」 と 「cache_creation_input_tokens」 で計測できます。総入力トークンは 「cache_read_input_tokens + cache_creation_input_tokens + input_tokens」 の合計になる点に注意が必要です。

OpenAI GPT-5.6/4o系

OpenAIのプロンプトキャッシングは、OpenAI公式ドキュメントで運用ルールが公開されています。GPT-4o以降のモデルで自動キャッシュが有効で、GPT-5.6ファミリー（Sol/Terra/Luna）からは明示的なブレークポイント制御と最小TTL 30分保証が追加されました。

• 自動キャッシュ条件
  プロンプトが1,024トークン以上で自動的にキャッシュが有効化
  ルーティングは冒頭の約256トークンのハッシュに基づく
  
  

• 明示的キャッシュ（GPT-5.6以降）
  「prompt_cache_breakpoint」 でキャッシュ境界（どこまでをキャッシュ対象にするか）を指定
  「prompt_cache_options.mode」 で implicit/explicit を選択（TTLは30mのみ）
  「prompt_cache_key」 は同一プレフィックスを同一シャードにルーティングしてマッチング率を安定化させる用途（境界指定ではない）
  
  

• 料金モデル（GPT-5.6以降）

Cache write：1.25× uncached input token rate
Cache read：90%オフ（cached-input rate）
GPT-5.6 Sol（公式pricing）は入力$5/M・cache read $0.50/M・出力$30/Mが2026年7月時点の単価

• モニタリング
  Responses APIでは 「usage.input_tokens_details.cached_tokens」、Chat Completions APIでは 「usage.prompt_tokens_details.cached_tokens」 でキャッシュ読み込み量を追跡
  
  

GPT-5.6で cache write が有料化されたことで、GPT-4o時代の「自動キャッシュで無料削減」というフリーランチが終わりました。

ただし1.25倍書き込み＋90%オフ読み込みの構造上、書き込み後1回の再ヒットで通常2回分より安くなるため、損益分岐は1回のread hitです。

設計時点で「同じプレフィックスが少なくとも2回以上呼ばれるか」を確認する運用に切り替える必要があります。

Google Gemini

Google Geminiのコンテキストキャッシングは、Google公式ドキュメント（Generate Content API版）でImplicit（暗黙的）とExplicit（明示的）の2方式が用意されています。

• Implicit Caching
  Gemini 2.5以降のモデルでデフォルト有効

最小トークン：Gemini 2.5 Flash/Pro=2,048、Gemini 3.5 Flash・3.1 Pro Preview=4,096（Gemini 3.6 Flashもキャッシュ対応だが最小値は公式未明示）
自動でキャッシュヒット時にコスト削減が反映され、Generate Content APIでは 「usage_metadata.cached_content_token_count」 で確認可能

• Explicit Caching
  CachedContent APIで明示的にキャッシュオブジェクトを作成
  Gemini 2.5+でキャッシュ入力単価が90%オフ、加えてTTLに応じたストレージ課金（例：1Mトークンあたり時間$1）が発生。TTLは任意設定可能
  （Gemini 2.0系は2026年6月1日に提供終了、現行選択肢からは外れる）
  
  

Implicit CachingがGemini 2.5以降でデフォルト有効になったことで、コード変更なしでもキャッシュヒットが自動的に発生するようになりました。

ただし、明示制御ができないため、大きなsystem instructionや長文データファイルをプロンプトの先頭に配置する運用ルールが実効性を左右します。

DeepSeek

DeepSeekは2024年8月2日に「Context Caching on Disk」を正式導入し、DeepSeek公式アナウンスで「価格を桁違いに削減する」と公表しました。以降、V3・V4系すべてに引き継がれています。

• 完全自動
  cache_controlパラメータ・追加ヘッダー・opt-inフラグ不要
  リクエスト境界でキャッシュプレフィックスユニットを自動生成
  
  

• 料金（DeepSeek V4-Flash、100万トークンあたり）

ベース入力（cache miss）$0.14 / キャッシュヒット $0.0028（98%オフ） / 出力 $0.28
V4-Pro：ベース入力$0.435 / キャッシュヒット$0.003625 / 出力$0.87

• モニタリング
  「prompt_cache_hit_tokens」（ヒット）と 「prompt_cache_miss_tokens」（ミス）でトラッキング
  
  

• 追加料金なし
  ストレージ課金・書き込み課金なし。未使用キャッシュは数時間〜数日で自動クリア
  
  

DeepSeek V4-Flashのキャッシュヒット時単価$0.0028/MTokは、2026年時点の業界最安値レンジです。同じキャッシュヒットでもAnthropic Claude Haiku 4.5の$0.10/MTokと比べて約36倍安く、大量ワークロードでは月額コストの桁が変わります。

xAI Grok

xAI Grokは主要モデルで自動キャッシュを実装しており、公式ドキュメントで仕様が公開されています。

料金例としてGrok 4.3を取ると、100万トークンあたりの単価は以下のとおりです（2026年7月時点の最新モデルはGrok 4.5）。

ベース入力 $1.25 / キャッシュ入力 $0.20（約84%オフ） / 出力 $2.50

cache write追加課金なし、キャッシュ制御パラメータ不要で、同一プレフィックスの繰り返しリクエストで自動的にヒットが発生します。

TTLの厳密な数値は公式ドキュメントで明示されていないため、実測モニタリングでヒット率を確認する運用が現実的です。

なお、Grok 4.1 Fastは2026年5月15日に提供終了しており、現行の比較対象からは外れます。

AWS Bedrock

AWS Bedrockは、Anthropic Claude・Amazon Nova・OpenAI GPT系でプロンプトキャッシングをサポートしていますが、公式ドキュメントによると挙動と料金はモデルシリーズ別に分かれています。

• Claude系（AWS掲載モデル。Sonnet 5・Haiku 4.5・Opus 4.8等）
  Cache write：1.25× base input rate、Cache read：0.1× base input rate（90%オフ）
  InvokeModel/Messages APIは 「cache_control」、Converse APIは 「cachePoint」（同じClaudeでも呼び出しAPIで記法が変わる点に注意）
  最小トークン数はBedrock上のモデルごとに異なる
  
  

• Amazon Nova系（Pro・Lite・Micro）
  Bedrock独自の 「cachePoint」 を挿入してキャッシュ境界を指定
  cache write追加課金なし、cache read 90%オフ
  2024年12月にBedrock Prompt Cachingがプレビュー投入され、2025年4月にNovaを含めてGAされている
  
  

AWS環境で既存のBedrockパイプラインに統合する場合、Claude系のInvokeModel/Messages APIならAnthropic API直接と同じ 「cache_control」 記法が使えるため実装移植コストは小さくなります。Converse APIやNova系を選ぶ場合は 「cachePoint」 の挿入設計に切り替える必要があります。

---

プロンプトキャッシングのコスト削減試算と事例

プロンプトキャッシングの投資対効果は、実際のワークロードで計算しないと直感的に掴めません。本セクションでは、単発リクエストの試算・エージェント運用の月次試算・公開されている事例の3層で数値化します。

単発リクエストの試算

20,000トークンの長いsystem promptを含むリクエストを、Claude Opus 5で10回連続実行する場合の試算です。

• キャッシュなし
  20,000 × $5/M × 10回 = $1.00
  
  

• キャッシュあり（初回のみwrite、以降9回はread）
  (20,000 × $6.25/M × 1回) + (20,000 × $0.50/M × 9回) = $0.125 + $0.090 = $0.215
  
  

• 削減率
  78.5%
  
  

10回程度の反復でも約8割のコスト削減が実現できることが分かります。

反復回数が増えるほど、cache writeの初回投資が償却されて削減率は90%に近づいていきます。

エージェント運用の月次試算

AIエージェントが1タスクあたり20,000トークンのsystem promptを50ステップ回すワークロード（月間1,000タスク）を、GPT-5.6 Sol（入力$5/M・cache write $6.25/M・cache read $0.50/M）で運用する場合の試算です。

• 総入力トークン
  20,000 × 50ステップ × 1,000タスク = 10億トークン
  
  

• キャッシュなし
  10億 × $5/M = $5,000
  
  

• キャッシュあり（cache write率2%＝2,000万トークン・cache read率98%＝9億8,000万トークン）
  (2,000万 × $6.25/M) + (9億8,000万 × $0.50/M) = $125 + $490 = $615
  
  

• 削減率
  約87.7%
  
  

この試算のポイントは、キャッシュヒット率が高いほど削減効果が跳ね上がる点です。

系列的なエージェント処理（同じsystem promptで数十ステップ回すワークフロー）は、cache read率が高い水準に張り付きやすく、コスト圧縮の投資対効果が最も高い領域になります。

ProjectDiscoveryの59〜70%削減事例

セキュリティ企業ProjectDiscoveryは、Anthropic Claudeを使う自社サービスでプロンプトキャッシングを最適化し、cache hit rateを7%から84%まで引き上げることで、総LLMコストを59〜70%削減した事例を公開しています。

本番環境では9.8Bトークンがキャッシュから配信されました。
「84%×90%=75.6%」はキャッシュ対象の入力トークンに対する単純計算の理論値で、59〜70%は総LLMコストベースの実測削減率のため計算範囲が異なりますが、いずれもキャッシュ設計を最適化した効果が二桁パーセントに達することを示しています。

このケースが示すのは、「プロンプトキャッシングを有効化した」だけでは効果が限定的で、設計を見直してヒット率を7%→84%に引き上げる作業が本体という事実です。

cache_controlの配置位置・静的コンテンツの先頭寄せ・cache breakerの除去といった設計最適化が、実際のコスト削減の大半を生み出します。

DeepSeekのディスクキャッシュ導入事例

DeepSeekは公式ブログで、Context Caching on Disk導入により「入力トークン価格を最大90%削減、最適化なしでも平均50%削減」と公表しました。

DeepSeek V4-Flashのキャッシュヒット単価$0.0028/MTok（公式pricing）は2026年時点の業界最安値レンジで、大量ワークロードのコスト構造を根本から変えます。

実効的なコスト削減率は個別のcache hit率によって決まるため、自社ワークロードでの実測値を確認する運用が推奨されます。

---

プロンプトキャッシングを効かせる設計原則

プロンプトキャッシングを実装しても、設計を間違うとキャッシュヒット率が上がらず、cache writeの追加コストだけが積み上がる事故が起きます。

前方一致（prefix match）というメカニズムの特性上、いくつかの設計原則を守るだけでヒット率が数倍〜10倍以上変わります。

静的コンテンツを先頭に配置する

プロンプトキャッシングの最重要原則は「静的コンテンツをプロンプトの先頭に置き、動的コンテンツを末尾に寄せる」ことです。

プロンプトは以下の順序で組み立てるのが基本形になります。

1. ツール定義（tools配列）——変更頻度が最も低い
2. システムプロンプト——ロール・振る舞い・出力形式などの固定指示
3. 共通のリファレンス資料——社内ドキュメント・仕様書・過去会話等のセッション内で共有される長文
4. 会話履歴——ターンごとに追加される
5. 今回のユーザー入力——毎リクエストで変わる

この順序を守ると、1〜3までがキャッシュヒット対象になり、変わるのは4〜5だけになります。

逆に、今回のユーザー入力を先頭に置いてしまうと、それ以降すべてがcache missになり、キャッシュ機能が実質無効化されます。

キャッシュ境界の配置ポイント

Anthropic Claudeの 「cache_control」、OpenAI GPT-5.6の 「prompt_cache_breakpoint」 のように明示的なキャッシュ境界指定があるプロバイダーでは、ブレークポイントの配置位置がヒット率を決定します。

• tools配列の末尾
  ツール定義全体をキャッシュ
  
  

• systemメッセージの末尾
  システムプロンプトまでをキャッシュ
  
  

• 長文コンテキストブロックの末尾
  リファレンス資料までをキャッシュ
  
  

• 会話履歴の直前
  履歴を含めない場合の境界
  
  

Anthropicは1リクエストあたり最大4ブレークポイントまで設定可能ですが、実務では3〜4個で十分カバーできます。

ブレークポイント自体に追加料金は発生せず、課金は実際に書き込み・読み込みされたトークン量に基づきます。

キャッシュを壊すアンチパターン

キャッシュヒット率を意図せず下げてしまう典型的なアンチパターンは以下のとおりです。

• システムプロンプトに現在時刻・日付を入れる
  「今日は2026年7月28日15時30分です」のような動的な情報を先頭に入れると、毎リクエストでプレフィックスが変わりキャッシュが常にmissする
  
  

• ツール定義の順序をランダム化する
  tools配列のJSON serialize順が変わると、文字列レベルで一致しなくなりcache miss
  
  

• セッション途中でツールを追加・削除する
  tools配列に変更が入るとその位置以降がcache miss。追加が必要な場合は「新規セッション開始時から入れておく」設計が推奨
  
  

• モデルを途中で切り替える
  Claude Sonnet 5とOpus 5でキャッシュは共有されない。ワークフロー内で複数モデルを使う場合、それぞれのモデルで独立にcache writeが必要
  
  

• 動的コンテンツを先頭に入れる
  ユーザーIDやセッションIDなどの可変値を先頭付近に入れると、それ以降すべてがcache miss
  
  

これらのアンチパターンは、プロンプトキャッシング未実装のときには問題にならなかった設計要素です。実装後は「先頭からどこまでが不変か」を常に意識する運用に切り替える必要があります。

---

AIエージェント運用でのプロンプトキャッシング

プロンプトキャッシングが最も効くのは、単発のAPI呼び出しよりもAIエージェント運用のような反復ワークロードです。

同じsystem promptと同じツール定義を数十〜数百ステップ回す構造は、キャッシュ経済性が最大化する典型パターンで、月額コストの桁を1つ下げる打ち手になります。

反復system promptループの経済性

AIエージェントは、タスクを完了するまでLLMを反復呼び出しします。1タスクあたり数十ステップになるケースは珍しくなく、各ステップで同じ長大なsystem prompt（20,000〜100,000トークン規模）を送信します。

キャッシュなしの場合、system prompt分のトークンが毎ステップ課金されるため、system promptが大きくなるほどエージェント運用の限界コストが急上昇します。

プロンプトキャッシングを有効化すると、現行主要モデルでは初回書き込み後にプロバイダ・モデルにより約84〜98%オフで再利用できるため、system promptを大きく取っても運用コストが線形に増えなくなります。

実務上、エージェント設計で「system promptに何を入れるか」「何を除外するか」の判断軸が、キャッシュ有無で大きく変わります。

キャッシュなし前提だとsystem promptを圧縮する動機が強く働きますが、キャッシュあり前提では「性能を最大化するために潤沢に入れておく」設計が経済的に成立します。

MCPツール定義のキャッシュ

Model Context Protocol（MCP）経由で外部ツール群を接続するエージェントでは、tools配列が数千〜数万トークン規模になることがあります。

• MCPサーバーが提供するツール定義は、セッション開始時から不変
• Anthropic Claudeなら tools配列末尾に 「cache_control」 を配置してキャッシュ対象化
• OpenAI GPT-5.6なら 「prompt_cache_breakpoint」 でtools定義まで含めてキャッシュ対象化

tools配列がリクエスト全体のトークンに占める割合が大きいほど、キャッシュ化の効果は増します。

実際の削減率はワークロードごとに変わるため、cache read率と総トークン内訳をモニタリングして自社ケースで検証するのが確実です。

会話履歴のキャッシュ設計

マルチターン会話では、過去のターンが履歴として蓄積されていきます。この履歴もキャッシュ対象にできますが、設計に工夫が必要です。

• cache breakpointを会話履歴末尾に配置
  過去N-1ターンまでの履歴をキャッシュ、今回の新規ユーザー入力だけがcache miss
  
  

• 履歴の要約統合を避ける
  ターンごとに履歴を「要約して統合」する処理を入れると、履歴部分の文字列が毎ターン変わりcache miss。原文ままの追記のみが望ましい
  
  

• 履歴の圧縮タイミングを設計する
  コンテキスト窓の上限に近づいたら履歴を圧縮するが、圧縮のタイミングでキャッシュが完全にmissする。圧縮頻度と再ヒットまでの回復コストのバランスを設計時点で見積もる
  
  

会話履歴を上手くキャッシュに乗せると、長期セッションでもコスト増加が抑えられ、複数ターンの対話エージェントが経済的に運用可能になります。

モデル切替とキャッシュの関係

エージェント運用で「軽量タスクはClaude Haiku 4.5、重量タスクはClaude Opus 5」のようにモデルを使い分けたい場合、キャッシュはモデルごとに独立している点に注意が必要です。

例えば、Sonnet 5で書き込んだキャッシュをOpus 5では読めません。

切り替えのたびに再書き込みが走るため、頻繁なモデル切替は cache writeコストが積み上がる要因になります。

実務上の推奨は以下のとおりです。

• モデル固定
  単一ワークフロー内では原則1モデルで完結させる
  
  

• モデル切替が必要な場合
  切替コストを差し引いても性能改善が正当化されるステップに限定する
  
  

• キャッシュを共有できる代替
  モデルレベルではなくプロンプトエンジニアリングで難易度を吸収する
  
  

AI総研の支援現場でも、エージェント運用のコスト設計相談は「モデル選定」より「キャッシュ設計」に軸足が移ってきています。モデル単価の差以上に、キャッシュヒット率の差が総コストを支配するようになったためです。

---

プロンプトキャッシングの導入判断とプロバイダ選定

プロンプトキャッシングの導入価値はワークロード特性で大きく変わります。

全案件で一律に「使うべき」ではなく、自社のユースケースに合った判断軸で選定する必要があります。

プロバイダ選定の3つの基準

主要プロバイダーの中でどれを選ぶかは、以下の3基準で整理できます。

• 実装コストを最小化したい場合
  DeepSeek V4 か xAI Grok の完全自動キャッシュが第一候補。コード変更不要でヒットすれば自動で割引が反映される
  
  

• 静的/動的コンテンツを細かく分けたい大規模アプリ
  Anthropic Claudeの 「cache_control」 か OpenAI GPT-5.6の 「prompt_cache_breakpoint」 による明示的境界指定が第一候補。Anthropicは最大4ブレークポイントで tools・system・context・history を分離できる
  
  

• 既存のクラウド基盤に統合したい
  AWS環境なら Amazon Bedrock（Claude系のInvokeModel/Messages APIならAnthropic直接と同じcache_control、ConverseやNova系はcachePoint）、Google Cloud環境なら Vertex AI経由の Gemini（Implicit自動）、Azure環境なら Microsoft Foundry（OpenAI準拠）が実装移行コストを抑えられる
  
  

コスト最適化を最優先するなら DeepSeek V4-Flash が現時点で最安値レンジですが、日本語性能・SLA・法人契約の要件によってはAnthropic・OpenAI・Geminiが現実的な選択肢になります。

最初にやることの優先順位

自社アプリでプロンプトキャッシングを本格導入する場合、以下の順序で着手するのが実務的です。

1. 現状のトークン消費構造を把握
   system prompt・tools・会話履歴・ユーザー入力の各パートが総トークンに占める割合を計測
2. 静的コンテンツの割合を見て投資判断
   静的部分の比率と再ヒット回数が投資対効果を決める。ワークロードごとに検証したうえで実装可否を判断
3. 既存プロンプトを「静的先頭・動的末尾」に再構成
   コード変更前にプロンプト構造を見直し、キャッシュヒットしやすい形に整理
4. プロバイダの明示境界指定を実装（明示制御プロバイダの場合）
   Anthropicは 「cache_control」 を最大4箇所、OpenAI GPT-5.6は 「prompt_cache_breakpoint」 で境界を指定
5. ヒット率のモニタリング
   「cache_read_input_tokens」 / 「cached_tokens」 / 「prompt_cache_hit_tokens」 などのフィールドで実測し、設計最適化で継続的に引き上げる

ProjectDiscoveryの事例（cache hit rate 7%→84%）が示すように、実装よりも「設計最適化でヒット率を上げる」フェーズに時間と工夫が必要です。1発で高いヒット率が出ることは稀で、モニタリングと調整を繰り返して育てる運用になります。

導入で判断に迷う論点

プロンプトキャッシング導入で実務的に判断に迷う典型論点は以下のとおりです。

• Anthropic 5分TTLの扱い
  5分TTLは、間隔が空くワークロード（バッチ処理・低頻度API）だと再ヒットしにくい。1時間TTL（cache write 2倍）に切り替えるか、リクエスト頻度を上げて5分以内に再ヒットさせる設計を選ぶかの2択
  
  

• GPT-5.6でのcache write有料化
  GPT-4o時代の「無料でコスト削減」設計から変更が必要。書き込み1.25倍＋読み込み90%オフの構造上、書き込み後1回の再ヒットで元が取れるため、同一プレフィックスが2回以上呼ばれる設計かを検証
  
  

• モデル切替でのキャッシュ再書き込み
  軽量/重量モデルの切替はキャッシュ経済性を損なう。単一モデル運用に寄せるか、切替を正当化する性能改善が必要か判断
  
  

• 会話履歴の圧縮タイミング
  コンテキスト窓上限に近づくと履歴圧縮が必要だが、圧縮タイミングでキャッシュ全損する。圧縮頻度と再ヒットまでの回復コストのバランス設計
  
  

• プロバイダ乗換え時の実装移植
  Anthropic→OpenAI GPT-5.6のようなプロバイダ切替時は、境界指定パラメータ（cache_control vs prompt_cache_breakpoint）・最小トークン数・TTL設計を再設計する必要がある
  
  

AI総研の支援現場でも、初期導入より「ヒット率を上げるチューニング」の相談が多くなっています。実装後もモニタリングと改善サイクルを継続的に運用に組み込むのが現実的です。

---

プロンプトキャッシング設計を業務Agentに組み込むなら

プロンプトキャッシングは単発API利用よりも、反復system promptを回すAIエージェント基盤で最大の効果を発揮します。ただし、ヒット率を上げるにはプロンプト構造の再設計・キャッシュ境界の配置最適化・モニタリング運用が必要で、モデル切替やTTLの選定も含めて設計工数がまとまって発生します。

このレイヤーを担うのが、業務エージェント基盤の統合設計です。AI総合研究所のAI Agent Hubは、業務特化Agent群を1つのダッシュボードで統合管理し、モデル切替とキャッシュ設計を吸収する運用基盤として機能します。

• モデル世代交代を吸収する管理層
  Claude Opus 5 → Fable 5、GPT-5.6 → 次世代のように短サイクルで世代交代が起きても、業務Agent側の設計は不変。キャッシュ再書き込みコストや実装差分を管理層で吸収します
  
  

• プロンプト構造の統一設計
  静的コンテンツ（tools・system・context）を先頭に置く設計原則を、全Agent共通のテンプレートとして適用。ヒット率を初期から高く保てます
  
  

• キャッシュ効果のモニタリング統合
  Agentごとのcache_read率・cache_creation率をダッシュボードで一元可視化。ヒット率が下がったAgentを早期検出できます
  
  

• データは100%自社Azureテナント内に保持
  プロンプト・キャッシュ対象データはAIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計です
  
  

AI総合研究所の専任チームが、プロンプトキャッシング設計から業務Agent基盤の統合設計まで一貫して支援します。AI Agent Hubのサービスページで、キャッシュ設計を含む業務Agent実装例をご確認ください。

---

まとめ

本記事では、プロンプトキャッシング（プロンプトキャッシュ）について、仕組み・料金構造・主要6プロバイダーの比較・コスト削減の実例試算・設計原則・AIエージェント運用での使い方・導入判断までを、2026年7月時点の最新情報で解説しました。

2026年時点で押さえておくべきポイントは次の3つです。

• プロンプトキャッシングは主要LLM6社（Anthropic・OpenAI・Google・DeepSeek・xAI・AWS Bedrock）で標準実装され、キャッシュヒット時のトークン単価は現行主要モデルで通常入力の約2〜16%（約84〜98%オフ）まで下がる（OpenAI旧世代はGPT-4o=50%、GPT-4.1=75%などモデル別）
• 2026年後半の重要な変化はOpenAI GPT-5.6（Sol/Terra/Luna）でのcache write 1.25x課金化で、GPT-4o時代の「自動キャッシュで無料削減」から設計前提の見直しが必要
• 「静的コンテンツを先頭に配置＋動的コンテンツは末尾」がヒット率を左右する最重要原則で、ProjectDiscoveryは設計最適化で7%→84%まで引き上げて総コスト59〜70%削減を達成
  
  

プロンプトキャッシングは、LLM APIコスト削減の中で最も投資対効果が高い設計要素です。実装コストを最小化したいならDeepSeek V4かxAI Grokの完全自動キャッシュ、細かな制御をしたいならAnthropic Claudeの 「cache_control」 かOpenAI GPT-5.6の 「prompt_cache_breakpoint」 が第一候補になります。まずは現状のトークン消費構造を計測し、静的コンテンツの比率と再ヒット回数を見て投資対効果を判断するのが、最も実用的な第一歩になります。