Synthorai で使う Claude Opus 4.8：キャッシュと TTL を 4.7/4.6 と比較

claude-opus-4-8 が Synthorai ゲートウェイで利用可能になりました。すでに Opus 系列でプロンプトキャッシュを運用しているなら、見出しは安心できると同時にやや退屈なものです。キャッシュや TTL の契約は 4.7 や 4.6 から何も変わっていません。 同じ cache_control マーカー、同じ 5 分と 1 時間の TTL、同じ読み取り割引、同じ書き込みプレミアム。あなたのキャッシュコードはそのまま流用できます。

ただ一つだけ変わったものがあります——しかもそれは 4.8 ではなく 4.7 の時点で変わっており——トークン予算に影響します。本記事はそれをあなたの代わりに測定しました。

以下のすべての数値は、2026-05-29 に https://synthorai.io/（Anthropic ネイティブの /v1/messages）に対して、約 8K 文字の英語システムプロンプト、小さめの max_tokens、単一の逐次実行で測定したものです。引用する前に、ご自身のプロンプトで再現してください。

利用可能状況

import os
from anthropic import Anthropic

anth = Anthropic(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/",   # SDK appends /v1/messages
)

msg = anth.messages.create(
    model="claude-opus-4-8",            # the only line that changes
    max_tokens=512,
    system=[
        {"type": "text", "text": SYSTEM_PROMPT,
         "cache_control": {"type": "ephemeral"}},
    ],
    messages=[{"role": "user", "content": question}],
)
print(msg.usage)   # cache_creation_input_tokens, cache_read_input_tokens, cost

claude-opus-4-7 → claude-opus-4-8 に置き換えれば、キャッシュ経路の他の部分は一切動かす必要がありません。cache_control の背後にある仕組みはキャッシュチュートリアルで扱っています。キャッシュがなぜ存在するのかというアーキテクチャはシリーズ第 1 部にあります。

キャッシュの挙動：4.7/4.6 から変わらず

直近の Opus 系列に対して、同じキャッシュ書き込み / キャッシュ読み取り / キャッシュなしのシーケンスを実行しました。割引構造は最初から最後まで完全に同一です。

4 つのバージョンすべてで 2 つの不変条件が成り立ちます。

• 読み取り割引 ≈ 89%。 ウォームキャッシュの読み取りコストは、キャッシュなし入力価格の約 11% です。これは Anthropic が文書化している 10% のキャッシュ読み取りレートで、変わっていません。
• 書き込みプレミアム ≈ 25%。 最初の（コールドな）呼び出しはキャッシュを充填するために、キャッシュなし価格の約 1.25 倍かかります。1 回のヒットで損益分岐します。

4.7 と 4.8 の絶対的なドル金額は 4.5/4.6 より高いですが、後ほど見るように、それはトークン数の話であってキャッシュの経済性の話ではありません——パーセンテージは横ばいです。

TTL の挙動：4.7/4.6 から変わらず

Opus 4.8 は系列の他のメンバーと同じ 2 つの TTL に従います。5 分のスライディングなデフォルトと、オプトインの 1 時間ウィンドウです。呼び出しごとに一意のプレフィックスを使って TTL 経路を分離し（古いキャッシュエントリが結果を汚染しないように）、各 TTL の書き込みプレミアムを測定しました。

# 1-hour TTL — same marker syntax on 4.8 as on 4.7/4.6
"cache_control": {"type": "ephemeral", "ttl": "1h"}

usage オブジェクトは以前とまったく同じように TTL バケットを報告します——cache_creation.ephemeral_5m_input_tokens または ephemeral_1h_input_tokens。1 時間の書き込みはキャッシュなしの約 2 倍（5 分の書き込みの約 1.25 倍に対して）かかり、読み取りは TTL に関係なく約 11% に留まります。4.7 と同一です。4.7 でライブチャットに 5m、人間が介在する一時停止のあるエージェントに 1h を選んでいたなら、4.8 でもその選択を維持してください。

最初のトークンまでの時間：系列全体で横ばい

ストリーミング呼び出しでウォーム読み取りの TTFT を測定しました（ゲートウェイのウォームアップ後にモデルごとに 5 サンプル、中央値を報告）。この約 8〜11K トークンのプロンプトでは、TTFT は約 2.2〜2.8 秒の帯域に収まり、バージョンごとの実質的な傾向はありません——サンプル範囲は重なっており、差はバージョンの効果ではなくジッターです。

明確に述べておくべき注意点が 2 つあります。

• ここからランキングを読み取らないでください。 範囲は大きく重なっています（4.8 の高い値のサンプルは 4.38 秒の外れ値でした）。このプロンプトサイズでは TTFT はモデルのバージョンではなくネットワークとキューイングのジッターに支配されます。約 2.2〜2.8 秒を 4 つすべてのウォーム帯域として扱ってください。
• キャッシュによる TTFT の利得はプロンプト長に応じて拡大します。 約 8〜11K トークンでは、キャッシュヒットによって節約されるプリフィルは小さいため、コールドとウォームの TTFT は近くなります（ウォームアップ済みゲートウェイではどちらも約 2〜3 秒）。100K 以上のトークンでプリフィルが支配的になると、その差は大幅に広がります——そこではウォームキャッシュが数秒の待ち時間を高速な最初のトークンに変えます。仕組みは第 1 部：KV キャッシュと TTL の仕組みにあります。

唯一の本当の変更：トークン化（4.7 以降）

これが移行前に再確認すべきことです。同じシステムテキストが、4.5/4.6 よりも 4.7/4.8 で約 43% 多い入力トークンを報告します。

トークン数は 4.7 世代で跳ね上がり、4.8 へと引き継がれます。コストはトークン数をほぼ正確に追従します。コスト比（4.8 / 4.5）は 1.43、トークン比は 1.429 です。言い換えれば、系列全体でトークンあたりの価格は同じであり——4.7/4.8 での高い請求額は、まったく同じテキストがより多くのトークンとして数えられることからすべて来ています。

実際的な帰結が 2 つあります。

1. 割引ではなく絶対コストで予算を組み直してください。 あなたのキャッシュ割引は変わっていません（読み取り約 89%）が、同じ英語プロンプトの絶対コストは 4.6 より 4.7/4.8 で約 43% 高くなります。4.6 のトークン数に対して 1 回あたりの予算を見積もっていたなら、ずれます。
2. 1,024 トークンのキャッシュ対象下限を再確認してください。 Anthropic は最小サイズ以上のプレフィックスのみをキャッシュします。4.6 で下限をわずかに下回っていたプロンプトが、4.7/4.8 ではそれを超える（トークンが多い）可能性があり、古いトークナイザー用にトークンでサイズ設定されたプロンプトは再測定が必要です。一致しない可能性のあるローカルトークナイザーからの推定ではなく、常にライブレスポンスから cache_creation_input_tokens / cache_read_input_tokens を読み取ってください。

私たちが説明しているのは実測の観察です——同一テキストで 4.7/4.8 が約 43% 多い入力トークンを報告した——これは 4.7 世代でのトークナイザー/語彙の更新と最も整合します。ただし結論は根本原因に依存しません。移行時にはトークン数を再測定してください。キャッシュの計算はトークンベースだからです。

移行チェックリスト（4.6/4.7 → 4.8）

• ✅ キャッシュコードはそのまま引き継がれます。 cache_control マーカー、ブレークポイント数（最大 4）、ttl: "1h"、usage フィールド名——すべて同一です。
• ✅ TTL の選択は引き継がれます。 ライブ/セッションのワークロードには 5m、バースト的/一時停止のあるエージェントには 1h。
• ✅ 割引の経済性は引き継がれます。 読み取り約 89%、書き込み約 1.25×（5m）、書き込み約 2×（1h）。
• ⚠️ トークン数を再測定してください。 4.5/4.6 から移る場合、同じテキストで入力トークンが約 40% 以上増えると見込んでください（これは 4.7 で起きました）。4.7 から移るなら同等と見込めます。
• ⚠️ コストダッシュボードを再検証してください。 古い世代のキャッシュされた推定ではなく、ライブレスポンスの usage.cost と *_input_tokens フィールドを信頼してください。

まとめ

すでに Opus でキャッシュしているエンジニアリングチームにとって、claude-opus-4-8 は楽なタイプのアップグレードです。キャッシュと TTL の面全体が安定しているので、学び直すことも書き直すコードもありません。4.6 以前からジャンプするならトークナイザーの変化を予算に織り込み、ライブの usage オブジェクトに照らして数値を確認し、リリースしてください。

完全なキャッシュの手引き——プロンプト構造、ヒット率のデバッグ、TTL を意識したパターン——については、KV キャッシュと TTL の仕組みから始まる 4 部構成のシリーズと、動作する Python チュートリアルをご覧ください。

FAQ

Opus 4.8 を使うのに cache_control のコードを変える必要はありますか？ いいえ。マーカー構文、ブレークポイントの上限、TTL のオプションは 4.7/4.6 と同一です。model フィールドだけを変えれば、他は何も変える必要はありません。

キャッシュ読み取り割引は 4.8 で変わりましたか？ いいえ。ウォーム読み取りはキャッシュなし入力価格の約 11%（約 89% オフ）で、4.5 から 4.8 まで同じであり、Anthropic が文書化したレートと一致します。

1 時間 TTL のプレミアムは変わりましたか？ いいえ。1 時間の書き込みはキャッシュなし入力価格の約 2 倍、5 分の書き込みは約 1.25 倍です。読み取りは TTL に関係なく約 11% です。4.7 と同じです。

なぜ同じプロンプトが 4.6 より 4.8 で高いのですか？ トークンあたりの価格は同じです——プロンプトが単純により多くのトークンとして数えられるだけです。私たちの測定では、同一テキストが 4.5/4.6 で約 8.0K トークン、4.7/4.8 で約 11.4K トークン（約 43% の増加）を報告し、これは 4.7 世代でのトークナイザー変更と最も整合します。キャッシュ割引は変わっていません。

4.8 は 4.7 のドロップイン代替ですか？ キャッシュ/TTL の面では、はい——トークン数と経済性はすでに 4.7 のレベルにあったので、4.7 からの移行は同等です。私たちは実施していない能力ベンチマークは公開しません。品質と推論に関する主張については、Anthropic のモデルカードをご覧ください。

検証：すべてのキャッシュ、TTL、トークン数、コスト、TTFT の数値は、2026-05-29 に https://synthorai.io/ に対し、公式の anthropic SDK、シングルテナントで測定しました。コスト/トークンの数値は単一の逐次実行です。TTFT はゲートウェイのウォームアップ後にモデルごとに 5 サンプルの中央値です。割引/プレミアム比率は Anthropic プロンプトキャッシュのドキュメント と相互確認しました。あなたの数値はプロンプト、リージョン、負荷によって異なります。

← ブログに戻る