一行定義

同じプロンプト接頭辞（system·tools·context）を再送信せずサーバー側に残して再利用し、入力コスト 10 分の 1·レイテンシ短縮を狙う最適化。

全体システムの中での役割

プロンプトキャッシュは、LLM を使うときの 「入力コストとレイテンシの支配的要因」を潰すための層 だ。

LLM の 1 回の呼び出しには、毎回同じものを積んで送っている部分がある。

• system prompt（エージェントの人格・ルール・ツール説明）
• tool definitions（MCP や function calling の仕様）
• 大きな文脈 (ドキュメント、コードベース、過去の会話履歴)

この接頭辞は「リクエストごとに書き換えられない」のに、普通の API では 毎回フルに token 課金されて、毎回フルに処理される。会話やエージェントのターンが進むほど、同じ長大プレフィックスを何度も入力に積むことになる。

プロンプトキャッシュはここを切り離す。指定した接頭辞を サーバー側に一時保存 (ephemeral cache) して、次のリクエストで「前と同じプレフィックスです」と参照すると、キャッシュヒット部分は

• 入力コストが最大で 1/10 程度まで下がる (Anthropic docs 準拠)
• 処理時間もその分短縮される

ように設計されている。

Anthropic の API では、Messages API のブロック単位で cache_control: { type: "ephemeral" } を明示的に貼る。system、tools、個別の content block にも貼れるので、「どこから先を使い回すか」をエンジニアが切り分けられる。TTL は標準 5 分で、同じ接頭辞がその時間内に再利用されるとヒット、放っておくと消える。

対する OpenAI は、同等の仕組みを 自動プロンプトキャッシュとして透過的に提供 している。開発者側で cache_control を貼る必要はなく、同じプレフィックスが連続して使われると勝手にキャッシュが効く。宣言する Anthropic 型と、黙って効く OpenAI 型、という差があるので、同じ「プロンプトキャッシュ」でも運用設計がだいぶ違う。

Claude Code のような agent harness では、このキャッシュが効くか効かないかでターンあたりコストがひと桁変わる。つまりこの用語は「細かい API 最適化」ではなく エージェント運用の経済性を決める柱 にある。

よくある誤解

• 誤解 1：プロンプトキャッシュ = 出力を使い回す仕組み、と思われがち。

– 実際には「入力プレフィックスの処理結果を使い回す」仕組みで、出力は毎回新規生成される。同じ質問を 2 回送れば、2 回モデルが考える。安くなるのは入力側の前処理だ。

• 誤解 2：キャッシュがあれば context window を実質無限にできる、と期待されがち。

– 実際にはキャッシュされていても、その接頭辞はモデルのコンテキストにちゃんと乗る必要がある。1M トークンのキャッシュを貼っても、1M を超える入力は入らない。キャッシュは容量を広げる機能ではなく、同じ容量を安く使う機能だ。

• 誤解 3：Anthropic の prompt caching は貼れば常にお得、と単純化されがち。

– 実際には cache write はむしろ 25% 高いトークンレート で課金される。短い 1 回だけの呼び出しに cache_control を貼ると、キャッシュヒットが取れずに高くつく。5 分の TTL 内に何度も同じプレフィックスを叩く想定があって初めて元が取れる。

この用語が重要な理由

読者の実務判断にこれが効くのは、「AI アプリの月額コストが現実的かどうか」 を決める層だからだ。

エージェントや社内 AI ツールを運用するとき、よく詰まるのはこういう質問になる。

• system prompt と tool 定義を毎回 2,000 トークン送っている。これを半年回したらいくらか
• RAG で常に 20,000 トークンのガイドを積んでいるが、これがユーザー 1 人あたりの原価を決めている
• Claude Code / Codex でセッションが長くなるほど重くなるのはなぜか

ここに対して「プロンプトキャッシュを貼ると何割取り返せるか」が言えるかどうかで、プロダクトの粗利率とエージェントの継続運用可能性が変わる。1M context の話がモデル選定の入口なら、prompt caching はその選んだモデルを ビジネスとして回す 側の入口だ。

この用語が登場する記事

• (発行後に追記)

次に読むべき用語 3 つ

• token — 課金単位。キャッシュ効果を金額で語るための前提。
• context window — 「容量」の軸。キャッシュは「コスト」の軸で同じ容量を安くする側。
• API — cache_control が実際に貼られる実装レイヤー。