プロンプトキャッシュ(Prompt Caching)とは｜LLM APIのコストとレイテンシを下げる仕組みと実務

長い文脈や定型の指示を毎回モデルに送っていると、同じ内容を何度も処理させることになり、コストと応答時間が積み上がります。プロンプトキャッシュ(Prompt Caching)は、この「同じ部分の再計算」をサーバ側で省く仕組みです。この記事では、キャッシュがなぜ効くのかという仕組みの基本から、主要3社の差分、はまりやすい落とし穴、そして実務でどう取り入れ・どこで使わないかまでを、変動前提で整理します。トークン課金の総論は別記事に譲り、ここではキャッシュ機構そのものに絞ります。

プロンプトキャッシュとは何か#

LLMは、入力されたトークンごとにattention(注意機構)のkey-value(KV)を計算しながら応答を組み立てます。長いシステム指示や大きな文脈を毎回渡すと、そのKV計算をリクエストのたびにやり直すことになり、これが初回応答時間(TTFT)とコストに直結します。

プロンプトキャッシュは、複数のリクエストで共通するプレフィックス部分のKV計算結果をサーバ側に保存しておく仕組みです。次のリクエストが同じプレフィックスで始まっていれば、その部分の計算をスキップして保存済みの結果を読み出せます。結果として、再計算の分だけTTFTとコストが下がります。

効かせるための基本:静的を先頭、可変を末尾#

3社に共通する勘所は、プロンプトの構造化です。システム指示・長い文脈・少数の例といった静的コンテンツをプレフィックス(先頭)に固め、ユーザ入力のような可変コンテンツを末尾に置きます。こうすると、リクエストが変わっても先頭の一致区間が長く保たれ、ヒット率が上がります。

効果が出やすいのは、次のような場面です。

• 長い文脈を毎回渡すケース(仕様書・マニュアル・コードベースなど)
• RAGで取得した定型的な参照情報を繰り返し添えるケース
• 同じ指示を何度も使い回すケース
• マルチターンの会話や、共通の前提を持つエージェント

逆に言えば、毎回まったく異なる短い単発の入力では、共通プレフィックスが育たないため恩恵は小さくなります。文脈をどう構成し、どの順で渡すかという設計は、コンテキストエンジニアリングの考え方とも地続きです。

3社の差分:Anthropic・OpenAI・Google#

仕組みの発想は共通でも、有効化の方法や課金の考え方はプロバイダごとに異なります。以下は本記事時点で公式に確認できた範囲の整理です。

Anthropic(Claude)#

Anthropicは、cache_controlでキャッシュのブレークポイント(どこまでをキャッシュ対象にするか)を明示的に指定します。課金は、書き込み(キャッシュ作成)が基準入力価格に対してプレミアム、読み出しが割安という構造です。書き込みのプレミアムはTTLで変わり、5分TTLで1.25倍、1時間TTLで2.0倍、読み出しは0.1倍とされています。最小キャッシュ長はモデル依存で、例としてOpus 4.8/Sonnet 5は1024トークン、Haiku 4.5は4096トークン、Fable 5/Mythos 5は512トークンと、モデルにより異なります。デフォルトTTLは5分で、TTL内に再利用すると無償でリフレッシュされます。レスポンスのusage(cache_creation_input_tokens / cache_read_input_tokens)で、キャッシュの書き込み・読み出し状況を確認できます。

OpenAI#

OpenAIは、対象リクエストで自動的に有効になり、コード変更は不要です。おおむね1024トークン以上のプロンプトが対象で、静的コンテンツを先頭に置くとヒットしやすくなります。新しめのモデル(GPT-5.6以降)ではcache writeが1.25倍、cached readは割引が適用されるとされています(具体的な割引率は公式・料金ページで確認してください)。ルーティングは概ね先頭256トークン程度でハッシュして振り分けられます。

Google(Gemini)#

Geminiには、暗黙的キャッシュ(implicit caching)と明示的キャッシュ(explicit caching)があります。暗黙的キャッシュはGemini 2.5以降でデフォルト有効・設定不要で、ヒット時に自動で割引が適用されます。明示的キャッシュは、保存に対して時間課金が発生します。最小トークン数はモデル依存で、例としてGemini 2.5は2048トークン、3.5 Flash/3.5 Pro Previewは4096トークンとされています。

全体傾向としては、3社ともキャッシュヒット時の入力トークンを大きく割り引きます。ただし、書き込みプレミアムの有無、保存の時間課金の有無、明示指定か暗黙かといった課金体系は、プロバイダとモデルで異なり、今後も改定され得ます。

落とし穴:効かない・かえって割高になるケース#

キャッシュは万能ではなく、前提を外すと効かないどころか割高になります。運用前に押さえておきたい点を挙げます。

その他の注意点は次のとおりです。

• 書き込みプレミアムがある提供元では、一度きり・低頻度の利用だとキャッシュがかえって割高になり得ます。読み出しの回数で書き込み分の元を取る、という前提で判断します。
• 最小トークン長に満たない短いプロンプトはそもそもキャッシュされません。短い入力には効きません。
• キャッシュにも機密情報・個人情報が載り得る点は、運用上の配慮が必要です。保存範囲やTTLの扱いを確認してください。
• 明示/暗黙・課金・TTLはプロバイダごとに異なるため、別の提供元へ移植すると前提が変わります。移植時は再設計が要ると考えたほうが安全です。

実務での取り入れ方#

導入は、いきなり全体に広げるのではなく、静的と動的を切り分けて高頻度の共通プレフィックスから当てていくのが安全です。

コスト削減の全体像(モデルの使い分け・見積もり・監視の仕組みづくり)は、キャッシュ単体ではなく削減の定石としてまとめた別記事も合わせて読むと、位置づけが掴みやすくなります。

本記事の仕様・数値は、Anthropic「Prompt caching - Claude Docs」、OpenAI「Prompt Caching」、Google「Context caching - Gemini API」の各公式ドキュメント(2026年7月時点で確認できた範囲)を参照しています。倍率・最小トークン長・TTL・割引率・対象モデルは、提供元とモデルで異なり改定され得ます。実装前に必ず各社の公式で最新の値を確認してください。

よくある質問#

まとめ#

プロンプトキャッシュは、共通するプレフィックスの再計算を省くという一点に絞った、地味だが効果の見えやすい最適化です。効くのは先頭一致する静的部分だけ、課金体系は提供元とモデルで異なり改定され得る、という2つの前提さえ押さえておけば、過度な期待も見当違いの実装も避けられます。まずは手元の高頻度なプロンプトを静的と動的に分け、usageでヒット率を測るところから始めてみてください。