プレフィックスキャッシュ（プレフィックスキャッシュ）

プレフィックスキャッシュとは

プレフィックスキャッシュは、LLM APIの商用運用で広く採用されている最適化手法である。多くのAPIリクエストはシステムプロンプトやFew-shot例など共通の先頭部分を持つ。この共通部分（プレフィックス）のKVキャッシュを保持・再利用することで、重複する計算を省略する。

例えばAnthropicのClaude APIでは、4,096トークン以上のプレフィックスが一致する場合にキャッシュが適用され、キャッシュヒット時の入力トークン料金が90%割引される。OpenAIのGPT-4oでも同様の自動プレフィックスキャッシュが実装されており、キャッシュヒット時に50%割引が適用される。

プレフィックスキャッシュの動作原理

マッチング方式

プレフィックスキャッシュのマッチングは「先頭から連続一致」が基本原則である。プロンプトの途中だけが一致していてもキャッシュは効かない。

この制約があるため、キャッシュ効率を最大化するにはプロンプトの構成順序が重要になる。変化しない部分（システムプロンプト、Few-shot例、参照文書）を先頭に配置し、変化する部分（ユーザー入力、動的コンテキスト）を末尾に配置する。

トークン粒度とアラインメント

APIプロバイダーによってキャッシュの最小単位が異なる。Anthropicでは128トークン単位でキャッシュが管理され、プレフィックスが128の倍数に切り捨てられた位置までがキャッシュ対象となる。これにより内部的なメモリ管理が効率化される。

主要APIプロバイダーの実装比較

暗黙的 vs 明示的キャッシュ

Anthropicの cache_control ブレークポイントやGoogleのContext Cachingのように、開発者が明示的にキャッシュ範囲を指定する方式と、OpenAIのように自動的にプレフィックス一致を検出する方式がある。明示的方式はキャッシュヒット率を制御しやすいが実装コストが高く、暗黙的方式は手軽だがヒット率が予測しにくい。

実践的な設計パターン

パターン1: 固定システムプロンプト

最も単純で効果的なパターン。全リクエストで同一のシステムプロンプトを使用する場合、プレフィックス部分が自動的にキャッシュされる。カスタマーサポートbot、翻訳API、コード生成ツールなどに適する。

パターン2: 文書QA（RAG）

検索で取得した文書をプロンプトに含める場合、文書部分をプレフィックスに配置し、質問を末尾に置く。同一文書に対する複数質問でキャッシュが有効になる。文書のハッシュ値でキャッシュキーを管理すると効率的。

パターン3: Few-shot学習

タスク固有の例題をプレフィックスにまとめ、新しい入力を末尾に追加する。例題が多いほど（8-shot、16-shot）キャッシュの恩恵が大きくなる。

FAQ

Q1: プレフィックスキャッシュはファインチューニングの代替になりますか？

部分的にはなり得る。Few-shot例をプレフィックスに大量に含めることで、ファインチューニングに近い精度を低コストで実現できる場合がある。ただし、モデルの重み自体を最適化するファインチューニングと比べると、コンテキストウィンドウの制約を受ける点と、推論時のレイテンシが若干大きい点が異なる。

Q2: マルチテナント環境でプレフィックスキャッシュは共有されますか？

APIプロバイダーの実装に依存する。多くのプロバイダーではセキュリティ上の理由からテナント（APIキー）ごとにキャッシュが分離されている。ただし同一組織内の複数プロジェクトでは共有される場合がある。

Q3: キャッシュヒット率を監視する方法は？

Anthropicでは usage オブジェクトに cache_creation_input_tokens と cache_read_input_tokens が返される。OpenAIでも cached_tokens フィールドが含まれる。これらをモニタリングダッシュボードで追跡し、プロンプト設計の改善に活用できる。