anydoc 徹底レビュー：Firecrawl が Rust で構築した万能ドキュメント→Markdown ツール

TL;DR：LLM にドキュメントを与える際、フォーマット変換の品質が RAG の効果を直接左右します。テーブルが崩れ、見出しが乱れ、数式が消えれば、情報自体が失われます。Firecrawl チームは Rust でゼロから anydoc を開発しました。14 種類のオフィス形式（Word/PPT/Excel/PDF/EPUB/RTF/CSV/OpenDocument）を 1 つのライブラリでカバーし、中央変換速度はわずか 4.4 ミリ秒。品質スコアは Pandoc、Markitdown、Docling などの競合を全面的に上回ります。GitHub リリースから 3 週間で 17,000 以上の Star を獲得。本記事ではアーキテクチャの原理からデプロイ実践まで、2026 年最も注目されるドキュメント前処理ツールを徹底解説します。

1. anydoc とは？Firecrawl チームの「ドキュメント前処理エンジン」

anydoc は Firecrawl チームが 2026 年 8 月初旬にオープンソース化した Rust ライブラリで、ただ一つの課題を解決します：あらゆるオフィスドキュメント形式をクリーンな GitHub-Flavored Markdown に統一変換することです。

Firecrawl はもともと有名なウェブスクレイピング＆パース API サービス（Y Combinator 支援プロジェクト）ですが、ドキュメント解析に取り組む中で普遍的な課題に直面しました。市場にはすべての一般的なドキュメント形式を確実に処理できるライブラリが存在しなかったのです。開発者は 4〜5 個のツールを組み合わなければならず、それぞれに独自の依存関係、出力形式、障害パターンがありました。そこで彼らは自ら車輪を作ることを決意し、実は 2 つを作りました：

• pdf-inspector：PDF 専門、13k Star、各ページがテキストかスキャンか判定し、OCR の要否を決定
• anydoc：その他の全形式（Word/PPT/Excel/EPUB/RTF/CSV/OpenDocument）を処理し、テキスト型 PDF は pdf-inspector を内蔵して処理

2 つのライブラリ、同じ設計思想：Pure Rust、ローカル実行、API キー不要、システム依存なし、Markdown 出力。

ドキュメントバイト
  │
  ├─► 形式検出          → コンテンツマジックベース、拡張子に依存しない
  │
  ├─► 形式パーサー       → 各形式に 1 つのパーサー（doc/docx/ppt/pptx/xls/
  │                        xlsx/odt/ods/odp/rtf/epub/csv）
  │         │
  │         └─► Document → 共有ドキュメントモデル：ブロック、インライン、テーブル、脚注、リソース
  │               │
  │               └─► GFM シリアライザ → Markdown
  │
  └─► PDF → pdf-inspector → 直接 Markdown を出力

重要な設計：すべての形式が同じドキュメントモデルとシリアライザに集約されます。つまり、1 つの形式のバグ（例えばテーブルのエスケープ）を修正すれば、他のすべての形式も自動的に恩恵を受けます。

2026 年 8 月 21 日時点、anydoc の GitHub データ：

2. なぜドキュメント変換が RAG にとって重要なのか？

RAG（Retrieval-Augmented Generation）アーキテクチャでは、LLM の知識源は訓練データだけでなく、与えるプライベートドキュメントも含まれます。これらのドキュメントは以下の可能性があります：

• ユーザーがアップロードした Word 契約書
• 経理部門がエクスポートした Excel レポート
• プロダクトマネージャーが作成した PPT プレゼン
• テクニカルチームが書いた PDF ホワイトペーパー
• 歴史的な .doc ファイル（2003 年以前の形式）

フォーマットの喪失 = 情報の喪失。変換ツールがテーブルをプレーンテキストに平坦化し、見出し階層を壊し、数式を文字化けさせたら、LLM が受け取るのは欠損情報です。RAG の効果が直接低下します。

具体的な例を見てみましょう。Word ドキュメントに地域・四半期・売上高の 3 列を含む販売データテーブルがあるとします。低品質な変換ツールは以下のように出力するかもしれません：

地域 四半期 売上高
華東 Q1 100万
華東 Q2 150万

テーブル構造が失われると、LLM は「地域」と「四半期」が列名で、「100万」が「華東 Q1」の売上高であることを理解できません。一方、anydoc は標準的な Markdown テーブルを出力します：

| 地域 | 四半期 | 売上高 |
|------|--------|--------|
| 華東 | Q1     | 100万  |
| 華東 | Q2     | 150万  |

構造が完全に保たれ、LLM は各フィールドの意味を正確に理解できます。

これが、ドキュメント変換の品質が RAG の効果を直接左右する理由です。anydoc の設計目標は：入力形式に関わらず、構造が完全で意味が明確な Markdown を出力することです。

3. サポートされる 14 形式の詳細

anydoc は 14 種類の一般的なオフィス形式をカバーし、現在唯一「全形式カバー」を実現したオープンソースライブラリです：

3.1 形式検出：拡張子に依存しない

anydoc の形式検出はファイルコンテンツマジックに基づき、拡張子に依存しません。つまり、ファイルが誤った名前（例えば report.pdf が実際は Word ドキュメント）でも、anydoc は正しく識別して変換できます。

// Rust
Format::from_bytes(&bytes); // Some(Format::Docx), or None when nothing matches
Format::from_extension("pptm"); // Some(Format::Pptx)
Format::from_path(Path::new("report.odt")); // Some(Format::Odt)

# Python
import anydoc
anydoc.format_from_bytes(data)  # <Format.DOCX: ...>
anydoc.format_from_extension("pptm")  # <Format.PPTX: ...>

検出原理： - PDF：PDF ヘッダーマジック %PDF- を読み取り - RTF：RTF オープングループ {\\rtf を読み取り - OLE 形式（.doc/.ppt/.xls）：OLE ストリーム名を読み取り - ZIP パッケージ形式（.docx/.pptx/.xlsx/.odt など）：ZIP パッケージの mimetype とコンテンツタイプを読み取り - CSV：コンテンツマジックなし、拡張子または明示指定に依存

3.2 変換品質：完全なドキュメント構造を保持

anydoc はテキスト抽出だけでなく、完全なドキュメント構造を保持します：

• 見出し階層：H1-H6、アンカー付き
• テキストスタイル：太字、斜体、取り消し線、インラインコード
• コードブロック：構文ハイライトマーカー付き
• リスト：順序付き、順序なし、ネスト、タスクリスト（元の番号を保持）
• テーブル：結合セル、ヘッダー行
• 引用ブロック：blockquote
• 脚注と巻末注
• 数式：Word/PowerPoint の OMML、OpenDocument/EPUB の MathML、RTF 数式はすべて GitHub 風の LaTeX 数式記法に変換（$...$ インライン、$$...$$ ブロック）
• 埋め込みリソース：画像と埋め込みオブジェクトは Markdown で alt テキストとしてレンダリングされ、元のバイトはドキュメントモデルに保持（メディアタイプマーカー付き）

4. 技術アーキテクチャ：Rust 実装、4.4ms 中央値速度の秘密

anydoc のパフォーマンスは 3 つのコア設計判断から生まれます：

4.1 Pure Rust 実装、外部依存なし

anydoc はゼロから Rust で書かれ、LibreOffice、Python ライブラリ、その他の外部サービスに依存しません。Rust のゼロコスト抽象化とメモリ安全性により、anydoc はミリ秒単位で変換を完了し、メモリリークやセグメンテーションフォールトを回避します。

4.2 共有ドキュメントモデル + 単一シリアライザ

すべての形式のパーサーが同じ Document 構造を出力します：

pub struct Document {
    pub blocks: Vec<Block>,      // 段落、見出し、リスト、テーブルなど
    pub inlines: Vec<Inline>,    // 太字、斜体、リンクなど
    pub tables: Vec<Table>,      // テーブル
    pub footnotes: Vec<Footnote>, // 脚注
    pub assets: Vec<Asset>,      // 画像、埋め込みオブジェクト
}

そして 1 つの GFM（GitHub-Flavored Markdown）シリアライザで統一的にレンダリングします。これは以下を意味します： - 一貫性：入力が .docx でも .rtf でも、出力される Markdown 形式は完全に同一 - 保守性：1 つのバグ修正がすべての形式に恩恵 - 拡張性：新形式の追加はパーサー実装のみ、シリアライズロジックは再利用

4.3 ML モデルなし、純ルールベース解析

anydoc は機械学習モデルを使用せず、形式仕様に基づくルールベースの解析を行います。これにより： - 高速：中央変換時間 4.4ms（Ryzen 9 9950X3D でテスト） - 予測可能：モデル推論の不確実性がない - 低リソース：GPU 不要、CPU で実行可能

スキャン PDF については、anydoc は「OCR 必要」とマークし、外部ビジュアルパイプライン（Firecrawl の Fire-PDF サービスなど）に渡します。

4.4 バインディング設計：メインスレッドをブロックしない

• Node.js：変換は libuv スレッドプールで実行、イベントループをブロックしない
• Python：GIL を解放、他のスレッドが継続実行
• TypeScript 型と Python スタブ：パッケージ同梱、IDE 補完フレンドリー

5. Pandoc / Markitdown / Docling との比較

anydoc は唯一のドキュメント変換ツールではありません。主要競合との比較を見てみましょう：

5.1 機能カバレッジ比較

主な違い： - Pandoc はサポート形式が最多（40+）だが、出力品質は anydoc に劣る（後述のベンチテスト参照）。Haskell 依存が統合を複雑にする - Markitdown は Python ライブラリで、6 形式のみ対応、速度が遅い（134.8ms vs 4.4ms） - Docling は PDF と画像ドキュメントに特化、PyTorch が必要、4 形式のみ対応 - LibreOffice は完全なオフィススイートで、体积が大きい（数百 MB）、変換速度が遅い（1129.5ms） - Mammoth は docx のみだが、品質は良好（70 点）

5.2 公式ベンチテスト

Firecrawl チームは 100 の実ドキュメントで各ツールのパフォーマンスと品質をテストしました（Claude Sonnet 5 を LLM 審査員として使用）：

主な発見： - 速度：anydoc は最速の競合（mammoth）より 12 倍速く、最遅（libreoffice）より 256 倍速い - 品質：anydoc はテストされたすべての形式で最高スコア - カバレッジ：anydoc は 14 形式すべてをサポートする唯一のツール

5.3 形式別品質比較

注：mammoth の 70 点は docx 1 形式のみのスコアで、anydoc の 81 点は 14 形式全体のスコアです。形式別の比較が公平です。

5.4 選択の推奨

• anydoc を選択：複数形式を処理する必要があり、速度と品質を追求し、ゼロ依存を希望
• Pandoc を選択：形式変換（Markdown → PDF など）が必要で、Haskell 依存を容認
• Markitdown を選択：既存の Python エコシステム、基本形式サポートのみ必要
• Docling を選択：PDF と画像ドキュメントに特化、GPU リソースあり
• LibreOffice を選択：完全なオフィススイート機能が必要、体积と速度を容認

6. ローカルデプロイ実践：3 つの方法

anydoc は 3 つのデプロイ方法を提供し、様々なシーンに対応します：

6.1 CLI ツール：最速で始められる

# npx で一時的に実行（初回実行時にプリコンパイルバイナリをダウンロード）
npx @firecrawl/anydoc report.docx               # stdout に出力
npx @firecrawl/anydoc slides.pptx -o slides.md  # ファイルに出力
npx @firecrawl/anydoc - --format csv < data.csv # stdin から読み取り

# グローバルインストール
npm install -g @firecrawl/anydoc
anydoc report.docx -o report.md

適用シーン：クイックテスト、スクリプト統合、CI/CD パイプライン。

6.2 Python SDK：RAG パイプラインに最適

pip install firecrawl-anydoc

import anydoc

# ファイルパスから変換
markdown = anydoc.to_markdown("contract.docx")
print(markdown)

# バイトから変換（自動形式検出）
with open("report.pdf", "rb") as f:
    data = f.read()
markdown = anydoc.to_markdown_bytes(data)

# 形式を明示指定（CSV に必要）
markdown = anydoc.to_markdown_bytes(csv_data, "csv")

# 完全なドキュメントモデルを取得（埋め込みリソース含む）
document = anydoc.to_document("presentation.pptx")
print(document.blocks)  # ドキュメント構造にアクセス
print(document.assets)  # 埋め込み画像にアクセス

適用シーン：Python RAG パイプライン、バッチ処理、LangChain/LlamaIndex との統合。

6.3 Node.js SDK：Web アプリケーション統合

npm install @firecrawl/anydoc

import { toMarkdown, toDocument } from '@firecrawl/anydoc';

// ファイルパスから変換
const markdown = await toMarkdown('contract.docx');

// バイトから変換
const buffer = fs.readFileSync('report.pdf');
const markdown = await toMarkdownBytes(buffer);

// 完全なドキュメントモデルを取得
const document = await toDocument(buffer);
console.log(document.blocks);

適用シーン：Node.js Web アプリ、Express/Fastify バックエンド、リアルタイムドキュメントプレビュー。

6.4 WebAssembly：ブラウザで実行

anydoc は WebAssembly にコンパイルしてブラウザでローカル実行でき、ファイルはサーバーにアップロードされません：

npm install @firecrawl/anydoc-wasm

import init, { toMarkdownBytes } from '@firecrawl/anydoc-wasm';

await init();

const file = document.getElementById('file-input').files[0];
const buffer = await file.arrayBuffer();
const markdown = toMarkdownBytes(new Uint8Array(buffer));

適用シーン：プライバシー重視のシーン、オフラインアプリケーション、サーバー負荷削減。

6.5 Docker デプロイ

anydoc には公式 Docker イメージはありませんが、自分でビルドできます：

FROM node:20-alpine

RUN npm install -g @firecrawl/anydoc

WORKDIR /app
CMD ["anydoc"]

docker build -t anydoc .
docker run -v $(pwd):/app anydoc report.docx -o report.md

適用シーン：コンテナ化デプロイ、Kubernetes クラスター、マイクロサービスアーキテクチャ。

7. 実践：ドキュメント前処理パイプラインの構築（anydoc + RAG）

ユーザーがアップロードする様々なドキュメントを処理する完全な RAG パイプラインを構築しましょう：

7.1 アーキテクチャ設計

ユーザーがドキュメントをアップロード → anydoc で変換 → テキスト分割 → Embedding → ベクトル DB → 検索 → LLM 生成

7.2 Python 実装

import anydoc
import os
from pathlib import Path
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma

# 1. ドキュメント変換
def convert_document(file_path: str) -> str:
    """任意形式のドキュメントを Markdown に変換"""
    try:
        markdown = anydoc.to_markdown(file_path)
        return markdown
    except anydoc.ConvertError as e:
        print(f"変換失敗: {e}")
        return None

# 2. テキスト分割
def chunk_text(text: str, chunk_size: int = 1000, overlap: int = 200):
    """長文テキストを小块に分割"""
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=chunk_size,
        chunk_overlap=overlap,
        separators=["\n## ", "\n### ", "\n\n", "\n", " ", ""]
    )
    return splitter.split_text(text)

# 3. ベクトルデータベース構築
def build_vector_store(chunks: list, collection_name: str = "documents"):
    """テキストブロックをベクトルに変換して保存"""
    embeddings = OpenAIEmbeddings()
    vectorstore = Chroma.from_texts(
        texts=chunks,
        embedding=embeddings,
        collection_name=collection_name
    )
    return vectorstore

# 4. 完全なパイプライン
def process_document_pipeline(file_path: str):
    """完全なドキュメント処理パイプライン"""
    # 変換
    print(f"変換中: {file_path}")
    markdown = convert_document(file_path)
    if not markdown:
        return None

    # Markdown を保存（オプション）
    output_path = Path(file_path).with_suffix('.md')
    output_path.write_text(markdown, encoding='utf-8')
    print(f"Markdown 保存完了: {output_path}")

    # 分割
    chunks = chunk_text(markdown)
    print(f"{len(chunks)} 個のブロックに分割")

    # ベクトル DB 構築
    vectorstore = build_vector_store(chunks)
    print("ベクトルデータベース構築完了")

    return vectorstore

# 5. バッチ処理
def batch_process(directory: str):
    """ディレクトリ内の全ドキュメントをバッチ処理"""
    supported_extensions = {
        '.doc', '.docx', '.docm',
        '.ppt', '.pptx', '.pptm',
        '.xls', '.xlsx', '.xlsm',
        '.odt', '.ods', '.odp',
        '.rtf', '.epub', '.csv', '.pdf'
    }

    for file_path in Path(directory).rglob('*'):
        if file_path.suffix.lower() in supported_extensions:
            print(f"\n処理中: {file_path}")
            process_document_pipeline(str(file_path))

# 使用例
if __name__ == "__main__":
    # 単一ファイル処理
    vectorstore = process_document_pipeline("contract.docx")

    # バッチ処理
    # batch_process("./documents")

7.3 LangChain との統合

from langchain.document_loaders import BaseLoader
from langchain.schema import Document
import anydoc

class AnyDocLoader(BaseLoader):
    """anydoc ドキュメントローダー"""

    def __init__(self, file_path: str):
        self.file_path = file_path

    def load(self) -> list[Document]:
        """ドキュメントを読み込んで変換"""
        markdown = anydoc.to_markdown(self.file_path)
        metadata = {"source": self.file_path}
        return [Document(page_content=markdown, metadata=metadata)]

# 使用例
loader = AnyDocLoader("report.pdf")
docs = loader.load()

# LangChain パイプラインとの統合
from langchain.chains import RetrievalQA
from langchain.llms import OpenAI

qa = RetrievalQA.from_chain_type(
    llm=OpenAI(),
    chain_type="stuff",
    retriever=vectorstore.as_retriever()
)

result = qa.run("このレポートの主な発見は何ですか？")
print(result)

7.4 エラーハンドリング

anydoc のエラータイプ：

import anydoc

try:
    markdown = anydoc.to_markdown("document.pdf")
except anydoc.ConvertError as e:
    if isinstance(e, anydoc.EncryptedError):
        print("ドキュメントが暗号化されています")
    elif isinstance(e, anydoc.UnsupportedError):
        print("サポートされていない形式です")
    elif isinstance(e, anydoc.MalformedError):
        print("ドキュメント構造が破損しています")
    elif isinstance(e, anydoc.ResourceLimitError):
        print("リソース制限を超過しました")
    else:
        print(f"変換エラー: {e}")
except OSError as e:
    print(f"ファイル読み取りエラー: {e}")

8. パフォーマンスベンチマーク実測

anydoc の実際のパフォーマンスを検証するため、様々なシナリオでテストを行いました：

8.1 テスト環境

• CPU: AMD Ryzen 9 7950X
• メモリ: 64GB DDR5
• OS: Ubuntu 22.04
• Python: 3.11
• anydoc: 最新版

8.2 単一ファイル変換速度

結論：ほとんどのドキュメントが 10ms 以内に変換完了し、公式宣称の「一桁ミリ秒」パフォーマンスに適合しています。

8.3 バッチ処理パフォーマンス

100 件の混在形式ドキュメントを処理：

8.4 競合との実測比較

10 件の典型的なドキュメントを選び、各ツールの変換時間と品質を比較しました：

anydoc は速度で 1 桁以上领先し、品質スコアも最高、メモリ使用量も最低です。

9. 制限事項と注意点

anydoc は優れたパフォーマンスを発揮しますが、いくつかの制限に注意する必要があります：

9.1 サポートされない形式

• 画像型 PDF：スキャン PDF は外部 OCR サービス（Tesseract、Firecrawl Fire-PDF など）が必要
• 暗号化ドキュメント：パスワード保護されたファイルは変換不可、Encrypted エラーをスロー
• 旧 Mac 形式：.pages、.numbers、.key はサポートなし
• 画像形式：.jpg、.png などの画像ファイルは直接サポートなし（先に OCR 必要）

9.2 既知の制限

• 複雑なレイアウト：多段レイアウト、テキスト回り込み画像などの複雑なレイアウトは失われる可能性
• 埋め込みオブジェクト：Excel グラフ、Word に埋め込まれた OLE オブジェクトは alt テキストのみ保持
• マクロとスクリプト：VBA マクロ、JavaScript スクリプトは変換されない
• 超大規模ファイル：リソース制限を超えるドキュメントは ResourceLimit エラーをスロー

9.3 バージョン互換性

• 旧版 Office：.doc/.ppt/.xls（Office 97-2003）はサポートされるが、.docx/.pptx/.xlsx ほど品質は高くない
• WPS 形式：WPS で生成されたドキュメントは通常互換性があるが、公式テストはされていない
• Google Docs：.docx でエクスポートしてから変換するのが最適

9.4 本番環境の推奨

1. エラーハンドリング：常に ConvertError をキャッチし、失敗ファイルを記録
2. リソース制限：大規模ファイルにはタイムアウトを設定し、ブロッキングを回避
3. 形式検証：変換後に出力品質をチェックし、必要に応じて人手でレビュー
4. 元ファイルのバックアップ：変換前に元のドキュメントを保持
5. パフォーマンス監視：変換時間を記録し、異常があれば即座に調査

10. よくある質問 FAQ

1. anydoc と pdf-inspector の違いは何ですか？

pdf-inspector は PDF に特化し、各ページがテキストかスキャンかを判定し、OCR の要否を決定します。anydoc はその他の全形式（Word/PPT/Excel/EPUB/RTF/CSV/OpenDocument）を処理し、テキスト型 PDF は pdf-inspector を内蔵して処理します。両者を組み合わせることで、すべての一般的なドキュメント形式をカバーします。

2. anydoc には API キーが必要ですか？

いいえ。anydoc は完全にローカルで動作するオープンソースライブラリで、API キーもネットワーク接続も外部サービスも不要です。すべての変換はローカルで完了します。

3. anydoc は中国語ドキュメントをサポートしていますか？

はい。anydoc は Unicode ベースで、中国語、日本語、韓国語などの多言語ドキュメントを完璧にサポートします。変換後の Markdown は元の言語とエンコーディングを保持します。

4. スキャン PDF はどのように処理すればよいですか？

anydoc はテキスト型 PDF のみ処理できます。スキャンについては： 1. anydoc で OCR が必要なページを検出 2. スキャンページを OCR サービス（Tesseract、Firecrawl Fire-PDF など）に渡す 3. 結果をマージ

コード例：

import anydoc

try:
    markdown = anydoc.to_markdown("scanned.pdf")
except anydoc.UnsupportedError:
    # OCR サービスを呼び出し
    ocr_result = call_ocr_service("scanned.pdf")
    markdown = ocr_result.text

5. anydoc は商業利用できますか？

はい。anydoc は MIT ライセンスで、商業利用、改変、再配布が無料で許可されています。

11. 総評

長所

✅ 包括的な形式カバレッジ：14 形式、全形式カバーを実現した唯一のオープンソースライブラリ
✅ 卓越したパフォーマンス：中央速度 4.4ms、競合より 12〜256 倍高速
✅ 最高品質：LLM 審査員スコア 81、全面的にリード
✅ ゼロ依存：Pure Rust 実装、外部サービス不要
✅ 多言語バインディング：Rust/Node.js/Python/WebAssembly
✅ オープンソース無料：MIT ライセンス、商用利用可能

短所

❌ スキャン PDF 非対応：外部 OCR サービスが必要
❌ 暗号化ドキュメント非対応：パスワード保護ファイルは変換不可
❌ 複雑なレイアウトが失われる：多段レイアウト、テキスト回り込みなどが失われる可能性
❌ プロジェクトが新しい：2026 年 8 月にリリースされたばかりで、エコシステムはまだ構築中

適用シーン

• ✅ RAG パイプラインのドキュメント前処理
• ✅ ナレッジベース構築
• ✅ ドキュメント検索エンジン
• ✅ AI アシスタントのドキュメント理解
• ✅ 企業ドキュメント移行
• ✅ コンテンツ管理システム

非適用シーン

• ❌ スキャン OCR（専門 OCR ツールが必要）
• ❌ 複雑なレイアウト保持（専門レイアウトツールが必要）
• ❌ 形式変換（Markdown → PDF など、Pandoc が必要）

最終スコア

推奨度：⭐⭐⭐⭐⭐（強く推奨）

anydoc は現在最も優れたオープンソースのドキュメント→Markdown ツールであり、特に複数形式を扱い、速度と品質を追求する本番環境に最適です。RAG パイプラインやナレッジベースシステムを構築しているなら、anydoc は第一選択となるべきです。

参考リンク： - GitHub リポジトリ：https://github.com/firecrawl/anydoc - Firecrawl 公式ブログ：https://www.firecrawl.dev/blog/anydoc-and-pdf-inspector - オンラインデモ（WebAssembly）：https://firecrawl.github.io/anydoc/ - Firecrawl Parse API（ホストサービス）：https://firecrawl.dev/parse