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（ドキュメントを生成 AI 向けに整える）」です。

というわけで、これはクローラーではなく「コンバーター」のハンズオンレビューです。以下の内容はすべて、CPU のみの 1 台のマシン（macOS arm64、Python 3.14.2、Docling 2.111.0）で計測し、スクリプトでスコアリングし、失敗はそのまま失敗として記録したものです。リポジトリは巨大で、しかも日々動いています——63,069 スター、4,449 フォーク、メタデータを取得したその日にもプッシュがありました——ので、ここに出てくる Issue 番号やバージョン番号は「その時点のスナップショット」であって、固定値ではないと考えてください。

Docling とは何か（そして何ではないか）

Docling におけるすべての基本単位は DoclingDocument です。ファイルをこの構造にパースし、そこから Markdown、HTML、DocTags、あるいはロスレスな JSON をエクスポートします。コードは MIT ライセンス（個々のモデルのライセンスは異なります）で、IBM Research チューリッヒ発。執筆時点の最新リリースは v2.112.0 で、私が今回の検証を走らせる 2 日前に公開されたものです。

目玉となる機能は PDF と画像の処理経路です。この経路は文字列パースではありません——機械学習モデルのスタックです。RT-DETR のレイアウトモデル、TableFormer の表構造モデル、オプションの視覚言語モデル、そしてスキャン用の RapidOCR。これらのモデルが、ページレイアウト、読み順、表構造を復元します。レビューする価値があるのはまさにこの部分であり、HTML だけのテストでは決して見えてこない部分でもあります。

ひとつの区別を押さえておくだけで、1 週間分の混乱を避けられます。Docling は何もフェッチしません。JavaScript をレンダリングしませんし、アンチボットの壁を突破することもなく、クロールもしません。ファイルはこちらが用意する。Docling は理解だけを担当する。クロールは別のツールの仕事です。この点は後半で効いてきます——「Docling は Firecrawl の代わりになるのか」という質問が出るからです（答えはノー。両者は補完関係にあります。理由は後述します）。

誰も警告してくれない「初回実行」

pip install docling は Python 3.14.2 上できれいに成功します。そのあと venv を覗くと、1.3 GB あります。変換するのが HTML ファイルだけだったとしても、Docling は ML スタック一式を必須依存として引っ張ってくるのです。

依存パッケージ	ディスク上のサイズ（MiB、du）
torch (2.13.0)	536
opencv (cv2)	119
transformers (5.8.1)	101
scipy	99
sympy	76
pandas	72
rapidocr（同梱モデル含む）	75.6
docling_parse	30

しかもこれは、PDF を 1 枚も変換する前の話です。本当の摩擦が生じるのは最初の PDF 変換のとき——このタイミングでモデルがダウンロードされるからです。まっさらな隔離済み HuggingFace キャッシュの状態では、最初の PDF 変換に約 224 秒かかりました。しかもそのほとんどはダウンロード時間であって、計算時間ではありません。レイアウトモデルと TableFormer モデルは、ディスク上で 約 506 MiB（TableFormer 342 MiB ＋ レイアウト 164 MiB、du で検証済み）を占め、RapidOCR は約 40 MB の PP-OCRv4 の重みを site-packages に取得します。では、同じファイルの 2 回目の変換は？ 0.55 秒です。モデルはキャッシュされるので、通行料を払うのは 1 回きりです。

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

Docling のコンテナを作ろうとする人を悩ませる、第 2 の落とし穴もあります。重みが 2 か所に、2 つの異なるタイミングで分かれて配置されるのです。レイアウトモデルと TableFormer モデルは HF_HOME を尊重し、初回の PDF 変換時にダウンロードされます。ところが RapidOCR のモデルはそうではありません——キャッシュ設定を完全に迂回して …/site-packages/rapidocr/models/ に落ちてきます。イメージを事前ビルドしたりエアギャップ環境で運用したりするなら、両方のキャッシュを扱う必要があり、HF_HOME をどう設定しても 2 つ目は捕まえられません。

さて、公平を期しましょう。Docling は初期のリリース以降、docling-slim を提供しています——約 50 MB のコアで、torch を引き込むことなく pip install docling-slim[format-html] として HTML 用に使えます。つまり 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 として上流でオープンのままです。

表の再現度：TableFormer が本領を発揮するところ

素の PDF→テキスト変換ではなく Docling に手を伸ばす理由は、たいてい表にあります。そこで、機械可読な正解データを持つ表の PDF を 7 種類生成し、出力をセル単位でスコアリングしました。重要な指標は 2 つあり、両者は同じものではありません。**セル再現率（cell recall）**は、検出された表のどこかに正解値が存在する割合。**行内一致率（in-row rate）**は、それが正しい行に収まっている割合です。この 2 つを混同するとツールを過大評価することになるので、両方を示します。

表（ストレステスト）	検出	セル再現率	行内一致率	備考
T1 罫線ありの単純なグリッド（5×8）、ページ内に単独配置	いいえ	0.0	—	<!-- image --> と分類され、全セルが欠落
T2 罫線なし（ヘッダー罫のみ）	はい	1.00	1.00	完璧、グリッドも正確
T3 2 段階の colspan 結合ヘッダー	はい	1.00	0.97	全値を検出。ヘッダーの値が 1 つ行ずれ
T4 rowspan 結合の行ラベル、ページ内に単独配置	いいえ	0.0	—	<!-- image --> と分類
T5 colspan ヘッダー ＋ 罫線なし	はい	1.00	0.97	全値を検出。T3 と同じヘッダー行のずれ
T6 財務データ、空白列あり、右揃え	はい	1.00	1.00	空白列が保持され、ずれもなし
T7 12 列の横長グリッド	はい	1.00	1.00	横長の表でも列ずれなし

Docling が検出した 5 つの表については、正解値がすべて出力に現れました——セル再現率は全件 1.00 です。そのうち 3 つでは、すべての値が正しい行にも収まりました。多段ヘッダーの 2 ケース（T3 と T5）では、ヘッダーの値が 1 つ元の行から外れ、行内一致率が 0.97 に下がっています——データはすべて存在しており、積み重なったヘッダー部分で行の割り当てが 1 つ分ぶれるだけです。

構造的に難しいケースは、予想以上によく持ちこたえました。2 段階の colspan ヘッダーは GitHub Flavored Markdown へ正しくフラット化されました（「Q1 2026」というラベルが、またがっている 2 列にわたって繰り返されました。これは colspan を GFM に落とし込む際の正しいやり方です）。ヘッダー罫のみの罫線なしグリッド（T2）はそのまま正確に出力されました。12 列の横長の表（T7）にも列ずれはありませんでした。そして完全に空の財務列（T6）も、削除されたり詰められたりせず、空のセルとして保持されました。これは公式の TableFormer TEDS スコア——単純表 95.4、複雑表 90.1、全表 93.6——とも整合しており、モデルカードのベンチマークでは Camelot（73.0）や EDD（88.3）を大きく上回っています。

結合セルについては、注意書きを添えておきます。逆のことを報告しているオープンな Issue が存在するからです。Issue #3698 は、V1 と V2 が結合された行・列を正しく扱えないと報告しています。私のフィクスチャでは、単純な colspan（T3／T5）と rowspan の値は正しくフラット化され、上で述べた多段ヘッダーの行ずれだけが観測されました。しかし #3698 で失敗しているのは、不規則な複数行／複数列の結合や複数ページにまたがる表——つまり病的な側の端です。私が扱ったのは単純な側の端でした。したがって正確な言い方はこう狭くなります：ここでは単純な colspan と rowspan の値は復元できた（多段ヘッダーは行がずれることがある）、複雑で不規則な結合は文書化済みの未解決問題として残っている、と。「結合セルは動く」でも「結合セルは壊れている」でもありません。

落とし穴：ページに表が 1 つだけだと消えることがある

先ほどの表に戻ってください——T1 と T4 はまったく検出されませんでした。Docling は <!-- image --> を出力し、エラーも出さずに全セルを捨てたのです。T1 はごく普通の、罫線ありの 5×8 グリッドです。これはかなり不穏な結果なので、何が実際のトリガーなのかを切り分けるまでは「表パースの弱点」とは呼ばないことにし、スクリプトによる 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 レイアウトモデルがページの文脈を利用しており、ほぼ空白のページに小さな表が 1 つだけ置かれていると、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 秒（1 ページあたり 17.5 秒）で、各ページのテスト用の文を出力しました。デフォルトの OCR が自動的に発火しています——フラグも設定も不要です。

多くの記事が取り違えている細部がここにあります。デフォルトの OCR エンジンは RapidOCR であって、EasyOCR ではありません。初回実行時に PP-OCRv4 の .pth 重みがダウンロードされるのを確認して裏を取りました。既存のブログや古い Docling の FAQ の記述には、いまだに EasyOCR がデフォルトだと書かれているものが多くありますが、それは古い情報です。EasyOCR は現在、明示的に選ぶオプション扱いになっています。一方で今も有効な注意点はこちら：OCR は大規模になると遅い経路であり、ここに挙げた数値はすべて CPU のみの上限値です——GPU を使えば、これらの時間は大幅に短縮されるはずです。

実物の PDF、読み順、そして 1 ページあたりの処理時間

合成フィクスチャは特定の挙動を証明しますが、実物の PDF は「本当に使えるか」を証明します。今回はボーンデジタルの学術論文を 2 本走らせました——9 ページの Docling テクニカルレポートと、15 ページの「Attention Is All You Need」。どちらも 2 段組で、表と数式を含みます。

15 ページの Attention 論文では、5 つのセクション見出し——Abstract、Introduction、Background、Conclusion、References——が、2 段組にもかかわらず、線形化された Markdown の中にドキュメント順どおりに現れました。内容確認用のプローブ（Transformer、encoder、BLEU、multi-head）はすべて存在し、あの有名な複数列の結果表も 4 つの表として検出されました。これは本物の読み順復元と段組マージであり、RAG のチャンク分割にとって中核的な価値提案です——線形化処理が 2 段組ページを交互に混ざった意味不明な文字列にしてしまったら、ドキュメントをまともにチャンク分割することなどできません。

処理時間からは、直感に反する教訓が得られます。1 ページあたりの時間を決めるのは、ページ数ではなく「各ページにどれだけ構造があるか」です。より密度の高い 9 ページのレポートは 1 ページあたり 14.95 秒 で、15 ページの論文の 1 ページあたり 5.99 秒 より遅くなりました——表や図がより多く詰まっており、そのたびにレイアウト推論と TableFormer 推論が走るからです。つまり CPU 上の「1 ページあたり秒数」は、長さではなく構造密度の関数だということです。これは CPU のみでの単発実行なので、上限値であって本番の数値ではありません。

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

Docling は統一的なマルチフォーマットのパースを謳っているので、内容が既知で正解プローブを仕込んだ DOCX、XLSX、PPTX を生成し、2 点を確認しました。プローブが Markdown に現れるか、そして export_to_dict() を経由した JSON のラウンドトリップを生き延びるか、です。

ファイル	変換秒数	MD 内で検出されたプローブ	MD 内の表	JSON を生き延びたプローブ
report.docx（見出し ＋ 結合「Total」表 ＋ 箇条書き）	0.137	7/7	1	はい
workbook.xlsx（2 シート、空白列あり）	0.016	6/6	2	はい
deck.pptx（3 スライド、箇条書き ＋ 表）	0.038	6/6	1	はい

内容プローブはすべて Markdown に現れ、表も復元され（DOCX の結合された「Total」行と XLSX の両シートを含む）、すべてのプローブが export_to_dict() の JSON も生き延びました——これが、少なくともクリーンな入力においては、ロスレスな DoclingDocument という主張を裏づける証拠になります。これらのフォーマットは ML モデルではなくフォーマットネイティブのバックエンドを通るため、数十ミリ秒で完了し、完全にオフラインで動作します。ただしスコープは正直に言っておきます。フォーマットごとにクリーンなファイル 1 つずつなので、対応範囲の広さは裏づけられますが、病的な Office ファイルに対するストレステストではありません。

HTML：忠実だが、クリーンではない

これは Docling を自分の RAG パイプラインに入れるかどうかを左右する注意点なので、よく読んでください。Docling は HTML ドキュメント全体を変換します。readability 方式の本文抽出は行いません。どれだけサイトの装飾（chrome）が残るかを、Docling 自身の出力に含まれるナビ・目次・Cookie・フッターのマーカー行を数えて定量化しました。

ページ	空行を除く MD 行数	定型（boilerplate）行数	定型の割合	本文の開始行
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% がナビ／目次／フッターの定型部分で、本文が始まるのは 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 バックエンドです。「視覚モデルがページを読む」という話は PDF と画像に限った話であり、HTML を食わせてもレイアウトや TableFormer の機構は一切動きません。第二に、PDF の経路ではヘッダーやフッターといった装飾の分類を試みているので、「定型除去がまったくない」と言い切るのは強すぎます——装飾をそのまま返してくるのは、あくまで HTML バックエンドです。

他ツールとの位置関係（そして Thunderbit の立ち位置）

Web データ抽出に Thunderbit を試す

Docling の比較対象としてよく持ち出されるのは Firecrawl なので、ポジショニング表を用意しました。先に注意点をひとつ。重要なので明記します。これはドキュメントレベルの比較であって、同一マシン上のベンチマークではありません。今回のフィクスチャで Firecrawl を実行したわけではありません。計測値があるのは Docling の列だけで、Firecrawl の列は公開ドキュメントに基づいています。

観点	Firecrawl（公式ドキュメントより）	Docling（本記事での計測）
中心的な仕事	ライブ Web をクロール＋スクレイプ → Markdown	すでに手元にあるドキュメントを変換 → Markdown/JSON
フェッチ／JS レンダリング／アンチボット	あり（ホスト型ブラウザ）	なし——ファイルは自分で用意する
本文抽出	あり	なし——忠実なフルドキュメント（Wikipedia で装飾が約 13%）
PDF の表構造（ML）	限定的	あり——TableFormer（公式 TEDS 93.6。検出されたフィクスチャでセル再現率 1.00、行内一致率 0.97〜1.00）
スキャン PDF／OCR	限定的	あり——デフォルトで RapidOCR（テキストレイヤー 0 のスキャンを復元）
対応フォーマットの広さ	Web ページ	PDF/DOCX/PPTX/XLSX/HTML/EPUB/画像
デプロイ形態	ホスト型 API（＋セルフホスト）	ローカルの pip ライブラリ、オフライン、API キー不要
セットアップの重さ	API キー／軽量クライアント	デフォルト構成で 1.3 GB ＋ モデル約 506 MiB（または docling-slim）
ライセンス	商用／ソース公開	MIT

一行でまとめるなら：データがライブ Web 上にあり、クロール、JS レンダリング、本文のクリーンアップが必要なら Firecrawl。すでにドキュメントを手元に持っていて——特に PDF、スキャン、表の多い Office ファイルで——忠実・オフライン・構造保持の変換を、本物の表理解と OCR 込みで行いたいなら Docling。両者は補完関係にあります。現実的なパイプラインは、片方でクロールし、もう片方でドキュメントを変換します。

そこで Thunderbit について率直に書いておきます。私はここで働いており、そうでないふりをすれば当然疑われるからです。Thunderbit と Docling は同じ仕事をしていませんし、無理に同列に並べるつもりもありません。開発者にとっての Thunderbit は、AI スクレイピング API ＋ MCP サーバー ＋ CLI であり、その作業単位はライブの Web ページです。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 です。両方なら——現実のパイプラインはたいてい両方です——2 つを組み合わせればよく、どちらも相手になろうとはしていません。

総評：暫定評価、宿題は残っている

0〜100 の単一スコアを提示するつもりはありません。ここで加重合計を出すと、Docling がもともと主張していないこと（たとえばクロール）に対する減点まで織り込み、それがあたかも比較可能であるかのように見せてしまうからです。今回テストしたフィクスチャにおける、次元ごとの評価はこうです。

• セットアップ／初回実行： 重い——venv 1.3 GB、モデル約 506 MiB、初回 PDF 約 224 秒、ウォーム時約 0.55 秒——ただし docling-slim でこの重さは回避できる。
• 表の再現度： 表が検出されたときは強力（5/5 でセル再現率 1.00、行内一致率 0.97〜1.00）。今回のフィクスチャでは公式 TEDS の主張と整合。
• 表の検出の頑健さ： スパースページの罠——単独配置された表が Picture として落ちうる。doc.tables の後段チェックを。
• スキャン／OCR： 動作する。デフォルトは RapidOCR。ただし大規模では遅い。
• マルチフォーマット： 堅実。JSON のラウンドトリップも無傷。
• HTML： 忠実だがクリーンではない——本文抽出はなし。
• 開発者体験： 3 行で書けるすっきりした API と整った DoclingDocument。ただし __version__ が欠けている点はマイナス。

向いているのは：PDF、スキャン、Office ファイルを対象に RAG やデータパイプラインを構築するチームで、オフラインかつ構造を保った変換と、本物の表理解・OCR を求める人たち。向いていないのは：ライブ Web のクロールや、きれいな本文だけの HTML 抽出が必要な人——それは別のツールの仕事です。

そしてこれはプレスリリースではなくレビューなので、限界も表示ラベルに残しておきます。今回は的を絞ったプローブ——CPU のみの 1 台のマシン上で、合成の表 7 種類と実物の PDF 2 本——であって、TEDS 規模の精度ベンチマークではありません。私がテストしていないもので、Docling にパイプラインを賭ける前に確認すべきものはいくつもあります：オプションの VLM（GraniteDocling）経路、docling-slim の実際のフットプリント、GPU での実行、複雑・不規則な結合セルと複数ページにまたがる表、数式→LaTeX の再現度、そして——本番でもっとも驚かされる可能性が高いのが——数千件の変換にわたるバッチ処理でのメモリ増加、スレッド／GIL のスケーリング、オブジェクトのライフサイクルという「耐久性の三点セット」です。Docling は自ら主張している領域では強く、マーケティングではなく計測に裏づけられています。同時に、コーパスを預ける前に地図を描いておきたい本物の限界も抱えています。スパースページの注意点を把握し、初回のダウンロード時間を見込み、大規模時の挙動は自分で検証してください。

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

よくある質問

Docling は Web スクレイパーやクローラーですか？ いいえ。Docling は、すでに手元にあるドキュメント——PDF、DOCX、PPTX、XLSX、HTML、画像——を Markdown や JSON に変換するものです。URL を取得したり、JavaScript をレンダリングしたり、アンチボットに対処したりはしません。ライブ Web のクロールは Firecrawl や Thunderbit の Web API といったツールが担う別の仕事であり、Docling は提供されたファイルを起点とします。

Docling のインストールサイズと初回ダウンロード量はどれくらいですか？ デフォルトの docling メタパッケージは、ML スタック一式（torch だけで 536 MiB）を必須依存として引き込むため、約 1.3 GB の venv になります。最初の 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 レイアウトモデルはページの文脈を利用しており、ほぼ空白のページに小さな表が 1 つだけあると、Picture に分類され、エラーも出さずに捨てられることがあります。同じ表でも、本文に囲まれていれば問題なく変換されます。対処法は、レイアウトモデルにページの文脈を与えるか、変換後に doc.tables を後段チェックして件数が 0 のページにフラグを立てることです。

Docling と Firecrawl、どちらを使うべきですか？ 仕事が違うので、たいていは二者択一にはなりません。Firecrawl はライブ Web をクロールし、JavaScript をレンダリングし、本文を抽出します。Docling はすでに手元にあるドキュメントを、本物の PDF 表構造解析と OCR を伴って、完全オフラインで変換します。ソースが Web ページなら Web 系のツール（Firecrawl、あるいは Thunderbit の API/MCP/CLI）を、PDF・スキャン・Office ファイルなら Docling を。現実のパイプラインの多くは、両方を走らせています。