AnthropicはModels APIの応答にmax_input_tokens、max_tokens、capabilitiesオブジェクトを追加した。GET /v1/modelsとGET /v1/models/{model_id}から、各モデルの上限と対応能力を取得できる。
これまでモデル名の接頭辞、リリース日、社内の手書き設定表で機能を判定していたアプリは、モデル追加や能力変更のたびにコード更新が必要だった。APIによる動的発見を使えば更新漏れを減らせるが、毎リクエスト取得や無条件自動有効化は別の障害を生む。
何が変わったか
モデル一覧・詳細取得の結果から、入力上限、最大出力、能力情報を機械的に参照できるようになった。ルーター、管理画面、入力バリデーション、モデル比較ツールが、モデル名だけに依存せず判断できる。
変更前後の差
| 項目 | 固定設定表 | Models API活用 |
|---|---|---|
| 上限管理 | コードへ手書き | API応答から取得 |
| 新モデル対応 | デプロイが必要 | 検出可能 |
| 更新漏れ | 起こりやすい | 差分監視できる |
| 障害時 | 固定値で継続 | キャッシュが必要 |
| 権限制御 | 設定表と混在 | 能力と許可を分離 |
| 監査 | 変更履歴が不明 | 取得時点を記録可能 |
誰に影響するか
複数Claudeモデルを自動選択する基盤、最大コンテキストに応じて文書を分割するRAG、出力上限をUIへ表示する製品、特定能力が必要なエージェント、モデル移行を自動化するCIに影響する。
期限
強制対応期限はない。既存API呼び出しは継続できるが、モデル更新頻度が高い環境では固定表の陳腐化リスクが増える。
必要な対応
能力情報と組織ポリシーを分離する。capabilitiesが対応を示しても、本番利用を自動許可しない。利用許可リスト、地域、データ要件、費用、評価完了状況を別レイヤーで判定する。
実装・移行手順
- 現在のモデル設定表と利用箇所を棚卸しする。
- 起動時または定期処理でModels APIを取得する。
- 取得結果を取得日時付きでキャッシュする。
max_input_tokensとmax_tokensを入力・出力検査へ利用する。capabilitiesは未知キーを保持するスキーマで保存する。- 前回値との差分を通知し、自動有効化は承認後に行う。
- API取得失敗時は直近の検証済みキャッシュへ戻す。
失敗しやすい点
毎リクエストModels APIを呼び出す、取得失敗時に全モデルを利用不可にする、capabilityがtrueなら即座に本番ルートへ入れる、未知フィールドをデシリアライズで破棄する、入力上限をトークナイズせず文字数で代用する、といった設計は避ける。
リスク
API応答の一時障害、キャッシュの古さ、能力情報と契約・地域制約の混同、自動ルーティングによる未評価モデル利用がある。上限値が増えた場合も、アプリのメモリ、遅延、費用が同じとは限らない。
評価方法
- Models API取得成功率とキャッシュ年齢
- 固定表との差分検出時間
- 上限超過リクエストの事前拒否率
- 未評価モデルへ自動流入した件数
- モデル追加から管理画面反映までの時間
- API障害時の継続稼働率
- 未知capabilityキーの保存率
ロールバック
動的判定をFeature Flagで無効化し、直近の検証済み固定スナップショットへ戻す。取得データと差分ログは保持し、誤判定の原因を確認する。モデル許可リストは動的情報とは独立させ、ロールバック時も安全側を維持する。
編集部分析
動的能力発見は、モデル更新への追随を速める一方、ガバナンスを自動化する機能ではない。能力の有無、組織が許可するか、品質が十分かは別問題である。Models APIは「何が可能か」の正本、社内ポリシーは「何を使ってよいか」の正本として二層に分けるべきだ。
実務チェックリスト
- [ ] モデル名によるハードコード判定を洗い出した
- [ ] Models API応答を取得日時付きで保存した
- [ ] 未知のcapabilitiesキーを保持できる
- [ ] 能力情報と利用許可を分離した
- [ ] 取得失敗時のキャッシュフォールバックがある
- [ ] 上限変更の差分通知を設定した
- [ ] 新モデルを評価前に本番利用しない