RAG PDF Parsing ベストプラクティス：PDF 取り込み前の5つのチェック

結論：RAG ナレッジベースが破綻する主因は、埋め込みモデルの選定ミスではなく、PDF を事前チェックなしで取り込んだことにあります。スキャンをテキスト層と誤認、表がノイズに砕け散る、ヘッダー・フッターが全チャンクを汚染、二段組の読み順が狂う——といった典型例です。本稿では本番投入前に必須の5 つのチェックを、サンプリングコマンド・パーサー対照表・チャンキングゲートとともに解説します。RAG PDF Parsing の実務指針としてお読みください。

マニュアル、論文、契約書を LangChain、LlamaIndex、Dify、自前スタックへ流すなら、順序は 品質検証 → チャンキング です。キーワード：RAG PDF Parsing、PDF Parsing Best Practices、AI PDF Parsing。

最終確認：2026 年 8 月 7 日。パーサー挙動は現行の PyMuPDF、pdfplumber、LlamaIndex loaders に準拠。

PDF が RAG で最もリスクが高い理由

PDF は印刷再現のための形式であり、意味的ストレージではありません。1 ページにテキスト層、ベクター、埋め込みフォント、不可視 OCR 層、スキャン画像が重なることも珍しくなく、汎用 get_text() は文字を返しても読み順を保証しません。RAG はミスを増幅します。汚れたテキスト → 誤った境界 → 埋め込みのドリフト → 無関係な検索 → 自信満々のハルシネーション。

よくある失敗：製品 PDF 800 件をデフォルト loader に投入。2 週間後、サポートエージェントがフッターの著作権表記を仕様として引用。原因はスキャン 60%、二段組 30%、パーサー一本化。修復は再パース・再埋め込み・再インデックス——5 つの事前チェックより遥かに高コストです。

PDF Parsing Best Practices の鉄則：文書タイプでルーティングし、「万能 loader」に頼らない。

チェック 1：ネイティブテキスト vs スキャン PDF

目的：30 秒で、テキスト抽出か OCR＋レイアウト解析かを判断する。

手順：

• pdfinfo または PyMuPDF を実行。page.get_text() がページあたり 50 文字未満で画像オブジェクトが多いならスキャン扱い。
• 先頭・中間・末尾の 3 ページをサンプル。順序通りにテキスト選択できるか。
• Producer/Creator メタデータを確認。「PDF に印刷」系は壊れた疑似テキスト層を生むことがある。

合格：サンプルページの ≥ 90% で連続かつ正しい順序のテキスト。

不合格：OCR（Tesseract、PaddleOCR、マネージド LlamaParse）へ。バッチは別の エージェント編成ホストで OCR worker を回し、埋め込みキューの停滞を防ぐ。

チェック 2：テキスト抽出品質のサンプリング

目的：埋め込みに文字化けや不可視文字を混入させない。

手順：

• ランダム 5 ページのテキストをエクスポート。置換文字、私用領域 Unicode、リガチャ分割（fi、fl）を検索。
• PDF 原本と抽出結果で SKU、バージョン番号、API パスを照合——検索価値の高いトークン。
• CJK PDF では簡体・繁体、全角・半角の混在を確認。

合格：重要エンティティ 100% 一致。文字化け率 < 0.5%。

不合格：パーサー切替——表は pdfplumber、大量テキストは PyMuPDF、学術ページはレイアウトツール。LangChain の PDF loader ガイドを参照し、必ずサンプルで検証。

チェック 3：レイアウト——段組・表・ヘッダー/フッター

目的：読み順が人間の理解と一致し、描画順ではないこと。

手順：

• 多段組：左段を終えてから右段。交互ならレイアウト検出または bbox 並べ替え。
• 表：2 ファイルをサンプル。セルがカンマの粥に潰れないこと。Markdown 表または content_type=table チャンクで保存。
• ヘッダー/フッター：同一行がチャンクの > 40% に現れたらパース時に除去。

合格：3 名のスポットチェックで読める。表は二次元。ヘッダー/フッター除外済み。

不合格：パーティション型パーサー（Unstructured hi_res、Docling 等）またはチャンキング前の重複行除去。AI PDF Parsing の痛みの多くはレイアウトにあり、生の OCR 精度ではない。

チェック 4：セキュリティとコンプライアンス

目的：暗号化・PII 過多・無ライセンスコンテンツをインデックスに入れない。

手順：

• パスワード PDF はスキップまたは復号。skipped_encrypted を記録。
• 契約・チケットで PII スキャン（メール、電話、ID パターン）——マスクまたはインデックス分離。
• 著作権・データ処理の法務承認。社内インデックスでも規約違反の可能性あり。
• 本番で抽出全文をログに出さない。保存境界は エージェントメモリ vs チャットログを参照。

チェック 5：チャンキング準備とメタデータ

目的：パース結果が意味のあるチャンク分割に耐える構造を持つこと。

手順：

• page_number、source_file、section_title を可能な限り保持。
• 20 問のサンプルで固定ウィンドウ vs 見出し分割をプレビュー。
• チャンク長分布を監視——100 トークン未満の断片が多すぎると意味が薄まる。
• 長コンテキスト再ランキングを使うなら context caching コストを試算——きれいなパースは「全文詰め込み」回避につながる。

合格：メタデータ完全性 > 95%。top-3 チャンクが回答箇所をカバー。フッター汚染なし。

パーサー早見表（2026）

ゴールデンサンプルセット（二段組・表・スキャン・縦書き CJK など厄介 PDF 10–20 件）を維持し、パーサー変更のたび同じ Q&A 評価を再実行——「どれが最強か」の口論より実用的です。

推奨インポートパイプライン

1. ファイルハッシュ重複排除と分類メタデータでキュー投入。
2. チェック 1–2：自動タイプ判定＋テキストサンプル。スキャンは OCR 分岐。
3. チェック 3：レイアウトパース、ヘッダー/フッター除去、表構造化。
4. チェック 4：PII/暗号化フィルタ。失敗は隔離。
5. チェック 5：構造認識チャンキング＋メタデータ。小バッチ Q&A ゲート。
6. 合格後のみ埋め込み・インデックス。パーサーはバージョン管理して再実行可能に。

RAG 取り込みは生きたデータプロダクトであり、一度きりの ETL ではありません。パーサーのドリフトはモデル更新より速いことも。

ステークホルダーへの一問

聞いてください：「ユーザーが質問したとき、引用はページ・セクション・表の行のどの粒度か？」——チェック 3 と 5 の厳しさが決まります。

検索をエージェントに接続するなら 単一からマルチエージェントパイプラインへ続けてください。