結論：先に答えると、5つの互換性をテストしてから切り替える
Claude Sonnet 5からClaude Sonnet 5.5へ移行する時は、モデルIDの変更を本番へ直接出さず、thinking、強制tool、thinking blocks、computer use、advisorの5つを固定fixtureで確認します。公式のSonnet 5.5は1M tokensのcontext、最大128K tokensの出力、入力$2・出力$10/MTokですが、既存コードが同じように動くとは限りません。移行の成否はレスポンスが返ることではなく、表示、tool実行、会話継続、監査ログまで期待どおりかで判定します。
根拠はClaude Sonnet 5.5公式モデルページと公式migration guideです。変更点の詳細はWhat's new in Claude Sonnet 5.5にもまとまっています。既存のinline toolsとMCPの運用ガイドは会話途中のtool追加が中心で、この記事はモデル移行時の互換性確認に絞ります。
Sonnet 5と5.5で変わる箇所を比較する
| 確認点 | Sonnet 5.5の公式条件 | 移行テスト |
|---|---|---|
| thinking | adaptiveが既定。前倒し思考を止める最低設定はbetween_tools | disabledを送る経路とeffortの組合せ |
| tool_choice | any・toolの強制tool useは非対応 | 400とfallbackの扱い |
| thinking blocks | モデルと会話に結び付く | streaming表示と会話継続 |
| computer use | API・Google Cloudではcomputer_20251124を受理しない | provider別tool選択 |
| advisor | Opus 4.8、Opus 4.7、Sonnet 5をadvisorにできない | advisor構成とエラー処理 |
変更を一つの「モデル更新」として扱うと、どの差分で壊れたか分からなくなります。5つのfixtureを分け、同じprompt、権限、provider、会話長で比較します。公開情報の「speed and intelligence」はモデルの位置づけであり、自社アプリの品質保証ではありません。画面の応答が速くても、toolの誤実行や表示欠落があれば移行を止めます。
移行前に行う8手順
- 依存経路を洗い出す。直接のMessages API、SDK、BedrockやGoogle Cloudのadapter、stream表示、tool routerを一覧にします。
- 現在の契約を保存する。Sonnet 5のmodel ID、thinking、effort、tool_choice、system、会話fixture、期待するイベント名を記録します。
- 新しいIDだけを別環境で試す。Claude APIでは
claude-sonnet-5-5を使い、providerごとのIDを混ぜません。 - thinking設定を検査する。
thinking: {"type":"disabled"}を送るコードを検索し、between_toolsへ切り替える条件を決めます。 - forced toolを試す。
tool_choiceのanyとtoolをfixtureへ入れ、400を利用者向けエラーに変換するか、通常のautoへ戻すかを決めます。 - streamを確認する。tool間の短い進捗がthinking blocksへ入る場合に、UIが無言にならないか、displayの扱いを確認します。
- provider固有toolを確認する。computer_20251124の利用箇所とadvisorの構成をAPI・Google Cloud・Bedrock等で分けます。
- 段階配布とrollbackを決める。tenant、利用者、作業種別を限定し、旧モデルへ戻す条件をエラー率だけでなく表示欠落と人手修正量でも定義します。
手順4では「thinkingを切れば同じ表示になる」と決めつけないでください。between_toolsは前倒し思考を止める最低設定ですが、tool間に返る要約文がthinking blocksになる仕様は残ります。表示を利用者へ見せるアプリは、ストリームのblock typeを捨てず、利用者向け表示と監査保存を分けて実装します。
テストケースとrollbackの判定表
| ケース | 合格条件 | 不合格時の判断 |
|---|---|---|
| 通常のtext応答 | 内容・usage・stop reasonが既存契約どおり | prompt差分とmodel差分を分離 |
| toolを1回呼ぶ | 入力、結果、次のtextがUIとログに出る | stream parserを修正し再試験 |
| forced tool | 対応しないことを検出して安全に案内 | autoまたは旧modelへ戻す |
| 会話を継続 | thinking blockのmodel・account条件が満たされる | 新規会話で再試験し混在を止める |
APIが200を返しただけでは合格にしません。利用者へ表示する進捗、toolの承認、コスト記録、エラーの再試行を同じfixtureで確認します。特にSDKの型定義が未知のblockを無視する実装だと、本文は返るのにtool間の表示だけが消えることがあります。ログにはmodel ID、provider、thinking設定、tool_choice、request IDを残し、原因を再現できるようにします。
企業導入で先に決めるチェックリスト
- Sonnet 5.5を使う業務と、旧モデルを残す業務を分けた。
- APIと各クラウドのmodel IDを台帳に記載した。
- disabled、between_tools、adaptiveの選択理由を記録した。
- forced tool useを使う呼び出しを全件検索した。
- thinking blocksをUIと監査ログで別々に扱った。
- computer useとadvisorの組合せをprovider別に検証した。
- 1M context・128K max output・料金を公開直前に公式readbackした。
- rollbackの期限、担当者、対象tenant、再試験条件を決めた。
よくある質問
モデルIDを変えるだけで移行できますか？
できません。リクエストが返る場合でも、forced tool、stream表示、thinking block、provider固有toolの契約が変わっています。
Sonnet 5.5のthinkingを完全に無効化できますか？
公式仕様ではdisabledではなく、条件に合う場合のbetween_toolsが前倒し思考を止める設定です。xhighやmax effortとの組合せ、会話途中のeffort変更も確認します。
既存会話をそのまま使えますか？
thinking blocksはモデルと会話に結び付くため、モデルやアカウントをまたぐ継続は別のfixtureで確認します。安全側では移行時に新しい会話を開始します。
公式情報と次の一歩
正式名称、ID、料金、制限は公式モデルページ、移行差分は公式migration guideを公開直前にも読み直します。全体のモデル選定はClaude最新モデルの選び方、APIの料金整理はClaude料金ガイドも参照してください。複数provider、UI、監査を同時に移行する場合は、Miraigentの無料診断でrollback条件から整理できます。