プロンプトキャッシュコスト最適化（プロンプトキャッシュコストサイテキカ）
LLMのプロンプトキャッシュ機能を活用してAPI利用コストを体系的に削減する設計手法。キャッシュ書き込みコスト・読み取り割引・TTL・ヒット率を総合的に考慮し、費用対効果を最大化する。
プロンプトキャッシュコスト最適化とは
プロンプトキャッシュコスト最適化は、LLM APIのキャッシュ機能を戦略的に活用して運用コストを最小化する設計アプローチである。単にキャッシュを有効化するだけでなく、プロンプト構成・リクエストパターン・モデル選択を総合的に設計し、キャッシュの費用対効果を最大化することが目標となる。
大規模アプリケーションではLLM APIの月額コストが数千〜数万ドルに達することがあり、キャッシュ最適化による10-20%の改善でも大きな絶対額の削減となる。特にAnthropic Claudeの90%割引やDeepSeekの90%割引は、適切に活用すれば劇的なコスト削減を実現する。
コストモデルの理解
各プロバイダーの料金構成
| プロバイダー | 通常入力 | キャッシュ書込 | キャッシュ読取 | 出力 |
|---|---|---|---|---|
| Anthropic Claude 3.5 Sonnet | $3/M | $3.75/M（+25%） | $0.30/M（-90%） | $15/M |
| OpenAI GPT-4o | $2.50/M | $2.50/M（追加なし） | $1.25/M（-50%） | $10/M |
| Google Gemini 1.5 Pro | $1.25/M | $1.25/M + ストレージ | $0.315/M（-75%） | $5/M |
| DeepSeek V3 | $0.27/M | $0.27/M（追加なし） | $0.027/M（-90%） | $1.10/M |
（M = 100万トークン、2026年6月時点の参考価格）
損益分岐点の計算
キャッシュ書き込みにはコストがかかるため、十分な回数の読み取りがなければ元が取れない。Anthropic Claudeの場合：
- キャッシュ書き込みコスト: 通常入力の1.25倍（25%増）
- キャッシュ読み取りコスト: 通常入力の0.10倍（90%割引）
- 損益分岐点: 書き込み1回 + 読み取りN回で元を取るには
書き込みコスト（1.25P）= 読み取りN回の節約（N × 0.90P）の場合、N = 1.25 / 0.90 ≈ 1.39回。つまり 2回以上の読み取りがあれば元が取れる。OpenAIの場合は書き込みコスト増なしで読み取り50%割引のため、1回目からコスト削減が始まる。
最適化戦略
戦略1: プロンプト階層化
プロンプトを変更頻度で階層化し、キャッシュ効率を最大化する。
| 階層 | 内容 | 変更頻度 | キャッシュ効果 |
|---|---|---|---|
| L1（最上位） | システムプロンプト | デプロイごと | 最高（全リクエスト共有） |
| L2 | Few-shot例・ツール定義 | 週次〜月次 | 高（同一タスク内共有） |
| L3 | セッションコンテキスト | セッション単位 | 中（同一会話内共有） |
| L4（最下位） | ユーザー入力 | 毎リクエスト | なし（キャッシュ不可） |
L1〜L3をこの順序でプロンプトに配置し、L4を末尾に置く。L1が2,000トークン、L2が3,000トークン、L3が1,000トークンの場合、L1-L2の5,000トークンは全リクエストでキャッシュされ、L3まで含む6,000トークンは同一セッション内でキャッシュされる。
戦略2: リクエストバッチングとソート
複数リクエストを処理する場合、同一プレフィックスを持つリクエストをグルーピングして連続送信する。例えばRAGアプリケーションで10件の文書に対してそれぞれ3つの質問がある場合：
- 非最適: 文書1-Q1、文書2-Q1、文書3-Q1、文書1-Q2...（キャッシュミス多発）
- 最適: 文書1-Q1、文書1-Q2、文書1-Q3、文書2-Q1...（文書単位でキャッシュ再利用）
戦略3: モデルティアリング
全リクエストに最高性能モデルを使うのではなく、タスクの複雑さに応じてモデルを使い分ける。キャッシュは同一モデル内でのみ有効なため、モデル選択とキャッシュ戦略をセットで設計する。
- ルーティング型: 簡単な質問はHaiku/GPT-4o-mini（安価）、複雑な質問はSonnet/GPT-4o（高性能）
- エスカレーション型: まずHaikuで回答し、信頼度が低ければSonnetで再回答（キャッシュは別管理）
戦略4: コンテキスト圧縮
プロンプトに含める参照文書やコンテキストを圧縮し、入力トークン数自体を削減する。LLMLingua-2やAutoCompressorなどのプロンプト圧縮手法を適用すると、品質を維持しつつ入力トークンを50-70%削減できる場合がある。キャッシュ割引との相乗効果で大幅なコスト削減が期待できる。
ROI計算フレームワーク
キャッシュ最適化の投資対効果を定量的に評価するフレームワーク：
| 指標 | 計算式 |
|---|---|
| 月間キャッシュ節約額 | (キャッシュヒットトークン数 × 割引率 × 単価) - キャッシュ書込追加コスト |
| 最適化開発コスト | エンジニア工数 × 時給 |
| ROI回収期間 | 開発コスト ÷ 月間節約額 |
| 年間ROI | (月間節約額 × 12 - 開発コスト) ÷ 開発コスト × 100% |
FAQ
Q1: 小規模アプリケーションでもキャッシュ最適化は意味がありますか？
月間API利用額が$100未満の小規模アプリケーションでは、最適化の開発工数に見合わない場合がある。ただしプロンプト構成の順序を変えるだけの簡単な最適化（戦略1）はコストゼロで実施できるため、規模に関係なく推奨。
Q2: キャッシュ最適化とレスポンス品質はトレードオフですか？
基本的にはトレードオフではない。キャッシュはプロンプトの処理結果を再利用するだけで、モデルの出力品質には影響しない。ただしコンテキスト圧縮（戦略4）を適用する場合は品質低下のリスクがあるため、ベンチマークでの検証が必要。
Q3: マルチリージョンデプロイでキャッシュはどう扱うべきですか？
多くのAPIプロバイダーではキャッシュはリージョンローカルに管理される。東京リージョンで作成されたキャッシュは米国リージョンでは利用できない。マルチリージョン構成の場合、各リージョンで独立したキャッシュウォームアップが必要となり、ヒット率が低下する可能性がある。リージョンごとのトラフィック配分を考慮した設計が重要。