ベストローカルビジョンモデル2026：Gemma 4・Qwen3-VL・LLaVA & Ollamaマルチモーダルセットアップ

基本情報

• VLMの機能： 画像＋テキスト入力 → テキスト出力。画像生成器ではなく、画像を*理解する*モデルです。
• Ollamaサポート： Gemma 4、Qwen3.8、Qwen3.5、Qwen3-VL、Llama 3.2 Vision、MiniCPM-V、LLaVA、Moondreamは公式Ollamaライブラリにあります。InternVL、PaliGemma 2、SmolVLMはコミュニティビルドが必要です。
• 最小の実用モデル： Moondream 2（1.8B、1.7GBダウンロード）、Qwen3-VL 2B（1.9GB）、Qwen3.5 0.8B（1.2〜1.3GB）。
• 最大の実用ローカルモデル： Qwen3.5 122B（81GB）は128GBのMac、Llama 3.2 Vision 90B（55GB）は96GB以上のMac（Apple M-Series）またはマルチGPU向け。Qwen3-VL 235Bは143GBが必要。
• 画像入力形式： JPEG、PNG、WebP。最大解像度はモデルによって異なります（通常1024×1024〜4096×4096）。
• 音声と動画： Gemma 4 E2B、E4B、12Bは音声入力にも対応。すべてのGemma 4サイズとQwen3.8は動画をフレームとして処理します。
• OCR精度： Qwen3.8 27B ≈ Qwen3-VL 8B ≈ Qwen3.5 9B > Gemma 4 > MiniCPM-V > LLaVA 1.6 13B > LLaVA 1.6 7B > Moondream 2。
• マルチモーダル = 低速： ビジョンモデルはLLMにビジョンエンコーダーを追加するため、同サイズのテキストのみモデルより〜30〜60%遅くなります。

ビジョン言語モデル（VLM）とは？

• 画像生成器との違い： Stable Diffusion、FLUX、DALL-E 3はテキストから画像を生成します。VLMは画像からテキストへのモデルで、画像を説明・分析・回答します。
• OCRツールとの違い： 従来のOCR（Tesseract）はパターン認識でテキストを抽出します。VLMはコンテキストを理解し、テーブルの意味を説明したり、グラフに関する質問に答えたりできます。
• ローカル実行の理由： プライベートドキュメント（医療記録・法的スキャン・財務諸表）、独自スクリーンショット、または画像をクラウドAPIに送信することにコンプライアンス上の懸念があるワークフロー。
• できないこと： 画像生成、スクリーンショット内のコード実行、インターネットアクセス。VLMは画像に見えるものに基づいてテキスト出力のみを生成します。

利用可能なローカルビジョンモデル — 比較表

参考例：請求書抽出の比較

マルチ画像サポート

• MiniCPM-Vは1プロンプトで最大4枚の画像を受け付け、Qwen3-VLは最大8枚に対応。LLaVAとMoondreamは1リクエストにつき1枚のみです。
• マルチ画像が重要な場面： 複数ページのPDFの全ページを送信して完全なドキュメント抽出、2つの商品写真を並べて比較、1つのプロンプトでビフォー・アフターのスクリーンショットを分析。

Ollamaセットアップ — ステップバイステップ

• ステップ1 — Ollamaをインストール： macOS・Linux・Windows用をollama.comからダウンロード。インストールは2分以内。
• ステップ2 — ビジョンモデルをダウンロード： 8GBカードにはollama pull gemma4:e4b（6.6〜9.5GBダウンロード）、OCRにはollama pull qwen3-vl:8b（6.2GB）、VRAMが少ない場合はollama pull moondream（1.8B、1.7GB）。
• ステップ3 — CLIで使用： ollama run gemma4:e4b "What is in this image? /path/to/photo.jpg" — 画像パスはプロンプト内に記述します。ollama runに--imageフラグはありません。
• ステップ4 — HTTP APIで使用： http://localhost:11434/api/generateにPOSTし、images配列にBase64エンコードされた画像を含める。formatフィールドにJSONスキーマを追加すると構造化出力を得られます。
• ステップ5 — Pythonの例： Base64エンコーディングでrequestsライブラリを使用 — 以下のコードブロックを参照。

import base64
import requests

def ask_vision_model(image_path: str, prompt: str, model: str = "gemma4:e4b") -> str:
    with open(image_path, "rb") as f:
        image_b64 = base64.b64encode(f.read()).decode("utf-8")

    response = requests.post(
        "http://localhost:11434/api/generate",
        json={
            "model": model,
            "prompt": prompt,
            "images": [image_b64],
            "stream": False,
        },
    )
    return response.json()["response"]

# 使用例
result = ask_vision_model("invoice.png", "この請求書からすべての行項目と合計金額を抽出してください。")
print(result)

ユースケース1：ドキュメントOCRと抽出

• うまく機能するもの： スキャンした請求書・PDFスクリーンショット・手書きのブロック体メモ・明確な境界線のあるテーブル・名刺。
• うまく機能しないもの： 手書きの草書体・150DPI未満のスキャン・高圧縮JPEG・重なり合うテキスト。
• OCRに最適なモデル： Qwen3-VL 8BとQwen3.5 9B（6〜8GBクラス）、Qwen3.8 27B（18GB、モデルカードによるとOmniDocBench 1.5で91.1）、混合ドキュメントタイプにはGemma 4。
• OCR向けプロンプトエンジニアリング： 「このドキュメントのすべてのテキストを改行を保持して正確に抽出してください。」または「この請求書の内容をJSONで返してください（フィールド：ベンダー、日付、行項目[]、合計）。」
• 従来のOCRとの比較： VLMは低速ですが意味的に強力です。クリーンなドキュメントの純粋なテキスト抽出にはTesseractが高速です。構造化データ抽出が必要な場合はVLMを使用。

ユースケース2：画像Q&Aと説明

• シーン説明： 「この写真には何がありますか？」— オブジェクト・人物・活動・設定・雰囲気。
• 商品カタログ化： プロンプトテンプレートで商品写真を処理：「この商品を説明してください：色・形・素材・状態。」クラウドAPIなしでECインベントリに有用。
• アクセシビリティ： 大規模に画像のaltテキストを生成。
• 最適なモデル： Gemma 4 12BまたはGemma 4 26B A4B（一般的な写真Q&A）。Qwen3.5 4BまたはLLaVA 1.6 7B（速度が精度より重要な大量処理）。
• 速度の考慮： 速度はモデル・GPU・説明の長さによって異なります — 数千枚のバッチを始める前に、自分のハードウェアで20枚程度のサンプルをベンチマークしてください。

ユースケース3：スクリーンショットとUI分析

• 開発者ワークフロー： エラーメッセージのスクリーンショットをモデルに送る：「このスクリーンショットの何が問題で、どう修正しますか？」
• バグレポート生成： 構造化プロンプトを使ってスクリーンショットから自動的にバグレポートの説明を生成。
• ダッシュボードモニタリング： モニタリングダッシュボードのスクリーンショットを分析して異常を検出。
• アクセシビリティテスト： UI変更前後のスクリーンショットを比較して視覚的アクセシビリティを確認。
• 最適なモデル： InternVL 2.5 8B（コミュニティビルド、UIに強い）、Gemma 4とQwen3-VL（公式Ollamaサポート、エージェントワークフロー向けのツール呼び出し対応）。

ユースケース4：グラフとチャートの読み取り

• 機能するもの： 軸ラベルの読み取り・傾向の特定・相対的なバーの高さの比較・明確なフォントのテーブル値の読み取り。
• 信頼性が低いもの： 連続グラフからの精密な数値抽出・ラベルなしの円グラフのパーセンテージ。
• プロンプト戦略： 「この折れ線グラフに示されている傾向を説明してください」は「2026年3月の正確な値は？」より効果的。
• グラフに最適なモデル： InternVL 2.5（強力なグラフ理解）、Gemma 4とQwen3-VL（明確にラベルされたグラフに良好）。
• 制限の注意： 2026年時点で、視覚的に複雑なグラフから精密な数値を確実に抽出できるローカルVLMはありません。

ユースケース5：動画フレーム分析

• フレーム抽出： ffmpeg -i video.mp4 -vf fps=1 frames/frame_%04d.jpg（1fpsで抽出）
• フレームごとの分析： 一貫したプロンプトで各フレームをビジョンモデルに送信（例：「このフレームで起きていることを1文で説明してください」）。
• クロスフレームのサマリー： すべてのフレーム説明を収集してテキストLLMにサマリープロンプトと共に渡す。
• ユースケース： セキュリティカメラレビュー（異常なアクティビティのフレームにフラグ）、講義録画分析（スライドごとのノート生成）、製造品質検査（欠陥のあるフレームにフラグ）。
• 動画フレームに最適なモデル： Gemma 4またはQwen3.8（品質 — どちらも動画をフレームとしてネイティブに受け付けます）、Qwen3.5 4BまたはLLaVA 1.6 7B（速度・高フレームスループット）。
• 速度の現実： 1フレーム/秒の抽出と1フレームあたり〜1〜3秒の推論では、10分の動画（600フレーム）の処理にモデルとGPUに応じて約10〜30分かかります。

import base64
import subprocess
import os
import requests

def extract_frames(video_path: str, output_dir: str, fps: int = 1) -> list[str]:
    os.makedirs(output_dir, exist_ok=True)
    subprocess.run([
        "ffmpeg", "-i", video_path,
        "-vf", f"fps={fps}",
        f"{output_dir}/frame_%04d.jpg",
        "-y"
    ], check=True)
    return sorted([
        os.path.join(output_dir, f)
        for f in os.listdir(output_dir)
        if f.endswith(".jpg")
    ])

def analyze_frame(image_path: str, model: str = "gemma4:e4b") -> str:
    with open(image_path, "rb") as f:
        image_b64 = base64.b64encode(f.read()).decode("utf-8")
    response = requests.post(
        "http://localhost:11434/api/generate",
        json={
            "model": model,
            "prompt": "Describe what is happening in this frame in one sentence.",
            "images": [image_b64],
            "stream": False,
        },
    )
    return response.json()["response"]

frames = extract_frames("lecture.mp4", "frames/", fps=1)
descriptions = [analyze_frame(f) for f in frames]
print("\n".join(f"[{i+1}s] {d}" for i, d in enumerate(descriptions)))

VRAMとパフォーマンスの現実

ローカルVLM vs GPT-5.5 Vision比較

• 構造化ドキュメント（請求書・フォーム）： 編集部の見立てであり、測定したベンチマークではありません。優れたローカルモデルは、きれいで形式が整ったドキュメントではGPT-5.5 Visionに近い結果を出します。出力を検証すれば本番利用にも十分です。
• 複雑なシーン・曖昧な画像： 珍しいコンテキスト、難しい照明、曖昧な内容の画像では、ローカルモデルはGPT-5.5 Visionに明確に劣ります（編集部の見立てで、測定値ではありません）。
• 手書き認識： ローカルモデルは特に草書体で著しく弱い。GPT-5.5 Visionは手書きを大幅に良く処理。
• グラフデータ抽出： 両方で信頼性が低いが、GPT-5.5は正確な数値でより精確。
• コスト： GPT-5.5 Vision：1枚あたり$0.01〜$0.03 vs ローカルは$0。月10,000枚 = $100〜$300の節約。
• プライバシー： ローカルモデルは既定でデバイス上で画像を処理する — クラウド機能や接続型ツールを有効にしない限り、画像はクラウドAPIに送信されない。GPT-5.5は画像をOpenAIサーバーに送信。
• 速度： ローカルモデル10〜20トークン/秒 vs GPT-5.5 30〜80トークン/秒、ただしローカルはバッチ処理でネットワーク遅延なし。

LLaVA詳細解説

• アーキテクチャ： CLIP ViT-L/14ビジョンエンコーダー + Llama-2またはMistralテキストデコーダー、シンプルな線形投影層で接続。
• LLaVA 1.5 vs 1.6： バージョン1.6（2024年初頭）は動的パッチングによる高解像度入力サポートを追加し、OCRとグラフ読み取り精度を大幅に向上。
• トレーニング： LLaVA-Instruct-150Kでインストラクションチューニング — 画像キャプションと物体検出アノテーションから生成された視覚的会話データセット。
• 強み： 幅広い一般知識・充実したドキュメント・大きなコミュニティ・豊富なOllama統合。
• 弱み： Qwen3-VLやMiniCPM-VよりOCRが弱く、InternVL 2.5よりUI分析が劣り、Gemma 4とQwen3ファミリーに全体的に上回られている。
• それでも推奨される理由： すべてのローカルVLMの中で最大のコミュニティ・最多のチュートリアル・最多のプロンプト例を持つ。問題が発生した時にサポートが見つけやすい。
• 詳細レビュー： LLaVAレビュー(2026) — Apache-2.0とベースモデルライセンスの微妙な違い、実際のOllamaコマンドを含むPromptQuorumの専用レビュー。

Qwen3-VL・Qwen3.5・Qwen3.8 — 最高の多言語OCR性能

• アーキテクチャ： 4096×4096までの動的解像度サポート — LLaVA 1.6（672×672）やLlama 3.2 Vision（1120×1120）より大幅に高い。高DPIスキャンをダウンサンプリングなしで読み取り可能。
• 多言語OCR： 中国語・日本語・韓国語・英語のOCRでクラス最高。大規模な多言語ドキュメントコーパスを含むトレーニングデータが、非英語ドキュメントでLLaVAやLlama 3.2 Visionに対して大きな優位性をもたらす。
• どのサイズを選ぶか： Qwen3-VL 8Bは6.2GBのダウンロードで8GBカード向け。Qwen3.5 9Bは6.6〜7.6GB。Qwen3.8 27Bは18GBで24GBカードが必要。Qwen3-VL 32Bは21GB。OllamaにQwen3-VLの72Bバリアントはありません。
• Qwen3-VL 4B： 3.3GBのダウンロード（256Kコンテキスト）。VRAM約4〜6GBのカード向けで、2B（1.9GB）と8B（6.2GB）の中間にあたります。
• Ollamaインストール： ollama pull qwen3-vl:8b、ollama pull qwen3.5:9b、またはollama pull qwen3.8 — いずれもOllamaモデルライブラリにあります。
• マルチ画像サポート： 1リクエストで最大8枚 — この比較で最高のマルチ画像容量。
• モデルページ： OllamaのQwen3-VL、Hugging FaceのQwen3.8-27B

ビジョンモデルの選び方

• 4GB未満のVRAM： Qwen3.5 2B（2.7〜3.1GB）、Qwen3-VL 2B（1.9GB）、Moondream 2（1.7GB）が実用的な選択肢。PaliGemma 2（3B）とSmolVLM（2.2B）はコミュニティビルドの代替です。密なテキストOCRにはいずれも不向き。
• 6〜8GBのVRAM： 一般的な写真Q&AにはGemma 4 E4B、ドキュメントOCRと多言語テキストにはQwen3-VL 8BまたはQwen3.5 9B、コミュニティサポートが重要ならLLaVA 1.6 7B。
• 12〜16GBのVRAM： Gemma 4 12B（7.7〜8.0GBダウンロード）が明確な推奨 — サイズの割に高いビジョンスコア、音声入力、256Kコンテキストウィンドウを備えます。LLaVA 1.6 13BとInternVL 2.5 8B（UIとコードのスクリーンショット）も収まります。
• 24GBのVRAM： Gemma 4 26B A4B（16〜19GB）、Gemma 4 31B（19〜20GB）、Qwen3.8 27B（18GB）、Qwen3-VL 32B（21GB） — クラウド級のビジョン品質に最も近いローカルオプション。
• 96GB以上のユニファイドメモリ（Apple M-Max/Ultra、マルチGPU）： 最大級のローカルモデルとしてQwen3.5 122B（81GB、128GBのMacが必要）またはLlama 3.2 Vision 90B（55GB）。どちらも高メモリのハードウェアが必要で、24GBクラスのモデルよりトークンあたりが低速です。
• 数値は必ず検証： モデルに関わらず、グラフやテーブルから抽出した数値は必ずソースデータと照合。ローカルVLMは視覚的グラフから精密な数値を幻覚することがあります。

よくある質問

参考資料

• Hugging FaceのGemma 4モデルカード — GoogleのApache 2.0ライセンス、サイズ別の対応モダリティ、MMMU Proの結果。
• OllamaのGemma 4 — タグ、ダウンロードサイズ、コンテキストウィンドウ。
• Hugging FaceのQwen3.8-27B — Apache 2.0ライセンス、262Kコンテキスト、OmniDocBench 1.5の結果。
• OllamaのQwen3.5とOllamaのQwen3-VL — サイズとダウンロードサイズ。
• OllamaのLlama 3.2 VisionとOllama issue #16547 — リストと、報告されているmllamaロードエラー。
• LLaVAプロジェクトページ — LLaVA 1.5・1.6モデルカード、アーキテクチャの詳細、トレーニングデータセットの説明。
• OllamaのMiniCPM-VとHugging FaceのOpenBMB — モデルカードとOCRベンチマーク。
• OllamaのMoondreamとGitHubのMoondream — モデルダウンロードと推論スクリプト。
• Hugging FaceのInternVL 2.5 — OpenGVLabモデルカード、ドキュメントとUIタスクのベンチマーク。
• Ollamaドキュメント — ビジョンモデルサポート、構造化出力、APIリファレンス、モデルライブラリ。
• Hugging FaceのPaliGemma 2 — GoogleのPaliGemma 2 3Bモデルカード。
• Hugging FaceのSmolVLM — HuggingFaceのSmolVLMモデルカードと推論手順。
• llama.cppのマルチモーダル文書 — 対応ビジョンモデルとllama-serverの使い方。
• vLLMの対応モデル — vLLMで提供できるマルチモーダルアーキテクチャ。
• OllamaのGemma 4タグ — q4_K_M、q8_0、bf16、QAT、MLXビルドのサイズ。

関連記事

• Ollamaでビジョンをサポートするモデルは？ — 画像を受け付けるOllamaライブラリのモデルをVRAM仕様付きで簡潔に回答。
• Ollamaビジョンモデル(2026) — Ollama経由でビジョンモデルを実行するための実践ガイド。実際のCLI/API構文と、ライブラリに実際にあるモデルを解説。
• カメラとドローンにおけるVLM 2026 -- デスクトップVLMの基礎はこちら。組み込みカメラ・ドローン展開についてはこのエッジ向けガイドを参照。
• ローカルマルチモーダルAIパイプライン2026 — ビジョンモデルとSTT・TTSを組み合わせた完全なローカルマルチモーダルスタック。
• ローカル音声認識2026：Whisper.cpp vs faster-whisper — ビジョン出力を補完する音声入力の追加。
• ローカルTTSと音声クローニング2026 — VLMの応答を読み上げる音声出力の追加。
• Ollamaのインストール — 前提条件：OllamaのセットアップとConfiguration。
• ローカルLLMハードウェアガイド — ビジョンモデル推論のVRAMとRAM要件。