Prompt Caching 完全ガイド：仕組み、コストモデル、実践的な導入方法

Prompt caching が解決する課題

ほとんどの LLM 呼び出しの入力には、毎回同じ部分がかなり含まれています。システムプロンプト、few-shot の例、検索で取得した固定ドキュメント、ツール定義（tool schema）などです。通常の課金では、こうした繰り返しの内容に対して毎回入力 Token の料金を払い、毎回 attention を計算し直すことになります。

Prompt caching の考え方はシンプルです。サーバー側でこのプレフィックスの計算結果を保存しておき、次のリクエストでプレフィックスが完全に同じであればそのまま再利用し、新しく追加された部分だけを再計算します。Anthropic は [prompt caching のドキュメント](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)でこれをレイテンシとコストを下げる手段として位置づけており、OpenAI 側では自動 prompt caching や batch 割引などの仕組みが対応します。

本当にコスト削減になるシナリオ

Prompt caching は「オンにすれば節約できる」スイッチではありません。明確な損益分岐点があります。同じプレフィックスが再利用される回数 × プレフィックス長 > キャッシュ書き込みの追加コスト です。

• 長いシステムプロンプト + マルチターン対話：システムプロンプトが数千 Token、会話のターン数が多い場合はほぼ確実に得になります。
• RAG + 固定ドキュメント集：変わらないポリシードキュメントやナレッジベースをプレフィックスに置き、ユーザーの質問だけを変化させます。
• コード Agent / ツール呼び出し：ツール schema やリポジトリ構造の説明は通常、毎回の呼び出しで繰り返されます。
• 単発・短いプレフィックスの呼び出し：キャッシュ書き込みのコストが節約額を上回る可能性があるため、無理にキャッシュしないでください。

キャッシュを無効化する5つのよくあるミス

• プレフィックスにタイムスタンプやランダム ID を混入させる：固定位置に1つでも Date.now() を置くと、プレフィックス全体が変わってしまいます。
• システムプロンプトを動的に結合する：ユーザーごとに異なるプレフィックスになると、キャッシュヒット率はほぼ 0 まで薄まります。
• 履歴メッセージを要約圧縮する：毎ターン書き換えるとプレフィックスが不安定になります。
• ユーザー入力を先頭に置く：最もよくある構造上のミスです。変数はできるだけ後ろに寄せるべきです。
• 請求額だけを見てヒット率を見ない：ヒット率の指標がないと、キャッシュの効果をまったく帰属分析できません。

複数モデル間で同じキャッシュ戦略を再利用する

製品で Claude と GPT を併用している場合、キャッシュのセマンティクスはベンダー間で完全には一致しません（誰がキャッシュのブレークポイントを宣言するか、TTL の長さ、課金方法など）。この適配を1つの統一ゲートウェイの背後にまとめておくと、ビジネスコードはプロンプト構造を1つだけ維持すればよく、モデルを切り替える際に書き直す必要がありません。

Admesh のゲートウェイは下流に対して OpenAI 互換プロトコルを維持しているため、同じプロンプト構造のまま model フィールドだけを変えてベンダー間を切り替えられます。キャッシュヒット時の課金基準は請求の usage 明細に統一的に反映されるため、ベンダーごとに課金基準を個別に接続する必要はありません。

課金単位とキャッシュ Token の説明を見る →

実践チェックリスト

1. プロンプトを「安定プレフィックス / 半安定部分 / ユーザー入力」の3段に分割し、安定部分を先頭に置く。
2. 安定プレフィックスにタイムスタンプ、乱数、ユーザー ID が含まれないことを確認する。
3. 請求の中でキャッシュの読み書き Token を個別に集計し、実際のヒット率に換算する。
4. 固定の評価リクエストセットで定期的にリグレッションを行い、プロンプト変更でヒット率が崩れていないことを確認する。
5. キャッシュ効果に下限を設ける（例：5% を下回ったらプロンプト構造をロールバックする）ことで、最適化のための最適化を避ける。