毎回同じ長いSystem Promptを送っている
RAGで同じ巨大ドキュメントを何度も参照する
AI Agentで大量のTool定義を毎回渡している
長い会話履歴を毎ターン送り直している

例えば、次のようなプロンプトです。

[System Prompt: 5,000 tokens]
[Tool Definitions: 10,000 tokens]
[Reference Documents: 20,000 tokens]

User:
東京都の売上について教えて

次のリクエストでは、最後の質問だけが変わります。

[System Prompt: 5,000 tokens]       ← 同じ
[Tool Definitions: 10,000 tokens]  ← 同じ
[Reference Documents: 20,000 tokens] ← 同じ

User:
大阪府の売上について教えて

毎回35,000トークン近くをモデルがゼロから処理するのは、少しもったいないですよね。

そこで使われるのが Prompt Caching（プロンプトキャッシュ） です。

Prompt Cachingを使うと、過去に処理したプロンプトの共通部分を再利用できるため、

入力トークンのコスト削減
Time to First Token（TTFT）の短縮
Agent / RAGアプリケーションの高速化

が期待できます。

この記事では、Prompt Cachingが内部で何をキャッシュしているのかを含め、その仕組みを整理します。

※ APIの具体的な価格・TTL・対象モデルなどは変更されるため、利用時には各社の最新ドキュメントを確認してください。本記事のサービス仕様に関する記載は2026年8月時点です。

Prompt Cachingとは

一言でいうと、

以前計算した「プロンプトをLLM内部表現へ変換する途中結果」を再利用する仕組み

です。

ここで重要なのは、

「LLMの回答をキャッシュしているわけではない」

という点です。

例えば、

Q: 日本の首都は？
A: 東京です

という結果そのものをRedisなどに保存して、

Q: 日本の首都は？

が来たらLLMを呼ばずに、

A: 東京です

を返しているわけではありません。

Prompt Cachingでは、LLMが入力プロンプトを処理するときに行った計算の一部を再利用します。

そのため、後半の質問が違えば、もちろん異なる回答を生成できます。

LLMはプロンプトをどう処理しているのか

Prompt Cachingを理解するには、Transformerの推論処理をざっくり理解すると分かりやすくなります。

例えば、

あなたは優秀なプログラミングアシスタントです。
Pythonについて回答してください。

User:
FastAPIについて教えて

という入力があるとします。

LLM内部では、まず文章がトークンへ分割されます。

Prompt
  ↓
Tokenize
  ↓
[token1, token2, token3, ...]

その後、Transformerによって各トークンのAttention計算が行われます。

概念的には、

Token
 ↓
Embedding
 ↓
Transformer Layer 1
 ↓
Transformer Layer 2
 ↓
Transformer Layer 3
 ↓
...
 ↓
Transformer Layer N
 ↓
次のTokenを予測

という処理です。

このときTransformerのAttentionでは、過去のトークンについて

Key
Value

という内部表現が計算されます。

これが、よく聞く KV Cache（Key-Value Cache） です。

Prompt Cachingの正体

例えば次のプロンプトがあるとします。

System:
あなたはECサイトの分析AIです。
以下のデータ仕様に従って回答してください。

[大量の仕様書]
[大量のTool定義]
[大量のFew-shot Examples]

User:
東京の売上を分析してください。

これを簡略化すると、

AAAAAAAAAAAAAAAAAAAA BBB

だと考えてください。

A が毎回同じ部分、

AAAAAAAAAAAAAAAAAAAA

B がユーザーごとに変わる部分です。

初回リクエストでは、

AAAAAAAAAAAAAAAAAAAA BBB
↓
全部計算
↓
AAAA...部分の計算結果をCache

します。

次に、

AAAAAAAAAAAAAAAAAAAA CCC

というリクエストが来たとします。

先頭部分は同じなので、

AAAAAAAAAAAAAAAAAAAA
        ↓
   Cache Hit
        ↓
計算結果を再利用

CCC
 ↓
ここから計算

できます。

つまり概念的には、

Request 1

[A A A A A A A A A A][B B B]
 └──── 計算 ────────┘


Request 2

[A A A A A A A A A A][C C C]
 └── Cache Hit ─────┘└計算┘

となります。

OpenAIもPrompt Cachingについて、キャッシュヒットにはプロンプトのprefix（接頭辞）の一致が重要であり、固定コンテンツを前、動的コンテンツを後ろに置くことを推奨しています。

なぜ「Prefix」が重要なのか

Prompt Cachingを理解するとき、一番重要なのがこれです。

共通部分はプロンプトの前方に置く

例えば次の構成を考えます。

良い例

System Prompt
↓
Tool Definitions
↓
Reference Documents
↓
Few-shot Examples
↓
User-specific Context
↓
User Question

前半が固定されています。

[STATIC STATIC STATIC STATIC][DYNAMIC]

そのため多数のリクエストでキャッシュを共有しやすくなります。

一方、

悪い例

Current Time: 2026-08-26 01:00:01

System Prompt
Tool Definitions
Reference Documents
User Question

次のリクエストが、

Current Time: 2026-08-26 01:00:02

System Prompt
Tool Definitions
Reference Documents
User Question

になると、先頭付近から内容が変化します。

[DYNAMIC][STATIC STATIC STATIC]

これでは長い共通Prefixを作れません。

したがって、

System Prompt
Tool Definitions
Reference Documents

Current Time: 2026-08-26 01:00:02
User Question

のように、変動する情報を後ろへ移した方がキャッシュ効率を上げやすくなります。

Prompt Cachingと「普通のキャッシュ」の違い

Webアプリケーションでよく利用するRedisキャッシュと比較すると分かりやすいです。

通常のResponse Cache

Request
  ↓
Hash(Request)
  ↓
Cache Lookup
  ↓
Hit
  ↓
Responseをそのまま返す

例えば、

"日本の首都は？"

に対する回答、

"東京です"

自体を保存します。

同じRequestであれば、そもそもLLMを実行しません。

Prompt Cache

Prompt Cacheの場合は、

Prompt
 ↓
Cached Prefix
 ↓
途中の計算を再利用
 ↓
LLMは続きを推論
 ↓
新しいResponseを生成

となります。

つまり、

	Response Cache	Prompt Cache
キャッシュ対象	最終回答	入力処理の途中結果
LLM推論	原則スキップ	続きは実行
質問が変化	Hitしにくい	Prefixが同じなら利用可能
出力	同じ結果	新しく生成される
主な用途	完全に同一な問い合わせ	共通の長いContext

という違いがあります。

なぜPrompt Cachingで高速になるのか

Transformerでは長いContextを処理するために、大量のAttention計算が必要です。

例えば、

System Prompt       5k tokens
Tool Definitions   10k tokens
Documents          50k tokens
User Input          1k tokens

合計、

66k tokens

だったとします。

毎回これを最初から処理すると、

Request 1 → 66k tokens processing
Request 2 → 66k tokens processing
Request 3 → 66k tokens processing
Request 4 → 66k tokens processing

となります。

ところが最初の65k tokensが共通なら、

Request 1

[65k static][1k dynamic]
     ↓
   compute


Request 2

[65k static][1k dynamic]
     ↓          ↓
 Cache Hit    compute


Request 3

[65k static][1k dynamic]
     ↓          ↓
 Cache Hit    compute

という形にできます。

特に、

巨大System Prompt
MCP / Function Callingの大量Tool定義
Coding AgentのRepository Context
RAGの巨大ドキュメント
Few-shot examples
長期間のConversation History

などを持つアプリケーションでは効果が大きくなります。

KV Cacheとの関係

ここで、

「Prompt CacheとKV Cacheは同じなの？」

と思うかもしれません。

概念としては密接に関連しています。

TransformerではAttentionを計算するとき、

Q = Query
K = Key
V = Value

を利用します。

自己回帰型LLMでは、

token1
token2
token3
token4
...

と生成するたびに過去トークンのK/Vを毎回再計算するのは無駄です。

そこで、

token1 → K1,V1
token2 → K2,V2
token3 → K3,V3

を保存して、

KV Cache
┌───────────────┐
│ K1 V1         │
│ K2 V2         │
│ K3 V3         │
│ ...           │
└───────────────┘

として再利用します。

通常のKV Cacheは、1回の生成中や会話処理を効率化する仕組みとして語られることが多いです。

Prompt Cachingは、それをさらにAPIリクエストをまたいで活用し、

Request A
     ↓
Prefixの計算結果
     ↓
Prompt Cache
     ↓
Request B

と再利用できる仕組みだ、と捉えると理解しやすいでしょう。

ただし、具体的に何をどの形式で保存し、どのようにルーティングするかはLLMプロバイダーの実装詳細なので、

Prompt Cache = 必ず生のKV Tensorをそのまま永続保存する機能

と断定するのは避けた方が正確です。

Anthropicも、Prompt Cachingに関連してKV表現やキャッシュされたコンテンツの暗号学的ハッシュについて説明しています。

Cache Hitには「完全一致」が重要

例えば、

You are a helpful assistant.

Document:
AAAAAAAAAAAAAAAA

がキャッシュされたとします。

次のリクエストが、

You are a helpful assistant.

Document:
AAAAAAAAAAAAAAAA

なら再利用しやすいですが、

You are a very helpful assistant.

Document:
AAAAAAAAAAAAAAAA

と前半を変えると、その位置以降のキャッシュを利用できなくなる可能性があります。

OpenAIでは、キャッシュヒットにはexact prefix matchが必要だと説明しています。画像やTool定義についても、キャッシュ対象部分では同一性が重要です。

つまり、

Static Prompt
Static Tools
Static Documents
Dynamic User Context

という設計は単なる見た目の整理ではなく、推論コスト最適化にも影響するアーキテクチャ設計になります。

AI Agentでは特に重要

Prompt CachingはAI Agentと非常に相性が良いです。

Agentでは毎回、

System Prompt
+
50個のTool Definitions
+
Policies
+
Environment Information
+
Conversation History
+
User Message

のような巨大プロンプトになることがあります。

例えば、

System Prompt       8,000 tokens
Tools              15,000 tokens
Policies            5,000 tokens
Repository Context 30,000 tokens
Conversation        5,000 tokens
User Input            500 tokens

合計約63,500 tokens。

Agentが10回Tool Callすると、キャッシュなしでは同じ情報を何度も処理することになります。

LLM
 ↓
Tool
 ↓
LLM
 ↓
Tool
 ↓
LLM
 ↓
Tool

各LLM Callで共通Prefixを再利用できれば、大きな最適化になります。

このためPrompt Cachingは、

「長いプロンプトを使うAgentを現実的なコストで運用するための重要技術」

の一つになっています。

OpenAIのPrompt Caching

OpenAIでは長い共通Prefixを持つリクエストに対してPrompt Cachingを利用できます。

従来のPrompt Cachingでは、対象となる長いプロンプトについて共通Prefixが自動的にキャッシュされ、レスポンスのusageから、

cached_tokens

を確認できます。OpenAIは2024年のPrompt Caching発表時点で、1,024トークン以上の対応プロンプトについて、1,024トークンから128トークン単位で最長の一致Prefixをキャッシュすると説明していました。

現在のResponses APIでは、

prompt_cache_key

を使って共通Prefixを持つリクエストのキャッシュヒット率を高めるための制御も用意されています。

さらにGPT-5.6では、従来の暗黙的なキャッシュに加え、明示的なcache breakpointを指定できるPrompt Cachingも導入されています。現在のAPIリファレンスではprompt_cache_optionsによる制御が用意され、TTLのデフォルトは30分とされています。

したがって最新モデルでは、

完全に「全部自動」

だけでなく、

ここまでを再利用したい
──────────────↑
      cache breakpoint

という制御も可能になってきています。

ClaudeのPrompt Caching

Anthropic Claudeでは、

cache_control

を利用したPrompt Cachingが提供されています。

2026年8月時点では、

Automatic caching
Explicit cache breakpoints

の2種類があります。

Automatic cachingではトップレベルにcache_controlを設定すると、キャッシュ可能な最後のブロックまでを自動的にキャッシュします。

Explicit cachingなら、

System
Tools
Large Context
──── cache breakpoint ────
Dynamic User Message

のように、より細かく境界を設定できます。

Anthropicのドキュメントでは、デフォルトのキャッシュ有効期間は5分で、追加コストを伴う1時間のTTLも提供されています。

また、

tools
system
messages

など多くのコンテンツをキャッシュ対象にできます。

Agentで大量のTool定義を毎ターン利用する場合にも非常に有効です。

GeminiのContext Caching

Google Geminiでは、同様の仕組みを Context Caching と呼んでいます。

現在のGemini APIには、大きく、

Implicit Caching
Explicit Caching

という考え方があります。

Gemini 2.5以降ではImplicit Cachingがデフォルトで有効になっており、同一・類似のPrefixを再利用できた場合にコスト削減が適用されます。Googleもキャッシュヒット率を高めるため、

大きく共通するコンテンツをプロンプト前方に置く
類似Prefixを持つリクエストを近い時間に送る

ことを推奨しています。

また、明示的なContext Cacheを作成するAPIも用意されており、

CachedContent

として再利用するContextを管理できます。

つまり、

巨大なPDF
巨大な動画
巨大なドキュメント

を一度Contextとして登録し、

Question A
Question B
Question C

のように何度も問い合わせる用途にも向いています。

3社をざっくり比較

2026年8月時点で概念をざっくり整理すると、

Provider	機能	主な考え方
OpenAI	Prompt Caching	共通Prefixを再利用。現行モデルでは暗黙/明示的キャッシュ制御も進化
Anthropic	Prompt Caching	`cache_control`でAutomatic / Explicit caching
Google	Context Caching	Implicit caching + 明示的CachedContent

細かいAPI設計は違いますが、本質的には、

巨大な共通Context
       ↓
一度処理
       ↓
計算結果を再利用
       ↓
可変部分だけ追加処理

という考え方は共通しています。

Prompt Cacheが効きやすいケース

特に効果が期待できるのは次のようなケースです。

1. 長いSystem Prompt

System:
[5,000〜20,000 tokensの指示]

を毎リクエスト利用する場合。

2. AI Agent

Tool A schema
Tool B schema
Tool C schema
...
Tool Z schema

大量のTool Definitionを毎回送る場合。

3. RAG

同じ巨大なReference Contextに対して、

Question A
Question B
Question C

と繰り返し問い合わせる場合。

4. Document Analysis

100ページの契約書

に対して、

契約期間は？
解約条件は？
責任制限条項は？

と質問する場合。

5. Coding Agent

Repository Instructions
Coding Rules
Architecture Documents
Tool Definitions

などの固定Contextが大きい場合。

逆に効果が薄いケース

Prompt Cachingは万能ではありません。

例えば毎回、

完全に異なるDocument
+
完全に異なるPrompt

を送る処理。

Request1
AAAAAAAAAAAA

Request2
BBBBBBBBBBBB

Request3
CCCCCCCCCCCC

では共有Prefixがないため、キャッシュメリットはほぼありません。

また、

System Prompt: 300 tokens
User Prompt: 50 tokens

のようにPrompt自体が非常に短い場合も、キャッシュ管理の恩恵は限定的です。各プロバイダー・モデルにはキャッシュ対象となる最小トークン数などの条件もあります。

Prompt設計のBest Practice

Prompt Cacheを意識すると、Prompt構造は次のようにするとよいでしょう。

┌─────────────────────────┐
│ Stable System Prompt    │
├─────────────────────────┤
│ Stable Tool Definitions │
├─────────────────────────┤
│ Stable Policies         │
├─────────────────────────┤
│ Stable Documents        │
├─────────────────────────┤
│ Semi-static Context     │
├─────────────────────────┤
│ Dynamic User Context    │
├─────────────────────────┤
│ User Input              │
└─────────────────────────┘

↑ Static
│
│ Cacheしやすい
│
│
↓ Dynamic

つまり、

Stable → Dynamic

の順番です。

意外なCache Killer

実運用では、ほんの小さな変更でキャッシュ効率を落とすことがあります。

例えば、

Current Time: 2026-08-26T01:00:01

をSystem Promptの先頭へ入れてしまうケース。

毎回、

01:00:01
01:00:02
01:00:03

と変化するので、共通Prefixを壊してしまいます。

他にも、

request_id
session_id
random UUID
timestamp
user name
dynamic JSON

などを前方へ置くと同様です。

そのため、

System Prompt
Tools
Documents
Policies

--- dynamic ---
Timestamp
User Metadata
User Question

とするのが重要です。

「プロンプトの内容」だけではなくTool定義にも注意

Agent開発では、Tool Definitionが巨大になることがあります。

例えば、

{
  "name": "search_database",
  "description": "...",
  "parameters": {
    ...
  }
}

が50〜100個あるケースです。

毎回ツールの順番を、

A B C D E

から、

B A D C E

へ変えるだけでも、シリアライズされた入力Token列は変わります。

その結果、同じTool群でもPrefixの一致を損なう可能性があります。

したがってTool定義についても、

順序を固定する
schemaを毎回生成し直さない
不要な動的値を含めない

といった工夫が有効です。

Cache Hit率を監視する

Prompt Cachingは、

有効にしたからOK

ではありません。

重要なのは、

実際に何Tokenキャッシュされたか

です。

例えば、

Input Tokens:   50,000
Cached Tokens:  45,000

なら、

Cache Ratio = 45,000 / 50,000
            = 90%

です。

一方、

Input Tokens:   50,000
Cached Tokens:   2,000

なら、Prompt構造を見直した方がよいかもしれません。

OpenAIではusage内のcached_tokens、Geminiではusage.total_cached_tokensなど、各APIからキャッシュ利用状況を確認できます。

本番環境では、

Cache Hit Tokens
Cache Miss Tokens
Input Cost
TTFT
Request Latency

をまとめてObservability対象にするのがおすすめです。

Prompt Cachingは「LLMアプリの設計」を変える

Prompt Cachingを単なる、

API料金を安くする機能

として考えると少しもったいないです。

むしろ重要なのは、

LLMに渡すContextを「Static」と「Dynamic」に分離する

というアーキテクチャ上の考え方です。

例えば、

Static Layer
────────────────
System Prompt
Policies
Tool Definitions
Knowledge
Examples

Dynamic Layer
────────────────
Current State
User Context
Retrieved Data
User Question

という設計です。

これはPrompt Cachingだけでなく、

Prompt Versioning
Agent Architecture
Context Engineering
Observability
Cost Optimization

にもつながってきます。

まとめ

Prompt Cachingのポイントをまとめると、

1. LLMは長いPromptを処理するために大量の計算を行う

2. 同じPrefixについて、その計算を毎回やり直すのは無駄

3. Prompt Cachingによって計算済みPrefixを再利用する

4. その結果
   - Input Cost削減
   - TTFT短縮
   - Agent高速化
   が期待できる

5. Cache HitにはPrefixの一致が重要

6. そのためPromptは

   Static Context
       ↓
   Dynamic Context

   の順に設計する

ということになります。

特に今後、

AI Agent
MCP
Long Context
Coding Agent
RAG

の利用が増えるほど、一度のLLM Callに投入されるContextは巨大になります。

LLMアプリケーションの最適化では、

「何Token使っているか？」

だけでなく、

「そのうち何Tokenを毎回再計算しているか？」

を見ることが重要になります。

Prompt Cachingは、単なるキャッシュ機能というより、

Context Engineeringにおける重要な最適化技術

として理解しておくとよいでしょう。

参考資料

OpenAI, Prompt Caching / API documentation
OpenAI, GPT-5.6 Builder's Guide
Anthropic, Prompt Caching documentation
Google AI for Developers, Context Caching