Claude Sonnet 4.5 が 2026-11-30 に退役 — 後継の公開2日後に期限が切られた

要約

Anthropic は 2026-09-30、Claude Sonnet 4.5（claude-sonnet-4-5-20250929）の非推奨化を Claude Platform の API リリースノートで告知しました。退役日は 2026-11-30。本記事公開時点で、残りは約2か月です。

この告知の並びに注目する価値があります。

移行先の Claude Sonnet 5.5 は、2026-09-28 に公開されました。 つまり、後継モデルの公開から2日後に、前世代の退役日が確定したことになります。Sonnet 5.5 は Claude API、Amazon Bedrock、Claude Platform on AWS、Google Cloud、Microsoft Foundry で提供されており、提供経路が揃った時点で期限を切ったという形です。

約2か月という猶予は、Anthropic のモデル退役としては標準的な長さです。 ただし、この移行はモデル ID を差し替えるだけでは終わりません。 Sonnet 5.5 側に、2026-09-28 のリリースノートで告知された破壊的変更が5点あります。

1. 拡張思考の制御方法が変わった。 high 以下の effort では、thinking: {"type": "disabled"} ではなく thinking: {"type": "between_tools"} を使います。

2. 強制ツール利用が 400 エラーを返す。 tool_choice の any と tool が使えなくなりました。これが今回の移行で最も重い変更です（後述）。

3. thinking ブロックがモデルと会話に紐づく。 以前のように、ある会話で得た thinking ブロックを別の文脈へ持ち回ることができません。

4. 旧 computer use ツールが拒否される。 computer_20251124 は、Claude API と Google Cloud では受け付けられません。

5. Advisor ツールの制限。 Claude Opus 4.8 / 4.7 / Sonnet 5 を advisor として指定すると拒否されます。

さらに、thinking ブロックの扱いにアカウント境界が入りました。 Sonnet 5.5 が生成した thinking ブロックは、生成元のアカウントまたは連携アカウントでのみ有効です。他のアカウントへ渡した場合、API がモデルへ渡す前にブロックを破棄し、リクエスト自体は成功します。 旧モデルが生成したブロックは影響を受けません。

この「リクエストは成功する」という挙動が、移行時の落とし穴になりえます。 エラーが出ないため、thinking ブロックが落ちていることに気づかないまま、品質だけが変わるという状態が起こります。マルチテナント構成や、複数アカウントをまたいで会話履歴を保存している実装では、確認が必要です。

最も影響が大きいのは、2番目の tool_choice の変更です。

tool_choice: {"type": "any"} は「必ずいずれかのツールを呼べ」、{"type": "tool", "name": "..."} は「必ずこのツールを呼べ」という指定です。これは、モデルの出力形式を確定させたいときの定番の手段でした。 構造化データを確実に得たい、フォーム入力を必ず埋めさせたい、分類結果をツール呼び出しの形で受け取りたい——こうした用途で広く使われてきました。

これが 400 エラーを返すようになったということは、実装の設計を変える必要があるという意味です。 リトライやエラーハンドリングで吸収できる変更ではありません。「必ずツールを呼ぶ」という前提に依存しているコードは、別の方法で同じ保証を得る必要があります。

何が変わったか

• claude-sonnet-4-5-20250929 が非推奨化（2026-09-30 告知）
• 退役日: 2026-11-30
• 移行先: Claude Sonnet 5.5（2026-09-28 公開。Claude API / Amazon Bedrock / Claude Platform on AWS / Google Cloud / Microsoft Foundry）
• Sonnet 5.5 の破壊的変更5点:
  1. high 以下の effort では thinking: {"type": "disabled"} ではなく {"type": "between_tools"} を使う
  2. 強制ツール利用（tool_choice の any / tool）が 400 エラーを返す
  3. thinking ブロックがモデルと会話に紐づく
  4. 旧 computer_20251124 の computer use ツールは Claude API と Google Cloud では受け付けられない
  5. Advisor ツールが Claude Opus 4.8 / 4.7 / Sonnet 5 を advisor として拒否
• thinking ブロックのアカウント境界: Sonnet 5.5 の thinking ブロックは生成元アカウント（または連携アカウント）でのみ有効。他アカウントではブロックが破棄されるがリクエストは成功する
• 旧モデルが生成した thinking ブロックは影響を受けない
• 専用の移行ガイドが公開されている

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

最初にやることは、grep です。

claude-sonnet-4-5-20250929 という文字列を、コード、設定ファイル、環境変数、インフラ定義、ドキュメントの全体で検索してください。 モデル ID は散りやすい値です。アプリケーションコードだけを見て完了にすると、バッチ処理や管理画面、検証用スクリプトに残ります。

特に見落としやすい場所を挙げます。 CI の設定ファイル、Terraform / CloudFormation などのインフラ定義、Lambda や Cloud Functions の環境変数、社内 Wiki のサンプルコード、Notion などに貼られた手順書。最後の2つは動作には影響しませんが、2026-12 以降に誰かがそれを見てコードを書くと、動かないものを作ります。

次に、tool_choice の使用箇所を特定してください。これが本番の移行作業の中心です。

tool_choice に any または tool を指定している箇所を全部洗い出します。 そのうえで、それぞれについて「なぜ強制していたのか」を確認してください。目的はたいてい次のどれかです。

(1) 構造化出力を確実に得たい。 JSON 形式の結果を必ず得たいためにツール呼び出しを強制していた場合、構造化出力の機能や JSON スキーマ指定へ置き換えるのが素直です。

(2) 分類・判定を必ずさせたい。 「このメールは問い合わせか苦情か」をツール呼び出しで受け取っていた場合、プロンプト側で出力形式を指定し、パース失敗時のリトライを用意する構成へ変えることになります。確実性は下がるため、どの程度の失敗率を許容できるかを先に決める必要があります。

(3) 外部システムの呼び出しを保証したい。 必ず検索を実行させる、必ず DB を引かせる、といった場合、モデルに判断させずにアプリケーション側で先に実行してから結果を渡す構成への変更が、多くの場合は正解です。そもそもモデルに任せる必要がなかった処理である可能性があります。

この3番目のケースが、移行をきっかけに設計を見直す価値がある部分です。 「必ずツールを呼べ」と指定していた処理は、本質的にモデルの判断を必要としていなかったことが少なくありません。アプリケーション側のコードで確定的に実行すれば、モデル呼び出しの回数もコストも減ります。

検証の進め方。 移行は、本番トラフィックの一部を Sonnet 5.5 へ流して比較する形が安全です。約2か月あるため、1〜2週間の並行稼働は確保できます。

比較すべき項目は3つです。 (1) 出力品質 — 同じ入力に対する結果の差。(2) レイテンシ — Sonnet 5.5 は公式が「Sonnet 5 比で30%高速」と説明していますが、自社のワークロードで確認する価値があります。(3) コスト — 「ほとんどの作業で最大30%安い」とされていますが、thinking の挙動が変わるため、トークン消費量が想定と違う可能性があります。

thinking ブロックのアカウント境界は、特定の構成だけで問題になります。 マルチテナントで会話履歴を共有している場合、複数の API キー / 組織をまたいで履歴を保存している場合、会話履歴をエクスポートして別環境へ持ち込んでいる場合。該当する場合、エラーが出ないまま品質が変わるため、ログで thinking ブロックの有無を確認する仕組みが必要です。

スケジュールの目安を書きます。 10月中に grep と tool_choice の洗い出しを終える。 11月第1〜2週で並行稼働と比較。11月第3週までに切り替えを完了し、最後の1週間を予備に残す。 2026-11-30 当日を切り替え日にするのは避けてください。退役日は、たいてい予定より静かに訪れますが、問題が出たときに逃げ場がありません。

副業・個人活用視点

個人開発や小規模な受託で Claude API を使っている場合、作業量そのものは小さいはずです。 モデル ID の箇所が少なく、tool_choice を使っていなければ、文字列の置き換えで終わります。

むしろ重要なのは、この種の告知に気づく仕組みを持っているかどうかです。

モデルの退役は、予告されます。 今回も2か月前に告知が出ています。それでも事故になるのは、告知を見ていないからです。 API リリースノートを定期的に確認する習慣がなければ、2026-12-01 に「突然 API が動かなくなった」という形で知ることになります。

受託案件で納品したシステムがある場合、これは信用の問題になります。

納品先のシステムが退役で止まったとき、連絡が来るのは作った人です。 保守契約がなければ、無償で対応するか、断って関係を悪くするかの選択になります。どちらも損です。

ここに、提案できるものがあります。 「モデル退役の監視と対応」を小さな保守契約として明示的に切り出すことです。月額は小さくて構いません。重要なのは、退役が起きたときに誰が対応するかを先に決めておくことです。 この契約があれば、告知を見たときに「対応します」と連絡でき、それ自体が信用になります。

提案の根拠として、今回の事例はそのまま使えます。 「Sonnet 4.5 が 2026-11-30 に退役します。御社のシステムは claude-sonnet-4-5-20250929 を使っています。対応が必要です」——具体的で、期限があり、放置した結果が明確です。 この種の連絡を一度でも入れておくと、次の案件につながります。

技術的な学びとしては、tool_choice の廃止が示していることに注目する価値があります。

「モデルに必ず特定の動作をさせる」という指定が、モデル世代の更新で消えました。 これは偶然ではありません。強制ツール利用は、モデルの判断を上書きする仕組みです。 モデル側の推論能力が上がると、「判断を上書きする」こと自体が品質を落とす方向へ働きます。

ここから引き出せる設計原則は、こうです。モデルに判断させたい処理と、確定的に実行したい処理を混ぜない。

確定的に実行したい処理は、アプリケーションのコードで書く。モデルの出力形式を確実に固定したいなら、構造化出力の仕組みを使う。「モデルに頼みつつ、必ず従わせる」という中間の設計は、モデル側の仕様変更で壊れやすいということが、今回の変更で実証されました。

この原則は、Claude に限りません。 OpenAI の function calling、Gemini の tool use でも、同じ性質の仕様変更は起こります。中間の設計を避けておくと、移行コストが構造的に下がります。 個人で作るものは保守する人も自分なので、この差は積み上がります。

最後に、現実的な注意を1つ。 今回の破壊的変更は 2026-09-28 の Sonnet 5.5 公開時に告知されていました。 退役告知（09-30）だけを読んで ID を置き換えると、tool_choice の 400 エラーで初めて気づきます。 退役告知を見たら、移行先モデルのリリースノートも必ず読んでください。 退役の告知と、移行先の破壊的変更は、別の日に別の場所へ出ます。