マルチモーダルLLMとは｜画像・音声を扱う仕組みと業務での使いどころ

会議のホワイトボードを撮った写真、UIのスクリーンショット、外出先で録った音声メモ。仕事の現場には、テキスト化されていない情報がたくさんあります。マルチモーダルLLMは、こうした画像や音声をそのままLLMに渡し、テキストと同じように理解させる技術です。この記事では、マルチモーダルLLMがなぜ必要とされているのか、仕組みをどう捉えればよいか、画像・音声の入力を業務でどう使えるか、そしてコストと精度の面で過信してはいけない点までを整理します。出力側の画像生成については扱わず、あくまで画像・音声を「入力として理解する」側に焦点を当てます。

なぜマルチモーダルが必要なのか#

業務で扱う情報の多くは、最初からきれいなテキストになっているわけではありません。紙の書類をスキャンした画像、取引先から送られてきたスクリーンショット、会議や現場で録った音声メモ。これらを使ってLLMに何か作業を頼みたいとき、従来は次のような手間が必要でした。

• 画像は、まずOCR(光学文字認識)で文字を抽出してからLLMに渡す
• 音声は、まず音声認識(ASR)で文字起こしをしてからLLMに渡す
• 抽出・文字起こしの精度が悪いと、その誤りがそのままLLMの入力に混入する

マルチモーダルLLMは、この前処理の手間を省き、画像や音声を直接LLMに渡せるようにします。単に文字を抜き出すだけでなく、「この図表で伸びているのはどの項目か」「このスクリーンショットのUIで分かりにくい部分はどこか」「この音声メモで決まった宿題は何か」といった、文脈を理解したうえでの受け答えができる点が、単純なOCR・音声認識との違いです。

仕組みの概念整理:画像・音声をどう「読む」か#

LLMは本来、テキストをトークンという単位に区切って処理します(トークンとコンテキストウィンドウの詳しい仕組みは

で扱っています)。マルチモーダルLLMは、画像や音声もトークンや、それに準じる数値表現(埋め込み)に変換したうえで、テキストのトークン列と同じTransformerの中で一緒に処理します。「画像や音声を、テキストと共通の土俵に乗せてから読む」というのが基本的な考え方です。

ネイティブ型とパイプライン型#

画像や音声をモデルに取り込む設計には、大きく2つの方向性があります。特定の製品がどちらの方式かは変わりうるため断定は避けますが、考え方として押さえておくと理解の助けになります。

1つ目は、画像や音声も含めて最初から一体で学習するネイティブ型です。テキスト・画像・音声のトークンを同じ表現空間に置いて訓練することで、モダリティをまたいだ文脈理解がしやすくなるとされています。

2つ目は、画像・音声を専用のエンコーダで処理してから、その結果をLLMに橋渡しするパイプライン型です。画像処理に強いエンコーダとテキストに強いLLMをそれぞれ流用しやすい一方、エンコーダとLLMの橋渡しの部分で情報が失われやすい、という指摘もあります。

どちらの方式でも、利用者から見た使い勝手(画像や音声のファイルをAPIやチャットにそのまま渡せる)は大きく変わりません。実務では方式の違いを気にするより、次に説明する入力形態ごとの得意・不得意を押さえるほうが役立ちます。

画像入力の使いどころ#

画像入力が業務で効きやすいのは、次のような場面です。

• OCR代替:紙の書類やスキャン画像から、必要な項目だけを指定して抽出する。単純な文字起こしに加えて、「宛名と金額だけ拾って」といった条件付き抽出がしやすい
• グラフ・図表の読み取り:資料に貼られたグラフのおおまかな傾向や、表の構造を説明させる
• UIレビュー:アプリやWebサイトのスクリーンショットを見せて、分かりにくい導線や表記ゆれの指摘をもらう

画像はどのようにコストへ跳ね返るか#

画像はテキストと違い、送るだけでまとまったトークン数を消費します。方式は提供元によって異なりますが、代表的な考え方は次の2つです。

• タイル分割方式:画像を一定サイズの正方形タイルに分割し、タイルの枚数に応じてトークンが加算される。低解像度モードでは画像サイズによらず固定の低コストで扱える一方、高解像度モードでは画像を縮小してからタイルに分けて計算する
• パッチ分割方式:画像を一定ピクセルの正方形パッチ(視覚トークン)に区切り、縦横のパッチ数に応じてトークンが増える。モデルごとに扱える最大解像度(長辺の上限)が決まっており、それを超える画像は自動的に縮小されてから処理される

あわせて読みたい

トークンとは/コンテキストウィンドウとは｜LLMの入出力を測る単位と上限の仕組み

音声入力の使いどころ#

音声入力が業務で効きやすいのは、次のような場面です。

• 音声メモの要約:外出先や移動中に録った音声メモから、要点や次のアクションを抜き出す
• 発話理解:単純な文字起こしにとどまらず、話者の意図や感情のニュアンスを踏まえた要約・分類を頼む

音声も長くなるほどコンテキストを消費する#

音声は、長さに比例してトークン数が増えていきます。たとえばGoogleのGemini APIの公式ドキュメントでは、音声は1秒あたり32トークンに換算され、1分間の音声で1,920トークンになる、と説明されています。1時間の音声であれば10万トークンを優に超える計算になり、テキストの会議メモに比べて桁違いにコンテキストを消費しやすい点は覚えておいて損はありません。コンテキストウィンドウそのものの仕組みは前述のとおり別記事に譲りますが、「長い音声をそのまま丸ごと渡すと、それだけで上限に近づく」という感覚は音声入力を扱ううえで重要です。長時間の録音は、あらかじめ話題の区切りで分割してから渡す、あるいは要約を段階的に重ねるといった前処理が有効です。

精度の限界:過信しないための注意点#

マルチモーダルLLMは便利な反面、テキストだけのやり取りより誤りに気づきにくいという弱点があります。過信しないために、次の点を押さえておいてください。

• 細かい文字・複雑な表・グラフの数値読み取りミス:Anthropicの公式ドキュメントは、低品質・回転・非常に小さい(200ピクセル未満)画像で誤認識(ハルシネーション)が起きうると明記しています。OpenAIの公式ドキュメントも、グラフの色やスタイルの違いを読み分けるのが苦手な場合があるとしています。数値をそのまま業務判断に使う場合は、必ず元の書類や別の方法で裏取りしてください
• 長時間音声での聞き漏らし:長い音声を一度に渡すほど、途中の細部が抜け落ちるリスクが増えます。重要な決定事項が含まれる部分は、区切って渡す・該当箇所だけ再確認させるといった工夫が有効です
• 画像内の計算間違い:画像から読み取った数値をもとに計算させると、読み取りの誤差がそのまま計算結果に伝播します。重要な数値は、画像から抽出させたあとにテキストとして渡し直し、計算はテキストベースで検算するほうが安全です
• 人物の同定や医療画像の診断など、そもそも対応していない・向かない用途がある:提供元の利用規約や制限事項は事前に確認してください

選び方の視点:マルチモーダル入力が効く場面、従来の専用APIで十分な場面#

すべての画像・音声処理をマルチモーダルLLMに置き換える必要はありません。判断の目安は次の通りです。

マルチモーダルLLMが効きやすいのは、文脈理解や柔軟な指示出しが必要な場面です。「この資料の中で懸念点になりそうな数字を教えて」「このスクリーンショットで初見のユーザーが迷いそうな箇所は」といった、単純な抽出を超えた解釈が要る作業に向いています。

一方、次のような場面では、専用のOCR・音声認識APIのほうが向くことがあります。

• 定型フォーマットの帳票を大量・高速に処理したい(専用OCRは処理速度やコストで有利なことが多い)
• 文字起こしの精度そのものを厳密に評価・保証する必要がある(専用ASRは音声認識に特化して検証されている)
• 個人情報や機密情報を含む音声・画像を、用途を絞った専用サービスの範囲でのみ扱いたい社内規程がある

実務では、両者を組み合わせる設計もよくあります。たとえば専用OCRで文字を高精度に抽出しつつ、その結果と元画像の両方をLLMに渡して文脈理解の判断だけを任せる、といった役割分担です。どの用途にどちらを使うかは、精度要件・処理量・コストの3点を並べて、実際のデータで試してから決めるのが確実です。

まとめ#

マルチモーダルLLMは、画像や音声をテキストと同じモデルの中で扱えるようにすることで、OCRや音声認識の前処理を挟まずに文脈理解を伴う指示出しができる技術です。画像は解像度、音声は長さに応じてトークンとコストが増えるという実務上の勘所を押さえ、細かい文字・複雑な表やグラフの数値・長時間音声・画像内の計算では過信せず人の確認を残す。そのうえで、定型的で大量の処理や精度保証が必須の用途は専用APIとの使い分けも検討する。この切り分けができれば、マルチモーダルLLMを業務の道具として無理なく組み込めます。

画像・音声のトークン換算やコスト、解像度上限などの仕様は提供元・モデルによって異なり、随時更新されます。本記事の数値は執筆時点で確認できた公式ドキュメントの記載に基づく一般的な目安であり、特定モデルの性能優劣を示すものではありません。導入前には利用するモデルの公式ドキュメントで最新仕様を確認してください。

あわせて読みたい

主要LLMの選び方｜用途別の考え方と「使い分け」の基準