AIにPDFを読ませる前に――Markdown化ではなく『答えてよいページ』を選ぶ

PDFをAIに渡して「フリーキャッシュフローはどうだった」と聞く。数字は確かにPDFに載っている。にもかかわらずAIは、正しい値である△36,719ではなく、財務活動キャッシュフローの41,908を拾い、こう答えた。

FCFは41,908百万円のプラスを確保し、キャッシュ創出力は維持されている

文章は自然だ。数字もPDFのどこかにはある。だから危ない。住友重機械工業の長期財務表では、一般的なテキスト抽出が行ラベルと数値列の結び付き、さらに符号を崩した。AIが嘘をついたというより、答えを一つに定められない材料から、自然な説明を組み立てたのである。

結論を先に書く。

PDFをMarkdownへ変換するだけでは足りない。AIに数値を答えさせる前に、そのページが「行・列・単位・期間・符号」を確認済みかどうかを判定する必要がある。

RAGとは、質問に関係する文書を検索し、その内容をAIの回答の根拠にする仕組みだ。ここでPDFを入力に使うなら、変換器の性能だけでなく、根拠にしてよいページを選ぶ工程が必要になる。

同じPDFでも、壊れ方は三つに分かれる

PDFは見た目が同じ文書でも、情報の置かれ方が異なる。まず、この違いを区別する。

紙面の型	何が意味を持つか	AIへ渡す前の扱い
仕様表・財務表	行と列の交点。年度・単位・符号	Markdown表変換とレイアウト保持抽出を比較し、元ページと照合する
罫線書式の文書	線ではなく、セル内の文章	通常抽出を優先。文章が細切れのセルに変わっていないかを見る
グラフ・図解	棒や線、凡例の位置	テキストだけで系列と値を確定しない。視覚確認か元表データへ回す

Markdownは、| などの記号で見出しや表を表すプレーンテキスト形式である。表の行列を残せるため便利だが、PDF上の罫線をすべて「表」と見なせば、段落までセルに閉じ込めてしまう。

図は今回の実装方針を示す編集部の整理であり、実在するPDFの紙面を転載したものではない。

表ではMarkdownが効く。ただし「常に勝つ」わけではない

Rust製のPDF→Markdown変換ライブラリであるpdf-inspectorを題材に、一般的なPDFテキスト抽出、pdftotext -layoutによるレイアウト保持抽出、Markdown表変換を比べた。対象は5類型・19文書・約2,700ページである。

半導体データシートLM358の多階層表では、12問中、一般的な抽出は6問、レイアウト保持抽出とMarkdown表変換はともに11問を正答した。品種・温度・条件と数値を照合する問いで差が出た。一方、BERT論文の単純な結果表は三方式とも12問中12問正答だった。表が単純で行順が保たれていれば、構造化の上積みは小さい。

医薬品インタビューフォームでは逆の面も見えた。ページ全体を囲む罫線を表として変換すると、散文と結果表が大きなセルに詰め込まれ、読みにくくなる。必要な数値が本文に明記されていた今回の10問では三方式とも10問正答だった。ここで得るべき結論は、「Markdownが悪い」ではない。AIに何を答えさせるかが、変換方式より先に来るということだ。

ケイ（検証設計を担当する編集者）は、抽出結果をそのまま正解にしてはいけないと指摘する。そこで元ページを画像として見て、行・列・値の対応を別に正解表として作った。同じ質問を独立したAIに渡し、答えを決められなければ「不明」と答えるようにした。評価したのは文字が取り出せたかではなく、抽出結果だけから安全に答えられるかである。

20 PDF・2,643ページを仕分けてみた

次に、この比較を実装へ移した。20 PDF、2,643ページについて、文字量、表らしい行列の反復、画像、罫線、フォントをページごとに調べ、抽出先を決めた。

ページ型	ページ数	行き先	数値回答の扱い
本文中心	1,470	通常抽出	検索・要約には利用。数値QAは別判定
数値表中心	466	Markdown表変換と-layoutを併走	行・列・単位・期間・符号の確認後だけ利用
グラフ・図解中心	448	視覚確認へ回す	テキストだけでは確定しない
罫線書式	155	通常抽出を優先	本文がセル化されていないか確認
単純表	71	通常抽出を基準	必要時に-layoutと比較
スキャン／OCRが必要	33	OCR品質確認へ回す	確認まで使わない

分類した結果、数値表は全体の一部にすぎない。本文中心のページは通常抽出で役に立つ。だが、AIが年次比較や財務指標を答える場面では、本文を安全に読めることと、数値を安全に答えられることを混同してはならない。

ナオ（RAGパイプラインを設計するエンジニア）は、数値の取り違えを許容できない文書では、複数の表現を比べる工程を本番処理に置くべきだと主張した。対してミサ（医薬品文書の利用者）は、表変換の成功率ではなく、散文がセル化されたときに止める条件を先に決めるべきだと指摘した。両者の意見は、万能な抽出器を探すより「失敗をどこで止めるか」を設計する点で一致した。

数値QAを安全と認定できたページは、まだゼロだった

この実行では、全ページの safe_for_numeric_qa を false のままにした。これは変換に失敗したからではない。数値を答えてよいページには、少なくとも次の五つが確認済みであることを求めたからだ。

1. 表題と単位が残っている。
2. 対象期間・年度と、連結／単体などの範囲が分かる。
3. 行ラベルと数値列の対応を確認できる。
4. 負数記号、△、括弧、パーセント、桁区切りが失われていない。
5. 元ページの画像と代表的な行を照合している。

2,643ページ中、ページ型を目視で正解と突き合わせたのは18ページだった。分類は15ページで一致したが、BERT論文の表を本文中心と見なした取りこぼし、罫線書式をグラフ中心へ回した過剰保留もあった。重要なのは、これらが数値表を無警告で回答へ流す失敗にならなかったことだ。

ユリ（PDFレイアウト解析を担当する研究者）は、文字が正しく抽出できることと、構造が正しく残ることは別の問題だと補足する。日本語PDFではCIDフォントとToUnicodeも確認した。CIDフォントは文字の形を番号で参照する形式、ToUnicodeはその番号をUnicode文字へ戻す対応表である。対応表の欠落は即座に文字化けを意味しないが、抽出器を変えると読めなくなる場合がある。したがって、PDFの属性だけで除外するのではなく、実際の出力を別方式と照合して警告を付ける。

実装で守るべき、最小限の境界線

実務で全ページを人手で確認する必要はない。後段のAIが実際に数値の質問へ使う表ページだけを優先して照合し、確認済みのページだけを数値QAへ渡せばよい。

本文の検索・要約       → 通常抽出を使える
数値の比較・計算       → 確認済みの表ページだけを使う
グラフの値・系列の質問 → 画像確認か作図元データを使う
文字化けの疑い         → 別の抽出器で検証する

この境界線は、AIを慎重に使わないためのものではない。むしろ、本文の検索や要約は速く進め、誤答の損害が大きい数値回答だけを厳しく扱うための設計である。

まとめ：変換器を選ぶ前に、答えてよいページを選ぶ

PDF→Markdown変換は、表を多く含む文書でAIの照合を助ける。だが、単純表では差がなく、罫線書式では読みやすさを損なうことがあり、グラフはテキスト化しても表にはならない。

今回の仕分けでは、数値QAを無条件で許可できるページは一つもなかった。これは失敗ではない。未確認の表・グラフ・文字化けリスクを、分からないままAIへ渡さない境界線を引けたということだ。

表ならMarkdown、ではない。確認済みの表だけが、AIに数値を答えさせられる。

出典

• pdf-inspector：比較対象にしたPDF→Markdown変換ライブラリ。
• 住友重機械工業 統合報告書2025：フリーCFと財務CFの行列対応を検証した長期財務表。
• 三菱HCキャピタル 統合報告書2025：表とグラフが混在するページの検証対象。
• TI LM358 データシート：多階層のパラメトリック表の検証対象。
• BERT論文：単純な学術論文表の比較対象。
• Volkswagen Annual Report 2024：グループヘッダーを持つ表の変換例。