LLM プロンプトキャッシュ完全ガイド 2026：入力コストを 50～90% 削減

大規模言語モデルを使ったチャットボット、RAG アプリ、AI エージェントを提供するなら、プロンプトキャッシュは最も効果の大きい最適化です。品質を落とさず、入力コストを 50～90% 削減し、最初の token が返るまでの時間を 3～10 倍高速化できます。後付けの小技ではありません。Transformer の attention の定義から自然に導かれる仕組みです。そこを理解すれば、TTL、プロバイダーごとの差、プロンプト構造まで一貫して理解できます。

TL;DR

• プロンプトキャッシュは、品質を落とさず、入力コストを 50-90% 削減し、最初の token が返るまでの時間を 3-10x 高速化します。
• 2026-05-25 の計測では、Claude の cache_control marker により入力コストが 88-89% 減少しました。GPT-5.4-mini の auto-cache では TTFT が 3.6s から 0.73s に短縮されました。DeepSeek-v4-flash の disk-backed cache では 74% 割引になりました。
• TTL が短いのは、KV state が非常に大きいためです。70B クラスの model で 32K-token context を保持すると、およそ 10 GB を消費します。
• DeepSeek のキャッシュ粒度は 64-token です。一般的な 1,024-token の下限より細かいため、prefix の一部だけが一致した場合でも割引が適用されます。

このページは、理論から本番環境向けの判断 matrix、さらに実際にプロンプトを組み立てる framework 層まで扱う全 5 回のシリーズの目次です。すでに知っている内容に合わせて、必要なところから読んでください。

どこから読むべきか

各回は単独でも読めます。順番に読めば、内容が重複することなく全体像を把握できる構成です。

第 1 回：LLM プロンプトキャッシュの仕組み

LLM プロンプトキャッシュの仕組み：KV Cache と TTL を解説 →

アーキテクチャを扱う記事です。self-attention を 1 つの式で示し、安定した prefix の K vector と V vector を数学的に再利用できる理由を説明します。さらに、メモリと計算量の tradeoff が、すべての開発者が考慮すべき TTL の挙動にどうつながるかを解説します。

要点：

• プロンプトキャッシュは後付けの最適化ではなく、causal-masked attention から直接導かれます。位置 i の K/V は token 1…i の決定論的な関数なので、同じ prefix からは bit 単位で同一の K/V が得られます。
• キャッシュによって省略できるのは、compute-bound で O(N²) の prefill です。decode は token ごとに O(N) の memory-bandwidth-bound な処理であり、どの inference engine でもすでに最適化されています。
• TTL が存在するのは、KV cache が非常に大きいためです。70B model で 32K context を保持すると約 10 GB になります。5 分という TTL は GPU のメモリ圧力を考慮した時間幅です。数時間から数日保持できるのは、DeepSeek の MLA architecture のような disk-backed cache に限られます。
• キャッシュは、コストとレイテンシの両方に効きます。cache hit 時の入力料金は 50～90% 安くなります。5～10K-token のプロンプトでは TTFT が 3～10 倍短縮され、100K-token を超えると効果はさらに大きくなります。

第 2 回：プロバイダー別に LLM プロンプトキャッシュを比較

プロンプトキャッシュ比較：Claude、GPT-5、Gemini、DeepSeek、Qwen（2026）→

プロバイダー選定のための記事です。5 社はそれぞれ大きく異なる方法でプロンプトキャッシュを提供しています。Claude は明示的な marker、GPT-5 と DeepSeek-v4 は完全自動、Gemini と Qwen は implicit と explicit の hybrid、DeepSeek の MLA は architecture レベルで disk-backed cache を採用しています。機能ごとの比較に加え、実際の workload に合わせて評価するための 5 次元の評価 framework を示します。

要点：

• 基本料金だけを比較してはいけません。hit rate で重み付けした実効コストを比較してください。計算式は §4.1 にあります。リアルタイムの LLM 料金比較 と コスト計算ツール を使えば、自分の workload に当てはめて確認できます。
• Claude は単一 call で最も大きい約 90% の割引を提供しますが、明示的な cache_control marker が必要です。
• 大規模な disk-backed cache を提供しているのは DeepSeek-v4 だけです。粒度が 1,024 token ではなく 64 token なので、prefix の一部だけが一致した場合も割引されます。
• Gemini の explicit cache には 1 時間単位の保存料金がかかります。損益分岐点は call 頻度で決まります。
• hit rate を揃えて比較した場合、プロバイダーを実質的に区別するのは、API の使いやすさ、hit rate の予測可能性、TTL との適合、cache miss 時のレイテンシ、移行コストという 5 つの観点です。

第 3 回：実践 Python チュートリアル

Python で使う LLM プロンプトキャッシュ：動くコードで学ぶチュートリアル →

実装中心の記事です。単一 gateway に対して OpenAI SDK と Anthropic SDK を 1 つずつ使います。2026-05-25 に Claude の全 family（haiku-4-5 から opus-4-7）、GPT-5.x、Gemini 2.5、DeepSeek-v4、Qwen3 を計測した結果も掲載しています。

要点：

• cache_control marker を使った Claude：haiku、sonnet、opus の 4-x 全体で、88～89% のコスト削減を一貫して確認しました。Anthropic SDK に base_url="https://synthorai.io/" を指定して使います。
• GPT-5.4-mini auto-cache：7K-token のプロンプトで TTFT が 5 倍改善し、3.6 s から 0.73 s になりました。system token の cache hit rate は 93% です。
• Gemini 2.5-flash implicit：streaming の usage を取得した場合、cache hit 時のコストが 88% 減少しました。
• DeepSeek-v4-flash：74% 割引です。disk-backed なので、1 時間単位で idle 状態が続いてもキャッシュが残ります。
• TTL を考慮した pattern：cron 向けの keep-alive heartbeat、prefix を安定させるルール、call ごとに記録すべき log 項目を扱います。

第 4 回：用途別の最適な Model

チャット、RAG、エージェントに最適な LLM：2026 年版 Model ＋ コスト判断 Matrix →

model 選定の記事です。コストとレイテンシに影響する要因は workload ごとに異なります。チャットは自然にキャッシュが効きやすく、RAG では prefix の安定性が課題になります。エージェントでは、累積 prefix を崩さない設計が重要です。workload の特性ごとに、コスト見積もりを含む model の推奨を示します。

要点：

• チャットボット：auto-cache 対応 model ならどれでも使えます。session 内では自然に hit するため、コストと品質で選びます。最安は gpt-5.4-nano、キャッシュ適用時の TTFT が最速なのは gpt-5.4-mini、多少高くても instruction-following を重視するなら claude-haiku-4-5 が最適です。
• RAG：取得した document の順序が変わると、プロンプト中盤以降の cache hit が失われます。対策は 3 つです。reference を末尾に置く、chunk の順序を決定論的にする、または Claude の複数 cache_control breakpoint を使います。
• エージェント：tool call と result は追記のみとし、各 step で byte 単位まで同一に保つ必要があります。4 個の cache_control marker を使う claude-sonnet-4-5 は、累積 prefix に対して最も大きな割引を得られます。gpt-5.4-mini はコード変更なしで動作し、50% 削減できます。
• TTL の選び方：チャットは 5 分、人間の確認を挟むエージェントは 1 時間、断続的な batch 処理には disk-backed cache が適しています。

第 5 回：LangChain との統合

LangChain プロンプトキャッシュ：確実にキャッシュを効かせる構成 →

framework 層を扱う記事です。第 1～4 回では、プロンプトの byte 列を自分で制御できる前提でした。LangChain はプロンプトを自動的に組み立てますが、最も便利な構文を使うと、気付かないうちに Claude のキャッシュが無効になります。langchain-core 1.4.8 で marker 付き system prefix を使って計測しました。

要点：

• ("system", "...") 形式の string-tuple template には cache_control を指定できません。同一 call を繰り返しても、キャッシュがまったく使われないことを計測で確認しました。content block を持つ SystemMessage に変更すれば解決します。
• プロンプトの順序が hit rate を左右します。静的な rule より前に RAG で取得した context を置くと、すべての call が cold write になりました。Claude では write premium がかかるため、キャッシュを使わない場合より高くなります。
• system block の marker は bind 済みの tool も対象にします。bind_tools の serialization は byte 単位で安定しており、Anthropic 形式の tool dict に付けた marker もそのまま渡されます。
• multi-turn agent では、marker を最新 message に移動します。各 turn で過去の prefix 全体を再読込し、差分だけを書き込めます。計測値は read 1,864、write 15 でした。
• 自動キャッシュ対応 model（GPT、GLM、DeepSeek）では、順序を間違えても何も通知されません。追加料金も error もなく、期待した割引だけが適用されません。usage field を監視してください。

このシリーズの読み方

• このテーマを初めて学ぶエンジニア：順番に読んでください。第 1 回のアーキテクチャを理解すれば、第 2～4 回の内容がすぐにつながります。
• ベンダー選定を担当する PM またはアーキテクト：第 2 回と第 4 回を先に読んでください。チームメンバーから「なぜ TTL が必要なのか」と聞かれたら、第 1 回を参照できます。
• 今日中に特定の workload をリリースしたいエンジニア：まず第 4 回で matrix の該当行を探し、次に第 3 回でそのまま使えるコードを確認してください。
• すでに LangChain を使っている場合：第 5 回から直接読んでください。第 3 回の raw SDK 向け pattern も応用できますが、string template、変数の配置、usage field 名といった落とし穴は framework 固有です。
• 既存アプリを最適化したい場合：第 3 回 §6 のプロバイダー横断 benchmark を参照してください。自分のプロンプトで再現する作業は 1 日で済み、数週間かかる移行ではありません。

このシリーズの計測値

第 1～4 回の数値は 2026-05-25、第 5 回の LangChain の数値は 2026-07-04 に計測しました。Synthorai gateway（OpenAI 互換は https://synthorai.io/v1、Anthropic native は https://synthorai.io/）を使い、single-tenant 環境で同時負荷をかけず、1 回の sequential run を実行した結果です。数値は region、時間帯、他 tenant の負荷によって変わります。あくまで初期値として扱い、引用する前に自分の traffic で再計測してください。

料金表と TTL の挙動は、2026-05 時点で公開されていた各ベンダーの document に基づいています。プロバイダーは数か月おきに内容を更新します。第 1 回のアーキテクチャ上の説明は変わりませんが、第 2 回と第 3 回の比較値は時間とともに変動します。

← ブログに戻る