AnyDoc / pdf-inspector とは — Firecrawl製Rust製ドキュメント解析OSS
2026年8月、Firecrawlが公開したOSSライブラリAnyDocとpdf-inspectorを解説する。14形式をMarkdown化するAnyDocと、PDFをページ単位でOCR要否判定するpdf-inspectorの仕組み・使い方・ベンチマークをまとめた。
AnyDocとpdf-inspectorは、Webスクレイピングサービスで知られるFirecrawlが2026年8月6日に公開したRust製・MITライセンスのオープンソースライブラリである。AnyDocはWord・Excel・PowerPointなど14形式のファイルをMarkdownに変換し、pdf-inspectorはPDFをページ単位でテキストベース／スキャン／画像ベースに分類してOCRの要否を判定する。どちらもAPIキー不要でローカル完結するため、RAGの前処理や社内文書のMarkdown化を外部サービスに依存せず行える点が実務上の利点である。
この2本が注目を集めているのは、Firecrawl自身が本番で使っているパーサを切り出して公開したものだからである。同社は2026年4月にPDFパーサをRustで書き直した新エンジン「Fire-PDF」を投入し、処理速度を3.5〜5.7倍に改善したと発表していた。その内部部品にあたるのがpdf-inspectorであり、8月6日の公開後はGitHubのTrending（週間）上位に入り、リポジトリのスター数は1万3千を超えている。
何ができるか
2本のライブラリは役割が分かれている。AnyDocは「多様なファイル形式をMarkdownという単一フォーマットに揃える」ことに特化し、pdf-inspectorは「PDF1本に絞り込んで、ページ単位でOCRが必要かどうかを見極め、不要なページはOCRなしでテキストを抽出する」ことに特化している。AnyDoc自身もPDFの処理にはpdf-inspectorを内蔵しており、2つは独立しつつも補完し合う構成になっている。
- AnyDoc: Word/Excel/PowerPoint/OpenDocument/RTF/EPUB/CSV/PDFなど14形式をGitHub-Flavored Markdownに変換
- 形式判定の堅牢性: 拡張子ではなくファイルシグネチャ（ファイル内容そのもの）で形式を判定するため、拡張子偽装や欠落にも対応
- 一貫した出力: 全形式をいったん共通の内部ドキュメントモデルに変換してから描画するため、入力形式が変わっても出力の構造が揺れにくい
- pdf-inspector: PDFをページ単位でtext-based/scanned/image-based/mixedの4種類に分類し、confidence（信頼度）とOCRが必要なページ一覧を返す
- マルチ言語対応: どちらもRust / Node.js / Python / WebAssembly（AnyDocのみブラウザ動作）のバインディングを提供
- エージェント連携: AnyDocはAgent Skillとしても配布されており、Claude CodeやCursorなどのAIエージェントから直接呼び出せる
対応フォーマットと分類の仕組み
AnyDocが対応する14形式は8カテゴリに分かれる。埋め込み画像などのアセットはMarkdown中でalt textとして扱われ、必要であれば生バイト列も別途取得できる。一方pdf-inspectorは、検出フェーズと抽出フェーズでPDFの読み込みを1回だけ共有する設計になっており、二重パースによる無駄を避けている。CIDフォント（CMapデコード）や多段組レイアウトの検出、表認識（矩形解析とヒューリスティックな整列判定の併用）、エンコーディング異常の自動フラグ付けにも対応する。
| カテゴリ | 対応拡張子 |
|---|---|
| Word | .doc / .docx / .docm |
| PowerPoint | .ppt / .pps / .pot / .pptx / .pptm / .ppsx / .ppsm |
| Excel | .xls / .xlsx / .xlsm / .xlsb |
| OpenDocument | .odt / .ods / .odp |
| RTF | .rtf |
| EPUB | .epub |
| CSV | .csv |
| .pdf（pdf-inspectorを内蔵処理） |
インストールと使い方（最短手順）
どちらもRust / Node.js / Pythonのパッケージマネージャからそのままインストールできる。AnyDocはpipでも配布されているが、pdf-inspectorのPythonバインディングはmaturinでのビルドが前提となっている点に注意したい。まずはAnyDocのインストールと呼び出し例から見ていく。
# AnyDoc インストール
cargo add anydoc
npm install @firecrawl/anydoc
pip install firecrawl-anydoc// Rust
let markdown = anydoc::to_markdown("report.docx")?;// Node.js
import { toMarkdown } from '@firecrawl/anydoc';
const markdown = await toMarkdown('report.docx');# Python
import anydoc
markdown = anydoc.to_markdown("report.docx")続いてpdf-inspectorのインストールと呼び出し例である。CLIとして単体利用したい場合はcargo install pdf-inspectorを使う。
# pdf-inspector インストール
cargo add pdf-inspector
npm install @firecrawl/pdf-inspector
cargo install pdf-inspector # CLI# Python
import pdf_inspector
result = pdf_inspector.process_pdf("document.pdf")
print(result.pdf_type)
print(result.markdown)// Node.js
import { processPdf } from '@firecrawl/pdf-inspector';
const result = processPdf(readFileSync('document.pdf'));
console.log(result.pdfType);既存ツールとの違い（ベンチマーク比較）
Firecrawlが公開したベンチマークによれば、AnyDocはlibreoffice・unstructured・markitdown・pandoc・docling・mammothといった既存ツールと比べて、対応形式数・処理速度・品質スコア（completeness/structure/formatting/cleanlinessの複合評価）のいずれでも上位に位置する。特に処理速度はlibreofficeの約250倍、markitdownの約30倍という差が出ている。
| ツール | 対応形式数（/14） | 速度 | 品質スコア |
|---|---|---|---|
| anydoc | 14 | 4.4ms | 81 |
| libreoffice | 12 | 1129.5ms | 40 |
| unstructured | 8 | 572.9ms | 63 |
| markitdown | 6 | 134.8ms | 65 |
| pandoc | 5 | 102.1ms | 56 |
| docling | 4 | 513.6ms | 57 |
| mammoth | 1 | 52.5ms | 70 |
pdf-inspectorも同様に、liteparse・opendataloader・pymupdf4llm・markitdownとの比較で公開されている。200文書を対象にした評価では、Overallスコアと速度の両面で優位に立ち、特にmarkitdownと比べると速度は約34倍、表認識（Tables）スコアは約3倍という差がある。
| ツール | Overall | Reading Order | Tables | Headings | 速度 |
|---|---|---|---|---|---|
| pdf-inspector | 0.875 | 0.915 | 0.814 | 0.788 | 0.470s |
| liteparse | 0.873 | 0.913 | 0.693 | 0.811 | 0.750s |
| opendataloader | 0.831 | 0.902 | 0.489 | 0.739 | 2.569s |
| pymupdf4llm | 0.735 | 0.886 | 0.401 | 0.424 | 17.117s |
| markitdown | 0.589 | 0.844 | 0.273 | 0.000 | 16.165s |
なお、これらの数値はいずれも開発元Firecrawlが公開した自社計測値である。評価文書の内容や比較対象のバージョンによって結果は変動しうるため、参考値として捉えたい。
どんな場面で効くか
最も分かりやすい用途はRAG（検索拡張生成）の前処理である。社内に散在するWord・Excel・PowerPoint・PDFなどの文書をAnyDocでMarkdownに統一しておけば、チャンク分割やベクトル化のパイプラインを形式ごとに作り分ける必要がなくなる。またpdf-inspectorを組み合わせることで、分類フェーズ（約20ms）でテキストPDFかスキャンPDFかを見極め、テキストPDFはそのままローカル抽出（約150ms）、スキャンPDFのみ外部OCRサービスに回すという振り分けが可能になる。公開資料によれば約54%のPDFはOCR不要と判定されるため、OCR APIの呼び出し回数とコストを大きく削減できる可能性がある。社内文書のMarkdown化や、既存のOCRパイプラインのコスト最適化を検討している情報システム担当者にとって、検討価値のある選択肢である。
導入時の注意点
いくつか留意しておきたい点がある。第一に、pdf-inspector自体はOCRエンジンではない。あくまで「OCRが必要かどうか」を振り分けるツールであり、スキャンPDFのテキスト化には別途OCRエンジンやサービスの用意が必要になる。第二に、Pythonバインディングの導入手順に差がある。AnyDocはpipでそのままインストールできるのに対し、pdf-inspectorのPythonバインディングはmaturinでのビルドが前提となっており、AnyDocに比べて一段手間がかかる。第三に、ベンチマーク数値はFirecrawl自身が計測したものである点を踏まえ、自社が扱う文書群での再計測を推奨する。最後に、公開直後のライブラリであるため今後APIが変更される可能性がある。本番パイプラインに組み込む際はバージョンを固定して運用するのが無難だろう。
AnyDocとpdf-inspectorは無料で使えますか。
どちらもMITライセンスのオープンソースソフトウェアであり、無料で利用・改変・商用利用が可能である。APIキーの取得や外部サービスへの登録も不要で、ローカル環境で完結する。
AnyDocとpdf-inspectorはどちらを使えばよいですか。
Word・Excel・PowerPointなど多様な形式をまとめてMarkdown化したい場合はAnyDocを使う。PDFに絞ってページ単位でOCRの要否を判定し、テキストPDFを高速に抽出したい場合はpdf-inspectorを使う。AnyDoc自身もPDF処理にpdf-inspectorを内蔵しているため、PDFだけを扱うならAnyDoc経由でも良い。
日本語文書やスキャンした日本語PDFにも対応していますか。
公開情報には日本語特有の対応可否についての明示的な記載はない。CIDフォント（CMapデコード）への対応はアナウンスされているが、実際の日本語文書での挙動は自社の文書サンプルで事前検証することを推奨する。
pdf-inspectorだけでスキャンPDFの文字も読み取れますか。
読み取れない。pdf-inspectorはOCRエンジンではなく、PDFがテキストベースかスキャン（画像）ベースかを判定する分類ツールである。スキャンPDFの文字起こしには別途OCRエンジンやサービスを組み合わせる必要がある。
どのプログラミング言語から使えますか。
どちらもRust製で、Rust・Node.js・Pythonのバインディングが提供されている。AnyDocはさらにWebAssembly版があり、ブラウザ上でファイルを外部送信せずローカル処理できるオンラインデモも公開されている。
お気軽にご相談ください
お問い合わせ