Doclingレビュー：IBMのドキュメント→Markdown変換ツールはPDFに何をしているのか

DoclingはよくWebスクレイパーと同じ括りで語られますが、実際はまったく別モノです。IBM Research発で、いまは LF AI & Data Foundation 配下のプロジェクトになっているドキュメント変換ツールキットで、手元にあるファイル（PDF、DOCX、PPTX、XLSX、HTML、画像）を Markdown または JSON に変換します。公式のキャッチコピーも、そのまま「Get your documents ready for gen AI.」です。

つまり、これはクローラーではなく変換ツールの実地レビューです。以下の内容はすべて、CPUのみの1台のマシン（macOS arm64、Python 3.14.2、Docling 2.111.0）で計測し、スクリプトで採点し、失敗は失敗として記録しました。リポジトリはかなり大きく、日々更新されています。たとえば 63,069 stars、4,449 forks があり、メタデータを取った当日にも push がありました。そのため、ここにある issue 数やバージョン番号は固定値ではなく、あくまでその時点のスナップショットとして見てください。

Docling は実際には何で、何ではないのか

Docling のすべての中心にある単位は DoclingDocument です。ファイルをこの構造に解析し、そこから Markdown、HTML、DocTags、またはロスレス JSON を出力します。コードは MITライセンス（個別モデルのライセンスは異なります）で、起源は IBM Research Zurich にあります。執筆時点の最新リリースは v2.112.0 で、これを実行する2日前に公開されていました。

目玉は PDF と画像の処理です。しかも、これはただの文字列パースではありません。RT-DETR のレイアウトモデル、TableFormer の表構造モデル、オプションの vision-language model、そしてスキャン用の RapidOCR という機械学習モデル群でできています。これらのモデルが、ページレイアウト、読み順、表構造を復元します。まさにレビューする価値があるのはこの部分で、HTML だけのテストでは見えてこない領域です。

ひとつ大事な切り分けがあります。Docling は何も取りにいきません。JavaScript のレンダリングもしないし、アンチボット対策も突破しないし、クロールもしません。あなたがファイルを渡し、Docling はそれを理解します。クロールは別のツールの仕事です。ここはあとで重要になります。なぜなら、Docling が Firecrawl の代わりになるのかと聞かれたとき、答えは違うからです（実際には補完関係で、その理由は後ほど説明します）。

最初の実行で誰も警告してくれないこと

pip install docling は Python 3.14.2 で問題なく通ります。ですが venv を見ると、サイズは 1.3 GB。Docling は、たとえ HTML ファイルしか変換しなくても、ML スタック全体を強い依存関係として引き込みます。

依存関係	ディスク上のサイズ（MiB, du）
torch (2.13.0)	536
opencv (cv2)	119
transformers (5.8.1)	101
scipy	99
sympy	76
pandas	72
rapidocr（+ 同梱モデル）	72.1
docling_parse	30

これは、まだ PDF を1つも変換する前の話です。最初の PDF 変換で本当の重さが出ます。というのも、そのタイミングでモデルのダウンロードが始まるからです。新規の、分離された HuggingFace キャッシュ環境では、最初の PDF 変換に約224秒かかりました — しかも、その大半は計算ではなくダウンロードです。レイアウトモデルと TableFormer モデルは、ディスク上で 約506 MiB（TableFormer 342 MiB + レイアウト 164 MiB、du で確認）を占め、RapidOCR は PP-OCRv4 の重みを約40 MB、site-packages 配下に取得します。同じファイルを2回目に変換すると？ 0.55秒。モデルはキャッシュされるので、通行料を払うのは一度だけです。

ひとつ、無視してよい数値があります。coldstart スクリプトは model_download_mb に 1060.2 と表示しますが、これはフットプリントとして引用すべき数ではありません。os.walk が symlink をたどってしまうためで、HuggingFace のキャッシュは各モデルファイルを blobs/ に1回だけ保存し、それを snapshots/ から symlink で再公開します。そのため walk が14個のモデルファイルを二重に数えてしまうのです。du と一致する、symlink を重複排除した値は 約506 MiB（blobs のみで 505.4 MiB）です。Docling をベンチマークする人への教訓は、ダウンロード量とディスク使用量は別々に報告することです。実際に別物だからです。

Docling のコンテナを作る人が引っかかる、もうひとつの論点があります。重みの保存先は2か所に分かれ、ダウンロードのタイミングも異なります。レイアウトと TableFormer のモデルは HF_HOME に従い、最初の PDF 変換時にダウンロードされます。一方で RapidOCR のモデルはそうではありません。…/site-packages/rapidocr/models/ に置かれるため、キャッシュ設定を完全に無視します。イメージを事前に焼き込む場合や air-gapped 環境に持ち込む場合は、両方のキャッシュを処理する必要があり、HF_HOME を設定しただけでは後者は捕まえられません。

ただし、公平に言うと、Docling の以前のリリースからはかなり改善されています。プロジェクトは docling-slim を提供しており、これは torch を引っ張らずに HTML 用として pip install docling-slim[format-html] できる、約50 MB のコア版です。したがって、1.3 GB という重さはデフォルトの docling メタパッケージでは本当ですが、今では回避可能です。私は依然として pip install docling で入るデフォルト版をテストしましたが、この重さは未解決の欠陥ではありません。モジュール化された解決策はすでに存在し、issue #2393 で追跡されています。

セットアップ中、ひとつ小さな痛点もありました。import docling; docling.__version__ を実行すると AttributeError: module 'docling' has no attribute '__version__' になります。モジュール側でバージョンを公開していないのです。正しく確認する方法は importlib.metadata.version("docling") で、これは '2.111.0' を返します。DX上のちょっとした不便ですが、2026年7月から issue #3733 として upstream で公開中 です。

表の忠実度：TableFormer が真価を発揮する場所

表があるからこそ、誰かが単純な PDF→テキスト変換ではなく Docling を使うわけです。そこで、機械可読な正解データを持つ7つの表入り PDF を作成し、セル単位で出力を評価しました。重要な指標は2つで、似て非なるものです。cell recall は、検出された表のどこかに正解値が存在した割合。in-row rate は、正しい行に入った割合です。この2つを混同するとツールを過大評価してしまうので、両方を示します。

表（ストレス条件）	検出	Cell recall	In-row rate	備考
T1: 枠線ありの単純なグリッド（8行×5列）、ページ単独	No	0.0	—	<!-- image --> と分類され、全セルが落ちた
T2: 枠線なし（ヘッダーの罫線のみ）	Yes	1.00	1.00	完璧、正確なグリッド
T3: 2段階の colspan を持つ結合ヘッダー	Yes	1.00	0.97	すべての値は検出、ただし1つのヘッダー値が1行ずれる
T4: rowspan を持つ行ラベル、ページ単独	No	0.0	—	<!-- image --> と分類
T5: colspan ヘッダー + 枠線なし	Yes	1.00	0.97	すべての値は検出、T3 と同じヘッダー行のずれあり
T6: 財務表、空白列あり、右寄せ	Yes	1.00	1.00	空白列も保持、ずれなし
T7: 幅の広い12列グリッド	Yes	1.00	1.00	幅広表でも列ずれなし

Docling が検出した5つの表では、正解値はすべて拾えており、cell recall は全表で 1.00 でした。その5つのうち3つでは、すべての値が正しい行にも入りました。2段階ヘッダーのケース（T3 と T5）では、1つのヘッダー値だけが元の行から外れ、in-row rate は 0.97 に下がりました。つまり、データ自体は存在しており、積み重なったヘッダーで行の割り当てが1つ揺れた、ということです。

構造が厳しいケースでも、想像よりしっかり対応していました。2段階の colspan ヘッダーは GitHub Flavored Markdown に正しく平坦化されました（「Q1 2026」というラベルが、またがっている2列の上に繰り返し表示されるのは、colspan を GFM に落とし込む正しいやり方です）。ヘッダー罫線だけの枠線なしグリッド（T2）もそのまま通りました。12列の広い表（T7）でも列ずれは起きませんでした。そして、空白の財務列（T6）も、消えたり圧縮されたりせず、空セルのまま保持されました。これは 公式の TableFormer TEDS スコア と整合的です。モデルカードでは simple 95.4、complex 90.1、all-tables 93.6 とされ、Camelot（73.0）や EDD（88.3）よりかなり上です。

結合セルについては注意が必要です。というのも、逆のことを言っている open issue があるからです。issue #3698 は、V1 と V2 が結合行・結合列を正しく扱えないと報告しています。私のフィクスチャでは、単純な colspan（T3/T5）と rowspan の値は正しく平坦化され、上で述べたマルチレベルヘッダーの1行ずれ以外はありませんでした。ただし #3698 の失敗例は、複雑で不規則な多行・多列結合や、複数ページにまたがる表 といった、より病的なケースです。私のケースは単純な側です。したがって正確な言い方はこうなります。ここでは単純な colspan と rowspan は復元できた（ただしマルチレベルヘッダーは1行ずれることがある）。複雑で不規則な結合は、依然として未解決の問題です。決して「結合セルは全部動く」でも、「結合セルは全部壊れる」でもありません。

落とし穴：1ページに単独である表は消えることがある

先ほどの表を見返してください。T1 と T4 は、そもそも検出されませんでした。Docling は <!-- image --> を出力し、エラーを出さないまま全セルを捨てました。T1 はごく普通の、枠線付き 8行×5列のグリッドです。これはかなり気がかりだったので、表パースの弱さと断定する前に、何が本当に引き金なのかを切り分けるため、スクリプトで A/B テストを組みました。

まず、ありそうな説明を順番に潰しました。テキスト層は無傷です。pypdfium2 は T1 から 327 文字、T4 から 221 文字を読み取れたので、これはスキャン画像ではなく、実際のデジタル PDF です。OCR をオフ（do_ocr=False）にしても改善しません。表は依然として落ちます。さらに DoclingDocument を直接見ると、len(doc.tables) == 0 なのに len(doc.pictures) == 1 でした。つまりレイアウトモデルが、その表領域全体を Picture として分類していたのです。

そして決定打となるテストを行いました。同じ T1 と T4 の表を、今度は普通の本文パラグラフで囲んで再レンダリングし、再度変換しました。すると両方とも完璧に通りました。len(doc.tables) == 1 となり、正しい GFM の表が出力され、T4b の rowspan ラベル「North」は3行にわたって正しく繰り返されました。表は同じです。変えたのは、それがスパースなページ上で単独だったのか、本文中に埋め込まれていたのか、ただそれだけでした。

つまり本当の注意点は、TableFormer が脆いということではありません。Docling の RT-DETR レイアウトモデルはページの文脈を使うため、ほとんど何もないページに単独で置かれた小さな表は、Picture として読まれて静かに捨てられやすい、ということです。実務ではかなり起こりやすいです。請求書、仕様書、切り出しエクスポートは、まさに「1ページに1表、周囲の文章なし」という形になりがちだからです。対策は地味ですが効きます。レイアウトモデルにページ文脈を与えるか、変換後に doc.tables をチェックして、件数が0のページをフラグすることです。これは issue #3495（Table と Picture の両方として検出される表）に近い話ですが、ページのスパースさが引き金になる、つまり同じ表が単独だと落ち、文脈に埋めると通る、という点については、公開された記述を見つけられませんでした。計測して確認したが、まだ文書化されていない現象です。誰も知らないバグではありませんが、少なくとも私は既出の形では見つけられませんでした。

実スキャンでの OCR：EasyOCR ではなく RapidOCR

スキャン PDF は、多くの変換ツールが静かに失敗する領域です。そこで、測定上 0 文字のテキスト層 を持つ本物のスキャン2本を Docling に通しました。pypdfium2 でも復元可能な文字数は0と出ており、出力が OCR であり、裏に隠れたテキスト層ではないことが確認できます。

1ページの ocr_test.pdf は、CPU上で 14.3 秒できれいに復元されました。「Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package」と、そのまま読める形で出力されています。4ページの nemotron_multipage.pdf では、4ページすべてに OCR がかかり、合計 70.1 秒（17.5 秒/ページ）で、各ページに同じテスト文が出ました。デフォルト OCR は自動で動作し、フラグも設定も不要でした。

多くの解説記事が間違えている点を挙げると、デフォルト OCR エンジンは RapidOCR であり、EasyOCR ではありません。初回実行時に PP-OCRv4 の .pth 重みがダウンロードされるのを確認して、この点を確かめました。既存のブログや古い Docling の FAQ には、いまだに EasyOCR がデフォルトだと書いているものが多いですが、それは古い情報です。EasyOCR は今では、必要なら追加で有効化するオプションです。変わらず正しい注意点は、OCR は大規模処理では遅い経路である ことです。ここでの数字はすべて CPU の上限であり、GPU があればかなり短縮できます。

実際の PDF、読み順、そしてページあたりの時間

合成フィクスチャは個別の挙動を証明しますが、実在の PDF こそが「本当に動く」ことを示します。そこで、2つの born-digital な学術論文 — 9ページの Docling 技術レポートと、15ページの “Attention Is All You Need” — を試しました。どちらも2段組で、表と数式を含みます。

15ページの Attention 論文では、Abstract、Introduction、Background、Conclusion、References の5つのセクションマーカーが、2段組レイアウトにもかかわらず、線形化された Markdown の中で 文書順に 現れました。さらに、Transformer、encoder、BLEU、multi-head といった内容のプローブもすべて存在し、有名な多段組の結果表は4つの検出表として認識されました。これは本物の読み順復元と列の統合復元であり、RAG のチャンク分割における核心的価値です。2段組ページを線形化したときに順序が崩れると、意味のあるチャンクにはできません。

時間の面では、少し意外な教訓があります。ページあたりの時間を決めるのはページ数ではなく、各ページにどれだけ構造が詰まっているかです。より密な9ページのレポートは 14.95秒/ページ で、15ページの論文の 5.99秒/ページ より遅くなりました。これは、9ページに3表、15ページに4表というように、1ページあたりの表や図が多く、そのたびにレイアウト推論と TableFormer 推論が追加で走るためです。もちろん差は薄く、絶対数で見れば密な文書のほうが表は少なく、より多いわけではありません。したがって、CPU 上の「秒/ページ」は長さではなく構造密度の関数です。これは1回の CPU 実行結果であり、実運用値ではなく上限値です。

マルチフォーマット対応と、ロスレス JSON という主張

Docling は統一的なマルチフォーマット解析をうたっているので、DOCX、XLSX、PPTX をそれぞれ既知の内容と正解プローブ付きで作成し、2点を確認しました。Markdown にプローブは現れるか、export_to_dict() 経由の JSON ラウンドトリップで生き残るか、です。

ファイル	変換時間（秒）	Markdown でプローブ検出	Markdown 内の表数	JSON でもプローブ維持
report.docx（見出し + 結合した“Total”表 + 箇条書き）	0.137	7/7	1	Yes
workbook.xlsx（2シート、空白列あり）	0.016	6/6	2	Yes
deck.pptx（3スライド、箇条書き + 表）	0.038	6/6	1	Yes

すべての内容プローブは Markdown に入り、表も復元され（DOCX の結合された “Total” 行と、XLSX の両シートを含む）、さらに各プローブは export_to_dict() の JSON でも維持されました。これが、少なくともクリーンな入力においては、ロスレス DoclingDocument という主張を裏づける証拠です。これらの形式は、ML モデルではなく形式ネイティブのバックエンドで処理されるため、数十ミリ秒で終わり、完全にオフラインで動作します。対象範囲は誠実です。各形式で1つのクリーンファイルを通しただけで、広さは示せますが、病的な Office ファイルのストレステストにはなっていません。

HTML：忠実だが、きれいではない

これは、Docling を RAG パイプラインに入れるかどうかを決める重要な注意点です。よく読んでください。Docling は HTML 文書全体を変換します。Readability のようなメインコンテンツ抽出はしません。サイトの装飾要素がどの程度残るかを、Docling 自身の出力から nav、TOC、cookie、footer のマーカー行を数えて評価しました。

ページ	空行を除く Markdown 行数	ボイラープレート行	ボイラープレート率	本文開始行
Wikipedia "Web scraping"	255	34	13.3%	28
scrapethissite/forms	63	1	1.6%	—
books.toscrape	65	0	0.0%	—
quotes.toscrape	35	0	0.0%	—

Wikipedia のように装飾の多いページでは、Markdown 行の約13% が nav/TOC/footer のボイラープレートで、本文は28行目まで始まりません。出力は「move to sidebar / Contents / Toggle the table of contents」で始まり、「CS1 maint… / Search Wikipedia」で終わります。books や quotes のようなきれいなコンテンツページでは約0%なので、これはページごとの固定コストではなく、テンプレート由来の装飾問題です。Docling はきれいなメイン記事抽出ではなく、文書全体を忠実に Markdown 化します。HTML の装飾問題は、上流では issue #1865（クローズ）と #1930（オープン）で追跡されています。

この評価を公平にするため、2点補足しておきます。まず HTML に関しては、Docling は ML モデルを一切使いません。単純なパイプライン上の BeautifulSoup バックエンドです。「あなたのページを vision model が読んでいる」という話は PDF と画像にのみ当てはまります。HTML を渡しても、レイアウトや TableFormer の仕組みは動きません。次に、PDF パスではヘッダーとフッターの装飾分類は試みられるので、「ボイラープレート除去が全くない」と言い切るのは強すぎます。装飾をそのまま返してくるのは、あくまで HTML バックエンドです。

他ツールとの比較と、Thunderbit の位置づけ

Webデータ抽出に Thunderbit を試す

Docling と比較されやすい基準ツールは Firecrawl なので、位置づけを表にしておきます。ひとつ注意点があります。これは同一マシンでのベンチマークではなく、ドキュメントレベルの比較です。Firecrawl はこれらのフィクスチャで実測していません。ここで実測しているのは Docling 側のみで、Firecrawl 側は公開ドキュメントからの情報です。

観点	Firecrawl（ドキュメント上）	Docling（今回の計測）
主な役割	ライブウェブをクロール + スクレイプ → Markdown	手元にあるドキュメント → Markdown/JSON へ変換
取得 / JSレンダリング / アンチボット	あり（ホスト型ブラウザ）	なし — ファイルを渡すだけ
メインコンテンツ抽出	あり	なし — 文書全体を忠実に保持（Wikipediaで約13%が装飾）
PDF の表構造（ML）	限定的	あり — TableFormer（公式 TEDS 93.6、検出済みフィクスチャでは cell recall 1.00、in-row 0.97–1.00）
スキャンPDF / OCR	限定的	あり — デフォルトは RapidOCR（0文字のスキャンを復元）
対応フォーマット	Webページ	PDF/DOCX/PPTX/XLSX/HTML/EPUB/画像
デプロイ	ホスト型 API（+ self-host）	ローカル pip ライブラリ、オフライン、APIキー不要
導入コスト	APIキー / 軽量クライアント	デフォルト導入で1.3 GB + 約506 MiB のモデル（または docling-slim）
ライセンス	商用 / source-available	MIT

ひとことで言うと、データがライブウェブ上にあって、クロール、JSレンダリング、メインコンテンツの整形が必要なら Firecrawl が向いています。すでに文書を持っていて、特に PDF、スキャン、表の多い Office ファイルを、構造を保ったまま忠実に、オフラインで変換したいなら Docling です。両者は補完関係にあります。現実的なパイプラインでは、一方でクロールし、もう一方で文書を変換します。

ここで Thunderbit についても正直に言います。私はこの会社で働いているので、違うふりをするつもりはありません。Thunderbit と Docling は同じ仕事をしているわけではなく、無理に同一視するつもりもありません。開発者向けに言うと、Thunderbit は AI スクレイピング API、MCP サーバー、CLI を備えたツールで、対象は ライブウェブページ です。POST /distill は URL をクリーンで LLM 向けの Markdown に変換し、Docling が明示的に触れない JS レンダリング、アンチボット、CAPTCHA も処理します。POST /extract は、あなたが定義した JSON Schema に合わせた構造化 JSON を返します。これは RAG パイプラインの「取得して整える」側です。Docling はローカル文書側、つまりディスク上にある PDF、スキャン、スプレッドシートです。コーパスが Web ページなら、Thunderbit の API、MCP ツール（thunderbit_suggest_fields、thunderbit_distill、thunderbit_extract）、または CLI（npx @thunderbit/thunderbit-cli）を使ってください。PDF とスキャンなら Docling です。両方あるなら — 実際のパイプラインの多くはそうです — 両方を組み合わせればよく、どちらも相手の代わりではありません。

結論：暫定評価、ただし宿題は残る

ここで 0–100 の単一スコアは出しません。なぜなら、加重合計を作ってしまうと、Docling がそもそもやると主張していないこと（たとえばクロール）に対する減点まで織り込むことになり、比較可能なものとして扱ってしまうからです。私が試したフィクスチャでは、各観点ごとにこう評価できます。

• セットアップ / 初回起動: 重い — 1.3 GB の venv、約506 MiB のモデル、初回 PDF で約224秒、ウォーム時約0.55秒。ただし docling-slim で重さは回避可能。
• 表の忠実度: 表が検出されたときは強い（5/5で cell recall 1.00、in-row 0.97–1.00）。公式 TEDS の説明とも整合的。
• 表検出の堅牢性: スパースページの落とし穴あり — 単独の表が Picture として落ちることがある。doc.tables を後で確認すべき。
• スキャン / OCR: 動作する。デフォルトは RapidOCR。ただし大規模では遅い。
• マルチフォーマット: 安定しており、JSON ラウンドトリップも維持。
• HTML: 忠実だがきれいではない — メインコンテンツ抽出はなし。
• 開発者体験: 3行で使える API と整理された DoclingDocument は良いが、__version__ が公開されていない。

向いている人：PDF、スキャン、Office ファイルを扱う RAG やデータパイプラインを作っていて、オフラインかつ構造を保った変換と、本物の表・OCR 理解がほしいチーム。向いていない人：ライブウェブのクロールや、きれいな本文だけの HTML 抽出が必要な人。そこは別の道具です。

そして、これはプレスリリースではなくレビューなので、限界もそのまま書いておきます。これはターゲットを絞った検証であり、7つの合成表と2つの実在PDFを、1台の CPU-only マシンで試したものに過ぎません。TEDS 規模の精度ベンチマークではありません。以下は未検証です。実運用で Docling に賭ける前に、あなた自身が確認すべき項目です。オプション VLM（GraniteDocling）経路、実際の docling-slim のフットプリント、GPU 実行、複雑・不規則な結合セルや複数ページ表、数式から LaTeX への忠実度、そして本番で最も驚かれやすいであろう、バッチ処理でのメモリ増加、スレッド / GIL スケーリング、数千回の変換にわたるオブジェクトライフサイクルの耐久性です。Docling は、主張していることに対しては強いです。誇張ではなく計測でそう言えます。ただし、実際に使う前に把握しておきたい癖もあります。スパースページの注意点を理解し、初回ダウンロード分を予算化し、スケール時の挙動は自分で確認してください。

Webデータ抽出に Thunderbit を試す Get Started Free

FAQ

Docling は web scraper あるいは crawler ですか？ いいえ。Docling は、すでに手元にある文書 — PDF、DOCX、PPTX、XLSX、HTML、画像 — を Markdown または JSON に変換するツールです。URL の取得、JavaScript のレンダリング、アンチボット対策は行いません。ライブウェブのクロールは、Firecrawl や Thunderbit の Web API のような別ツールの役割です。Docling は、あなたが渡したファイルから始まります。

Docling のインストールサイズと初回ダウンロードはどれくらいですか？ デフォルトの docling メタパッケージは、フルの ML スタックを強制依存として引っ張るため、venv は約1.3 GB になります（torch だけで536 MiB）。初回の PDF 変換では、レイアウトと TableFormer のモデル約506 MiB がディスクにダウンロードされ、さらに RapidOCR の重み約40 MB が入り、所要時間は約224秒です。ほとんどがダウンロード時間です。2回目の変換は約0.55秒です。軽量フォーマットだけ必要なら、docling-slim（約50 MB コア）で重い経路を避けられます。

Docling は OCR をしますか？エンジンは何ですか？ はい。テキスト層のないスキャン PDF では、Docling の OCR が自動で動作し、私のテストではきれいに復元できました。デフォルトエンジンは EasyOCR ではなく RapidOCR です。古い解説でよくある誤解です。EasyOCR は今では追加で有効化する形式です。OCR は大規模処理では遅い経路で、特に CPU では顕著です。

なぜ Docling は表を画像にしたり、消したりしたのですか？ いちばん可能性が高いのはスパースページ効果です。Docling の RT-DETR レイアウトモデルはページ文脈を使うため、ほとんど何もないページ上の小さな表は Picture として分類され、エラーなしで捨てられることがあります。同じ表でも本文に囲まれていれば問題なく変換されます。対策は、レイアウトモデルにページ文脈を与えるか、変換後に doc.tables を確認して、件数が0のページをフラグすることです。

Docling と Firecrawl なら、どちらを使うべきですか？ 役割が違うので、多くの場合は二者択一ではありません。Firecrawl はライブウェブをクロールし、JavaScript をレンダリングし、メインコンテンツを抽出します。Docling は手元にある文書を変換し、PDF の表構造や OCR を本格的に扱え、完全オフラインで動きます。ソースが Web ページなら Web 系ツール（Firecrawl、または Thunderbit の API/MCP/CLI）を使ってください。PDF、スキャン、Office ファイルなら Docling です。実際のパイプラインでは、両方を使うケースが大半です。