画像や書類を読めるローカルモデルの選び方:できること・難しいことの見極め

先に判断の目安を表で

下の表は、確認の観点と見方をまとめた編集上の整理です。数値の合格ラインは、手元で試すときの自分用の目安として使ってください。

• 画像入力に対応か、確認方法：実行環境の能力表示、または画像を渡して反応を見る、要注意のサイン：名前に「VL」とあっても、変換版や設定次第で画像が無視されることがある
• メモリ、確認方法：画像を渡した瞬間の使用量を監視、要注意のサイン：画像1枚でメモリが急増、処理が止まる
• 文字の読み取り、確認方法：手順4の課題A〜C、要注意のサイン：数字や固有名詞の取り違え
• 構造の理解、確認方法：表・レイアウトの課題D〜F、要注意のサイン：行や列のずれ、存在しない項目の追加
• 判断を伴う読み取り、確認方法：課題G〜J、要注意のサイン：自信ありげな誤答

画像入力に対応しているかを確認する

Ollamaの場合

Ollamaの公式ドキュメントでは、画像入力はCLIなら ollama run にモデル名、画像ファイルのパス、質問文を続けて渡す形で使えます(Ollama Vision)。REST APIでは画像をbase64文字列にして images フィールドに入れる必要があり、公式のPython・JavaScriptのSDKはファイルパスを直接渡せると記載されています。

対応しているかどうかは、/api/show の応答にある capabilities(対応機能の一覧)で確認できます。ドキュメントの例では completion、thinking、vision が並びます(Show model details)。

curl http://localhost:11434/api/show -d '{"model": "使いたいモデル名"}'

返ってきたJSONの capabilities に vision があれば、画像入力に対応するモデルです(Show model details - Ollama)。なければ、画像を渡しても読んでもらえない前提で選び直します。

LM Studioの場合

LM Studioの0.3.31のリリースノートによると、画像入力に対応したモデルを読み込んでいるときは、チャット欄に画像を貼り付けられます。画像は既定で長辺2048pxまでに縮小され、Settings > Chat > Image Inputs で上限を変えられます(2025年11月4日公開の記事。画面の名称はバージョンで変わる可能性があります)(LM Studio 0.3.31)。開発者向けのドキュメントでは、画像の形式はJPEG、PNG、WebPと書かれています(Image Input)。

判別の実務としては、モデルを読み込んだあとに画像を貼れるかを見ます。貼れないなら、そのモデルは画像入力として使えていません。LM Studioの資料では、画像入力にはVLMが必要と説明されています(Image Input)。

Hugging Faceのモデルを直接動かす場合

Transformersでは、画像と文章を受けるモデルを image-text-to-text というタスクで扱います。モデル検索でこのタスクに絞ると候補を探せます。

メモリは「重み+画像分」で見積もる

画像を使うとき、メモリは大まかに次の合計で増えます。これは仕組みから整理した見方で、実際の量はモデルと実装ごとに違います。

• モデル本体の重み(量子化すると小さくなります)
• 画像を処理する部分の重み
• 画像が変換された「画像トークン」の分だけ長くなる入力(会話の記憶領域も増えます)

見落としやすいのは3つ目です。Hugging Faceの資料には、Qwen3-VLやQwen3.5などの解像度可変モデルは既定の最長辺が約16メガピクセルで、1枚で1万を超える画像トークンが出て、一般向けGPUでは処理が止まったりメモリ不足になったりしうる、と警告があります。対策として、min_pixels と max_pixels で上限を決める例が載っています(Transformers: Image-text-to-text)。

from transformers import AutoProcessor

processor = AutoProcessor.from_pretrained(
    "Qwen/Qwen3-VL-4B-Instruct",
    min_pixels=224 * 224,
    max_pixels=1024 * 1024,
)

同じ資料には、int8量子化で重みのメモリを最大約75%減らせる一方、処理が遅くなる場合があるとも書かれています(Transformers: Image-text-to-text)。小さな実行環境に載せるときは、量子化と画像サイズの上限の両方を調整します。

試し方は単純です。①文章だけの質問でメモリ使用量を記録する、②同じモデルで画像を1枚渡して再度記録する、③画像の解像度を下げて差を見る。OSのタスクマネージャーなどで十分です。LM Studioなら、画像の上限を2048pxから1024pxなどに下げて比べます。

自分で試す画像課題10問

以下の課題は、画像入力モデルの限界を見るための編集上の案です。画像は説明用の例として自分で作ってください。実際の請求書や身分証は使わず、架空の名前・金額に置き換えた画像で試します。

• A 大きな活字、用意する画像：架空の会社名と金額だけを大きく書いた画像、依頼文の例：「画像内の文字をそのまま書き出してください」、見るポイント：基準。ここで失敗するなら以降は望み薄
• B 小さな文字、用意する画像：Aと同じ内容を小さく縮小したもの、依頼文の例：同上、見るポイント：解像度に対する弱さ
• C 斜め・影つき、用意する画像：スマホで斜めに撮った紙の写真、依頼文の例：同上、見るポイント：撮影条件への耐性
• D 単純な表、用意する画像：3列×5行の架空の表、依頼文の例：「表をMarkdownの表にしてください」、見るポイント：行列のずれ
• E 結合セルのある表、用意する画像：見出しが結合された表、依頼文の例：同上。「読み取れない箇所は『不明』と書く」と追記、見るポイント：無理な補完
• F 2段組の文書、用意する画像：2段組の架空のチラシ、依頼文の例：「読む順番どおりに文章を書き出してください」、見るポイント：読み順の乱れ
• G 手書き、用意する画像：自分の手書きメモ(架空の内容)、依頼文の例：「読めた文字を書き出し、自信のない文字に?を付けてください」、見るポイント：自己申告の正確さ
• H グラフ、用意する画像：棒グラフ(値が分かるもの)、依頼文の例：「各棒のおおよその値を答えてください」、見るポイント：数値の読み取り
• I 計算を伴う、用意する画像：数行の明細と合計欄、依頼文の例：「明細の合計は合計欄と合っていますか。計算過程も示してください」、見るポイント：計算ミス
• J 存在しない項目、用意する画像：日付欄がない書類、依頼文の例：「発行日を答えてください。書かれていなければそう答えてください」、見るポイント：作り話をするか

採点のしかた

各課題を2〜3回ずつ流し、次の4段階で記録します。

1. 正確(一字一句、数字が合う)
2. 軽微な誤り(読み順や空白だけ)
3. 内容の誤り(数字・固有名詞の取り違え)
4. 作り話(存在しないものを答える)

おすすめの切り分けは、4が1回でも出た用途には任せない、3が出る用途は人が原本と突き合わせる前提にする、という運用です。これは編集上の提案で、用途の重さに応じて厳しくしてください。AとJの両方を通ったモデルだけが、次のB〜Iに進む価値があります。

難しいことが出やすい場面

上の課題で崩れやすいのは、一般に次のような場面です。ただし、どこまで崩れるかはモデルごとに違うので、必ず手元で確かめてください。

• 小さな文字や低解像度:縮小の設定が強いと、読めたはずの文字が読めなくなります。精度が悪いときは、メモリを節約するための上限が原因かもしれません。画像サイズの上限を上げて再実行し、差が出るか見ます。
• 表の構造:文字は読めても、行と列の対応が崩れる場合があります。
• 数値の正確さ:金額や日付は、1桁の間違いが致命的です。読み取り結果は必ず原本と照合します。
• 「書かれていない」と言えるか:課題Jで作り話が出るモデルは、依頼文に「不明なら不明と書く」と加えても改善しないことがあります。

画像に氏名や住所などの個人情報が含まれるときは、本番の書類で試す前に説明用のデータで挙動を固めておくと安全です。ローカルで動かせば外部サービスに送らずに済みますが、結果を保存・共有する先の扱いは別に考える必要があります。

使い始める手順のまとめ

1. 候補モデルを2〜3個選び、capabilities または画像貼り付けで対応を確認する
2. 文章のみ・画像ありでメモリを記録する
3. 課題AとJで足切りする
4. 残ったモデルで課題B〜Iを流し、4段階で採点する
5. 画像サイズの上限を変えて、メモリと精度のどちらが先に限界になるかを見る

この記録が、自分のPCと自分の書類に対する、いちばん信頼できる選定資料になります。