Claude Sonnet 5.5 で cache read 価格が半額に改定、値下げ効果を実測してみた

はじめに

2026年10月7日に、Anthropic の Haiku 5.5 のリリース発表の中で、Claude Sonnet 5.5 の cache read 料金が半額になる案内がありました。

https://www.anthropic.com/claude-haiku-5-5

この記事では、Amazon Bedrock の Sonnet 5.5 でも cache read 料金が改定されていることを確認し、Converse API でプロンプトキャッシュを効かせたチャットを実行して、その効果を実測した結果を紹介します。

料金改定内容

案内によると、cache read は50%安くなり、100万トークンあたり $0.20 から $0.10 になるとされています。

Anthropic は、この値下げの効果を次のように説明しています。

Because cache reads make up a large share of models’ token consumption, this reduces the cost of Sonnet 5.5 on most agentic tasks by around 20%.

Bedrock の単価

Bedrock の単価は Price List API の get-products で引けます。サービスコードは AmazonBedrockFoundationModels で、モデルは servicename で絞ります。

aws pricing get-products --region us-east-1 --service-code AmazonBedrockFoundationModels \
  --filters 'Type=TERM_MATCH,Field=servicename,Value=Claude Sonnet 5.5 (Amazon Bedrock Edition)' \
            'Type=TERM_MATCH,Field=regionCode,Value=us-east-1'

次の表は us-east-1 の単価です。Sonnet 5.5 の列は上の結果から、Sonnet 5 の列は Price List API の Bulk API（index.json）から取り出しました。単位は USD / 1M tokens です。

改定前の Sonnet 5.5 の cache read は、現在の Sonnet 5 と同じでした。

https://dev.classmethod.jp/articles/bedrock-claude-sonnet-5-5/

AWS の料金ページの Anthropic の欄にも、10月7日から Sonnet 5.5 の cache read 料金を従来より50%引き下げたとの注記があります。

https://aws.amazon.com/bedrock/pricing/

キャッシュの利用条件

Bedrock のドキュメントによると、キャッシュがヒットする条件は次の3つです。

• 先頭から同じ内容が続くこと。チェックポイントは tools → system → messages の順に処理され、前段を変えると後段のキャッシュも無効になります。
• チェックポイントまでのプレフィックスが最小トークン数以上であること。Sonnet 5.5 は 512、Sonnet 5 は 1,024 です。
• TTL 内に再利用されること。TTL は5分か1時間で、ヒットのたびに延びます。1時間を選ぶと cache write の単価が高くなります。

この条件に合うのは、固定の長い system プロンプトやドキュメントに質問を重ねるチャット、tools 定義が長いエージェントなどです。

Converse API でのキャッシュ利用

Converse API では、キャッシュしたい範囲の末尾に cachePoint を置きます。今回は system の末尾と、各ターンの最新のユーザーメッセージの末尾の2か所です。2ターン目のリクエストは次の構造になります。

{
  "modelId": "global.anthropic.claude-sonnet-5-5",
  "system": [
    {"text": "<固定ドキュメントを含む指示文>"},
    {"cachePoint": {"type": "default"}}
  ],
  "messages": [
    {"role": "user", "content": [{"text": "<1問目>"}]},
    {"role": "assistant", "content": [{"text": "<1問目の回答>"}]},
    {"role": "user", "content": [{"text": "<2問目>"}, {"cachePoint": {"type": "default"}}]}
  ],
  "inferenceConfig": {"maxTokens": 300}
}

今回の条件は次のとおりです。

• system：約16,400トークンの固定ドキュメントと、「ドキュメントだけを根拠に、3文以内の日本語で答える」旨の指示
• 質問：短い日本語の20問を、会話の履歴を引き継ぎながら順に送る
• 回答：maxTokens 300 を上限として設定

リクエストは AWS CLI で送ります。

aws bedrock-runtime converse --region us-east-1 \
  --cli-input-json file://<リクエスト>.json --output json

2ターン目の usage は次のとおりです。

"usage": {
    "inputTokens": 4,
    "outputTokens": 300,
    "totalTokens": 16983,
    "cacheReadInputTokens": 16433,
    "cacheWriteInputTokens": 246,
    "cacheDetails": [
        {
            "ttl": "5m",
            "inputTokens": 246
        }
    ]
}

1ターン目に書き込んだ 16,433 トークンが、2ターン目で cache read として読まれています。

#!/usr/bin/env python3
"""使い方: chat-driver.py <model-id> <cache|nocache> <turns>"""
import json, subprocess, sys

model, mode, turns = sys.argv[1], sys.argv[2], int(sys.argv[3])
cache = mode == "cache"

questions = [l.strip() for l in open("questions.txt", encoding="utf-8") if l.strip()]
doc = open("document.txt", encoding="utf-8").read()
system_text = ("あなたは Amazon Bedrock のドキュメント担当アシスタントです。"
               "次のドキュメントだけを根拠に、日本語で、3文以内で簡潔に答えてください。\n\n"
               "<document>\n" + doc + "\n</document>")

history = []
for i in range(turns):
    user = {"role": "user", "content": [{"text": questions[i]}]}
    if cache:
        user["content"].append({"cachePoint": {"type": "default"}})
    system = [{"text": system_text}]
    if cache:
        system.append({"cachePoint": {"type": "default"}})
    req = {"modelId": model, "system": system, "messages": history + [user],
           "inferenceConfig": {"maxTokens": 300}}
    path = f"request-{i+1:02d}.json"
    json.dump(req, open(path, "w", encoding="utf-8"), ensure_ascii=False)

    proc = subprocess.run(
        ["aws", "bedrock-runtime", "converse", "--region", "us-east-1",
         "--cli-input-json", "file://" + path, "--output", "json"],
        capture_output=True, text=True, check=True)
    resp = json.loads(proc.stdout)

    # 回答は text ブロックだけを履歴へ戻す（reasoningContent は戻さない）
    blocks = resp["output"]["message"]["content"]
    answer = "".join(b["text"] for b in blocks if "text" in b)
    u = resp["usage"]
    print(f"turn {i+1:02d} in={u['inputTokens']} out={u['outputTokens']} "
          f"cr={u.get('cacheReadInputTokens', 0)} cw={u.get('cacheWriteInputTokens', 0)} "
          f"stop={resp['stopReason']}", flush=True)

    history += [{"role": "user", "content": [{"text": questions[i]}]},
                {"role": "assistant", "content": [{"text": answer}]}]

チャットの費用の実測

値下げの効果

Sonnet 5.5（Global）で会話を実行したときの費用です。単価は前述の表のとおりです。費用の単位は USD、input は毎ターン 4 トークンです。累計の削減率は、そのターンまでの累計費用で改定前と改定後を比べた値です。合計は全ターンの値です。

累計の削減率は、改定前の費用に占める cache read の割合の半分になります。この条件では20ターン目までの累計で cache read が改定前の費用の約4割を占め、削減率は20.0%になりました。

合計の計算式は次のとおりです。

改定前: 80 × 2.00 + 5,302 × 10.00 + 350,380 × 0.20 + 20,681 × 2.50 = 174,958.5（÷ 1,000,000 = $0.1750）
改定後: cache read が 350,380 × 0.10 = 35,038 になるので 139,920.5（$0.1399）
削減額: 350,380 × (0.20 − 0.10) ÷ 1,000,000 = $0.0350
削減率: 0.0350 ÷ 0.1750 = 20.0%

改定前の費用に占める cache read は 40.1% で、これが半額になったため、削減率は 40.1% × 50% ≒ 20% になります。今回実測した条件での削減率は 20% でした。

キャッシュあり・なし

同じ system プロンプトと質問を、Sonnet 5.5 で cachePoint なしでも実行しました。次の表は、改定後の単価で計算した、そのターンまでの累計費用（USD）です。

1ターン目だけキャッシュありが高いのは、同じ 16,433 トークンを、入力の単価（2.00）ではなく cache write の単価（2.50）で処理するためです。2ターン目の累計で逆転し、20ターン目の累計ではキャッシュありが82%安くなりました。

Sonnet 5 との費用比較

同じ system プロンプトと質問を Sonnet 5 でも実行し、Sonnet 5.5 の実測と並べました。費用は Global の単価で計算しました。

1ターン目の cache write はどちらも 16,433 トークンで、Sonnet 5 から 5.5 に切り替えても入力トークンは大きく増えていません。

出力量が同等であれば、cache read の単価が 0.20 から 0.10 に下がる分が、そのまま節約になります。

まとめ

Claude Sonnet 5.5 の cache read 単価が半額になりました。

今回のように長い system プロンプトをチャットで繰り返し送る処理では、費用に占める cache read の割合が大きくなるため、値下げの効果が大きく出ることを確認できました。

Sonnet 5.5 を利用しているがキャッシュを利用していない場合、キャッシュを活用する余地がないか見直すことをおすすめします。