マルチモーダルRAGとは？図表・画像を検索する仕組みと実装方式の選び方

マルチモーダルRAGは、テキストに加えて図表・画像・音声・動画といった複数の形式（モーダル）のデータを検索対象へ広げ、見つかった内容に基づいてLLMが回答を生成する仕組みです。社内のマニュアルや提案書には、文章よりも図解やグラフ、スクリーンショットの側に肝心な情報が入っている文書が少なくありません。テキスト抽出だけに頼る従来のRAGでは、この部分がまるごと欠け落ちます。本記事では、マルチモーダルRAGを構成する3つの方式と、ページを画像のまま検索するColPali系のアプローチ、そして自社文書の性質からどの方式を選ぶべきかという実装判断までを、実装する側の目線で整理します。

まとめ：マルチモーダルRAGの要点と実装方式を選ぶ判断の結論

マルチモーダルRAGの構成は、大きく3方式に分かれます。テキストと画像を同じベクトル空間へ埋め込む「共有ベクトル空間方式」、画像をVLM（視覚言語モデル）で説明文に変換してからテキストRAGとして扱う「キャプション変換方式」、モーダルごとに別のインデックスを持ち検索結果を統合する「モーダル別ストア方式」です。これに加えて、PDFのページを画像のまま多ベクトル化して検索するColPali系のページ画像検索が、帳票や図面など視覚情報の濃い文書で存在感を増しています。

実装する側の結論を先に述べます。最初の一歩は、キャプション変換方式による小規模な検証が手堅い選択です。既存のテキストRAG構成をほぼそのまま流用でき、前処理に画像の説明文生成を足すだけで効果を確かめられます。そのうえで、図面・帳票・スライドのように図表が主役の文書が多いと分かったら、ColPali系または共有ベクトル空間方式へ進む価値があります。逆に、規程集や議事録のようにテキスト主体の文書しかないなら、マルチモーダル化は見送りが正解です。検索の取りこぼしを実データで確かめる前に方式を決め打ちしない、という順序が費用対効果を左右します。

マルチモーダルRAGとは何か、テキスト専用RAGとの違いと扱えるデータ

まず、マルチモーダルRAGが従来のRAGと何が違い、どんなデータを扱えるようになるのかを押さえます。基礎が分かると、後述する方式の違いも読み解きやすくなります。

マルチモーダルRAGの定義と、図表・画像・音声まで広がる検索対象の範囲

RAG（検索拡張生成）は、質問に関連する社内文書を検索で引き当て、その内容を根拠としてLLMに回答させる構成を指します。従来のRAGが検索できるのはテキストだけでした。マルチモーダルRAGは、この検索対象を画像・図表・音声・動画へ広げたものです。具体的には、操作マニュアルのスクリーンショット、設備の点検写真、決算資料のグラフ、CADから書き出した図面、会議録音などが検索の土俵に載ります。実現の中核になるのが、テキスト以外のデータも数値ベクトルへ変換する埋め込みモデルと、画像を直接読んで文章を生成できるVLMの2つです。複数モーダルを扱うAIモデル自体の仕組みや業務応用はマルチモーダルAIの仕組みと実装判断を整理した記事で解説しているため、本記事は「検索して回答を作るRAG構成にどう組み込むか」に集中します。

テキスト専用RAGが取りこぼす情報と、既存構成から流用できる部分

テキスト専用RAGの取りこぼしは、想像より広い範囲に及びます。PDFからテキストを抽出すると、グラフの数値や傾向、フローチャートの分岐、表のセル同士の対応関係、画像内に書かれた注記が抜け落ちるのが実情です。「前年比の推移を教えて」と聞いても、その答えがグラフにしか描かれていなければ、検索は空振りします。一方で、悲観する必要はありません。RAGパイプラインの骨格、つまり文書の分割、ベクトルデータベースへの登録、検索結果を添えた回答生成という流れは、マルチモーダル化してもそのまま生きます。差し替えるのは埋め込みモデルと前処理が中心で、ゼロから作り直すわけではない点が実装上の救いです。RAGそのものの仕組みやファインチューニングとの違いはRAGの仕組みと企業での導入例を解説した記事が前提知識になります。

マルチモーダルRAGを構成する3方式、埋め込み設計と検索の流れ

マルチモーダルRAGの設計は、複数モーダルをどうやって1つの検索基盤に載せるかで方式が分かれます。3方式とページ画像検索、そして共通する処理フローを順に見ていきます。

共有ベクトル空間方式、マルチモーダル埋め込みで一括検索する構成

共有ベクトル空間方式は、テキストも画像も同一のベクトル空間へ埋め込み、1つのインデックスで横断検索する構成です。OpenAIが2021年に公開したCLIPが対照学習でテキストと画像を同じ空間に対応付けて以来、この系統のモデルが商用APIにも広がりました。Google CloudのVertex AIが提供するmultimodalembedding@001は、テキスト・画像・動画を同一空間の1,408次元ベクトルへ変換し、レイテンシやストレージを抑えたい場合は128・256・512次元も指定できます（公式ドキュメント・2026年7月時点）。AWSではAmazon BedrockのTitan Multimodal Embeddings G1が同様の一括埋め込みを担い、既定1,024次元で提供されています（同時点）。「赤い警告ランプが点灯した状態」とテキストで問い合わせて点検写真が引き当たる、というモーダル横断の検索が1つのインデックスで済む点が強みです。弱点は、長文テキストの検索精度がテキスト専用の埋め込みモデルに一歩譲る場合があることと、採用したモデルの空間に全データが縛られるため、モデル乗り換え時に全件の再埋め込みが発生することです。

キャプション変換方式とモーダル別ストア方式、コストと精度の傾向

キャプション変換方式は、画像や図表をVLMにいったん説明文へ変換させ、そのテキストを通常のRAGに登録する構成です。モーダルを主要モーダル（テキスト）へ寄せるアプローチで、既存のテキストRAGがほぼ無改修で流用でき、VLMの推論コストは前処理時の1回に限られます。モーダル別ストア方式は、テキストはテキスト用、画像はマルチモーダル用と、インデックスを分けて持ち、検索時に両方へ問い合わせて結果を統合します。統合にはRRF（順位の逆数で足し合わせる手法）などの順位融合が使われ、この考え方はハイブリッド検索とRRFの仕組みを解説した記事と地続きです。3方式の傾向を整理すると次のようになります。

キャプション変換の弱点は、説明文の粒度に検索精度が縛られる点です。VLMが「売上推移の棒グラフ」とだけ要約すれば、個別の数値への質問には答えられません。細部まで問い合わせたい文書では、後述のページ画像検索が選択肢に入ります。

ColPaliに代表されるページ画像検索、OCR不要で図表を引き当てる構成

ColPaliは、PDFのページを画像のまま埋め込むという発想の検索モデルです。2024年6月に公開された論文（arXiv:2407.01449）で提案され、OCRやレイアウト解析でテキストを取り出す従来のパイプラインを丸ごと省きます。仕組みの核は多ベクトル埋め込みで、SigLIP-So400m系の視覚エンコーダによりページを約1,024個のパッチへ分け、パッチごとのベクトルを保持したまま、クエリの各トークンと最も近いパッチの類似度を足し合わせるMaxSim（late interaction）で関連度を計算する仕組みです。文書検索ベンチマークのViDoReでは、従来パイプライン比でNDCG@5を最大29%改善したと論文で報告されています。表・図・レイアウトが情報を担う帳票や図面で強みが出る一方、1ページあたり千個規模のベクトルを持つためストレージ消費が単一ベクトルの数百倍になり、ベクトルデータベース側にも多ベクトル対応（QdrantやVespaなどが対応）が要ります。精度と引き換えにインフラ負担を受け入れる方式だと捉えてください。

検索から回答生成までの処理フロー、精度を左右する前処理と評価

どの方式でも、処理はデータ準備と検索実行の2段階に分かれます。データ準備では、PDFをページや図単位に分解し、画像には撮影日・文書名・ページ番号などのメタデータを付けて登録する流れです。図とその前後の本文を同じチャンクに紐付けておくと、検索後にLLMへ渡す文脈が揃い、回答の裏付けが強くなります。検索実行では、質問をベクトル化して候補を引き当て、ヒットした画像はテキスト化せず画像のままVLM対応のLLMに渡して回答を生成させるのが現在の主流です。GPT系・Claude系・Gemini系の主要モデルはいずれも画像入力に対応しています（2026年7月時点）。評価は「正しい文書・画像を引き当てたか（検索精度）」と「引き当てた内容から正しく答えたか（回答品質）」を分けて測ります。検索が外れているのに生成側のプロンプトを調整しても改善しないため、切り分けが先です。少量でよいので、想定質問と正解ページの組を人手で用意し、方式を変えるたびに同じ組で再計測すると、改善が数字で追えます。

マルチモーダルRAGの実装判断、採用すべき場面と見送るべき場面

ここからは方式の解説から一歩進め、自社の文書とデータの性質からどう選ぶかを示します。判断を分けるのは文書の中身であって、技術の新しさではありません。

文書の性質で決める方式選定、帳票・図面・スライドごとの使い分け

方式選定は、検索対象の文書で「図表が主役か、脇役か」を見極めるところから始まります。図面・帳票・検査票のように、レイアウトと視覚要素そのものが情報を担う文書が中心なら、ColPali系のページ画像検索を第一候補にします。テキスト抽出やキャプション化では、この種の文書の情報がほとんど残らないからです。プレゼン資料やレポートのように、文章とグラフ・図解が半々で混ざる文書には、共有ベクトル空間方式が釣り合います。図も文も同じ土俵で検索でき、モーダル横断の質問にも強い構成です。一方、本文が主体で図が補助的な文書、たとえば図を数点含む技術文書やマニュアルであれば、キャプション変換方式で足ります。図の存在と概要が検索に引っかかれば実用になる場面が多く、インフラ追加も不要です。写真データベースのように画像だけが大量にある場合は、画像側をマルチモーダル埋め込み、規程類をテキスト埋め込みに分けるモーダル別ストア方式が向きます。全文書を一律に最上位の方式へ載せる必要はなく、文書群ごとに方式を変える混在構成が実務の落としどころです。

マルチモーダル化を見送る条件と、既存RAGから段階導入する手順

見送るべき条件も言い切っておきます。検索対象が規程集・議事録・FAQ・ソースコードのようにテキスト主体なら、マルチモーダル化は過剰です。埋め込みAPIとストレージの費用が増えるだけで、検索精度はテキスト専用RAGと変わりません。スキャンPDFであっても、中身が文字中心ならOCRを通したテキストRAGの方が安く確実です。導入する場合も、一足飛びは勧めません。手順は4段階に分けます。

1. テキストRAGを土台として構築し、検索ログを取れる状態にする
2. 回答できなかった質問を分析し、図表起因の取りこぼしが何割かを実測する
3. 取りこぼしが目立つ文書群だけキャプション変換方式で検証し、改善幅を測る
4. 改善幅が大きく細部の検索も要るなら、ページ画像検索や共有空間方式へ拡張する

土台となるテキストRAGのデータ整備から精度向上までの進め方はRAG構築の手順を本番運用まで整理した記事にまとめています。自社の文書構成でどの方式が釣り合うか、テキストRAGから始めるべきか判断がつかない場合は、社内文書検索と生成AIの受託開発を手がける一創のRAG構築支援にご相談ください。文書の実態調査から方式選定、構築・運用までを一貫して支援します。

マルチモーダルRAGの仕組み・実装に関してよくある質問と回答

マルチモーダルRAGでよく検索される疑問に、実装目線で簡潔に答えます。

マルチモーダルRAGと通常のRAGは何が違いますか？

検索対象の範囲が違います。通常のRAGはテキストだけを埋め込み・検索しますが、マルチモーダルRAGは図表・画像・音声・動画も検索対象に含め、ヒットした画像を画像のままLLMに渡して回答を生成できます。文書分割やベクトルデータベースといった骨格は共通で、埋め込みモデルと前処理を差し替えることで成り立つ構成です。既存のテキストRAGを持っている場合、その大部分は流用できます。

マルチモーダルRAGの実装にはどの埋め込みモデルを使いますか？

共有ベクトル空間方式なら、テキストと画像を同一空間へ埋め込むモデルを使います。商用APIではVertex AIのmultimodalembedding@001（1,408次元）やAmazon BedrockのTitan Multimodal Embeddings G1（既定1,024次元）が代表例です（いずれも2026年7月時点）。ページ画像検索ならColPali系の多ベクトルモデルを使い、キャプション変換方式なら画像はVLMで説明文にするため、埋め込み自体はテキスト専用モデルで足ります。

PDFの図表を検索するにはOCRが必要ですか？

方式によります。キャプション変換方式やテキストRAGでは、スキャンPDFの文字を拾うためにOCRやレイアウト解析を前処理に挟みます。一方、ColPali系のページ画像検索はページを画像のまま埋め込むため、OCRそのものが不要です。図表やレイアウトが情報を担う文書ではOCRを省けるページ画像検索が有利で、文字主体の文書ではOCR＋テキストRAGの方が安く済みます。

マルチモーダルRAGの導入コストは高くなりますか？

方式次第で差が大きく出ます。キャプション変換方式は、前処理時にVLMの推論費用がかかるだけで、検索基盤は既存のテキストRAGを流用できるため増分は小さめです。共有ベクトル空間方式は埋め込みAPIの費用が加わる程度ですが、ColPali系は1ページあたり千個規模のベクトルを保存するためストレージ消費が数百倍になり、対応ベクトルデータベースの運用も必要です。小さく検証してから重い方式へ進む順序を勧めます。

どんな場合にマルチモーダルRAGを見送るべきですか？

検索対象がテキスト主体の場合です。規程集・議事録・FAQ・ソースコードが中心なら、テキスト専用RAGで精度が出るため、マルチモーダル化は費用の増加に見合いません。判断材料は実データにあります。テキストRAGを先に動かし、回答できなかった質問のうち図表起因の取りこぼしがどの程度かを測ってから、マルチモーダル化の要否を決めるのが確実です。

関連記事

• Agentic RAGのアーキテクチャと構成要素を詳しく解説：検索の実行判断をエージェントに委ねるRAG変種を知りたい方はこちら。
• GraphRAGをAzureで動かす方法｜2026年の現行構成と手順：知識グラフで文書間の関係を扱うRAG変種の実装を知りたい方へ。
• DeepRAGとは何か？定義と基本概念を詳しく解説：検索と推論を段階的に繰り返すRAG変種の考え方を知りたい方へ。
• ハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装：モーダル別ストア方式の結果統合で使う順位融合の詳細はこちら。
• マルチモーダルとは？複数データを扱うAIの仕組み・業務応用と実装判断を解説：RAGに限らずマルチモーダルAI全般の仕組みを押さえたい方へ。