AnthropicのPrompt Caching — APIコストを90%削る「自動キャッシュ」の仕組み

2026-04-18

Claude APIを使っていると、毎回同じシステムプロンプトや大量のコンテキストを送っていませんか?その無駄なトークン課金、Prompt Cachingで劇的に削減できます。

Prompt Cachingとは

AnthropicのPrompt Cachingは、APIリクエストのプロンプトプレフィックスをサーバー側でキャッシュし、次回以降のリクエストで再利用する仕組みです。

つまり、同じ内容を何度も送らなくてよくなるため、処理時間とコストの両方を大幅に削減できます。

ざっくり言うと:毎回10,000トークンのシステムプロンプトを送っていた場合、2回目以降はキャッシュヒットで入力コスト90%オフ

2つのキャッシュモード

Prompt Cachingには2つの使い方があります。

1. 自動キャッシュ(Automatic Caching)

リクエストのトップレベルにcache_controlを1行追加するだけ。システムが自動的に最適な位置にキャッシュブレークポイントを適用してくれます。

マルチターン会話に最適。会話が進むにつれてメッセージ履歴が増えても、前のターンまでの内容がキャッシュされます。

2. 明示的キャッシュブレークポイント

個別のコンテンツブロックに直接cache_controlを配置する方法。キャッシュの境界を細かく制御したい場合に使います。

例えば「システムプロンプトだけキャッシュ」「ツール定義だけキャッシュ」といった制御が可能です。

推奨:基本的には自動キャッシュを使いましょう。コードの変更は1行だけで済みます。細かな制御が必要になったら明示的キャッシュに切り替えればOKです。

自動キャッシュの使い方 — たった1行追加するだけ

既存のAPIリクエストに"cache_control": {"type": "ephemeral"}を追加するだけです。

{
  "model": "claude-opus-4-7",
  "max_tokens": 1024,
  "cache_control": {"type": "ephemeral"},
  "system": "あなたは親切なアシスタントです。以下のルールに従って...(長いシステムプロンプト)",
  "messages": [
    {"role": "user", "content": "こんにちは"}
  ]
}

これだけ。システムが自動的に最後のキャッシュ可能ブロックにキャッシュを適用します。

何が起きるか:初回リクエストでプロンプトがキャッシュに保存され(キャッシュ書込)、2回目以降はキャッシュから読み出されます(キャッシュヒット)。プロンプトの内容が変わらなければ、何度でもヒットします。

コスト削減の具体例

Opus 4.7の料金体系で計算してみましょう。

項目 価格(1Mトークンあたり)
通常入力 $5.00
キャッシュ書込(5分TTL) $6.25
キャッシュ書込(1時間TTL) $10.00
キャッシュヒット $0.50(90%オフ!)

計算シミュレーション

10,000トークンのシステムプロンプトを使うチャットボットを1時間で50回呼び出すシナリオ:

さらに良いことに:キャッシュが使用されるたびにTTLが自動リフレッシュされます(追加コストなし)。5分以内にリクエストが来続ければ、キャッシュは実質的にずっと有効です。

キャッシュの仕組み — 内部で何が起きているか

キャッシュはプロンプトのプレフィックス(先頭からの連続した部分)に対して機能します。具体的には以下の順でプロンプトが構成され、キャッシュブレークポイントまでの全内容がキャッシュされます:

  1. ツール定義tools
  2. システムプロンプトsystem
  3. メッセージmessages

自動キャッシュでは、この中で最後のキャッシュ可能ブロックの末尾に自動的にキャッシュブレークポイントが置かれます。

TTL(有効期限)について

どんな用途に向いているか

✅ チャットボット・マルチターン会話

会話が進むほどメッセージ履歴が長くなりますが、前のターンまでの内容がキャッシュされるので、毎回全履歴を再処理する必要がありません。自動キャッシュのベストケースです。

✅ RAG(検索拡張生成)

大量のドキュメントをコンテキストとして渡すRAGシステムでは、同じドキュメントを何度も再処理することになります。システムプロンプトとツール定義をキャッシュしておけば、検索結果の差分だけを新たに処理できます。

✅ AIエージェント

ツール定義が大量にあるエージェントシステムでは、ツール定義だけで数千トークンを消費することも。キャッシュすれば毎回のツール定義処理をスキップできます。

✅ Few-shotプロンプト

多くの例を含むプロンプトは、その例の部分が毎回同じなのでキャッシュと相性抜群です。

向いていないケース:毎回プロンプトが完全に異なる場合はキャッシュの恩恵がありません。キャッシュ書込のコスト(+25%)だけがかかってしまいます。

移行のステップ

既存のコードに自動キャッシュを導入するのは非常に簡単です。

Step 1: リクエストに1行追加

既存のAPI呼び出しに"cache_control": {"type": "ephemeral"}を追加。

Step 2: レスポンスでキャッシュ状況を確認

APIレスポンスのusageフィールドにキャッシュ関連の情報が含まれます。

"usage": {
  "input_tokens": 100,
  "cache_creation_input_tokens": 10000,
  "cache_read_input_tokens": 0
}

2回目以降のリクエストでは:

"usage": {
  "input_tokens": 100,
  "cache_creation_input_tokens": 0,
  "cache_read_input_tokens": 10000
}

cache_read_input_tokensの値が増えていれば、キャッシュが正しくヒットしています。

Step 3: コストを確認

あとは料金ダッシュボードでコストが下がっていることを確認するだけ。

まとめ

Prompt Cachingの自动キャッシュ — 3つのポイント:

  1. 1行追加するだけ"cache_control": {"type": "ephemeral"}をリクエストに追加
  2. コスト90%オフ — キャッシュヒット時の入力は$0.50/MTok(通常$5.00の1/10)
  3. 自動リフレッシュ — キャッシュが使われるたびにTTLが延長(追加コストなし)

まだ使っていないなら、今日から始めるべき機能です。既存のコードに1行追加するだけで、来月のAPI請求が劇的に変わるかもしれません。

参考: Anthropic公式ドキュメント — Prompt Caching