Claude Sonnet 5.5 公開。Terminal-Bench で Opus 5.5 を上回り、API には破壊的変更が4点入る

要約

Anthropic が2026年9月28日、Claude Sonnet 5.5（claude-sonnet-5-5）を公開しました。9月22日の Opus 5.5 に続く、Claude 5.5 ファミリーの2番目のモデルです。

役割分担が公式に整理されました。 Opus 5.5 は「慎重な判断を要する複雑な仕事」、Sonnet 5.5 は「範囲の決まった日常業務、バグ修正、体裁の整った文書・スライド・スプレッドシートの作成」。Anthropic は Sonnet 5.5 を「Opus 5.5 の、より速く安価な補完物」と位置づけています。

価格は入力 $2 / 出力 $10 per MTok です。 キャッシュ読み出しが $0.20、キャッシュ書き込みが $2.50。Opus 5.5（$4 / $20、キャッシュ書き込み $5）のちょうど半額という関係になっています。プロンプトキャッシュで最大90%、バッチ処理で50%の削減が可能とされます。出力生成は Sonnet 5 比で30%以上高速、1タスクあたりのコストは最大30%減。 単価だけでなく、1タスクに必要なトークン数自体が減ったという説明です。

注目すべきはベンチマークの逆転です。 エージェント型コーディングの Terminal-Bench 4.0 で Sonnet 5.5 は 70.6%。Sonnet 5 は 10.3%、そして Opus 5.5 は 66.4% です。上位モデルであるはずの Opus 5.5 を、この項目に限っては Sonnet 5.5 が上回っています。

ただし全項目で勝っているわけではありません。FrontierCode 1.1（High Effort）は Sonnet 5.5 が 46.2%、Opus 5.5 が 54.4%。CursorBench 4.0 は 55.5% 対 57.8%、OSWorld 2.1 は 80.1% 対 81.8%、知識労働の GDPval-AA v2.1 は 1844 対 1846 でほぼ並びます。「難しい判断は Opus、手数の多い実行は Sonnet」という切り分けが、数字の上でも裏づけられた格好です。 なお Sonnet 5 からの伸びは全項目で大きく、OSWorld は 57.0% → 80.1%、CursorBench は 34.1% → 55.5% です。スクリーンショットだけでポケモン赤をクリアした初の Sonnet でもあります。

提供先は Claude API、Amazon Bedrock、Claude Platform on AWS、Google Cloud、Microsoft Foundry です。 Claude Code は同日リリースの v2.1.284 で、既定の Sonnet モデルとして取り込んでいます。Claude Haiku 5.5 は「数週間のうちに」追加予定とされています。

そして、ここからが実務上いちばん重いところです。 Claude Platform のリリースノートには破壊的変更が4点明記されています。モデル ID を差し替えるだけでは動きません。

何が変わったか

• claude-sonnet-5-5 を公開。Claude API / Amazon Bedrock / Claude Platform on AWS / Google Cloud / Microsoft Foundry で提供
• 価格は入力 $2 / 出力 $10 per MTok、キャッシュ読み出し $0.20、キャッシュ書き込み $2.50（Opus 5.5 の半額）
• 出力生成が Sonnet 5 比で30%以上高速、1タスクあたりコストは最大30%減
• Terminal-Bench 4.0 で 70.6%（Sonnet 5: 10.3%、Opus 5.5: 66.4%）
• OSWorld 2.1 は 80.1%、CursorBench 4.0 は 55.5%、GDPval-AA v2.1 は 1844
• FrontierCode 1.1（High Effort）は 46.2% で、Opus 5.5 の 54.4% には及ばない
• 破壊的変更1: 強制ツール利用（tool_choice: "any" / "tool"）が 400 エラーになる
• 破壊的変更2: high 以下の effort で前段の thinking を切るには thinking: {"type": "between_tools"} を使う。"disabled" は不可
• 破壊的変更3: 旧 computer_20251124 ツールは Claude API と Google Cloud で拒否（Bedrock では継続動作）
• 破壊的変更4: Advisor ツールが Opus 4.8 / 4.7 / Sonnet 5 を advisor として拒否
• thinking ブロックがアカウントに紐づく。別アカウントのリクエストでは推論前に破棄される
• Claude Code v2.1.284 が既定の Sonnet として採用
• Claude Haiku 5.5 は数週間のうちに追加予定

業務インパクト（一般企業向け）

最初にやるべきは、移行作業の見積もりです。 「安くて速い新型が出た」で終わる話ではありません。tool_choice: "any" や tool_choice: {"type": "tool", ...} を使っているコードは、Sonnet 5.5 に向けた瞬間に 400 エラーで落ちます。 構造化された出力を確実に取るために強制ツール利用を入れている実装は珍しくなく、むしろ真面目に作ったシステムほど該当します。

thinking: {"type": "disabled"} も同様です。 レイテンシを抑えるために推論を切っている実装は、between_tools へ書き換える必要があります。コスト削減のために thinking を切っていた組織が、移行時にいちばん引っかかる箇所です。

computer use を使っている場合は、プロバイダーによって挙動が割れます。 旧 computer_20251124 は Claude API と Google Cloud では拒否されますが、Bedrock では動き続けます。 マルチクラウドで冗長化している構成だと、同じコードが Bedrock では通り Claude API では落ちるという、最も切り分けにくい形の障害になります。移行時はプロバイダーごとに検証してください。

thinking ブロックのアカウント紐づけは、見落とされやすい変更です。 あるアカウントで生成した thinking ブロックを、別アカウントのリクエストに載せても推論前に破棄されます。会話履歴をアカウントをまたいで引き回す設計（共有ワークスペース、マルチテナントの SaaS、社内の共通プロキシ）を採っている場合は、期待した継続性が得られません。

モデル選定の前提も更新が必要です。 これまでの「Opus が上位、Sonnet が廉価版」という理解は、エージェント型コーディングに関しては成り立ちません。 Terminal-Bench で Sonnet 5.5 が Opus 5.5 を上回っている以上、CI で走らせる自動修正や、定型的なコード変更のパイプラインは、半額の Sonnet 5.5 のほうが速くて強い可能性があります。 一方 FrontierCode のような難度の高い設計判断では Opus 5.5 が上です。「上位モデルを使えば安全」という運用は、この世代からコストの無駄になります。

社内ガイドラインを持っている組織は、モデル一覧と推奨の書き換えが必要です。 9月22日の Opus 5.5、9月28日の Sonnet 5.5 と1週間で2つ動いており、Haiku 5.5 も控えています。 個別に追うより、「モデル名と価格を本文に直書きしない」という書き方へ変えるほうが、長期的には安くつきます。

副業・個人活用視点

単価が下がったことより、1タスクあたりのコストが下がったことのほうが効きます。 入力 $2 / 出力 $10 は Sonnet 5 と同水準ですが、**必要トークン数が減り、生成が30%以上速くなった結果として「最大30%安い」**という説明です。同じ予算で試行回数を増やせるという意味になります。

受託でコード自動化を組んでいるなら、モデル構成を見直す価値があります。 エージェント型コーディングで Opus 5.5 を上回るスコアを、半額で出しています。Opus を既定にして走らせているパイプラインは、Sonnet 5.5 に切り替えるだけで費用が半分になり、しかも速くなる可能性があります。 ただし FrontierCode 系の難しい設計判断では Opus が上なので、「難所だけ Opus、残りは Sonnet」という2段構成が現実的な最適解になりそうです。実際に自分のタスクで並べて測ってから決めてください。

文書・スライド・スプレッドシート作成が明示的に強みとして挙げられている点は、コード以外の受託にとって意味があります。資料作成の代行、議事録の整形、提案書のたたき台。**「範囲の決まった仕事を、体裁よく、速く、安く」**というのが公式の位置づけです。

個人で API を叩いている場合、移行の手間は小さくありません。 強制ツール利用と thinking 無効化は、個人開発でこそ「とりあえず確実に JSON を返させる」「レスポンスを速くする」ために入れがちな設定です。切り替え前に、自分のコードを tool_choice と thinking で grep してください。動かしてから気づくと、原因の特定に時間を取られます。

Haiku 5.5 が数週間後に来ます。 大量処理・低単価の用途を組んでいるなら、いま Sonnet 5.5 で作り込むより、Haiku 5.5 を待ってから測り直したほうがいい場面があります。 今回の Sonnet 5.5 の伸び幅を見る限り、Haiku 側の更新も小さくない可能性があります。