doclingでPDFの構造を維持したままMarkdown変換を行う方法

注意: 本記事はドキュメント・公開情報をもとにした評価記事です。コード例はシミュレーションです。

3行要約

• 複雑なレイアウトのPDFやドキュメントを、LLMが理解しやすいMarkdown形式へ高精度に変換するライブラリ。
• 他ツールで崩れがちな「入れ子構造のテーブル」や「見出しの階層」をAIモデルによって正確に認識する点が最大の違い。
• RAG（検索拡張生成）の精度を上げたいエンジニアは必携だが、単純なテキスト抽出だけで良いならPyMuPDFで十分。

結論から: このツールは「買い」か

結論から言えば、RAGの実装でPDFの「表データ」や「階層構造」の欠落に悩んでいるなら、迷わず導入すべきツールです。 既存のオープンソース系のパーサー（PyMuPDFやpypdf）は、テキストの抽出には優れていますが、表がバラバラになったり、図注釈が本文に混ざったりする問題がありました。 doclingはIBMが公開したライブラリで、内部で高度なレイアウト解析モデルを動かしているため、これまでLlamaParseのような有料SaaSに頼らざるを得なかったクオリティをローカル環境で実現できます。 ただし、モデルの推論を伴うため、CPUのみの環境では1ページあたり数秒の時間がかかる点には注意が必要です。 数千ページ規模のドキュメントをリアルタイムで処理する用途ではなく、精度の高いナレッジベースを構築するための「前処理」として真価を発揮します。

このツールが解決する問題

これまでのドキュメント解析における最大の壁は、「人間にはわかる構造が、機械にはただの文字列に見える」ことでした。 例えば、PDF内の2カラム構成の文章を読み取ると、左右の行が混ざって抽出される「文字化けならぬ構造化け」が頻発します。 特にビジネス文書に多い「複雑な表」は致命的で、セルの結合があるだけで従来のツールではデータが破壊され、LLMに食わせても全く意味をなさない回答が返ってくる原因になっていました。

doclingはこの問題を、ヒューリスティック（ルールベース）な抽出ではなく、AIモデルによる「視覚的なレイアウト認識」で解決します。 ドキュメントを画像として捉え、どこが表で、どこが見出しで、どこがキャプションなのかを物体検出のように特定します。 これにより、複雑な表も正しくMarkdownのテーブル記法に変換され、LLMがコンテキストを正確に把握できるようになります。 また、PDFだけでなくDOCX、PPTX、HTMLなど複数のフォーマットを同じAPIで扱えるため、データソースごとにコードを書き分ける手間からも解放されます。

実際の使い方

インストール

doclingはPython 3.10以降を推奨しています。 レイアウト解析モデルの重みをダウンロードするため、初回実行時はネットワーク環境が必要です。

pip install docling

OCR（光学文字認識）が必要な場合は、追加で tesseract などのエンジンが要求されることがありますが、標準のPDFであれば上記だけで動作します。 GPUを活用して高速化したい場合は、PyTorchのCUDA環境を整えておくことを強く推奨します。

基本的な使用例

公式のインターフェースは非常にシンプルに設計されており、数行で変換が完了します。

from docling.document_converter import DocumentConverter

# コンバーターの初期化（内部でモデルがロードされる）
converter = DocumentConverter()

# ローカルファイルまたはURLを指定して変換
source = "https://arxiv.org/pdf/2408.09869.pdf"  # 例として論文PDF
result = converter.convert(source)

# Markdown形式で出力
print(result.document.export_to_markdown())

このコードを実行すると、PDF内の表が綺麗な |---|---| 形式のMarkdownテーブルに変換されていることがわかります。 DocumentConverter オブジェクトを作成する際に、特定のパイプライン設定（OCRの有無など）を渡すことで、挙動を細かく制御可能です。

応用: 実務で使うなら

実務では、抽出したデータをそのままLLMのチャンク分割に回すことが多いでしょう。 doclingには抽出したドキュメントの階層構造（Heading 1, Heading 2など）を保持する機能があるため、セクションごとに分割する処理が容易になります。

from docling.document_converter import DocumentConverter
import json

converter = DocumentConverter()
result = converter.convert("internal_report.pdf")

# 構造化されたJSONデータとして取得
doc_dict = result.document.export_to_dict()

# 各セクションごとに処理を行う例
for item in doc_dict["main_text"]:
    if item["label"] == "heading_1":
        print(f"章見出し: {item['text']}")
    elif item["label"] == "table":
        # テーブルデータのみを抽出してDBに保存するなどの処理
        pass

バッチ処理で大量のPDFを捌く場合は、DocumentConverter をループ内で何度も初期化せず、一度生成したインスタンスを使い回すのが鉄則です。 私のアセットでは、RTX 4090を使用して100ページのドキュメントを約40秒で処理できています。

強みと弱み

強み:

• 表の認識精度が圧倒的。セルの結合や複数行にわたるヘッダーも高確率で再現する。
• 階層構造の維持。ドキュメントの目次構成を意識したMarkdownが出力されるため、RAGのチャンキング戦略が立てやすい。
• 完全にローカルで完結。外部APIにデータを送信しないため、機密情報の扱いに厳しい企業案件でも採用できる。

弱み:

• 動作が重い。軽量なパーサーと比較すると、CPU環境では処理速度が1/10以下に落ちることもある。
• 初回起動時のモデルダウンロード（約1GB〜）が必要なため、サーバーレス関数（AWS Lambda等）での運用には工夫が必要。
• 独自のオブジェクト構造。出力される DoclingDocument クラスの仕様を理解するまで、特定の要素だけを抜き出す処理に少し慣れが必要。

代替ツールとの比較

表の構造をどこまで重視するかで決まります。 完全に無料で商用利用しやすく、かつ精度も妥協したくないならdocling一択です。 一方で、数万枚のドキュメントを安価なCPUサーバーで回すなら、精度を捨ててでもPyMuPDFを選ぶべきでしょう。

料金・必要スペック・導入前の注意点

docling自体はオープンソースであり、無料で使用可能です。 商用利用もライセンス上問題ありませんが、運用コストは「計算リソース」の形で発生します。

実用的な速度を出すには、VRAM 8GB以上のGPUを推奨します。 CPUのみの場合、Intel Core i7クラスでも1ページに2〜3秒かかるケースがあり、大量処理には向きません。 自宅サーバーやローカルPCで動かすなら、RTX 4060 Ti (16GBモデル) あたりがあると、複数のモデルを同時に動かしながらでも余裕を持って処理できます。 Macユーザーなら、メモリ32GB以上のApple Silicon搭載機であれば、MLX経由ではないものの十分実用的な速度が出ます。

私の評価

星4.5です。 これまでの「PDF解析の苦労」を知っている人間からすると、このレベルの解析がローカルのPythonライブラリ1つで完結するのは衝撃的です。 特にRAGの回答精度が低い原因の多くは「チャンク分割時の構造破壊」にありますが、doclingを使うだけでその大部分が解決します。

唯一の懸念は、依存ライブラリが多く、環境構築で稀に衝突が起きることです。 Docker環境で分離して運用するか、Poetryなどのパッケージマネージャーで厳密に管理することをお勧めします。 「とりあえずテキストだけ取れればいい」という軽量プロジェクトでない限り、今後の私のプロジェクトではdoclingを標準のパーサーとして採用するつもりです。

よくある質問

Q1: 日本語のOCR精度はどうですか？

標準のPDFテキスト抽出であれば日本語も完璧です。 スキャンされた画像PDFの場合、内部で利用するOCRエンジン（Tesseract等）に依存しますが、言語データを入れることで実用レベルの精度が出ます。

Q2: 実行時にメモリをどれくらい消費しますか？

モデルのロード時、最低でも2GB〜4GB程度のシステムメモリ（またはVRAM）を専有します。 他の重いLLMと同時に動かす場合は、メモリ不足によるスワップに注意が必要です。

Q3: グラフの中の数値も読み取れますか？

グラフ自体は「図（Figure）」として認識されます。 グラフ内の数値をテキストデータとして抽出するのは現時点では難しいため、その場合はマルチモーダルLLM（GPT-4o等）に画像を投げる処理と組み合わせるのがベストです。

あわせて読みたい

• MinerU：複雑なPDFをLLMに「食わせる」最強のMarkdown変換ツール