Anthropicは2026年6月30日、Claude Sonnet 5を公開した。モデルIDはclaude-sonnet-5で、Claude APIの全顧客に提供されている。

表面上はClaude Sonnet 4.6からモデルIDを置き換えられる構成だが、実務上は単純な差し替えではない。新しいトークナイザー、思考設定、サンプリングパラメーター、料金適用期間に関して、既存システムの前提が変わる。

30秒で分かる変更

項目Claude Sonnet 5の内容
モデルIDclaude-sonnet-5
コンテキスト100万トークン
最大出力12万8000トークン
導入価格入力2ドル、出力10ドル／100万トークン
導入価格の終了2026年8月31日
標準価格入力3ドル、出力15ドル／100万トークン
新トークナイザー同じ文章でSonnet 4.6より約30％多いトークン
手動extended thinking非対応、指定すると400エラー
非標準サンプリング値temperature、top_p、top_kを変更すると400エラー
Priority Tier利用不可

導入価格は期間限定である。9月1日以降は標準価格へ移行するため、7月または8月の利用実績をそのまま年間予算へ延長すると過小評価になる。

同じ文章でもトークン数が増える

Claude Sonnet 5は新しいトークナイザーを使用する。Anthropicによると、同じ入力テキストはClaude Sonnet 4.6と比べておおむね30％多いトークンになる。増加率は文章の内容によって変わる。

これはリクエスト形式の変更ではないが、次の数値へ直接影響する。

  • APIのusageに記録される入力・出力トークン
  • 100万トークンのコンテキストに実際に入る文章量
  • max_tokensで確保した出力上限
  • プロンプトキャッシュの保存量と料金
  • 1リクエスト当たりの費用
  • レート制限に対する消費量

標準のトークン単価がSonnet 4.6と同じでも、同じ文章を処理するためのトークン数が増えれば、実際の請求額は増える可能性がある。単価表だけを見て「同価格」と判断してはいけない。

導入価格終了後の費用差

導入価格と標準価格は次の通りである。

期間入力出力
2026年8月31日まで2ドル／100万トークン10ドル／100万トークン
2026年9月1日以降3ドル／100万トークン15ドル／100万トークン

単価は9月1日に入力・出力とも50％上がる。さらに新トークナイザーで同じ文章のトークン数が増える可能性があるため、移行後の費用差は「単価の50％増」だけでは評価できない。

例えば、現在の月間利用量をSonnet 4.6のトークン数で集計している場合、その値へ新単価を掛けるだけでは不十分である。Sonnet 5のトークンカウントAPIまたは試験リクエストで、実データを再計測する必要がある。

移行時に400エラーになる設定

手動extended thinking

Claude Sonnet 5では、次のような手動の思考予算指定は利用できない。

{
  "thinking": {
    "type": "enabled",
    "budget_tokens": 16000
  }
}

この形式を送ると400エラーになる。Anthropicはadaptive thinkingへの移行を求めている。Sonnet 5ではadaptive thinkingが既定で有効である。

サンプリングパラメーター

temperature、top_p、top_kへ既定値以外を設定したリクエストも400エラーになる。出力の揺らぎを抑える目的でtemperature: 0などを明示しているコードは、削除またはモデル別の条件分岐が必要である。

既存SDKの共通ラッパーがすべてのモデルへ同じサンプリング値を付与している場合、アプリケーション側で設定していなくてもエラーになる可能性がある。HTTPリクエストの最終形をログまたはテストで確認すべきである。

利用可能な基盤にも差がある

Anthropicの公式資料では、Claude Sonnet 5は次の環境で利用できる。

  • Claude API
  • Claude in Amazon Bedrock
  • Claude Platform on AWS
  • Google Cloud
  • Microsoft Foundry

一方、従来のAmazon BedrockにおけるInvokeModelおよびConverse APIを使うレガシー経路では利用できない。AWS上でClaudeを利用している企業は、「Amazon Bedrockで使える」という表現だけで判断せず、自社がどの提供経路とエンドポイントを利用しているかを確認する必要がある。

誰に影響するか

影響が大きいのは次のシステムである。

  • Claude Sonnet 4.6を本番利用している
  • トークン数を事前計算し、入力を上限近くまで詰めている
  • max_tokensを出力長に合わせて厳密に設定している
  • temperature、top_p、top_kを共通設定している
  • budget_tokensを使って思考量を制御している
  • 8月までの導入価格で予算を算定している
  • AWSの旧InvokeModelまたはConverse経路を使っている

必要な対応

1. 実データでトークン数を再計測する

テスト用の短いプロンプトだけでなく、長い日本語文書、コード、表、会話履歴、ツール定義を含む実データを使う。入力と出力を別々に記録し、Sonnet 4.6との差を分布で確認する。

2. 9月以降の価格で予算を作る

導入価格は一時的な値である。年間予算、顧客への価格、利用上限、アラート閾値は標準価格を基準に設定する。8月中の請求額だけを根拠にしない。

3. 非互換パラメーターを削除する

SDKラッパー、共通HTTPクライアント、プロンプト管理基盤を含め、budget_tokensと非標準サンプリング値を検索する。モデル別の設定分岐を設け、Sonnet 5へ送らない。

4. 切り替え前に出力切れを確認する

同じ文章でもトークン数が増えるため、以前のmax_tokensでは途中で切れる可能性がある。長文生成、JSON、コード、レポート作成は、終了理由と構文完全性を自動検査する。

5. 提供経路を確認する

AWS、Google Cloud、Microsoft Foundryを経由する場合は、モデル名だけでなく、利用するAPI、リージョン、認証、課金主体を確認する。特にAWSでは旧経路と新経路を混同しない。

編集部分析

Claude Sonnet 5の最大の移行リスクは、能力差ではなく計測前提の崩れである。モデル単価が同じという説明だけを見れば、Sonnet 4.6からの置き換えは簡単に見える。しかし、新トークナイザーでトークン数が増え、9月に導入価格が終了し、複数のパラメーターが400エラーになる。

したがって、移行の承認条件はベンチマークの品質だけでは足りない。請求額、コンテキスト収容率、出力完了率、エラー率を同時に比較する必要がある。

また、100万トークンという上限は同じでも、1トークン当たりに収まる文字量が変わるため、実質的に処理できる文書量はSonnet 4.6と同じではない。長大な文書を上限近くまで投入するRAGやコード解析では、入力分割の再設計が必要になる可能性がある。

実務チェックリスト

  • [ ] Sonnet 5で入力トークン数を再計測した
  • [ ] 出力トークン数とmax_tokensを再評価した
  • [ ] 2026年9月以降の標準価格で予算を作成した
  • [ ] budget_tokensを削除した
  • [ ] 非標準のtemperature、top_p、top_kを削除した
  • [ ] 400エラーを検知する回帰試験を追加した
  • [ ] AWSの利用経路がSonnet 5対応か確認した
  • [ ] 長文出力の途中切れとJSON破損を検査した

一次情報