CLAUDE LABEN
MODEL — Claude Sonnet 5が全プランの既定モデルになり、計画・ツール利用・自律実行が強化されましたPRICE — Sonnet 5は導入価格が100万トークンあたり入力$2・出力$10で、8月31日まで適用されますMODEL — Sonnet 5の性能はOpus 4.8に迫りつつ、より低価格でエージェントを常時運用できますCODE — Claude CodeがSonnet 5を既定モデルに採用し、ネイティブ1Mトークンのコンテキストに対応しましたCODE — Claude Codeにサンドボックスの資格情報ブロックと組織単位のモデル制限が追加されましたCLOUD — ClaudeがMicrosoft Foundry(Azure)で一般提供され、Azureネイティブで利用できますMODEL — Claude Sonnet 5が全プランの既定モデルになり、計画・ツール利用・自律実行が強化されましたPRICE — Sonnet 5は導入価格が100万トークンあたり入力$2・出力$10で、8月31日まで適用されますMODEL — Sonnet 5の性能はOpus 4.8に迫りつつ、より低価格でエージェントを常時運用できますCODE — Claude CodeがSonnet 5を既定モデルに採用し、ネイティブ1Mトークンのコンテキストに対応しましたCODE — Claude Codeにサンドボックスの資格情報ブロックと組織単位のモデル制限が追加されましたCLOUD — ClaudeがMicrosoft Foundry(Azure)で一般提供され、Azureネイティブで利用できます
記事一覧/API & SDK
API & SDK/2026-07-02上級

モデルを切り替えた朝、キャッシュヒット率はゼロに戻る — Opus 4.8 から Sonnet 5 への段替えとプロンプトキャッシュ再ウォーム設計

プロンプトキャッシュはモデル単位で分離されるため、モデル移行の初日はヒット率が0%から始まります。割合ベースの段階移行が二重にコストを壊す構造と、タスク系統単位で切り替えるコホート・カットオーバー設計を実測コードつきで整理します。

prompt-caching12claude-sonnet-5claude-opus-4-8model-migration3cost-optimization23

プレミアム記事

7月1日の朝、Claude Sonnet 5 の導入価格(100万入力トークンあたり $2、出力 $10)の告知を確認して、夜間バッチのモデルを Opus 4.8 から段階的に移す検討を始めました。

私自身、複数サイト向けの定期バッチをプロンプトキャッシュ前提で回しております。まず試しに1系統だけ Sonnet 5 へ向けたところ、その晩の実行ログで cache_read_input_tokens がゼロに落ち、代わりに cache_creation_input_tokens が全実行に立っていました。単価が6割下がったはずの晩に、その系統の請求はむしろ増えていた。この「切替初日の逆転現象」が、本稿の出発点です。

プロンプトキャッシュはモデルごとに別の世界です。ここを設計に織り込まずに移行すると、安くするための切替がしばらくの間だけ高くつきます。順に整理してまいります。

切替の朝に何が起きるか — キャッシュはモデル単位で分離される

Anthropic のプロンプトキャッシュは、キャッシュされたプレフィックスがモデルごとに独立しています。claude-opus-4-8 で温めたプレフィックスは、claude-sonnet-5 へのリクエストからは一切参照されません。組織・モデル・プレフィックス内容の組が一致して初めてヒットします。

料金の構造も思い出しておきます。キャッシュ書き込みは基本入力単価の 1.25 倍(5分 TTL の場合。1時間 TTL は 2 倍)、キャッシュ読み取りは 0.1 倍です。つまり切替初日は、全系統のプレフィックスが「0.1 倍で読めていたもの」から「1.25 倍で書き直すもの」に変わります。キャッシュされていた部分だけ見れば、単価はその瞬間 12.5 倍。

具体的な数字にします。8,000 トークンのプレフィックスを共有する系統で、Sonnet 5 の導入価格を使う場合を考えます。

  • ウォームな実行 — 読み取り 8,000 × $0.2/MTok = 約 $0.0016
  • コールドな実行 — 書き込み 8,000 × $2.5/MTok = 約 $0.02

1回あたりの差は小さく見えますが、系統が 10 個、1日の実行が数百回の規模になると、移行のやり方次第でこの差が数日から数週間続きます。逆に言えば、コールドライトは本来「系統ごとに 1 回」で済むはずのものです。何回払うかは移行戦略が決めます。

割合ベースの段階移行がキャッシュ経済を二重に壊す理由

モデル移行の定石として「まず 10%、様子を見て 50%、最後に 100%」というリクエスト単位の割合分割を考えたくなります。品質リスクの管理としては合理的ですが、プロンプトキャッシュの観点では最悪の分割です。壊れ方が二つあります。

一つ目は、二重のコールドライト。 割合分割ではすべてのプレフィックスが両方のモデルに流れます。プレフィックスが 12 種類あれば、コールドライトは 12 回ではなく 24 回。さらに TTL が切れるたびに、両側で再ウォームが発生し続けます。

二つ目が本命で、TTL 飢餓です。 5分 TTL は「使うたびに延長」されますが、延長されるのはそのモデル側のキャッシュだけです。4分間隔で回る監視系のタスクを考えます。100% 片側なら、2回目以降は常に TTL 内でヒットし続けます。これを 50/50 に分割すると、各モデルから見た平均到着間隔は 8 分に伸び、5分 TTL を毎回超えます。結果、両側でほぼ全実行がコールドライトになる。ヒット率 100% だった系統が、分割した瞬間に双方 0% 近くへ落ちます。

まとめると、こうなります。

移行戦略コールドライト回数ヒット率への影響品質検証
一括切替系統ごとに1回切替直後のみ低下全系統を同時に賭ける
割合分割(リクエスト単位)全系統 × 両モデル、TTL切れごとに再発疎な系統は両側ほぼ0%に低下細かく制御できる
コホート・カットオーバー(系統単位)移行した系統ごとに1回移行済み・未移行とも維持系統単位で段階検証できる

割合分割の「品質検証のしやすさ」だけを残し、キャッシュの壊れ方を避けるのが、次のコホート・カットオーバーです。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
プロンプトキャッシュがモデル単位で分離される仕組みと、切替初日に cache_creation_input_tokens が跳ね上がる様子を usage ブロックの実測で確認する手順
割合ベースの段階移行が『二重のコールドライト』と『TTL 飢餓によるヒット率ほぼ 0%』を招く計算根拠と、タスク系統単位のコホート・カットオーバー設計(動く TypeScript 実装つき)
導入価格の期限(2026-08-31)から逆算した移行コストシミュレータと、切替週だけ 1 時間 TTL を併用する損益分岐の考え方
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Claude Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

API & SDK2026-06-29
Claude API の Context Editing を入れたらエージェントが同じ調査を繰り返したとき — クリア境界とキャッシュ無効化を計測する運用メモ
Context Editing でツール結果を自動クリアしたら、エージェントが直前に読んだ内容を忘れて同じツールを呼び直し、キャッシュも毎回壊れてコストが上がった。沈黙する劣化を計測ログで切り分け、trigger・keep・clear_at_least を実測で決める運用メモです。
API & SDK2026-06-24
ツール定義を一行直しただけで、キャッシュが丸ごと作り直しになりました — cache_control ブレークポイントの置き場所
ヒット率が突然ゼロに張り付いた原因は、揮発するブロックを安定したブロックより上流に置いていたことでした。prefix キャッシュのカスケード失効の仕組みと、安定→揮発でブロックを並べ替え、4つしかない cache_control ブレークポイントをどこに置くかを実装と判断表で整理します。
API & SDK2026-06-24
毎朝のバッチでプロンプトキャッシュが毎回ミスしていた — 1時間TTLを延命するウォーミング間隔と損益分岐の出し方
数時間おきに走る定期実行では、1時間TTLのプロンプトキャッシュでも毎回コールドミスします。中身を変えずにTTLを延命するウォーミングの間隔をTTLから逆算し、読み取りコストを織り込んだ損益分岐を式で出す方法を、4サイトの自動生成パイプラインの実測とともにまとめました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →