PDF→Markdown変換にpdf-inspectorが選ばれる理由｜競合OSSとの違い

LLM や RAG パイプラインの普及に伴い、社内に蓄積された PDF をどう安定した Markdown に落とし込むかが、多くのエンジニアの手を止めるボトルネックになっています。特に、レポート・請求書・論文といったテキストベースの PDF まで一律に OCR サービスへ流している構成では、コストとレイテンシが線形に膨らみ、パイプラインの外側にも影響が及びます。

このような課題に対して、Firecrawl が公開した Rust 製 OSS「pdf-inspector」は、「まず PDF を分類し、必要な部分だけ OCR に振る」というルーティング思想で解決策を提示しています。ただ、PDF→Markdown 変換の OSS は LiteParse・pymupdf4llm・MarkItDown・OpenDataLoader など選択肢が多く、初見のエンジニアからは「何がどう違い、自プロジェクトに採用すべきか」の判断がつきにくい領域でもあります。

本記事では、pdf-inspector 公式リポジトリ（MIT ライセンス、記事執筆時点で 16,359 スター、直近 push 2026-08-20）と Firecrawl 公式ブログ の記述を出発点に、設計思想・アーキテクチャ・提供形態・類似 OSS との違い・採用判断のポイントを整理します。動作検証ではなく公開ドキュメントの引用に基づく解説であることを、あらかじめお断りしておきます。

pdf-inspectorとは — PDF処理を「分類」から始めるOSSの位置付け

pdf-inspector は、Firecrawl 社が「AnyDoc」構想の中核コンポーネントとして公開した Rust 製の PDF 解析ライブラリです。GitHub リポジトリの description では次のように紹介されています。

Fast Rust library for PDF inspection, classification, and text extraction. Intelligently detects scanned vs text-based PDFs to enable smart routing decisions.

出典: https://github.com/firecrawl/pdf-inspector

すなわち、単なる PDF→テキスト抽出ではなく、「PDF を分類してから抽出／OCR にルーティングする」という設計思想を強調している点が特徴です。Firecrawl 公式ブログ「AnyDoc and pdf-inspector」 では、テキストが埋め込まれた PDF まで OCR に流していた従来パイプラインの無駄を排除するために、ゼロから Rust で書き起こしたと説明されています。

Firecrawl と pdf-inspector の関係（AnyDoc / Fire-PDF との違い）

Firecrawl は Y Combinator が支援するウェブ・ドキュメント抽出 API を提供する企業で、Search / Scrape / Interact といったエンドポイントを公開しています。公式ブログの記述によれば、pdf-inspector は Firecrawl の /parse と /scrape エンドポイントに統合されており、ホステッド版「Fire-PDF」も並行して提供されています。Fire-PDF については、200 ページ中 150 ページがテキスト PDF の場合、従来 GPU 前提のパイプラインと比較して 3.5〜5 倍の高速化を実現するとされます（出典: https://www.firecrawl.dev/blog/anydoc-and-pdf-inspector）。

つまり整理すると、次のような階層関係になります。

• AnyDoc: Firecrawl が掲げるドキュメント処理の総合コンセプト
• pdf-inspector: AnyDoc の中核となる Rust 製 OSS ライブラリ
• Fire-PDF: pdf-inspector を組み込んだホステッド版サービス

本記事の主題である「OSS としての pdf-inspector」は、Fire-PDF や Firecrawl API を経由せずに、自分の環境で直接ライブラリを組み込みたい場合の選択肢を指します。

リポジトリの基本情報

gh api /repos/firecrawl/pdf-inspector で取得したメタデータをもとに、リポジトリの現状を整理します。数値はいずれも記事執筆時点のものです。

出典: https://github.com/firecrawl/pdf-inspector

archived と fork がいずれも false、disabled も false であることは、記事執筆時点で本リポジトリがアーカイブ済み・フォーク元不明・利用停止のいずれでもなく、上流本体として能動的にメンテナンスされている状態であることを示します。直近の push も 2026-08-20 と 1 日以内に更新があり、採用可否を検討する初期段階では「メンテナンスが継続している OSS」として扱ってよい状態です。

アーキテクチャと処理フロー — 分類と抽出を1回のロードで完結させる

pdf-inspector のアーキテクチャは、README の Architecture セクション で以下のように整理されています。ここでは、初見のエンジニアが「何がどうつながっているか」を把握しやすい粒度に噛み砕いて紹介します。

分類ステージの仕組み（Tj / TJ / Do 演算子ベース、confidence 出力）

分類ステージ（detector）は、PDF の xref と page tree を軽量にパースし、コンテンツストリーム内の描画演算子（Tj / TJ / Do 等）をサンプリングして PDF の種別を判定します。README では、次の 4 種類に分類されると説明されています。

• TextBased: テキストレイヤーが正しく埋め込まれている PDF
• Scanned: 画像のみでテキストレイヤーがない、OCR 前提の PDF
• ImageBased: 図表主体で本文テキストがほぼ含まれない PDF
• Mixed: ページごとに種別が混在している PDF

分類結果には confidence（0.0〜1.0）が付与され、Mixed の場合はどのページが OCR ルーティング対象かも返却されるとされます（出典: https://github.com/firecrawl/pdf-inspector#architecture）。呼び出し側は confidence の閾値を決めておくことで、「高信頼のテキストベース PDF はローカル抽出、それ以外は OCR に振る」といったルーティング判断が可能になります。

抽出ステージの仕組み（フォント解析 / マルチカラム / テーブル二重検出 / Markdown 変換）

抽出ステージ（extractor）は、fonts → content_stream → xobjects → links → layout の順に解析を進めます。README の記述に従うと、以下のような要素が段階的に処理されます。

• フォント解析: CID フォント（ToUnicode CMap、UTF-16BE、UTF-8、Latin-1）に対応
• マルチカラム対応: X-Y 座標を用いた列の並び替え、RTL 対応
• テーブル検出: PDF 描画命令の矩形ベース検出と、テキスト整列のヒューリスティック検出のデュアルモード
• Markdown 変換: フォントサイズ比で H1〜H4 見出しを判定、monospace フォントからコードブロックを推定、リスト・太字・斜体・URL リンク・ページ区切りを反映
• エンコーディング問題の検出: フォントエンコーディングが壊れているケースを検知し、呼び出し元が OCR フォールバックを判断できる情報を返す

出典: https://github.com/firecrawl/pdf-inspector#architecture

テーブルを矩形ベースとテキスト整列ヒューリスティックの二重で検出する設計は、財務表・脚注・ページを跨いで続く継続表など、テキスト PDF でも難所となるレイアウトを想定したものです。

ScanStrategy の 4 種と使い分け

pdf-inspector は、PDF の分類走査における戦略として ScanStrategy を 4 種類提供しています。README の記述に基づくと、以下のような使い分けが想定されています。

出典: https://github.com/firecrawl/pdf-inspector#architecture

「まず TextBased かどうかを最速で判定し、そうでなければ別ルートに振る」というルーティング用途では EarlyExit、既存パイプラインの品質検証や再処理向けには Full を選ぶ、といった判断が読み取れます。

さらに load_document_from_path / load_document_from_mem によって、PDF のパースは 1 回だけ実行され、その結果を分類ステージと抽出ステージが共有します。分類と抽出をそれぞれ独立に呼び出しても I/O が二重にならない設計は、パイプラインへの組み込み時に効いてきます。

5つの利用形態と依存関係 — Rust/CLI/Python/Node/WASMを1つのコアで提供

pdf-inspector の特徴の 1 つが、同一の Rust コアから 5 種類の利用形態を提供している点です。README の Quick start と各パッケージの配布ページを出典として、利用形態ごとに整理します。以下のコードブロックはいずれも README または公式配布ページの抜粋であり、改変は加えていません。

Rust（cargo add pdf-inspector）

Rust 環境で利用する場合、crates.io の pdf-inspector から cargo add で追加できます。

cargo add pdf-inspector

出典: https://crates.io/crates/pdf-inspector

README では、デフォルトは pure な抽出処理のみが有効で、OCR 経路は --features ocr で明示的にオプトインする設計であると説明されています。

CLI（pdf2md / detect-pdf）

CLI として利用したい場合は、cargo install からバイナリを導入できます。

cargo install pdf-inspector

出典: https://crates.io/crates/pdf-inspector

README によれば、これによって以下 2 種類のバイナリが提供されます。

• pdf2md: PDF を Markdown に変換
• detect-pdf: PDF の分類のみを実施（TextBased / Scanned / ImageBased / Mixed）

PoC 段階で「まずは自分の PDF がどう分類されるか」を素早く確認したい場合には、detect-pdf のみを CLI で走らせる進め方も想定されています。

Python（pip install pdf-inspector）

Python バインディングは PyO3 経由で提供され、PyPI の pdf-inspector から導入できます。

pip install pdf-inspector

出典: https://pypi.org/project/pdf-inspector/

Python API としては process_pdf と process_pdf_with_ocr の 2 種類が README に記載されており、既存の Python 製 PDF パイプライン（PyMuPDF・PDFMiner 経由の処理）から段階的に置き換えていく用途を想定した設計と読み取れます。

Node.js（@firecrawl/pdf-inspector）

Node.js からは、napi-rs を用いた @firecrawl/pdf-inspector が公開されています。

npm install @firecrawl/pdf-inspector

出典: https://www.npmjs.com/package/@firecrawl/pdf-inspector

TypeScript 製のサーバレスバックエンドから直接呼び出せるため、既存の Node.js パイプラインに組み込みやすい点は、フルスタック寄りのプロジェクトにとって選定材料になります。

Browser WebAssembly（@firecrawl/pdf-inspector-wasm）

ブラウザや Web Worker 上で動かしたい場合には、WASM ビルド版が用意されています。

npm install @firecrawl/pdf-inspector-wasm

出典: https://www.npmjs.com/package/@firecrawl/pdf-inspector（同一パッケージ配布元の関連パッケージとして）

同一の Rust コアがそのまま WASM としてブラウザ環境で動く設計は、「サーバに PDF を送らずクライアント側で分類だけ完結させる」といった構成にも活かせます。

OCR を有効化する場合の追加依存

デフォルトの利用範囲では、pdf-inspector が依存する PDF ライブラリは lopdf（純 Rust）のみに抑えられ、機械学習モデルや外部サービスへの依存はありません。この軽さが「まずライブラリを差し込んでみる」という判断のしやすさにつながっています。

一方で、OCR 経路を有効化する場合は README の記述に従って、PDFium と ONNX Runtime、および OCR モデル（PP-OCRv6 Small）が別途必要になります。OCR ランタイムのセットアップ手順は、README 内の docs/ocr-runtime.md に記載されています。OCR コスト削減が主目的の場合、この依存追加が許容できるかどうかは初期の判断ポイントの 1 つになります。

類似OSSとの比較 — LiteParse・pymupdf4llm・MarkItDown・OpenDataLoaderとどう違うか

「pdf-inspector を採用すべきか」を判断する上で、類似 OSS との比較は避けて通れません。ここでは、README の Benchmark セクション に掲載されている opendataloader-bench の結果と、各競合の立ち位置を照らし合わせて整理します。

model-free 部門でのベンチマーク比較

以下は、README に掲載されているベンチマーク結果を、そのまま引用したものです。opendataloader-bench のコーパス 200 PDF、2026-07-31 時点、Apple M4 Pro 上での計測とされ、OCR は無効化した model-free ローカルエンジン同士の比較で、5 回のフルコーパス実行の中央値（warm-up 除外）となっています。

出典: https://github.com/firecrawl/pdf-inspector#benchmark

再現用のベンチマークハーネスは、opendataloader-bench の再現可能ブランチ として公開されています。数値だけを鵜呑みにせず、自分のドキュメント種別で妥当性を確かめたい場合の出発点になります。

LiteParse / pymupdf4llm / MarkItDown / OpenDataLoader の違い

ベンチマークだけでは見えない、ライセンス・依存・提供形態の違いを、公式ドキュメントの記述から整理します。

• LiteParse（LlamaIndex）: モデル非依存の高速パーサで、Overall スコアは pdf-inspector とほぼ同等（0.873）。Rust / Node / Python / WASM / CLI の広い提供形態を持ち、ライセンスは Apache 2.0 とされています（出典: LlamaIndex 公式ブログ）。pdf-inspector と近い立ち位置にあり、テーブル精度（TEDS 0.814 vs 0.693）と処理速度（200 doc 0.470s vs 0.750s）で pdf-inspector が優位、Headings（MHS）では LiteParse が僅かに優位という関係です。
• pymupdf4llm（Artifex）: PyMuPDF ベースの Python 専用 PDF→Markdown ラッパで、AGPL-3.0 が継承されます（出典: PyMuPDF 公式ドキュメント）。ベンチマーク上は Overall 0.735、200 doc 17.117s と速度差が大きく、また AGPL の商用制約は pdf-inspector（MIT）にはない点も判断材料になります。
• MarkItDown（Microsoft）: PDF / DOCX / XLSX / PPTX などの多形式を Markdown 化する統合ツールで、ライセンスは MIT（出典: MarkItDown リポジトリ）。PDF 単体の精度・速度は Overall 0.589、200 doc 16.165s と劣後する一方、「多形式を 1 ツールで済ませたい」場合の受け皿として位置づけられます。PDF 型の分類・OCR ルーティングという概念自体は持ちません。
• OpenDataLoader: バウンディングボックス付きで AI 対応の PDF タグ付けを提供する OSS で、Apache 2.0（出典: OpenDataLoader 公式サイト）。model-free ベンチマークでは Overall 0.831 と pdf-inspector に僅差ですが、位置座標付きの構造化データが主目的で、pdf-inspector のような「OCR に振るかを判断するルーティング API」ではありません。

Marker / Docling / MinerU など「モデル同梱型」との棲み分け

Marker / Docling / MinerU など、VLM や OCR モデルを内包した「精度重視」型のツール群も、PDF→Markdown 領域では有力な選択肢です。ただし、これらは前提が異なり、「テキストベース PDF を高速にローカル処理する」という pdf-inspector の主軸とは、そもそも扱うレイヤーが違います。

• pdf-inspector: model-free で軽量・高速。テキスト PDF の高スループット処理と OCR ルーティングが主眼
• Marker / Docling / MinerU: 精度優先・モデル同梱。スキャン中心の PDF や複雑な図表主体の PDF に強い

したがってこれらは競合というより、pdf-inspector が「TextBased」と判定した PDF はローカル抽出、それ以外は Marker などのモデル同梱型に振る、といった役割分担で組み合わせる余地があります。

採用判断のポイント — どんな用途に向き、どんな用途では向かないか

比較を踏まえて、初見のエンジニアが「自プロジェクトに載せるか」を決める際の判断軸を整理します。判断基準は README の "Use case: smart PDF routing" 節と、公式ドキュメントサイト の記述に基づきます。

向くユースケース

• テキストベース PDF の高スループット処理: レポート・論文・財務諸表・請求書・法務文書など、テキストレイヤーが正しく埋め込まれた PDF を大量に Markdown 化する用途
• OCR コスト削減: すべての PDF を OCR に流していたパイプラインに対し、「まず分類 → TextBased はローカル抽出 → それ以外だけ OCR」という前段を挟むことで、OCR 呼び出し回数を減らしたい構成
• Rust / Node / Python バックエンドへの組込: 既存のバックエンドから、ネイティブ拡張として組み込みたい場合。Rust / CLI / Python / Node / WASM の 5 形態が同一コアから提供されているため、言語・ランタイムの制約に合わせて選択しやすい構成

向かないユースケース

• スキャン中心の PDF: 分類段階で Scanned に振り分けられ、結局 OCR が必要になる比率が高い場合、pdf-inspector 単体では価値が薄く、モデル同梱型（Marker / Docling / MinerU 等）と比較したうえで判断すべきです。
• 複雑な図表主体の PDF: レイアウトが複雑で、VLM ベースの精緻な解析が必要な用途。この場合もモデル同梱型のほうが向くケースがあります。
• モデル同梱で完結させたい構成: 分類やルーティングを自前で組みたくない、1 つのモデル同梱型ツールで完結させたい方針の場合、pdf-inspector の「ルーティング前段」というレイヤー分けの利点はむしろオーバーヘッドになります。

メンテナンス状況の見方

OSS を採用するときに気になるのは、「メンテナンスが継続しているか」「フォーク版ではなく本家か」といったリポジトリの健全性です。pdf-inspector については、記事執筆時点で以下の状況が確認できます。

• スター数: 16,359（比較的高い注目度）
• Fork 数: 1,132
• 直近 push: 2026-08-20（1 日以内の更新）
• archived / fork / disabled: いずれも false（本家リポジトリとして継続メンテナンス中）
• ライセンス: MIT（商用利用時の制約が少ない）

出典: https://github.com/firecrawl/pdf-inspector

このほか、Issue や PR の直近の動きも、リポジトリの GitHub ページから確認できます。数値だけで健全性を断定することはできませんが、少なくとも「アーカイブ済み」「他リポジトリからのフォーク」「利用停止扱い」といったネガティブサインは、記事執筆時点では出ていない状態です。

まとめ — pdf-inspectorを選ぶかどうかの整理

最後に、ここまでの内容を採用判断の観点でコンパクトに整理します。

• 設計思想: 「すべてを OCR」ではなく「まず分類して振り分ける」ことに主眼を置いた PDF ルーティング層。confidence 付きの 4 分類とページ単位の OCR ルーティング情報を返す
• 提供形態と依存: Rust / CLI / Python / Node / WASM の 5 形態が同一 Rust コアから提供され、デフォルト依存は lopdf のみ。OCR 経路は opt-in で PDFium と ONNX Runtime が必要
• 競合との差分: model-free 部門で LiteParse と Overall スコアは並ぶが、テーブル精度と処理速度で優位。pymupdf4llm・MarkItDown とは精度・速度の差が大きく、OpenDataLoader とは主用途（座標付き構造化 vs OCR ルーティング）が異なる
• 採用判断のサマリ: テキスト PDF 中心で OCR コスト削減が目的なら pdf-inspector を積極的に検討する価値がある。スキャン中心・複雑図表主体・モデル同梱で完結させたい構成なら、Marker / Docling / MinerU など別 OSS も比較検討すべき

より詳しい仕様や最新情報は、GitHub リポジトリ と 公式ドキュメントサイト、および Firecrawl 公式ブログ をあわせて参照してください。

関連情報

PDF を含むドキュメント処理パイプラインの設計や、Rust / Python / Node.js を用いた OSS ライブラリ選定のご相談を検討中の方は、秋霜堂株式会社の お問い合わせフォーム からご連絡ください。要件の整理段階からご相談いただけます。

Rust / Python / Node.js を用いた OSS 活用やドキュメント処理基盤の案件を探しているエンジニアの方は、フリーランスエンジニア向けマッチングサービスの Workee で案件情報をご覧いただけます。