Claude APIを使っていて、毎回同じシステムプロンプトを送信しているのに、その都度フル料金を請求されていませんか。Anthropicが提供する「Prompt Caching」を有効にするだけで、入力トークンのコストを最大90%削減できます。

この記事でわかること

  • Prompt Cachingの仕組みと解決する課題
  • 料金体系と具体的な節約額
  • 自動キャッシュと明示的ブレークポイントの使い分け
  • キャッシュが効かない落とし穴と対処法

Prompt Cachingが解決する課題

Prompt caching
Claude API Documentation
Claude API Docs

Claude APIでチャットボットやエージェントを構築する場合、リクエストごとにシステムプロンプト・ツール定義・過去の会話履歴を繰り返し送信します。これらの「変わらない部分」にも毎回フルの入力トークン料金がかかるため、呼び出し回数が増えるほどコストが膨らみます。

Prompt Cachingは、リクエストの先頭にある不変のプレフィックス部分をサーバー側に保持し、次回以降のリクエストで再利用する機能です。キャッシュから読み出されたトークンには、通常の入力料金の10分の1しかかかりません。

料金体系

Prompt Cachingの料金は3種類に分かれます。

キャッシュ書き込み（5分TTL） は通常の入力料金の1.25倍です。初回リクエスト時にキャッシュを作成するコストにあたります。

キャッシュ書き込み（1時間TTL） は通常の2倍です。デフォルトの5分では短い場合に、TTLを1hに指定して延長できます。

キャッシュ読み出し は通常の0.1倍です。ここが最大の節約ポイントになります。

たとえばClaude Sonnet 4.6の場合、通常の入力は100万トークンあたり3ドルです。キャッシュ読み出しなら0.30ドルで済みます。1万トークンのシステムプロンプトを1日100回送信するケースでは、キャッシュなしなら月約90ドル、キャッシュありなら月約9ドルまで下がります。

自動キャッシュの設定手順

最も手軽な方法は「自動キャッシュ」です。リクエストのトップレベルにcache_controlを1つ追加するだけで、システムがキャッシュ対象を自動判定します。

Python SDKでの実装例は以下のとおりです。

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    system="あなたはソフトウェア開発の専門家です。...",
    messages=[{"role": "user", "content": "質問内容"}],
)

自動キャッシュでは、リクエスト内の最後のキャッシュ可能なブロックにブレークポイントが自動配置されます。マルチターン会話では、ターンが進むたびにブレークポイントが前方へ移動し、過去の会話履歴はキャッシュから読み出されます。

明示的ブレークポイントの使い方

システムプロンプトとツール定義を別々にキャッシュしたい場合や、変更頻度が異なるセクションを分けたい場合は、個別のコンテンツブロックにcache_controlを直接付与します。ブレークポイントは最大4つまで設定可能です。

ツール定義はほとんど変わらないが、コンテキスト情報は日ごとに更新されるといったケースでは、それぞれにブレークポイントを設定することで、ツール定義だけをキャッシュから読み出し、コンテキスト部分だけを再書き込みする運用ができます。

キャッシュが効かない落とし穴

Prompt Cachingにはモデルごとの最小トークン数があります。Claude Sonnet 4.6は2,048トークン、Claude Opus 4.7は4,096トークンが下限です。これより短いプロンプトにcache_controlを付けても、キャッシュは作成されません。しかもエラーは返らず、レスポンスのcache_creation_input_tokensとcache_read_input_tokensがどちらも0になるだけです。

もう1つの典型的な失敗は、タイムスタンプやリクエストIDなど毎回変わるブロックにブレークポイントを置くケースです。キャッシュのハッシュはブレークポイントまでの全内容から計算されるため、1文字でも変われば別のキャッシュとして扱われます。ブレークポイントは「リクエスト間で内容が変わらない最後のブロック」に配置してください。

さらに、デフォルトのTTLは5分です。5分以内に次のリクエストが来なければキャッシュは失効します。リクエスト間隔が長い場合は、TTLを1hに設定することで対処できますが、書き込みコストが通常の2倍になる点に注意が必要です。

キャッシュの効果を確認する方法

APIレスポンスのusageフィールドに含まれる3つの値でキャッシュの動作を確認できます。cache_read_input_tokensはキャッシュから読み出されたトークン数、cache_creation_input_tokensは新たに書き込まれたトークン数、input_tokensはキャッシュ対象外のトークン数です。

cache_read_input_tokensが大きく、cache_creation_input_tokensが0であれば、キャッシュが正常にヒットしています。両方が0の場合は最小トークン数の要件を満たしていない可能性があります。

まとめに代えて

Prompt Cachingは、Batch API（50%割引）と組み合わせれば最大95%のコスト削減も可能です。設定はcache_controlパラメータを1つ追加するだけで、既存のコードへの影響は最小限に抑えられます。APIコストに悩んでいるなら、まずレスポンスのusageフィールドを確認し、キャッシュヒット率の改善から始めてみてください。