Claude の Models API が「thinking を切れるモデルか」を返すようになった — Sonnet 5.5 で分かれた挙動を事前に判定できる

要約

Claude Platform の API リリースノート 2026-10-05 付エントリで、Models API に capabilities.thinking.types.disabled フィールドが追加されました。 GET /v1/models と GET /v1/models/{model_id} のレスポンスが、各モデルが thinking: {type: "disabled"} を受け付けるかを返します。

単体では地味な追加ですが、背景を知ると位置づけが変わります。

2026-09-28 の Claude Sonnet 5.5 公開で、API に破壊的変更が入りました。 Sonnet 5.5 では thinking を切るのに "disabled" ではなく thinking: {"type": "between_tools"} を使う必要があります。つまりモデルによって、受け付ける thinking のタイプが分かれたということです。

この状態がコードに何を強制するかというと、モデル ID による分岐です。 「モデル名が claude-sonnet-5-5 を含むなら between_tools、それ以外なら disabled」という判定を書くしかありません。そしてこの手の分岐は、必ず壊れます。 新しいモデルが出るたびに条件を足す必要があり、足し忘れればリクエストが 400 で落ちます。

今回のフィールドは、その分岐を API への問い合わせに置き換えます。 モデル一覧を取得すれば、どのモデルが "disabled" を受け付けるかが機械的に分かります。 モデル ID の文字列を解釈する必要がありません。

この方向は、2026-10-01 に追加された line フィールドと同じです。 line は「Claude Opus 4.5 と 4.6 がどちらも opus を返す」ようにして、モデル ID をパースせずにモデルの系列を知れるようにしたものでした。Anthropic は、モデル ID の文字列から情報を読み取る実装を減らそうとしています。

実装者への示唆は明確です。モデル ID を includes() や正規表現で判定しているコードは、順次 capability の問い合わせに置き換えられます。 モデルが増えるたびにコードを直す運用から抜けるための足がかりが、API 側に用意され始めています。

なお本件は、2026-10-07 の日次チェックで追補として検出しました。 公開日（10-05）は前日の窓に入っていましたが、当日のサマリーには記録されていません。date-only のエントリは取りこぼしやすいという運用上の課題がそのまま出た形です。

何が変わったか

• Models API に capabilities.thinking.types.disabled が追加された（2026-10-05）
• 対象エンドポイントは GET /v1/models と GET /v1/models/{model_id}
• 各モデルが thinking: {type: "disabled"} を受け付けるかどうかを返す
• 背景は 2026-09-28 の Claude Sonnet 5.5 の破壊的変更。Sonnet 5.5 では thinking を切るのに between_tools を使う
• モデル ID の文字列判定による分岐を、capability の問い合わせに置き換えられる
• 方向性は 2026-10-01 の line フィールド（モデルの系列を ID のパースなしに取得）と同じ

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

自社の実装で「モデル名で分岐しているコード」を探すのが、最初の作業です。

探し方は単純です。claude-opus、claude-sonnet、-5-5 のような文字列を条件に使っている箇所を grep してください。そこがモデル更新のたびに壊れる場所です。 そして壊れ方が厄介です。 新しいモデルを追加した瞬間ではなく、そのモデルで thinking を切ろうとしたときに 400 が返ります。 テストで拾えないことが多い種類の不具合です。

モデルを複数扱っている組織ほど効きます。 「通常は Sonnet、難しい処理は Opus、安い処理は別のモデル」という振り分けをしている場合、thinking パラメータの組み立てがモデルごとに分かれます。 ここを ID のハードコードで処理していると、モデル構成を変えるたびにコードレビューが必要になります。capability を問い合わせる実装にしておけば、モデルの入れ替えが設定変更だけで済む可能性が出てきます。

運用として入れておきたいのは、モデル一覧の定期取得です。 GET /v1/models を起動時または日次で取得し、capability を含めてキャッシュする形にしておくと、新しいモデルが追加されたときに自動で追随します。毎リクエストで問い合わせる必要はありません。 ただしキャッシュの有効期限は短めにしてください。モデルの capability は増える方向に変わります。

意思決定として記録しておくべきは、「モデル ID から情報を読み取らない」という方針です。 これは Anthropic の API 設計が示している方向であり、今後も capability フィールドは増えると予想できます。 社内のコーディング規約に「モデル ID をパースしない」を入れておくと、新しく書かれるコードが同じ罠にはまるのを防げます。 技術的には1行の追加ですが、規約として書くかどうかで半年後の保守コストが変わります。

なお、小さな変更なので展開の緊急性は低いです。 既存コードが今動いているなら、壊れるのは次にモデル構成を変えるときです。 計画的なリファクタリングの対象として記録し、モデルを追加するタイミングで一緒に直すのが現実的です。

副業・個人活用視点

この種の追加は、読み方を知っていると差が付きます。

capabilities.thinking.types.disabled という1フィールドの追加は、リリースノートで見ると読み飛ばす大きさです。しかし2026-09-28 の破壊的変更と 10-01 の line フィールドと並べると、意図が見えます。 「モデル ID から情報を読み取らせない方向へ API を整えている」という流れです。

この「点を線にする読み方」は、技術記事で評価されます。 単発のリリースノートを翻訳した記事は量産されますが、3つの変更を並べて方向性を説明する記事は少ないです。 そしてこの方向性は実装の判断に直結します。「モデル ID をパースしない」という設計方針は、今後の API 変更に対して強いという予測が立ちます。

受託で LLM を組み込む仕事をしているなら、保守性の提案材料になります。 「モデル名で分岐しているコードは、モデルが増えるたびに直す必要があります。API 側に capability を問い合わせる仕組みが整ってきたので、そちらへ寄せましょう」という提案は、機能追加ではなく保守コストの削減です。この種の提案は、継続契約を取りやすいです。 派手ではないが、半年後に効果が出ます。

自分の個人プロジェクトでも、今のうちに直しておく価値があります。 モデルの切り替えを if (model.includes("opus")) で書いているなら、モデルが変わるたびに自分が直すことになります。個人プロジェクトは保守の優先度が下がりがちなので、壊れたまま放置されて「動かないからもう使わない」になるのが典型的な末路です。1回の手当てで寿命が延びます。

記事にするなら、失敗例を書くのが効きます。 「Sonnet 5.5 を追加したら 400 が返った。原因は thinking の type を disabled で固定していたこと」という実例は、同じ罠にはまる人が多い種類の話です。公式のリリースノートを読んだだけでは気づけず、実際に動かして初めて分かることなので、実測した記事は読まれます。

関連リンク

• Claude Platform API Release Notes（2026-10-05 エントリ）