RAG（Retrieval-Augmented Generation）は「社内PDFを入れれば、LLMが知識を答えてくれる」という期待で導入が進みました。しかし、技術文書・規格書・手順書・安全マニュアルのような“構造が強い”ドキュメントでは、精度が伸びず現場に定着しないケースが目立ちます。原因はモデルの性能不足ではなく、検索の土台となる前処理が文書を「読めない形」にしていることです。本記事では、RAG精度が上がらない典型原因と、セマンティック分割（構造チャンク）および図表対応（マルチモーダルテキスト化）での解決策、さらに信頼性を担保するUI設計までを、B2Bの実装観点で整理します。
1. なぜ企業RAGは技術文書で失敗するのか：問題はLLMではなく前処理
企業RAGの失敗は「LLMが賢くない」からではありません。多くのケースで、検索対象データが前処理の段階で“破壊”され、検索が適切な根拠を取れなくなっています。LLMは取得された断片から回答を組み立てるため、根拠が欠けると推測で埋めてしまい、結果としてハルシネーション（もっともらしい誤答）が発生します。
特に技術文書は、本文だけでなく見出し階層、表の行列、図のキャプション、注釈、脚注、ページ内レイアウトといった「視覚的・構造的な意味」に依存します。ところが標準的なRAGパイプラインは文書をフラットな文字列として扱い、ページ構造を無視して分割・埋め込みを行いがちです。この時点で、検索精度の上限が決まってしまいます。
つまり、RAGの品質改善は「より大きいモデルを買う」より先に、「文書を壊さずに索引化する」前処理の再設計が最短ルートになります。
2. 固定長チャンク分割の落とし穴：表・見出し・注釈が分断される
多くのチュートリアルでは、テキストを一定文字数（例：500〜1,000文字）で機械的に切る固定長チャンク分割が採用されています。一般的な読み物（プローズ）では機能しますが、技術文書では致命的な副作用が出ます。
代表例は表です。例えば安全仕様表が1,000トークン相当あるのに、チャンクサイズを500にすると、「項目名（電圧上限）」と「値（240V）」が別チャンクに分かれ、ベクトルDBには別々に保存されます。ユーザーが「電圧上限は？」と聞くと、検索は項目名のチャンクだけを拾い、値が見つからない。LLMは答えを要求されるため、推測で埋めるか、曖昧な回答になります。
さらに固定長分割は、見出しと本文の関係、図とキャプション、注釈と対象箇所などの結び付きを切断します。結果として、検索は“意味の単位”ではなく“文字数の都合”で切られた断片を返し、RAGは「当たりそうで当たらない」状態になります。
固定長分割で起きやすい問題
- 表のヘッダとセル値、行列関係が分断され、仕様検索が不安定になる
- 図のキャプションが別チャンクになり、図の意味が検索できない
- 見出し階層が壊れ、同名セクション（例：「注意事項」）が混線する
- 脚注・注釈が切り離され、条件付きの制約（例：「屋外は除く」）が落ちる
3. 解決策① セマンティック（構造）チャンク分割：レイアウト解析で文脈を保つ
解決の第一歩は、固定長を捨てて「文書の構造に沿って分割する」ことです。セマンティック（構造）チャンク分割では、章・節・段落・箇条書き・表・キャプションといった境界をレイアウト解析で検出し、意味のまとまりを保ったままチャンク化します。
実装イメージとしては、PDFを単純にテキスト抽出するのではなく、レイアウト認識可能な解析でブロック構造を取得し、構造単位でチャンクを作ります。長さは可変でよく、重要なのは「論理的一貫性が保たれること」です。特定の機器部品を説明する節は、その節として一つのチャンクにする。表は表として一塊にする。これだけで検索の再現率と精度が大きく改善します。
構造チャンクの設計ポイント
- 見出し階層（章/節/項）をメタデータとして保持し、検索・再ランキングに利用する
- 表は境界を検出して分割禁止にし、行列関係が崩れない形で保存する
- 段落・箇条書きは意味単位でまとめ、途中で切らない
- チャンクには「ページ番号」「座標」「親セクションID」を紐付け、後段のUIで根拠提示できるようにする
このアプローチは、LLM側の工夫（プロンプトやガードレール）よりも前段で効くため、コストを増やさずに「取れる根拠の質」を上げられるのが利点です。RAGの精度は、生成より検索が支配的であることが多く、特に表・仕様・条件分岐が中心の質問では効果が顕著です。
4. 解決策② 図表・フローチャートの“視覚ダークデータ”を検索可能にするマルチモーダルテキスト化
技術文書で二つ目の失敗要因は「RAGが見えていない」ことです。企業の重要なノウハウは、フローチャート、配線図、系統図、アーキテクチャ図、工程図といった画像に埋まっています。ところが、一般的なテキスト埋め込みは画像を扱えず、インデックス作成時に画像がスキップされます。質問の答えが図にしかない場合、検索は空振りし、LLMは「分からない」か推測で回答します。
現実的な解は、画像を“検索可能なテキスト”へ変換する前処理、すなわちマルチモーダルテキスト化です。画像をそのままベクトル化できない環境でも、視覚情報をテキストに落とし込めば、既存のテキストRAG基盤で検索対象にできます。
マルチモーダルテキスト化の典型パイプライン
- OCR抽出：図中のラベル、凡例、注記、数値、矢印近傍の文言を高精度に抽出する
- 画像キャプション生成：視覚モデルで図の意味を自然言語で説明する（例：「温度が50度を超えると工程AからBへ分岐するフローチャート」）
- ハイブリッド埋め込み：生成した説明文を埋め込み、元画像（ファイル・ページ・座標）とメタデータで紐付けて保存する
こうしておけば、ユーザーが「温度 条件 分岐 工程」と検索したとき、ベクトル検索は“画像由来の説明文”にヒットし、RAGは図を根拠として回答できます。重要なのは、画像を単に説明して終わりではなく、後段で「どの図のどの部分が根拠か」を提示できるよう、参照関係を崩さず保持することです。
5. 信頼性を担保するUI設計：根拠（表・図・該当箇所）を提示するエビデンス表示
企業利用では、正解率だけでなく「検証可能性」が採用を左右します。チャットがテキスト回答とファイル名だけを返すUIでは、利用者はPDFを開き、該当ページを探し、表や図を目視で確認する必要があります。高リスク領域（安全、品質、法務、運用）ほど、この手間が信頼の壁になります。
そこで必要になるのが、エビデンス表示を前提としたUIです。前処理でチャンクと原典（ページ番号、座標、表・図の領域）を紐付けておけば、回答と同時に「根拠になった表」「参照した図」「該当箇所のハイライト」を提示できます。いわゆる“Show your work（作業過程を見せる）”が、RAGの信頼レイヤーになります。
エビデンス表示で押さえるべき要件
- 回答文の直下に、参照した表・図・本文抜粋をそのまま表示する
- ページ番号・セクション名・版数（改訂番号）を明示し、監査・共有に耐える形にする
- 表は画像ではなく可能なら構造化（行列）で表示し、該当セルを強調する
- ユーザーがワンクリックで原典PDFの該当ページに遷移できる
この設計は「当たっているように見えるAI」から「確認しながら使える業務ツール」へ変える決定打になります。現場の合意形成や、インシデント時の説明責任にも直結します。
6. 今後の展望：ネイティブマルチモーダル埋め込みと長文コンテキスト時代のRAG
マルチモーダルテキスト化は現時点で実装しやすく効果も高い一方、将来的には画像とテキストを同一ベクトル空間に直接マッピングする「ネイティブマルチモーダル埋め込み」が主流になっていきます。中間生成（キャプション）を挟まずに、図そのものを検索対象にできれば、情報損失や表現ゆれを減らしつつパイプラインを簡素化できます。
また、長文コンテキストLLMが低コスト・低遅延で使えるようになると、「そもそもチャンク分割が不要になるのでは」という期待も出ます。実際、マニュアル全体をコンテキストに入れられれば、分割の難しさは軽減します。しかし、リアルタイム運用でのコスト、レイテンシ、版管理、参照箇所の提示、検索の再現性といった要件を考えると、当面はRAGの前処理（構造保持と視覚データ解放）が最も経済合理性の高いアプローチであり続けるでしょう。
まとめ
技術文書に強いRAGを作る鍵は、LLMの大型化ではなく前処理の再設計です。固定長チャンクは表・見出し・注釈・キャプションを分断し、検索が根拠を取り逃がすことでハルシネーションを誘発します。対策として、文書構造を尊重するセマンティック（構造）チャンク分割で文脈と表の関係を保ち、さらに図表・フローチャートといった“視覚ダークデータ”をマルチモーダルテキスト化して検索可能にすることが有効です。最後に、根拠を表・図・該当箇所として提示するエビデンス表示UIを組み合わせれば、精度だけでなく信頼性と業務定着まで一気通貫で改善できます。RAGをデモから本番へ引き上げる差は、文書を「文字列」ではなく「構造と視覚を持つ知識資産」として扱えるかどうかにあります。
