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は不要です。これは、文書が契約書や医療記録である場合にまさに求められる制約条件です。
#その後のすべてのプロセスを決定するステップ
文書アシスタントの回答が不適切だと、モデルが原因だと考えられがちです。しかし、原因はほぼ常に前段の処理にあります。企業のテンプレートからエクスポートしたレポートを単純なテキスト抽出ツールにかけると、ページのヘッダーが段落の途中に入り込み、2段組みの文章が横方向に読み取られ、結果の表が何を表すか分からない数値の羅列になる、といったテキストの流れが生まれます。その後、これらの断片がエンコードされ、検索で取り出され、事実としてモデルに提示されます。モデルは意味の通らない内容を読み、それを自信たっぷりに回答として返します。処理の前段で失敗した変換は、どんな埋め込みモデル、リランカー、プロンプトでも取り戻せません。多くのローカルRAGのチュートリアルは言語モデルの選択に集中し、この点には触れていません。
Docling は、見過ごされがちなこの工程に直接取り組んでいます。このプロジェクトは2024年7月に IBM Research によって MIT ライセンスでオープンソースとして公開され、使用料やコピーレフトの義務なしに商用利用できます。GitHub のスター数は短期間で10,000を超え、2025年初頭には世界で最も注目されているリポジトリの一つに数えられていました。2026年9月末には公式リポジトリのスター数が68,000を超え、最新安定版の v2.130.0 は2026年9月22日に公開されていました。
#Docling が行っていること
あなたのドキュメント、あなたの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でも構造を維持すれば、各値とその項目名の対応関係を保てます。求められる回答が数値であるコーパスでは、この点だけでも、単純なテキスト抽出ツールより処理の重い変換ツールを使う十分な理由になります。
#利用可能なOCRエンジン
Doclingは単一のOCRエンジンだけを搭載するのではなく、文書の種類に応じて複数の交換可能なエンジンを統括します。EasyOCRとTesseract(tesserocr経由またはコマンドラインで使用)は大半のケースに対応し、RapidOCRはカスタムモデルを利用できます。OcrMacは、利用可能な場合にmacOSのネイティブ文字認識機能を活用します。エンジンはアプリケーションのコードではなくパイプラインのオプションで選択するため、文書取り込みのロジックを変更せずに切り替えられます。
実際、本番用のデータ取り込みパイプラインでは、ほぼ必ず最初にサンプルでTesseractを試します。きれいなテキストが得られるなら、EasyOCRのコストを負担する理由はありません。EasyOCRへの切り替えが特に妥当なのは、劣化したスキャン、一部が手書きのフォーム、またはTesseractの認識精度が落ちる言語の場合です。RapidOCRとOcrMacは依然として用途の限られた選択肢で、それぞれ、すでに学習済みの自作OCRモデルを使う場合と、外部依存関係のインストールが不要な独立したMac端末で使う場合に限られます。
| エンジン | 強み | 典型的な用途 |
|---|---|---|
| Tesseract | 鮮明な文字を高速に処理 | すでにきれいにスキャンされたデジタル文書 |
| EasyOCR | 劣化したスキャンや標準的でない文字にも、より頑健に対応。use_gpuでGPUの使用を任意に設定可能 | アーカイブ、フォーム、多様な資料が混在するコーパス |
| RapidOCR | カスタムモデルのサポートあり | 特定のニーズ(希少言語、専門分野) |
| OcrMac | macOSのネイティブエンジンを使用し、追加の依存関係を必要としません | Macでの作業、少量の文書処理 |
#構造に沿った分割
ローカルRAGのガイドの大半で説明されていない点があります。Doclingは単に変換するだけでなく、再構築した文書に適した分割も提供します。HybridChunkerは、文書の階層構造(見出し、セクション)を起点に、選択した埋め込みモデルの実際のトークナイザーに合わせて各チャンクのサイズを調整します。長すぎるブロックは文の途中ではなく要素の境界で分割され、同じ見出しを持つ短すぎるブロックは結合されます。渡すトークナイザーは、後段で使用する埋め込みモデルのトークナイザーに合わせる必要があります。そうしないと、チャンクの実際のサイズ(トークン数)がベクトルインデックスの想定と一致しなくなります。これは文書構造に基づく分割であり、文の区切りを考慮せず文字数でブロックに分ける方法と比較できます。両者のトレードオフについては、当サイトのチャンク分割戦略ガイドをご覧ください。
#計算コスト
| 構成 | スループット | どのような場合に十分か |
|---|---|---|
| プロセッサのみ、OCR機能なし | 最も遅い:複雑なページごとに数秒かかります | 小規模なコーパス、単発の変換 |
| CPUのみで処理、OCRあり | さらに遅く、OCRが処理時間の大半を占める | 数件のスキャン済み文書 |
| GPU を使用する場合 | ページ分析、テーブル処理、EasyOCRによるOCRにおいてははるかに速い | 数千ページ、繰り返しの取り込み |
実際の運用では、バッチ単位で一度だけ変換し、その結果を保存します。再インデックスが必要なのは、元のデータが変わった場合だけです。また、言語モデルも提供しているマシンでは、パイプラインの高速化オプションを使うと、両方の処理が同じGPUを取り合います。ユーザーが質問している間にコーパスを取り込むと、両方の処理が遅くなります。
#処理の流れにおける役割
- 01変換するDocling はファイルを markdown または構造化された JSON に変換し、テーブルをそのまま保持します。
- 02チャンクに分割するHybridChunkerでは、モデルの埋め込みトークナイザーと検出された構造に従って処理し、単純に1,000文字ごとに分割するわけではありません。ここでコンバーターが二度目の価値を発揮します。
- 03エンコードして保存するローカルの埋め込みモデルが断片をベクトルに変換し、そのベクトルを Qdrant などのベクトルデータベースに格納します。
- 04回答ローカルモデルはOllamaまたはローカル推論サーバーを介して、検索された文章から文章を生成します。
- Qdrantにベクトルを保存する
- チャンキング戦略を比較する
- 自分のドキュメントについてチャットできる、すぐに使えるアプリ
- 特別なケース:請求書からデータを抽出
- Tesseract単体:鮮明なテキスト向けの、よりシンプルなOCR
- QuelLLMローカルRAGキット:すべてのコンポーネントを1ページに
- 出典:GitHub上の公式リポジトリ Docling
- 出典:Doclingパイプラインのオプション(OCR、TableFormer)
- ソース:HybridChunker ドキュメント
#まだ残る課題
- 品質の低いスキャン
- 斜めになったコピーのOCR精度には、ソフトウェアではなく物理的な限界があります。
- 非常にグラフィカルなレイアウト
- 雑誌、図の周囲に回り込むテキスト、フォームは、どの変換ツールでも扱いが難しいものです。
- 手書き文字
- このカテゴリのツールの範囲外です。
- 複雑な図表
- 一般的なグラフ(円グラフ、棒グラフ、折れ線グラフ)は理解できます。ただし、地図、技術図、アーキテクチャ図などの特殊な図は、元の数値を含めず、凡例だけが再現される場合が依然としてあります。
- 導入時の負担
- レイアウト、表、OCR のモデルをインストールするには、初回起動時に数ギガバイトのダウンロードが必要です。ネットワークに接続できない隔離環境のマシンでは、これらを事前に入手しておく必要があります。
#FAQ
Doclingは無料ですか?+
GPU は必要か?+
スキャンされたPDFを読み取れますか?+
TableFormerのFASTモードとACCURATEモードの違いは?+
Doclingとシンプルなテキスト抽出ツール、どちらを使うべきですか?+
Docling は LangChain または LlamaIndex と統合できますか?+
データは私のマシンから出るのですか?+
ご意見、誤りのご指摘、補足はありますか?ぜひお知らせください。皆さんにとってより良いガイドにするために役立ちます。