中級 11 分Stack

Docling:PDFをAI用に変換 locale

端的な回答

Doclingは、MITライセンスのオープンソースライブラリです(IBM Researchによるプロジェクトで、LF AI & Data Foundationの傘下にあります)。PDF、DOCX、PPTX、XLSX、HTML、EPUB、画像、音声をMarkdownまたは構造化JSONに変換し、レイアウト、読み順、表を再構築します。GPUの有無にかかわらず完全にローカルで動作し、LangChain、LlamaIndex、Crew AI、Haystackに直接接続して、文書RAGパイプラインにデータを供給できます。

PDFは、ローカル文書処理パイプラインの中で最も処理が難しい入力形式です。2カラムを横読みで処理すること、ヘッダーが文を2つに切断すること、数値の表がラベルなしの数値の列に縮小されてしまうことなどが挙げられます。DoclingはIBM Researchが公開し、現在はLF AI & Data Foundationがホスティングしているオープンソースライブラリで、レイアウトを解析し、読み取り順序を再構築し、表の構造を復元した上で、すべてをmarkdown、HTML、またはJSONにエクスポートします。すべてはあなたのマシン上で実行され、APIは不要です。これは、文書が契約書や医療記録である場合にまさに求められる制約条件です。

著者 Mohamed Meguedmi·更新 2026-09-28·Windows・macOS・Linuxでテスト済み

#その後のすべてのプロセスを決定するステップ

文書アシスタントの回答が不適切だと、モデルが原因だと考えられがちです。しかし、原因はほぼ常に前段の処理にあります。企業のテンプレートからエクスポートしたレポートを単純なテキスト抽出ツールにかけると、ページのヘッダーが段落の途中に入り込み、2段組みの文章が横方向に読み取られ、結果の表が何を表すか分からない数値の羅列になる、といったテキストの流れが生まれます。その後、これらの断片がエンコードされ、検索で取り出され、事実としてモデルに提示されます。モデルは意味の通らない内容を読み、それを自信たっぷりに回答として返します。処理の前段で失敗した変換は、どんな埋め込みモデル、リランカー、プロンプトでも取り戻せません。多くのローカルRAGのチュートリアルは言語モデルの選択に集中し、この点には触れていません。

Docling は、見過ごされがちなこの工程に直接取り組んでいます。このプロジェクトは2024年7月に IBM Research によって MIT ライセンスでオープンソースとして公開され、使用料やコピーレフトの義務なしに商用利用できます。GitHub のスター数は短期間で10,000を超え、2025年初頭には世界で最も注目されているリポジトリの一つに数えられていました。2026年9月末には公式リポジトリのスター数が68,000を超え、最新安定版の v2.130.0 は2026年9月22日に公開されていました。

#Docling が行っていること

ローカルRAGキット

あなたのドキュメント、あなたのAI:あなたのPDF、メモ、メールを扱う信頼性の高いローカルRAG。何もクラウドに送信しません。

  • 永久に利用できるオンラインスペース
  • PDF + ファイル
  • 生涯アップデート
レイアウト分析
ページ内の各領域とその種類を識別し、キャプションが段落にくっついたり、フッターが文の途中に入り込んだりしないようにします。
読み順
人が読む順序を再構成することで、段組みの文書もようやく活用できるようになります。
テーブルの構造
行、列、結合されたセルを検出し、単なるテキストの行ではなく、実際の表としてエクスポートします。
必要に応じて光学文字認識を実施
テキストレイヤーのないスキャンページは、空のまま取り込むのではなく、OCRで文字を認識してから取り込みます。
グラフの理解
円グラフ、ヒストグラム、折れ線グラフは、単に無視するのではなく、データ表や文章による説明に変換できます。
統一された文書モデル
共通の内部表現と、複数のエクスポート形式(Markdown、HTML、DocTags、情報を失わない JSON)を備えているため、後続の処理では、入力が PDF だったかオフィス文書だったかを意識する必要がありません。

DoclingはPDFだけでなく、DOCX、PPTX、XLSX、HTML、EPUB、画像(PNG、TIFF、JPEGなど)、メール(EML、MSG)にも対応し、文字起こしパイプラインを通じて音声(WAV、MP3)まで扱えます。実際のコーパスは決して均質ではないため、この対応範囲は重要です。連携面では、このライブラリは数行のコードでLangChain、LlamaIndex、Crew AI、Haystackに接続できるため、エージェントを使ったパイプラインで変換コードを自分で書く手間を省けます。

#表の処理こそ、手間をかける価値がある理由

業務文書では、数値はほぼ常に表の中にあり、単純な抽出が最も大きく失敗するのもそこです。ある行が「Paris 12 480 3,2」という並びになると、その数値に意味を与えていた列見出しが失われています。その後、検索は一見正しそうな抜粋を返し、モデルは値の間の関係をでっち上げます。その結果、気づきにくい形で回答が誤ったものになります。

Doclingはこの処理を専用モデルのTableFormerに任せています。TableFormerは、OTSL(Optimized Table Structure Language)という専用の語彙で表の構造を符号化し、結合セルや複数階層の見出しを適切に処理します。この形式の基になった研究論文によると、OTSLは、同等のHTML表現では28トークンを超える内容をわずか数トークンで表現できます。そのため、予測するシーケンスの平均長を約半分に短縮し、HTMLを生成するモデルと比べて推論時間を半分にできます。これはエンドユーザーには見えないアーキテクチャ上の細部ですが、表の認識だけにGPUを割り当てなくても、Doclingが大量のデータで実用性を保てる理由を説明しています。パイプラインのオプションには2つのモードがあります。FASTは高速ですが、複雑な表では精度が低くなります。ACCURATEは、結合セルや複数階層の見出しがある表で推奨されます。Markdownでも構造を維持すれば、各値とその項目名の対応関係を保てます。求められる回答が数値であるコーパスでは、この点だけでも、単純なテキスト抽出ツールより処理の重い変換ツールを使う十分な理由になります。

!
5つのドキュメントを手動で確認する
コーパス全体を取り込む前に、代表的な5つのドキュメントを変換し、生成されたMarkdownを確認してください。特にテーブルとページ分割に注意して読みましょう。ここで10分かけることで、モデルを責める1週間を避けることができます。

#利用可能なOCRエンジン

Doclingは単一のOCRエンジンだけを搭載するのではなく、文書の種類に応じて複数の交換可能なエンジンを統括します。EasyOCRとTesseract(tesserocr経由またはコマンドラインで使用)は大半のケースに対応し、RapidOCRはカスタムモデルを利用できます。OcrMacは、利用可能な場合にmacOSのネイティブ文字認識機能を活用します。エンジンはアプリケーションのコードではなくパイプラインのオプションで選択するため、文書取り込みのロジックを変更せずに切り替えられます。

実際、本番用のデータ取り込みパイプラインでは、ほぼ必ず最初にサンプルでTesseractを試します。きれいなテキストが得られるなら、EasyOCRのコストを負担する理由はありません。EasyOCRへの切り替えが特に妥当なのは、劣化したスキャン、一部が手書きのフォーム、またはTesseractの認識精度が落ちる言語の場合です。RapidOCRとOcrMacは依然として用途の限られた選択肢で、それぞれ、すでに学習済みの自作OCRモデルを使う場合と、外部依存関係のインストールが不要な独立したMac端末で使う場合に限られます。

ドキュメントに応じてOCRエンジンを選択します
エンジン強み典型的な用途
Tesseract鮮明な文字を高速に処理すでにきれいにスキャンされたデジタル文書
EasyOCR劣化したスキャンや標準的でない文字にも、より頑健に対応。use_gpuでGPUの使用を任意に設定可能アーカイブ、フォーム、多様な資料が混在するコーパス
RapidOCRカスタムモデルのサポートあり特定のニーズ(希少言語、専門分野)
OcrMacmacOSのネイティブエンジンを使用し、追加の依存関係を必要としませんMacでの作業、少量の文書処理

#構造に沿った分割

ローカルRAGのガイドの大半で説明されていない点があります。Doclingは単に変換するだけでなく、再構築した文書に適した分割も提供します。HybridChunkerは、文書の階層構造(見出し、セクション)を起点に、選択した埋め込みモデルの実際のトークナイザーに合わせて各チャンクのサイズを調整します。長すぎるブロックは文の途中ではなく要素の境界で分割され、同じ見出しを持つ短すぎるブロックは結合されます。渡すトークナイザーは、後段で使用する埋め込みモデルのトークナイザーに合わせる必要があります。そうしないと、チャンクの実際のサイズ(トークン数)がベクトルインデックスの想定と一致しなくなります。これは文書構造に基づく分割であり、文の区切りを考慮せず文字数でブロックに分ける方法と比較できます。両者のトレードオフについては、当サイトのチャンク分割戦略ガイドをご覧ください。

#計算コスト

構成による概算
構成スループットどのような場合に十分か
プロセッサのみ、OCR機能なし最も遅い:複雑なページごとに数秒かかります小規模なコーパス、単発の変換
CPUのみで処理、OCRありさらに遅く、OCRが処理時間の大半を占める数件のスキャン済み文書
GPU を使用する場合ページ分析、テーブル処理、EasyOCRによるOCRにおいてははるかに速い数千ページ、繰り返しの取り込み

実際の運用では、バッチ単位で一度だけ変換し、その結果を保存します。再インデックスが必要なのは、元のデータが変わった場合だけです。また、言語モデルも提供しているマシンでは、パイプラインの高速化オプションを使うと、両方の処理が同じGPUを取り合います。ユーザーが質問している間にコーパスを取り込むと、両方の処理が遅くなります。

#処理の流れにおける役割

  1. 01
    変換する
    Docling はファイルを markdown または構造化された JSON に変換し、テーブルをそのまま保持します。
  2. 02
    チャンクに分割する
    HybridChunkerでは、モデルの埋め込みトークナイザーと検出された構造に従って処理し、単純に1,000文字ごとに分割するわけではありません。ここでコンバーターが二度目の価値を発揮します。
  3. 03
    エンコードして保存する
    ローカルの埋め込みモデルが断片をベクトルに変換し、そのベクトルを Qdrant などのベクトルデータベースに格納します。
  4. 04
    回答
    ローカルモデルはOllamaまたはローカル推論サーバーを介して、検索された文章から文章を生成します。

#まだ残る課題

品質の低いスキャン
斜めになったコピーのOCR精度には、ソフトウェアではなく物理的な限界があります。
非常にグラフィカルなレイアウト
雑誌、図の周囲に回り込むテキスト、フォームは、どの変換ツールでも扱いが難しいものです。
手書き文字
このカテゴリのツールの範囲外です。
複雑な図表
一般的なグラフ(円グラフ、棒グラフ、折れ線グラフ)は理解できます。ただし、地図、技術図、アーキテクチャ図などの特殊な図は、元の数値を含めず、凡例だけが再現される場合が依然としてあります。
導入時の負担
レイアウト、表、OCR のモデルをインストールするには、初回起動時に数ギガバイトのダウンロードが必要です。ネットワークに接続できない隔離環境のマシンでは、これらを事前に入手しておく必要があります。

#FAQ

Doclingは無料ですか?+
はい。IBM Researchが2024年7月にMITライセンスで公開したオープンソースプロジェクトで、現在はLF AI & Data Foundationがホストしています。このライセンスでは、ライセンス料を支払うことも、自分のコードを再公開することも義務付けられず、商用利用が可能です。ツールはローカルで実行され、APIキーは不要で、変換したページ数や文書数に応じた課金もありません。
GPU は必要か?+
いいえ、DoclingはCPU上で動作します。ただし、ページ構成の解析、テーブル認識、EasyOCRエンジンはGPUで実行可能なモデルに依存しており、accelerator_options でGPUを有効にすることで、大量のデータに対する変換時間を大幅に削減できます。数十ドキュメント程度であれば、CPUで十分です。
スキャンされたPDFを読み取れますか?+
はい。プラットフォームに応じて、EasyOCR、Tesseract、RapidOCR、OcrMacのいずれかのOCRエンジンで読み取れます。テキストレイヤーのない文書では、OCRを有効にする必要があります。読み取りの品質はスキャンの状態に左右されます。300dpiの鮮明な文書なら良好に読み取れますが、斜めになったコピーでは精度が大きく落ちます。
TableFormerのFASTモードとACCURATEモードの違いは?+
FAST は速度を重視し、見出し行が 1 行だけのシンプルな表に適しています。ACCURATE はより低速ですが、文書に結合セルや複数階層の見出しが含まれている場合に推奨されます。こうした構造は、財務報告書や技術仕様書でよく見られます。
Doclingとシンプルなテキスト抽出ツール、どちらを使うべきですか?+
単純なテキスト抽出ツールのほうが高速で、1段組みの整ったテキストに適しています。Doclingを使う意義があるのは、複雑なレイアウト、表、PDF・Office文書・スキャン画像が混在する多様なコーパスを扱う場合です。つまり、実際の企業文書の大半が該当します。
Docling は LangChain または LlamaIndex と統合できますか?+
はい、このプロジェクトは LangChain、LlamaIndex、Crew AI、Haystack 向けに、そのまま使える連携機能を提供しています。これにより、ドキュメント変換と RAG パイプラインの残りの部分をつなぐコネクターを自分で書く必要がなくなります。Docling で変換されたドキュメントは、これらのフレームワークのドキュメントローダーが想定する形式で直接渡され、分割、続いてインデックス化を行える状態になります。
データは私のマシンから出るのですか?+
いいえ。レイアウト解析、表認識、OCRのモデルをダウンロードした後は、変換は完全にローカルで行われ、文書の処理中にネットワークへのアクセスは必要ありません。これはまさに、契約書、診療記録、会計書類などの機密文書に適した理由です。こうした文書は、サードパーティのAPIを経由させず、手元のコンピューターまたは自分で管理するサーバー内に留めておく必要があります。
このガイドは役に立ちましたか?

ご意見、誤りのご指摘、補足はありますか?ぜひお知らせください。皆さんにとってより良いガイドにするために役立ちます。