Prompt キャッシュへの影響：ヒット率とトークン節約のトレードオフ

このレッスンで学べること

LLM プロバイダーの Prompt Caching メカニズムの仕組みを理解する
DCP のプルーニングがなぜキャッシュヒット率に影響するかを知る
キャッシュ損失とトークン節約のバランスの取り方を学ぶ
使用するプロバイダーと課金モデルに応じた最適な戦略を立てる

あなたが直面している課題

DCP を有効にした後、キャッシュヒット率が 85% から 65% に下がったことに気づき、これがかえってコスト増加につながるのではないかと心配していませんか？あるいは、異なる LLM プロバイダー（Anthropic、OpenAI、GitHub Copilot）で DCP を使用した場合の影響の違いを知りたいと思っていませんか？

DCP のプルーニング操作はメッセージ内容を変更するため、Prompt Caching に影響を与えます。しかし、このトレードオフは価値があるのでしょうか？詳しく分析してみましょう。

このテクニックを使うタイミング

長いセッションでコンテキストの肥大化が顕著になった場合
リクエスト単位課金のプロバイダー（GitHub Copilot、Google Antigravity など）を使用している場合
コンテキスト汚染を減らし、モデルの応答品質を向上させたい場合
トークン節約の価値がキャッシュヒット率の損失を上回る場合

核心となる考え方

Prompt Caching とは

Prompt Caching は、LLM プロバイダー（Anthropic、OpenAI など）がパフォーマンスとコストを最適化するために提供する技術です。正確なプレフィックスマッチングに基づいて処理済みの prompt をキャッシュし、同じ prompt プレフィックスのトークン計算を繰り返さないようにします。

キャッシュメカニズムの例

以下のような会話履歴があるとします：

[システムプロンプト]
[ユーザーメッセージ 1]
[AI 応答 1 + ツール呼び出し A]
[ユーザーメッセージ 2]
[AI 応答 2 + ツール呼び出し A]  ← 同じツール呼び出し
[ユーザーメッセージ 3]

キャッシュがない場合、LLM に送信するたびにすべてのトークンを再計算する必要があります。キャッシュがあれば、2回目の送信時にプロバイダーは以前の計算結果を再利用でき、新しい「ユーザーメッセージ 3」の部分だけを計算すれば済みます。

DCP がキャッシュに与える影響

DCP がツール出力をプルーニングすると、ツールの元の出力内容をプレースホルダーテキストに置き換えます："[Output removed to save context - information superseded or no longer needed]"

この操作によりメッセージの正確な内容が変わり（元は完全なツール出力だったものがプレースホルダーになる）、キャッシュが無効化されます——その時点以降のキャッシュプレフィックスは再利用できなくなります。

トレードオフ分析

指標	DCP なし	DCP 有効	影響
キャッシュヒット率	約85%	約65%	⬇️ 20%減少
コンテキストサイズ	継続的に増加	制御されたプルーニング	⬇️ 大幅に減少
トークン節約	0	10-40%	⬆️ 大幅に増加
応答品質	低下の可能性	より安定	⬆️ 向上（コンテキスト汚染の減少）

キャッシュヒット率が下がってもコストが下がる可能性がある理由

キャッシュヒット率の低下はコスト増加を意味しません。その理由：

トークン節約は通常キャッシュ損失を上回る：長いセッションでは、DCP プルーニングで節約されるトークン数（10-40%）がキャッシュ無効化による追加トークン計算を上回ることが多い
コンテキスト汚染の減少：冗長なコンテンツが削除されると、モデルは現在のタスクにより集中でき、応答品質が向上する
キャッシュヒット率の絶対値は依然として高い：65%に下がっても、約2/3のコンテンツはキャッシュ可能

テストデータによると、ほとんどの場合、DCP のトークン節約効果の方が顕著です。

異なる課金モデルへの影響

リクエスト単位課金（GitHub Copilot、Google Antigravity）

最適なユースケース、マイナスの影響なし。

これらのプロバイダーはトークン数ではなくリクエスト数で課金します。したがって：

✅ DCP プルーニングで節約されるトークンは料金に直接影響しない
✅ コンテキストサイズの削減により応答速度が向上
✅ キャッシュ無効化による追加コストなし

GitHub Copilot と Google Antigravity

これら2つのプラットフォームはリクエスト単位課金のため、DCP はゼロコスト最適化です——キャッシュヒット率が下がっても料金は増加せず、むしろパフォーマンスが向上します。

トークン単位課金（Anthropic、OpenAI）

キャッシュ損失とトークン節約のバランスを取る必要があります。

計算例：

100メッセージ、合計100Kトークンの長いセッションを想定：

シナリオ	キャッシュヒット率	キャッシュ節約トークン	DCP プルーニング節約トークン	総節約
DCP なし	85%	85K × (1-0.85) = 12.75K	0	12.75K
DCP 有効	65%	100K × (1-0.65) = 35K	20K（推定）	35K + 20K - 12.75K = 42.25K

DCP プルーニング後はキャッシュヒット率が下がりますが、コンテキストが20Kトークン削減されるため、実際の総節約量は多くなります。

長いセッションでの優位性が顕著

長いセッションでは、DCP の優位性がより明確になります：

短いセッション（10メッセージ未満）：キャッシュ無効化が主要因となり、メリットは限定的
長いセッション（30メッセージ以上）：コンテキストの肥大化が深刻で、DCP プルーニングで節約されるトークンがキャッシュ損失を大幅に上回る

推奨：長いセッションでは DCP を優先的に有効化し、短いセッションでは無効化を検討。

観察と検証

ステップ 1：キャッシュトークン使用量の観察

目的キャッシュトークンが総トークンに占める割合を把握し、キャッシュの重要性を評価する

bash

# OpenCode で実行
/dcp context

期待される出力：以下のようなトークン分析

╭───────────────────────────────────────────────────────────╮
│                  DCP Context Analysis                     │
╰───────────────────────────────────────────────────────────╯

Session Context Breakdown:
──────────────────────────────────────────────────────────

System         15.2% │████████████████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│  25.1K tokens
User            5.1% │████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│   8.4K tokens
Assistant       35.8% │██████████████████████████████████████▒▒▒▒▒▒▒│  59.2K tokens
Tools (45)      43.9% │████████████████████████████████████████████████│  72.6K tokens

──────────────────────────────────────────────────────────

Summary:
  Pruned:          12 tools (~15.2K tokens)
  Current context: ~165.3K tokens
  Without DCP:     ~180.5K tokens

主要指標の解説：

指標	意味	評価方法
Pruned	プルーニングされたツール数とトークン数	高いほど DCP の節約効果が大きい
Current context	現在のセッションコンテキストの総トークン数	Without DCP より大幅に小さいはず
Without DCP	DCP を有効にしない場合のコンテキストサイズ	節約効果の比較に使用

ステップ 2：DCP 有効/無効の比較

目的比較を通じて、キャッシュとトークン節約の違いを直感的に把握する

bash

# 1. DCP を無効化（設定で enabled: false に設定）
# または一時的に無効化：
/dcp sweep 999  # すべてのツールをプルーニングし、キャッシュ効果を観察

# 2. 数回会話を行う

# 3. 統計を確認
/dcp stats

# 4. DCP を再度有効化
# （設定を変更するかデフォルト値に戻す）

# 5. 会話を続け、統計を比較
/dcp stats

期待される出力：

/dcp context を使用して主要指標の変化を観察：

指標	DCP 無効	DCP 有効	説明
Pruned	0 tools	5-20 tools	DCP がプルーニングしたツール数
Current context	大きい	小さい	DCP 後はコンテキストが大幅に縮小
Without DCP	Current と同じ	Current より大きい	DCP の節約ポテンシャルを表示

実際のテストの推奨事項

異なるセッションタイプでテストしてください：

短いセッション（5-10メッセージ）：キャッシュがより重要かどうかを観察
長いセッション（30メッセージ以上）：DCP の節約効果がより顕著かどうかを観察
繰り返し読み取り：同じファイルを頻繁に読み取るシナリオ

これにより、実際の使用習慣に基づいて最適な選択ができます。

ステップ 3：コンテキスト汚染の影響を理解する

目的 DCP プルーニングはトークン節約だけでなく、コンテキスト汚染を減らし、応答品質を向上させる

コンテキスト汚染とは？

コンテキスト汚染とは、過剰な冗長、無関係、または古い情報が会話履歴に溢れ、以下の問題を引き起こすことです：

モデルの注意が分散し、現在のタスクに集中しにくくなる
古いデータ（変更済みのファイル内容など）を参照する可能性
応答品質の低下、コンテキストを「理解」するためにより多くのトークンが必要

DCP は、完了したツール出力や重複した読み取り操作などを削除することで、この汚染を軽減します。

実際の効果比較：

シナリオ	DCP なし	DCP 有効
同じファイルを3回読み取り	3回分の完全な出力を保持（冗長）	最新の1回のみ保持
ファイル書き込み後に再読み取り	古い書き込み操作 + 新しい読み取り	新しい読み取りのみ保持
エラーのあるツール出力	完全なエラー入力を保持	エラーメッセージのみ保持

コンテキスト汚染を減らすことで、モデルは現在の状態をより正確に理解でき、「でたらめ」や古いデータの参照が減少します。

ベストプラクティスの推奨事項

プロバイダーに応じた戦略選択

プロバイダー	課金モデル	推奨	理由
GitHub Copilot	リクエスト単位	✅ 常に有効化	ゼロコスト最適化、パフォーマンス向上のみ
Google Antigravity	リクエスト単位	✅ 常に有効化	同上
Anthropic	トークン単位	✅ 長いセッションで有効化 ⚠️ 短いセッションは任意	キャッシュと節約のバランス
OpenAI	トークン単位	✅ 長いセッションで有効化 ⚠️ 短いセッションは任意	同上

セッションタイプに応じた設定調整

jsonc

// ~/.config/opencode/dcp.jsonc またはプロジェクト設定

{
  // 長いセッション（30メッセージ以上）：すべての戦略を有効化
  "strategies": {
    "deduplication": { "enabled": true },
    "supersedeWrites": { "enabled": true },  // 有効化推奨
    "purgeErrors": { "enabled": true }
  },

  // 短いセッション（10メッセージ未満）：重複排除のみ有効化
  "strategies": {
    "deduplication": { "enabled": true },
    "supersedeWrites": { "enabled": false },
    "purgeErrors": { "enabled": false }
  }
}

戦略の説明：

deduplication（重複排除）：影響小、常に有効化推奨
supersedeWrites（書き込み上書き）：影響中程度、長いセッションで推奨
purgeErrors（エラー削除）：影響小、有効化推奨

動的な戦略調整

/dcp context を使用してトークン構成とプルーニング効果を観察：

bash

# Pruned 値が高い場合、DCP が積極的にトークンを節約していることを示す
# Current context と Without DCP を比較して節約効果を評価

/dcp context

チェックポイント ✅

以下のポイントを理解していることを確認してください：

[ ] Prompt Caching は正確なプレフィックスマッチングに基づき、メッセージ内容の変更でキャッシュが無効化される
[ ] DCP プルーニングはメッセージ内容を変更し、キャッシュヒット率が低下する（約20%）
[ ] 長いセッションでは、トークン節約が通常キャッシュ損失を上回る
[ ] GitHub Copilot と Google Antigravity はリクエスト単位課金で、DCP はゼロコスト最適化
[ ] Anthropic と OpenAI はトークン単位課金で、キャッシュと節約のバランスが必要
[ ] /dcp context を使用してトークン構成とプルーニング効果を観察
[ ] セッションの長さに応じて戦略設定を動的に調整

よくある落とし穴

❌ キャッシュヒット率の低下がコスト増加と同義だと誤解

問題：キャッシュヒット率が85%から65%に下がったのを見て、コストが増加すると思い込む

原因：キャッシュヒット率だけに注目し、トークン節約とコンテキスト縮小の効果を無視

解決策：/dcp context で実際のデータを確認し、以下に注目：

DCP プルーニングで節約されたトークン（Pruned）
現在のコンテキストサイズ（Current context）
プルーニングしない場合の理論サイズ（Without DCP）

Without DCP と Current context を比較することで、DCP が実際に節約したトークン数を確認できます。

❌ 短いセッションでの過度に積極的なプルーニング

問題：5-10メッセージの短いセッションで、すべての戦略を有効化し、キャッシュ無効化が顕著

原因：短いセッションではコンテキストの肥大化が深刻ではなく、積極的なプルーニングのメリットが小さい

解決策：

短いセッションでは deduplication と purgeErrors のみ有効化
supersedeWrites 戦略を無効化
または DCP を完全に無効化（enabled: false）

❌ 異なるプロバイダーの課金差異を無視

問題：GitHub Copilot でキャッシュ無効化によるコスト増加を心配

原因：Copilot がリクエスト単位課金で、キャッシュ無効化が料金を増加させないことに気づいていない

解決策：

Copilot と Antigravity：常に DCP を有効化
Anthropic と OpenAI：セッションの長さに応じて戦略を調整

❌ 実際のデータを観察せずに判断

問題：感覚で DCP を有効にすべきかどうかを判断

原因：/dcp context と /dcp stats を使用して実際の効果を観察していない

解決策：

異なるセッションでデータを収集
DCP 有効/無効の違いを比較
自分の使用習慣に基づいて選択

このレッスンのまとめ

Prompt Caching の核心メカニズム：

LLM プロバイダーは正確なプレフィックスマッチングに基づいて prompt をキャッシュ
DCP プルーニングはメッセージ内容を変更し、キャッシュを無効化
キャッシュヒット率は低下（約20%）するが、トークン節約はより顕著

トレードオフ判断マトリックス：

シナリオ	推奨設定	理由
GitHub Copilot/Google Antigravity	✅ 常に有効化	リクエスト単位課金、ゼロコスト最適化
Anthropic/OpenAI 長いセッション	✅ すべての戦略を有効化	トークン節約 > キャッシュ損失
Anthropic/OpenAI 短いセッション	⚠️ 重複排除+エラー削除のみ	キャッシュがより重要

重要なポイント：

キャッシュヒット率の低下はコスト増加を意味しない：総トークン節約を見る必要がある
異なるプロバイダーの課金モデルが戦略に影響：リクエスト単位 vs トークン単位
セッションの長さに応じて動的に調整：長いセッションでメリットが大きい
ツールを使用してデータを観察：/dcp context と /dcp stats

ベストプラクティスのまとめ：

1. 使用しているプロバイダーと課金モデルを確認
2. セッションの長さに応じて戦略設定を調整
3. 定期的に /dcp context で効果を観察
4. 長いセッションではトークン節約を優先
5. 短いセッションではキャッシュヒット率を優先

次のレッスンの予告

次のレッスンでは サブエージェント処理 を学びます。
学べること：
DCP がサブエージェントセッションをどう検出するか
なぜサブエージェントはプルーニングに参加しないのか
サブエージェントでのプルーニング結果がメインエージェントにどう伝達されるか

付録：ソースコード参照

クリックしてソースコードの場所を表示

更新日：2026-01-23

機能	ファイルパス	行番号
Prompt Caching の説明	`README.md`	46-52
トークン計算（キャッシュ含む）	`lib/messages/utils.ts`	66-78
コンテキスト分析コマンド	`lib/commands/context.ts`	68-174
キャッシュトークン計算	`lib/commands/context.ts`	106-107
ログ記録キャッシュトークン	`lib/logger.ts`	141
プルーニングプレースホルダー定義	`lib/messages/prune.ts`	6-7
ツール出力プルーニング	`lib/messages/prune.ts`	22-46

主要な定数：

なし

主要な関数：

calculateTokens(messages, tokenizer)：メッセージのトークン数を計算、cache.read と cache.write を含む
buildSessionContext(messages)：セッションコンテキスト分析を構築、System/User/Assistant/Tools を区別
formatContextAnalysis(analysis)：コンテキスト分析出力をフォーマット

主要な型：

TokenCounts：トークンカウント構造、input/output/reasoning/cache を含む

キャッシュメカニズムの説明（README より）：

Anthropic と OpenAI は正確なプレフィックスマッチングに基づいて prompt をキャッシュ
DCP プルーニングはメッセージ内容を変更し、キャッシュを無効化
DCP 有効時のキャッシュヒット率は約65%、無効時は約85%
最適なユースケース：リクエスト単位課金のプロバイダー（GitHub Copilot、Google Antigravity）はマイナスの影響なし

Prompt キャッシュへの影響：ヒット率とトークン節約のトレードオフ ​

このレッスンで学べること ​

あなたが直面している課題 ​

このテクニックを使うタイミング ​

核心となる考え方 ​

異なる課金モデルへの影響 ​

リクエスト単位課金（GitHub Copilot、Google Antigravity） ​

トークン単位課金（Anthropic、OpenAI） ​

観察と検証 ​

ステップ 1：キャッシュトークン使用量の観察 ​

ステップ 2：DCP 有効/無効の比較 ​

ステップ 3：コンテキスト汚染の影響を理解する ​

ベストプラクティスの推奨事項 ​

プロバイダーに応じた戦略選択 ​

セッションタイプに応じた設定調整 ​

動的な戦略調整 ​

チェックポイント ✅ ​

よくある落とし穴 ​

❌ キャッシュヒット率の低下がコスト増加と同義だと誤解 ​

❌ 短いセッションでの過度に積極的なプルーニング ​

❌ 異なるプロバイダーの課金差異を無視 ​

❌ 実際のデータを観察せずに判断 ​

このレッスンのまとめ ​

次のレッスンの予告 ​

付録：ソースコード参照 ​

Prompt キャッシュへの影響：ヒット率とトークン節約のトレードオフ

このレッスンで学べること

あなたが直面している課題

このテクニックを使うタイミング

核心となる考え方

異なる課金モデルへの影響

リクエスト単位課金（GitHub Copilot、Google Antigravity）

トークン単位課金（Anthropic、OpenAI）

観察と検証

ステップ 1：キャッシュトークン使用量の観察

ステップ 2：DCP 有効/無効の比較

ステップ 3：コンテキスト汚染の影響を理解する

ベストプラクティスの推奨事項

プロバイダーに応じた戦略選択

セッションタイプに応じた設定調整

動的な戦略調整

チェックポイント ✅

よくある落とし穴

❌ キャッシュヒット率の低下がコスト増加と同義だと誤解

❌ 短いセッションでの過度に積極的なプルーニング

❌ 異なるプロバイダーの課金差異を無視

❌ 実際のデータを観察せずに判断

このレッスンのまとめ

次のレッスンの予告

付録：ソースコード参照