先に結論
この比較は、どの parser が一番賢いか ではなく、どこまで前処理責任を持たせたいか で選ぶのが正解です。
- MarkItDown: とにかく早く Markdown 化したい
- Docling: layout・表・reading order まで深く取りたい
- LlamaParse: managed API で精度寄りに進めたい
- Unstructured: parsing だけでなく ETL / connectors / enrichment までまとめたい
なので、実務ではこう分けるとズレません。
- まず OSS で PDF / DOCX / PPTX を AI-ready にしたい なら MarkItDown
- ローカル実行や air-gapped を守りつつ PDF 理解を深くしたい なら Docling
- 複雑 layout や scanned PDF も含めて managed で早く本番へ寄せたい なら LlamaParse
- enterprise の document ETL 全体を載せたい なら Unstructured
1文で言うなら、Markdown 変換なら MarkItDown、深い PDF 理解なら Docling、精度寄り managed parsing なら LlamaParse、前処理プラットフォームまで要るなら Unstructured です。
なぜ今この比較が重要か
RAG や agent workflow で詰まりやすいのは、embedding や vector DB より前の ingest 層 です。
PDF、Word、PowerPoint、HTML、画像混在資料をそのまま流すと、次の問題が起きます。
- 見出しと本文の階層が壊れる
- 表が行列として残らない
- header / footer がノイズになる
- scanned PDF が空振りする
- chunk が不自然になり retrieval 品質が落ちる
つまり、文書解析レイヤーを雑に選ぶと、その後の embedding、rerank、agent 回答精度まで全部に悪影響が出ます。
embedding 側の比較は Gemini Embedding 2 vs Voyage 4 vs Cohere Embed v4 vs OpenAI text-embedding-3-large がつながりますが、その前段として 何をどう chunk-ready にするか のほうが先に効くことが多いです。
比較表
| 比較軸 | MarkItDown | Docling | LlamaParse | Unstructured |
|---|---|---|---|---|
| 主な立ち位置 | 軽量 Markdown 変換 OSS | 高度 PDF understanding OSS | managed parsing API | enterprise data ETL / preprocessing platform |
| 強い入力 | PDF、Office、HTML、CSV、JSON、画像、音声、YouTube など | PDF、DOCX、PPTX、XLSX、HTML、画像、音声、LaTeX、WebVTT など | 複雑 layout、tables、charts、handwriting、scanned PDFs | 64+ file types、enterprise sources |
| 出力 | Markdown 中心 | Markdown、HTML、DocTags、lossless JSON | clean markdown、構造化抽出寄り | chunking、enrichment、embedding まで含む |
| OCR / scanned PDF | plugin や Azure Document Intelligence で補完 | OCR を強く訴求 | multimodal parsing を前面訴求 | platform 側で前処理に含める |
| ローカル実行 | しやすい | とても強い | enterprise 向け local cloud 訴求 | SaaS / platform 主体 |
| agent 連携 | MCP server、Python、CLI | LangChain / LlamaIndex / CrewAI / Haystack / MCP | LlamaIndex 周辺と相性が良い | API、UI、connectors、partners |
| 向く人 | 開発者、PoC、軽量 ingest | 機密文書、研究文書、表やレイアウト重視 | 精度重視の商用導入 | データ基盤 / IT / enterprise AI チーム |
| 編集部評価 | 4.5 | 4.8 | 4.7 | 4.6 |
4つの違いをひとことで言うと
MarkItDown
MarkItDown は、LLM に食べさせやすい Markdown へ手早く落とすための軽量 OSS です。
公式 README でも、PDF、PowerPoint、Word、Excel、画像、音声、HTML、CSV、JSON、XML、ZIP、YouTube URL など幅広い入力を Markdown に変換できる点を前面に出しています。MCP server も用意されていて、Claude Desktop のような LLM アプリへつなぎやすいのも特徴です。
ただし主語はあくまで 高忠実度な表示再現ではなく、text analysis pipelines 向け Markdown です。
だから MarkItDown がハマるのは、
- まず Markdown 化して chunking へ進みたい
- Office 文書や HTML をまとめて ingest したい
- Python / CLI / MCP で軽く組み込みたい
- OSS で小さく始めたい
ケースです。
逆に、複雑な表、reading order、学術 PDF、スキャン文書の品質まで最優先にすると、MarkItDown 単独では物足りないことがあります。
Docling
Docling は、local execution を守りながら高度 PDF understanding まで踏み込める OSS です。
公式 README では、page layout、reading order、table structure、code、formulas、image classification まで含む advanced PDF understanding を強く打ち出しています。Markdown だけでなく lossless JSON や DocTags も扱え、LangChain、LlamaIndex、CrewAI、Haystack、MCP server までつながります。
ここが重要です。Docling は単なる file-to-markdown 変換ではなく、文書の構造理解をどこまで残せるか が主役です。
向いているのは、
- 表や段組みが多い PDF
- 機密文書をローカル / air-gapped で処理したい
- chunk 前に layout 情報を保持したい
- OSS を使いたいが parsing 品質で妥協したくない
ケースです。
RAG 品質を本気で上げたいチームほど、Docling のように ingest 層で構造を残せる恩恵が大きいです。
LlamaParse
LlamaParse は、layout-aware / multimodal parsing を managed で使いたい人向けの本命 です。
公式サイトでは、complex layouts、tables、charts、handwriting、checkboxes、images を clean markdown に変換できること、100+ languages 対応、cost / accuracy を調整できる parsing modes、enterprise-ready、local cloud deployment まで訴求しています。
つまり LlamaParse の価値は、OSS を育てることではなく、難しい文書を managed で早く本番へ持っていけること です。
向いているのは、
- 精度寄りで導入を急ぎたい
- scanned PDF や複雑 layout が多い
- LlamaIndex 周辺と相性よく進めたい
- 運用コストより結果の安定性を優先したい
ケースです。
OSS で十分か迷うときは、「社内で parser 改善に時間を使うか、managed API に寄せて retrieval 精度へ集中するか」で見ると判断しやすいです。
Unstructured
Unstructured は、parser 単体というより enterprise 前処理基盤 と見たほうがズレません。
公式サイトでは、64+ file types、chunking / enrichment / embedding、30+ connectors、1,250+ pipelines、role-based access、security / compliance をまとめて訴求しています。UI と API の両方があり、Databricks、MongoDB、Pinecone、Weaviate、Elastic など partner 接続も強いです。
要するに Unstructured の主語は、文書を parse すること だけではなく、どこから取り込み、どう変換し、どこへ流すか まで含むことです。
だから向いているのは、
- enterprise で source が多い
- 自前の connectors 地獄を避けたい
- chunking / enrichment / embedding まで同じ基盤に寄せたい
- data engineering と AI 前処理を一体で回したい
ケースです。
逆に「PDF を少し Markdown 化したい」だけなら、明らかにオーバースペックです。
どう選ぶべきか
まず OSS で試したい
MarkItDown からで十分です。
Office 文書や PDF を Markdown 化し、どの程度の品質で検索や要約が成立するかを見るには速いです。PoC の初速が出ます。
OSS でも parsing 品質を上げたい
Docling が本命です。
MarkItDown より重くなりますが、表、段組み、reading order を意識したいときの伸びしろが大きいです。ローカル実行を守りたい組織にも合います。
精度優先で managed に寄せたい
LlamaParse が現実的です。
自前チューニングより、まず retrieval quality と導入速度を取りたいなら合います。特に複雑文書や scanned PDF が多いときに効きます。
enterprise の ingest 基盤そのものを作りたい
Unstructured を検討する価値があります。
parser 比較のつもりで入ると高く見えますが、connectors、pipelines、security、UI / API まで含めると、DIY ETL の保守コスト削減で回収できるケースがあります。
失敗しやすいポイント
1. Markdown が出れば十分と思い込む
Markdown 変換だけで十分な資料もありますが、請求書、財務資料、論文、複雑表では layout 情報が retrieval 品質を左右 します。ここを軽視すると、後段の embedding で取り返せません。
2. OCR を後回しにする
スキャン PDF が混ざるなら最初から考えるべきです。Docling や LlamaParse はこの主語に強く、MarkItDown は plugin や外部サービス補完前提になりやすいです。
3. parser と ETL platform を同列に比べる
Unstructured は parser 単体ではありません。connectors、pipeline maintenance、RBAC まで含むため、比較対象としては一段広いです。そこを揃えずに価格だけ比べると判断を誤ります。
4. 機密文書で managed API を雑に使う
機密度が高いなら local execution の価値が大きいです。Docling や MarkItDown のようなローカル寄り OSS を先に当てるべきケースがあります。
RAG / agent workflow とのつなぎ方
このテーマは parser 単体で終わりません。
- 文書の接続方法 を考えるなら Google Workspace CLI vs Composio vs MCP server vs 直接Google API
- ナレッジ母艦への接続 を考えるなら Notion MCP vs ChatGPT apps vs Claude Projects vs Composio
- embedding 層の選定 を考えるなら Gemini Embedding 2 vs Voyage 4 vs Cohere Embed v4 vs OpenAI text-embedding-3-large
この3層をつなげて初めて、document ingestion は収益や業務改善に効きます。
迷ったときの最終判断
最後はこの順で決めるのが実務的です。
- 複雑 layout / OCR がどれだけ多いか
- ローカル実行が必須か
- parser を OSS で育てる余裕があるか
- connectors / ETL まで一体で必要か
この基準なら、
- 軽く始めるなら MarkItDown
- 深く解析するなら Docling
- managed で精度を買うなら LlamaParse
- enterprise platform に寄せるなら Unstructured
で、ほぼ外しません。