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確認後の検索・引用品質を別に評価する

保存済みモデルがあるのにollama showが間欠的にnot foundになる場合

同じ保存済みの正確なnameとtagを指定しているのに、ollama show MODELが時々model not foundを返し、同じコマンドの再実行では通る場合、clientへ渡したmodel IDの不一致だけとは限りません。Ollamaのissue #18447は、保存済み名を指定したollama showが間欠的に失敗する例を報告し、修正PR #18438へ結び付けています。

PRの説明では、getExistingNameがmanifestからmodel名の各部分をcase-insensitiveに照合するとき、無関係なmanifestからcase表記を拾ってしまう問題が特定されました。3,000超のmanifestがある状況で、別model側のQ4_K_Mのようなtagが照合可能な例が挙げられ、Go mapのiteration orderにより結果が変わって、再試行だけ通ることがありました。これはissueとmaintainerの説明にある特定のserver-side lookup bugであり、大きなmodel libraryすべての故障を意味しません。

1. ollama --version、ollama ls、失敗した正確なcommandとmodel name:tagを記録し、secretやpromptは記録へ含めない。
2. 同じ保存一覧名をollama showへ渡したとき、初回と再試行の結果が変わるか確認する。tagのcaseを変えて直そうとせず、再現条件として記録する。
3. 保存済みモデルの削除、全件再pull、OLLAMA_MODELSの移動を、この一つのエラーだけを根拠に最初の対処として行わない。
4. 2026-09-28の公式release一覧ではv0.40.0がpre-release、v0.34.4がLatest stableで、v0.34.4の変更履歴に大きなlocal libraryでの間欠的なmodel not found修正が記載されています。これはissue #18447とPR #18438で説明されたlookup不具合に対応する配布状況であり、特定のWindows環境での動作試験を意味しません。
5. 利用するstable版を更新した後は、ollama --versionと同じmodel name:tagを記録し、同じ読み取りcommandを再実行して結果を比較します。症状が続く場合は、別server、tag、保存一覧との不一致も引き続き確認します。

PRとissueにはWindows・GPU・Ollama versionの再現条件が記載されていません。Windows固有、全ユーザー共通、ある特定の過去versionだけの不具合とは断定せず、issueが示す症状とupstreamの修正配布状態に範囲を限定します。

• Ollama issue #18447 - 保存済みmodel名でも間欠的にnot foundとなる報告を見る
• Ollama PR #18438 - model name lookupの原因とmerged fixを確認する
• Ollama v0.34.4 release notes - Latest stableに含まれた修正を確認する
• Ollama Releases - Latest stableとpre-releaseを再確認する

診断ログを安全に残し、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の安全性 - ログ・保存・権限・外部送信を確認する