はじめに
「LLM APIのコストが想定の5倍だった」という相談が後を絶ちません。多くの場合、原因はモデル選定ではなくプロンプトキャッシュを使っていないことです。AnthropicとOpenAIは2025〜2026年にかけて自動キャッシュ機能を強化し、適切に設計すれば月額コストを70〜90%削減できる状態になっています。本稿では最新仕様と、実装で陥りがちな落とし穴を整理します。
キャッシュが効く仕組み
LLM APIの課金は、入力トークン × 単価で計算されます。プロンプトキャッシュは「同じ前置き部分（system prompt・ツール定義・参照ドキュメント）を繰り返し送る」場合に、その前置きを一度だけフルコストで処理し、以後は割引価格で再利用する仕組みです。
- キャッシュヒット時の単価: 通常入力の10%（90%割引）
- キャッシュ書き込み時のオーバーヘッド: 5分TTLなら1.25倍、1時間TTLなら2.0倍
- 損益分岐点: 5分TTLなら2回目の呼び出しで黒字化
「同じ前置きを2回以上使う」が確定したら、キャッシュを入れない理由はない。
AnthropicとOpenAIの実装の違い
両社のアプローチは似て見えますが、制御モデルが大きく異なります。
| 観点 | OpenAI GPT | Anthropic Claude |
|---|---|---|
| 制御モデル | 自動 | 明示的（cache_control指定） |
| ヒット保証 | ベストエフォート | キャッシュ指定時100% |
| TTL | 自動管理 | 5分/1時間 |
| 自動キャッシュ | 既定で有効 | 2026年に導入 |
| 割引率 | キャッシュヒット90% | キャッシュヒット90% |
Claude側は「いつ・何をキャッシュするか」を開発者が制御できる代わりに実装が必要です。OpenAIは完全自動で透過的に動作しますが、ヒット率の予測が立てにくい側面があります。
実装パターン3選
パターンA: 静的システムプロンプト + 動的ユーザー入力
最も基本的なパターン。システムプロンプトと社内ドキュメントをcache_controlで指定し、ユーザー入力のみ動的に流す。長い社内RAGに特に効果的。
パターンB: ツール定義のキャッシュ
エージェント設計でツール定義が長くなりがちな場合、ツールスキーマ部分をキャッシュ対象に含めることで、ツール呼び出しごとのコストを大幅圧縮できる。
パターンC: マルチターン会話のコンテキスト保持
会話履歴をキャッシュに乗せ続ける設計。長セッションでも各ターンの追加コストが微小になる。
さらなる節約: Batch APIとの組み合わせ
リアルタイム性が不要な処理は**Batch API（50%割引）に回せます。プロンプトキャッシュ（90%割引）と組み合わせると、理論上は通常コストの5%（95%削減）**まで落とせます。
具体的な節約効果の例（同一ワークロード想定）。
| 構成 | 月額コスト指数 |
|---|---|
| デフォルト（キャッシュなし・同期API） | 100 |
| プロンプトキャッシュのみ | 30〜40 |
| Batch APIのみ | 50 |
| キャッシュ + Batch | 15〜20 |
落とし穴と回避策
- キャッシュが効かない: 前置きの冒頭が動的に変わると効かない。動的部分は末尾に配置
- TTL切れ: 5分TTLは意外と短い。低頻度ワークロードなら1時間TTLを選択
- 冪等性のないツール呼び出し: キャッシュは入力部分のみ。ツール側の重複実行に注意
- モデル切替時の再キャッシュ: モデルを変えるとキャッシュは無効化される
ビジネスへの示唆
中小企業にとって、月額LLMコスト30万円が5〜10万円になるインパクトは小さくありません。コスト削減施策の優先順位として、モデルダウングレードよりキャッシュ導入のほうが品質を落とさず効くことが多いため、最初の手としてキャッシュ最適化を試すべきです。
まとめ
プロンプトキャッシュは、モデル選定や品質チューニングと並ぶ「LLMOpsの三本柱」の一角です。導入は数行のコード変更で完了し、効果は月次請求書ですぐに確認できます。次回のAPI課金が想定より高いと感じたら、まずキャッシュヒット率をダッシュボードで確認してみてください。
LLMコスト最適化で最初に着手すべきは、モデル変更ではなく前置きの再設計。
