RAGのドキュメントパース｜PDFからテキストを取り出す前処理で精度は決まる

RAGの精度が出ないとき、真っ先に疑われるのは検索アルゴリズムやチャンクサイズ、あるいはプロンプトです。ところが実際に社内文書を投入したパイプラインを開けてみると、原因がもっと手前、「そもそも文書からテキストが正しく取り出せていない」ところにあるケースが少なくありません。表の行と列の対応が失われている、2段組みの左右の文章が1行ずつ交互に混ざっている、スキャンされたPDFから何も抽出できずチャンクが空になっている。こうした状態でどれだけ検索を磨いても、上限は前処理の質で決まってしまいます。この記事では、チャンク分割の前段にあたる「ドキュメントパース(文書からのテキスト抽出・構造化)」に主題を絞り、難所の分類・アプローチの類型・中間表現の設計・評価の回し方を整理します。

この記事の守備範囲#

RAGの工程は、大きく「取り出す -> 区切る -> 索引を作る -> 検索する -> 生成する」と並びます。このうち区切る工程(チャンク分割)は

なぜ抽出の段階で精度が決まるのか#

PDFは見た目の指示書であって、文書構造ではない#

多くの人が「PDFにはテキストが入っている」と考えていますが、実態はもう少し厄介です。PDFの中身は、どの文字をページのどの座標に、どのフォント・サイズで描画するか、という指示の集合に近いものです。人間が見れば「これは見出し」「これは表の2列目」と分かるのは、位置関係と字面から視覚的に推論しているからであって、ファイルの中にその意味が明示的に書かれているとは限りません。

この性質がはっきり表れるのが読み順です。W3CのWCAG向け解説技術(PDF3)は、PDFの読み順がタグ構造によって決まること、そして文書が適切にタグ付けされていない場合、スクリーンリーダーがページを上から下へ読み進め、2段組みの左右を1つの段として解釈してしまうことを説明しています。同じことがテキスト抽出でも起こります。段組みの左右をまたいで1行ずつ交互に読み取れば、文章としては完全に破綻したチャンクが出来上がります。

表はさらに難しくなります。罫線は単なる線の描画であり、セルの区切りとして記録されているとは限りません。結合セルや複数行にわたるヘッダーがあれば、どの数値がどの見出しに属するかは座標から推論するしかなくなります。ここを間違えると、テキストとしては存在しているのに意味が反転した数値がチャンクに入り、検索でヒットしたときに堂々と誤った回答の根拠になります。

抽出で落ちた情報は、後工程では復元できない#

前処理の失敗が厄介なのは、後段のどの工夫でも取り返しがつかない点です。抽出できなかった表は、どんなに賢く区切っても存在しません。左右が混ざった段組みは、埋め込みモデルを変えても直りません。検索アルゴリズムを再ランキングで強化しても、索引に入っていない情報は返ってきません。

いわゆるハルシネーションの一部も、実はここに起因していることがあります。ユーザーが「この規程の第5条には何と書いてありますか」と尋ね、第5条が表の中にあって抽出に失敗していた場合、検索は近そうな別の条文を返し、モデルはそれをもとにもっともらしい回答を組み立てます。モデルは嘘をつこうとしたわけではなく、渡された材料の範囲で答えているだけです。回答の根拠を追跡できる状態にしていないと、この種の誤答は「モデルの問題」として片付けられ、真の原因である前処理に手が入らないまま放置されます。

難所の分類#

前処理の失敗はランダムに起きるのではなく、いくつかの典型パターンに集中します。自社文書がどのパターンを含むかを把握しておくと、手段選びと検証項目が具体化します。

多段組みレイアウト#

学術論文、パンフレット、新聞形式の社内報などに多い形式です。素朴な抽出では左右の段が行単位で混ざります。これはレイアウト解析(どの矩形領域がどの本文ブロックか)を行うか、領域ごとにテキストを切り出す仕組みがなければ避けられません。

表#

前処理の最大の難所です。難しさは段階的に増していきます。

• 罫線があり結合のない単純な表: 比較的多くの手段で扱えます。
• 罫線がなく余白だけで列を分けている表: 列の境界を座標から推論する必要があります。
• 結合セル・複数行にわたるヘッダー: 「どの見出しがどのセルにかかるか」の構造を保持できる出力形式が必要です。
• 入れ子の表(表の中の表): 商用サービスでも制約が残る領域です。Google CloudのDocument AI Layout Parserの公式ドキュメントでも、DOCXやPPTXでは入れ子の表がサポート対象外である旨が明記されています。
• ページをまたぐ表: 同じくDocument AIの公式ドキュメントは、PDFでは複数ページにまたがる表が分割されうると説明しています。

スキャンPDF(画像PDF)#

紙をスキャンしたPDFや、画像として貼り込まれたページには、そもそもテキストレイヤが存在しません。抽出しようとしても空文字列が返るだけなので、OCRが必要になります。OCRを通す判断を自動化するには、ページごとに抽出できた文字数を見て閾値以下ならOCRに回す、といった分岐を組むことになります。厄介なのは、テキストレイヤのあるページとスキャンページが1つのPDFに混在するケースで、ファイル単位ではなくページ単位で判定する設計が要ります。

ヘッダー・フッター・脚注のノイズ#

全ページの上下に入る文書名・部署名・ページ番号・機密表示は、そのまま抽出すると本文の途中に定期的に割り込み、チャンクを汚します。逆に脚注や注記は、本文の意味を左右する重要情報であることもあり、一律に削るのも危険です。ここは「役割(role)を判定して分類する」タイプの解析が効きます。Azure AI Document Intelligenceのレイアウトモデルは、段落に対してタイトル・セクション見出し・ページヘッダー・ページフッターといった役割を付与する仕組みを公式ドキュメントで説明しており、役割ごとに残す・落とすを判断できるようになっています。

図表とキャプション#

グラフや図に情報の中心がある文書では、テキスト抽出だけでは中身が丸ごと欠落します。少なくともキャプションを本文と紐づけておけば「図3には売上推移が示されている」という手がかりは残せますが、グラフの数値そのものは別の手段(VLMによる読み取りや、元データの参照)が必要です。Azureのレイアウトモデルでは、図に対して位置・関連するテキストスパン・関連要素といった情報を持つオブジェクトが返る設計になっており、図とその説明文を結びつける材料になります。

Officeファイル(docx/xlsx/pptx)特有の事情#

Officeファイルは、PDFと違って構造情報を最初から持っています。docxには見出しスタイルがあり、xlsxにはセルの行列があり、pptxにはスライドとプレースホルダがあります。したがって、わざわざPDFに変換してから解析するより、元の形式のまま構造を読んだほうが情報量が多くなります。

一方で、それぞれ固有の落とし穴もあります。xlsxは1シートが巨大な表そのものであり、そのままテキスト化すると膨大な行の羅列になって検索に使いにくくなります(Document AIの公式ドキュメントでは、XLSXについてセル数の上限や複数テーブルの検出が非対応である旨が説明されています)。pptxはスライドごとの文脈が短く、単体では意味が取りにくい断片が量産されがちです。docxでも、見出しスタイルを使わず文字サイズだけで見出しを表現した文書では、構造情報が実質的に存在しません。

アプローチの4類型#

手段は大きく4つに分けられます。どれが優れているという話ではなく、扱う文書の難易度・量・コスト・データを外に出せるかどうかで選ぶ対象が変わります。

(a)テキストレイヤ抽出系ライブラリ#

PDFに埋め込まれたテキストと座標を、そのまま高速に取り出す系統です。PyMuPDFはPDFを中心とした抽出・変換・操作のPythonライブラリで、プレーンテキスト・HTML・XMLといった出力に加え、LLM向けにMarkdownを出力するPyMuPDF4LLMが公式に用意されています。MicrosoftのMarkItDownは、PDF・Office文書・HTML・画像・音声など多様な形式をMarkdownへ変換する軽量ユーティリティで、公式リポジトリは「LLMやテキスト解析パイプラインで使うため」のツールであり、人が読むための高忠実度な変換には最適とは限らない、と明記しています。この位置づけの説明は重要で、この系統は「そこそこの構造を、速く安く、大量に」得るための道具だと理解しておくと選定を誤りません。

(b)レイアウト解析モデルを使う変換系#

ページのレイアウトを機械学習モデルで解析し、本文・見出し・表・図といった領域に分けたうえで、読み順を決めて構造化する系統です。

Doclingは、IBM Researchが立ち上げ、現在はLF AI & Data Foundationのプロジェクトとしてホストされているオープンソースのドキュメント変換ライブラリです(ライセンスはMIT)。公式リポジトリによれば、PDF・DOCX・PPTX・XLSX・HTML・EPUB・画像・音声などを入力に取り、Markdown・HTML・可逆なJSONといった形式へ出力します。レイアウト解析と読み順の検出、表構造の認識、コードや数式の抽出、スキャン文書向けのOCR、そしてGraniteDocling(258Mパラメータ)を含む複数のVLMのサポートが機能として挙げられています。

Unstructuredのオープンソースライブラリは、文書を「要素(element)」の列に分解するアプローチを取ります。公式ドキュメントによれば、Title・NarrativeText・ListItem・Table・Header・Footer・FigureCaption・PageNumberといった要素型に分類し、filename・page_number・parent_id・text_as_html(表のHTML表現)などのメタデータを付けて返します。PDFや画像に対する処理戦略として、文書の特性から自動選択するauto、pdfminerで高速にテキストを取り出すfast、レイアウト検出モデルを使うhi_res、TesseractでOCRするocr_onlyが用意されており、速度と精度のどちらを取るかを戦略として切り替えられる設計です。ただし公式ドキュメントは、オープンソースライブラリを素早いプロトタイピングの出発点と位置づけており、本番シナリオではUnstructured Pipelinesを使うよう推奨しています。制約としてドキュメントや表の抽出性能が落ちる点も明記されているため、この位置づけは選定の段階で踏まえておく必要があります。

(c)VLMにページ画像を読ませる方式#

ページを画像としてレンダリングし、マルチモーダルLLMに「この内容をMarkdownで書き起こしてください」と依頼する方式です。人間が見て分かるものは原理的に扱えるため、図やチャートを含む視覚的に複雑なページに強く、レイアウト解析器が苦手な体裁でも通ることがあります。

弱点は、生成モデルである以上、出力が確率的である点です。同じページを2回処理しても完全に同じ結果になるとは限らず、桁の読み落としや行の取りこぼしが混入する可能性を排除できません。監査や数値の正確さが求められる用途では、この再現性の低さが問題になります。コスト面でも、ページ数に比例して画像トークンが積み上がるため、数万ページの一括処理では見積もりが跳ね上がります。画像・音声を直接モデルに渡す仕組みとその精度の限界については

(d)クラウドのドキュメント解析サービス#

文書解析に特化したマネージドサービス群です。Azure AI Document Intelligenceは、レイアウトモデルによってテキスト・表・選択マーク・段落の役割・図などを抽出し、outputContentFormat=markdownを指定することでMarkdown形式の出力を得られることが公式ドキュメントに記載されています。Google CloudのDocument AIはLayout Parserを提供しており、公式ドキュメントによれば、上位の見出しや表ヘッダーの内容を含めた「文脈を意識したチャンク」を生成する設計になっています。LlamaParseはLlamaIndexが提供するクラウドの解析サービスで、公式ドキュメントによれば130以上のファイル形式に対応し、Markdown・テキスト・JSONでの出力と、精度重視から低コスト・低レイテンシまで複数のパースモードを選べる構成になっています。

これらは難所を含む文書でも安定した結果を出しやすい反面、従量課金であること、そして文書を外部に送信する前提であることが選定上の分かれ目になります。契約書・人事情報・患者情報のように外部送信の可否が経営判断になる文書では、(b)のローカル実行できる系統が現実的な選択肢になります。

ここで挙げたOSS・サービスの機能と位置づけは、それぞれの公式リポジトリ・公式ドキュメント(Docling、MarkItDown、PyMuPDF/PyMuPDF4LLM、Unstructured、LlamaParse、Azure AI Document Intelligence、Google Cloud Document AI)の記載に基づいて整理しました。この領域は更新が速く、対応形式・出力形式・提供状況は変わりえます。優劣の断定は避け、導入前に必ず自社の文書で試したうえで、最新の公式情報を確認してください。

中間表現をMarkdownに正規化する#

どの手段を選んでも、抽出結果はいったん共通の中間表現に落としておくと後工程が素直になります。実務でよく採られるのが、Markdown(あるいはMarkdownと構造化JSONの併用)への正規化です。理由は3つあります。第一に、LLMがMarkdownの見出し・箇条書き・表を素直に解釈すること。第二に、見出し記号(#の数)が階層を表すため、章立てをそのまま持ち回れること。第三に、テキストとして差分が取れるため、抽出結果の変化をレビューしやすいことです。

見出しレベルを確定させる#

抽出器が「これは見出しらしい」と判定した要素を、h2・h3といった階層に落とし込みます。ここが決まると、後段のチャンク分割で「見出し単位で切る」「見出しをチャンク先頭に付ける」といった構造認識分割が使えるようになります。逆に見出しがただの太字テキストとして流れてしまうと、チャンクは文字数でしか切れなくなります。

表をどう書くかを決める#

Markdownの表記法は簡潔ですが、結合セルや複数行ヘッダーを表現できません。この制約に対する現実的な回答の1つが、表だけHTMLで書くという折衷です。実際、Azure AI Document Intelligenceの公式ドキュメントは、v4.0のGA版で表の表現をHTMLテーブルに変更したこと、その理由が結合セルや複数行ヘッダーを表現できるようにするためであることを説明しています。商用サービスが同じ結論に至っているのは、判断の参考になります。

表が大きすぎてチャンクに収まらない場合は、行のまとまりごとに分割したうえで、各断片の先頭にヘッダー行を複製して付けておくと、単体で読んでも列の意味が分かる状態を保てます。

読み順を確定させる#

多段組みや回り込みのあるページでは、最終的に「どの順で並べたテキストが正解か」を1つに決める必要があります。ここが曖昧なままだと、同じ文書を再処理するたびに順序が変わり、チャンクの境界も変わり、評価結果の比較ができなくなります。読み順の決定は再現性の問題でもあります。

メタデータ設計と引用可能性#

抽出の段階で一緒に確定させておきたいのが、各テキスト断片に付けるメタデータです。最低限、次の情報があると運用が大きく楽になります。

• 出典ファイル名(と、可能なら原本へのリンクやドキュメント管理システムのID)
• ページ番号(PDFの場合。Unstructuredのような要素ベースの抽出ではpage_numberとして付与されます)
• 章・節の見出しパス(「第3章/3.2申請手続き」のような形)
• 文書の版・更新日
• 部署やアクセス権限の区分

これらは検索時のフィルタリングに使えるだけでなく、回答に出典を添えるための材料になります。「就業規則/第3章/3.2節(2026年4月版)/12ページ」まで示せる回答と、根拠なしの回答とでは、業務での使い勝手がまったく違います。特にページ番号と見出しパスは、利用者が原本に当たって確認する動線を作るという点で価値が高く、前処理の精度が完璧でない場合の保険にもなります。

評価と運用#

前処理は一度書いて終わりにできる領域ではありません。新しい形式の文書が追加され、ライブラリが更新され、そのたびに結果が変わりうるからです。最低限、次の3つは仕組みとして持っておくと安全側に倒せます。

回帰セットの効果は、パーサの入れ替えを検討するときに最も出ます。「Doclingからクラウドサービスに変えたら精度が上がるのか」という問いに、同じ30件を通した差分で答えられるかどうかで、判断のコストが変わります。感触ではなく差分で議論できる状態を作っておくことが、この領域の投資対効果を最も高めます。

向かない場面・やりすぎない判断#

高精度なパースは、常に投資に見合うとは限りません。次のような場合は、別の設計を先に検討したほうが速く着地します。

まず、対象文書を絞る選択肢です。全社の全文書を一括でRAG化しようとすると、最も難しい文書に合わせた前処理が必要になり、費用も期間も膨らみます。実際の質問の大半が特定の数十文書に集中しているなら、まずそこだけを丁寧に処理し、残りは後回しにするほうが投資効率は高くなります。

次に、原本へのリンクで代替する選択肢です。図面・帳票・複雑な財務諸表のように、そもそもテキスト化に無理がある文書は、無理に本文を抽出せず、タイトル・概要・キャプションなど検索に必要な最小限だけを索引化し、回答では原本へのリンクを返す設計にできます。利用者が最終的に原本を見るのであれば、本文の完全な再現は必ずしも必要ありません。

さらに、元データがあるなら文書を経由しない選択肢もあります。PDFの表が基幹システムから出力されたものなら、PDFを解析するより、元のデータベースやCSVを直接参照するほうが正確で安価です。文書パースは「構造化されたデータが手に入らないときの代替手段」であって、目的そのものではありません。

進め方のまとめ#

よくある質問#

まとめ#

ドキュメントパースは、RAGの工程の中で最も地味で、最も見落とされ、それでいて上限を決めてしまう部分です。検索アルゴリズムやプロンプトの調整と違って、成果が「回答が正しくなった」という形でしか現れないため、投資の説得も難しい領域でもあります。それでも、抽出で落ちた情報は後段のどの工夫でも取り返せないという事実は変わりません。まず抽出結果を自分の目で読むこと、難所の回帰セットを持つこと。この2つを先に整えておけば、その後の手段選びは、感触ではなく差分で判断できるようになります。