RAG（社内文書を検索してAIに答えさせる仕組み）の多くは、文字で書かれた文書を前提にしている。だが実際の社内には、図面、写真、グラフ、スキャンしてPDFにした紙の書類など、文字以外の形で情報を持つ文書が数多くある。これらを「文字に変換すれば同じように扱える」と考えると、肝心の情報が落ちて、期待した答えが返らないことがある。

本記事は「RAG導入・連携の実務チェック」連載の一編として、図面・画像・PDFなど文字以外の情報を含む文書を扱う「マルチモーダルRAG」の論点を、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当、事業責任者である。マルチモーダルというと高度に聞こえるが、発注者として押さえたいのは「自社の文書のどこに情報があるのか」「テキスト化で落ちる情報はないか」という現実的な論点である。RAG全体の仕組みは社内ナレッジを活かすRAGとAI検索の実務ガイドでも扱っている。

結論：情報のありかを見極め、落ちる情報をどう扱うかを先に決める

マルチモーダルRAGで最初に必要なのは、技術選定ではなく「情報がどこにあるか」の見極めである。GXOがこの論点で重視するのは、次の3点である。

  • 自社の文書で、情報が文字にあるのか、図・表・画像にあるのかを切り分ける
  • テキスト化（文字起こし・OCR）で落ちる情報があるなら、その扱い方を先に決める
  • 図や画像を根拠にした回答でも、どこを根拠にしたかを示せる作りを前提にする

「とりあえずPDFを全部取り込めば答えてくれる」という期待は、図面や写真が中心の文書では裏切られやすい。まずは自社の文書を眺め、情報の本体が文字なのか、それ以外なのかを確かめることから始めたい。

なぜテキスト化だけでは足りないのか

通常のRAGは、文書を文字に変換し、その文字を分割して検索できるようにする。文字が情報の本体である文書（規程、マニュアル、議事録など）なら、この流れで十分に機能する。問題は、情報が文字以外にある文書である。

たとえば製造業の図面は、寸法、部品の配置、注記が図そのものに描かれている。これを単にテキスト化しても、図の構造や位置関係は文字に表れず、肝心の情報が落ちる。グラフや表も同様で、数値の並びや傾向が視覚的に意味を持つ場合、文字列にしただけでは関係が失われやすい。紙をスキャンしただけのPDFは、見た目は文書でも中身は画像であり、文字認識（OCR）を通さないとそもそも文字として扱えない。OCRも、手書きや劣化した書類では誤認識が起きやすい。

つまり、文書が「画像の形をした情報」を含むほど、テキスト化だけでは抜けが出る。マルチモーダルRAGは、こうした文字以外の情報も扱えるようにする考え方である。ただし万能ではなく、何をどこまで扱えるかは、文書の性質と求める精度によって変わる。

自社の文書を切り分ける：情報はどこにあるか

発注前にまず行いたいのは、自社の文書を「情報のありか」で切り分けることである。整理の目安を表にまとめる。

文書の例情報の主なありかテキスト化での扱い
規程・マニュアル・議事録文字テキスト化で十分なことが多い
仕様書・台帳（表が中心）文字＋表構造表の構造を保つ工夫が要る
図面・回路図・配置図図そのものテキスト化では落ちやすい
写真・現場画像・不具合写真画像文字化できず、画像として扱う必要
スキャンPDF（紙の書類）画像化された文字OCRが要る／精度に注意
グラフ・チャート視覚的な数値・傾向数値や説明の補完が要る

この切り分けで見えてくるのは、すべての文書がマルチモーダルの工夫を要するわけではない、ということである。文字が本体の文書は通常のRAGで足り、図や画像が本体の文書にだけ、追加の扱いを考えればよい。文書を棚卸しして種類を把握する作業は、文書の棚卸しで扱った進め方がそのまま使える。まずは「どの文書が、どのありかか」を一覧にしておきたい。

図面・画像・PDFを扱うときの実務的な工夫

文字以外の情報を含む文書を扱うには、いくつかの現実的な工夫がある。発注者として、おおまかな選択肢を知っておくと、提案を理解しやすい。

説明文を添えて検索できるようにする

図面や写真そのものを検索するのは難しいことが多い。そこで、各図面・画像に「何を表したものか」の説明文（キャプションやメタ情報）を添え、その説明文を検索の手がかりにする方法がある。説明を人が付けるか、AIで生成して人が確認するかは、量と精度の要求で決める。検索の手がかりとして添える情報の整理は、メタデータとフィルタの考え方が役立つ。

表は構造を保って取り込む

仕様書や台帳の表は、行と列の対応に意味がある。単に文字を並べると、どの値がどの項目のものか分からなくなる。表は構造を保ったまま取り込み、項目と値の対応を崩さないようにしたい。文書をどの単位で区切るかというチャンク設計の考え方はチャンク設計の基本で扱っており、表や図を含む文書では、文章とは別の区切り方が必要になる。

スキャンPDFはOCRの精度を確かめる

紙をスキャンしただけのPDFは、OCRで文字化してから扱う。ただしOCRは、手書き・かすれ・複雑なレイアウトで誤認識が起きやすい。誤認識をそのまま取り込むと、間違った情報を根拠に答えてしまう。重要な書類ほど、OCRの結果を確認する工程を設けたい。

画像そのものを扱うモデルを使う

近年は、画像を直接扱えるAIモデルもある。図や写真を見て内容を説明させる、といった使い方ができる。ただし、専門的な図面の細部まで正確に読み取れるかは用途によって差があり、過信は禁物である。どこまで任せ、どこから人が確認するかを決めておくことが前提になる。

出典と権限は、文字のRAG以上に丁寧に

マルチモーダルRAGでも、回答の根拠を示せることは欠かせない。むしろ、図や画像を根拠にした回答は「なぜそう言えるのか」が見えにくいため、どの図面・どの写真・どのページを根拠にしたかを示し、利用者が元の資料を確認できる作りが重要になる。出典提示とAIの作り話への向き合い方は出典提示とハルシネーション対策で扱っている。図の読み取りには誤りが混じりうるため、利用者が原本に当たれることは、誤りに気づくための安全装置になる。

権限の扱いも同様に丁寧にしたい。図面や現場写真には、機密性の高い情報が含まれることがある。文字の文書と同じ基準で、誰がどの資料を参照してよいかを管理する必要がある。文字以外の文書だからといって権限の設計が緩くなってはいけない。

また、画像を社外のサービスで処理してよいかという論点もある。図面や写真を外部に送る場合の扱いは、セキュリティ要件として先に確認しておきたい。

マルチモーダルRAGでよくある失敗

文字以外の情報を含む文書を扱うとき、次のような失敗が起きやすい。いずれも、情報のありかを先に見極めておけば避けられる。

  • すべてをテキスト化で済ませようとする：図や写真が本体の文書から情報が落ち、期待した答えが返らない。
  • OCRの精度を確かめない：スキャンPDFの誤認識をそのまま取り込み、間違った情報を根拠にする。
  • 表を文字の羅列にしてしまう：行と列の対応が崩れ、どの値がどの項目か分からなくなる。
  • 画像読み取りを過信する：専門的な図面の細部までAIが正確に読めると思い込み、確認工程を省く。
  • 出典・権限を文字の文書より甘くする：図や写真の根拠が見えにくいのに、確認手段や権限管理を緩める。

マルチモーダルへの対応は「全文書を高度に扱う」ことではなく、「文字以外に情報がある文書を見極めて、そこだけ適切に扱う」ことである。範囲を絞れば、過剰な作り込みを避けられる。

GXOに相談する前に整理するとよい情報

文字以外の情報を含む文書を一緒に扱うために、相談の前に次の情報を整理しておくと話が早い。すべて揃っていなくても問題ない。

  • 対象にしたい文書の種類（図面・写真・スキャンPDF・表中心の台帳など）
  • 情報の本体が文字にあるのか、図・表・画像にあるのか
  • 紙をスキャンした文書がどれくらいあるか、手書きが含まれるか
  • 図面や写真に機密情報が含まれるか、社外サービスで処理してよいか
  • 図や画像を根拠にした回答で、どこまで人の確認を要するか

これらが見えていれば、どの文書をどう扱うか、テキスト化で足りるか、画像として扱う必要があるかを一緒に設計できる。発注者が技術の詳細を理解している必要はなく、「自社の文書のどこに情報があるか」を共有できれば十分である。

参考にした外部観点

画像や図面を含む文書をAIで扱う場合、各モデルプロバイダの公式ドキュメントが、画像を扱う機能の範囲を確認する出発点になる。OpenAI Platform DocumentationやAnthropic Documentation、Google Cloud Vertex AI Documentationは、画像を含む入力をどう扱えるかの指針を公開している。リスク管理の観点では、NIST AI Risk Management Frameworkが、画像読み取りの誤りを含めAIを業務に組み込む際のリスクを組織的に扱う枠組みを示す。機密を含む図面・写真の取り扱いは、IPA（情報処理推進機構）の各種ガイドも、自社の制約を確認する助けになる。

実務では、まず情報が文字以外にある文書を一部だけ取り上げ、テキスト化で足りるか、画像として扱う必要があるかを小さく試してから範囲を広げると、過剰な作り込みを避けやすい。

関連記事

よくある質問

Q1. PDFを取り込めば、図面でも自動で答えてくれますか

文字が本体のPDFなら、取り込んで答えさせられることが多い。だが、図面や写真が情報の本体のPDFは、文字を取り出しただけでは肝心の情報が落ちる。図そのものを扱う工夫（説明文を添える、画像を扱えるモデルを使うなど）が必要になる。まずは自社のPDFが「文字が本体か、図が本体か」を確かめるところから始めたい。

Q2. 紙をスキャンした書類も使えますか

使えるが、OCR（文字認識）を通す必要があり、その精度に注意がいる。印刷された明瞭な書類は比較的読み取りやすい一方、手書きやかすれ、複雑なレイアウトでは誤認識が起きやすい。誤った文字を取り込むと、間違った情報を根拠に答えてしまう。重要な書類ほど、OCRの結果を確認する工程を設けるのが安全である。

Q3. 画像を扱えるAIなら、図面の細部まで読み取れますか

用途によって差がある。一般的な写真や図の概要なら扱えることが多いが、専門的な図面の寸法や細かな注記まで常に正確に読めるとは限らない。過信せず、どこまでAIに任せ、どこから人が原本を確認するかを決めておくことが前提になる。出典として元の図面を示し、利用者が確認できる作りにしておくと、誤りに気づきやすい。

図面・画像・PDFを扱うRAGを一緒に整理しませんか

GXOでは、文字以外に情報がある文書を見極め、テキスト化で足りるか・画像として扱うかを含めて、マルチモーダルRAGの設計をご支援します。

マルチモーダルRAGを相談する

※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。