Claude Opus 5.5 APIガイド：モデルID、4つの破壊的変更、そして黙された5つ目

モデル文字列を claude-opus-5 から claude-opus-5-5 に変えても、コードはコンパイルも通り、型チェックも通り、テストスイートらしきものも従来どおり通ります。そして本番環境で 400 を返します。Claude Opus 5 が受け付けていた 4 つのリクエスト形状は Claude Opus 5.5 によって即座に拒否され、5 つ目の変更は何も壊しません――まさにそれが、ユーザーのもとに届くものになる理由です。本記事はこのモデルの統合リファレンスです。識別子、それを提供するサーフェス、リクエスト契約、4 つのエラー、静かなる 5 つ目、そして effort パラメータが現在どのように機能するか。挙動が Claude Fable 5.1 と一致する箇所については、すでにそこへ移行済みのチームは作業の一部を終えているので、以下の各変更では、そのモデルにも当てはまるかどうかを示します。

ここにあるものはすべて、2026-09-24時点のAnthropic自身のClaudeドキュメントから読み取ったものであり、モデルの出荷から2日後のことです。ベンダーの主張はベンダーの主張として、独立した数値は独立したものとしてラベル付けされ、両者が比較可能であるかのように同じエフォート設定で提示されることは決してありません。

モデルID、およびそれが提供される場所

識別子はclaude-opus-5-5です。日付サフィックスのない固定モデルIDで、claude-opus-5と同じ方式です。採用すべき別個の固定スナップショット形式は存在せず、別の何かに解決されるエイリアスもありません。

Anthropicのモデル概要には、以下の正確な文字列とともに5つのサーフェスが一覧表示されています：

• Claude API — claude-opus-5-5、すべてのお客様がご利用いただけます。

• Amazon Bedrock — anthropic.claude-opus-5-5（ベンダー名を接頭辞として付ける唯一のサーフェス）。

• AWS上のClaude Platform — claude-opus-5-5、Bedrock形式のIDではなくClaude APIのIDを使用します。

• Google Cloud — claude-opus-5-5.

• Microsoft Foundry — claude-opus-5-5。送信するのはデプロイ名であり、Foundry は Claude API のライフサイクルスケジュールに従います。

その5つのうち2つは、このセクションの残りの内容よりも重要です。Amazon Bedrock と Google Cloud は独自のライフサイクルと廃止日を設定しており、以下の破壊的変更が示すように、Bedrock は旧式のコンピューター使用ツールが今でも動作する唯一のプラットフォームでもあります。Bedrock を使っているなら、他のみんなと同じ移行をしているわけではありません。

現在、すべてのリクエストが満たさなければならないもの

Anthropicの移行ガイドは、契約をリストとして示しており、そのリストは自分のクライアントを照合するのに十分なほど短い。どのモデルから移行する場合でも、claude-opus-5-5 へのリクエストは次の条件を満たす必要があります：

• thinking フィールドを送信しないか、thinking: {"type": "adaptive"} を送信してください — アダプティブ思考は常に有効であるため、この2つは同等です。

• 思考の深さを effortで制御します。これがそれを可能にする唯一のリクエストパラメータです。5段階すべてに対応しており、デフォルトは「medium」です。

• tool_choice に {"type": "auto"}（デフォルト）または {"type": "none"} を使用します。ツールの強制は拒否されます。

• 省略：temperature、top_p、top_k、またはデフォルト値のままにしてください。それ以外の値は、このモデルでも Claude Opus 4.7 以降のすべてと同様に拒否されます。

• messagesを事前入力済みのアシスタントターンで終了しないこと。これはOpus 4.6以降ですでに拒否されています。

• コンピュータ使用を computer_toolset_20260801 ツールセットとして Claude API と Google Cloud で宣言する。

• コンテキストウィンドウのベータヘッダーは送信しないでください。1M のコンテキストウィンドウがデフォルトであり、古いモデル向けに書かれたヘッダーには効果がありません。

ガイドで設定が拒否されるとされている箇所では、APIはHTTP 400を返します。これがこのモデルへ移行する際の失敗の全容です。出力が劣化するのでも、ログに警告が出るのでもなく、リクエストは決して実行されません。

4つの破壊的変更

1. 思考を無効にすることはできません

アダプティブ思考は常に有効です。thinking: {"type": "disabled"}は 400 を返し、手動で予算を指定した場合も同様です — thinking: {"type": "enabled", "budget_tokens": N}。エラーテキストには、送信した type が示され、続いて置き換え先の type が示されます:

• 「thinking.type.disabled」はこのモデルではサポートされていません。thinking の動作を制御するには、「thinking.type.adaptive」と「output_config.effort」を使用してください。

• このモデルでは「thinking.type.enabled」はサポートされていません。思考動作を制御するには「thinking.type.adaptive」と「output_config.effort」を使用してください。

実際の帰結はそのエラーそのものではなく、それを修正した後に何が起きるかにある。Claude Opus 4.8 以前では、thinking フィールドのないリクエストは thinking なしで実行された。Claude Opus 5.5 ではすべてのリクエストが thinking を行い、max_tokens は thinking と応答テキストの両方を対象とする厳格な上限のままである。thinking トークンは、thinking のテキストがあなたに返されない場合でも、出力トークンとして課金される。したがって、以前は thinking なしで実行されていたエンドポイントは、「修正」後には 1 リクエストあたり以前よりも多くの出力トークンを生成しうる。Anthropic の指針は、以前 thinking を無効化していた箇所では effort を下げること、そして xhigh または max effort では max_tokens を 64k から始めてそこから調整することである。

レスポンスの形状も変わります。レスポンスは最初のテキストブロックの前に1つ以上のthinkingブロックで始まることがあるため、位置で返信を読み取るコード — content[0].text、あるいは最初のcontent_block_startをテキストとして扱うストリームハンドラー — は、リクエストが成功した場合でもこうしたレスポンスでは壊れます。代わりにtypeフィールドでブロックを選択してください。

2. 強制的なツール使用はエラーを返す

tool_choice の型 any と tool は 400 を返し、同じ検証がトークンカウントのエンドポイントにも適用されるため、事前カウントは実際の呼び出しと同じように失敗します:

• tool_choice: タイプ "tool" および "any" はこのモデルではサポートされていません。

Auto と none は影響を受けません。文書化されている代替手段は、tool_choice: {"type": "auto"}を維持し、strict: trueでツールをマークしてスキーマに有効な引数を得るか、スキーマを構造化出力へ移すこと、そして auto は呼び出しを保証しないためツールがいつ適用されるかをプロンプトで明示することです。strict なツール使用は JSON Schema のサブセットのみを受け付けます。ツールの input_schema 内のすべてのオブジェクトはadditionalProperties: falseを設定する必要があるため、フラグを切り替える前に各スキーマを確認してください。そして、これが残す隙間に注意してください。呼び出しを単に許可するのではなく強制することにコードが依存していた場合、auto は許可を復元しますが保証は復元しません。tool_use ブロックが実際に返ってきたことを確認してください。

3. 思考ブロックはモデルと会話に紐付けられています

すべての思考ブロックは、それを生成したモデルを記録しており、各モデルは自身のブロックに加えて、定義された他者のブロック群を読む。ルールは双方向に機能する：

Claude Opus 5.5 は Claude Opus 5 およびそれ以前の Opus、Sonnet、Haiku モデルの thinking ブロックを読み取りますが、Claude Fable や Claude Mythos モデルのものは読み取りません。

• Claude APIでは、Claude Fable 5.1とClaude Mythos 5.1がClaude Opus 5.5のブロックを読み取ります。他のモデルはこれを読み取りません。

• 会話がClaude Opus 5.5からそれら2つ以外の何かに移ると、以降のターンは以前の推論なしで実行されます。

会話を移動させるルーターやフォールバックは、これに該当する明白な方法だ。より気づきにくい側面は、そのブロックが会話のプレフィックス——システムプロンプト、ツール、そしてその前にあるすべてのメッセージ——にも結び付いていることだ。Anthropic は、2026-08-31 00:00 UTC 以降に作成されたアカウントについて、Claude API およびクラウドプラットフォーム上でプレフィックスチェックを既定で適用する。システムプロンプト、ツール一覧、またはそれ以前のメッセージを編集した後にブロックを再送すると、リクエストは 400 を返す。回避策は 2 つある。thinking-binding-controls-2026-08-01 ベータヘッダーを送信し、thinking.block_binding.prefix_mismatch_behavior を "drop_block" に設定すると、リクエストを失敗させる代わりに影響を受けるブロックを破棄できる。あるいは、会話を追記専用に保ち、編集ではなく会話途中のシステムメッセージで指示を変更する——これは Claude Code、claude.ai、Claude Managed Agents、Claude Agent SDK がすでに行っていることだ。

見落としがちな良い知らせが1つあります。リクエストがターゲットモデルにとって読み取れないブロックを含んでいる場合、APIはモデルがそれを見る前にそのブロックを破棄します。リクエストは成功し、破棄されたブロックには課金されません。

4. 旧式の computer-use ツールは、Claude API および Google Cloud では拒否されます。

型 computer_20251124のツールエントリは、Claude API と Google Cloud で 400 を返します。メッセージには拒否された型が示され、続いてモデルが実際に受け入れる型が一覧表示されます:

• 「claude-opus-5-5」は次のツールタイプをサポートしていません: computer_20251124。

置き換えとなるのはcomputer_toolset_20260801ツールセットです。computer-use-2025-11-24ベータヘッダーを削除し、toolsエントリはnameも表示サイズも含めずに送信するようにします。これはリクエストの変更だけにとどまりません — エージェントループもそれに伴って変わります。アクションは単一のcomputerツールとしてではなく、メンバーのtool_useブロックとして届きます。1ターンに複数届くこともあり、アクションはブロックのnameではなくinput.action、そしてすべての結果はtoolset_nameをエコーバックする必要があります。Amazon Bedrockでは、computer_20251124はClaude Opus 5の場合とまったく同じように動作し続けるため、変更は不要です。

4つのうち、どれがClaude Fable 5.1にも当てはまりますか

Anthropicは、最初の3つはClaude Fable 5.1にも適用されると述べている — 常時オンの思考、強制ツール選択の不可、そしてモデルと会話に紐づけられた思考ブロックである。コンピュータ使用に関する変更はそうではない。それはClaude APIとGoogle Cloudにおけるこのモデルに固有のものだ。つまり、すでにClaude Fable 5.1へ移行したチームは、思考を無効化するコードパスと強制ツール選択を廃止しており、追記専用の会話パターンを採用している。残るのはモデルIDとコンピュータ使用ツールセットだけだ。Claude Opus 5から来るチームは、4つすべてに一度に対応することになる。それこそがスケジュールを組む価値のある移行であり、どこから始めるかによって作業量は異なる。

5番目の変更：何もエラーにならず、進捗フィードは静かになる

Claude Opus 5 では、モデルがツール呼び出しの合間に書く短いメモは、通常のテキストブロックとして返されます。Claude Opus 5.5 では — Claude Fable 5.1 と同様に — そのナレーションは進捗更新の thinking ブロックとして返され、各ツール呼び出しの前に最大 1 つです。また、thinking.display のデフォルトは "omitted"であるため、これらのブロックは署名とともに空の thinking フィールドを伴って返されます。

どのリクエストも失敗しない。エラーもログに記録されない。ツール間のテキストを進捗インジケーターとしてユーザーにストリーミングするアプリケーションは、ツール呼び出しの間で進捗を表示しなくなり、何も表示しなくなる。目に見える症状は、ユーザーが最も安心を求めるまさにその作業区間で UI がフリーズしたように見えることであり、これはパフォーマンス問題、ネットワーク問題、またはハングとして報告され、移行のバグとしては報告されない。これが本番環境にリリースされる変更である。

この修正は表示設定と、それに対応する読み取りです：

• thinking.displayを「updates」に設定します — ベータ版、thinking-display-updates-2026-08-18ヘッダーの背後にある — 推論自体は非表示のまま、進捗更新を取り戻すためです。これは進捗フィードが求める設定です。

• または、"summarized"に設定すると、進捗の更新と推論の要約が同じブロックにまとめて表示されます。

• 次に、テキストブロックではなく thinking ブロックからテキストを読み取り、空でない各 thinking ブロックを、そのブロックが先行する tool_use ブロックより前にレンダリングし、それらのブロックをアシスタントのターンの残りとともに変更せずに返します。

この点に関する Anthropic 自身の注記は、その趣旨を引用する価値がある。ツール呼び出しの間にテキストをレンダリングするインターフェースは、デフォルトに頼るのではなく、表示値を設定することが期待される。今日あなたの統合が thinking ブロックを完全に無視しているなら、そこがデフォルトが安全な唯一の箇所である。

労力がAPIサーフェスである

思考を無効化できない以上、output_config.effortはモデルがどれだけ推論するかを決める唯一の調整つまみとなり、ひいては特定のタスクにおけるコストとレイテンシを左右する唯一のつまみでもある。旧モデルから設定をそのままコピーする前に、これについて知っておくべきことが4つある。

デフォルトが移った。Claude Opus 5.5 のデフォルトは medium effortだが、Claude Opus 5 とそれ以前の Opus モデルは high がデフォルトだった。effort を省略したリクエストは、入れ替え前より1段階低い設定で実行されるようになる。Anthropic はまた、このモデルは同じ effort 設定であっても Claude Opus 5 よりも1ターンあたりに考える量が多くなる傾向があり、特に xhigh と max でそれが顕著だと文書化している。これら2つの効果は互いに逆方向に働く。まさにそのため、ベンダーの指示は、設定をそのまま横流しするのではなく、自分の評価で新たに effort スイープを回すことなのだ。

スケールはlow / medium / high / xhigh / maxで、ここでは5段階すべてがサポートされています。そもそも名前付きのレベルは固定のトークン予算ではありません — Anthropic は effort を厳密な予算ではなく行動のシグナルとして説明しており — 各レベルの背後にあるトークン配分はモデル間で変更されたため、Claude Opus 5.5 の「high」は Claude Opus 5 の「high」とは同じではありません。effort をモデルのデフォルトに設定することは、省略することと同一です。

運用上の注意点が2つあります。どちらも見落とすとコストがかさむためです。第一に、リクエスト間でトップレベルのeffort値を変更するとプロンプトキャッシュが無効になります。キャッシュヒットに依存する会話では1つのレベルを選んで一定に保ち、代わりにワークロードをまたいで変えるようにしてください。第二に、このモデルは次をサポートします：メッセージごとのeffort（ベータヘッダーmid-conversation-output-config-2026-07-01）。これはキャッシュを再起動することなく、後のターンからレベルを変更できます。ここでのプロンプトキャッシュの最小値は512トークンで、前世代の1,024から減少しているため、以前はキャッシュするには短すぎたプロンプトでも、コードを変更せずにエントリを作成できるようになりました。

出力上限：同期128K、Batchでは300K

同期 Messages API では出力が128K トークンに制限されます。Message Batches API では300K 出力トークンに達しますが、それにはoutput-300k-2026-03-24 ベータヘッダーが必要です — まさにこの文字列です。入力は既定で、ヘッダー不要の 1M トークンのコンテキストウィンドウ全体です。

実用上の解釈としては、128K の上限は Claude Opus 5 から変わっていない。したがって、同期統合について、その軸だけで予算を見直す必要は何もない。予算を見直す必要があるのは、その内部の thinking だ。現在、max_tokens はすべてのリクエストで thinking とテキストの両方をカバーするため、Claude Opus 5 では応答テキストにちょうど収まっていた値は、ここではより厳しくなる。そして xhigh または max の effort では、ベンダーは 64k から始めてチューニングすることを推奨している。長時間実行のジョブを 128K の同期上限に合わせて設計していて、今になって切り詰められる場合、変わったのは上限ではない。

セーフガードルーティングは仕様の一部です

これは統合上の事実であり、ポリシーの脚注ではない。プロンプトによっては、あなたが送信したモデル文字列は、実際に応答したものを表していない。

安全分類器を搭載したClaude Opus 5.5では、拒否されたリクエストはHTTP 200とともに返されます。stop_reason: "refusal"と、ポリシー領域を示すstop_detailsオブジェクトが付きます。このモデルはClaude Opus 5よりも多くのカテゴリをカバーしており、おなじみのカテゴリに加えてbio、frontier_llm、reasoning_extractionと、おなじみのcyberが含まれます。reasoning_extractionの拒否は再試行されず、完全にブロックされます。Anthropicのサーバーサイドフォールバックはこれを再試行せず、拒否はそのまま返されます。

リトライするカテゴリについては、仕組みはパラメータです。設定時は、fallbacksを"default"に設定し、server-side-fallback-2026-07-01 ベータヘッダーを付けると、API はそのカテゴリについて Anthropic が推奨するモデルで拒否されたリクエストを単一の呼び出し内で再実行し、1 つの応答を返します。Anthropic のヘルプセンターは、このモデルのルーティングを直接示しています。フラグが立ったサイバーセキュリティのリクエストのフォールバック先は Claude Opus 4.8 です。また、その生物学分類器 — Fable-5 スタイルのセット — は、Claude Opus 5 への、デュアルユースのライフサイエンス作業に対するフォールバックを引き起こします。フロンティア LLM 開発の限られた一部の能力も Claude Opus 5 にルーティングされます。Anthropic はまた、チェックはモデルが読むすべてのものを確認しており、最新のメッセージだけではないため、メモリ、コネクタのコンテンツ、検索結果、ファイルが切り替えを引き起こす可能性があると注記しています。

統合にあたって、次の3点に留意してください。すべてのレスポンスでトップレベルのmodelフィールドを確認してください。これはメッセージを実際に生成したモデルを報告するものであり、fallbackコンテンツブロックが各ハンドオフ地点を示します。フォールバック自体のレート制限を確認してください。レート制限にかかったフォールバックは試行されず、代わりに拒否が返されるためです。負荷がかかるとフォールバックは拒否に格下げされます。また、セーフガードを有効にした状態で公開されたベンチマークの実行結果は、Claude Opus 5.5 単体ではなくルーティングされたシステムの測定値として扱ってください。これはまさに、Anthropic が以下の自社の数値について述べているとおりです。

サーバーサイドフォールバックはベータ版であり、Claude API でのみ利用可能です。Message Batches API ではサポートされておらず、Amazon Bedrock、Google Cloud、Microsoft Foundry では利用できません。これらの環境では、代わりに SDK ミドルウェアが文書化された手段となっています。検証の面では、両カテゴリ（Cyber Verification Program と Life Sciences Verification Program）にアクセス経路が存在しますが、本稿執筆時点で Anthropic のヘルプセンターが文書化している非対称性に留意してください。Claude Opus 5.5 は現在 Cyber Verification Program に記載されていませんが、ライフサイエンスプログラムは、検証済み組織に最も高性能なモデルへのアクセスを提供すると説明されています。

コンテキスト、カットオフ、廃止、高速モード

エンベロープの残りの部分は、モデルページと非推奨テーブルから：

• コンテキストウィンドウ — 1Mトークン、デフォルト、ベータヘッダーなし

• 知識のカットオフ — 2026年6月。これはトレーニングデータのカットオフでもあります。

• 廃止 — Anthropic が運営するプラットフォームでは、2027-09-22 より前になることはなく、少なくとも 60 日前の通知があります。Amazon Bedrock と Google Cloud はそれぞれ独自の日程を定めています。Claude Opus 5 は少なくとも 2027-07-24 まで Active であるため、強制的な切り替えはありません。

料金表 — 入力100万あたり $4.00、出力100万あたり $20.00、5分キャッシュ書き込み100万あたり $5.00、1時間キャッシュ書き込み100万あたり $8.00、キャッシュ読み取り100万あたり $0.20。バッチは入出力とも半額で、$2.00 / $10.00です。

• キャッシュ読み取りは注目に値する例外です。$0.20 はベース入力の 5% で、ほとんどの Claude モデルは 10%、Claude Fable 5.1 は 2.5% に位置しています。キャッシュの再利用が多い混在ワークロードでは、これが実質的な割引として実感されます。

• ファストモード — 依然としてリサーチプレビューとして文書化されており、Claude API のみ、100万トークンあたり入力 $8.00 / 出力 $40.00 の個別価格設定です。有効にするには speed: "fast" と fast-mode-2026-02-01 ベータヘッダーを使用します。Bedrock、AWS 上の Claude Platform、Google Cloud、Microsoft Foundry では利用できず、Batch API でも、Priority Tier のコミットメントでも利用できません。なお、Claude Opus 5.5 は Priority Tier をまったくサポートしていません。

ベンチマークが示す内容と、どの設定においてか

エフォート設定こそが、ベンダーの表と独立した表を行単位で比較できない理由であり、また以下のすべての数値がその設定を伴っている理由である。

ベンダー報告、Anthropic自身のハーネスによる。Anthropicのローンチノートには、別段の記載がない限り、Claude Opus 5.5のすべての結果はmax effortでのアダプティブシンキングを使用したものであると記されている。例外はTerminal-Bench 4.0で、Claude Opus 5.5はxhigh、GPT-6 Astraはhighで報告されている。これがそれぞれのモデルの最高スコアだからだ。これに基づき、ベンダーはTerminal-Bench 4.0を66.4%、FrontierCode v1.1 Mainを54.4%、CursorBench 4.0を57.8%、GDPval-AA v2.1を1,846 Elo、AutomationBenchを40.0%、ツール使用時のHumanity's Last Examを67.7%、Terminal-Bench-Science 0.1を58.7%、OSWorld 2.0を81.8%の部分達成、ツール使用時のChartographyを89.0%と報告している。モデルのデフォルトであるmedium effortでは、ベンダーはFrontierCodeを54.6%、CursorBenchを52.5%としている。同じノートが開示している点にも注目されたい。評価は本番用のセーフガードを有効にして実行され、それらが作動した場合、サイバーセキュリティのタスクはClaude Opus 4.8が、生物学およびフロンティアLLM開発のタスクはClaude Opus 5が完了した。Anthropicは、これによりこれらのベンチマークにおけるClaude Opus 5.5の性能が低下した可能性が高いと述べている。したがって、影響を受けた評価で公表されたスコアは、このモデルのクリーンな測定値ではない。

独立系、Artificial Analysis。Intelligence Index v4.3.2において、Claude Opus 5.5は58を、Artificial Analysisが「Adaptive Reasoning, Max Effort, Default Fallback」と呼ぶ構成で記録している——これは同モデルの測定済み最高スコアを数ポイント上回るもので、10の構成評価のうち6つで首位に立っている。同じインデックス、同じハーネス上で、Claude Fable 5.1は53、Claude Opus 5は51を記録する。Artificial Analysisはエフォートの全段階を公開しており、これがここで最も有用な独立系の資料だ。max 58、xhigh 56、high 54、medium 51、low 42。同社自身の測定では、Claude Opus 5.5はmaxエフォート時にインデックスタスク1件あたり約119,000出力トークンで、Claude Opus 5の約73,000、Claude Fable 5.1の78,000、GPT-6 Astraの27,000と対比される——出力トークンとして課金されるトークンである——また同社のページはインデックスタスク1件あたり5.98ドルのコストを報告している。さらにTerminal-Bench 4.0で59.6%、Humanity's Last Examで61.4%を測定しており、異なるハーネスでmaxエフォート時にベンダーが示した66.4%および67.7%と対比される。

あの2つの段落を突き合わせて読めば、正直な結論は限定的だ。ベンダーの66.4%というTerminal-Benchと、独立系の59.6%は、異なる人々によって、一致が保証されない設定で実行された同じベンチマークであり、どちらもあなたのワークロードに関する証拠にはならない。転用可能な知見はエフォートのはしごだ。独立した指標では、このモデル自身の設定は16ポイントにまたがっており、これはこのモデルとその前身モデルとの差よりも広い。どのエフォートレベルを選ぶかは、これらのモデル間でどちらを選ぶかよりも重要であり、そのラベルにある「Default Fallback」条項は、上述のセーフガード・ルーティングであって、ベンチマークのアーティファクトではない。

ベンダー報告による効率性（帰属先明記）。Anthropicによれば、Claude Opus 5.5はほとんどの作業でClaude Fable 5.1と同水準の性能を、実行コスト約40%減で発揮し、一般的なワークロードのコストは、20%の定価引き下げに対してClaude Opus 5比でおよそ40%少ないという。出力は30%以上高速である。これらはベンダーが選定したワークロード全体の平均についての、ベンダーによる説明である。発表時の顧客コメントも同じ種類の証拠だ。Boxはトークン数が3分の1、回答は約40%簡潔になったと報告し、Kiroはトークン数がほぼ半分、呼び出し回数が約40%減、Factoryは出力トークンが20〜25%減、GitHubは同社が計測した中で最も少ない部類のトークン数とステップ数だとしている。Anthropicはまた、社内のファクトチェックテストで、18件の報告のうち16件が品質基準を通過したとも報告している。この基準はClaude Fable 5.1もClaude Opus 5も一度も達成できなかったものだ。これらはすべてベンダー報告であり、監査を受けたものは一つもない。開示された限界は異例なほど率直で、心に留めておく価値がある。AnthropicはClaude Opus 5.5について「自分が評価されているのではないかと頻繁に疑う」と述べている。

最後に、兄弟モデルについてです。Anthropicは、Claude Sonnet 5.5とClaude Haiku 5.5が「今後数週間のうちに」登場すると述べています。どちらもまだ出荷されておらず、価格も公表されておらず、今日時点でどのサーフェスにも搭載されていません。

完全なカットオーバーなしで4つの変更をテストする

ここでの移行リスクは品質ではありません — ステージングで一度も実行しなかったコードパスが、本番で400を返すことです。4つの破壊的変更はすべてリクエスト形状の変更であり、つまり決定的かつ即座に失敗します。見落としたパスを見つける唯一の方法は、実際のトラフィックをそれらに通すことです。

Claude Opus 5.5はOrcaRouterでanthropic/claude-opus-5.5として、Anthropic自身の定価のままマークアップ0%で提供されています — プロバイダーの定価をそのまま反映しているため、ベンダーの価格変更は同日中にここでも反映されます。

これにより、本番トラフィックの一定割合をそのモデルに振り向けつつ、残りは引き続き Claude Opus 5 で実行したまま、どのリクエストがなぜ失敗するかを監視し、一度に一つずつ修正できます。4 つのエラーは自己説明的で、それぞれが拒否されたパラメータを明示し、4 つのうち 3 つでは代替も示します。経路がまだ壊れている間の隙間は自動フェイルオーバーが埋めます——十分に特性を把握していないモデルに対して失敗したリクエストは、ユーザーに 400 を提示するのではなく、把握済みのモデルにフォールバックします。

実践的な作業順序としては、まずモデルIDを差し替えて effort を明示的に設定します。デフォルトが medium に移ったからです。次に、thinking-disabled と forced-tool-choice の経路を削除します。その後、ストリーミングリーダーを修正します — タイプによるブロック選択と thinking.display 設定です — これは大声で失敗するのではなく、静かに失敗するものだからです。Bedrock を使っている場合は、computer-use ツールセットの移行を最後に回してください。そこでは適用されないものだからです。それ以外はすべて — 価格、コンテキストウィンドウ、キャッシュ料金、1Mトークンのデフォルト — すでにあなたが置いたままです。

完全な切り替えを行うことなく、ライブトラフィックの一部を新しいモデルへ振り向けられます：OrcaRouter 上の Claude Opus 5.5は Anthropic の定価で稼働し、すでに特性を把握済みのモデルへの自動フェイルオーバーを備えています。