Sonnet 5.5 の推論は、ひとつのモデルとひとつのアカウントの中にとどまる

Claude Sonnet 5.5 は 9 月 28 日に Sonnet 5 と同じ価格でリリースされ、同じ日に Claude Code v2.1.284 が Anthropic API でのデフォルトの Sonnet をこれに切り替えました。Anthropic は、Sonnet 5 向けに書いたコードが壊れる点を 5 つ挙げています。tool_choice の強制指定は 400 を返し、Claude API と Google Cloud では computer use がツールセットに移ります。どちらも Opus 5.5 で見覚えのある変更です。advisor ツールは Opus 4.8、Opus 4.7、Sonnet 5 を advisor として受け付けません。thinking のオフの仕方は Opus 5.5 と異なり、disabled は 400 を返し、代わりに high 以下の effort で between_tools を使います。そして thinking ブロックが、モデルとアカウントに紐づくようになりました。

先週、400 は良い壊れ方だと書きました。5 つ目の変更は 400 を出さないほうの変更で、モデルルーターが扱うべき単位を、ターンから会話へと静かに変えてしまいます。

Sonnet 5.5 の thinking を読めるモデルはどれか？

Sonnet 5.5 自身だけです。ドキュメントははっきりしています。Sonnet 5.5 は Sonnet 5、Opus 4.8、Haiku 4.5 とそれ以前のモデルの thinking ブロックを読めますが、Opus 5、Opus 5.5、Fable や Mythos 系のモデルのブロックは読めません。そして "no other model reads thinking blocks from Claude Sonnet 5.5." とあります。

これでどのペアが切れるかを見てください。このラインナップなら自然に考えるルーティングは、定型的なターンを Sonnet 5.5、難しいターンを Opus 5.5 に振る形です。この 2 つは、どちらの方向にも何も共有しません。Opus 5.5 は Opus 5 と、それ以前の Opus、Sonnet、Haiku のブロックを読めるので、Sonnet 5 から Opus 5.5 へ渡れば推論は残ります。Sonnet 5.5 から Opus 5.5 では残りません。Haiku 4.5 へ戻すルートでも同じです。

モデルが読めないブロックはどうなるのか？

プロンプトがモデルに届く前に API が取り除き、リクエストは成功します。破棄されたブロックは課金されず、input_tokens にも数えられません。text と tool_use のブロックは残るので、モデルは何が話され、何が実行されたかは引き続き把握できます。ただ、そのターンにはその裏にあった推論なしで答えることになります。

失われるのはリクエスト単位で、永続的ではありません。API が messages 配列を書き換えることはないので、それらのブロックを読めるモデルに戻った次のリクエストでは、推論がまた渡されます。Anthropic の推奨は、thinking を含む履歴を丸ごと送り続け、現在のモデルが使えないものは API に捨てさせることです。推論が本当に失われるのは、自分のクライアントがそれを削った場合だけです。

アカウントへの紐づけで何が加わるのか？

モデルとは無関係の、2 つ目の壁です。Sonnet 5.5 が生成したブロックは "work only in the account that produced them, or in an account linked to it." とされています。別のアカウントからブロックを送ると、API はやはり 200 のまま破棄します。以前のモデルのブロックは影響を受けません。

つまり、リンクされていない複数のアカウントにまたがる会話は、アカウントをまたぐたびに推論を失います。複数の組織のキーに負荷を分散するゲートウェイ、最初のアカウントがレート制限に当たったときに 2 つ目へ切り替える運用、開発用アカウントの会話を本番で再生するケースなどです。

ドキュメントに書かれていないことは？

エラーを一切出さない挙動にしては、不明な点が思ったより多く残っています。「リンクされた」の定義がありません。紐づけが組織単位なのか、ワークスペース単位なのか、キー単位なのか、また Bedrock のアカウントが直接の API アカウントに対して「別のアカウント」になるのかは、ページからは読み取れません。organization_binding_mismatch の報告が文書化されているのは Claude API と Google Cloud だけで、Amazon Bedrock、Claude Platform on AWS、Microsoft Foundry についてはどちらとも書かれていません。オプトアウトの方法も記載がありません。

Anthropic 自身の拒否時フォールバックもモデルの切り替えで、ドキュメントもそう明記しています。サーバー側フォールバック（fallbacks: "default"、ベータ、Claude API）は cyber と frontier_llm の拒否を Sonnet 5 で再試行しますが、Sonnet 5 は Sonnet 5.5 のブロックを読めないので、ブロックは破棄されます。しかも 1 ターンでは終わりません。スティッキールーティングにより、その会話の後続リクエストは約 1 時間、直接フォールバック先のモデルに送られます。範囲は自分の組織内です。

破棄はどうすれば見えるのか？

ブロック単位で見るには、自分から求めるしかありません。ベータヘッダー thinking-binding-controls-2026-08-01 を付けると、すべてのレスポンスのトップレベルに input_transformations 配列が入り、破棄された各ブロックが理由付きで並びます。モデル違いなら model_binding_mismatch、アカウント違いなら organization_binding_mismatch です。ヘッダーがなければ、破棄は黙って行われます。フォールバックはレスポンスの model フィールドには現れますが、分かるのはモデルが変わったことだけで、何が失われたかではありません。

resp = client.beta.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=16000,
    messages=history,
    betas=["thinking-binding-controls-2026-08-01"],
)
for t in getattr(resp, "input_transformations", None) or []:
    if t.type == "thinking_dropped":
        log.warning("reasoning dropped at %s: %s", t.path, t.reason)

このとき、削ったリクエストではなく本物の system と tools を一緒に送ってください。Anthropic は今後のチェックで新しい種類や理由が増えるとしているので、知らない値で処理が失敗しないようにしてください。

ルーターは何を変えるべきか？

ルーティングの単位です。私見では、設計は擁護できても、デフォルトは擁護できません。ハードエラーにすれば、互換性のない切り替えをまたいで thinking を渡すルーターがすべて壊れますし、ブロックは消されるわけではなく、そのターンで使われないだけです。それでもリクエストはひとつも失敗しないので、通常のエラー監視には数えるものがありません。ブロック単位の唯一のシグナルは、ほとんどのインテグレーションが送ることのないベータヘッダーを付けないと得られません。

役割で分ける構成、つまりレビュアーがワーカーの出力を自分の会話で受け取る形なら、何も失いません。レビュアーが読むのは成果物であって、ワーカーの thinking ではないからです。これは、よりエージェント的なモデルをレビュアーの席に座らせたときに書いた役割分担の形です。一方、ひとつの会話の中でターンごとにモデルを選ぶルーターは、いまやモデルにどの推論を見せるかも選んでいることになります。モデルを、じっとしていない依存関係として扱う話で書いたモデルのポートフォリオは、各会話がその中のひとつにとどまる限り、今も機能します。

ですから、できるところでは会話単位でルーティングし、ひとつの会話はひとつのアカウントに置き、途中でどうしても切り替えるなら、互いのブロックを読めるペアの中にとどまってください。そのうえでステージングでヘッダーを有効にし、実際のトラフィックを 1 日分ルーターに流して、何が破棄されたかを数えてみてください。