A
コスト / COST
同じ入力をより安く読み取ります。
代表例：キャッシュヒットした入力単価は通常入力の10%
FIELD GUIDE · 2026.08
REQUEST / 0042LIVE
01ツール定義固定
02システム指示固定
03参照ドキュメント固定
CACHE BOUNDARY
04今回の質問変更
05最新の結果変更
先頭はそのまま。新しい情報だけを後ろに追加。
キャッシュ読み取り単価代表例 90%↓*
研究でのTTFT最大改善31%↓†
基本原則先頭は固定、末尾は変化
* GPT-5.6・Claude・Geminiの公式価格に基づく代表例 · † 500件のエージェントセッションを対象としたarXiv研究の最大値。戦略によっては改善しない、または遅くなる場合があります
01
仕組み / THE MECHANISM
AIは答えを記憶するのではなく、
同じ先頭部分の計算を再利用します。
プロンプト／コンテキストキャッシュは答えそのものを記憶しません。回答前のプリフィル段階で、一致する先頭部分の計算を再利用します。キャッシュが有効なら、新しい末尾だけを読みます。
01プリフィル
入力全体を読み、内部の計算結果を作ります。
02キャッシュ再利用
同じ先頭部分の再計算を省きます。
03デコード
回答を1トークンずつ生成します。
要点
キャッシュが主に削減するのは入力のプリフィルです。出力トークンのコストと生成速度は別です。
INTERACTIVE LAB 01
実際にキャッシュを壊してみましょう。
変更位置によって再利用できる範囲が変わります。
SIMULATION良い流れ: 3/5
01ツール定義HIT
02システム指示HIT
03参照ドキュメントHIT
04今回の質問NEW
05最新の結果NEW
先頭の3ブロックがそのまま再利用されます。
一般的なプレフィックスキャッシュでは、変更箇所以降の再利用可能な範囲が小さくなります。
02
効果 / WHY IT MATTERS
コスト、速度、処理量。1回のキャッシュヒットが3つすべてを変えます。
条件とメリットはプロバイダーやモデルによって異なります。以下の90%は代表的な入力価格で、リクエスト全体の削減率ではありません。
90%↓
B
速度 / SPEED
長いプリフィルを省き、最初のトークンが速く返ります。
効果はプレフィックス長やインフラによって異なります
C
処理量 / THROUGHPUT
同じ予算と時間で、より多くの作業を進めます。
Claude APIでは多くのモデルでキャッシュ読み取りがITPMから除外されます
INTERACTIVE LAB 02
ヒット率だけでは、半分しか見えていません。
キャッシュ読み取り単価を通常入力の10%とした単純モデルです。書き込み・保存（TTL）・出力コストは含みません。
RESULT / PER TURN
56K
全額課金トークン換算のターンあたり有効入力負荷
入力コスト指数28 / 100
概算削減率72%
98% HIT900K × 0.118 = 106.2K
VS
70% HIT50K × 0.37 = 18.5K
ヒット率が高くても、コンテキストが大きすぎると約5.7倍重くなります。
CASE
私たちのOrca利用記録
ORCA HQ · 2026.07.20—07.27 · LOCAL USAGE LOG
実際の利用記録から、キャッシュが活きるパターンを見つけました。
Orcaがローカルで集計したHQ作業記録のうち、パスを直接確認できた207セッションを分析しました。数値はusageフィールドの合計で、請求記録がないためコストは推定していません。
- 観測期間ログ測定
- 8日間 7月20〜27日
- Orcaセッションログ測定
- 207 HQパスを直接確認
- 記録された応答ログ測定
- 12,554 usage記録あり
- 使用モデルログ測定
- 8 Claude・GLM・DeepSeek
WHAT THE LOG SHOWS
入力関連トークン全体に占めるキャッシュ読み取りの割合
合計22.01億トークンのうち、21.61億がcache read、3,882万がcache write、79.9万が新規入力でした。
ログ測定cache read ÷ (read + write + fresh input)
キャッシュ読み取りログ測定
21.61億98.20%キャッシュ書き込みログ測定
3,882万1.76%新規入力ログ測定
79.9万0.04%ターンあたり平均17.2万 cache-read tokens
再利用率は高い一方、絶対コンテキストも大きい
THREE REAL RUNS
約1時間の集中実行で、数百件の応答にキャッシュ読み取りが記録されました。
いずれもClaude Opus 5を使用したOrcaベンチマークです。合計値は丸めています。
01 · 運用文書レビューOPSREV3
615ターン
- 実行時間
- 57分
- キャッシュ読み取り
- 1.371億
- キャッシュ書き込み
- 29.8万
- 読み取り比率
- 99.78%
観測：読み取り量は書き込み量の約460倍でした。
02 · シナリオレビューSCENAREV
486ターン
- 実行時間
- 49分
- キャッシュ読み取り
- 1.102億
- キャッシュ書き込み
- 29.2万
- 読み取り比率
- 99.73%
観測：入力関連トークンの大部分が再利用されました。
03 · 長文要約レビューLONGSUM4
425ターン
- 実行時間
- 48分
- キャッシュ読み取り
- 1.005億
- キャッシュ書き込み
- 26.4万
- 読み取り比率
- 99.74%
観測：長文作業でも高い再利用率が見られました。
確認した要点
3つの実行はすべて、同じ目的の作業を短時間に1セッションで連続していました。
注意：強い相関パターンですが、個々のキャッシュ書き込み原因を直接分類したものではありません。03
実践 / THE PLAYBOOK
先頭は固定し、末尾だけを動かしましょう。
キャッシュ最適化は、セッションの始め方、続け方、整理の仕方の問題です。
始める前に固定するものを決めます。
- 長く使うルールと参照資料を整理
- モデル・MCP・ツール構成を確定
- 1スレッドに1つの作業
作業中は変更分だけを追加します。
- 今回の質問と最新結果は後ろに
- 大きな画像やログはファイルに分離
- 同じ作業はできるだけ連続して行う
重くなったら思い切って整理します。
- 同じ作業ならコンテキストを圧縮
- 作業が変わったら新しいスレッド
- ヒット率と絶対トークン数を確認
一般的なチャットボット / PRESCRIPTION
トピックごとにスレッド、資料は一度だけ
- 01
説明と資料は最初に一度まとめます。
- 02
同じ作業は同じスレッドで続けます。
- 03
長文書は変更点だけを伝えます。
CACHE & CONTEXT HABITS
これらの習慣は再利用とコンテキスト効率を損ないます。
- ×システム指示に動的な値を入れる
- ×ツール一覧や順序を頻繁に変える
- ×同じ文書を直して何度も貼り直す
- ×画像や生ログを積み重ねる
- ×異なる作業を1つのスレッドに混ぜる
WHAT TO MEASURE
比率と絶対量をあわせて見ましょう。
01キャッシュ読み取り／書き込み
実際にヒットしているか？
02ターンあたりの総入力
セッションが重すぎないか？
03作業あたりのコスト
1つの結果にいくら使うか？
04TTFT
最初のトークンは速くなったか？
自分のワークロードの基準線と傾向が、普遍的な理想値より重要です。
04
GPTの見解 / A MODEL'S TAKE
キャッシュ最適化はプロンプトの小技ではなく、情報構造の設計です。
ヒット率は有用ですが、100%が目標ではありません。変わらない事実を安定して再利用し、今必要な情報だけを新しく読みます。
OPTIMIZE IN THIS ORDER
- 01不要なコンテキストを削除
- 02安定した情報を固定
- 03作業ごとにスレッドを分ける
- 04ヒット率を測定
最新性や正確性と衝突する場合は、キャッシュより正確性を優先してください。
05
セッション前の30秒チェック
YOUR NEXT SESSION
始める前に、6つだけ確認しましょう。
0 / 6
チェックするほどセッションは軽くなります。
ONE LINE TO REMEMBER
良いキャッシュ活用 =
先頭の安定性 × コンテキスト管理 × 作業リズム
数値と計算式はどう算出しましたか？
概算削減率＝ヒット率×（1−読み取り単価／通常入力単価）。読み取り単価10%、ヒット率80%なら入力コストは約72%減ります。
キャッシュはすべてのAIで同じですか？
いいえ。TTL、最小長、割引率、usageフィールドはモデルとプロバイダーで異なります。
同じチャットなら必ずヒットしますか？
保証されません。ポリシー、TTL、内部コンテキスト管理によって異なります。
ファクトチェックに使用した一次情報
2026年8月13日時点の公式文書と原研究を照合し、Orcaの数値はローカルusageログから再集計しました。