GraphRAGやRAGを入れたのに精度が出ない。多くの場合、原因は検索アルゴリズムではなく、その手前のデータの取り込み（抽出・ingestion）にあります。どれだけ賢い検索や生成を載せても、グラフに入っている情報が崩れていれば、返ってくる答えも崩れます。地味ですが、ここがGraphRAGの精度を最も左右する工程です。
そして取り込みの現場で最初にぶつかる難所が、PDFからの抽出です。PDFは人が見るための形式で、機械が構造を読み取るためにできていません。表は崩れ、段組みは混ざり、スキャン文書は文字を誤認する。本記事では、なぜ抽出が本丸なのか、PDFとLLM抽出の限界はどこにあるのか、そして自分たちの手で埋めるしかない工程は何かを、実装の視点で整理します。
GraphRAGの精度は、検索より「取り込み」で決まる
GraphRAGは、文書から概念・エンティティ・関係を抽出してグラフに構造化し、それを検索の手がかりに使う仕組みです。つまり抽出した構造の質が、そのまま検索と回答の質になります。抽出が雑なら、いくら経路を増やしても正解にたどり着けません。入力がゴミなら出力もゴミ、という古い原則がそのまま当てはまります。
ベクトルRAGとの違いや、検索側で複数経路をどう統合するかはGraphRAGとは？ベクトルRAGとの違いと、根拠付き回答を実現する実装で扱いました。本記事はその手前、グラフに入れる前のデータをどう整えるかに絞ります。ここに手を抜くと、後段の工夫がすべて無駄になります。
なぜPDFからの抽出は難しいのか
「PDFをそのままAIに読ませればいい」と考えると、まずここでつまずきます。PDFは見た目のレイアウトを固定する形式で、論理的な文書構造（どこが見出しで、どこが表で、どの順に読むか）を持っていません。具体的には次のような崩れが起きます。
- 表が崩れる：セルの対応が失われ、行と列が混ざったテキストの羅列になる。金額表や仕様表ほど、抽出後に意味が壊れやすい。
- 読み順が入れ替わる：2段組みや3段組みのページで、左の段と右の段が交互に混ざり、文が途中でつながらなくなる。
- スキャンPDFは文字を誤認する：画像として取り込まれた文書はOCR（文字認識）が必要で、0とO、1とl、半角と全角、日本語の縦書きなどで誤読が混ざる。
- 図・グラフの中の情報が出ない：画像内の数値やラベルはテキストに含まれず、そのまま抜け落ちる。
- ノイズが混ざる：ヘッダー・フッター・ページ番号・脚注・透かしが本文に紛れ込み、文の意味を汚す。
やっかいなのは、これらの崩れが静かに起きることです。抽出処理はエラーを出さずに完了し、一見それらしいテキストが取れます。壊れているのは中身だけ。だからこそ、抽出結果が元の文書と合っているかを確かめる工程を省けません。そして、その前処理はPDFの種類によって入口から変わります。
テキストPDFと画像PDFは、別物として扱う
ひとくちにPDFといっても、中身の作られ方で難易度も手法もまったく変わります。取り込みの前に、どのタイプかを見分けて振り分けるのが最初の分岐点です。
- テキスト埋め込みPDF：文字データを持つPDF。テキストは比較的きれいに取り出せます。ただし段組みや表といったレイアウトの論理構造は持たないため、読み順の乱れや表の崩れは残ります。
- 画像PDF（スキャン・写真）：紙をスキャンした、あるいは画像を貼り込んだPDF。そもそも文字データが無いので、OCR（文字認識）をかけないと1文字も取り出せません。OCRの誤認識、傾き・かすれ、手書きの混在が精度を大きく左右します。
- 混在PDF：本文はテキスト、図表だけ画像、というように両方が混ざるPDF。ページごと・領域ごとに処理を切り替える必要があり、いちばん判定が面倒です。
同じ「PDFを取り込む」でも、テキストPDFなら抽出とレイアウト補正から、画像PDFならOCRから、と入口が変わります。ここを一律の処理で流すと、画像PDFがまるごと空になったり、混在PDFの図表だけ抜け落ちたりします。しかもエラーは出ないので、後で回答がおかしくなって初めて気づきます。まずタイプを判定して経路を分けるのが、崩れを防ぐ最初の一手です。
とくに手を焼くのは、表・手書き・多言語
同じPDFの中でも、次のような中身はさらに手強く、汎用の抽出では取りこぼしがちです。
- 表：本文のテキスト抽出とは別問題です。セルの行と列の対応を保ったまま取り出すには、表を表として扱う専用の抽出処理が要ります。結合セルや入れ子になった表は、専用ツールでも崩れることがあります。
- 手書き帳票：印刷された文字より認識が難しく、OCRの精度が大きく落ちます。チェック欄・訂正・崩し字が混ざる帳票を、そのまま自動化で確定させるのは危険です。
- 多言語・縦書きの混在：日本語の縦書きと横書き、英数字や外国語が同じ文書に混ざると、読み順の判定とOCRの両方が難しくなります。
こうした文書ほど、自動抽出だけで確定させず、人の確認を残す価値が高くなります。どこまで自動化し、どこから人が見るかの線引きを、文書の性質に合わせて決めます。
LLMで抽出するにも限界がある
「では抽出もLLMに任せれば」と考えるのが自然な流れですが、LLMによる抽出にも越えられない壁があります。強力な道具ではあるものの、丸投げできる万能の抽出器ではありません。
- 関係を捏造する：文書に書かれていないエンティティや関係を、それらしく作ってしまう（ハルシネーション）。事実のグラフに嘘が混ざると、後段の回答も汚染される。
- 同じものを別名で二重登録する：「A社」「株式会社A」「Aコーポレーション」を別エンティティとして登録してしまう。この名寄せ（エンティティ解決）を放置すると、関係が分散して検索が効かなくなる。
- 粒度がばらつく：どこまでを1つのエンティティ・関係とするかの基準（スキーマ・オントロジー）を決めずに任せると、抽出のたびに粒度が変わり、グラフが育たない。
- 出力がぶれる：同じ文書でも実行のたびに抽出結果が変わることがある。再現性が低いと、品質を安定させにくい。
- 専門用語を勝手に一般名称にする：社内固有の略語を、もっともらしい別の正式名称に置き換えてしまう。ドメインの文脈を知らないLLMは、この種の誤りを自信を持って犯す。
- コストとレイテンシ：全文書を大きなモデルに通すのは高く、遅い。量が増えるほど、抽出フェーズの費用が無視できなくなる。
これは能力の低いモデルの話ではありません。よく作り込まれた抽出でも完璧にはなりません。たとえばニュース記事から企業間の関係をLLMで自動抽出する取り組みでは、抽出精度は約73%と報告されています（出典：NTTデータ DATA INSIGHT）。実用に十分な水準ですが、裏を返せばこの事例でもおよそ3割は人の確認が要るということです。LLM抽出は「検証込み」で初めて使えます。
だから「抽出の検証」が要る
抽出は入れて終わりではなく、入れたものが正しいかを測る工程とセットで初めて回ります。私たちの経験でも、ここを省いた取り込みは、後で必ず精度の問題として跳ね返ってきます。最低限、次の仕掛けを用意します。
- 出典スパンを残す：抽出した各エンティティ・関係が、元文書のどの箇所（ページ・段落）から来たかを保持する。後から人が突き合わせて確かめられる状態にしておく。
- 評価データで測る：正解を用意した少量のデータで抽出精度を数値で確認する。手を加えるたびに測り、良くなったかを目視の印象でなく数字で判断する。
- 重要な関係は人がレビューする：金額・権限・契約・法規制など、間違えたときのコストが高い情報は、自動抽出だけで確定させず人の確認を挟む。
- 足し算で精度を過信しない：抽出の手法や後処理を増やすほど良くなるとは限らない。良かれと入れた処理がかえって精度を下げることもあるため、必ず評価で採否を決める。
回答精度そのものを業務水準に引き上げる考え方は生成AIの回答精度を業務レベルに引き上げる方法でも扱っています。抽出の検証は、その一番手前にある工程です。
自分たちの手で埋めるしかない工程
抽出には、ツールやLLMに任せきれず、ドメインを理解した人が決めるしかない部分が残ります。ここを外注や自動化で飛ばそうとすると、たいてい後で作り直しになります。
- スキーマ・オントロジー設計：何をノードにし、何を関係とするか。この設計は、その業務で「どんな問いに答えたいか」から逆算して決めます。業務を知らないと決められません。
- 用語辞書と名寄せルール：表記揺れ・略語・社内固有語をどう統一するか。固有名詞の対応表や、略語の正式名称を人が用意しておくと、LLMの誤りを大きく減らせます。
- 出典の信頼度：どの文書を信頼できる情報源として扱い、矛盾したときどちらを優先するか。この格付けは業務判断で、機械には決められません。
- 前処理の選定：PDFの種類ごとに、レイアウト解析・表抽出・OCRのどれをどう組むか。データの実物を見て決める、地道な作業です。
要するに、「AIに文書を放り込めば勝手に賢くなる」わけではありません。構造化に手間をかけた分だけ賢くなるのが実際のところです。この関係は、ナレッジグラフを丁寧に構造化するほどAIの判断が確かになる、という井本賢『ナレッジグラフ活用大全：構造化すれば、AIは賢くなる』の主題とも重なります。
現実的な取り込みパイプラインの作り方
以上を踏まえると、取り込みは1本の万能処理ではなく、データの種類ごとに分けた前処理と、抽出・検証を組み合わせた流れとして作るのが現実的です。
- データを種類で仕分ける：テキストPDF、スキャンPDF、表中心の文書、HTML、議事録などに分け、それぞれに合う前処理を当てる。1つの処理で全部を捌こうとしない。
- 前処理で構造を取り戻す：レイアウト解析で読み順を直し、表は表として抽出し、スキャンはOCRにかける。ヘッダー・フッターなどのノイズを落とす。
- 抽出はLLMとルールの合わせ技にする：定型で取れる部分はルールや正規表現で確実に、文脈が要る部分はLLMで。用語辞書で名寄せを効かせる。
- 検証してから登録する：出典スパンを残し、評価データで精度を測り、重要な関係は人がレビューしてからグラフに入れる。
- 小さく作って広げる：最初から全文書を狙わず、少量で抽出と回答の品質を固めてから対象を増やす。量を増やすのは、品質が安定してから。
費用の話をすると、GraphRAGの見積もりで見落とされやすいのが、この取り込みフェーズの工数です。検索や生成の実装より、データを整える前処理・抽出・検証のほうが手間がかかることも珍しくありません。AI開発全体の費用の考え方はAI受託開発の費用相場を参考にしてください。
Beekleの進め方
Beekleは、GraphRAG/RAGの構築で取り込みと抽出の検証を最初の作業として扱います。検索や生成の作り込みを先に進めるより、元データがどの形式で、どこが崩れやすいかを実物で確かめ、データの種類ごとに前処理を組みます。LLM抽出は検証込みで使い、スキーマ設計や用語辞書のように人が決めるべき部分は省きません。派手な手法を積むより、精度を確実に出すために地味な工程に手をかける方針です。ナレッジ検索の全体像はナレッジグラフは発注者に何の得があるかもあわせてご覧ください。
よくある質問（FAQ）
Q. PDFをそのままRAGやGraphRAGに入れてはいけないのですか？
A. 入れられますが、精度は期待しないほうがよいです。PDFは見た目を固定する形式で、表・段組み・スキャン画像が抽出時に崩れます。エラーは出ないのに中身だけ壊れることが多く、静かに精度を下げます。PDFの種類ごとに前処理（レイアウト解析・表抽出・OCR）を分け、抽出結果を元文書と突き合わせて検証する工程が必要です。
Q. データ抽出はLLMに任せれば済むのではないですか？
A. 万能ではありません。LLM抽出には、書かれていない関係を作ってしまう幻覚、同じ対象を別名で二重登録する名寄せの問題、実行ごとの出力のぶれ、専門用語を勝手に一般名称にする誤りといった限界があります。よく作り込んだ抽出でも精度は完璧になりません。定型はルールで、文脈が要る部分はLLMで、そして必ず検証を挟む合わせ技が現実的です。
Q. 抽出の精度はどうやって確かめればよいですか？
A. 正解を用意した少量の評価データで、抽出結果を数値で測ります。あわせて、抽出した各情報が元文書のどこから来たか（出典スパン）を残しておき、人が突き合わせて確かめられるようにします。金額・権限・契約・法規制など間違いのコストが高い情報は、自動抽出だけで確定させず人のレビューを挟みます。手を加えるたびに評価して、良くなったかを印象でなく数字で判断します。
Q. 抽出は全部おまかせできますか。自分たちでやることは残りますか？
A. ドメインを理解した人しか決められない部分が残ります。何をノード・関係にするかのスキーマ設計、表記揺れや略語を統一する用語辞書、どの文書を信頼するかの格付けは、その業務で何に答えたいかを知らないと決められません。ここを飛ばすと後で作り直しになります。前処理の選定も、データの実物を見て決める地道な作業です。
Q. どこから着手するのが現実的ですか？
A. 少量のデータで、抽出から回答までの品質を固めるところからです。最初に扱う文書の種類を1つ絞り、前処理・抽出・検証の流れを作って精度を測る。そこが安定してから対象データを増やします。いきなり全文書を狙わないのが、失敗しない進め方です。小さく試して判断したい場合は、初期費用0円のゼロスタートやRAGシステム構築でご相談ください。
Beekleにご相談ください Beekleでは、生成AI／CDP／業務システムの企画・要件定義・開発・運用までワンストップで支援しています。「何を作れば成功か」の整理、検証フェーズの設計、本番化判断まで、発注側の判断材料が揃うように伴走します。費用感の概算だけでも歓迎です。