キャッシュヒット率（LLM推論）（キャッシュヒットリツ）

キャッシュヒット率（LLM推論）とは

キャッシュヒット率は、LLMへのリクエストにおいてプロンプトキャッシュが有効に再利用された割合を示す指標である。計算式は「キャッシュ読み取りトークン数 ÷ 総入力トークン数 × 100」で求められる。ヒット率80%であれば入力トークンの80%がキャッシュから読み取られ、再計算されたのは20%だけという意味になる。

商用LLM APIの料金体系はキャッシュヒットの有無で大きく異なる。Anthropic Claudeではキャッシュヒット時の入力料金が通常の10%（90%割引）、OpenAI GPT-4oでは50%割引となるため、ヒット率の改善は直接的なコスト削減に繋がる。月間100万リクエストの大規模アプリケーションでは、ヒット率を60%から80%に改善するだけで月数百ドル〜数千ドルのコスト差が生まれる。

ヒット率に影響する要因

プロンプト構成の順序

キャッシュヒット率に最も大きく影響するのがプロンプトの構成順序である。プレフィックスキャッシュは先頭からの連続一致でマッチするため、変化しない要素を先頭に配置する設計が重要。

リクエスト頻度とTTL

キャッシュにはTTL（有効期間）があるため、リクエスト間隔がTTLを超えるとキャッシュミスが発生する。Claudeの5分TTL環境で平均リクエスト間隔が3分なら高ヒット率を期待できるが、10分間隔ではほぼミスする。

トークンアラインメント

キャッシュは一定のトークン単位（Anthropicでは128トークン）で管理されるため、プレフィックスが127トークンの場合キャッシュされない。最小キャッシュ単位を意識したプロンプト設計が必要。

ヒット率のモニタリング

Anthropic Claude APIの場合

レスポンスの usage フィールドにキャッシュ関連メトリクスが含まれる：

ヒット率 = cache_read_input_tokens ÷ input_tokens × 100

OpenAI APIの場合

レスポンスの usage.prompt_tokens_details.cached_tokens にキャッシュヒットしたトークン数が返される。

モニタリングダッシュボード設計

本番環境では以下のメトリクスを時系列で追跡することを推奨する：

• 瞬間ヒット率: 直近5分間のヒット率（急激な変化の検知用）
• 移動平均ヒット率: 1時間移動平均（トレンド把握用）
• コスト節約額: キャッシュヒットによる実際の節約金額
• キャッシュ書き込み回数: 新規キャッシュ作成の頻度（高すぎる場合はプロンプト設計を見直す）

ヒット率改善の実践テクニック

1. プロンプトテンプレートの標準化

チーム内で使用するシステムプロンプトを標準化し、各開発者が独自にカスタマイズしないようにする。わずかなスペースや改行の違いでもキャッシュミスの原因となるため、テンプレート管理ツールで一元管理する。

2. 動的要素の後方配置

ユーザーIDやタイムスタンプなど動的に変化する要素は必ずプロンプトの末尾に配置する。日時を含む挨拶文をシステムプロンプトの冒頭に入れる設計はキャッシュ効率を著しく低下させる。

3. バッチリクエストのソート

複数リクエストを一括送信する場合、同一プレフィックスを持つリクエストをグルーピングして連続送信する。これによりキャッシュの時間的局所性が高まり、ヒット率が向上する。

FAQ

Q1: キャッシュヒット率の目標値はどの程度ですか？

アプリケーションの性質による。固定プロンプト型のチャットbotなら80%以上を目標にすべきで、RAG型の動的プロンプトでは40-60%が現実的な目標。ワンショット翻訳のような再利用見込みの低いユースケースでは10%以下でも問題ない。

Q2: ヒット率が急に下がった場合の原因として何が考えられますか？

主な原因は3つ。(1) プロンプトテンプレートの変更（デプロイ後に全キャッシュがミスする）、(2) トラフィックパターンの変化（リクエスト間隔がTTLを超えるようになった）、(3) APIプロバイダー側のインフラ変更（キャッシュポリシーの変更通知を見逃していないか確認）。

Q3: キャッシュヒット率とFirst Token Latencyの関係は？

キャッシュヒット時はプレフィックス部分のKV計算がスキップされるため、TTFT（Time To First Token）が大幅に短縮される。Anthropicの公式ベンチマークでは、長いプロンプト（10,000トークン以上）でキャッシュヒット時のTTFTが85%短縮された事例が報告されている。