Prompt Cache 実測：同じ呼び出し量で請求が 62% 減

背景

Anthropic も OpenAI も 2024 年後半に prompt cache を順次投入しました。初回リクエストはキャッシュ書込価格（通常は入力価格の 1.25x）、以降のキャッシュヒットはキャッシュ読取価格（通常は入力価格の 10%）で課金されます。

理論上は大幅な削減です。しかし 理論と実際の間には「キャッシュヒット率」が横たわっています。 ZetaAPI 自身のカスタマーサポート agent と codegen パイプラインで 1 か月実測しました。

テストシナリオ

• シナリオ A：サポート agent — システムプロンプト固定（約 3,200 トークン）、ユーザーの質問は変化、対話は累積。日均 18k 回。
• シナリオ B：codegen パイプライン — プロジェクト文脈の前置部（約 12k トークン）はリポジトリ変更で更新、同一リポジトリの連続呼び出しは前置部を再利用。日均 4k 回。

両シナリオとも cache_control: { type: 'ephemeral' } でシステムプロンプトをマークします。

結果

シナリオ	キャッシュヒット率	元の入力コスト	cache 有効後	節約
サポート agent	88%	$300/日	$103/日	66%
codegen パイプライン	71%	$643/日	$279/日	57%
総合	82%	$943/日	$382/日	59.5%

月初の請求対account を加味すると、月全体での節約は 62% でした。

どんなリクエストがヒット率が高いか

データから、ヒット率を決める要因を重み順に：

1. 前置部の安定性 — システムプロンプトが長期不変なら、ヒット率は一気に 80%+
2. 呼び出し密度 — Anthropic の ephemeral cache は TTL 5 分。呼び出しが密なほど同一 TTL ウィンドウに収まりやすい
3. 前置部の長さ — 1,024 トークン未満の前置部はキャッシュ閾値にすら入らない

直感に反する発見

当初は codegen の方がサポートよりヒット率が高いと考えていました——プロジェクト文脈の方が「安定」だと。しかし実際には codegen はコミットのたびにキャッシュを断ち切り、実ヒット率はむしろ 17 ポイント低かったのです。

キャッシュは時間軸の最適化であって、意味軸の最適化ではありません。 プロンプトは 1 トークン変わるだけで、前回とは無関係のまったく新しいプロンプトになります。

接続側へのアドバイス

• システムプロンプトはなるべく不変のテンプレートにし、動的部分はユーザーメッセージに置く
• バッチタスクは優先的に同一バッチで投入し、TTL をまたぐ数波に分けない
• ephemeral タグの位置は、システムプロンプト全体の末尾ではなく、最長の不変前置部の末尾に置く

今後コンソールに API キーごとのキャッシュヒット率統計を追加し、接続側が cache を有効化できているか自分で判断できるようにします。