Claude Opus 5（claude-opus-5）で動く本番エージェント基盤を運用しているエンタープライズにとって、2026年9月22日公開の Claude Opus 5.5（claude-opus-5-5）はモデルIDを書き換えるだけでは済まない。thinking制御・forced tool use・thinking blockのモデル間互換性・computer useツールの4点で、既存コードがそのままでは400エラーを返す破壊的変更が入っている。本稿ではエンタープライズの移行観点から、各変更の技術的な原因と対応策を整理する。
thinkingは無効化できなくなったのか
Claude Opus 5.5ではthinkingパラメータの
disabled指定が400エラーを返す。effortパラメータでの制御に一本化された。
Claude Opus 5ではthinking: {"type": "disabled"}や手動バジェット指定のenabledが受理されたが、Opus 5.5ではthinkingは常時オンになった。この2つの指定はいずれもinvalid_request_error（400）を返し、エラーメッセージは「thinking.type.adaptiveとoutput_config.effortを使うこと」を明示する。
対応は次の2点に分かれる。
- thinkingフィールドを省略、または
{"type": "adaptive"}を明示する: これがデフォルト相当の動作になる - 推論の深さ・コスト・レイテンシは
effortパラメータで制御する: 従来「thinking無効化」で得ていた低コスト・低レイテンシはeffortをlowないしmediumに下げることで再現する
もう一点、Opus 5.5では応答の先頭に空のthinkingブロック（display: "omitted"時）が含まれ得るため、コンテンツブロックを位置ではなくtypeフィールドで判定するようにコードを変更する必要がある。すでにthinkingを有効化した状態でOpus 5を使っていた実装は、この変更の影響を受けない。
forced tool useは何に置き換えるべきか
tool_choiceのany/tool指定は廃止され、autoとstrict tool useの組み合わせに置き換える必要がある。
Opus 5.5はtool_choice: {"type": "any"}と{"type": "tool", "name": "..."}をサポートしない。いずれも400エラーになり、token countingエンドポイントでも同じ検証が働く。
移行先は2パターンある。
- スキーマ準拠のJSON出力が目的:
tool_choice: {"type": "auto"}を維持したままstrict: true（strict tool use）を設定する。あるいはStructured Outputsにスキーマを移す - 特定ツールを確実に呼ばせたい: プロンプト側で「このツールが適用される場面」を明示する指示に置き換える。tool_choiceによる強制ではなく、モデルの判断に委ねる設計に変わる
エンタープライズのオーケストレーション層で「必ずこのツールを呼ぶ」という前提でリトライ・フォールバックを組んでいる場合、この前提が崩れる点をテスト計画に含める必要がある。
thinking blockはどのモデルまで持ち越せるか
thinking blockは生成元モデルに紐付き、Opus 5.5はOpus 5以前のモデルのblockは読めるがFableやMythos系のblockは読めない。
Opus 5.5の各thinking blockは生成したモデルを記録する。Opus 5.5はOpus 5以前のOpus/Sonnet/Haikuモデルが生成したblockを読めるが、Claude FableやClaude Mythos系のblockは読めない。逆にClaude API上ではFable 5.1とMythos 5.1がOpus 5.5のblockを読める（他のモデルは読めない）。
これは具体的に次のような制約になる。
- Opus 5からOpus 5.5への会話の引き継ぎ、あるいはOpus 5.5からFable 5.1/Mythos 5.1への引き継ぎは、それまでの推論を保持したまま継続できる
- それ以外のモデル間切り替えでは、切り替え後のターンは前モデルの推論なしで進む
- 読めないblockを含むリクエストはAPI側で自動的に該当blockを除外して送信され、リクエスト自体は成功する（除外されたblockは課金対象外）。
thinking-binding-controls-2026-08-01ベータヘッダーを付けると、除外の発生がinput_transformationsに記録される
さらに、2026年8月31日00:00 UTC以降に作成されたアカウントでは、thinking blockより前のsystemプロンプト・tools・過去メッセージが変更されていないかをAPIが検証する。変更を検知するとリクエストは400エラーになるため、会話をappend-onlyに保つ設計が前提になる。会話の途中で指示やツールを変える場合は、既存メッセージの編集ではなくmid-conversation system messageを使う。
computer use実装はそのまま動くのか
Claude APIとGoogle Cloud上では旧
computer_20251124ツールが拒否され、computer_toolset_20260801への移行が必須になる。
Opus 5はcomputer_toolset_20260801（新ツールセット）と、ベータヘッダー付きの旧computer_20251124の両方を受理していた。Opus 5.5では、Claude APIとGoogle Cloud上に限り旧ツールが拒否される（400エラー）。
移行手順は3点。
- ベータヘッダー（
computer-use-2025-11-24）を外す toolsエントリを{"type": "computer_toolset_20260801"}に置き換える- エージェントループをメンバー単位の
tool_useブロック・バッチアクション・結果のtoolset_nameに対応させる
Amazon Bedrock上では旧ツールが引き続き動作するため、対応の優先度はデプロイ先ごとに異なる。すでに新ツールセットまたはbrowser useツールに移行済みの実装は変更不要だ。
移行時に見落としやすい挙動変化
effortの既定値がOpus 5の
highからOpus 5.5ではmediumに下がり、同じリクエストでもレイテンシとコストが変わる。
コード変更を要さないが数値が変わる挙動として、次の3点をリグレッションテストの対象に含めるべきだ。
- effortの既定値変化:
effortを省略した場合、Opus 5ではhigh相当、Opus 5.5ではmediumが既定になる。既定値に依存していたレイテンシ・コスト計測は再計測が必要 - 同一effortでの思考トークン増加: 特に
xhigh・maxでは、同じeffort設定でもOpus 5より思考トークンが増える傾向がある。max_tokensに思考分の余裕を確保する - ツールコール間のテキストがthinkingブロックに変わる: これまで
textブロックとしてユーザーに進捗表示していた内容が、display: "omitted"の既定設定ではthinkingブロックの空フィールドとして返る。進捗をUIに表示している場合はthinking.displayの設定変更が必要
料金面では、Opus 5.5は入力$4/M・出力$20/M（Opus 5の$5/$25から低下）、キャッシュ読み取りは入力価格の0.05倍の$0.20/M、バッチ処理は$2/$10と、コスト構造そのものも変わる。AI FinOps基盤のレート表・アラート閾値を更新しておく。
参考
- What's new in Claude Opus 5.5 — Claude Platform Docs
- Pricing — Claude Platform Docs
- Preserved thinking — Claude Platform Docs
まとめ
Claude Opus 5.5への移行は、モデルIDの書き換えだけで完了しない。thinkingの無効化不可・forced tool useの廃止・thinking blockのモデル間互換性・computer useツールの世代交代という4つの破壊的変更が、既存の本番エージェント実装に直接影響する。エンタープライズの移行チェックリストとしては、(1) thinking関連パラメータをeffort制御に置き換え、(2) tool_choiceの強制指定をstrict tool useまたはプロンプト誘導に置き換え、(3) 会話をappend-onlyに保ちモデル切り替え境界を洗い出し、(4) computer use実装のデプロイ先ごとの対応可否を確認する、の4点を順に潰していく設計が現実的だ。
大規模なモデル移行の設計・検証を伴走支援が必要な場合は、KuuのRDEサービスにお問い合わせいただきたい。