LLM APIのプロンプトキャッシュは「同じ接頭辞を送れば毎回ヒットする」設計のはずだ。だがAnthropic Sonnet 4.6 APIを実測した研究では、ヒット率が理論値（ρ=1.0）ではなくρ≈0.83で頭打ちになり、約3,500トークンを境に挙動が変わる「二段階構造」が見つかった。原因の一端は、質問ごとにプロンプトの中身を変える、よくある「賢い」圧縮手法そのものにある。
キャッシュヒット率が理論値より下がる具体的な条件、その原因になる「クエリ対応型プロンプト圧縮」の落とし穴、そしてプロンプトの書き方だけで防ぐ具体的な手順。
LLM APIのプロンプトキャッシュは、同じ接頭辞（プレフィックス）を送れば理論上は毎回ヒットするはずの仕組みだ（ヒット率ρ=1.0）。だがarXivに投稿された論文「Cache-Aware Prompt Compression」がAnthropic Sonnet 4.6 APIを対象に実測したところ、30回連続の呼び出しセッションでもヒット率は理論値に届かず、約3,500トークンを境に挙動が変わる「二段階構造」が観測された。
具体的には、プロンプトの長さが約3,500トークン未満の領域でも、ヒット率はρ≈0.83で頭打ちになる。キャッシュ対象になっているはずのリクエストのうち、平均して6回に1回程度は理論どおりにヒットしていない計算だ。この論文は査読前の研究レポート（arXiv）で、Anthropic公式のキャッシュ仕様説明ではない点は先に断っておく——ただし、実測ベースで「なぜヒット率が落ちるのか」まで踏み込んで原因を特定している点に、実務的な価値がある。
節約のための工夫が、別の節約の仕組みを壊しているという構造。
プロンプトキャッシュは基本的に、プレフィックス（先頭部分）が1文字でも変わると別物として扱われるprefix-strictという単純な仕組みで動く。ところが、トークン節約のために質問内容に応じてプロンプトを動的に削る「クエリ対応型プロンプト圧縮」という手法が広く使われている。質問が変わるたびに圧縮結果（＝プレフィックス）も変わる設計のため、キャッシュ機構からは「毎回別のプロンプトが来た」ように見え、機械的にキャッシュが無効化される。
「プロンプトを賢く削って節約しよう」という工夫それ自体が、「同じ接頭辞を保てば安くなる」というキャッシュの前提を壊している。圧縮率を上げる個別最適化と、キャッシュヒット率を保つ全体最適化が対立するという、地味だが見落としやすい構造だ。
ここが核心。プロンプトを「質問ごとに」削るのではなく、削り方そのものを固定し、質問ごとに変わる部分をプレフィックスの外（後ろ）に追い出すことでしか、圧縮とキャッシュは両立しない。
論文が提案する CAPC（Cache-Aware Prompt Compression）は、①クエリの内容に関係なく同じ圧縮結果を返す「クエリ非依存の圧縮」、②APIのcache_controlを明示的に指定する、③圧縮しすぎてキャッシュの階層構造（tier）を壊さないための比率上限、の3点で構成される。
検証用データセットLongBench-v2では、キャッシュだけを使った場合と比べて49%のコスト削減、一般的なクエリ対応型圧縮と比べると64%のコスト削減を達成したと報告されている。実運用に近いケース（94,000トークンの巨大なスキーマをプレフィックスに持つ本番ワークロード）でも51.7%のコスト削減が確認された。もう一つの検証セットtau-benchでは、コストを最も抑えながら50タスク中36タスクで応答品質を維持したという。
自分でCAPCそのものを実装しなくても、この論文の発見から得られる教訓はシンプルだ——プロンプトの前半（システムプロンプト・固定の指示・スキーマなど）は一切変えず、質問ごとに変わる部分は必ず末尾に置く。これだけで「毎回微妙に違うプレフィックスを送って、自分でキャッシュを殺す」事故を避けられる。
以前書いた「会話を始める前に3万3000トークン消費している」という実測記事は、ツール定義やシステムプロンプトという"動かせない固定費"の大きさを扱った。今回の話は、その固定費側の話ではなく、自分がコントロールできるはずの可変部分の置き方の話になる。固定費を削れなくても、可変部分の置き場所を間違えなければ、キャッシュはちゃんと効く。
研究レポートの数値を、明日から使える書き方の判断に変換する。