できること
利用可能なモデルの一覧取得
GET /v1/models で、API で利用できるモデルを確認できます。一覧は、新しくリリースされたモデルから順に並びます。
特定モデルの情報とエイリアス解決
GET /v1/models/{model_id} で、特定のモデルの情報を取得できます。モデルのエイリアスを実際のモデル ID に解決する用途にも使えます。
対応機能と上限値の確認
各モデルの capabilities オブジェクトで、画像・PDF・Batch API・structured output などへの対応を確認できます。max_input_tokens と max_tokens で、入力コンテキストと出力トークン数の上限も分かります。
機能解説
概要
一覧を返す GET /v1/models と、特定のモデルの情報を返す GET /v1/models/{model_id} があります。各モデルについて、対応している機能、入力コンテキストの上限、ライフサイクル段階などを取得できます。アプリケーションからどのモデルを使うかを判断する場面に関わる機能です。
Models API には 2 つのエンドポイントがあります。
- List Models (
GET /v1/models): API で利用できるモデルの一覧を返します。新しくリリースされたモデルが先に並びます。 - Get a Model (
GET /v1/models/{model_id}): 特定のモデルの情報を返します。モデルのエイリアスをモデル ID に解決する用途にも使えます。
一覧の取得では、次のクエリパラメーターを使えます。
limit: 1 ページあたりの件数です。既定値は 20 で、1〜1000 の範囲で指定します。after_id/before_id: ページ送りのカーソルです。レスポンスのlast_idを次のページのafter_idに、first_idを前のページのbefore_idに使えます。lifecycle: 指定したライフサイクル段階 (active・deprecated・retired) のモデルに絞り込みます。値は 3 つまで指定できます。
capabilities で分かること
各モデルのエントリには capabilities オブジェクトが含まれます。機能名とその対応状況を対応付けたもので、既知の機能のキーは常にすべて含まれます。主な内容は次のとおりです。
- Batch API への対応
- 画像のコンテンツブロックを受け付けるか
- PDF のコンテンツブロックを受け付けるか
- structured output / JSON mode / strict tool schemas への対応
- effort (
reasoning_effort) への対応と、使える effort のレベル server_tools: Web 検索ツールとコード実行ツールを受け付けるか- トップレベルの
code_execution: コードがリクエスト内の他のツールを呼び出せるか thinking.types: リクエストで受け付けるthinking.typeの値
thinking.types の各キーは、それぞれ単独で読みます。たとえば enabled が false で、disabled が true という組み合わせもあります。
このほか、各モデルには line フィールドがあり、モデルが属するモデルライン (例: opus) を返します。どのラインにも属さないモデルでは null です。ラインはモデルの id から推測せず、このフィールドで判断します。入力コンテキストの上限は max_input_tokens、max_tokens パラメーターに指定できる最大値は max_tokens で確認できます。
ライフサイクルと提供終了の扱い
各モデルの lifecycle フィールドは、現在のライフサイクル段階を active・deprecated・retired のいずれかで示します。
一覧の取得で lifecycle パラメーターを省略すると、active と deprecated のモデルだけが返ります。retired のモデルは、retired を明示的に指定した場合にだけ含まれます。
retires_at は、そのモデルの現時点で予定されている提供終了日です。この日付は、実際に提供が終了するまで変更される場合があります。deprecated のモデルで retires_at が過去の日付になっていても、それは提供終了が予定より遅れていることを示すもので、終了したことを意味しません。提供終了の判断には lifecycle を使います。
管理者・導入時に確認したい点
anthropic-workspace-idヘッダーは、リクエストの対象となる Workspace を選びます。このヘッダーが必要なのは、複数の Workspace を操作できる認証情報を使う場合だけです。特定の Workspace に属する認証情報では省略でき、送る場合はその Workspace と一致させます。server_toolsでツールに対応しているモデルでも、組織の設定によってツールが拒否される場合があります。たとえば、管理者が Web 検索をオフにしている場合です。
使い方
ここでは、モデル一覧を取得する流れを示します。
- リクエストに
anthropic-versionヘッダーを付けます (例:anthropic-version: 2026-10-21)。 Authorization: Bearer $ANTHROPIC_API_KEYヘッダーで API キーを渡します。GET /v1/modelsにリクエストを送り、モデルの一覧を受け取ります。特定のモデルを取得する場合は、同じヘッダーでGET /v1/models/$MODEL_IDに送ります。
利用シーン
アプリケーションの起動時や設定画面で、API で利用できるモデルの一覧を表示する場面に使えます。
画像や PDF を扱う処理の前に、選んだモデルがそれらのコンテンツブロックを受け付けるかを確認する場面に向いています。
利用中のモデルが deprecated になっていないか、retires_at がいつかを定期的に確認する場面に使えます。
設定ファイルにエイリアスで書いたモデル名を、実際のモデル ID に解決する場面に使えます。
ChatGPT・OpenAI の対応する機能
公式リリースノートでは、対応する発表を確認できていません (2026-11-03 時点)。 これは、対応する機能が存在しないことを示すものではありません。
これまでの変更
capabilities.thinking.types.between_toolsが追加され、各モデルが事前の thinking をオフにするthinking: {type: "between_tools"}を受け付けるかを返すようになりました。capabilities.server_toolsが追加され、各モデルが Web 検索ツールとコード実行ツールを受け付けるかを返すようになりました。capabilities.thinking.types.disabledが追加され、各モデルが thinking をオフにするthinking: {type: "disabled"}を受け付けるかを返すようになりました。lineフィールドが追加され、GET /v1/modelsとGET /v1/models/{model_id}が各モデルの属するモデルラインを返すようになりました。どのラインにも属さないモデルではnullです。