リリースノートって、ちゃんと読むと「あ、これ地味に使える」ってアップデートが隠れていることがある。
2026年3月18日のAnthropic Platform Updateがまさにそれだった。
今回追加されたのは、Models APIへのモデル能力フィールドの追加だ。GET /v1/models と GET /v1/models/{model_id} のレスポンスに、max_input_tokens・max_tokens・capabilities オブジェクトが返ってくるようになった。capabilities オブジェクトとは、そのモデルが何をサポートしているかを構造化されたデータで表現したものだ。
これ、何がうれしいのか
正直、最初は「まあそうだよね」と流しそうになった。
ただ、ちょっと考えると実装上のインパクトがある変更だと気づいた。
これまで、「このモデルのコンテキスト長って何トークンだっけ？」という問いに答えるには、ドキュメントを調べるしかなかった。
コード側にハードコード（プログラムの中に値を直接埋め込むこと）するか、自前でモデル名と上限値のマッピングテーブルを持つしかなかった。
でも今は、APIを叩けばそのまま返ってくる。
モデルが増えたり、スペックが変わったりしても、マッピングテーブルを更新し忘れるバグが起きにくくなる。
マルチモデル対応のコードが書きやすくなる
Claudeを使っていると、用途に応じてモデルを切り替えたいシーンが出てくる。
軽いタスクはHaikuで処理して、複雑な推論が必要なときはSonnetに切り替える、みたいな設計だ。
こういう「動的なモデル選択」をする実装では、各モデルのスペックをコード側が把握している必要がある。
コンテキストウィンドウの上限を超えるリクエストを投げてしまうと、エラーになるからだ。
capabilities オブジェクトがどこまで詳細な情報を持っているかが、今後の実装設計に効いてくると思う。
ビジョン対応かどうか、ツールコール対応かどうか、といった情報もここに入るなら、モデル選択ロジックをAPIドリブンで組めるようになる。
地味なアップデートに見えるけど、複数モデルを切り替えるシステムを本番運用しているチームには刺さる変更だと思う。
GPTやGeminiと比べると？
OpenAIのModels APIも似たような情報を返すが、max_tokens のような能力値を直接返す設計は昔からあったわけではない。
Gemini側でも、モデルのメタデータ取得エンドポイントで似た情報が取れる設計になってきている。
こうした「APIでモデルのスペックを自己記述的に返す」設計は、マルチモデル対応アプリを作るときの標準的なやり方として定着しつつある。
Anthropicがこれを今回正式に追加したのは、開発者向けのエコシステムを整備している意図が見える。
モデルが増えれば増えるほど、ドキュメントに頼るやり方はスケールしない。
APIが自分自身のスペックを語れる設計は、正しい方向性だと思う。
モデルを複数使い分ける設計を考えているなら、まず GET /v1/models を叩いてレスポンスの構造を眺めてみてほしい。
実際に何が返ってくるか確認してから設計を始めると、実装の見通しがかなり変わるはずだ。