LMM（大規模マルチモーダルモデル）とは？LLMとの違いと評価時の注意点
スマートAI管理
社内の生成AI利用、把握・管理できていますか？
利用状況の可視化からリスク評価・承認管理・監査レポートまで、AIガバナンスをご支援します。
1992年生まれ鳥取県出身、高専にてソフトウェア開発を学ぶ⚙️ レシピアプリや通話アプリなどのMVP開発を担当し、合計1000万DLを突破。 その経験を経てMojiを創業、生成AIやその周辺システムの開発マネジメントを行っている。 趣味はキャンプと二郎、筋トレ（ベンチ100kg）。
AI分野のLMMとは
LMMとは、画像・音声・動画・テキストなど複数種類の情報を関連付けて扱う大規模マルチモーダルモデルです。LLMとの違い、用語の範囲、ベンチマークを業務評価へそのまま当てはめられない理由、複数情報の照合で起きる失敗を解説します。
LLMとの違いを一言でいえば、LMMでは複数種類の情報を関連付けて扱う課題が中心になる点です。ただし、LMM、MLLM、VLMといった略語の範囲は資料・研究分野ごとに重なります。LLMという名称だけから「テキストだけを入力するモデル」とは決めず、導入・評価の前に個別モデルの公式仕様で、入力形式、出力形式、時間情報の渡し方、ファイルサイズ・長さの制限を確認してください。
たとえばGemini 1.0の技術報告は、同モデル群を画像・音声・動画・テキストのデータで共同学習したものとして説明しています。一方で、この記述はGemini 1.0という個別モデル群の説明です。すべてのLMMが同じモダリティや入出力に対応することを意味しません。Gemini 1.0技術報告
画像とテキストを扱うモデルの構造、OCRやマルチモーダルRAGとの使い分けは、VLMとは？LLMとの違い・画像理解の仕組みと活用例で解説しています。本記事ではそれらの一般的な導入手順は繰り返さず、複数情報を同じ出来事の証拠として照合する評価に焦点を絞ります。
LMMのベンチマークの読み方
ベンチマークのスコアは、定められた入力、問題形式、採点方法での結果です。自社の動画、音声、帳票、ログを同時に扱う業務での正確性を、そのまま保証するものではありません。比較の前に、何を入力し、何を回答させ、どう採点した試験かを確認します。
ベンチマーク | 原論文で確認できる評価範囲 | 業務評価へ読み替えないポイント |
|---|---|---|
MMBench | 英語・中国語の選択式問題を用い、視覚と言語を扱うVLMの能力評価を目的とするベンチマークです。MMBench原論文 | 画像中心の結果から、音声の聞き分け、動画の時間的な対応、実データの欠損耐性までは判断しません。 |
MMMU | 大学レベルの知識と推論を要するマルチモーダル問題を対象に、図表、地図、表、楽譜、化学構造式などを含む問題を扱います。MMMU原論文 | 専門問題に対する正答率を、社内規程・現場映像・運用ログの照合精度と同一視しません。 |
MM-Vet | 6つの視覚・言語能力と、その組み合わせを対象に、複雑なマルチモーダル課題を評価します。MM-Vet原論文 | 統合能力を測る設計でも、自社の時刻ずれ、データ欠損、検索処理、承認ルールは別途評価が必要です。 |
判断基準：候補モデルを比較する際は、ベンチマーク名や総合順位より先に、①自社入力との一致、②回答形式の一致、③許容できない誤りが含まれているか、④採点が自動か人手か、を確認します。入力品質、評価指標、許容誤差によって結論は変わります。
複数情報の照合で起きる4つの失敗
以下は、研究で全モデルに共通すると保証された仕様ではなく、複数モダリティを使う業務システムを評価するためのMojiによる設計・評価の提案です。モデルの出力が自然でも、情報同士の対応が崩れていれば、業務上は誤答になり得ます。
- 時系列の同期がずれる
映像の時刻、音声の発話時刻、機器ログの記録時刻が一致していないのに、同一の事象として結び付けてしまう失敗です。回答を採点する前に、各入力の開始・終了時刻、タイムゾーン、サンプリング単位を固定します。 - 必要な入力が欠けている
映像はあるが音声がない、必要なページだけOCRに失敗した、ログの直近区間が取得できていない、といった状態です。入力不足なのに推測で完答していないかを、別の失敗として記録します。 - モダリティ間で矛盾する
画面表示と操作ログ、音声発言と議事録、現場映像とセンサーデータが食い違うケースです。もっともらしい一つの説明へ寄せず、「矛盾を検出して確認を求められるか」を評価対象にします。 - 回答の根拠位置が追えない
結論が正しく見えても、どの時刻、画像領域、文書ページ、ログ行を根拠にしたか分からなければ、人が再確認できません。根拠の提示が必要な業務では、結論だけで合格にしないことが重要です。
横断理解を確かめる評価ケース
次の例は架空の例です。特定の製品やモデルの性能を示すものではありません。映像・音声・ログを同時に扱う想定で、正答率だけでは見えにくい照合品質を確認するための最小ケースです。
入力 | 質問 | 期待する振る舞い | 不合格とする例 |
|---|---|---|---|
作業映像、作業者の音声、設備ログ | 「停止の直接要因と、確認できる根拠を示してください」 | 映像・音声・ログの該当時刻を分けて示し、根拠が足りなければ不明と回答する。 | ログ上の時刻差を無視し、映像だけから原因を断定する。 |
画面録画、操作ログ、手順書PDF | 「手順逸脱があったか確認してください」 | 画面上の操作とログを照合し、参照した手順書のページ・項目を示す。 | 手順書にない条件を補って、逸脱の有無を断定する。 |
会議音声、議事録、添付表 | 「決定事項と保留事項を分けてください」 | 発言と議事録・表の不一致を検出し、確認が必要な箇所を明示する。 | 矛盾する記載を一つに混ぜ、決定事項として出力する。 |
評価手順：同じ質問について、正常入力、時刻を意図的にずらした入力、一部を欠かせた入力、互いに矛盾させた入力の4条件を用意します。各条件で「正答」「不明と保留」「矛盾の指摘」「根拠位置」の4項目を人が判定すると、単一の正答率では見落とす失敗を分類できます。
誤りの原因を入力・同期・取得・モデルに分ける
出力が誤っていた場合、すぐにモデルの性能問題と結論付けないでください。原因を次の順番で切り分けると、修正対象を誤りにくくなります。
確認する層 | 確認事項 | 主な対応 |
|---|---|---|
入力 | 元ファイルに必要な音声・画像・ページ・ログ行が存在するか。変換時に欠落・文字化けがないか。 | 原本と抽出結果を並べ、欠損の発生地点を特定する。 |
同期 | 時刻の基準、タイムゾーン、開始点、フレーム・音声・ログの対応がそろっているか。 | 共通の時刻基準を定め、補正値と適用条件を記録する。 |
取得 | 検索・切り出し・要約処理を使う場合、正しい根拠がモデルへ渡る候補に入っていたか。 | 検索候補、採用した断片、モデルへ渡した最終入力を保存して比較する。 |
モデル | 必要な根拠が欠けず、正しく同期した状態で渡っているのに、誤認・矛盾見落とし・根拠なき断定が起きたか。 | プロンプト、モデル、パラメータ、回答形式を比較し、人の確認へ戻す条件を設ける。 |
この切り分けは、モデルの優劣を決めるためだけのものではありません。入力・同期・取得の問題を残したままモデルだけを変更しても、同種の失敗が再発するためです。評価設計全体の考え方は、AIの評価とは？評価指標や評価方法、その費用についても参照してください。
評価費用と記録で確認するチェックリスト
複数情報を扱う評価では、API利用料だけでなく、動画・音声・文書の前処理、アノテーション、根拠確認、人による判定、再試行の工数が費用になります。比較可能な結果を残すために、少なくとも次を記録します。以下はMojiによる記録項目の提案です。
- 対象ケース：業務上の質問、期待する出力、許容できない誤り、保留が許される条件
- 入力の状態：ファイル種別、対象区間、抽出方法、欠損の有無、時刻基準
- 実行条件：モデル名・バージョン、利用日、APIまたは実行環境、プロンプト、温度などの設定値
- 根拠の追跡：回答が参照した時刻、ページ、画像領域、ログ行。取得処理がある場合は候補と最終入力
- 判定結果：正答、誤答、保留、矛盾検出漏れ、根拠位置の誤りを分けた記録
- 費用：1件ごとの推論・前処理・人手確認・再試行を分けた実測値
最終チェック：「答えられたか」ではなく、①必要な入力がそろっていたか、②同じ時点の情報を照合したか、③矛盾時に止まれたか、④根拠を人が再確認できるか、⑤失敗の原因を次回に再現できる形で残したか、の5点で判定してください。
まとめ
LMMは、複数のモダリティを扱うモデルや研究を説明する際に使われる用語ですが、対応範囲は略語だけで確定しません。ベンチマークを読む際も、画像中心の評価結果を音声・動画・社内データの照合能力へ一般化しないことが大切です。
複数情報を業務で扱う場合は、時系列の同期、入力の欠損、モダリティ間の矛盾、根拠位置という4点を、実データに近い条件で別々に確認します。モデル、入力品質、評価指標、許容誤差によって結論は変わるため、回答の自然さや単一スコアだけで採否を決めず、失敗原因を追跡できる評価記録を残してください。