プロンプトキャッシュは入力コストを削るが、本当の問題は解かない

要約

• プロンプトキャッシュは入力トークンの費用を50〜90%減らしますが、規模で支出を支配する出力トークンには一切触れません。
• キャッシュが効くのは、安定して頻度の高い接頭部だけです。ヒット率が低いのは、キャッシュの設定の問題ではなく、プロンプトの構造の問題を示しています。
• 各提供者は接頭部の完全一致を要求し、静かに失敗するキャッシュ（最小トークン数を下回る場合など）は、有効に見えたまま請求額を悪化させ得ます。
• 本当の手当ては、確率的な呼び出しを減らすことです。ルールベースの工程を決定論的なロジックへ変え、残ったものをキャッシュします。
• 規制下の企業にとって、Jinba Flowはワークフローの80%を決定論的なロジックとして構築し、1回あたりの費用を15〜60分の1にしつつ、監査可能性を担保します。

プロンプトキャッシュは主要な提供者のどこでもよく文書化されており、入力トークンの請求から意味のある一片を削ってくれます。しかしそれは、LLMのワークフローを決定論的にも、監査可能にも、そして規模で支出を支配する費目——いまも一回ごとに確率的な推測をしているモデルが生成する出力トークン——について安くもしません。業界がキャッシュを既定のコストの手当てとして選び取ったのは、有効にするのが簡単で、割引が本物だからです。まさにそれゆえに危険なのです。症状を割引しただけなのに、コストの問題を解いたとエンジニアリングの組織に思わせてしまいます。

プロンプトキャッシュが実際にしていること

プロンプトキャッシュ（プレフィックスキャッシュ、コンテキストキャッシュとも呼ばれます）は、直前のリクエストの接頭部について計算されたキー・バリュー（KV）のキャッシュを再利用します。まったく同じ接頭部を共有する新しいリクエストは、そのトークンの再計算を飛ばし、新しい後続部分だけを処理します。これは、ひとつのリクエストの内側にすでにある考えを機械的に延長したものです。KVキャッシュ自体はリクエスト内のもので、ひとつの生成のデコードの段階でアテンションの状態を再利用します。プレフィックスキャッシュは、その同じ再利用を複数のリクエストにまたがって広げます。これが、繰り返されるシステムプロンプトや伸びていくチャットの履歴を、繰り返しの出費ではなくコストの節約に変えます。

この仕組みには、回避の難しいルールがひとつあります。接頭部が完全に一致していなければなりません。空白、書式、トークンの順序——1文字違うだけでキャッシュは外れます。人間にとっては同じ意味の2つのプロンプトでも、キャッシュの境界までバイト単位で同一でなければ、まったくヒットしないことがあります。これは、コスト削減の売り文句の多くが飛ばす細部であり、キャッシュが本番で本当に元を取るかどうかを決める細部でもあります。

何を作り直すか判断する人にとって、キャッシュできる面がどこかは重要です。キャッシュできる面とは、静的なシステムプロンプト、ツールの定義、参照文書、そして再直列化された会話の履歴です。リクエストの末尾に置かれる利用者の一回きりの質問はその面には含まれず、定義上、毎回新しいものです。Amazon Bedrockでは、これがシステムプロンプト、システムの指示、メッセージの履歴にそのまま対応し、ツールの項目はモデルによってキャッシュ可能です。

プロンプトキャッシュではないもの

もっともよくある誤解は、プロンプトキャッシュとセマンティックキャッシュの混同です。どちらも「キャッシュ」という言葉を、違う意味で使っています。セマンティックキャッシュは入力と出力のテキスト全体を保存し、一致したときは保存済みの答えを返して、モデルを完全に迂回します。プロンプトキャッシュはそんなことはしません。保存済みの答えを返すことは決してありません。モデルは依然として動き、生成は依然として起こり、組織はモデルが生む出力トークンのすべてに依然として支払います。プロンプトキャッシュは、入力を読むことへの割引です。出力を書くことの近道ではありません。

この区別が、議論の全体をそのまま縮めたものです。経済性の異なるキャッシュの層が3つあります。提供者のプレフィックスキャッシュ（入力側のみ、完全一致、モデルは後続部分について依然として動く）、セマンティックな応答キャッシュ（埋め込みの類似度でモデルを迂回し、入力と出力の両方を節約する）、そして完全一致の応答キャッシュ（ハッシュの照会でモデルの呼び出しは一切なく、定型の照会に最適）です。出力の費用に触れるのは、後ろの2つだけです。どのベンダーの文書も最初に持ち出す提供者のプロンプトキャッシュは、もっとも節約の小さい層です。

各提供者の比較

いまや主要な提供者はいずれも何らかの形でこれを提供しており、価格の仕組みは各社で十分に近く、違いは中核の経済性というより、主にTTLと最小のブロックサイズにあります。

Anthropicの公開ベータは2024年8月に始まり、同年12月に一般提供へ。OpenAIは2024年10月に自動キャッシュを出荷。Googleは2024年5月のI/Oで明示的なコンテキストキャッシュを、2025年5月に2.5のモデル向けの設定不要の暗黙のキャッシュを導入しました。これはもはや新しくも実験的でもありません。成熟した、自分で有効にできる機能です。だからこそ、「LLMの請求が高すぎる」への反射的な答えになってしまったのです。

どの提供者も、開発者がキャッシュの境界を能動的に指定することを求めます。Anthropicはcache_control、Bedrockは「キャッシュのチェックポイント」、OpenAIはprompt_cache_breakpoint、Geminiは明示的あるいは暗黙のキャッシュです。並べ方の規律はどこでも同じで、安定しているものから安定していないものへ——まずツールの定義、次にシステムプロンプト、次に参照資料、次に会話の履歴、そして最後に生きた利用者の照会。とりわけAnthropicでは、あるブロックを変えるとそのブロックと、それ以降のすべてが無効になるため、動的なデータは末尾に置かなければ、ターンごとにキャッシュが崩れます。

プロンプトキャッシュが正しい選択になるときと、ならないとき

キャッシュが元を取るのは、本当に安定して頻度の高い接頭部があるときです。毎分数千回の呼び出しで再利用される長いシステムプロンプト、一度読み込んで繰り返し照会される文書、伸びていくが過去のターンを書き換えないチャットの履歴。5分のTTLは高いQPSの処理に、書き込みの割増が高い1時間の階層は中程度の頻度の用途に、OpenAIの24時間の延長保持はゆっくり進むバッチのエージェントに向きます。

元を取れなくなるのは、その「安定した」接頭部が実は安定していない瞬間です。売り文句と本番の現実は、ここで分かれます。Bedrockのキャッシュ書き込みは標準の入力単価の1.25倍かかり、Anthropicの5分の階層は、書き込み1回につきおよそ1.4回のキャッシュ読み出しで損益が分かれます。つまりヒット率がおよそ30%を下回ると、書き込みの割増が読み出しの節約を上回ります。キャッシュは常に正の効果を持つ梃子ではありません。揺れる接頭部に対して有効にすれば、請求を良くするどころか悪くすることもあり得ます。しかもどこかのダッシュボードは「キャッシュは有効です」と、それがキャッシュが効いていることと同じであるかのように報告し続けます。

ベンダーの文書が見出しではなく細字に埋める、第二の失敗の型もあります。Bedrockのキャッシュのチェックポイントには、モデルごとの最小トークン数があります。Claude 3.7 Sonnetは1,024トークン、Claude Opus 4.5、Sonnet 4.5、Haiku 4.5は4,096トークンです。指定したブロックがその最小を下回ると、推論は成功し、接頭部は静かにキャッシュされません。エラーもありません。警告もありません。リクエストはただ満額で走り、エンジニアリングのチームはキャッシュが効いていると信じています。クロスリージョンの推論はリスクを重ねます。需要の高い時間帯には、キャッシュの書き込みを減らすどころか増やすことがあります。プロンプトキャッシュはチェックボックスとして売られています。正しく運用することは、それ自体の失敗の型を持つ統合の規律であり、その失敗の型は静かなだけに、本物のお金を食います。

誰も正しく使っていない診断

見落とされている洞察は、キャッシュのヒット率を100%へ押し上げるべき指標として扱ってしまうことです。ヒット率は、直接最適化するKPIというより、プロンプトのアーキテクチャの炭鉱のカナリアとして理解するほうが適切です。プロンプトが本当に静的なのにヒット率が低い——安定しているはずの接頭部でおよそ60%を下回る——なら、それはキャッシュの問題ではありません。固定されているはずの部分に、動的な内容が漏れ出している合図です。

これのもっとも明確な証拠は、理論ではなく記録に残った事例です。ProjectDiscoveryは、動的な「作業記憶」をシステムプロンプトから末尾のユーザーメッセージへ移すことで、キャッシュのヒット率を7%から84%へ引き上げ、キャッシュから提供された98億トークンにわたってLLMの費用全体を59%削減しました。キャッシュの設定を触った人は誰もいません。手当ては構造的なものでした。固定されているはずのブロックから、状態を外へ移したのです。この59%の削減は、キャッシュを有効にしたことから生まれたのではありません。プロンプトが実は安定していなかったと気づき、安定するように作り直したことから生まれました。

これは議論の全体を組み替えます。キャッシュのヒット率12%を眺めているチームは、キャッシュの設定にさらなるエンジニアリングの労力を注いで解くべきキャッシュの問題を抱えているのではありません。キャッシュがずっと露わにしていた、プロンプトの設計の問題を抱えているのです。直感に反する点として、素朴に全文脈をキャッシュすると、境界を意図的に制御しなければ長い接頭部が再計算の面を広げ、レイテンシを上げることさえあります。「とにかく全部キャッシュする」という本能は、追いかけている当の結果に逆らって働きます。

正しくやってもなお取り逃がすもの

ここまでの但し書きのすべてに、きれいな手当てが施されたとしましょう。接頭部の並べ方は完璧、TTLの選択も正しく、ヒット率は80%超、チェックポイントの静かな失敗もなし。それでも組織は、そもそも問題の全体ではなかった請求の入力側を最適化しただけです。

キャッシュの割引は入力トークンについて50%から90%の幅にとどまり、出力トークンには一切触れません。長い文書を読んで短い答えを書くワークフローなら、それは本物の勝利です。しかし控えめなプロンプトを読んで、長く構造化された出力——契約書の赤入れ、KYCの要約、コンプライアンスのメモ——を書くワークフローでは、キャッシュの割引は請求の小さいほうの半分に当たっているだけです。そしてそれらの出力トークンのすべては、いまも確率的に次のトークンを選ぶモデルによって生成されています。規制下の企業が本当に気にしている根っこの問題は手つかずのままです。呼び出しは依然として確率的で、出力が二度同じである保証はなく、入力の90%引きは、その出力を監査可能にはしません。

銀行・保険会社のためのJinbaのワークフローのアーキテクチャは、この区別を軸に作られました。銀行のコンプライアンスのチームがまず問うのは、「そのAPIの呼び出しはいくらだったか」ではありません。同じ書類を二度走らせたとき同じ分類が出るのか、そしてその判断を18か月後に検査官のために再構成できるのか、を問います。プロンプトキャッシュは、そのどちらの問いにも意見を持ちません。メーターの読みを生むアーキテクチャに触れないまま、メーターだけを最適化します。入力側のコストの割引と決定論的な実行の間のこの緊張関係については、トークン費用を下げるためのプロンプト最適化と決定論的ワークフローの比較でより詳しく扱っています。

Jinbaが違う判断をしたのは、そこです。確率的な呼び出しの入力側をキャッシュして割引が積み上がることを願うのではなく、あるワークフローの実行の経路のおよそ80%を、決定論的でルールベースのロジックとして構築します。LLMを呼ぶのは、本当に判断を要する残りの工程だけです——境界的な書類の分類、曖昧な項目の抽出、自由記述の要約。銀行・保険会社は、AIコストを下げる決定論的なワークフローで同じアプローチを採れます。工程の大半が、割引された限界費用ではなく、実行あたりのLLMの限界費用ゼロを担うため、コストの構造は「確率的な呼び出しを安くする」ではなく「確率的な呼び出しを減らす」になります。規模で見れば、それはワークフローの1回あたりの支払いが15〜60分の1になるか、キャッシュで最適化されたとはいえ根本的には確率的な請求を払い続けるかの違いです。さらに、ワークフローの決定論的な大部分は本質的に再現でき記録されます——キャッシュの割引が、ヒット率がどうであれ決して届けられなかったものです。

率直な反論

ここまでの議論へのもっとも強い反論は率直なものです。実際の支出の大きな塊に対する90%の割引は依然として本物のお金であり、すべてを解決しないからといって退けるのは誤った二者択一だ、という反論です。両者は排他的ではありません。本当に安定した高QPSの接頭部を回していて、まだキャッシュしていないチームは、理由もなく割引を放置しています。接頭部が安定していてヒット率も健全なら、キャッシュを有効にすることはほぼタダで手に入るお金であり、「本当の手当てではない」からと無視するエンジニアリングのリーダーは、逆方向で同じ間違いを犯しています。正当な戦術上の勝ちを、目を向けるに値しないものとして扱っているのです。Claudeを規模で展開する企業も同じ二者択一に直面します。オンプレミスでのClaudeの展開の選択肢については、別途扱っています。

この反論は成り立ちますし、結論ではなく枠組みのほうを変えるべきです。キャッシュは、本当に安定して量の多い接頭部に対する、正しく労力の小さい最適化です。そこで使っていないチームは、お金を置き去りにしています。失敗はキャッシュを使うことにあるのではありません。失敗は、キャッシュの割引を、コストと信頼性の問題に手当てがなされた証拠として扱うことにあります。実際には、出力側では依然として確率的な呼び出しの、入力側にだけ手当てがなされたにすぎません。キャッシュとバッチAPIに厚く投資したチームが、コストの問題はもう解決したと感じるのは無理からぬことです。そしてその感覚こそが、より深い手当てを社内で通しにくくします。ダッシュボードは請求が下がったことを示します。しかし、それらの呼び出しのひとつひとつが、決定論という点ではいまもコイン投げであることは示しません。

最初に走らせるべき最適化

1トークンあたりの費目だけでなく、推論の総費用とアーキテクチャに責任を持つエンジニアリングのリーダーにとって、順序が重要です。キャッシュの設定に手を伸ばす前に、診断を走らせましょう。安定していると仮定しているプロンプトについて、いまのキャッシュのヒット率はいくつか。費用に責任を負う購買者はより広い梃子を使います。それはエンタープライズのAIコスト削減のための2部構成のCFO向けフレームワークに整理しています。ヒット率が健全なら——TTLの階層に応じて、おおむね60〜80%を超えていれば——キャッシュは役目を果たしており、残る梃子は本当に出力の費用の側にあります。低いなら、それは工学で回避すべきキャッシュの問題ではありません。プロンプトの構造の問題であり、手当てはProjectDiscoveryの一手です。静的なはずの接頭部の中に座っている動的な内容を見つけ、リクエストの末尾へ移すのです。

その診断のあとで初めて、より難しい問いを立てるべきです。このワークフローの工程のうち、本当に確率的なモデルの呼び出しを要するのはいくつで、必要ではなく便利さからLLMを経由しているのはいくつか。既知の分類体系に照らした書類の分類、ルールに照らした項目の検証、明確な分岐のロジックを持つ振り分けの判断——これらは、決定論的に教えられるはずの答えをモデルに推測させる必要がありません。モデルの呼び出しからルールベースのロジックへ変えた工程はどれも、費用の一行と監査可能性の穴を、一手で同時に取り除きます。この並べ替え——まずキャッシュを診断し、次にアーキテクチャを点検し、それから残ったものをキャッシュする——こそ、費用に責任を負う購買者が走らせるべき順序です。割引しやすい半分だけでなく、請求の両方の半分に触れる唯一の順序だからです。

よくある質問

プロンプトキャッシュは、出力トークンの費用を減らしますか？いいえ。どの提供者のキャッシュの割引も、キャッシュから読み出された入力トークンに適用されます。モデルは呼び出しのたびに応答をゼロから生成し、入力がどう提供されたかにかかわらず、出力トークンは満額で課金されます。

プロンプトキャッシュは、Redisのようなアプリケーションのキャッシュと同じものですか？いいえ。従来のキー・バリューやRedisのキャッシュは、計算を一切伴わずに保存された値を返します。プロンプトキャッシュは、リクエストの新しい部分についてモデルを依然として走らせます。変わっていない接頭部についてKVの状態を再計算することを飛ばすだけなので、減るのは計算であって、呼び出しではありません。

キャッシュのヒット率が低いとき、モデル自体は問題なくプロンプトだけが壊れている、ということはあり得ますか？はい。しかも、これが手に入るもっとも有用な捉え直しです。静的だと仮定していたプロンプトでヒット率が低いのは、たいてい、タイムスタンプ、セッションの状態、取得した文脈といった動的な内容が、固定されているはずのブロックの中に座っているからです。それはモデルや基盤の問題ではなく、プロンプトエンジニアリングの手当てです。

プロンプトキャッシュを有効にすれば、レイテンシは必ず下がりますか？自動的にそうなるわけではありません。素朴に全文脈をキャッシュすると、キャッシュされた接頭部が長く、境界が意図的に制御されていない場合、外れたときの再計算の面が広がるため、レイテンシが上がることがあります。

規制下の企業は、監査への備えをプロンプトキャッシュに頼れますか？いいえ。キャッシュが変えるのは、リクエストがどう課金され提供されるかであって、根っこのモデルの呼び出しが決定論的かどうかではありません。キャッシュされた呼び出しも、されていない呼び出しも、再現性の性質は同じです。どちらにせよ、モデルは確率的な出力を生成しています。