RAGのPDF処理：pdf-inspectorとOCRの選び方（2026）

先に結論：全量OCRではなく条件分岐が基本です

pdf-inspectorの公式READMEでは、PDF分類を約10〜50ms、テキスト抽出をローカルで200ms未満の処理として説明しています。また、同プロジェクトのベンチマークでは、200文書の完全処理を2.8秒で実行した記録が掲載されています。数値は環境とサンプルに依存するため、そのまま本番性能とは見なせませんが、RAGのPDF処理では「先に検査し、必要なページだけOCRへ送る」設計が現実的です。(github.com)

つまり、pdf-inspectorとOCRのどちらか一方を選ぶのではありません。pdf-inspectorを検査と原生テキスト抽出の入口に置き、スキャンページ、画像ページ、文字層が壊れたページだけをOCRへ回す構成が、品質と運用負荷のバランスを取りやすいです。

この内容は、これからRAGの取り込み基盤を作る開発者、既存のOCR処理が遅いチーム、そして遠隔の計算環境で大量回帰テストを準備する責任者に向いています。単にPDFをテキスト化する方法ではなく、どの条件でどの処理へ分岐させるかを決めたい場合に有効です。

※最終更新：2026年8月10日。pdf-inspectorの最新README、実装説明、掲載ベンチマークを確認しています。ベンチマークの実行環境とバージョンは、公式リポジトリの比較表を参照してください。

RAGのPDF処理で最初に測るべき品質

PDF Parsingでは、文字が抽出できたかだけを見ると誤判定が起きます。隠しテキスト層が存在するPDFでも、文字順が崩れていたり、段組みが混ざっていたり、表のセルが別々の文章として出力されたりするためです。

RAG向けの受け入れ判定では、少なくとも次の項目を分けて確認します。

本文の文字が欠落していないか
見出しと本文の階層が維持されているか
2段組みの読み順が逆転していないか
表の行と列が対応しているか
ページ番号を引用元として追跡できるか
ヘッダー、フッター、透かしが本文へ混入していないか
数式、単位、型番、URLが壊れていないか

pdf-inspectorは、テキストベース、スキャン、画像ベース、混合型の分類に加え、OCRが必要なページの一覧を返す設計です。公式説明では、文字演算子や画像演算子を確認し、ページ単位のルーティングに利用できるとされています。ただし、これは分類と抽出の機能であり、業務文書の意味理解や完全な表構造復元を保証するものではありません。(github.com)

RAGへ取り込む前にOCRは必須ですか。
スキャンPDFや画像ページを含む場合は必要ですが、すべてのPDFに対して先に実行する必要はありません。原生テキストが十分に読める文書までOCRへ送ると、処理段階、検証対象、障害要因が増えます。反対に、文字層が空に近いページや文字化けが多いページを原生抽出だけで進めると、検索インデックスに不完全な情報が固定されます。

方式別の選び分け

方式	向いている入力	強み	弱点	評価
pdf-inspectorで検査し、原生抽出	報告書、論文、規程、テキスト主体の請求書	低い追加負荷で分類とMarkdown化を同じ入口に置ける	複雑な画像文字やOCR品質は扱えない	◎
全量OCR	全ページが画像、紙文書中心の保管庫	処理ルールを単純化しやすい	不要なOCR、遅延、誤認識、検証量が増える	○
検査後の条件付きOCR	テキストPDFとスキャンPDFが混在	ページ単位で品質と処理量を調整できる	ルーター、再試行、ログ設計が必要	◎
汎用解析器のみ	表、図、段組みなど形式が多様	文書構造の補助処理を追加しやすい	分類機能が弱い場合、OCRへ送る判断を別に作る必要がある	○

この表の評価は、特定製品の正確率を示すものではありません。入力データを分類し、OCRを条件分岐として扱えるかという、RAGの文書前処理における設計上の評価です。

pdf-inspectorだけでOCRを置き換えられますか。
テキストベースPDFの検査と抽出入口としては有力ですが、スキャンページの文字認識そのものを置き換えるものではありません。公式READMEにも、OCRを使わずに分類とテキスト抽出を行うライブラリとして説明されており、OCRが必要なページを検出した後の処理は別に用意する前提です。(github.com)

速度とスループットは固定値ではなく分岐率で決まります

全量OCRの設計では、テキストがすでに存在するページにも画像化、認識、結果検証を適用します。一方、検査後に分岐すれば、原生抽出で問題ないページをそのまま次の切り分けへ進められます。

ただし、「何倍速くなる」といった結論は、PDFのページ数、画像解像度、言語、表の量、OCRエンジン、並列数で変わります。pdf-inspectorの公式ベンチマークにある2.8秒という値も、Apple M4 Pro上で指定バージョンと評価用コーパスを使った結果であり、別の環境へ直接移植できる保証はありません。(github.com)

運用では、平均処理時間だけでなく、次の3つを記録します。

1文書あたりの検査時間と抽出時間
OCRへ分岐したページ比率
再処理、失敗、手動確認へ回った比率

スキャンPDFは、通常のテキスト抽出では検索可能な文字を得られません。Adobeの説明でも、スキャン直後のPDFは画像データだけを含む場合があり、OCR後には認識結果の確認が必要とされています。(helpx.adobe.com)

多段組み、表、数式では役割を分けます

PDFの種類を判定できても、文書の意味まで理解できるわけではありません。特に、次のようなファイルでは分類結果を解析品質と混同しないことが重要です。

左右の段組みがある技術資料
セル結合を含む財務表
数式や添字を含む研究論文
図の中に説明文が埋め込まれた資料
テキストページと画像ページが交互に現れる混合PDF

この場合、pdf-inspectorは「どのページを原生抽出し、どのページをOCRへ送るか」を判断する層に置きます。構造解析器は段組みや表の再構成を担当し、OCRは画像上の文字を機械可読化する担当です。1つのツールに分類、文字認識、表理解、チャンク設計のすべてを期待すると、障害時の切り分けが難しくなります。

費用は処理工程と保管期間に分解します

RAGのPDF取り込み費用は、OCR料金だけでは決まりません。少なくとも次の式で見積もると、ピーク時と平常時の差を把握できます。

総費用＝検査・抽出の計算費用＋ OCR処理費用＋埋め込み費用＋保存費用＋再処理費用

OCRを外部サービスで実行する場合は、ページ数、画像処理、API呼び出し、失敗時の再送を分けて記録します。自前環境では、CPU、メモリ、ディスク、一時画像、同時実行数を見ます。OCRの有無だけでなく、ピーク時に何件を何時間で処理するか、増分取り込みが毎日発生するかで、適切な環境は変わります。

小規模な試作なら手元のMacや短期レンタル環境で十分な場合があります。大量の回帰試験や夜間バッチでは、処理期間と同時実行数を先に決め、Macのレンタル環境やMac VPSの料金体系と照合すると、購入と短期利用の差を比較しやすくなります。

規模別の推奨アーキテクチャ

小型の原型では、PDFを受け取ったらpdf-inspectorで分類し、テキストベースなら原生抽出、スキャンまたは低信頼ならOCRへ送るだけでも検証できます。周期的な一括処理では、ページ単位の結果、OCRの再試行回数、抽出後の差分を保存します。

継続的な本番取り込みでは、次のような分離が安定します。

受付層：ハッシュ、ファイル名、取得日時、文書IDを記録
検査層：PDF種別、信頼度、OCR対象ページを記録
抽出層：原生抽出、OCR、構造解析を個別ジョブ化
品質層：見出し、表、ページ引用、文字欠落を検査
RAG層：チャンク化、埋め込み、インデックス登録
回帰層：固定サンプルで旧版と新版の差分を比較

テキスト版とスキャン版はどの解析器へ送るべきですか。
テキスト版はまず原生抽出と構造解析へ送り、文字が不足するページだけOCRへ回します。スキャン版はOCRを起点にしますが、OCR後のテキストをそのまま信頼せず、ページ番号、見出し、表、固有名詞の確認を通過させてからチャンク化します。

本番投入前に通す可否判定

以下をすべて確認できない場合は、処理速度を上げるより先に検証設計を見直すべきです。

[ ] テキスト版、スキャン版、混合版を含む代表サンプルを用意した
[ ] 原生抽出、全量OCR、条件付きOCRを同じサンプルで比較した
[ ] 文字欠落、読み順、表、見出し、ページ引用を個別に採点した
[ ] OCR失敗時に原ファイルを保持して再処理できる
[ ] pdf-inspector、解析器、OCR関連依存のバージョンを固定した
[ ] 文書ID、ページ番号、処理経路、失敗理由をログへ残した
[ ] 依存更新後に同じサンプルで回帰テストを実行した
[ ] 埋め込み前のMarkdownまたは中間形式を保存した

pdf-inspectorの依存関係や変更履歴は、導入時だけでなく更新前にも確認する必要があります。GitHubでは依存関係、ライセンス、既知の脆弱性を確認できる仕組みが案内されています。(docs.github.com)

既存方式が全量OCRの場合、主な弱点は、不要なページまで処理すること、誤認識の検証対象が増えること、ピーク時の計算資源を余分に確保することです。反対に、pdf-inspectorだけへ寄せる方式では、スキャンページを取りこぼし、検索結果の欠落を見逃す危険があります。

そのため、現在の方式から移行するなら、まず同一サンプルで分岐率と品質を測るのが適切です。短期間の大量検証や回帰試験で計算環境が必要なら、固定構成を購入する前に、Macの仮想デスクトップ環境を候補へ加えると、処理期間に合わせて利用時間を調整できます。長期の安定した重負荷処理や物理機器への接続が必要な場合は自社設備が適しますが、検証用の一時環境では、必要な期間だけMacをレンタルできる方が構成変更と撤去の負担を抑えやすいです。

RAGのPDF処理は、OCRを使うかどうかではなく、どのページをどの品質基準で次工程へ渡すかが本質です。まず小さな固定サンプルで指標を決め、周期的なバッチや継続的な取り込みへ進む段階で、分級ルーターと回帰ログを追加する流れが安全です。