序論：見過ごされがちなテコ入れポイント

システムプロンプトを3,000トークンから500トークンに最適化できた時、あなたはきっと満足したでしょう。さらに安価なモデルに切り替えた時は、もっと満足したはずです。

しかし、あなたは一度もこの問いを投げかけたことがないかもしれません。「私のキャッシュヒット率はどれくらいだろう？」と。

2025年から2026年にかけて、AI推論キャッシュはもはや「オプションの最適化」ではなく、アーキテクチャの核となる柱となっています。OpenAI、Anthropic、Googleはいずれも自動キャッシュを組み込んでおり、vLLMやSGLangはKVキャッシュヒット率を95%以上に高めています。しかし、ほとんどのチームは、繰り返し行われる計算に二重に—しかも全額—料金を支払っていることに全く気づいていません。

この記事ではキャッシュの技術的な原理には触れません。私たちが焦点を当てるのはただ一つの数字、**Cache Hit Rate（キャッシュヒット率）**です。それが何を意味し、どのように計算され、何がそれに影響を与え、どう最適化するのか、そして一体どれくらいの価値があるのか、を掘り下げていきます。

序章：キャッシュとは何か？一般的なキャッシュとAIキャッシュの違い

キャッシュとは

キャッシュ（Cache）は、コンピューターサイエンスにおける最も古くからの最適化手段の一つです。高コストな操作の結果を保存しておき、次回必要になった際に直接再利用するというものです。

• CPUにはL1/L2/L3キャッシュがあります—メモリから毎回データを読み込む手間を省きます。
• データベースにはバッファプールがあります—ディスクから毎回データを読み込む手間を省きます。
• CDNにはエッジキャッシュがあります—オリジンサーバーから毎回ファイルを引っ張ってくる手間を省きます。
• ブラウザにはHTTPキャッシュがあります—毎回リソースを再ダウンロードする手間を省きます。

これらに共通するロジックは「時間と空間のトレードオフ（空間的リソースを使って時間的リソースを節約する）」です。わずかなストレージスペースを費やすことで、大量の繰り返し計算やI/Oを節約します。

AIキャッシュの独自性

AIモデル推論におけるキャッシュは、従来のキャッシュとは本質的に異なります。

1. キャッシュの粒度：「ファイル」から「数学的状態」へ

従来のキャッシュは完全な結果—HTMLページ全体、画像1枚、SQLクエリの結果1件—をキャッシュします。ヒットすればそのまま返され、「部分的なヒット」という概念は存在しません。

AIキャッシュは計算の途中状態—Key-Value行列—をキャッシュします。プロンプトが8,000トークンあっても、キャッシュが最初の6,000トークンにヒットした場合、残りの2,000トークンは依然として計算が必要です。これは以下のことを意味します。

• ヒット率は0または100%ではなく、連続的なパーセンテージで表されます。
• 80%のヒット率は、80%のトークンがキャッシュでカバーされ、残りの20%のみを計算すればよいことを示します。
• これにより、計算コストの削減が段階的になるという特性が生まれます。60%のヒット率のリクエストは50%のヒット率のリクエストよりも少し安くなりますが、その差はプレフィル（事前処理）量の10パーセントポイントにすぎません。

2. キャッシュキー：「完全一致」から「前方一致」へ

従来のキャッシュは完全一致するキー—URL、SQLハッシュ、ファイル名—でインデックスを付けます。キーが一致しなければ、ミス（キャッシュされていない状態）と見なされます。

AIキャッシュは前方一致を使用します。新しいリクエストのプロンプトの冒頭が、キャッシュ内のプロンプトの冒頭と一致すればヒットと見なされます。これは以下のことを意味します。

• キャッシュヒットの判定自体が計算操作（文字列/ベクトルマッチング）です。
• 2つのリクエストが完全に等しくなくても、一部のプレフィックスを共有していれば恩恵を受けられます。
• 一つのキャッシュエントリが、同じプレフィックスを持つ無数の異なるリクエストに同時にサービスを提供できます。

3. 整合性モデル：「厳密な整合性」から「近似的な整合性」へ

従来のキャッシュは、ヒットして返される結果が再計算された結果と完全に一致することを求めます。古いデータが返されることはバグです。

AIキャッシュは異なるトレードオフに直面します。

• KVキャッシュがキャッシュする途中状態は、数学的に再計算された結果と完全に一致することが保証されます。
• **Semantic Cache（セマンティックキャッシュ）**は、ある程度の近似を許容します。意味的に類似した2つのプロンプトが同じ回答を共有するため、微妙なニュアンスが失われる可能性があります。
• **GenCache（生成的キャッシュ）**はさらに進んでいます。キャッシュするのは結果そのものではなく、結果を生成するパターンです。プログラムによって変化に適応した新しい回答を動的に合成するため、これはもはや従来の意味での「キャッシュ」とは全く異なります。

4. コスト構造：「ストレージ節約」から「計算コスト節約」へ

従来のキャッシュはI/Oと帯域幅のコストを節約します。CDNのヒットは、オリジンサーバーのCPUと帯域幅のコストを節約することに相当します。

AIキャッシュが節約するのはGPU計算コストであり、これは現在最も高価な計算リソースの一つです。

• GPT-4レベルのプレフィルでは、10万トークンのプレフィルに数秒のGPU時間を要することがあります。
• キャッシュヒットすれば、このGPU時間はゼロになります。
• APIレベルでのキャッシュ割引は、最大90%（Anthropic）または75-90%（OpenAI。GPT-4.1は75%、GPT-5系は90%）にもなります。
• AIのシナリオでは、キャッシュは直接的に「真のお金」に相当します。

5. 有効期限と書き込みコスト

従来のキャッシュには「書き込みコスト」という概念がありません。将来のヒットに備えるためのキャッシュの書き込みは、ほとんど無料です。

AIキャッシュの書き込みには実際のコストがかかります。初めてプロンプトを送信する際、APIプロバイダーはプレフィル計算を完全に実行し、その中間結果（KVキャッシュ）を保存します。この計算プロセスに対して、あなたは100%の料金を支払います。Anthropicの場合、あなたはさらに25%の「書き込みプレミアム」を支払う必要があります。これは、サーバー側の貴重なGPUメモリを消費してキャッシュエントリを保存するためです。

これこそが、AIキャッシュがこれほどまでにユニークである理由です。それが直面する「高コストな操作」は従来のシナリオよりも桁違いに高価ですが、キャッシュ自体のコストも同様に高価です。ヒット率は性能指標だけでなく、財務指標でもあるのです。

第一章：ヒット率とは何か？どう計算するのか？

定義

AIモデル推論には二層のキャッシュがあり、ヒット率の定義も異なります。

1. プロンプトキャッシュヒット率（API層）

ヒット率 = キャッシュにヒットしたトークン数 / 総入力トークン数

OpenAIやAnthropicのAPIを呼び出す際、プロンプトのプレフィックスが以前のリクエストと同じであれば、APIサーバーは重複するプレフィル計算をスキップし、キャッシュ結果を直接読み取ります。この部分のトークンは割引価格が適用されます。

• 各レスポンスにはusage.cached_tokensフィールドが返されます。
• もし0であれば、キャッシュにヒットしたトークンが全くなかったことを意味します。

2. KVキャッシュヒット率（エンジン層）

ヒット率 = キャッシュ内でマッチしたトークン数 / 総プレフィル（事前処理）トークン数

vLLM、SGLangなどの推論エンジン内部では、これは新しいリクエストが既存のキャッシュ内でいくつのマッチするプレフィックス（前方一致）トークンを見つけられたかを測定します。ヒット数が多いほど、最初から計算する必要のあるプレフィルが少なくなります。

ベースラインデータ

異なるシナリオでの典型的なヒット率は大きく異なります。

第二章：ヒット率の真の経済学

API層：プロンプトキャッシュの算出方法

これは最も直感的で、最も簡単に計算できる部分です。2025年から2026年にかけての主要プラットフォームの料金モデルです。

Anthropic（Claude Sonnet 4.6を例に）

OpenAI（GPT-4.1）

📝 2026-10-12 更新：GPT-5系のキャッシュヒット料金は基本料金の0.10倍まで下がっている（例：GPT-5.4は入力 $2.50/M、キャッシュヒット $0.25/M）。書き込み料金がかからない点は同じ。出典：OpenAI 料金ページ。

重要な違いに注意してください。Anthropicはヒット後に90%割引（0.10倍）を適用しますが、初回書き込みには25%のプレミアム（1.25倍）を支払う必要があります。OpenAIはヒット後に75-90%割引（モデルにより異なる）を適用しますが、書き込みプレミアムは徴収しません。

損益分岐点

これは最も見過ごされがちな落とし穴です。Anthropicのキャッシュ書き込みには25%のプレミアムがかかるということは、以下のことを意味します。

書き込みコストを回収するためには、最低でも約1.4回のヒットが必要です。

計算過程：

• 書き込みコスト：8Kトークン × $3.75/100万トークン = $0.030
• 1回のヒットで節約できる額：8Kトークン × ($3.00 - $0.30)/100万トークン = $0.0216
• 損益分岐点：$0.030 / $0.0216 ≈ 1.39回ヒット

つまり、もし同じキャッシュプレフィックスが5分間のTTL（有効期限）ウィンドウ内（Anthropicのデフォルトキャッシュ時間は5分）で1〜2回しかリクエストされなかった場合、あなたはキャッシュを使わない方が良かったということになりかねません。なぜなら、一度書き込むたびに損をしてしまうからです。

OpenAIは異なります

OpenAIは書き込みプレミアムを徴収しないため、1回のヒットごとに純粋な節約となります。

• 1回ヒット → 50%節約
• 0回ヒット → 損も得もしない

したがって、OpenAIのキャッシュはほぼ常に純粋な利益をもたらし、その利益の大きさはヒット率に依存します。

実際の請求額比較

シナリオ：カスタマーサポートエージェント、1日200セッション、各セッション5ターンの対話。

前提：

• システムプロンプト + ツール定義 = 8Kトークン（全ターンで不変）
• ユーザー入力（各ターン異なる）= 2Kトークン
• 1ターンあたりのAPI呼び出し：システムプロンプト（8K）+ ユーザー入力（2K）

キャッシュなし（各ターンを全額負担）：

1セッション：5ターン × 10K = 50Kトークン
1日：200 × 50K = 10Mトークン
月額（26有効日）：260Mトークン
コスト（Anthropic $3/M）：260M × $3/M = $780/月

Anthropicキャッシュ（システムプロンプトにヒット）：

1セッション：
  1ターン目：書き込み 8K → $3.75/M × 8K = $0.030
            ユーザー入力 2K → $3.00/M × 2K = $0.006
            小計：$0.036
  2-5ターン目：ヒット 8K → $0.30/M × 8K/ターン × 4ターン = $0.0096
               ユーザー入力 2K → $3.00/M × 2K × 4 = $0.024
               小計：$0.0336
  1セッション合計：$0.0696

1日200セッション：$0.0696 × 200 = $13.92
月額（26日）：$13.92 × 26 = $362

節約効果：$780 → $362、約 54%。

OpenAIの場合（50%割引、書き込みプレミアムなし）：

1セッションあたりのコストは若干高くなるが、書き込みプレミアムリスクなし。
ヒット率40%以上で純利益。

重要な洞察：キャッシュによる節約幅は、安定プレフィックスが総入力に占める割合によって決まる。本例では8K/10K = 80%が安定トークンで、これに90%割引が適用される。システムプロンプトが2Kでユーザー入力が8Kの場合、100%ヒットしても節約効果は限定的。

実際のケーススタディ

🎯 ケース1：あるセキュリティツール企業は、システムプロンプトの先頭に動的な内容（タイムスタンプ、リクエストID）を置いていたため、ヒット率はわずか**7.4%でした。安定した内容をプレフィックスに移動させたところ、ヒット率は84%**に急上昇しました。ビジネスロジックを一切変更せず、構造を変えただけです。

🎯 ケース2：あるAIコードアシスタントがOpenAIでprompt_cache_keyを有効にしたところ、ヒット率が60%から87%に向上しました。このパラメータにより、リクエストが同じキャッシュ済みプレフィックスを持つ推論エンジンにルーティングされる可能性が高まります。

🎯 ケース3：Culprit（事故分析ツール）はAnthropicでプロンプトキャッシュを利用し、1回のRCA呼び出しコストを$0.0065から$0.0033に削減しました。約50%の削減です。Batch APIの50%割引と合わせると、限界費用はほとんど無視できるレベルになります。

第三章：ヒット率に影響を与える6つの主要因

1. プレフィックスの安定性

ヒット率の上限は、あなたのプロンプト構造によって決まります。

❌ 悪い例：システムプロンプト + ユーザーID + タイムスタンプ + 機能説明
✅ 良い例：システムプロンプト + 機能説明 + ユーザーID + タイムスタンプ

核心原則：安定した内容を先に、動的な内容を後に置く。

2. 最小キャッシュ長

• OpenAI / Anthropic はキャッシュをトリガーするために1,024トークン以上を要求します。
• Gemini は32,000トークン以上を要求します。

もしシステムプロンプトが500トークンしかない場合、キャッシュは永遠にトリガーされません。ヒット率は常に0%です。

興味深いことに、プロンプトを長くすることでかえってコストが節約できる可能性があります。900トークンのプロンプトは決してキャッシュにヒットしませんが、200トークンの安定したプレフィックスを追加して1,100トークンにすることで、ヒット率が50%であれば、全体的なコストはかえって低くなります。

3. リクエスト密度

キャッシュにはTTL（有効期限）があります。

• OpenAI：5-10分
• Anthropic（デフォルト）：5分
• Anthropic（延長）：1時間
• Gemini：ユーザー定義

もし同じプレフィックスを持つ2つのリクエストが10分以上間隔を空けている場合、Anthropicの5分間のTTLは既に期限切れとなり、2回目のリクエストは再度書き込みが必要になります（再び25%のプレミアムを支払うことになります）。

高密度のトラフィックはキャッシュの味方、低密度のトラフィックはキャッシュの敵です。

4. ルーティングアフィニティ

OpenAI内部では、プロンプトの最初の約256トークンに基づいてハッシュルーティングが行われます。ルーティングアフィニティがない場合、同じプレフィックスのリクエストが異なる推論インスタンスに分散され、キャッシュミスを引き起こす可能性があります。

prompt_cache_keyパラメータを使用すると、ルーティングアフィニティを強化し、同じプレフィックスのリクエストが同じインスタンスに到達する可能性を高めることができます。ただし、prefix + cache_keyの組み合わせが約15RPMを超えると、他のインスタンスに溢れることに注意が必要です。

5. スケジューリングポリシー（エンジン層）

セルフデプロイされた推論エンジンでは、リクエストの到着順序がKVキャッシュヒット率に直接影響します。

• キャッシュ非認識型スケジューリング：FCFS（先着順）でリクエストを処理するため、異なるプレフィックスが頻繁に切り替わります。
• キャッシュ認識型スケジューリング（SGLangのLPM、PRISMのQASなど）：プレフィックスの類似性に基づいてグループ化し、キャッシュにヒットする可能性のあるリクエストを優先的に処理します。

PRISM（2026年発表）のスケジューリングとキャッシュの協調設計は、スケジューリングとキャッシュのエビクション（追い出し）ポリシーを連携して最適化することで、ヒット率を5.9〜12.2パーセントポイント向上させることが可能であることを示しています。

6. エビクションポリシー（キャッシュ追い出し戦略）

キャッシュスペースが不足した際、どの項目を追い出すかが将来のヒット率を直接決定します。

中でもUniCacheの重要な洞察は、すべての負荷において最適な追い出しポリシーは存在しないということです。複合的な負荷の下では、LRU、LFU、FIFOそれぞれに長所があり、UniCacheは動的に適応することができます。

第四章：プロダクション環境でヒット率を向上させる方法

4.1 プロンプト構造の最適化（最も簡単で高リターン）

ステップ1：プロンプトを監査する

// 各API呼び出しでチェック
{
  "usage": {
    "prompt_tokens": 4500,
    "cached_tokens": 0  // もし常に0なら、要注意！
  }
}

ステップ2：安定した部分と動的な部分を分離する

❌ 現在の構造（ヒット率 < 10%）：
  タイムスタンプ + ユーザーID + システムプロンプト + 検索ドキュメント + ユーザーの質問

✅ 最適化後の構造（ヒット率 70-85%）：
  システムプロンプト + ツール定義 + 検索ドキュメント + タイムスタンプ + ユーザーID + ユーザーの質問

ステップ3：OpenAIでprompt_cache_keyを使用する

# 同じシステムプロンプトを共有するすべてのリクエストに同じキーを設定
response = client.responses.create(
    model="gpt-4.1",
    input=[...],
    prompt_cache_key="my-app-v1-system-prompt"  # ✨ 重要なパラメータ
)

ステップ4：Anthropicでキャッシュ境界を明示的に指定する

# システムプロンプトとツール定義をキャッシュ
response = client.messages.create(
    model="claude-sonnet-4-20250514",
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT,
            "cache_control": {"type": "ephemeral"}  # 🎯 キャッシュをマーク
        }
    ],
    messages=[{"role": "user", "content": user_input}]
)

4.2 エンジン層での最適化（セルフデプロイ環境）

vLLMのPagedAttentionではなく、SGLangのRadixAttentionを選択する

SGLangのRadixAttentionはトークンレベルのRadix Treeに基づいており、任意の長さの共有プレフィックスを自動的に発見し再利用します。vLLMのPagedAttentionはブロックレベルのマッチングに基づいているため、共有プレフィックスがブロック境界と整列していない場合、最後の数トークンは再計算されます。

ベンチマーク：

共有プレフィックスの割合が40%を超える場合、SGLangに切り替えることでプレフィル（事前処理）のレイテンシーを30-40%削減できます。

キャッシュ認識型スケジューリングの有効化

SGLangで--schedule-policy lpmを設定し、既存のキャッシュとマッチするリクエストを優先的に処理します。PRISMでは、クエリ認識型スケジューラ（QAS）を有効にし、再利用可能なセグメントの優先順位を追跡します。

エビクションポリシー（キャッシュ追い出し戦略）の調整

ワークロードの特性に基づいてエビクションポリシーを選択します。

• マルチターン対話が主 → LRU
• 長期セッション + 頻繁な再利用 → LFU
• 複合的な負荷 → UniCacheまたはSGLangの優先度ベースのエビクション

4.3 モニタリングと指標

追跡すべきはヒット率だけではなく、収益の帰属です。

ヒットによる収益 = ヒットしたトークン数 × (基本料金 - キャッシュヒット料金)
書き込みコスト = 書き込んだトークン数 × 書き込みプレミアム
純収益 = ヒットによる収益 - 書き込みコスト

有効ヒット率 = 純収益が0を超えるセッションの割合

プロダクションにおけるアラートしきい値：

必須のモニタリングツール：

• 各API呼び出しでcached_tokensフィールドを記録する。
• 最もミスが多いプロンプトパターンを分析し、最適化する。
• 定期的に「書き込みヒット比」をチェックする—書き込みが多すぎてヒットが少なすぎる場合は、TTLを調整するか、ポリシーを変更する。

第五章：2026年の最先端技術

ランダム化エビクション：RLT

2026年のある研究では、ランダム化エビクションポリシーが、特定の動的負荷下でLRUよりも6.92倍優れていることが示されました。その直感は、LRUが「悪意のある」または高変動の到着パターンに直面すると、キャッシュが繰り返しクリアされてしまうというものです。ランダム化は決定論を犠牲にする代わりに、あらゆるパターンに対する理論上の下限を保証します。

学習型ルーティング（LBGR）と組み合わせると、エンドツーエンドのレイテンシーは11.96倍減少し、ヒット率は36.45%向上します。

PRISM：スケジューリングとキャッシュの協調設計

PRISMの核心的な洞察は、スケジューリングとキャッシュは同じコインの裏表であるというものです。

• スケジューリングの決定（どのリクエストを先に処理するか）は、将来のキャッシュの内容に直接影響します。
• キャッシュエビクションの決定（どれを追い出すか）は、スケジューリングの選択肢に逆方向に影響します。

PRISMのクエリ認識型スケジューラ（QAS）は、共有プレフィックスを持つリクエストを「ホットレーン」にまとめて優先的に処理するとともに、コールドレーンの空きを確保して飢餓状態を防ぎます。需要認識型Radix Tree（DART）は、スケジューラのヒントを利用して、高価値のプレフィックスが追い出されないように保護します。

結果：P99 TTFT（Time To First Token）が23-37%減少し、ヒット率が5.9-12.2パーセントポイント（絶対値）向上します。

コンテキストの切り詰めとヒット率の落とし穴

プロダクション環境からの直感に反する発見：コンテキストを切り詰めるとヒット率が大幅に低下する。

ある企業は、非常に長いコンテキストを処理するためにスライディングウィンドウを使用し、入力の最新トークンのみを保持するように切り詰めていました。結果として、切り詰められた入力がキャッシュされた完全なプレフィックスと一致しなくなったため、前方一致キャッシュのヒット率が85%から45%に急落しました。

教訓：もし切り詰めが必要な場合でも、プレフィックスを安定させるように努めるべきです—切り詰めは、先頭からではなく、末尾から開始するようにします。

まとめ：ヒット率最適化ロードマップ

クイックチェックリスト（今日からできること）

• API呼び出しログのcached_tokensフィールドをチェックする。
• システムプロンプトが1,024トークン以上あるか確認する（足りなければ長くする）。
• 動的な内容（タイムスタンプ、ID）がプロンプトの最後に置かれているか確認する。
• OpenAIユーザー：prompt_cache_keyを追加する。
• Anthropicユーザー：システムプロンプトの後にcache_controlを追加する。
• 5分間のTTL内で、同じプレフィックスの平均リクエスト回数が2回を超えているか確認する。

中期的な最適化（1週間以内）

• SGLangユーザー：キャッシュ認識型スケジューリング（--schedule-policy lpm）を有効にする。
• vLLMユーザー：V1エンジンに切り替える（プレフィックスキャッシュがデフォルトで有効）。
• 最もミスが多いリクエストパターンを分析し、プロンプト構造を最適化する。
• ビジネスワークロードに基づいてエビクションポリシー（LRU / LFU / 優先度ベース）を選択する。
• ヒット率をモニタリングし、日次/時間粒度でアラートを設定する。

究極の目標

キャッシュヒットは「あればより良い」といったものではありません。2026年において、それは競合との決定的な差となります。競合他社は同じモデル、同じデータを使用しているかもしれませんが、ヒット率が30%高いため、コストは50%低く、応答速度は3倍速いかもしれません。

一方、あなたは、同じシステムプロンプトに全額を払い続けているかもしれません。