モデルは対応してるのに動かない？Ollama /api/tagsの罠とv0.34.1の修正

自作のエージェントやVS Code拡張機能から、Ollamaでホストしているモデルのcapabilities(対応機能)を/api/tagsで自動判定していないだろうか。

実はこのエンドポイント、つい最近まで ollama show や /api/show と食い違う結果を返すことがあった。ツール呼び出し対応のモデルなのに、連携先のクライアントからは「非対応」と誤判定される——そんな静かな不具合の中身と、v0.34.1での直し方を確認する。

Ollama v0.34.1(2026-09-14公開)で、/api/tagsが返すcapabilitiesが/api/showと食い違っていた不整合バグが修正された。原因はGGUFメタデータを取得する実装が2系統存在していたこと。修正後は/api/tagsの応答も大幅に高速化されている(大規模モデルライブラリでの計測で3.1秒→294ミリ秒)。TL;DR

最近、自分で作ったエージェントが「このモデルはツール呼び出し非対応」って判定して、勝手にfunction callingを使わない動作になったんです。でもOllamaで ollama show すると、ちゃんと tools って書いてあるんですよ…どういうことですか？

それ、まさにOllamaの/api/tagsにあった既知の不具合ですね。ollama show や /api/show とは違う結果を /api/tags だけが返していたんです。v0.34.1で直っているので、まずは仕組みから説明しますね。

この記事でできること

対象読者

【中級者向け】Ollamaで複数モデルをサーバーにホストし、/api/tagsや/api/showをスクリプト・エージェント・VS Code拡張機能などから呼び出して「このモデルはツール呼び出しに対応しているか」を自動判定している人を想定しています。単発でOllamaを個人PCで使っているだけなら影響は小さいですが、判定ロジックを組んでいる場合は要確認です。

確認環境・確認日

背景：なぜ2つのAPIが違う答えを返していたのか

Ollamaはモデルの情報を返すエンドポイントを複数持っている。

このうちGET /api/tagsは、モデルのcapabilities(tools=ツール呼び出し対応、thinking=思考プロセス対応、completion=通常の補完対応など)も含めて一覧を返す。GGUF形式のモデルファイルからこのcapabilitiesを含むメタデータを取り出す処理には計算コストがかかるため、Ollama内部では複数のキャッシュの仕組みが並行して育っていた。その結果、capabilitiesを判定する実装が実質的に2系統存在し、モデルによって/api/show系と/api/tags系で異なる結果を返す状態になっていた。

何が起きていたか：deepseek-r1でtools機能が見落とされる

この不整合は2026年6月30日に公式GitHubへ報告されている(Issue #16969)。報告環境はOllama 0.30.11、Windows 11、対象モデルはdeepseek-r1:32bだった。Issueに記載された再現結果は次の通り。

ollama show deepseek-r1:32b
→ capabilities: completion, thinking, tools

POST /api/show { "model": "deepseek-r1:32b" }
→ capabilities: completion, thinking, tools

GET /api/tags
→ capabilities: completion, thinking   ← "tools" が含まれていない

Issue本文では、この食い違いが実際に「VS Code Language Model provider(GitHub Copilot Chat統合)のようなクライアントが、/api/tagsだけを見てモデルはツール呼び出し非対応だと誤認する」影響を引き起こしていたと報告されている。ツール呼び出し可能なモデルを使っているのに、連携先のクライアント側でその機能が黙って無効化される、という静かな不具合だった。

全体像：修正前後で何が変わったか

v0.34.1での修正：メタデータキャッシュの統一

修正はGitHub上のPR #17858(2026-09-10マージ)で行われた。PR本文では、修正前の状態を次のように説明している。

Loading GGUF metadata is an expensive operation. Two caches had evolved to mitigate this, and the two capability implementations produced inconsistent results for some models.

対応として、モデルファイル(blob)ごとにメタデータを1回だけ抽出し、OLLAMA_MODELSディレクトリ配下のmetadataフォルダに、ハッシュ値を名前にしたJSONファイルとしてキャッシュする方式へ変更された。/api/tagsはGGUFファイルを毎回読み直すのではなく、このキャッシュとモデルのマニフェスト情報から直接構築されるようになっている。これにより/api/tagsと/api/showが同じ情報源を参照するようになり、capabilitiesの食い違いが解消された。

パフォーマンスも大幅に改善

同じ修正の副産物として、/api/tagsの応答速度も改善している。公式リリースノートには次のように明記されている。

/api/tags is much faster on large model libraries (3.1 s → 294 ms cold in testing)

毎回GGUFファイルを読み直していた処理がキャッシュ参照に置き換わったことが、この高速化の直接の理由。多数のモデルをホストし/api/tagsを頻繁に呼び出す運用ほど、恩恵が大きくなる。

なるほど、キャッシュを1本化したから、速くなった上に答えも揃うようになったんですね。自分の環境でも直ってるか確認したいんですが、どうすればいいですか？

バージョンと、capabilitiesが一致しているかを見比べればOKです。次の章にまとめますね。

確認の考え方

このセクションのコマンドは公式ドキュメント・公式Issueの記載に基づく例。自身の環境のOllamaバージョンやモデル構成によって出力内容は変わる。

1. バージョンを確認する

ollama --version

0.34.1以降であれば、今回の修正が適用されている。

2. capabilitiesが一致しているか比較する

/api/showと/api/tagsで同じモデルのcapabilitiesを見比べる。

curl -s http://localhost:11434/api/show -d '{"model": "<モデル名>"}' | grep -A5 capabilities

curl -s http://localhost:11434/api/tags | grep -A5 '"<モデル名>"'

両方に同じcapabilitiesの一覧(toolsを含むかどうかなど)が出ていれば、/api/tagsだけがツール呼び出し対応を見落とす状態は解消されている。

3. エージェント側の判定ロジックを見直す

/api/tagsが信頼できなかった時期に、/api/showとの二重照合を組み込んだ設計にしている場合は、v0.34.1以降であれば/api/tags単独の判定に簡略化できる可能性がある。ただし判定ロジックを変更する際は、実際に使うモデルで挙動を確認してから反映すること。

応用：全モデルの整合性をまとめてチェックする

モデル数が多いサーバーでは、1つずつollama showと/api/tagsを見比べるのは手間だ。/api/tagsが返す一覧をそのまま使い、モデルごとに/api/showの結果と突き合わせるスクリプト例(jqが必要)。

#!/bin/bash
# usage: bash check_capabilities.sh
for name in $(curl -s http://localhost:11434/api/tags | jq -r '.models[].name'); do
  tags_caps=$(curl -s http://localhost:11434/api/tags \
    | jq -r --arg n "$name" '.models[] | select(.name==$n) | .capabilities | sort | join(",")')
  show_caps=$(curl -s http://localhost:11434/api/show -d "{\"model\": \"$name\"}" \
    | jq -r '.capabilities | sort | join(",")')
  if [ "$tags_caps" != "$show_caps" ]; then
    echo "不一致: $name  tags=[$tags_caps]  show=[$show_caps]"
  fi
done
echo "確認完了"

ollama --versionが0.34.1以降であれば、通常は不一致が出力されないはず。何か出力された場合は、対象モデルをollama pullコマンドで再取得してメタデータキャッシュを作り直してから、もう一度実行する。このスクリプトはOllamaの公式API仕様(/api/tags・/api/showのレスポンス形式)に基づいて構成したもので、jqのインストールとcurlが使える環境であれば動作する。

注意点・制限事項

よくある誤解

「ドキュメントにcapabilitiesが載っていないから、このフィールド自体が無い」

誤り。docs.ollama.com/api/tagsのサンプルは簡略版であり、実際のレスポンスにはcapabilitiesが含まれる(Issue #16969の再現例で確認)。

「これは単なる速度改善で、機能面には関係ない」

誤り。高速化とcapabilitiesの不整合解消は、どちらも同じ「メタデータキャッシュの統一」という1つの修正から生まれている。速くなったのは結果で、本質的な変更は「情報源を1本化した」こと。

早見表

まとめ

参考にした公式情報

Release v0.34.1 · ollama/ollama

What's Changed MLX safetensors ollama create no longer experimental. GGUF model creation now requires using llama.cpp tooling for safetensor conversion and quantization. Improved MLX memory handl...

server: extract GGUF metadata and unify capabilities by dhiltgen · Pull Request #17858 · ollama/ollama

Loading GGUF metadata is an expensive operation. Two caches had evolved to mitigate this, and the two capability implementations produced inconsistent results for some models. This PR now extracts ...

/api/tags omits "tools" capability for deepseek-r1 while /api/show reports it correctly · Issue #16969 · ollama/ollama

What is the issue? What happened? deepseek-r1:32b reports different capabilities depending on the API endpoint. ollama show reports: completion thinking tools POST /api/show reports: completion thi...

List models - Ollama

Fetch a list of models and their details