Claude Sonnet 5とは何か、Sonnet 4.6から何が変わったのか

Claude Sonnet 5は、Anthropicが2026年6月30日に発表したSonnet系の最新モデルです。同日にAWSも提供開始を公表し、Amazon Bedrockでは一般提供（GA）としてすでに利用できます。ライフサイクルはActiveでプレビューではありません。2026年2月リリースのSonnet 4.6の後継にあたり、Anthropicは「near-Opusの知性をSonnetの価格帯で」提供する位置づけとして紹介しています。

確定しているスペックは、コンテキストウィンドウが1Mトークン、最大出力が128Kトークン、knowledge cutoffが2026年1月です。入力はテキストと画像に対応し、出力はテキストのみです。実装上で特に押さえたいのが推論の扱いです。Sonnet 5ではadaptive thinkingが常時ONで無効化ができず、代わりにeffort levelで思考の深さを制御します。この点は4.6世代からの実装上の違いとして重要になります。

料金はオンデマンドかつStandard tierで、2026年8月31日までのプロモ価格が入力100万トークンあたり2ドル、出力10ドルです。2026年9月1日以降は入力3ドル、出力15ドルへ移行します。なお前世代4.6の詳細スペックやSWE-bench等の具体的なベンチマークスコアは本記事では断定しません。定量比較が必要な場合はAnthropicのSystem Cardをご確認ください。

Amazon BedrockでClaude Sonnet 5を呼び出す

Amazon Bedrockには複数のモデルIDと推論プロファイルがあります。In-Region用のベースモデルIDは anthropic.claude-sonnet-5、地域横断のGeoプロファイルは us.anthropic.claude-sonnet-5 と eu.anthropic.claude-sonnet-5、グローバルは global.anthropic.claude-sonnet-5 です。In-Regionのベースモデルに対応するのは us-east-1 と eu-west-1 のみで、東京（ap-northeast-1）を含むアジアパシフィックからはGlobalプロファイルのみ対応します。東京で使う場合は global.anthropic.claude-sonnet-5 を指定してください。

まずは推奨のプロバイダ非依存インタフェースであるConverse APIの例です。systemは配列で渡し、max_tokensは inferenceConfig.maxTokens に置く点がポイントです。

import boto3

client = boto3.client("bedrock-runtime", region_name="us-east-1")

response = client.converse(
    modelId="anthropic.claude-sonnet-5",  # 東京は global.anthropic.claude-sonnet-5
    system=[{"text":"あなたは有能なアシスタントです。"}],
    messages=[
        {"role":"user", "content":[{"text":"Amazon Bedrock の特徴を説明して。"}]}
    ],
    inferenceConfig={"maxTokens":1024, "temperature":0.3},
)
print(response["output"]["message"]["content"][0]["text"])
print(response["usage"])  # inputTokens / outputTokens / cacheReadInputTokens 等

リアルタイムに逐次出力したい場合はConverseStream（converse_stream）を使い、contentBlockDeltaのtextを追記していきます。

resp = client.converse_stream(
    modelId="anthropic.claude-sonnet-5",
    messages=[{"role":"user", "content":[{"text":"長文を書いて"}]}],
    inferenceConfig={"maxTokens":2048},
)
for event in resp["stream"]:  # ストリームを逐次処理します
    if "contentBlockDelta" in event:  # 差分イベントのみ取り出します
        print(event["contentBlockDelta"]["delta"].get("text",""), end="")

Anthropicネイティブなmessages形式が必要な場合はInvokeModelを使い、body側にsystem、messages、max_tokensを渡します。ストリーミングは invoke_model_with_response_stream です。いずれのAPIでもusageに inputTokens、outputTokens、cacheReadInputTokens などが返り、コスト集計に活用できます。

body = json.dumps({
    "anthropic_version":"bedrock-2023-05-31",
    "system":"簡潔に答えて",
    "messages":[{"role":"user", "content":"Bedrock の特徴は?"}],
    "max_tokens":1024,
})
response = client.invoke_model(modelId="anthropic.claude-sonnet-5", body=body)
print(json.loads(response["body"].read()))

prompt cachingでコストを最適化する

コスト最適化で最優先の施策がprompt cachingです。systemプロンプトやツール定義、共有ナレッジといった静的で繰り返し使う部分をcachePoint化すると、2回目以降のリクエストではその部分をキャッシュから読み取れます。読み取りは通常入力より低いレートで済むため、同じ前提を毎回送るワークロードほど効果が出ます。

Sonnet 5でのprompt cachingの制約は次の通りです。最小トークン数は4,096、1リクエストの最大チェックポイント数は4、対応TTLは5分と1時間、配置できるフィールドは system、messages、tools の3つです。Converse APIでは cachePoint {"type":"default","ttl":"5m|1h"} を置きます。TTL省略時は5分です。InvokeModel（Claude）では cache_control {"type":"ephemeral","ttl":"5m|1h"} を付与します。

response = client.converse(
    modelId="anthropic.claude-sonnet-5",
    system=[
        {"text":"（4,096トークン以上の静的な指示・ナレッジ本文…）"},
        {"cachePoint":{"type":"default","ttl":"1h"}},  # ttl省略時は5分
    ],
    messages=[{"role":"user", "content":[{"text":"上記に基づき回答して"}]}],
    inferenceConfig={"maxTokens":1024},
)
u = response["usage"]
# 総入力 = inputTokens + cacheReadInputTokens + cacheWriteInputTokens
print(u.get("cacheReadInputTokens"), u.get("cacheWriteInputTokens"))

チェックポイントの処理順は tools、system、messages の順で、安定したコンテンツを前に、可変のコンテンツを後ろに置きます。最小トークン数は3セクションの合算で判定されます。TTLは高頻度な呼び出しなら5分、間隔が空くエージェント処理や長い会話なら1時間が向き、1時間キャッシュは5分キャッシュより前に配置する制約があります。トークン集計では、総入力が inputTokens、cacheReadInputTokens、cacheWriteInputTokens の3項の和になり、inputTokensはキャッシュ非該当分のみを表します。なお読み取りと書き込みの具体的な倍率はSonnet 5について公式で確認できていないため断定を避け、読み取りは低レート、書き込みは高レートになり得るという定性的な理解にとどめます。

バッチ推論とモデル使い分けでさらにコストを下げる

非リアルタイムの処理にはバッチ推論が有効です。分類、要約、データエンリッチメント、評価パイプラインといった即時応答が不要なワークロードをS3へのJSONL投入で非同期に処理すると、Amazon Bedrockのバッチ推論は一般にオンデマンド比でおおむね50%の割引になります。ただし重要な設計判断として、prompt cachingはオンデマンド限定でバッチとは併用できません。リアルタイムでキャッシュを効かせるか、バッチで50%割引を取るかをワークロードごとに切り分けます。

モデルの使い分けもコストに直結します。高スループットで単純な処理はHaiku系、標準的なエージェントやコーディングはSonnet 5、最高精度が要る局面のみOpusという分担が目安です。Sonnet 5は価格帯を据え置きつつ知性を高めた位置づけのため、従来Opusに投げていたワークロードのダウンサイズを検討する余地があります。

出力単価は入力の約5倍のため、過大なmaxTokensを避けて必要十分な値に設定することが効きます。さらにプロモ価格の2ドルと10ドルは2026年8月31日までで、9月1日以降は3ドルと15ドルへ移行するため、予算試算には移行後価格も織り込んでおくことが望ましいです。1Mコンテキストに対応していても入力トークンはそのまま課金対象のため、長文や画像を毎回送るならキャッシュの併用が事実上必須です。

実装でよくあるミスと対処法

実装でつまずきやすいポイントと対処を表にまとめます。リージョンやスループットに関わる問題は推論プロファイルの選択で解消できるものが多く、東京から使う場合はglobal.が必須である点を押さえておくと安全です。

そのほか、adaptive thinkingは無効化できないため、思考を抑えたい場合はeffort levelで調整します。出力が途中で切れるのはmaxTokens不足で、最大128Kまで拡張できます。トークン集計が合わないときは、総入力が inputTokens、cacheReadInputTokens、cacheWriteInputTokens の3項の和である点を確認してください。