Claudeのキャッシュを使い倒す

AIによる記事の要点

情報元の記事をもとに自動生成しています。誤りや省略が含まれる場合があります。詳細は元記事で確認してください。

【概要】 Claude APIのプロンプトキャッシュ機能は、毎回送信される重複コンテンツの計算結果を再利用することで、入力コストを最大90%削減し、レイテンシとスループットを改善する仕組みである。仕組みを誤解したまま使うと書き込み課金だけを払い続けてヒットがゼロになるため、正確な理解と設計が必須である。 【具体的なポイント】 ・**キャッシュの対象範囲｜プレフィックスの先頭から cache_control を付けたブロックまでの全体が対象で、上流を1バイト変えると下流のキャッシュもすべて無効になる非対称性がある。** ・**自動キャッシュと明示的ブレークポイント｜自動キャッシュはリクエストのトップレベルに cache_control を1つ置くだけで、システムが最後のキャッシュ可能ブロックにブレークポイントを自動配置する。明示的ブレークポイントは個々のコンテンツブロックに直接置き、変更頻度の異なるセクションを分けてキャッシュしたい場合に使う。** ・**増分キャッシュの成立条件｜書き込みはブレークポイントという「点」だけに発生し、読み込みはそこから後方最大20ブロックの「線」を遡って過去のエントリを探す。この非対称性により、会話が伸びる場合は毎リクエスト最後のブロックにブレークポイントを置くだけで増分キャッシュが成立する。** ・**TTLと課金の仕組み｜デフォルトTTLは5分で、キャッシュが使われるたびに追加費用なしでリフレッシュされる。課金は5分キャッシュ書き込みが基本入力の1.25倍、1時間書き込みが2倍、読み取りが0.1倍で、N回利用時の総コストは「1回のwrite + (N−1)回のread」となり、N が大きいほど削減率は90%に近づく。** ・**最小キャッシュ可能トークン数｜各モデルに最小値があり、Haiku 4.5は4,096トークンで、短めのシステムプロンプトは丸ごと無視される。公式ドキュメントは「閾値にわずかに届かない場合は、few-shot例を追加してでも閾値に到達させる方が割に合う」と明言している。** ・**プレフィックスの構成順序｜「変わらないものを前に、変わるものを後ろに」が大原則で、ツール定義・システム指示・固定ナレッジ・few-shot例を先頭に置き、タイムスタンプ・ユーザー固有情報・検索結果・質問は末尾に置く。上流の変更は下流をすべて無効化するため、可変要素が1つ前方に紛れ込むだけで毎回キャッシュミスになる。** ・**バイト一致の厳密性｜ヒット条件は100%のバイト一致で、空白の揺れ・JSONのキー順・改行コード・ロケール依存の整形がすべて敵になる。SwiftやGoなど一部言語はJSON変換時にキー順をランダム化するため、tool_use ブロックのキー順が安定しているか確認が必要である。** ・**プレウォーム戦略｜max_tokens: 0 を指定するとAPIはプロンプトを読み込んでブレークポイントでキャッシュを書き、出力を生成せずに即座に返す。初回ユーザーのキャッシュミス由来のTTFTペナルティを消す公式手段で、アプリ起動時とデプロイ直後に発火させるのが定番である。** 【注目点】 実測では47本の実験で全体のヒット率45.91%、実測課金$1.598602（キャッシュ無し想定$1.935495に対して17.4%削減）を記録したが、各実験が短命な使い捨てプレフィックスに対して初回writeを払う構成のため、定常運用での削減率89.9%（第2章の算数検証）が実態に近い。Claude Fable 5で書き込み直後のキャッシュ可視化にわずかなラグが観測されたため、ヒット率のKPI化と監視が必須である。 **用語** - **プロンプトキャッシュ｜プレフィックス