LLM 前処理に MarkItDown が選ばれる理由｜Docling との違いと選定基準

社内文書を LLM に読ませたい、あるいは RAG（Retrieval-Augmented Generation）のインデックスに投入したい。要件は明確なのに、いざ実装フェーズに入ると「どのドキュメント変換ライブラリを選ぶか」で手が止まりがちです。

理由は選択肢の多さです。Microsoft の MarkItDown、IBM の Docling、Unstructured、Marker、PyMuPDF4LLM、そして商用 SaaS の LlamaParse など、方向性の異なる OSS・SaaS が並立しています。精度・速度・対応形式・依存ライブラリ・GPU 要件・料金モデルのトレードオフを一気に把握しないと選定判断がつきません。

本記事では、その中でも指名検索が多い MarkItDown（microsoft/markitdown）に焦点を当て、以下を整理します。

• MarkItDown が何をするツールで、Microsoft スタックのなかでどう位置づけられているのか
• どのファイル形式に対応し、どのようなユースケースで採用されているのか
• Docling / Unstructured / Marker との具体的な違い、そして「どの要件でどれを選ぶべきか」の判断軸
• インストール・CLI・Python API の基本的な使い方、本番運用時のセキュリティ考慮事項

執筆時点の GitHub 上のリポジトリ状態は、archived: false / fork: false / disabled: false / ライセンス MIT（microsoft/markitdown）で、Microsoft 公式リポジトリとして能動的にメンテナンスが継続されています。動作検証は行わず、README・PyPI・Azure 公式ドキュメントおよび複数の技術ブログの二次情報を根拠に、意思決定を支援できる観点で整理していきます。

MarkItDown とは何か｜Microsoft 公式のドキュメント→Markdown 変換 OSS

MarkItDown は、Microsoft が公開している Python 製のドキュメント→Markdown 変換ユーティリティです。リポジトリは microsoft/markitdown で、README では「various files を Markdown へ変換する Python ユーティリティ」であり、LLM やテキスト分析パイプラインでの利用を主眼に置くと明記されています（出典: microsoft/markitdown README）。

位置づけとメンテナンス母体（Microsoft AutoGen チーム）

MarkItDown は「Built by AutoGen Team」バッジが示すとおり、Microsoft の AutoGen チームがメンテナンスしています。AutoGen は Microsoft Research が中心となって推進するマルチエージェントフレームワークで、そのチームが LLM 取り込み用の前処理ユーティリティとして MarkItDown を切り出している構図です。

つまり MarkItDown は「独立系 OSS」ではなく、Microsoft 内部の AI プロジェクトが自ら使うために整備し、外部にも公開している位置づけです。この点は、選定時に「メンテナンス母体は誰か」「継続開発の見通しはどうか」を評価する上で重要な情報になります。

なぜ Markdown 出力なのか（LLM 親和性・トークン効率）

README では、変換先を Markdown に固定している理由として、主流の LLM（GPT-4o 等）が Markdown をネイティブに扱い、同じ情報量でも他形式よりトークン効率が高いことを挙げています（出典: microsoft/markitdown README）。

また、位置づけの類例として textract を引きつつも、単なる素のテキスト抽出ではなく「重要なドキュメント構造（見出し・リスト・表・リンク等）を Markdown として保持することに注力する」点が明確化されています。人向けの高忠実度変換ツールではなく、あくまで「テキスト分析ツール向け」の出力を目指す設計方針です。

リポジトリ基本情報（スター数・ライセンス・最終更新）

執筆時点でのリポジトリ基本情報は以下のとおりです（値は gh api /repos/microsoft/markitdown の実測値）。

スター数 17 万台後半という規模、直近のリリースが 2026 年 7 月末である点、リポジトリが archived / fork / disabled のいずれでもない点から、活動継続中の Microsoft 公式 OSS として扱ってよい状態です。一方でバージョンはまだ 0.1.x 台で、後述するように API 互換性については 0.x 系ゆえの留意が必要です。

MarkItDown が対応するファイル形式と変換の仕組み

MarkItDown の強みは、対応するファイル形式の広さと、その多くを ML モデルに頼らずに処理する軽量なアーキテクチャにあります。パッケージは PyPI（markitdown） から取得でき、バージョン情報・依存関係・エクストラの構成もここから確認できます。

標準サポート形式（PDF / Word / PowerPoint / Excel 等）

README では、標準サポート形式として以下が明示されています（出典: microsoft/markitdown README）。

• PDF
• PowerPoint（.pptx）
• Word（.docx）
• Excel（.xlsx）
• HTML
• CSV / JSON / XML
• ZIP ファイル（内部のファイルを反復的に処理）
• YouTube URL
• EPub
• そのほか多数

Office 系ファイル（Word / PowerPoint / Excel）は Office XML を直接パースするアプローチが採られており、Word の見出し階層や PowerPoint のスライド構造、Excel のセル情報をそのまま Markdown 構造に写し取ります。ML モデルを介さないため CPU のみで動作し、レイアウト解析のコストがかからないぶん高速に処理できるのが特徴です。

追加機能領域（画像 OCR・音声書き起こし・YouTube トランスクリプト）

Markdown 変換の周辺機能として、以下も README で言及されています（出典: microsoft/markitdown README）。

• 画像: EXIF メタデータの抽出と、OCR による本文テキスト化
• 音声: EXIF メタデータの抽出と、音声書き起こしによるテキスト化
• YouTube URL: 自動生成トランスクリプトの取得と Markdown 化

つまり MarkItDown は「文書ファイルだけを扱うツール」ではなく、テキスト以外のモダリティを含めてまとめて Markdown に落とし込むことを想定しています。ここは、LLM のコンテキストに「議事録音声＋関連資料＋YouTube 解説」といった異なる媒体をまとめて投入したいケースで有用です。

プラグイン機構と markitdown-ocr の位置づけ

MarkItDown は 3rd-party プラグインをサポートしており、デフォルトでは無効化された状態で提供されます。GitHub 上ではハッシュタグ #markitdown-plugin でプラグイン群を検索できると案内されています（出典: microsoft/markitdown README）。

代表的な拡張の一つが markitdown-ocr で、PDF / DOCX / PPTX / XLSX 内の画像を LLM Vision で OCR 抽出するプラグインです。標準の PDF パーサでは埋め込み画像内テキストを取得できませんが、このプラグインを組み合わせることで画像 PDF・スクリーンショット中心の資料にも対応の幅を広げられます。プラグイン方式にすることで、コア本体は軽量なまま、必要なユースケースだけ拡張できる設計になっています（実装例の解説として MarkItDown で OCR を組み合わせる方法（Qiita） も参考になります）。

MarkItDown の主なユースケース｜LLM 前処理と RAG 構築

README では、想定される第一のユースケースとして「LLM ingestion」を挙げています。GPT-4o のような主流 LLM に社内ドキュメントを取り込ませ、要約・分類・RAG での参照に使う前段パイプラインとして設計されています。

LLM 取り込み用のシンプルな前処理

もっとも素直な使い方は、社内ストレージから取り出したドキュメントを 1 つの Markdown 文字列に変換し、その本文を LLM API に渡す、あるいはベクターストアにチャンクとして投入する構成です。MarkItDown は「変換のみ」を担うため、チャンキング・埋め込み生成・ベクター DB への保存は LangChain / LlamaIndex のような RAG フレームワーク側に任せる設計が自然になります。

これは、Unstructured のような「ETL プラットフォーム型」のライブラリと対照的な設計思想です。用途を「変換」に絞り、単体で完結する API を提供している分、既存の RAG スタックに後から組み込みやすいのが利点になります。

画像・音声を含む多モーダル文書への拡張

前節で触れた画像 OCR や音声書き起こしを組み合わせると、テキスト以外を多く含む資料（プレゼン資料、議事録音声、動画）を単一の Markdown 表現へ揃えられます。LLM のコンテキストウィンドウは Markdown を扱いやすい設計になっているため、複数モダリティを 1 つのプロンプトに束ねる際の中間フォーマットとして役立ちます。

さらに MarkItDown では、llm_client / llm_model を渡すことで PowerPoint 内の画像・画像ファイルに対して LLM 生成の説明文（キャプション）を挿入する使い方もサポートされています（出典: microsoft/markitdown README）。この機能を有効化すると、単なる OCR では拾いにくい「図の意味」を LLM に読ませたテキスト化結果として Markdown に埋め込めます。

Azure Content Understanding / Document Intelligence との統合

Microsoft 公式 OSS ならではの特徴が、Azure 側のドキュメント理解サービスとの統合です。README では以下 2 つの Azure サービスとの連携が言及されています（出典: microsoft/markitdown README）。

• Azure Content Understanding: 音声・動画への対応拡張、構造化フィールドの抽出（YAML front matter として付与）、カスタムアナライザーによるドメイン別フィールド抽出などが可能。ただし CU 経由の変換は Azure API 課金の対象。
• Azure Document Intelligence: CLI では -d -e "<endpoint>" オプションで有効化。PDF レイアウト解析の精度を Doc Intelligence に肩代わりさせる用途で利用。

README には「built-in / Doc Intelligence / Content Understanding」の 3 者を比較する表も掲載されており、対応形式や強みの棲み分けを一次情報として確認できます。「まずは OSS 単体で試し、精度が足りない部分だけ Azure サービスに逃がす」という段階的な導入がしやすい設計になっている点は、Microsoft スタックを前提とするチームには有力な選定理由になります。

類似 OSS との比較｜Docling / Unstructured / Marker との違い

MarkItDown を検討する場面では、必ずと言っていいほど Docling / Unstructured / Marker といった他の OSS が候補に上がります。ここでは、公式ドキュメントと外部の比較記事を突き合わせながら、5 軸で違いを整理します。

Docling（IBM）との違い｜レイアウト精度 vs 速度・広対応

Docling は IBM 発のドキュメント理解ライブラリで、AI レイアウトモデル（TableFormer など）を用いて表や段組み、読み順を検出し Markdown / JSON / DoclingDocument へエクスポートします。第三者の比較記事では、F1 スコアが Docling 88% / MarkItDown 82%、テーブル抽出精度は Docling が優位、一方で CPU での処理速度は Docling が数分オーダー・MarkItDown が 100 ページ 12 秒程度と報告されています（出典: MarkItDown vs Docling vs Marker（danilchenko.dev） / Docling vs MarkItDown（file2markdown））。

まとめると、複雑な学術論文 PDF や表主体の資料が中心なら Docling 側にレイアウト精度のアドバンテージがあり、Office 中心・大量ドキュメントを CPU で高速に捌きたいなら MarkItDown 側の設計が向く、という棲み分けです。

Unstructured との違い｜変換単機能 vs ETL プラットフォーム

Unstructured は「変換」だけでなく、ソースコネクタ・チャンキング・メタデータ付与を含むドキュメント ETL プラットフォームとして設計されています。RAG パイプライン全体を Unstructured 上に載せて完結させたいユースケースに向いています（比較指標として F1 スコア 85% 前後、GPU で 35 pages/sec 相当という報告があります／出典: Best PDF Parser for RAG（blazedocs.io））。

一方 MarkItDown は「1 ファイルを Markdown 文字列に変換する」ことに絞っており、コネクタ・チャンキングは持ちません。既存の LangChain / LlamaIndex のような RAG フレームワークに載せた上で「入口の変換部分だけ差し替える」構成に向いており、Unstructured と役割レイヤーがそもそも異なります。

Marker との違い｜CPU 軽量 vs GPU 精度

Marker は PDF / EPub / DOCX などを Markdown・JSON・HTML に変換するツールで、ディープラーニングモデルを積極的に使ったテーブル・数式・図表抽出の精度に強みがあります。ただし高速動作のためには GPU が実質的に前提となります（出典: MarkItDown vs Docling vs Marker（danilchenko.dev））。

MarkItDown は逆に「CPU でとにかく多くの形式を軽く処理する」設計です。GPU リソースを常時確保できない環境、あるいは大量ドキュメントをまとめて Markdown 化する ETL 用途では MarkItDown の方が扱いやすく、逆に GPU を割ける環境で PDF の数式・図表精度を優先したい場合には Marker の方が適する、という選び分けになります。

参考: PyMuPDF4LLM / LlamaParse の立ち位置

比較対象として補足しておきたいのが以下 2 つです。

• PyMuPDF4LLM: PyMuPDF ベースの PDF 特化 Markdown 抽出ユーティリティ。PDF だけを対象にしたシンプルな選択肢。
• LlamaParse: LlamaIndex が提供する商用ドキュメントパース SaaS（無料枠あり）。API 経由で高精度な変換を委譲したい場合の候補。

MarkItDown は「Microsoft 公式・OSS・広い対応形式・CPU 前提」という組み合わせで、これらとは立ち位置がはっきり分かれます。「PDF 単体特化なら PyMuPDF4LLM」「SaaS で精度を買うなら LlamaParse」「オンプレ CPU で幅広く変換したいなら MarkItDown」といった第一次スクリーニングをかけると、比較検討が進めやすくなります。

MarkItDown を選ぶ判断軸と注意点

比較を踏まえて、「どういう要件のとき MarkItDown を選ぶべきか」「逆にどういう場面では別 OSS を優先すべきか」を整理します。

採用しやすいケース（Office 中心・依存最小・CPU 環境）

以下のような要件では、MarkItDown が有力な選択肢になります。

• 変換対象の中心が Office ファイル（Word / PowerPoint / Excel）で、レイアウトは比較的単純
• GPU リソースを常時確保できない CPU 中心のオンプレ環境や、コスト最適化されたクラウド VM 上で動かしたい
• 依存パッケージを最小限にしたい（ML モデルの重量ダウンロードや GPU ドライバのセットアップを避けたい）
• Microsoft スタックを既に使っており、必要に応じて Azure Document Intelligence / Content Understanding へ段階的にオフロードしたい
• LLM/RAG の前処理部分だけを差し替えたい（変換に責務を限定したい）

とくに「Office ファイル多め・PDF は補助的」という構成であれば、Docling のような高精度モデルまで動員する必要が薄く、MarkItDown のシンプルさが素直に効いてきます。

追加検討が必要なケース（複雑レイアウト PDF・大量画像 PDF・厳格な精度要求）

一方、以下のようなケースでは MarkItDown 単体では要件を満たしづらく、追加設計が必要になります。

• 学術論文・技術仕様書のように 2 段組み・複雑テーブル・図表混在の PDF が中心 → Docling / Marker と比較検討する
• スキャン PDF・画像 PDF が多く、OCR 精度が成果に直結する → markitdown-ocr プラグイン、あるいは Azure Document Intelligence 連携を組み合わせる
• 抽出結果に高い正確性が要求される（法務文書・監査対象文書など） → 変換結果の目視レビュー工程を含めて設計する
• 大規模データを対象に、コネクタ・チャンキング・エンリッチメントまで一気通貫で処理したい → Unstructured 等の ETL プラットフォームを検討する

MarkItDown を採用する場合でも、「PDF レイアウト精度が足りない部分だけ Doc Intelligence に委譲する」「画像 PDF だけ markitdown-ocr を挟む」といった補完前提で設計するのが現実的です。

バージョン 0.x 系の位置づけと API 変更リスク

MarkItDown は執筆時点で v0.1.7（2026-07-29 公開）と、まだ 0.x 系のバージョンです。0.x 系はセマンティックバージョニングの一般的な扱いとして、マイナーバージョンでも API 変更や破壊的変更が入る可能性がある帯域です。実際、外部の解説記事の中でも「バージョン 0.x 系のため API の変動には注意」という趣旨の指摘が見られます（例: MarkItDown（OpenStandia／NRI））。

本番採用する場合は、以下のような運用上の備えを検討しておくと安全です。

• 依存宣言は markitdown[all]>=0.1.7,<0.2 のように上限を明示し、マイナー跨ぎの自動更新を避ける
• CI で「代表的な社内ドキュメントを変換して、期待する Markdown 構造が保たれるか」を確認するリグレッションテストを組み込む
• リリースノートを継続的に確認する運用体制を整える（microsoft/markitdown の Releases を購読する等）

MarkItDown の導入イメージ｜インストール・CLI・Python API

導入手順の一次情報は README のインストールセクション（microsoft/markitdown#installation）にまとまっています。ここでは README の抜粋をそのまま引用しながら、依存の選び分けの考え方を補足します。

インストール（[all] と個別依存の選び分け）

もっとも簡単な導入方法は、全機能のエクストラを含めて一括インストールする方法です。

pip install 'markitdown[all]'

出典: microsoft/markitdown README

[all] の代わりに、必要なフォーマットに応じたエクストラだけを指定する運用も可能です。README では以下のエクストラが挙げられています。

• [pdf] / [pptx] / [docx] / [xlsx]
• [audio-transcription] / [youtube-transcription]
• [az-doc-intel] / [az-content-understanding]
• [outlook] ほか

出典: microsoft/markitdown README

「イメージサイズを小さく保ちたい」「ライセンス上の依存関係を絞りたい」といった要件がある場合は、必要な形式に対応するエクストラだけを個別指定するのがおすすめです。逆に PoC や社内向け検証用途であれば [all] を選び、あとから絞り込む流れの方が試行錯誤しやすくなります。

CLI での基本操作

CLI は 3 通りの入出力パターンが README に掲載されています。

markitdown path-to-file.pdf > document.md

markitdown path-to-file.pdf -o document.md

cat path-to-file.pdf | markitdown

出典: microsoft/markitdown README

シェルパイプラインに組み込みやすいインターフェースになっているため、既存のドキュメント配布バッチや ETL スクリプトから素直に呼び出せます。

Python API での基本操作と llm_client / docintel_endpoint オプション

Python API 側のもっともシンプルな呼び出しは以下のとおりです。

from markitdown import MarkItDown

md = MarkItDown(enable_plugins=False)
result = md.convert("test.xlsx")
print(result.text_content)

出典: microsoft/markitdown README

MarkItDown クラスのコンストラクタには、以下の主要オプションを渡せます。

• enable_plugins: 3rd-party プラグインの有効化フラグ（デフォルト無効）
• llm_client / llm_model: PowerPoint 内画像・画像ファイルの説明文生成に使う LLM クライアント
• docintel_endpoint: Azure Document Intelligence を経由させる場合のエンドポイント
• Azure Content Understanding 関連のオプション（cu_file_types などで対象形式・スコープを制御可能）

Docker で動かしたい場合は、README にビルド・実行の例が掲載されています。

docker build -t markitdown:latest .

docker run --rm -i markitdown:latest < ~/your-file.pdf > output.md

出典: microsoft/markitdown README

イミュータブルな変換ワーカーとしてコンテナ化しておけば、既存のジョブ基盤（Kubernetes CronJob、Cloud Run Jobs など）にそのまま乗せられます。

本番運用で押さえたい観点｜セキュリティと拡張性

競合記事では触れられにくいものの、業務システムに組み込む場合に無視できないのがセキュリティと拡張性の観点です。ここは README の「Security Considerations」に一次情報がまとまっており、選定判断・設計判断の両方に効いてきます。

セキュリティ考慮事項（信頼できない入力・API スコープ）

README の Security Considerations には、次のような趣旨のことが記載されています（出典: microsoft/markitdown README）。

• MarkItDown はカレントプロセスの権限で I/O を行うライブラリであり、標準の open() や requests.get() と同様のリスクを持つ
• 信頼できない入力に対しては、呼び出し側でサニタイズが必要
  • ファイルパスの範囲を絞る（想定外のディレクトリを触らせない）
  • 許可する URI スキームを制限する（http / https のみに限定するなど）
  • プライベート IP / ループバック / リンクローカル / クラウドのメタデータサービスへのアクセスをブロックする
• 用途に応じてもっとも狭い API を選ぶ（convert_local() / convert_response() / convert_stream() の使い分け）

とくに RAG パイプラインでユーザ提供の URL を受け取るような設計にする場合、SSRF（Server Side Request Forgery）のリスクは無視できません。MarkItDown 側で全ての防御をやってくれるわけではないため、呼び出し側で入力サニタイズと通信先制限を明示的に設計しておく必要があります。

プラグイン拡張と markitdown-ocr 等の 3rd-party

拡張性の面では、前述したプラグイン機構がキーになります。デフォルトではプラグインは無効化されており、必要な拡張だけを能動的にオプトインする形です。

• markitdown-ocr: 画像 OCR を LLM Vision で行うプラグイン
• そのほか、GitHub 上でハッシュタグ #markitdown-plugin で検索できるコミュニティ拡張

3rd-party 拡張は当然ながらメンテナンス品質にばらつきがあるため、本番採用時にはリポジトリの更新頻度・Issue の状況・ライセンスを確認し、必要ならフォークして自チームで面倒を見る覚悟も検討しておくのが安全です。

Azure 連携時のコスト・スコープ制御（cu_file_types 等）

Azure Content Understanding や Document Intelligence を組み合わせると精度・対応範囲は広がる一方、API 課金が発生します。README でも、Content Understanding 経由の変換は Azure API 課金対象であることが明記されています（出典: microsoft/markitdown README）。

コスト管理の観点では、以下のような設計が現実的です。

• MarkItDown の built-in で処理できる形式は built-in に任せ、Content Understanding / Doc Intelligence を呼び出す対象を絞る
• cu_file_types などのオプションで Content Understanding を発火させるファイル種別を明示的に限定する
• Azure 側のリソース単位でクォータ・アラートを設定し、想定外の呼び出し量を検知できるようにする

Azure Content Understanding の全体像・料金体系・利用可能なアナライザーの一覧は、公式ドキュメントの Azure Content Understanding を確認するのが最短です。導入判断の際は、README と公式ドキュメントの両方に目を通した上で、どこまで OSS で完結させ、どこから Azure サービスに委譲するかの線引きを設計しておくのがおすすめです。

まとめ｜MarkItDown を選ぶかどうかの判断チェックリスト

ここまでの内容を、意思決定に直接使えるチェックリストとして再整理します。以下の条件を満たすほど、MarkItDown を主軸に据える構成が有力です。

• 変換対象の中心が Office ファイル（Word / PowerPoint / Excel）である
• 大量のドキュメントを CPU 環境で高速に処理したい（GPU リソースは常時確保しない）
• Microsoft スタックを既に採用しており、必要に応じて Azure Document Intelligence / Content Understanding へ段階的に拡張したい
• RAG 前処理は変換部分だけ差し替えたい（チャンキング・埋め込み生成は既存の LangChain / LlamaIndex に任せたい）
• 依存パッケージを最小限にしたい（ML モデルの重量ダウンロードを避けたい）

一方、以下のいずれかが強く効く要件では、MarkItDown 単体では厳しく、Docling / Unstructured / Marker などとの併用または置き換えを検討したほうが確実です。

• 複雑レイアウト PDF・学術論文・大量テーブルの高精度抽出が最優先
• スキャン PDF・画像 PDF が中心で OCR 精度が成果に直結する
• コネクタ・チャンキング・エンリッチメントまで含む ETL 全体を単一プラットフォームで完結させたい
• ライブラリの API 安定性を最優先し、0.x 系のバージョン推移を追う余裕がない

裏返せば、MarkItDown は「Microsoft スタックと相性がよく、変換を軽量・広対応で片付けたい」チームに素直にはまるツールです。まずは README・PyPI・Azure Content Understanding 公式ドキュメントを一度ざっと読み、自プロジェクトの要件と 5 分照らし合わせるだけでも、選定の解像度は大きく上がります。

関連情報

社内文書の Markdown 化や RAG パイプラインの前処理設計、Azure Document Intelligence / Content Understanding との組み合わせをご検討中の方は、お問い合わせフォーム からご相談ください。要件整理段階からのご相談も歓迎しています。

LLM / RAG やドキュメント処理まわりに関わるフリーランス案件を探している方は、Workee で案件を探す をご覧ください。技術スタックや稼働条件で案件を絞り込めます。