Claude Sonnet 5（claude-sonnet-5）で本番エージェント基盤を運用しているエンタープライズにとって、2026年9月28日公開の Claude Sonnet 5.5（claude-sonnet-5-5）はモデルIDの書き換えだけでは移行が終わらない。thinkingを止める手段が変わり、強制ツール使用が廃止され、thinking blockの持ち越し条件も変わる。同時期に公開されたClaude Opus 5.5とは異なり、Sonnet 5.5にはthinkingを最小構成まで落とすbetween_toolsという新しい選択肢がある。本稿ではこの差分を軸に、エンタープライズの移行観点から対応点を整理する。
thinkingを止める方法はどう変わったか
Sonnet 5.5では
thinking: {"type": "disabled"}が400エラーになり、代わりに最小構成のbetween_toolsを使う。
Claude Sonnet 5ではthinking: {"type": "disabled"}でthinkingを完全に止められた。Sonnet 5.5ではこの指定はinvalid_request_errorを返し、エラーメッセージは「最小構成にはthinking.type.between_toolsを、挙動制御にはthinking.type.adaptiveとoutput_config.effortを使うこと」を明示する。
between_toolsはSonnet 5.5だけが持つ選択肢で、Opus 5.5のように「thinkingを完全に無効化する手段が消えた」わけではない点が異なる。between_toolsはツールコール前の事前思考を止めつつ、ツールコール間の進捗更新は引き続きthinkingブロックとして返す。ツールを使わないリクエストではテキストのみが返る。ベータヘッダー不要で全プラットフォームから利用できるが、low〜highのeffortでのみ有効で、xhigh・maxでは400エラーになる。またリクエスト途中でeffortを変更することもできない。エージェントのレイテンシ最適化で「thinkingを切って軽くする」設計をしていた実装は、この置き換えが移行の中心になる。
forced tool useはどう置き換えるか
tool_choiceのany/tool指定はSonnet 5.5で廃止され、autoとstrict tool useの組み合わせが必須になる。
Sonnet 5.5はtool_choice: {"type": "any"}と{"type": "tool", "name": "..."}をどちらも400エラーで拒否する。token countingエンドポイントでも同じ検証が働くため、事前見積もりの段階で検出できる。
移行先は2系統ある。
- スキーマ準拠の出力が目的:
tool_choice: {"type": "auto"}を維持し、対象ツールにstrict: trueを設定する。1リクエストで指定できるstrict toolは最大20件で、MCP・computer use・browser useの各ツールセットエントリはstrictを受け付けない - 特定ツールを確実に呼ばせたい: プロンプト側に「この条件ではこのツールを使う」という指示を明示する設計に切り替える。モデルの判断に委ねる前提に変わるため、呼ばれなかった場合のフォールバックを合わせて設計する
Amazon Bedrock上ではStructured Outputs（strict tool useを含む）自体が未提供のため、autoのみを送り、ツール入力の検証をアプリケーション側で行う必要がある。
thinking blockはどこまで持ち越せるか
Sonnet 5.5のthinking blockはSonnet 5・Opus 4.8・Haiku 4.5以前のblockは読めるが、Opus 5系・Fable・Mythos系のblockは読めない。
Sonnet 5.5の各thinking blockは生成元モデルを記録し、会話履歴全体に対する署名も持つ。読めないモデルの組み合わせでリクエストすると、該当blockはAPI側で自動的に除外されて送信される（リクエスト自体は200で成功し、除外分は課金されない）。
もう一点、2026年8月31日00:00 UTC以降に作成されたアカウントでは、thinking blockより前のsystem・tools・過去メッセージが未変更であることをAPIが検証するようになった。変更を検知すると400エラーになるため、会話はappend-onlyに保ち、途中で指示やツールを変える場合はmid-conversation system messageを使う設計が前提になる。この検証は同時期に出たOpus 5.5にも共通する仕様で、モデルをまたいだマルチエージェント構成では両モデルとも同じ制約に従う。
computer useとadvisor toolの互換性はどう変わるか
Claude APIとGoogle Cloud上ではcomputer useの旧
computer_20251124が拒否され、advisor toolはSonnet 5を含む旧世代モデルを受け付けなくなる。
Claude APIとGoogle Cloud上では、Sonnet 5.5はcomputer useをcomputer_toolset_20260801でのみ受理し、旧computer_20251124は400エラーになる（Amazon Bedrock上では引き続き旧ツールが動作する）。fine-grained-tool-streaming-2025-05-14ベータヘッダーを送っている場合は外し、必要なツールにeager_input_streaming: trueを個別設定する。
advisor toolでは、Sonnet 5.5をexecutorにする場合、advisorにClaude Opus 5.5・Opus 5・Sonnet 5.5・Fable/Mythos系のいずれかを指定する必要がある。Opus 4.8・Opus 4.7・Opus 4.6・Sonnet 5・Sonnet 4.6をadvisorに指定すると400エラーになり、advisorの応答はadvisor_redacted_resultとして暗号化されて返る（本文は読めない）。複数モデルを役割分担させるAdvisorパターンを組んでいる場合、advisor側のモデル世代を合わせて更新する必要がある。
移行時に見落としやすい挙動変化
ツールコール間の進捗テキストがthinkingブロックに変わり、価格はSonnet 5から据え置きで変更なしと公式に確定した。
コード変更を要さないが挙動や前提が変わる点として、次の3点を移行チェックに含めるべきだ。
- 進捗テキストの格納先変更: 一文を超える長さのツールコール間テキストは、既定の
display: "omitted"では空フィールドのthinkingブロックとして返る。進捗をUIに表示している場合はdisplayを"updates"（ベータ）または"summarized"に設定する - 拒否カテゴリの追加: Sonnet 5.5はSonnet 5より広い範囲で
stop_reason: "refusal"を返すようになった。"cyber"・"bio"・"frontier_llm"・"reasoning_extraction"・"general_harms"のカテゴリがstop_detailsに入るため、リトライ・フォールバック設計にこの分岐を追加する - プロンプトキャッシュの最小長が512トークンに短縮: Sonnet 5・Sonnet 4.6の1,024トークンから引き下げられ、これまでキャッシュ対象外だった短いプロンプトもキャッシュできるようになった
価格面では、Sonnet 5.5は入力$2/M・出力$10/Mで、Sonnet 5と完全に同額のまま据え置かれている。Sonnet 5の$2/$10は当初「2026年8月31日までの導入価格」としてアナウンスされ、9月1日に$3/$15へ引き上げる予定だったが、Anthropicは公式にこの値上げを撤回し、$2/$10を恒久価格として確定させた。エンタープライズのAI FinOpsレート表を更新する際は、Sonnet 5.5への移行によるコスト変動要因が無いことを前提にできる。
参考
- Claude Sonnet 5.5 — Claude Platform Docs
- Migrating to Claude Sonnet 5.5 — Claude Platform Docs
- Pricing — Claude Platform Docs
まとめ
Claude Sonnet 5.5への移行は、thinking制御の置き換え・forced tool useの廃止・thinking blockの互換条件・computer useとadvisor toolのツール世代という4系統の破壊的変更に対応する必要がある。Opus 5.5と違い、Sonnet 5.5にはbetween_toolsという最小構成のthinking設定が残されている点が、レイテンシ重視のエージェント設計における実務上の分岐点になる。移行チェックリストとしては、(1) thinkingの無効化依存箇所をbetween_toolsかeffort制御に置き換え、(2) tool_choiceの強制指定をstrict tool useまたはプロンプト誘導に置き換え、(3) 会話をappend-onlyに保ちモデル間のthinking block互換性を洗い出し、(4) computer use・advisor toolの対応可否をデプロイ先ごとに確認する、の4点を順に潰す設計が現実的だ。価格据え置きが確定したことで、移行の意思決定からコスト変動要因を切り離して進められる。
大規模なモデル移行の設計・検証を伴走支援が必要な場合は、KuuのRDEサービスにお問い合わせいただきたい。