OllamaのモデルIDをWindowsで確認する方法｜/v1/models・api/show・capabilities

先に結論：モデルID・保存状態・能力・実行状態を分けて照合する

Ollamaの「モデル名」は、どの画面・API・clientから見ているかで役割が変わります。OpenAI互換clientへ渡すID、Ollamaが保存しているnameやdigest、モデル詳細のcapabilities、今ロードされている実行状態を一つの文字列だけで判断しないでください。

「表示名をそのままclientへ入れる」「保存一覧にあるからtool対応のはず」「実行中だから別tagと同じ」といった推測を止め、同じmodel文字列とdigestを複数endpointで記録します。これがmodel not foundと機能非対応を分ける最短の入口です。

• Ollamaモデル管理 - 保存・停止・削除・容量整理の操作へ進む
• Ollama OpenAI互換API - base URL・endpoint・clientの前提を見る
• Ollama API認証 - localhostとcloudの認証境界を確認する

OpenAI互換clientが使うIDを/v1/modelsで確認する

OpenAI互換APIを使うときは、まずGET /v1/modelsを呼び、レスポンスのdata配下にあるidをそのまま記録します。Ollama公式の互換性docsでは、/v1/modelsでclientから見えるモデル一覧を取得でき、createdやowned_byなどの項目も示されています。createdはモデルの最終変更時刻として扱われるため、現在時刻や推論開始時刻と混同しません。

$models = Invoke-RestMethod `
  -Uri "http://localhost:11434/v1/models"

$models.data | Select-Object id, object, created, owned_by

# 以降のclient設定には、表示名ではなくdata[].idを使う

1. Ollamaが動いているWindowsで、最初にlocalhostのbase URLを固定する。
2. GET /v1/modelsのレスポンスを保存し、data[].idをコピーする。
3. Responses、chat completions、tool callingなどへ指定するmodel文字列を、そのidと完全一致させる。
4. 404やmodel not foundが出る場合は、URL・port・model IDを一度に変更せず、同じGETを再確認する。

この一覧はOpenAI互換serverから見えるclient向けのIDを確認する場所です。保存先の容量、量子化、capabilities、現在のVRAM使用量までを/v1/modelsだけで断定せず、次のnative APIを追加で見ます。

• Ollama OpenAI compatibility公式docs - /v1/modelsとmodel IDの現行例を見る
• Ollama Responses API - 取得したIDを/v1/responsesへ渡す実装を見る
• Ollamaのmodel not found対策 - provider共通の表示名・ID・slugの違いを確認する

保存済みのname・model・digestを/api/tagsで照合する

GET /api/tagsは、Ollamaが保存済みとして管理しているモデルの一覧を返します。Windowsで容量やtagを確認するときは、nameだけでなくsize、digest、modified_at、detailsも記録し、/v1/modelsのidと同じ文字列かを比較します。tagを省略した名前、別tag、カスタムモデルを一つにまとめて扱わないことが重要です。

$saved = Invoke-RestMethod `
  -Uri "http://localhost:11434/api/tags"

$saved.models | Select-Object `
  name, model, modified_at, size, digest, details

保存一覧に出ないIDをOpenAI互換clientへ指定している場合は、まずモデルのpull・tag・serverの向きを確認します。逆に保存一覧にあるだけで、/v1/modelsで同じIDが公開される、または任意のendpointが使えると決めつけません。

• Ollama API List models公式docs - name・size・digest・detailsの仕様を見る
• Ollamaモデルの一覧・削除 - ollama ls・ps・show・rmの順番を確認する
• モデル保存場所 - OLLAMA_MODELSとWindowsの保存先を分ける

能力・形式・contextの根拠を/api/showで確認する

tool calling、vision、embeddingなどをモデル名から推測せず、POST /api/showで詳細を取得します。公式仕様では、modelを指定してcapabilities、model_info、license、format、parameter size、quantization、templateなどを確認できます。capabilitiesが返した事実を記録し、対応しているように見える名前やコミュニティの紹介文だけを根拠にしません。

$body = @{
  model = "MODEL_FROM_API_TAGS"
  verbose = $true
} | ConvertTo-Json

$details = Invoke-RestMethod `
  -Uri "http://localhost:11434/api/show" `
  -Method Post `
  -ContentType "application/json" `
  -Body $body

$details | Select-Object capabilities, format, details, model_info, license

• まず/api/tagsで取得したmodel文字列を使い、手入力で別tagへ置き換えない。
• capabilitiesは返却された値をそのまま記録し、対応している機能とclient側の実装を分ける。
• parameter size、quantization、context関連の情報を、性能・速度・品質の保証とは表現しない。
• licenseやtemplateを取得しても、配布元の利用条件を自動で満たすとは考えない。

api/showはモデルの能力を確認するための根拠ですが、clientがそのendpointやrequest schemaを正しく呼べることまで保証しません。tool calling、Structured Outputs、embedding、Responsesは、それぞれのAPI記事とOllama公式仕様を組み合わせて確認します。

• Ollama API Show model details公式docs - capabilities・model_info・licenseの仕様を見る
• Ollamaのtool calling - 能力確認後のtools実装へ進む
• OllamaのEmbedding API - embedding modelと/api/embedの実装を見る

現在ロード中か、VRAM・contextを/api/psで確認する

GET /api/psは保存済み一覧ではなく、現在ロードされているモデルの状態を確認するendpointです。公式仕様のname、model、size、digest、details、expires_at、size_vram、context_lengthを記録すると、同じ名前のモデルが保存されているだけなのか、今のserverが別digestを実行しているのかを切り分けやすくなります。

$running = Invoke-RestMethod `
  -Uri "http://localhost:11434/api/ps"

$running.models | Select-Object `
  name, model, size, digest, size_vram, expires_at, context_length

api/psのsize_vramは「このPCで常にGPU推論できる」という保証ではありません。モデル、context、同時実行、設定、Windowsの負荷によって結果が変わるため、診断時点の値として記録します。

• Ollama API List running models公式docs - 実行中モデルとsize_vram・context_lengthを見る
• Ollama GPU未使用の切り分け - GPU・CPU・ドライバ・負荷を分けて確認する
• コンテキスト長の基礎 - contextとメモリ・長文の関係を整理する

model not found・tool・vision・embeddingを機能別に切り分ける

4つのレスポンスをそろえたら、症状を「IDが違う」「保存されていない」「能力の根拠がない」「実行状態やrequestが違う」に分けます。機能名をモデル名に足して解決しようとせず、model identityの確認とendpointの実装確認を別のチェックにします。

1. 同じendpoint、同じmodel文字列、同じ時刻で4つのレスポンスを保存する。
2. digestが一致しない場合は、保存済み・実行中・client-visible IDの経路を分けて直す。
3. capabilitiesが一致しても、request schema・client SDK・endpointの対応を別に確認する。
4. 最後に短い最小リクエストを一つだけ実行し、症状がID・能力・負荷のどこに残るか記録する。

• Ollama Structured Outputs - formatとJSON Schemaの実装へ進む
• Ollama Responses API - /v1/responsesの入力・tools・streamを確認する
• RAG・埋め込みの評価 - model確認後の検索・引用品質を別に評価する

診断ログを安全に残し、localとcloudを混同しない

再現できる診断にするには、秘密情報や実文書を残さず、endpoint、model ID、digest、capabilities、実行状態、client、エラーのstatusだけを記録します。Ollama公式API Introductionのlocal base URLと、Cloud docsのcloud経路を分け、localhostで見たmodel identityをそのままollama.com/apiの認証済みmodel identityとみなさないでください。

$evidence = [ordered]@{
  checked_at = (Get-Date).ToString("o")
  endpoint = "http://localhost:11434"
  openai_model_id = "ID_FROM_V1_MODELS"
  saved_model = "NAME_FROM_API_TAGS"
  digest = "DIGEST_FROM_API_TAGS_OR_PS"
  capabilities = @("RETURNED_VALUES_ONLY")
  client = "PowerShell / Python / JavaScript / app name"
  note = "No prompt, API key, cookie, or private document"
}
$evidence | ConvertTo-Json -Depth 5

• API key、cookie、実文書、private promptを診断ログへ入れない。
• local endpoint、proxy、OLLAMA_HOST、cloud model suffix、直接cloud APIを分けて記録する。
• digestとmodel IDを残し、後で同じ名前のtagを同一モデルと決めつけない。
• 環境変数や設定を変えたらOllamaを再起動し、同じ4 endpointを再取得する。
• 未検証のモデル能力、速度、品質、privacyを記事や運用記録で断定しない。

このページの確認はlocalhostの読み取り中心です。OllamaをLANへ公開したり、cloud APIを呼び出したり、API keyを取得したりする必要はありません。外部通信・料金・組織のsecret管理が関係する場合は、認証と利用条件を別に確認してください。

• Ollama API Introduction公式docs - local /apiとcloud /apiのbase URLを分ける
• Ollama Cloud公式docs - signin・cloud model・offloadの境界を見る
• ローカルLLMの安全性 - ログ・保存・権限・外部送信を確認する