プロンプトキャッシュ（Prompt Caching）とは｜仕組みと主要APIの使い方

プロンプトキャッシュ（Prompt Caching）とは、LLMへ送るプロンプトのうち先頭から共通する部分（プレフィックス）の内部計算を再利用し、入力トークンの料金と応答遅延を下げる仕組みです。誤解されやすいのですが、モデルが返した「応答」を保存して同じ答えを返す技術ではありません。キャッシュされるのは入力側の中間状態（KVキャッシュ）で、応答は毎回モデルが新しく生成します。長いシステムプロンプトや大きな文脈を繰り返し送るAPI利用で効果が大きく、OpenAI・Anthropic Claude・Amazon Bedrock・Google Geminiなど主要プロバイダが標準機能として提供しています。本記事は仕組みと、混同されやすい応答キャッシュ・セマンティックキャッシュとの違い、各APIでの設定方法、ヒット率の上げ方までを整理します。

まとめ：プロンプトキャッシュの要点（結論）

• キャッシュされるのは入力プレフィックスの計算結果で、割引されるのは入力トークン。応答は毎回生成されるため、回答内容がキャッシュで固定されることはありません。
• プレフィックス（先頭）の完全一致が原則。途中が1文字でも変わるとそこから先はヒットせず再計算になります。可変部分は末尾に置くのが鉄則です。
• OpenAIは自動（1,024トークン超で無設定適用）、Claudeは明示指定（cache_control）と、プロバイダで方式が分かれます。
• Amazon Bedrock・Google Geminiも対応。ローカルLLM（llama.cppなど）はKV再利用による高速化が主目的です。
• 効果は主に「入力料金の割引（最大約90%）」と「最初のトークンが返るまでの時間（TTFT）の短縮」。以下、仕組みと各社の使い方を順に見ていきます。

プロンプトキャッシュの仕組み（プレフィックスのKVキャッシュ再利用）

プロンプトキャッシュの中身を理解する鍵は「LLMが入力をどう処理するか」にあります。ここを押さえると、なぜ入力料金だけが下がり応答は毎回変わりうるのかが明確になります。

入力の内部計算（KVキャッシュ）を保持して再利用する

LLMは入力されたプロンプトを先頭のトークンから順にTransformerで処理し、各トークンについてKey・Value と呼ばれる中間表現（KVキャッシュ）を計算します。プロンプトキャッシュは、直前までに処理したプロンプト先頭部分のKVキャッシュをプロバイダ側で一時保存し、同じ先頭で始まる次のリクエストではその区間の計算をまるごと省きます。この土台となる、推論エンジン内部でKey・Valueを再利用して逐次生成を速くする仕組みはKVキャッシュとは何かと推論高速化・メモリ削減の解説で詳しく整理しています。省けるのは重い入力処理なので、結果として入力トークンの課金が割り引かれ、最初のトークンが返るまでの時間（TTFT）が短くなるのが本質的な効果です。長い共通指示や大きな参照ドキュメントを毎回送るチャットボットやエージェントで、この共通部分が繰り返しヒットします。

プレフィックス完全一致が原則で、途中の変更は無効化する

ヒットするのは先頭から連続して完全一致する区間だけです。プロンプトの途中で1バイトでも文字が変われば、その位置より後ろはキャッシュが効かず再計算されます。Anthropic Claudeでは内部のレンダリング順が「ツール定義、システムプロンプト、メッセージ」の順に固定されており、先頭側ほど安定させる設計が推奨されます。したがって、システムプロンプトに現在時刻やリクエストIDを埋め込む、ツール一覧を毎回並べ替える、といった変動要因を先頭側に置くとキャッシュはほぼ効きません。固定の指示は先頭、毎回変わる質問や可変データは末尾に置くのが設計の基本です。

割引されるのは入力側で、応答は毎回生成される

ここが旧来もっとも誤解されてきた点です。プロンプトキャッシュはモデルの回答を保存して返す仕組みではありません。キャッシュ対象は入力プレフィックスの内部計算だけで、モデルは毎回あらためて推論して応答を生成します。つまり同じプロンプトを再送しても、温度（temperature）や実装によっては応答が変わりえます。「同じ入力に必ず同じ回答を返したい」という要件は、後述の応答キャッシュやセマンティックキャッシュで扱う別レイヤーの話であり、混同するとコスト設計も品質設計も破綻します。

プロンプトキャッシュと応答キャッシュ・セマンティックキャッシュの違い

「LLMのキャッシュ」と一言で言っても、実際には目的も実装レイヤーも異なる3種類があります。プロンプトキャッシュを検討する前に、自分が下げたいのが「入力料金」なのか「モデル呼び出し回数そのもの」なのかを切り分けると選択を誤りません。

プロンプトキャッシュは入力の再計算を省くだけで応答は毎回生成するため、回答品質を犠牲にせずコストと遅延を下げられるのが強みです。一方応答キャッシュはプロンプトが完全一致したときに保存済みの回答をそのまま返し、モデル自体を呼びません。セマンティックキャッシュは「返品方法を教えて」と「返品のやり方は？」のように意味が近い質問へ過去回答を再利用します。後者2つはFAQのような定型応答で呼び出し回数を大幅に減らせますが、古い回答を返す鮮度リスクや、似て非なる質問へ誤った回答を返すリスクを自前で管理する必要があります。入力料金と遅延を下げたいならプロンプトキャッシュ、同一・類似リクエストの回答生成そのものを省きたいなら応答／セマンティックキャッシュ、と目的で選び分けます。両者は排他ではなく、併用も可能です。

OpenAIのプロンプトキャッシュ（自動・prompt_cache_key）

OpenAI APIのプロンプトキャッシュはコード変更不要の自動適用が特徴です。対応モデルへのリクエストで、プロンプトが1,024トークンを超えると自動的に有効になります。

キャッシュは先頭一致するプレフィックスを1,024トークンから128トークン刻みで対象にします。キャッシュされた入力トークンの割引率はモデルにより異なり、旧世代は約50%、新しい世代では75〜90%まで拡大しています（最新の割引率は公式料金ページで確認してください）。キャッシュへの書き込みに追加料金はかかりません。キャッシュは非アクティブ状態が5〜10分続くと失効し、最終利用から1時間以内には必ず消えます。TTLをユーザー側で設定することはできません。ヒット率を高めたい場合はprompt_cache_keyパラメータを使い、同じプレフィックスのリクエストを同じキャッシュへ寄せてルーティングできます。可変の指示を先頭に置かず、共通のシステムプロンプトや例示を先頭に固定するだけで、無設定でもかなりの割引が得られます。

Anthropic Claudeのプロンプトキャッシュ（cache_controlで明示指定）

Anthropic Claudeは自動ではなく明示指定型です。キャッシュしたいブロックにcache_control（typeはephemeral）を付け、どこまでを共通プレフィックスとして区切るかを開発者が制御します。ブレークポイントは1リクエストにつき最大4つまで置けます。

内部のレンダリング順は「ツール定義、システムプロンプト、メッセージ」の順で、この順に安定した内容を前へ、可変の質問を後ろへ並べます。TTLは既定で5分、ttlを1hに指定すると1時間まで延ばせます。料金面ではキャッシュ読み取りが基本入力価格の約0.1倍（およそ90%引き）、書き込みは5分TTLで1.25倍、1時間TTLで2倍がおおよその目安です。したがって数回以上再利用されて初めて元が取れる設計になっています。キャッシュ可能な最小プレフィックスはモデル依存で、Claudeでは概ね1,024〜4,096トークン（上位モデルほど大きめ）が下限です。効いているかどうかは応答のusageにあるcache_read_input_tokensとcache_creation_input_tokensで必ず検証します。これらが常にゼロなら、先頭側に毎回変わる値が紛れ込んでいるサインです。Claudeの前提となるAPIの料金体系やキー取得はAnthropic API（Claude API）の料金とAPIキー取得方法もあわせて確認してください。

Amazon Bedrock・Google Gemini・Grok・ローカルLLMでの対応

プロンプトキャッシュは特定ベンダー固有の機能ではなく、主要な基盤モデル提供先とローカル実行環境の双方に広がっています。利用先ごとに方式と条件が違うため、移植時は前提を取り違えないことが重要です。

Amazon Bedrock（キャッシュチェックポイント方式）

Amazon BedrockのプロンプトキャッシュはGA（一般提供）済みで、AnthropicのClaude各モデル（Claude 3.5 Haiku・3.7 Sonnetや4.x系）とAmazon Nova各モデル（Nova Micro・Lite・Pro）に対応します（対応モデルは順次拡大）。プロンプト内にキャッシュチェックポイントを置く方式で、チェックポイントは最大4つです。1チェックポイントあたりの最小トークンはモデルで異なり、Claude 3.7 Sonnetは1,024トークン、Claude 4.x系は4,096トークンが目安です。公称ではレイテンシを最大85%、コストを最大90%削減します。AWS上で生成AIアプリを組む文脈はBedrock Engineerの概要と特徴も参考になります。

Google Gemini（コンテキストキャッシュの暗黙・明示）

Gemini APIでは「コンテキストキャッシュ」という名称で、2種類の方式を提供します。暗黙的キャッシュはGemini 2.5以降で既定オンかつ自動で、キャッシュされた入力に約90%の割引が入ります。明示的キャッシュはCachedContentを作成してTTL（既定60分）を設定する方式で、キャッシュを保持している時間に対してストレージ課金が発生します。明示キャッシュの最小トークン数は引き下げられており、現在はGemini 2.5 Flashで1,024トークン、2.5 Proで2,048トークンが目安です（下限や課金は変わりやすいため最新は公式ドキュメントで確認してください）。保存料金がかかるぶん、高頻度で再利用する大きな固定文脈があるときだけ明示キャッシュを使い、通常は暗黙キャッシュに任せるのが費用面では堅実です。いずれもプロンプトキャッシュ同様、応答は毎回生成されます。

xAI Grokとローカル実行環境（llama.cpp・Ollama・LM Studio）

xAI GrokもAPIでプロンプトキャッシュに自動対応し、共通プレフィックスの入力が割り引かれます。Grokではリクエストが別サーバーへ振り分けられるとキャッシュを外すことがあるため、x-grok-conv-idヘッダに安定した会話IDを設定して同じサーバーへ寄せるとヒット率が上がります（OpenAIのprompt_cache_keyと同じ発想です）。ローカルLLMでは意味合いが少し変わり、llama.cppの--cache-promptや、OllamaやLM Studioでの会話継続時に、直前のプロンプトのKVキャッシュを保持して再計算をスキップします。ローカルは従量課金がないため、目的は料金割引ではなく応答の高速化（TTFT短縮）です。クラウドAPIとローカルで「何を得るためのキャッシュか」が異なる点を押さえておくと、環境を跨いだ設計で混乱しません。

キャッシュヒット率を上げる設計と料金の考え方

プロンプトキャッシュは有効化するだけでは十分に効きません。プレフィックス完全一致という制約に沿ってプロンプトの組み立て方を変えることが、割引を実際に受け取る条件です。ここは判断を明確に述べます。

まずプロンプトの先頭には固定の内容だけを置く。共通のシステムプロンプト、ツール定義、few-shotの例示、参照ドキュメントを前半に固定し、ユーザーの質問・現在時刻・リクエストIDといった毎回変わる値は必ず末尾へ回します。システムプロンプトにdatetime.now()相当の値やUUIDを埋め込むのは、キャッシュを自ら壊す典型的なアンチパターンです。JSONを直列化して差し込む場合はキー順を固定し、同じバイト列になるようにします。会話が長くなるエージェントでは、ツール定義やモデルを会話の途中で入れ替えると全体が無効化されるため、モードの切り替えはツールの差し替えではなくメッセージ内容で表現します。

料金の損益分岐も理解しておきます。Claudeのように書き込みが割高（1.25〜2倍）で読み取りが激安（約0.1倍）な方式では、同じプレフィックスが数回以上再利用されて初めて黒字になります。逆に先頭が毎回変わり共有できるプレフィックスが無いワークロードでは、キャッシュを付けても書き込み料金だけを払って読み取りが発生せず割高になります。リクエスト間隔がTTLより長く空くケースも同様で、この場合はTTLの長い設定に切り替えるか、そもそもキャッシュを付けない判断が正解です。効き具合は必ず応答の使用量メトリクス（キャッシュ読み取りトークン）で実測し、感覚で判断しないことが重要です。トークン消費そのものを圧縮する隣接テーマとして、auto-compactによる自動コンテキスト圧縮やコンテキストエンジニアリングも併読すると、キャッシュ・圧縮・文脈設計を通した全体最適が見えてきます。

よくある質問

プロンプトキャッシュを使うと毎回同じ回答が返りますか？

いいえ。キャッシュされるのは入力プレフィックスの内部計算（KVキャッシュ）だけで、応答は毎回モデルが生成します。同じ入力に必ず同じ回答を返したい場合は、応答キャッシュやセマンティックキャッシュという別レイヤーの仕組みが必要です。

OpenAIのプロンプトキャッシュはコードが必要ですか。TTLは設定できますか？

コード変更は不要で、プロンプトが1,024トークンを超えると自動で適用されます。TTLはユーザー側で設定できず、非アクティブ5〜10分で失効・最終利用から1時間以内に必ず失効します。ヒット率を高めたいときはprompt_cache_keyで同じプレフィックスのリクエストを寄せられます。

Anthropic Claudeでキャッシュを効かせるには何をしますか？

キャッシュしたいブロックにcache_controlを付けて明示指定します（ブレークポイントは最大4つ）。TTLは既定5分で、ttlを1hにすれば1時間です。最小プレフィックスはモデル依存でおよそ1,024〜4,096トークン、効果はusageのキャッシュ読み取りトークンで確認します。

キャッシュがヒットしない主な原因は何ですか？

プレフィックスの先頭側に毎回変わる値が入っているのが最多です。現在時刻・UUID・順序が不定なJSON・可変のシステムプロンプトなどが該当します。固定内容を先頭、可変内容を末尾に置き直し、キャッシュ読み取りトークンがゼロでないかを実測してください。

Amazon BedrockやGemini、ローカルLLMでも使えますか？

使えます。Bedrockはキャッシュチェックポイント方式でClaude・Novaに対応、Geminiはコンテキストキャッシュ（暗黙・明示）を提供します。ローカルはllama.cppの--cache-promptなどでKVキャッシュを再利用しますが、こちらは料金割引ではなく応答の高速化が目的です。

関連記事

• Anthropic API（Claude API）料金とAPIキー取得方法｜無料枠・使い方を解説【2026年版】
• auto-compactとは？AIコーディングエージェントの自動コンテキスト圧縮を仕組み・使い方・注意点まで解説
• コンテキストエンジニアリングとは何か？現代のAI開発で注目される新たな技術概念の定義と背景を詳しく解説
• Bedrock Engineerとは何か？AWS発の開発者向け生成AIツールの概要と特徴を詳しく解説