API費用が爆発してるんですけど……

ミドリ： タツヤさん、助けてください。社内のAIエージェントを本番運用し始めたら、API費用が月10万円を超えちゃったんです。

タツヤ： あらら。ちなみに何のAPIを使ってて、どういう使い方してる？

ミドリ： Claude APIで社内ナレッジベースのQ&Aボットを動かしてます。システムプロンプトに社内マニュアルを5万トークンくらい詰め込んで、毎回送ってます。

タツヤ： はい、原因わかった。プロンプトキャッシュ使ってないでしょ。

ミドリ： プロンプトキャッシュ？ なんですかそれ？

タツヤ： 同じシステムプロンプトを何度も送るとき、API側がその内容をキャッシュしておいて、2回目以降は処理コストを大幅に下げてくれる仕組みだよ。AnthropicもOpenAIも対応してる。

プロンプトキャッシュの仕組み

ミドリ： もうちょっと詳しく教えてください。何がどうキャッシュされるんですか？

タツヤ： 仕組みはシンプル。API呼び出しのプロンプト部分（特にシステムプロンプト）をサーバー側にキャッシュしておく。次のリクエストで同じ内容が送られたら、前処理済みのキャッシュをそのまま使う。

ミドリ： CDNみたいなイメージですか？

タツヤ： 近いね。ただしキャッシュされるのは「トークン化・前処理済みのプロンプト」であって、レスポンスじゃない。つまり同じ質問をしても毎回ちゃんと考えて回答する。キャッシュはあくまで入力側の最適化だ。

ミドリ(nodding)： なるほど、回答の質は変わらないんですね。

タツヤ： まったく変わらない。変わるのはコストとレイテンシだけ。ここ重要。

Anthropic vs OpenAI：キャッシュ機能の比較

ミドリ： AnthropicとOpenAI、両方プロンプトキャッシュがあるんですよね？ 違いは？

タツヤ： けっこう違う。比較表を見てみよう。

項目Anthropic（Claude）OpenAI（GPT-4o/o1）
キャッシュ方式明示的（cache_control指定）自動（prefix match）
最小キャッシュ単位1,024トークン1,024トークン
キャッシュ書き込みコスト通常の1.25倍なし（通常料金）
キャッシュ読み取りコスト通常の0.1倍（90%オフ）通常の0.5倍（50%オフ）
キャッシュ有効期限最終使用から5分（延長あり）5〜10分
対象モデルClaude 3.5 Sonnet, Claude 3.5 Haiku, Claude 4 Opus 等GPT-4o, GPT-4o-mini, o1 等
キャッシュ対象system, tools, images, 長いusersystem, tools, messages prefix

ミドリ： Anthropicのほうが割引率が大きいんですね。90%オフって。

タツヤ(smiling)： そう。ただしAnthropicは最初のキャッシュ書き込み時に1.25倍のコストがかかる。とはいえ、2回目以降がずっと0.1倍だから、3回以上使えば元が取れる計算。社内Q&Aボットみたいに同じシステムプロンプトを何百回も使うケースでは、圧倒的にAnthropicが有利。

実装方法：Anthropic Claude API

ミドリ(thinking)： 実際にどうやって実装するんですか？

タツヤ： Anthropic APIの場合、cache_control パラメータを追加するだけ。

import anthropic

client = anthropic.Anthropic()

# 社内マニュアルの内容（5万トークン相当）
company_manual = open("manual.txt").read()

response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": company_manual,
            "cache_control": {"type": "ephemeral"}  # ← これだけ
        }
    ],
    messages=[
        {"role": "user", "content": "有給休暇の申請方法を教えて"}
    ]
)

ミドリ： え、cache_control を1行足すだけですか？

タツヤ： そう。レスポンスの usage フィールドに cache_creation_input_tokens と cache_read_input_tokens が返ってくるから、キャッシュが効いてるかどうかも確認できる。

キャッシュヒット率を最大化するコツ

ミドリ： キャッシュが効いたり効かなかったりすることってあるんですか？

タツヤ： ある。キャッシュヒット率を上げるには、いくつかコツがある。

コツ1：変わらない部分を先頭に

タツヤ： キャッシュはプロンプトの先頭からの前方一致で判定される。だから、固定のシステムプロンプトを先頭に、変動するユーザー入力を後ろに置く。

ミドリ： 順番を入れ替えるだけでキャッシュ効率が変わるんですか。

タツヤ： 変わる。たとえばこういう構成がベスト。

① 会社のガイドライン（固定・大容量）← キャッシュ対象
② ツール定義（固定）← キャッシュ対象
③ 会話履歴（変動）
④ ユーザーの質問（変動）

コツ2：キャッシュの粒度を適切に

タツヤ： キャッシュブレークポイントは最大4つまで指定できる。全部を1つの塊でキャッシュすると、一部が変わっただけでキャッシュが無効になる。

ミドリ： じゃあシステムプロンプトとツール定義を別々のブレークポイントにすれば？

タツヤ(nodding)： その通り。そうすれば、ツール定義を更新してもシステムプロンプト部分のキャッシュは有効なままだ。

コツ3：リクエスト間隔を意識する

タツヤ： Anthropicのキャッシュ有効期限は最終使用から5分。5分以内に次のリクエストが来れば延長される。つまり、一定のトラフィックがあるサービスほどキャッシュが効きやすい。

ミドリ： 逆に言うと、たまにしか使わないツールだとキャッシュが消えちゃう？

タツヤ： そう。1日に数回しか使わないようなケースでは、キャッシュの恩恵は薄い。

コスト削減シミュレーション

ミドリ： 実際にどれくらい安くなるか、計算してみたいです。

タツヤ： ミドリのケースで試算しよう。Claude Sonnet、システムプロンプト5万トークン、ユーザー入力平均500トークン、月3,000リクエストとする。

キャッシュなしの場合

項目計算費用（USD）
入力トークン50,500 × 3,000 × $3/MTok$454.50
出力トークン500 × 3,000 × $15/MTok$22.50
月額合計$477.00

キャッシュありの場合（ヒット率95%）

項目計算費用（USD）
キャッシュ書き込み（5%）50,000 × 150 × $3.75/MTok$28.13
キャッシュ読み取り（95%）50,000 × 2,850 × $0.30/MTok$42.75
非キャッシュ入力500 × 3,000 × $3/MTok$4.50
出力トークン500 × 3,000 × $15/MTok$22.50
月額合計$97.88

ミドリ： $477が$98に！？ 約80%削減じゃないですか！

タツヤ： しかもこれはキャッシュヒット率95%で計算してる。実際の運用では、トラフィックが一定あれば98%以上も珍しくない。そうなると月$70くらいまで下がる。

ミドリ： 月10万円が2万円以下になるってことですね……。もっと早く教えてほしかった。

キャッシュすべきでないケース

ミドリ： キャッシュって万能なんですか？ 使わないほうがいいケースもありますか？

タツヤ(nodding)： いい質問。以下のケースではキャッシュの効果が薄いか、逆効果になる。

1. リクエスト頻度が低い

タツヤ： 1日に数回しか呼ばれないAPIなら、キャッシュが期限切れするたびに書き込みコスト（1.25倍）がかかる。トータルで損する可能性がある。

2. システムプロンプトが頻繁に変わる

タツヤ： A/Bテストでプロンプトを頻繁に切り替えてるなら、キャッシュがヒットしない。

3. プロンプトが短い

タツヤ： システムプロンプトが1,024トークン未満だと、そもそもキャッシュ対象にならない。短いプロンプトならコスト自体が小さいから、あまり気にしなくていい。

ミドリ(thinking)： つまり「長いシステムプロンプトを、高頻度で、安定して送り続ける」ケースが最適なんですね。

タツヤ： まさにその通り。RAGで大量のコンテキストを送るケースや、社内ボット、カスタマーサポートAIなんかは最高にフィットする。

導入時のモニタリング

ミドリ： 導入した後、ちゃんと効いてるか確認するにはどうすればいいですか？

タツヤ： 3つの指標を追えばいい。

指標目標値確認方法
キャッシュヒット率90%以上cache_read_input_tokens / 全入力tokens
コスト削減率70%以上月次API費用の前月比
レイテンシ改善TTFT 50%短縮APIレスポンスの time_to_first_token

タツヤ： 特にAnthropicの場合、キャッシュヒット時はTTFT（最初のトークンが返ってくるまでの時間）も大幅に短縮される。コストだけじゃなくて体感速度も上がるんだ。

ミドリ： コスト削減と速度向上が同時に手に入るって、デメリットなくないですか？

タツヤ(thinking)： デメリットがほぼない。だからこそ「やらない理由がない」最適化なんだよ。

まとめ：今すぐ確認すべき3つのこと

ミドリ： 今日の話をまとめるとどうなりますか？

タツヤ： プロンプトキャッシュは、LLM APIのコスト最適化で最も簡単で効果が大きい施策。特にAnthropicのClaude APIなら、cache_control を1行追加するだけでAPI費用を80〜90%削減できる。

ミドリ： 実装コストがほぼゼロで、効果が絶大。やらない手はないですね。

タツヤ(nodding)： その通り。今すぐ3つ確認してほしい。

  1. 現在のAPI費用の内訳を確認する — 入力トークンのうち、システムプロンプトが占める割合は？ 50%以上なら即キャッシュ対象
  2. リクエスト頻度を確認する — 同じシステムプロンプトへのリクエストが5分に1回以上あるか？ あればキャッシュが常時有効になる
  3. キャッシュを有効化して効果を測定する — 1週間のA/Bテストで、コスト・レイテンシの変化を数字で確認する

次のアクション

API費用の最適化を始めましょう。