プロンプトキャッシュとは？AI APIのコストと応答速度に効く仕組み

先に要点

プロンプトキャッシュは、AI APIで繰り返し使う長い入力の前半部分を再利用し、入力コストや待ち時間を下げやすくする仕組みです。
効きやすいのは、長いシステム指示、ツール定義、JSON Schema、社内ルール、参照ドキュメントを何度も使う場面です。
基本は「固定部分を前に、ユーザーごとに変わる部分を後ろに置く」ことです。
キャッシュが効いても、出力トークンの生成やAPIのレート制限まで消えるわけではありません。

AI APIを使っていると、同じような長いプロンプトを何度も送ることがあります。
たとえば、システムメッセージ、ツール定義、出力JSONのスキーマ、社内ルール、長い仕様書、コードベースの説明を毎回入れるケースです。

このとき問題になるのが、入力トークンのコストと応答速度です。
モデルに渡す情報が長いほど、API料金は増えやすく、最初の応答までの待ち時間も伸びやすくなります。

プロンプトキャッシュは、この「毎回ほぼ同じ長い入力」を再利用し、コストとレイテンシを下げるための仕組みです。
この記事では、2026年4月23日時点で OpenAI のプロンプトキャッシュ、料金、レイテンシ最適化、Anthropic のプロンプトキャッシュ公式ドキュメントを確認しながら、実務でどう効くのかを整理します。

AI API全体の料金やモデル選びから押さえたい場合は、AIのAPIとは？初心者向けに料金・トークン・モデル選びをわかりやすく解説も先に読むとつながりやすいです。

プロンプトキャッシュとは

プロンプトキャッシュは、AI APIに送る入力のうち、以前と同じ部分を再利用して処理を軽くする仕組みです。
特に重要なのは、同じ前半部分、つまり prefix が繰り返されると効きやすいことです。

OpenAIの公式ドキュメントでは、モデルに渡すプロンプトにはシステムプロンプトや共通指示のような繰り返し内容が含まれやすく、最近同じプロンプトを処理したサーバーへリクエストをルーティングすることで、コストとレイテンシを下げられると説明されています。

かなりざっくり言うと、次のようなイメージです。

部分	例	キャッシュとの相性
固定部分	システム指示、ツール定義、出力形式、共通ルール、長い参考資料	同じ内容ならキャッシュに乗りやすい
変動部分	ユーザーの質問、現在時刻、検索結果、個別の入力データ	毎回変わるためキャッシュに乗りにくい
出力	モデルが今回生成する回答	キャッシュで不要になるわけではない

なぜコストに効くのか

AI APIの料金は、多くの場合、入力トークンと出力トークンで分かれます。
さらに最近のAPIでは、入力トークンの中でも 通常の入力 と キャッシュ済み入力 が別料金として扱われることがあります。

OpenAI の Pricing ページでは、Text tokens の料金表に Input / Cached input / Output が分かれて表示されています。
2026年4月23日時点の公開料金では、GPT-5.4 は標準処理で Input が $2.50 / 1M tokens、Cached input が $0.25 / 1M tokens と案内されており、キャッシュ済み入力は通常入力よりかなり低い単価です。

つまり、毎回10,000トークンの共通指示を送っているようなアプリでは、そこがキャッシュヒットするかどうかで請求額が大きく変わります。

ポイント

プロンプトキャッシュは、出力料金を安くする仕組みではありません。主に、繰り返し送る入力側の処理と課金を軽くする仕組みです。

なぜ応答速度に効くのか

長い入力を処理するとき、モデルはまず入力を読み込み、内部表現を作ります。
この入力処理の部分が重いほど、最初のトークンが返るまでの時間が伸びます。

OpenAIの公式ドキュメントでは、プロンプトキャッシュによりレイテンシを最大80%削減できる場合があると説明されています。
また、Latency optimization のドキュメントでも、長いコンテキストを扱うときはプロンプトを prefix へ置き、リクエストをKV cache friendlyにする考え方が紹介されています。

ただし、ここで誤解しやすいのは、すべての応答が一瞬になるわけではないことです。
キャッシュは入力処理を軽くするものなので、モデルが長い回答を生成する時間、ツールを呼ぶ時間、外部検索やDBアクセスの時間は別に残ります。

何をキャッシュできるのか

OpenAIの公式ドキュメントでは、Messages、画像、ツール、Structured Outputs のスキーマなどがキャッシュ対象として説明されています。
つまり、単なる文章だけでなく、ツール定義や構造化出力の形も、同じ prefix に含まれるならキャッシュに関係します。

実務では、次のようなものが対象になりやすいです。

長い system message
開発チーム共通のコーディング規約
ツール定義や function schema
JSON Schema や Structured Outputs のスキーマ
長い利用規約、社内規程、FAQ、仕様書
コードレビュー用の固定ルール
エージェントの行動ルール

逆に、ユーザーごとに毎回変わる質問、検索結果、日時、画面入力、最新のDB結果はキャッシュに乗りにくいです。

どう書くと効きやすいか

いちばん大事なのは、固定部分を前に置くことです。
OpenAI のベストプラクティスでも、静的な指示や例をプロンプトの先頭に置き、ユーザー固有の情報のような変動部分を末尾に置くことが推奨されています。

たとえば、次のように分けます。

順番	置くもの	理由
1	固定のシステム指示	毎回同じ prefix にしやすい
2	ツール定義、出力形式、共通ルール	長くなりやすく、繰り返し使うことが多い
3	共通の参考文書や例	同じ資料に対して何度も質問する場合に効きやすい
4	ユーザーの今回の質問	毎回変わるため後ろに寄せる
5	検索結果、現在時刻、個別データ	変動が大きく、前に置くとprefix一致を壊しやすい

悪い例は、毎回違う情報を先頭に置いてしまうことです。

現在時刻: 2026-04-23 07:30
ユーザーID: 12345
今回の質問: ...

固定の長いルール...
固定のツール定義...

この形だと、先頭が毎回変わるため、長い固定ルールが後ろにあってもキャッシュヒットしにくくなります。

よりよい形は、こうです。

固定の長いルール...
固定のツール定義...
固定の出力形式...

現在時刻: 2026-04-23 07:30
ユーザーID: 12345
今回の質問: ...

この方が、共通の前半部分を再利用しやすくなります。

OpenAI APIではどう見ればよいか

OpenAI の Prompt Caching は、対応モデルでは基本的に自動で動きます。
ドキュメントでは、キャッシュは1024トークン以上のプロンプトで有効になり、1024トークン未満のリクエストでも usage.prompt_tokens_details.cached_tokens は返るものの、その場合は0になると説明されています。

確認すべきなのは、レスポンスの usage です。

{
  "usage": {
    "prompt_tokens": 2006,
    "completion_tokens": 300,
    "total_tokens": 2306,
    "prompt_tokens_details": {
      "cached_tokens": 1920
    }
  }
}

ここで cached_tokens が増えていれば、入力の一部がキャッシュヒットしています。
逆に、毎回長い入力を投げているのに cached_tokens がほぼ0なら、prefix が揃っていない、短すぎる、リクエスト間隔が空きすぎている、ツール定義や画像指定が微妙に変わっている、といった原因を疑います。

OpenAI では、prompt_cache_key や prompt_cache_retention を使ってキャッシュの効き方を調整できる場合もあります。
ただし、まず見るべきなのは「プロンプト構造が固定部分から始まっているか」と「usageをログで見ているか」です。

Anthropic APIとの違い

Anthropic のプロンプトキャッシュは、OpenAIとは運用の見え方が少し違います。
Anthropicのドキュメントでは、cache_control を使ってキャッシュのブレークポイントを指定する形が説明されています。

また、料金も Base Input Tokens / Cache Writes / Cache Hits のように分かれます。
キャッシュへ書き込む初回は通常入力より高め、キャッシュヒット時は通常入力よりかなり安い、という設計です。

ここから分かるのは、プロンプトキャッシュは「AI APIなら全部同じ」ではないことです。

観点	OpenAI	Anthropic
基本の使い方	対応モデルで自動的に効く	cache_control で明示する
確認する値	cached_tokens	cache_read_input_tokens / cache_creation_input_tokens など
設計の中心	同じprefixを作る、必要に応じてcache keyやretentionを使う	どこまでをキャッシュ対象にするか、breakpointを設計する
注意点	自動でもprefixが揃わなければ効きにくい	書き込み料金とヒット率のバランスを見る必要がある

向いている場面

プロンプトキャッシュが向いているのは、長い固定入力を何度も使う場面です。

社内ルール付きチャット

回答方針、禁止事項、文体、FAQ、業務ルールを毎回読ませる場合に効きやすいです。

AIエージェント

ツール定義、権限ルール、出力形式、停止条件が長くなりやすいため、固定prefixを作る価値があります。

コードレビュー支援

レビュー観点、コーディング規約、出力フォーマットを固定し、差分だけ後ろに置くと扱いやすいです。

長文ドキュメントQA

同じ資料に対して複数の質問をする場合、資料部分をキャッシュに乗せられると効果が出やすいです。

向いていない場面

一方で、次のような場面では効果が限定的です。

入力が短い
毎回まったく違う質問だけを送る
固定部分より変動部分の方が大きい
リクエスト間隔が長く、キャッシュが残りにくい
毎回ツール定義やスキーマを動的に組み替えている
出力が非常に長く、コストの大半が出力トークン側にある

特に見落としやすいのは、出力トークンです。
プロンプトキャッシュで入力側が安くなっても、長い回答を毎回生成していれば、全体コストはあまり下がらないことがあります。

よくある誤解

キャッシュされれば回答も使い回される？

違います。
プロンプトキャッシュは、最終回答をそのまま保存して返す仕組みではありません。入力処理を再利用しても、出力はそのリクエストごとに生成されます。

短いプロンプトでも効く？

多くの場合、短い入力では効果がありません。
OpenAIのドキュメントでは、Prompt Caching は1024トークン以上のプロンプトで有効になると説明されています。

キャッシュすればレート制限も軽くなる？

OpenAI のFAQでは、cached prompts もTPM rate limitsに寄与すると説明されています。
つまり、キャッシュは料金やレイテンシには効いても、レート制限を消すものではありません。

機密情報を入れても安全？

ここはAPI事業者のデータ管理条件を必ず確認します。
OpenAIのドキュメントでは、プロンプトキャッシュは組織間で共有されないこと、また in-memory retention と extended retention で Zero Data Retention との扱いが異なることが説明されています。

実務では、キャッシュ以前に、AIへ渡してよい情報かを先に判断します。
機密情報や個人情報の扱いは、AIに渡すプロンプトや入力情報で気を付けること｜機密情報・個人情報・著作権・プロンプトインジェクションも確認してください。

実装前のチェックリスト

プロンプトキャッシュを狙うなら、最低限この順で見ます。

長い固定入力が本当にあるか
固定部分をプロンプト先頭へ寄せたか
ユーザー入力、日時、検索結果などの変動部分を後ろへ寄せたか
ツール定義やJSON Schemaを毎回同じ順序で渡しているか
usageログで cached tokens や cache read/write tokens を記録しているか
入力コスト、出力コスト、レイテンシを分けて見ているか
キャッシュ保持時間やデータ管理条件を確認したか
キャッシュが効かない場合でも成立する料金設計になっているか

プロンプトキャッシュは、設計が合えばかなり効きます。
ただし、効く前提で料金見積もりを組むと危険です。初回リクエスト、キャッシュミス、低頻度アクセス、prefix崩れは必ず起きます。

まとめ

プロンプトキャッシュは、AI APIで繰り返し使う長い入力を再利用し、入力トークンのコストと応答待ち時間を下げやすくする仕組みです。
特に、システムプロンプト、ツール定義、出力スキーマ、社内ルール、長い参照文書を何度も使うアプリでは効果が出やすいです。

実務で大事なのは、固定部分を前に置き、変動部分を後ろに置き、usageログで本当に効いているかを見ることです。
キャッシュは魔法ではありませんが、長いコンテキストを扱うAIアプリでは、コスト設計と速度改善のかなり重要な部品になります。

参考リンク

OpenAI Docs: Prompt caching
OpenAI Docs: Pricing
OpenAI Docs: Latency optimization
Anthropic Docs: Prompt caching