画像対応モデルに変えたら、今度は返事が空になった
この記事の概要
前回の記事では、Ollama 経由で使っていた Claude Code が、画像を開いた瞬間に止まった話を書きました。
この記事の内容は、2026年9月5日に私の環境で確認した結果です。モデルやOllama、Claude Codeの更新によって挙動が変わる可能性があります。
原因は、接続先の glm-5.3:cloud が画像入力に対応していなかったことです。
それなら、画像を読めるモデルへ変えれば解決するはずです。
ところが、画像対応の qwen3.5:cloud へ変更したつもりなのに、もう一度試すと同じエラーになりました。
結論から言うと、モデルの選び方ではなく、変更する設定欄を間違えていました。
画像対応モデルへ変えたのに直らなかった
私の ollama-cc では、Claude Code が使うモデルを次のように割り当てています。
Haiku枠 → gpt-oss:20b-cloud
Sonnet枠 → deepseek-v4-flash:cloud
Opus枠 → glm-5.3:cloud
Haiku、Sonnet、Opus は、ここでは Ollama のモデル名ではありません。Claude Code が「どの設定欄のモデルを使うか」を選ぶための名前です。
私は最初、Sonnet枠を画像対応の qwen3.5:cloud へ変えました。
Haiku枠 → gpt-oss:20b-cloud
Sonnet枠 → qwen3.5:cloud
Opus枠 → glm-5.3:cloud
これで画像を読めると思ったのですが、Claude Code はまだエラーになります。
実際に使われていたのはOpus枠だった
理由は単純でした。
そのセッションでメインに使っていたのは、Sonnet枠ではなく Opus枠だったからです。
Sonnet枠だけを画像対応モデルへ変えても、Opus枠には画像非対応の glm-5.3:cloud が残っています。Claude Code が画像を送った先も、この Opus枠でした。
流れにすると、こうなります。
Sonnet枠を画像対応モデルへ変更
↓
しかし、セッションはOpus枠を使用
↓
画像はglm-5.3:cloudへ送られる
↓
画像非対応なのでエラー
「画像対応モデルを設定した」というだけでは足りません。今のセッションが実際に使っている欄を変更する必要があります。
Opus枠を変えたら画像を読めた
私の環境では、Opus枠を qwen3.5:cloud へ変更しました。
Haiku枠 → gpt-oss:20b-cloud
Sonnet枠 → deepseek-v4-flash:cloud
Opus枠 → qwen3.5:cloud
前回紹介した ollama-cc を使うなら、今回の確認は次のように起動できます。
OLLAMA_CC_OPUS_MODEL=qwen3.5:cloud ollama-cc --model opus
この状態で新しいセッションを開き、Claude Code の Read ツールから PNG 画像を読ませました。今度はエラーにならず、画像内の文字も正しく読み取れました。
反対に、Haiku枠とSonnet枠だけを画像対応モデルへ変え、Opus枠に glm-5.3:cloud を残した状態では失敗しました。
これで、画像が実際にOpus枠へ送られていたことも確認できました。
なお、ここで qwen3.5:cloud を使ったのは、私の環境で動作を確認できたモデルだったからです。画像対応モデルの探し方や、ほかの候補については前回の記事にまとめています。
Opusを変えればよい、という話ではない
今回の答えが、いつでも「Opus枠を変える」になるわけではありません。
Sonnetを選んで起動しているならSonnet枠、Opusを選んでいるならOpus枠を変更します。大切なのは、自分のセッションがどの欄を使っているかです。
私が間違えたのは、モデル名だけを見て、実際に選ばれている欄を確認しなかったことでした。
モデルを一時的に差し替えて試すなら、次の2点をセットで確認したほうがよさそうです。
- 起動時にHaiku、Sonnet、Opusのどれを選んでいるか
- その欄に割り当てたOllamaモデルが画像入力に対応しているか
ここまでは、今から考えるとかなり当たり前の話です。
使っている欄に、使いたいモデルを設定する。それだけでした。
ところが、原因を調べるために行ったテストでは、もう一つ分かりにくい現象に遭いました。
画像は読めたのに、返事が空になった
Claude Code 側の問題なのか、接続先モデルの問題なのかを分けるため、Claude Code を通さず、Ollama のAnthropic互換APIへ直接画像を送りました。
テスト内容は単純です。画像には「RATE: 42% LEFT」とだけ書き、その文字を読んでもらいます。
ところが、qwen3.5:cloud から返ってきた答えは空でした。
エラーが出たわけではありません。処理は終わっているのに、回答本文だけがありません。
このとき、出力の上限を max_tokens: 500 にしていました。
max_tokens は、モデルが1回の応答で使える出力トークン数の上限です。短い文字を読むだけなら500もあれば十分だと思っていました。
回答を書く前の「考え中」で使い切っていた
返ってきたデータを詳しく見ると、text ブロックは空でしたが、thinking ブロックには内容が入っていました。
thinking は、モデルが最終的な回答を書く前に行う推論です。人間でいえば、答えを書く前の下書きや考え事に近いものです。この推論も max_tokens の上限に含まれます。
今回の qwen3.5:cloud は、「RATE: 42% LEFT」を読むだけの処理に長い推論を行い、最終回答を書く前に出力の上限へ到達していました。
つまり、何もしていなかったわけではありません。
画像を読む
↓
回答を書く前に長く考える
↓
使える量の上限に達する
↓
最終回答を書けず、空の返事になる
AIが黙っていたのではなく、考えているうちに回答欄を使い切っていたわけです。
thinkingを切ると返事が戻った
今回のような単純な文字読み取りに長い推論は必要ありません。
今回直接テストしたのは、Ollama のAnthropic互換 /v1/messages エンドポイントです。そのため、リクエストにAnthropic形式の次の設定を加えました。
"thinking": { "type": "disabled" }
Ollama ネイティブの /api/chat を使う場合は書き方が異なり、"think": false を指定します。
thinking を無効にすると、今度は約2秒で画像内の文字が返ってきました。
| 今回の条件 | 所要時間 | 結果 |
|---|---|---|
| thinkingあり | 48.8秒 | 回答本文が空 |
| thinkingなし | 2.1秒 | 画像内の文字を正しく回答 |
この結果だけを見ると、常に thinking を無効にしたくなります。
ただし、複雑な問題を解かせるときには推論が役立つ可能性があります。今回は単純な文字読み取りだったため、切っても問題がなかった、という結果です。
普通にClaude Codeを使うだけなら気にしなくてよい
ここは大事なところです。
私が確認した範囲では、Claude Code から普段どおり使ったときに、今回と同じ空回答は再現しませんでした。
thinking の設定が問題になったのは、原因を調べるためにOllamaへ直接リクエストを送り、出力を500に制限したときです。
そのため、この結果だけを理由に、Claude Code を使う人全員が設定を変更する必要はありません。
役に立つのは、Ollama の API を直接試していて、次のような状態になったときです。
- エラーは出ていない
- 処理には時間がかかっている
- それなのに回答本文が空
- 終了理由が
max_tokensになっている
この場合は、モデルが壊れたと考える前に、回答を書く前の推論で上限へ達していないか確認したほうがよさそうです。
まとめ
前回の記事から今回までの流れをまとめると、こうなります。
glm-5.3:cloudは画像に対応していなかった- 画像対応モデルへ変えたが、使っていない設定欄を変更していた
- 実際に使っているOpus枠を変えると、Claude Codeから画像を読めた
- 直接APIで小さく試すと、今度は推論が上限を使い切って回答が空になった
- 単純な画像読み取りでは、
thinkingを無効にすると速く回答できた
Claude Code で画像を使うだけなら、まず確認するのは「画像対応モデルを、実際に使っている欄へ設定したか」です。
APIを直接試して空の返事が来たときだけ、thinking と max_tokens の関係も確認する。
最初から全部を知っておく必要はありません。どの段階で失敗しているかを分けて考えると、それぞれの原因は意外と単純でした。