会社で扱う文書の90%はウェブにはありません。契約書、四半期レポート、請求書、ユーザーがアップロードしたPDF — すべてディスク上にあり、その処理は常に別々のパイプラインでした。
Firecrawlが4月14日にFire-PDFをリリースし、14日後の4月28日に/parseエンドポイントを追加したことで、その分断が終わりました。ウェブスクレイプとローカルファイルが初めて同じエンジンを使います。
なぜ一緒に見るべきなのか?
Firecrawlが4月の1か月で公開した2つのリリースを別々に見ると、意味が半分しか伝わりません。
4月14日 — Fire-PDF。 RustベースのPDFパーサーです。従来パイプラインと比べて平均ページあたり400ms以下、3.5〜5.7倍速い処理を実現。核心のポイントは、すべてのページをGPUに投げないことです。オープンソースのpdf-inspectorがページをテキストベース/スキャンベースにミリ秒単位で分類し、テキストページはネイティブ抽出で処理し、スキャン/画像ページだけをGPUレイアウトモデル + OCRに送ります 。
4月28日 — /parseエンドポイント。 同じエンジンをローカルファイルにも使えるようにした入り口です。multipart/form-dataでファイルのバイトをアップロードすると、Markdown、JSON、要約、構造化抽出まで一度に返ってきます。対応フォーマットはPDF、DOCX、DOC、ODT、RTF、XLSX、XLS、HTML — ファイルあたり50MBまで 。
2つが統合されたことの意味はシンプルです。ウェブページと社内ファイルが初めて同じRAGパイプラインに入るのです。以前はウェブはFirecrawl、PDFはPyMuPDF/Unstructured、スキャンはTesseract/Textract — 3つに分かれていました。出力フォーマットが違い、表・数式の処理品質が違い、コスト構造も違っていたんです。
従来のPDFパイプラインの何がそんなにコスト高だったのか?
Fire-PDFが誇る5倍の速度がマーケティングではない理由は2つあります。
- ネイティブ抽出を優先 — テキストベースのページはGPUをまったく通しません。PDFの内部構造(フォント、テキストオペレーター、画像カバレッジ)を
pdf-inspectorがレンダリングなしにミリ秒単位で読み取り、そのままテキストを抽出します。 - レーンベースのGPUルーティング — GPUが必要なページだけを送り、文書サイズ別にレーンを分けます。200ページのレポートが入っても、1ページの請求書処理のレイテンシーには影響しません。
- リージョン最適化OCR — 表・数式・テキストブロックを別々のリージョンとして検出し、それぞれ異なるトークンバジェットとプロンプトを使います。表は25秒まで余裕を持たせ、数式はLaTeXで保存し、テキストは12秒・256トークンで区切って効率優先。
金融レポートのようなmixed文書をイメージすると違いは明らかです。150ページがテキストベースで60ページだけスキャンなら、以前は210ページ全部OCRを走らせていました。Fire-PDFなら60ページだけGPUに送ります。速度とコストがほぼ比例して削減される構造です。
何が変わるのか?
コストより大きいのはパイプラインの単純化です。会社がRAG/エージェントを運用するとき、通常こんな構成でした。
| 処理対象 | 以前 — 分断されたスタック | 以降 — Firecrawl統合 |
|---|---|---|
| ウェブページ | Firecrawl /scrape |
/scrape + Lockdownオプション |
| ウェブ上のPDF/DOCX | ダウンロード → 別パーサー | /scrape URLを投げるだけで自動検出 → Fire-PDFで処理 |
| ローカルファイル/ユーザーアップロード | PyMuPDF + Unstructured + Tesseractの組み合わせ | /parseにファイルをアップロードするだけ |
| 構造化抽出（契約当事者、請求書合計） | パース → LLM呼び出し → JSON正規化（3ステップ） | /parse呼び出しにschemaを一緒に渡すだけ（1ステップ） |
| 出力フォーマット | ツールごとに異なる — 後処理必須 | すべてMarkdown / JSONで統一 |
| 機密文書（契約・医療） | 自社インフラ + 別途セキュリティ審査 | Enterprise ZDR — レスポンス後即時破棄 |
RAGパイプラインを運用してきた立場から見ると、表の最後の2行が本当の価値です。「パース → LLM呼び出し → JSON正規化」が1行になるのは、単純な行数の問題ではなく、エラーが出る箇所が1/3に減るということです。中間ステップごとのretry/fallback/検証ロジックがなくなります。
/parseは毎回の呼び出しで再パースします — キャッシュがありません。同じファイルを複数回アップロードすると毎回課金されます。ユーザーアップロードを受けるサービスなら、ファイルハッシュベースの独自キャッシュレイヤーを前段に置くのが合理的です。
始め方のポイント
- ステップ1 — まず分岐点を決める
ウェブ上の公開URLなら/scrape、ローカルファイルや認証が必要なファイルなら/parse。Firecrawlのガイドもこの分岐から始まります 。 - ステップ2 — PDFモードを明示する
スキャンが多ければparsers: [{type:"pdf", mode:"ocr"}]。テキストPDFならmode:"fast"。mixedならデフォルトのautoのままでOKです。 - ステップ3 — schemaも一緒に渡す
契約書・請求書のように決まったフィールドを抽出するなら、formatsに{type:"json", schema:{...}}を一緒に入れます。後続のLLM呼び出しが1ステップなくなります。 - ステップ4 — 大きなPDFはmaxPagesで制限する
200ページのレポート全体が必要なケースは稀です。maxPages: 50のようなキャップを設けてコスト・レイテンシーを抑えます。timeoutも合わせて延ばしてください（デフォルト30秒 → 最大5分）。 - ステップ5 — 機密文書はZDRプランで分ける
契約・医療・内部レポートはZDRが有効なEnterpriseキーで呼び出し、通常のRAGはstandardキーで分けます。キー単位でデータ保持ポリシーが変わります。
よくある質問
すでにUnstructured.ioやLlamaParseを使っているのですが、乗り換える価値はありますか?
速度・コスト面ではFire-PDFが優位ですが、「既存のスタックが壊れていないなら触るな」が正直なところです。乗り換えの本当の価値は、ウェブスクレイプとファイルパースが同じエンジンになる点にあります。ウェブデータを一緒に使うRAG/エージェントなら、出力フォーマット・課金・SDKが統一される運用の単純化が大きいです。ファイルだけを処理するワークフローなら、今すぐ移行する優先度は低いです。
Fire-PDFで表・数式の処理品質は実際どのくらい上がるのですか?
Firecrawlが公式の精度ベンチマークを公開しているわけではありませんが、アーキテクチャ自体が違います — 表はトークンバジェットを25秒まで優先し、数式はLaTeX保存プロンプトが別途あり、マルチカラムの読み順はニューラルモデルが予測してXY-cutをフォールバックにしています 。学術論文、金融レポート、法律文書のように「既存のOCRが表を崩して使えなかった」文書が主な恩恵を受ける領域と見てください。
50MBの制限がありますが、大きなPDFはどう処理するのですか?
2つのパターンがあります。(1) クライアント側でPDFをページ単位に分割（例：PyPDF2 split）してから/parseを並列呼び出し — 1回につき1ファイルが原則なのでバッチアップロードはありません 。(2) maxPagesオプションで最初のNページだけ抽出 — レポートの要約やメタ抽出なら十分です。数百MBの単一PDFは事実上(1)が唯一の答えです。
Lockdown Modeと一緒に使えますか?
現在Lockdownは/scrape専用です。/parseはoutboundリクエスト自体がないエンドポイント（ファイルのバイトを直接受け取る）なので、Lockdownのようなキャッシュのみの保護は意味がありません。ただしZDRオプションでレスポンス後にデータを即時破棄できるため、セキュリティワークフローのもう一つの層になります。2つの機能は異なる脅威モデルに対処します — Lockdownは「outboundから漏れる情報」、ZDRは「プロバイダーに残る情報」です。
さらに深掘りしたい人へ
Fire-PDF launch (Eric Ciarla, 4/14) Rustエンジンの5段階パイプラインとpdf-inspectorの分類ロジックを最も詳しく解説した1次資料。表・数式・マルチカラム処理の詳細も含む firecrawl.dev
Introducing /parse (Eric Ciarla, 4/28) エンドポイントのリリース発表。コード例（Python）とRAG ingestionパターン、ZDR活用シナリオまで簡潔にまとめた内容 firecrawl.dev
/parse 公式ドキュメント オプション・PDFモード・structured JSON・制限事項を1ページにまとめています。始める前に一度は見ておくべきリファレンス docs.firecrawl.dev
PDF Parser v2（前世代） Fire-PDFの直前世代であるPDF Parser v2のリリース背景。どんな限界からRustへの刷新に至ったのかが分かる firecrawl.dev
