2026年 AI PDF OCR ツール比較：pdf-inspector、MinerU、Marker どれが最適？

RAG、契約レビュー、論文ナレッジベースを組むとき、よく聞かれるのが「MinerU と Marker、どちらが強い？」です。しかしパイプラインを実際に遅くしているのは、テキスト層付き PDF をそのまま GPU OCR に流していること——バッチが秒単位から分単位になり、Agent は文書の準備完了を待ち続けます。Firecrawl オープンソースの pdf-inspector が示す解は明快です。先に分類し、ネイティブテキストを抽出し、文字が欠けているページだけ OCR する。

本記事は、PDF をベクトル DB や Agent に渡す iOS / Flutter / バックエンド開発者、およびローカル解析用に Cloud Mac ノード を検討しているチーム向けです。最終更新は 2026 年 8 月 5 日。ツールのバージョンとライセンスは各プロジェクトの GitHub を参照してください。

なぜ「全部 OCR」は文書パイプラインを壊すのか

企業の PDF コーパスには、レポート、論文、請求書、目論見書など抽出可能なテキスト層を持つファイルが大量に含まれます。ページごとにビジョンモデルで認識する必要はありません。従来は MinerU / Marker / クラウド OCR API を一律呼び出し、次の三つの隠れコストを抱えがちです。

1. レイテンシ税——純テキスト PDF は数百ミリ秒で Markdown 化できるのに、GPU キューで待たされる。
2. 構造税——OCR が読み順を崩し、表や脚注の後処理が難しくなる。
3. ライセンス税——Marker などはモデル重みに商用条項があり、全量 OCR はコンプライアンス面積を広げる。

2026 年の合理的な枠組みは 入口分類 → ローカルテキスト抽出 → ページ単位 OCR フォールバック です。opendataloader-bench の 200 PDF で、pdf-inspector は OCR なしモードで全体スコア約 0.875、ライブラリ全体を約 2.8 秒で処理——数分かかる ML パイプラインとは別世界です。

AI PDF ツールの分類（三つの入口）

三ツールを同一ランキングの順位争いと見なさないでください。パイプラインの異なる層を担います。

タイプ	代表	主な処理	典型レイテンシ
A. ルーティング / テキスト層抽出	pdf-inspector	TextBased / Scanned / Mixed を判定し、ネイティブテキストを Markdown 化	分類 ~20ms + 抽出 ~150ms/件
B. 高精度 OCR パイプライン	MinerU	レイアウト解析、表 HTML、数式 LaTeX、84 言語 OCR	秒〜分/件（GPU 依存）
C. 高スループット OCR パイプライン	Marker	Surya スタック、多形式入力、任意 LLM 後処理	バッチ時はページ/秒級（GPU）

非対称な結論：本当の分水嶺はモデルパラメータ数ではなく、パイプライン入口で「テキスト層 vs スキャン」を正しく分類できているかです。この層がなければ、どれだけ強い OCR も「OCR 不要な文書」に課金していることになります。

核心比較：pdf-inspector vs MinerU vs Marker

下表は技術選定ドキュメントにそのまま貼れる統一軸です。「実行能力」はバッチ組み込みと出力制御、「コンテキスト」は版式・表・数式・多言語の保持度を指します。

ツール	入口	実行能力	コンテキスト	向いている人
pdf-inspector	Node / Python / Rust CLI；Agent 前段に組み込み可	ML 不要；pages_needing_ocr でページ単位ルーティング；MIT	ネイティブテキスト Markdown、二モード表、多段組読み順；スキャン OCR は非対応	ハイブリッドパイプラインを組むバックエンド；Firestore / S3 の大量 PDF 前処理
MinerU	CLI / Docker / API；CPU と VLM デュアルバックエンド	OmniDocBench 系で高精度；VLM パスは ≥8GB VRAM；カスタム OSS ライセンス	表・数式・CJK に強み；ヘッダ/フッタ除去；JSON + MD 出力	学術論文庫、財務報告、中国語多段組、研究向け RAG
Marker	CLI / GUI / API；PDF 以外の Office 形式も可	バッチスループット高；任意 LLM 後処理；GPL コード + 重みライセンス制限	90+ 言語 OCR；画像抽出に強い；複雑な表は時々弱い	英語書籍の一括 MD 化、多形式アーカイブ、ライセンス審査が可能なチーム

コストと算力（第二の比較軸）

ツール	ハードウェア	ディスク / モデル	ライセンス要点
pdf-inspector	CPU のみ；Apple Silicon 向き	モデル DL 不要	MIT、クローズドソース組み込み可
MinerU	高精度は NVIDIA GPU 推奨；CPU パイプラインで劣化	初回は数十 GB 級の依存	カスタム条項、商用前に要確認
Marker	CPU / CUDA / MPS（Mac）	Surya 重みの DL が必要	GPL + RAIL-M、高収益法人は要審査

シナリオ別の選び方：意思決定マトリクス

あなたが…	優先すべき点	推奨ツール	備考
電子版レポート / 契約が中心のコーパス	レイテンシとコスト	pdf-inspector を主軸	Mixed ページだけ OCR
スキャン論文 / 古い期刊	OCR と数式	MinerU VLM パス	GPU またはリモート Mac を確保
英語書籍の大量デジタル化	スループット	Marker バッチ	先にライセンス審査
Agent がユーザー PDF をリアルタイム読取	P95 レイテンシ	pdf-inspector → 条件付き OCR	モデル冷起動を避ける
モバイルアプリのオフライン解析	バンドルサイズと消費電力	pdf-inspector 層のみ現実的	スキャンはクラウド OCR
データ国外持ち出し不可のコンプライアンス	セルフホスト	三者ともローカル可；デフォルトのクラウド OCR は避ける	ヘルプセンター の分離デプロイを参照

推奨スタック（重ね合わせ可）

スタック A — 低コスト RAG 入口（デフォルト推奨）

• pdf-inspector で分類 + テキスト層 Markdown
• pages_needing_ocr → MinerU CPU またはクラウド API
• ベクトル DB は統一チャンク戦略（見出し + ページメタデータ）
• 向き：企業ナレッジベース、サポート文書、スキャン混在コーパス

スタック B — 学術 / 中国語金融の高精度

• MinerU 全量（VLM バックエンド）で MD + JSON
• 品質保証：レイアウト可視化で 5% サンプルをスポットチェック
• 算力：ローカル M4 24GB で試走；ピークバッチは Cloud Mac M4 ノード

スタック C — 大量英語アーカイブ + CI 自動化

• Marker で夜間バッチ → オブジェクトストレージ
• CI で pdf-inspector による新規アップロードの「OCR 要否」ゲート
• オーケストレーションは OpenClaw クラウド自動化 で解析ジョブとビルドノードを分離

Cloud Mac / Apple Silicon との関係

MinerU と Marker は macOS 上で MPS 統一メモリを使えますが、24GB メモリの M4 ノードは「夜間バッチ + 昼間リモート開発」の分担に向きます。解析ジョブがノードを占有し、Xcode ビルドと swap を奪い合いません。pdf-inspector は極めて軽量で、CI Runner や GitHub Actions 自ホスト Mac のアップロードゲートに載せられます——先に判定し、重い OCR を起動するか決めます。

常設 GPU サーバーがないチームは、Marker / MinerU バッチを Cloud Mac で月額レンタルする方が、OCR 専用 GPU を買うより運用コストが低いことが多いです。ルーティング層はアプリ側か軽量コンテナに残すのが定石です。

よくある誤解

1. ベンチマーク総点で業務受入を代替する——自社 PDF は二段組中国語表注かもしれず、英語論文集とは分布が違う。
2. 「偽テキスト層」を無視する——GID エンコードや文字化け層は pdf-inspector が needsOcr とマークする。抽出を無理せず OCR へ。
3. MinerU / Marker の二択に固執する——混合コーパスは「ルーティング + ページ単位デュアルエンジン」が現実的。
4. ページ単位メタデータを付けない——ベクトル検索で「何ページの表か」を引用できず、幻覚の修正が難しくなる。
5. ライセンスを最後に見る——Marker の GPL と重み条項が SaaS 配布経路を塞ぐことがある。

導入ステップ（7 ステップ Action Plan）

1. 実 PDF を 30〜50 件サンプリングし、pdf-inspector で TextBased / Scanned / Mixed 比率を集計。
2. 受入指標を定義——読み順、表構造、数式 LaTeX のレンダ成功率に合格ラインを設定。
3. ルーティング層を実装——高信頼 TextBased はローカル抽出；pages_needing_ocr リストを出力。
4. OCR セグメントのエンジン選定——中国語複雑版式は MinerU；英語一括は Marker；モデル版を記録。
5. 算力を配置——軽量ルーティングは CI；GPU バッチは Cloud Mac または専用機。Mac mini レンタル を参照。
6. 1 週間の本番トラフィックを走らせる——P95 レイテンシ、失敗ページ、手修正率を記録し閾値を調整。
7. 運用マニュアル化——ライセンス境界、ロールバック版を ヘルプセンター の鍵管理・データ保持方針と揃える。

FAQ

pdf-inspector は OCR ツールですか？

従来型 OCR ではありません。分類してからネイティブテキストを抽出し、OCR が必要とマークされたページだけ MinerU、Marker、クラウド API に渡します。

MinerU と Marker、表はどちらが正確？

複雑な学術表や中国語多段組は MinerU が安定しやすい。Marker は英語一括と画像抽出に向く——商用前にライセンスを確認してください。

NVIDIA GPU なしで MinerU は動く？

CPU パイプラインで可能。高精度 VLM は ≥8GB VRAM 推奨。Apple Silicon では Marker を MPS で試すか、バッチをリモート Mac に移す。

RAG はどれから始める？

デフォルトは pdf-inspector ルーティング → スキャンページだけ OCR。平均コストとレイテンシを大きく下げられます。

三ツールは連結できる？

可能です。2026 年の主流パターン：inspector 分類 → テキスト層はローカル MD → 欠落ページは MinerU/Marker → 統一スキーマで DB 投入。

まとめ

「pdf-inspector、MinerU、Marker どれが一番？」に単一の勝者はいません。pdf-inspector は入口とコスト、MinerU は複雑構造と CJK、Marker は英語一括スループットで勝つ——まず「OCR なしで何ページ処理できるか」を答えてからエンジンを選ぶ方が、ランキング点を追うより算力も安定も得られます。

本番前に一問だけ自問してください：OCR を切ったら、まだ使える Markdown が出る文書は何割あるか？ その比率をアーキテクチャレビューの冒頭に書いておくべきです。

関連記事

• Gemini 4 vs GPT-5.6：開発者の選び方 →
• OpenClaw とクラウド Mac：自動化チェーン →