platform.claude.com/docs/en/build-with-claude/prompt-caching)を基にしており、コピペしてすぐ使える例を APIYI の設定向けに調整しています。
一文で言うと
長く、繰り返し使う prompt のプレフィックス(システム指示 / 長い文書 / few-shot の例)をcache_control でマークします。サーバーがそれを保存し、同じプレフィックスで次のリクエストが来たときは再処理をスキップします — おおよそ 10 倍安く、速くなります。一定期間使われないと期限切れになります。
なぜ気にするのか — 倍率を見てください
モデルのベース入力token価格(1×)に対して:
損益分岐点:
- 5分TTL: 同じプレフィックスを 2回再利用 するだけで損益分岐します(1.25 + 0.1 = 1.35、キャッシュなしの2回のリクエストより安いです)。
- 1時間TTL: 3回再利用 で損益分岐します(2 + 0.2 = 2.2、3回のリクエストより安いです)。
TTLはスライディングウィンドウです。キャッシュヒットするたびに有効期限のタイマーがリセットされるため、アクティブな会話が途中で期限切れになることはありません。TTLを超えて本当にアイドル状態になった場合のみ、エビクションが発生します。
向いているケース
- 同じ長いシステムpromptを何度も呼び出す場合(エージェント、チャットボット)
- マルチターンの会話(過去の各ターンが再利用可能なプレフィックスになる)
- 1つのドキュメントをバッチ処理する場合(1つの契約について50個の質問をする)
- 安定した取得チャンクがプレフィックスを形成するRAG
向いていないケース
- すべてのpromptが最初の文字から異なる
- 全体が短く、モデルごとの最小値(下記)を一度も超えない
3つの必須要件
3つすべてが必須です。1. 明示的な cache_control マーカー
content は単なる文字列ではいけません。コンテンツブロック配列である必要があり、キャッシュしたいブロックに cache_control を付けます。
2. 長さがモデルごとの最小値を超えていること
コンテンツがモデルの最小値より短い場合、マーカーがあってもキャッシュされません(エラーにはならず、黙ってスキップされます)。Anthropic の公式ドキュメントで確認済みです。APIYI で測定(2026-07-29)。 固定プレフィックスを段階的に増やして書き込みしきい値を検証しました。
claude-opus-5 では 301 token でキャッシュ書き込みは起きず、614 で発生し、公式の 512 を挟みました。claude-sonnet-5 では 612 で発生せず、1,250 で発生し、公式の 1,024 を挟みました。どちらも上の表と一致します。3. プレフィックスはバイト単位で一致すること
キャッシュはプレフィックスベースです。リクエストの先頭からcache_control マーカーまでのバイト列は、前回のリクエストと完全に同一でなければなりません。空白、JSON キーの順序、タイムスタンプのような単一文字の変更でも、新しいプレフィックスとみなされ、ヒットではなく新規書き込みが発生します。
実用ルール: 変わらないものは前に、変わるものは後ろに置く。
最小の実行例
同じ長いドキュメントを使って、異なる質問で 2 回リクエストを送信します。1 回目は書き込み、2 回目はヒットします:read ≈ 1 回目の呼び出しの write — 同じプレフィックスが再利用されています。
ヒットしたかどうかの見分け方 — 3つの usage フィールド
各レスポンスで、usage は次を報告します:
input token の合計 = 3 つすべての合計です。
cache_read_input_tokens > 0である限り、コストを節約できます。
最もよくある落とし穴
詳細: マルチターン会話
cache_control を直近のユーザーメッセージの最後のコンテンツブロックに置きます。新しいターンが追加されるたびに、キャッシュされた読み取り範囲は前のターンの末尾まで自動的に拡張されます:
- 1リクエストあたり、4
cache_controlブレークポイントまでです。 - 各ブレークポイントのプレフィックス検索ウィンドウは 最大20コンテンツブロック前まで です。それより古いものはヒットの対象になりません。つまり、非常に長い会話では、最新のターンだけをマークしても、以前の履歴全体はカバーできません。
APIYI とキャッシュについて
APIYI はキャッシュ項目をエンドツーエンドで転送します。 あなたが送信した
cache_controlは、上流の Claude(AWS Claude または Claude 公式リレー)にそのまま渡され、返されたcache_creation_input_tokens / cache_read_input_tokensはそのままあなたに返されます。コード側で特別な対応は不要です。- 1回目のリクエストでは、
usage.cache_creation_input_tokens > 0(書き込み成功)となります。 - 数秒以内に、同じプレフィックスをもう一度送信すると、
usage.cache_read_input_tokens > 0(ヒット)が表示されるはずです。 - 課金ダッシュボードでは、キャッシュ書き込み と キャッシュ読み取り が個別に明細化され、公式と同じ倍率(1.25× / 2× / 0.1×)で表示されます。
要約
1. それをマークする
cache_control: {"type": "ephemeral"} コンテンツブロック上で — plain-string content はキャッシュされません。2. 十分な長さにする
Opus 5 ≥ 512; Sonnet 5 / Sonnet 4.6 ≥ 1,024; Opus 4.7 ≥ 2,048; Opus 4.6 / Haiku 4.5 ≥ 4,096 tokens, それ以外は静かにスキップされます。
3. 安定したプレフィックス
先頭は安定させ、後ろは変動してもよく、1 文字でもずれるとヒットしなくなります。
4. 使用状況を確認する
cache_read_input_tokens > 0 だけが、実際にコストを節約できたことを証明します。関連リンク
- 親ページ: Claude API 基礎
- クライアント設定ガイド: Claude Code 連携 · Cherry Studio 連携
- token の取得・管理:
https://api.apiyi.com/token - Anthropic 公式ドキュメント:
platform.claude.com/docs/en/build-with-claude/prompt-caching