やす研究所 AI Lab
戻る

Claude APIコスト最適化2026:5分TTL時代に効くプロンプトキャッシュ実装

Claude APIコスト最適化2026:5分TTL時代に効くプロンプトキャッシュ実装

「Claude API の請求書、先月より3割増えてない?」——3月のクレジットカード明細を見て、私は二度見しました。コードもプロンプトもほぼ変えていないのに、です。

原因はすぐにわかりました。2026年早々、Anthropic がプロンプトキャッシュのデフォルト TTL を 60分から5分へ静かに短縮していたんです。これに気づかないまま運用していると、せっかくのキャッシュがほとんど効かない設計に陥ります。

この記事では、私が自分の副業案件で実際にやり直したコスト最適化の手順を、コード付きで全部公開します。Claude Sonnet 4.6 を使った典型ワークロードなら、入力コストを6〜8割落とせる余地が残っているはずです。

結論:Claude API コスト最適化は「3つのレバー」を重ねるだけ

先に結論から。2026年5月時点で、Claude API のコストを現実的に削るレバーは次の3つです。

  1. プロンプトキャッシュ(入力の繰り返し部分を最大90%オフ)
  2. モデルルーティング(Haiku 4.5 / Sonnet 4.6 / Opus 4.6 を用途で振り分け)
  3. Batch API(非リアルタイムなら全部一律50%オフ)

この3つを重ねると、素朴に Opus 4.6 を叩いていた構成と比べて2〜3割の請求額に収まるケースが多いです。私が試した範囲でも、月$40前後だった自動化スクリプトの請求が$15〜20まで落ちました。

ただし、2026年に入ってからのキャッシュ仕様変更を理解していないと、レバー1がまるごと不発になります。ここがこの記事の本題です。

なぜ2026年に「Claude API コスト最適化」がやり直しなのか

大きな変化が2つありました。

変化1: プロンプトキャッシュの TTL が5分に短縮

以前は1時間だったキャッシュの寿命が、2026年初頭からデフォルト5分になりました。dev.to の解説記事によると、本番ワークロードでは実効コストが30〜60%上がったケースもあるそうです。

何が起きるかというと、たとえば15分に1回動くクロンエージェントは、以前なら最初の1回でキャッシュを書き込んで残り3回はキャッシュ読み込みで済んでいました。それが今では毎回キャッシュを書き直す羽目になります。書き込みは通常入力の1.25倍コストなので、むしろ高くつくことすらあるんですよね。

変化2: ワークスペース単位のキャッシュ分離

2026年2月5日から、Claude API・Claude Platform on AWS・Microsoft Foundry(beta)ではワークスペースごとにキャッシュが分離されるようになりました。Bedrock と Vertex AI は組織単位のまま、という点も地味に重要です。

複数ワークスペースを使っている人は、同じプロンプトでも別キャッシュ扱いになる前提で設計を見直してください。

Claude API の料金体系を5分でおさらい(2026年5月時点)

まずベースの料金を頭に入れます。Anthropic 公式の価格表と複数の独立した解説記事を突き合わせると、2026年5月時点の主要モデルは次の通りです(100万トークンあたりUSD)。

キャッシュ関連は次の倍率がベース料金にかかります。

つまり Sonnet 4.6 のキャッシュ読み込みは$0.30/1Mトークン。これが「90%オフ」の正体です。さらに Batch API は全モデル一律50%オフで、キャッシュ倍率と掛け算できます。

料金更新は意外と細かいので、本番投入前に必ず公式 docs を見にいく癖をつけたほうがいいです。私も3月の TTL 変更には1ヶ月気づかず請求書で殴られました。

プロンプトキャッシュの最小トークン閾値という落とし穴

ここ、見落としやすいので強調します。

複数の実装記事で言及されているように、Claude Sonnet 4.6 は最低2,048トークン、Claude Opus 4.7 は最低4,096トークンないと cache_control を付けてもキャッシュが作られません。短いシステムプロンプトにcache_controlを付けて「効いてるつもり」になるのが一番もったいないパターンです。

しかも失敗はサイレント。レスポンスは普通に成功しますが、usage フィールドの cache_creation_input_tokens と cache_read_input_tokens がゼロのままです。だからログを取らないと気づけないんですよね。

実装:Python で書く最小キャッシュ構成

実際のコードを見たほうが早いです。Claude Sonnet 4.6 でシステムプロンプトをキャッシュする最小例。

from anthropic import Anthropic

client = Anthropic()

# 2048トークン以上ある長文システムプロンプトを想定
SYSTEM_PROMPT = open("system_prompt.md").read()

resp = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT,
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[
        {"role": "user", "content": "今日のタスクを3つ提案して"}
    ],
)

usage = resp.usage
print(f"input: {usage.input_tokens}")
print(f"cache_create: {usage.cache_creation_input_tokens}")
print(f"cache_read: {usage.cache_read_input_tokens}")
print(f"output: {usage.output_tokens}")

初回実行で cache_create が増え、5分以内に2回目を叩くと cache_read 側に乗ります。これが乗らない場合は、ほぼ確実にトークン数不足か、プレフィックスの中身が毎回変わっています。

5分TTL時代に効く実装パターン3つ

ここからが本記事の核心です。5分という短い窓でキャッシュを実用域に乗せる設計パターンを、私が試して効いた順に並べます。

パターン1: バースト処理で「5分以内に詰め込む」

一番素直で効きます。15分ごとに1回 API を叩くのではなく、5分以内に複数の関連処理を連続実行する設計に変えます。

私のブログ自動化を例に取ると、もともと「記事生成 → 1時間後に翻訳 → さらに後でSEO処理」と分散していたのを、1回のジョブで write → translate-ja → translate-en → seo → summary を一気通貫で回すように書き換えました。同じ CLAUDE.md(約1万トークン)をキャッシュ前提で参照するため、2本目以降はすべてキャッシュ読み込みに乗ります。

これだけで入力コストが目視で6割以上落ちました。

パターン2: 動的コンテンツを「キャッシュ点の後ろ」へ移す

ProjectDiscovery の公開事例では、キャッシュヒット率が 7% → 74% に跳ね上がったケースが報告されています。やったことは1つだけ、動的フィールドをキャッシュ対象プレフィックスから外側に移しただけ。

具体的にはこういうアンチパターンを潰します。

地味ですが、「キャッシュ点の前に変わるものを置かない」という原則は何度でも唱える価値があります。

パターン3: 1時間キャッシュを「意図して」使う

5分 TTL がデフォルトですが、1時間 TTL も指定可能です。書き込みコストが2倍に上がるので、最低2回以上読まれる確証があるときだけ使います。

{
    "type": "text",
    "text": SYSTEM_PROMPT,
    "cache_control": {"type": "ephemeral", "ttl": "1h"}
}

判断基準はシンプルで、「5分以内に2回叩く確信があるか?」が答えです。Yes なら5分、No だが1時間以内に複数回叩くなら1時間。これだけ。

モデルルーティングで30倍の差を作る

キャッシュだけで満足してはいけません。用途に応じてモデルを振り分けるだけで、同じワークロードのコストが30倍違うこともあります。

私の振り分け基準はこうです。

副業の納品物作成でも、最初の素案出しは Haiku、本文の生成は Sonnet、最終の構造化レビューだけ Opus、という3段ロケットにしています。これで Opus を全工程に使っていた頃の3〜4割のコストに収まりました。

監視:usage を必ずログに残す

最適化したつもりでも、計測しないと意味がありません。cache_creation_input_tokens と cache_read_input_tokens を毎リクエスト記録して、週次でヒット率を眺めます。

安定したエージェントワークロードなら 50〜80% のキャッシュ読み込み比率が現実的な目標値です。1週間運用して20%を下回るなら、それはモデルの問題ではなくプレフィックス設計の問題、と切り分けてください。

簡易ロガーの例:

import json, time

def log_usage(resp, tag=""):
    u = resp.usage
    total = u.input_tokens + u.cache_creation_input_tokens + u.cache_read_input_tokens
    hit_rate = u.cache_read_input_tokens / total if total else 0
    print(json.dumps({
        "ts": int(time.time()),
        "tag": tag,
        "input": u.input_tokens,
        "cache_write": u.cache_creation_input_tokens,
        "cache_read": u.cache_read_input_tokens,
        "output": u.output_tokens,
        "hit_rate": round(hit_rate, 3),
    }))

これを CloudWatch なり BigQuery なりに流し込めば、ダッシュボードで一発でヒット率の劣化が見えます。

まとめ:今日からやる4つのアクション

ここまで読んでくれたあなたが、今日のうちに手を動かせる順序で並べます。

  1. 手元の最大の system prompt に cache_control を1個だけ足す。これは1行で済むのに一番効きます
  2. usage をログに出す関数を仕込む。キャッシュが効いてるかは数値でしか確認できない
  3. 動的な値(タイムスタンプ・ユーザー名)をキャッシュ点より後ろに移す。ヒット率が一気に伸びる
  4. モデルを Haiku / Sonnet / Opus で使い分ける。全部 Opus は2026年では贅沢すぎる選択

5分TTLは確かに痛い変更でした。でも逆に言うと、「設計しないと効かない」という当たり前のことが浮き彫りになっただけです。料理で言えば、火加減を雑にしてもそれなりに食えていた料理が、急に火加減シビアになった——そんな感覚に近いです。

まずは1つ目の cache_control を1行足すところから、今日始めてみてください。来月の請求書が静かに優しくなっているはずです。

参考リンク

この記事をシェア:
X で共有 Facebook で共有 Telegram で共有
次の記事
Claude Codeで月5万円の副業案件を取る方法【2026年最新ロードマップ】