Sonnet 5から5.5へ更新すべき？互換性・費用・切り戻しの確認

Sonnet 5.5はSonnet 5アプリの更新候補ですが、モデル名だけを見て無検証で置き換えるものではありません。 公式のトークン単価は同じでも、受け付けるリクエスト項目、effortの動作、応答処理が変わりました。自分たちの合格条件を満たし、必要な仕事が改善したと確認してから更新しましょう。

本記事は、すでにSonnet 5を運用しているチームに向けた展開判断のガイドです。総合的なモデル順位は扱いません。9月28日のSonnet 5.5公開後、2026年9月29日に資料を確認しました。すべてのSonnet 5アプリが直ちに本番移行すべきだという主張ではありません。

引き継げるものと再確認するもの

出典：Sonnet 5.5モデルページ、変更点。トークナイザーが同じなら同じ入力テキストは一貫して分割されますが、両モデルが同じ数の出力トークンを生成するとは限りません。

更新で確かめたい仮説を一つ決める

新モデルを試す具体的な理由を書きます。たとえば「範囲を限定したバグ修正で、回帰テストの合格率を維持しながら再試行を減らす」や「文書の下書きで必須セクションの欠落を減らす」です。これらは検証する仮説であって、公開告知だけで確認済みの改善ではありません。

プロンプト、検索処理、ツール、モデルを同時に変えないようにします。良くなっても、どの変更が効いたのか分からなくなるためです。旧設定を残し、同じタスク群を比べましょう。Sonnet 5.5が受け付ける形式にするために項目変更が必要なら、それも新構成の一部として記録します。

実際の用途からタスクを選び、必要に応じて非公開情報を除きます。よくある依頼、難しい例、ユーザーに重要な失敗を含めてください。提供元の最良デモに似た例だけを作らないようにします。

性能より先に互換性を確認する

優先項目は対応thinkingモード、強制ツール選択、思考履歴、computer use、advisorの互換性です。Sonnet 5.5はthinking.type: disabledを受け付けません。文書化された思考を抑える代替は、high以下のbetween_toolsです。強制するtool_choice値も移行が必要です。

リクエスト例とプラットフォームごとの条件は400エラー移行ガイドを参照してください。ここでは対処手順全体を繰り返しません。成功レスポンスもチェックリストに含めます。HTTP 200でも進捗表示や期待したツール呼び出しが欠けることがあります。

通常テキスト、ツール呼び出し、思考ブロック、拒否をパーサーがどう扱うか検証します。会話途中のモデル切り替えでは、非互換ブロックの扱いを確認します。過去のメッセージを編集するなら紐付け動作を確認してください。1ターンの「こんにちは」への応答だけでは本番エージェントのループは検証できません。

品質と費用を一緒に測る

合格条件は固定します。開発なら対象テストと回帰テスト全体の成功、無関係な編集がないことなどです。抽出ならスキーマと値の正確性、文書なら必須項目と入力データに関するすべての主張を確認します。

リクエスト数、課金区分別使用量、合格出力までの時間、レビューの手間を記録してください。ストリーミングが速くてもタスク完了が速いとは限りません。同じ単価でも出力やツール往復が増えれば請求額は変わります。

Artificial Analysisの公開時レポートは試験内容を選ぶ参考になりますが、公開前環境の問題と再評価予定を明示しています。自分のアプリで測った更新効果として扱わず、外部結果と自社結果は別欄に残しましょう。

戻せる形で展開する

最初は隔離したテスト環境で新設定を実行します。合格したら、製品に合った承認済みの限定展開を選びます。正確なモデル、設定、公開時刻を記録し、その後のトラフィックを旧版と区別できるようにします。両方を黙って一つの性能集計に混ぜないでください。

切り戻し設定と発動条件を用意します。たとえば無効な応答が許容しきい値を超える、重要タスクが悪化するといった条件です。戻したからといってモデル全般が劣るという意味ではなく、自分の連携や用途に追加調査が必要な場合もあります。

新しいモデルの公開が旧版の即時終了を意味すると考え、旧モデルを削除しないでください。公式のライフサイクル方針は別に確認します。アクセスや廃止予定はサービスによって異なります。見出しが生む焦りではなく、実際の対応日程とプラットフォーム動作に基づいて移行しましょう。

連携の種類から移行に必要な確認を決める

最終テキストだけを読む単発アプリは、モデルを切り替え、署名付き思考履歴を保存し、ツール進捗を表示するエージェントより互換性の確認範囲が小さくなります。ID を変える前にアプリを分類すれば、必要なテストが分かります。ただし単純なアプリなら答えが同一になるという保証ではありません。

有効な JSON でも抽出の事実が正しいとは限りません。スキーマは invoice_total を必須にできますが、金額は原本と照合する必要があります。引数が正しいツール呼び出しでも、違うレコードを対象にすることがあります。互換性テストは実行可能性、タスクテストは成果の有用性を確認します。

プラットフォームも重要です。現在の移行文書では、Bedrock 上の Sonnet 5.5 は strict tool use を含む structured outputs 非対応とされています。旧 computer-use ツールの扱いもプラットフォームで異なります。一つのエンドポイントでの結果を別サービスの準備完了へ転記せず、モデルIDとエンドポイントの種類を一緒に記録します。

アプリに合う最小の回帰セットを用意する

新しい回答を生成する前にフィクスチャを作ります。通常要求、アプリ独自の上限近くの長い入力、意図的な情報不足、拒否または対象外の要求、ツール失敗、複数ターンの続行に加え、影響が最大だった過去の不具合を含めます。これは網羅性を考える出発点で、7件あれば本番安全性を証明できるという意味ではありません。

各ケースに必須動作と失敗条件を書きます。抽出なら金額、通貨、出典位置の一致を求め、欠落情報の創作を失敗とします。コードなら基準では回帰テストが失敗し、パッチ後に通り、受け入れテストを編集しないことを要求します。文書なら元資料の事実が指定章へ入り、架空の引用がないことを確認します。

パーサーのケースは元応答の構造とアプリの表示結果を保存します。適切なブロックからテキストを取り、thinking を最終回答として表示せず、進捗が空でも画面が停止したように見えないか確認します。Sonnet 5.5 はリクエスト成功のまま中間応答の形を変えるため、HTTP ステータスだけの正常性確認では見逃します。

ツールのケースでは意図的に1回エラーを返します。結果を正しくモデルへ返し、再試行上限を守り、最初の成否が不明な外部操作を繰り返さないことを確認します。破壊的操作はサンドボックスの代替を使います。本物の決済やメールを2回実行して確かめるためのテストではありません。

デフォルトを含む二つの設定を特定する

モデルID、エンドポイント、SDK・クライアント版、思考モード、effort、出力上限、システムプロンプトのハッシュ、ツールスキーマのハッシュ、検索版を残します。要求で省略した項目も、有効なデフォルトを記録します。Sonnet 5.5 の API は high、Claude Code は medium がデフォルトなので、同じモデル名でも開始条件は異なり得ます。

変更しない基準commitまたは設定版を保持します。新フィールドが必要なら、唯一の旧要求を上書きせず5.5用の設定を分けます。IDだけ戻して非互換の5.5フィールドを残すのは、信頼できるロールバックではありません。秘密情報は報告に入れず、ハッシュと非機密設定で識別します。

公式には Sonnet 5 と5.5の tokenizer と料金表は同じです。同一入力の比較には役立ちますが、出力長やツールループは未確定です。互換性上必要でなければ現在のプロンプトから始めます。後で調整した場合は別設定として保存し、改善をすべてモデル更新に帰属させません。

テストから段階公開の判断へ進める

互換性失敗、タスク失敗、運用障害を分けます。要求フィールドの拒否は互換性、正しい形式で誤った金額はタスク、タイムアウトや依存先停止は運用の問題です。どれも公開を止め得ますが、対処は違います。一つの「精度」にまとめると次に何を直すか不明になります。

仮の公開条件として、重要ケースは全件合格、外部作用の重複なし、通常タスクは既存の合格基準を満たし、費用と完了時間は事前予算内、と設定できます。これは普遍的な閾値ではありません。重要な部分集合は平均改善でも免除しない条件にします。数値は製品要件と既存測定から選び、新モデル発表から作らないでください。

20タスクで両版とも18件合格でも、同等とは限りません。旧版の失敗が低影響の原稿2件、新版が財務抽出と移行なら意味が違います。90%同士だけでなくIDと失敗の重大度を照合します。新たな失敗を調べ、曖昧な例を再実行し、小標本という制約を判断記録へ残します。

ロールバックは名前だけでなく動作を戻す

承認された限定公開では要求を記録済み設定へ割り当て、明示的にテストしていない限り進行中タスクの途中でモデルを変えません。ログで旧・新版を分けられるメタデータを保存します。読み取り専用の影評価は有用な場合がありますが、モデルを比較するために副作用のある操作を二重実行してはいけません。

条件に達したら新設定への新規投入を止め、動作確認済みのアダプターを復元し、進行中の作業は保存状態に応じて処理します。成否不明の外部操作は再試行前に照合します。機密を保護したうえで失敗応答と usage を診断用に残し、本番を戻したという理由で新版の記録を消さないでください。

最終記録には合格フィクスチャ、未解決事項、誰または何が受け入れ確認を行うか、戻す設定を明記します。権限で実行できない場合は「準備済み、未検証」です。文書確認とローカルの要求形式検証は有用ですが、実際の端から端までの移行成功と報告することはできません。

次の確認先

計算には料金記録表、設定試験にはeffort比較を使えます。大きなモデルへ移るべきかが問題なら、更新試験とモデル階層の変更を混ぜず、SonnetとOpusの比較を参照してください。