10万PDFのOCR要否を一括判定：自動化パイプライン完全ガイド

要約： 企業アーカイブ、法律事務所、金融機関には数万〜数十万の PDF があり、Word 由来の「本物のテキスト」と 2005 年のスキャナー由来の「偽 PDF」（全ページ画像、コピー不可）が混在します。10 万件に全量 OCR をかけるとコストが無駄になり、すでに検索可能な文書まで再処理します。正しいアプローチは、まずバッチで OCR が本当に必要な PDF を検出し、タイプ別にローカルまたはクラウド認識エンジンへルーティングすることです。

「OCR が必要」の定義

エンジニアリング文脈では「OCR が必要」≠「画像がある」です：

要点： 検出段階の目的は内容認識ではなく、10 万件を「スキップ / 部分処理 / 全量 OCR」の 3 バケットに低コストで仕分けること。有料 API や重量級 OCR の前に必ず実行します。

3 層検出パイプライン

L1：テキスト層高速プローブ（< 50ms/ファイル）

PyMuPDF または pdftotext で印刷可能文字数を集計。avg_chars >= 80 → SKIP；avg_chars < 20 → OCR_REQUIRED；中間 → L2。

L2：ページ画像面積比率

L1 グレーゾーンで画像面積 / ページ面積を算出。画像比率 > 85% かつ L1 文字少 → OCR_REQUIRED；画像比率 < 30% → SKIP；残り → L3。

L3：レンダリングサンプル + 軽量 OCR

不確定ファイルは1 ページ目・中間・最終の 3 ページのみレンダリングし、macOS Vision または Tesseract で確認。L3 はグレーゾーンの約 5–8% のみ処理。

10 万件の並列アーキテクチャ

マニフェスト駆動 + メッセージキューで水平スケール：S3/MinIO → manifest.jsonl → Redis/RabbitMQ → N × Worker → SQLite/Parquet。

スループット（Cloud Mac mini M4、24GB）：

検出結果の 3 段階ルーティング

SHA-256 重複排除必須。検出結果を 90 日キャッシュで算力 20–40% 節約。

ツール選定

純 PDF：PyMuPDF + pdftotext 二重検証。混合文書：Apache Tika（JVM オーバーヘッドに注意）。

よくある落とし穴

1. 暗号化 PDF → qpdf --decrypt で複号コピーを検出
2. CID フォント文字化け → L3 で Unicode 印刷可能比率を確認
3. 二重層 PDF → pdffonts で既存 OCR 層を検出
4. 破損ファイル → CORRUPT バケットへ分離
5. NAS ランダム I/O → ローカル NVMe に rsync 後に実行

Cloud Mac を使う理由

• tmux 24/7 常駐、ノート PC 閉蓋でキュー中断しない
• Apple Silicon 統合メモリで PyMuPDF が x86 VPS より 20–40% 高速
• 検出 → OCR を同一ノードで一気通貫、10 万件の転送帯域を節約
• 法務・金融向けデータ residency：検出とローカル OCR をレンタルノード内で完結

7 ステップ実装チェックリスト

1. オブジェクトストアから manifest.jsonl をエクスポート
2. Cloud Mac に poppler、qpdf、PyMuPDF をインストール
3. L1 全量検出 → Parquet 出力
4. PARTIAL バケット 200 件を手動 spot-check、閾値調整
5. OCR_REQUIRED → ocrmypdf キュー；PARTIAL → ページ単位 OCR
6. サイドカー JSON を RAG / ES インデックス用に書き込み
7. 日次増分検出、全量再スキャン禁止

結論： 10 万件 PDF の OCR コストの少なくとも半分はそもそも OCR 不要なファイルに使われます。3 層検出パイプラインでバケットを先に分け、ローカル Vision かクラウド Document AI かを決める——これが 2026 年の文書デジタル化の正しいアプローチです。