2026.09.22 AI

Doclingとは？PDFをMarkdown化してRAGに載せる実装手順と採用判断

Doclingとは？PDFをMarkdown化してRAGに載せる実装手順と採用判断

Doclingは、PDFやOfficeファイルを解析してMarkdownやJSONへ変換し、LLMや検索システムの入力に載せるためのオープンソースライブラリです。PyPIの最新は2.129.0（2026年9月18日公開）で、ライセンスはMITです。この記事では、導入コマンドと動作要件、CLIとPython APIでの変換手順、表が崩れたときに触るパイプラインオプション、VLMへの切り替え、RAG用チャンクの切り出し、そして閉域網で動かすためのモデル事前取得までを、公式ドキュメントとPyPI・GitHubの実測値で整理します。取り込み工程と推論工程をどう分けるかという設計側の話はRAGパイプラインの工程設計をまとめた記事で扱っています。

まとめ：Doclingを選ぶ条件とMarker・商用APIとの分岐点

Doclingを採用するかどうかは、ライセンスと設置場所の2点でほぼ決まります。MITで配布されているため、受託開発の成果物へ同梱しても顧客側にライセンス条件が伝播しません。同じ用途のMarkerはGPL-3.0とOpen RAIL-Mの二重制約を持ち、売上基準を超える組織では商用利用そのものができないため、納品物に入れる選択肢から外れます。この差だけでDoclingに寄せる案件は現実に存在します。

設置場所の条件も効きます。Doclingはリモートサービスを前提にしておらず、モデル重みの置き場所さえ指定すればエアギャップ環境で完結します。外部APIへ画像を送る機能は明示的なオプトインが必要で、設定を書かない限り例外で停止する構造です。逆に、変換対象が月数十件で、社外へデータを出すことに制約がないなら、GPUもモデル管理も抱えずに済む商用の変換APIのほうが総コストは下がります。Doclingが効くのは、件数が積み上がるか、データを外へ出せないか、納品物に組み込むかのいずれかに当てはまる場合です。

Doclingが担う工程とv2.129.0時点で読める対応フォーマットの範囲

DoclingはIBM Researchが公開したドキュメント変換ライブラリで、レイアウト解析・表構造認識・読み順の推定までをローカルのモデルで処理します。変換結果はDoclingDocumentという統一表現に一度まとめられ、そこからMarkdownやJSONへ書き出す二段構えです。この中間表現を持つ点が、単純なテキスト抽出ツールとの構造上の違いになります。

IBM Researchが公開したOSSとMITライセンスの意味

リリースの動きは活発で、GitHubのリリース一覧を実測すると、v2.125.0（2026年9月3日）からv2.129.0（2026年9月18日）まで約2週間で5本が出ています。版番号が飛びやすいため、検証環境と本番でバージョンを固定せずに運用すると挙動が変わります。requirements側でマイナー版まで固定してください。

ライセンスはMITです。リポジトリのLICENSEファイルで直接確認できます。受託開発でこれが効くのは、成果物へライブラリを同梱しても顧客の著作物に条件が波及しない点です。同じ変換用途のMarkerの商用ライセンス制約を整理した記事で扱ったとおり、GPL-3.0系のツールは納品物へ組み込む時点で検討対象から外れます。選定の初手はライセンスであり、精度の比較はその後です。設計思想の背景はarXivに公開された技術レポートに記載があります。

PDFからメール・音声まで広がった入力フォーマットの実際の範囲

対応入力は公式の対応フォーマット一覧に表で載っています。PDFとOffice系（DOCX・XLSX・PPTX）が中心ですが、EPUB、Apple Pages、AsciiDoc、LaTeX、CSV、画像に加えて、メール（.emlと.msg）、音声（WAV・MP3ほか）、動画からの音声抽出、WebVTT字幕まで対象に含まれます。レガシーのDOC・XLS・PPTとRTFはLibreOfficeの同梱が前提で、音声はasrのextraが要る点に注意してください。

出力側はMarkdown、HTML、JSON、プレーンテキスト、DocTags、LaTeX、そしてRAG向けのチャンクをJSONL形式で書き出す選択肢が並びます。JSONは無損失のシリアライズで、座標やラベルを保持したまま後工程へ渡せます。図表の位置情報を検索に使う設計なら、Markdownではなく最初からJSONを受け取ってください。図表そのものを検索対象にする方式は図表・画像を検索するマルチモーダルRAGの記事で整理しています。

pipとuvで入れるインストール手順とPython 3.10以上という前提

導入はパッケージ1本で済みます。PyPIのメタデータを実測すると、要求Pythonは3.10以上4.0未満で、クラシファイアは3.10から3.14まで並んでいます。Python 3.9以前の環境では入りません。依存にPyTorchが含まれるため、仮想環境のサイズは数GB規模になる点を先に見積もってください。

pip installとuv addで入れる導入コマンドの違い

基本形は次のとおりです。CPUだけで回すLinuxサーバでは、CUDA同梱版のPyTorchを避けるためにインデックスを指定します。これを省くとイメージサイズが数GB単位で膨らみます。

pip install docling

# uv を使う場合
uv add docling

# Linux で CPU 版 PyTorch を使う場合
pip install docling --extra-index-url https://download.pytorch.org/whl/cpu

macOSのIntel機にはdocling[mac_intel]という専用のextraがあります。対応プラットフォームはmacOS・Linux・Windowsで、アーキテクチャはx86_64とarm64の双方を公式のインストール手順が明記しました。開発機がApple Silicon、本番がLinuxのx86_64という構成でも同じコードが動きます。

OCRエンジンをextrasで足すときの選択肢と前提パッケージ

スキャンPDFや画像を読む場合はOCRエンジンが要ります。extrasとしてeasyocr、rapidocr、feat-ocr-nemotron、GPU推論用のonnxruntimeが用意されており、必要なものだけを足す形です。

Tesseractを使う場合だけは手順が変わります。Pythonパッケージではなく、OS側にパッケージを入れてTESSDATA_PREFIXを設定する必要があるためです。Debian系ならtesseract-ocrとlibleptonica-dev、RHEL系ならtesseractとleptonica-develを入れます。Dockerイメージを作る際はこの分だけベースイメージ側の作業が増えるため、OCRエンジンの選定はビルド設計と合わせて決めてください。文字認識そのものの精度特性はOCRの仕組みと実装での組み込み方を解説した記事にまとめています。

CLIとDocumentConverterでPDFをMarkdownへ変換する実行手順

導入が済んだら、まずCLIで1本通してから実装へ移るのが手戻りの少ない順序です。

doclingコマンド1本でPDFをMarkdownにする最短手順

コマンドはファイルパスかURLを渡すだけです。初回実行時にモデル重みのダウンロードが走るため、最初の1本は時間がかかります。

docling https://arxiv.org/pdf/2206.01062

# VLM パイプラインへ切り替える場合
docling --pipeline vlm --vlm-model granite_docling https://arxiv.org/pdf/2206.01062

出力形式やページ範囲の指定はdocling --helpに一覧があります。検証段階では、手元の実ファイル（顧客から受け取る様式に近いもの）を数本流して、表と見出しがどこまで拾えるかを先に見てください。ここで許容できない崩れが出るなら、後続の設定でも埋まらない可能性が高く、方式そのものの再検討に戻ります。

DocumentConverterから呼び出すPython APIの最小コード

実装側はDocumentConverterを作ってconvert()を呼ぶだけです。戻り値のdocumentが中間表現で、そこから各形式へ書き出します。

from docling.document_converter import DocumentConverter

source = "https://arxiv.org/pdf/2408.09869"  # パスでもURLでも可

converter = DocumentConverter()
doc = converter.convert(source).document

print(doc.export_to_markdown())

この4行が公式クイックスタートに載っている最小形です。変換器のインスタンスは生成時にモデルを読み込むため、1ファイルごとに作り直すと初期化コストを毎回払います。バッチ処理ではconverterを使い回してください。

書き出しはexport_to_markdown()のほかにJSON、プレーンテキスト、DocTags、LaTeXが選べます。RAGへ載せる前提なら、まずJSONで受けて構造を確認し、索引へ入れる直前でMarkdownへ落とす順序が扱いやすくなります。Markdownへ先に落とすと、見出しの階層やセルの結合情報が欠けて、後から取り戻せません。

表が崩れるときに触るTableFormerとセル対応付けの切り替え

実務で最初に詰まるのは表です。Doclingは表構造認識にTableFormerというモデルを使い、公式の詳細オプションに切り替え方が載っています。崩れ方によって触る場所が変わるため、症状から設定を引く形で整理します。

TableFormerのFASTとACCURATEを切り替える判断

モードはFASTとACCURATEの2択で、既定はACCURATEです。1.16.0以降で選べるようになりました。罫線のない表や結合セルの多い帳票ではACCURATEのまま使い、処理時間が問題になる大量バッチでのみFASTへ落とす判断になります。

from docling.datamodel.base_models import InputFormat
from docling.datamodel.pipeline_options import PdfPipelineOptions, TableFormerMode
from docling.document_converter import DocumentConverter, PdfFormatOption

pipeline_options = PdfPipelineOptions(do_table_structure=True)
pipeline_options.table_structure_options.mode = TableFormerMode.ACCURATE

converter = DocumentConverter(
    format_options={InputFormat.PDF: PdfFormatOption(pipeline_options=pipeline_options)}
)

表の抽出そのものが不要ならdo_table_structureを切ってください。テキストだけを取りたい用途では、表認識を外すだけで処理時間が目に見えて縮みます。

列が結合されるときdo_cell_matchingを外して直す

複数の列がひとつに結合されて出てくる症状には、別の設定が効きます。既定では認識した表構造をPDFのセルへ対応付け直す動きをするため、ここが誤ると列がつながりました。do_cell_matchingをFalseにすると、構造予測側が出したテキストセルをそのまま使うため、この種の結合が解けます。

逆に、この設定を外すと文字の取りこぼしが増える文書もあります。どちらが良いかはレイアウト次第なので、実ファイル10本程度で両方を回し、列数の一致率で決めてください。案件ごとに固定値を決めて設定ファイルへ書き残しておくと、後任が同じ検証を繰り返さずに済みます。

VLMパイプラインへ切り替えてgranite_doclingで解析する手順

レイアウト解析・OCR・表認識を個別モデルで積み上げる標準パイプラインに対して、視覚言語モデル（VLM）でページ画像ごと解釈させる経路も用意されています。崩れの直し方が個別設定ではなくモデル選択になるため、標準側で埋まらない文書に当てる選択肢です。

docling –pipeline vlmで解析器ごと差し替える手順

CLIでは--pipeline vlmを付けるだけで切り替わります。既定で使われるGraniteDoclingは258Mパラメータの文書変換特化モデルで、仕様はHugging Faceのモデルカードで公開されました。ほかにSmolDocling系、Qwen2.5-VL、Pixtral、Gemma3などのモデル仕様が同梱されており、Apple Silicon向けのMLX版も選べます。

切り替えて必ず良くなるわけではありません。VLMは1ページを丸ごと解釈するため、レイアウトが複雑な文書では強く、単純な文字ベースのPDFでは標準パイプラインのほうが速くて安定します。

VlmPipelineをPython側から組み込む書き方と外部送信の扱い

コードからはpipeline_clsにVlmPipelineを渡します。公式のVLMページに記載されている形です。

from docling.datamodel.base_models import InputFormat
from docling.document_converter import DocumentConverter, PdfFormatOption
from docling.pipeline.vlm_pipeline import VlmPipeline

converter = DocumentConverter(
    format_options={InputFormat.PDF: PdfFormatOption(pipeline_cls=VlmPipeline)}
)

doc = converter.convert(source="sample.pdf").document

推論をローカルではなくOpenAI互換APIのリモートへ逃がす構成にも対応しました。ただし外部へデータを送る経路は明示的なオプトインが必要で、enable_remote_services=Trueを設定していない場合はOperationNotAllowed例外で処理が止まります。既定で外へ出ない設計のため、うっかり顧客文書が外部APIへ流れる事故は構造的に防がれる仕組みです。機密文書を扱う案件でセキュリティ要件を説明する際の材料になります。

HybridChunkerでRAG用のチャンクを切り出して索引へ渡す工程

変換して終わりではなく、チャンク分割までDocling側に持たせられます。公式のチャンキング解説に2種類のチャンカーが定義されており、構造情報を保ったまま切れる点が、Markdownへ落としてから文字数で切る方式との差になります。

HierarchicalChunkerとHybridChunkerの使い分け

HierarchicalChunkerは文書構造の要素ごとに1チャンクを作ります。見出しや段落の単位がそのままチャンクになるため、意味の切れ目とチャンクの境界が一致する形です。ただし要素の長さに依存するので、長い段落は巨大に、箇条書きの1項目は極端に短くなります。

HybridChunkerはその結果に対してトークン数を見た後処理を加えます。上限を超えたチャンクだけを分割し、同じ見出しやキャプションに属する連続した小さなチャンクは結合する2段構えです。RAGへ載せるならこちらを使ってください。導入時はextraが要り、HuggingFace系のトークナイザならdocling-core[chunking]、OpenAIのtiktokenを使うならdocling-core[chunking-openai]を入れます。

チャンク長をトークナイザと埋め込みモデルの上限で揃える実装手順

from docling.chunking import HybridChunker
from docling.document_converter import DocumentConverter

doc = DocumentConverter().convert("sample.pdf").document

chunker = HybridChunker()
for chunk in chunker.chunk(dl_doc=doc):
    print(chunk.text[:80])

ここで外しやすいのが、チャンカー側のトークナイザと埋め込みモデル側のトークナイザを別物にしてしまう構成です。分割時の想定トークン数と、実際に埋め込みへ渡したときのトークン数がずれると、上限超過で末尾が切り捨てられます。使う埋め込みモデルと同じトークナイザを指定してください。

切り出したチャンクを索引へ入れる先はフレームワーク側の担当です。統合はBaseChunkerインターフェース経由で行う設計になっており、LlamaIndexの索引構築APIを解説した記事で扱った枠組みへそのまま渡せます。データ整備から精度改善までの全体像はRAG構築の手順をまとめた記事を参照してください。

閉域網でDoclingを動かすモデル事前取得とartifacts_pathの指定

官公庁や金融の案件では、実行環境がインターネットへ出られない前提で設計します。Doclingはリモートサービスを呼ばない構成のため、モデル重みさえ持ち込めばエアギャップ環境で完結する作りです。公式FAQもこの点を明記しており、要件はモデル格納先を指すことだけだと書かれています。

docling-tools models downloadで重みを先に取得する

既定ではモデルは初回実行時に自動でダウンロードされます。閉域網ではこれが失敗するため、インターネットに出られる側で先に取得してから持ち込みます。

# 標準パイプラインで使う重みをまとめて取得
docling-tools models download

# EasyOCR の日本語モデルを追加で取得
docling-tools models download easyocr --easyocr-lang ja

# 任意の Hugging Face リポジトリを取得
docling-tools models download-hf-repo ds4sd/SmolDocling-256M-preview

1本目のコマンドでlayout、tableformer、picture classifier、code formula、RapidOCRの各モデルが取得され、既定では$HOME配下のキャッシュディレクトリへ置かれます。PDFパイプライン以外、つまりDOCXやPPTXの処理には重みが要りません。Officeファイルだけを扱う構成なら、このダウンロード自体を省けます。

artifacts_path・環境変数・CLI引数の3経路で参照させる

持ち込んだ重みを指す方法は3つあります。コードからはPdfPipelineOptionsのartifacts_path、CLIからは--artifacts-path、環境変数ならDOCLING_ARTIFACTS_PATHです。コンテナで運用するなら環境変数が扱いやすく、重みをボリュームでマウントしてパスを渡す形に収まります。

from docling.datamodel.base_models import InputFormat
from docling.datamodel.pipeline_options import PdfPipelineOptions
from docling.document_converter import DocumentConverter, PdfFormatOption

pipeline_options = PdfPipelineOptions(artifacts_path="/opt/docling/models")

converter = DocumentConverter(
    format_options={InputFormat.PDF: PdfFormatOption(pipeline_options=pipeline_options)}
)

重みをDockerイメージへ焼き込むか、外部ボリュームから読ませるかは運用方針で分かれます。イメージへ入れればデプロイ時に取得処理が不要になる代わりに、イメージが数GB膨らみます。バージョン更新のたびにイメージを作り直す体制があるなら焼き込み、そうでないならマウントを選ぶ、という分岐で判断してください。

Doclingを見送る案件条件とMarker・商用APIとの分岐の引き方

ここからは採用可否の線引きです。Doclingは無償で制約も緩い一方、モデルの管理と計算資源を自分たちで抱えることになります。抱える価値が出る境目を条件で示します。

Marker・MinerUとの使い分けをライセンスと工程で決める

納品物へ組み込むならDocling一択です。MarkerはGPL-3.0とOpen RAIL-Mの二重制約を持ち、売上200万ドルの基準を超える組織では商用利用ができません。判定フローはMarkerの使い方とライセンス制約を整理した記事にまとめてありますが、受託開発の現場では「顧客の売上規模を確認しないと使えない」時点で選定から落ちます。

精度面での使い分けは、文書の性質で分かれます。数式の多い学術系PDFはMarkerやMinerUが得意とする領域で、業務帳票や契約書のように表と見出しの構造が大事な文書はDoclingの表構造認識が効きます。両方を候補に残せる案件なら、実ファイル10本で変換結果を比較してから決めてください。ライセンスで先に絞り、残った候補を精度で選ぶ順序が手戻りを減らします。

商用のドキュメント変換APIへ寄せたほうが安く収まる案件の条件

変換が月数十件で、社外へデータを出す制約がないなら、商用の変換APIのほうが総コストは下がります。Doclingを入れると、PyTorchを含む数GBの実行環境、モデル重みの管理、バージョン更新時の再検証、GPUを使うならその費用が付いてきました。件数が少ないうちは、これらの固定費が従量課金を上回ります。

逆にDoclingへ寄せる条件は3つです。件数が月数千件以上に積み上がって従量課金が固定費を超える場合、文書を社外へ出せない場合、そして成果物へ変換機能を組み込んで納品する場合。このいずれかに当てはまるなら、自前で回す構成が合理的になります。判断に迷う段階で実ファイルでの検証から設計・実装まで任せたい場合は、RAG構築支援で相談を受け付けています。

よくある質問

Doclingの導入検討でよく挙がる質問を、公式ドキュメントとPyPI・GitHubの実測値をもとに整理します。

DoclingとMarkerはどちらを選べばよいですか？

ライセンス条件が先に効きます。DoclingはMIT、MarkerはGPL-3.0とOpen RAIL-Mの二重制約で、後者は売上200万ドルの基準を超える組織では商用利用できません。納品物へ組み込む用途や、顧客の事業規模を確認しづらい案件ではDoclingを選んでください。数式中心の学術文書に限ればMarker側が得意とする領域もあるため、両方を使える立場なら実ファイルで比較する価値があります。

動かすのにGPUは必要ですか？

必須ではありません。CPUだけでも動作し、LinuxではCPU版PyTorchを指定してインストールする手順が用意されています。ただし処理時間は当然伸びるため、件数が積み上がる用途ではGPUを検討してください。GPU側ではAcceleratorOptionsでCUDAデバイスを指定し、OCRやレイアウト検出のバッチサイズを引き上げる調整が効きます。

日本語のPDFはそのまま読めますか？

テキスト情報を持つPDFであれば、OCRなしで読めます。スキャン画像のPDFはOCRエンジンが要り、言語はocr_options.langにBCP-47準拠のコードで指定する形です。EasyOCRを使う場合は、日本語の認識モデルを事前に取得しておく手順が公式に用意されています。縦書きや罫線のない帳票は崩れやすい領域なので、本番相当のファイルで必ず事前検証してください。

社外にデータが送信されることはありませんか？

既定では送信されません。外部サービスを呼ぶ機能は明示的なオプトイン制で、enable_remote_services=Trueを設定していない状態で該当機能を使うとOperationNotAllowed例外が発生して処理が止まります。モデル重みの取得だけは初回にインターネットへ接続しますが、これも事前取得しておけば不要になります。閉域網での実行を要件に挙げられる案件でも、構成上の説明が付けやすい設計です。

変換結果はそのままRAGへ入れてよいですか？

チャンク分割を挟んでください。Markdownを文字数で機械的に切ると、表が途中で分断されたり、見出しと本文が別チャンクへ分かれたりします。HybridChunkerを使えば構造情報を見た分割とマージが入るため、この種の崩れを避けられます。分割時のトークナイザは、索引側で使う埋め込みモデルと同じものを指定してください。

関連記事

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る