VLMとは？LLM・SLMとの違いと選び方を解説

VLMは、画像や動画などの視覚情報を言語と結び付けて扱うAIモデルです。LLMは主に言語処理、SLMはモデル規模に着目した呼称であり、同じ分類軸ではありません。文字の正確な転記、画像の意味の解釈、複数資料に基づく回答など、目的に応じてVLM単体、OCRとLLM、マルチモーダルRAGを比較します。

ただし、実務で重要なのは「画像を入力できるからVLMを使う」と決めることではありません。正確に文字を転記したいのか、画像の意味を解釈したいのか、複数資料を横断して根拠付きで答えたいのかによって、VLM単体、OCR＋LLM、マルチモーダルRAGの比較対象は変わります。

本記事では、VLMとLLM・SLMの違いを実務上の比較軸で整理し、入力データ別の比較の始め方、導入手順、評価チェックリストを解説します。なお、VLM、LLM、SLMは、入力モダリティ、役割、モデル規模など異なる軸を示す言葉です。以下の比較は、各略語に排他的な定義を与えるものではなく、Mojiによる実務上の整理です。

「MLLM」や「LMM」は資料・製品ごとに対象範囲や正式名称が異なる場合があります。本記事では両者を独立した技術分類として定義せず、個別の論文・製品資料で正式名称、入力、出力、モデル構成を確認することを勧めます。

VLMとは

VLMは、視覚情報を言語と結び付けて扱うモデルです。代表的な研究では、画像と説明文のペアを用いて視覚と言語の対応を学習し、自然言語で指定した概念へ転移する方法が示されました。CLIPの原論文は、この画像・テキスト対応学習を代表する基礎研究です。

VLMには複数の構成があります。たとえば、視覚エンコーダで画像を特徴量に変換し、接続層を介して言語モデルと統合する構成が研究されています。視覚エンコーダとLLMを接続し、視覚指示に従う構成の一例として、LLaVAの原論文があります。VLMの構成や用途の分類については、VLMに関するサーベイ論文も参照してください。

VLMでできることの例

• 画像説明：商品画像、現場写真、図解の概要を文章化する
• 視覚質問応答：スクリーンショット、図表、地図、資料画像について質問に答える
• UI理解：画面内の要素や操作手順の候補を指摘する
• 文書理解：帳票・スキャンPDFの表、見出し、図、レイアウトを踏まえて内容を解釈する
• 動画理解：場面の説明、特定操作の発生箇所の探索、動画内容に関する質問応答を行う

実装サービスによって対応する入力形式、解像度、ページ数、動画処理方法、出力形式は異なります。たとえばGemini APIの公式ドキュメントでは、画像理解の用途として画像説明、分類、視覚質問応答が案内されています。動画についても、内容の説明、質問応答、特定タイムスタンプへの参照が案内されています。採用前には、利用予定のモデル・APIの現行仕様を確認してください。画像理解の公式ドキュメント、動画理解の公式ドキュメント

VLM・LLM・SLMを混同しないための整理

以下の表は、比較する軸をそろえるためのMojiによる実務上の整理です。VLMは主に視覚と言語の関係、LLMは言語処理、SLMはモデル規模に着目した呼称として扱います。厳密な用語定義や、相互の排他的な分類を定めるものではありません。

本記事でSLMはSmall Language Modelのみを指し、Specialized Language Model（特定領域向け言語モデル）の意味では扱いません。また、モデル規模だけでオンデバイス実行や閉域環境での運用可否が決まるわけではありません。必要なメモリ、レイテンシ、量子化、ハードウェア、セキュリティ要件を含めて確認します。

SLMに関するサーベイの一つは、100M〜5BパラメータのTransformerベース・デコーダ専用言語モデルを対象に、能力だけでなく推論レイテンシとメモリ使用量も評価しています。Small Language Modelsのサーベイ論文

MLLMを扱うサーベイには、テキストに加え、視覚、音声、動画、3D環境などの複数モダリティを統合・処理するモデルとして説明するものがあります。ただし、この説明を「LMM」表記を含むすべての資料へ一律に適用することはできません。MLLMに関するサーベイ論文

LLM、SLM、マルチモーダルAI全体の基本は、LLMとは、SLMとは、マルチモーダルAIとはも参照してください。

「VLMは画像生成AI」とは限らない

VLMは、画像を理解して言語で答える用途を中心に検討されるモデルです。画像を新規生成するモデルとは、目的と評価観点が異なります。画像を生成する必要がある場合は、画像生成モデルや、画像生成機能を併せ持つマルチモーダルモデルを別途検討します。

画像の生成と理解を同じ製品で扱える場合でも、入力理解の精度と画像生成の品質は分けて評価します。商品画像の説明が要件を満たしても、指定条件に沿う画像を生成できるかは、別の評価項目です。

VLMの仕組み：画像を言語モデルが扱える情報に接続する

構成はモデルにより異なりますが、視覚エンコーダとLLMを接続するタイプのVLMは、概ね次の流れで動きます。

1. 視覚エンコーダ：画像や動画フレームから特徴を抽出する
2. 接続層（プロジェクタなど）：視覚特徴を言語モデルが扱いやすい表現へ変換する
3. LLM／デコーダ：視覚情報とユーザー指示を踏まえ、回答、要約、構造化データなどを生成する

LLaVAは、視覚エンコーダとLLMを接続し、マルチモーダルな指示データでチューニングする構成を示した例です。Visual Instruction Tuning

ただし、この構成はVLMの唯一の実装方法ではありません。モデルごとの構成、対応モダリティ、学習方法を確認したうえで、対象タスクを評価する必要があります。文字の大きさ、画像の明るさ、帳票の傾き、表の複雑さ、根拠の分散状況といった入力条件も評価データに含めます。

入力別：VLM単体・OCR＋LLM・マルチモーダルRAGの選び方

以下はMojiによる設計上の目安です。一律の正解ではなく、対象モデル、入力品質、評価指標、許容誤差、データ量、求める応答時間、既存システムとの連携条件によって選定は変わります。PoCでは、候補構成を同じ評価データで比較してください。

1. VLM単体を比較候補に入れやすいケース

VLM単体は、「この写真の確認箇所を列挙して」「このUI画面の操作導線を説明して」のように、画像の意味を文章で解釈するタスクで比較候補になります。UIレビュー、商品画像の属性補完、現場写真の一次確認、図表の説明文作成などが該当します。

画像理解APIの仕様では、画像解像度が細かい文字や小さな要素の読み取りに影響する場合があります。たとえばGemini APIは、より高いメディア解像度では細かい文字や小さな詳細を読み取る能力が向上する一方、トークン使用量とレイテンシが増えると案内しています。重要な数値・型番・法的文言は、原画像の確認、ルール検証、必要に応じた人手確認を組み合わせる前提で評価します。Gemini APIの画像理解に関する技術情報

物体の位置・個数を継続的に判定する用途は、画像認識・物体検知AIも比較対象です。

2. OCR＋LLMを比較候補に入れやすいケース

OCR＋LLMは、「帳票から文字を抽出し、業務で使える項目へ整形・照合したい」場合に検討しやすい構成です。OCRでテキスト、座標、表、フォーム項目を取得し、LLMで正規化、分類、説明文作成、例外理由の整理を行います。

Google Cloud Document AIの公式ドキュメントでは、OCRによるテキスト・レイアウトの取得、フォームのキー・バリュー・ペアや表の抽出、文書種別の分類などが案内されています。Document AIの公式概要。帳票処理の詳細はAI OCR（画像文字認識）も参照してください。

選定の目安：抽出対象が「請求金額」「発行日」「注文番号」のように明確で、誤抽出を機械的に検知したい場合は、OCR結果に対して正規表現、桁数、金額範囲、取引先マスタ、合計一致などの検証ルールを重ねる構成を比較します。VLMを使う場合も、同じ検証ルールと人手確認の要否を評価対象に含めます。

3. マルチモーダルRAGを比較候補に入れやすいケース

マルチモーダルRAGは、図・表・ページレイアウトを含むPDF、スライド、マニュアル、動画などを検索対象にし、関連する根拠を取得してから回答を生成する構成です。RAGは、事前学習済みモデルのパラメトリックな記憶と、検索で参照する非パラメトリックな記憶を組み合わせる手法として提案されました。RAGの原論文

視覚的に複雑な文書では、テキスト化だけでは図表やレイアウトの手掛かりが失われる場合があります。VLMを用いて文書ページの画像を直接埋め込み、検索するColPaliは、その課題を扱う研究の一例です。ColPaliの原論文

社内規程、製品仕様書、提案資料などを横断し、「どのページの何を根拠にした回答か」まで示したい場合は、マルチモーダルRAG・VideoRAGの構成を比較対象に含めます。

VLMの業務活用例

UI・ソフトウェア品質確認

画面キャプチャを入力し、表示されている要素、想定ユーザー、操作導線の問題候補を整理します。VLMの回答はレビュー観点の洗い出しに使い、最終的な受け入れ判定は仕様書・テストケース・実機操作で行う運用を検討します。

帳票・文書の仕分けと確認

文書種別の分類、記載漏れ候補の抽出、表の内容の説明、例外帳票の人手確認への振り分けに活用できます。完全自動化の可否を判断する前に、「確認が必要な入力を担当者へ回す」運用も含めて、精度と業務負荷を評価します。

現場写真・設備点検の一次トリアージ

写真を説明し、確認すべき箇所の候補を提示する用途です。ただし、安全、品質保証、法令順守に関わる最終判定では、VLMの出力を決定根拠として単独利用せず、資格者・担当者の確認工程を残します。

動画マニュアル・研修動画の検索

動画を要約し、「設定画面を開く操作は何分何秒か」のような質問への回答候補を作ります。動画理解では、フレームサンプリングが評価結果に影響します。たとえばGemini APIの動画理解ガイドでは、静的処理の標準サンプリングは毎秒1フレームであり、速い動きや短い場面転換では詳細を失う可能性があると案内されています。実動画で、タイムスタンプの正確性と根拠となる場面を確認してください。Gemini APIの動画理解に関する技術情報

VLM導入を判断する5ステップ

以下はMojiによる提案です。モデル選定から始めるのではなく、失敗を定義してから構成を選びます。

1. 業務上の判断を一文で定義する：「画像を要約する」ではなく、「不備がある申請書を担当者へ振り分ける」のように、後続の行動まで定義します。
2. 入力を分類する：写真、スクリーンショット、スキャンPDF、テキストPDF、図表中心資料、動画に分け、解像度・傾き・文字サイズ・言語を記録します。
3. 許容できない失敗を列挙する：金額の誤読、根拠ページの取り違え、個人情報の不要な露出、危険箇所の見落としなどを具体化します。
4. 構成を比較する：同じ評価データで、VLM単体、OCR＋LLM、マルチモーダルRAGを比較します。比較対象はモデルだけでなく、前処理、プロンプト、検索方式、出力検証を含めます。
5. 小規模運用で監視する：人による確認結果を記録し、入力条件ごとの失敗傾向を分析してから対象範囲を広げます。

PoCで使える評価データセットのテンプレート

以下はMojiによる提案です。1件の正解・不正解だけで終わらせず、どの工程で問題が起きたかを診断できる列を用意します。

評価では、抽出精度だけでなく、根拠の正しさ、回答しない判断の妥当性、処理時間、1件当たりのコストも測ります。NISTのAI RMF Coreでは、TEVVのプロセス、テストセット・指標・ツールの詳細の文書化、導入環境に近い条件での評価、運用中の監視が示されています。NIST AI RMF Core

RAGの評価データを設計する際は、RAG評価データセットの作り方も参考にしてください。

導入前チェックリスト

• 対象業務における「正解」と「許容できない誤り」を定義したか
• 実運用に近い入力品質の評価データを用意したか
• VLM単体、OCR＋LLM、マルチモーダルRAGを同じ条件で比較したか
• 金額・ID・日付・固有名詞など、厳密性が必要な出力に検証ルールを設けたか
• 根拠ページ、画像領域、動画タイムスタンプを提示する要件を定義したか
• 低信頼度時の再試行・保留・人手確認のフローを設計したか
• 入力する画像・文書に含まれる個人情報、機密情報、著作物の取扱方針を確認したか
• モデル、前処理、プロンプト、評価データの変更時に再評価する運用を決めたか

まとめ

VLMは、画像・動画とテキストを組み合わせて扱えるため、UI、図表、帳票、現場写真、動画といった非テキスト情報を業務フローへ取り込む選択肢になります。

ただし、選定の軸は「VLMが使えるか」ではなく、視覚的な意味理解、正確な文字抽出、複数資料の根拠付き検索のどれが必要かです。単発の画像理解ではVLM、項目抽出ではOCRや検証ルールを組み合わせた構成、資料群の継続活用ではマルチモーダルRAGを含む検索構成を比較候補とし、実データと明確な評価基準で判断しましょう。