FlowTune Media

MarkItDown — Microsoftが「オフィス文書の刑務所」から解放してくれる小さなツール

MicrosoftオープンソースMCPAIコーディングAIツール

RAGパイプラインを組んだことがある人なら、一度はこう思ったはずだ。「PDF、Word、Excel、PowerPointを、ちゃんとLLMに食わせられる形に変換するだけで、なぜここまで面倒なのか」と。

Microsoftが静かに育てているMarkItDownは、その面倒をほぼ一掃する。2024年末にMicrosoft Research発のプロジェクトとして登場し、2026年4月時点でGitHubスターは91,000超、Trendshiftの「Document processing」カテゴリでもしっかり上位にいる。これはもう「知る人ぞ知る便利ツール」ではなく、LLMワークフローの事実上の前処理標準になりつつある存在だ。

MarkItDownが解決する問題

MarkItDownがやることは名前通り、ファイルをMarkdownに変換する、それだけだ。だがこの「それだけ」の重みは、実際にRAGや長文コンテキスト用途でドキュメントを扱ったことがある人でないと伝わりにくい。

PDFにはpdfplumberやPyMuPDFがある。Wordにはpython-docxがある。Excelにはopenpyxlがある。PowerPointにはpython-pptxがある。それぞれ使えば変換はできる。だが、統一されたMarkdown出力を得ようとすると、自分でラッパーを書くことになる。しかも、各ライブラリが返すオブジェクト構造はバラバラで、見出し階層の推定、表の再構成、箇条書きの検出を自前で書くのは地獄だ。

MarkItDownはこの「統一ラッパー」を最初から用意してくれている。しかも対応フォーマットが広い。

カテゴリ 対応フォーマット
オフィス文書 PDF、Word（docx）、Excel（xlsx）、PowerPoint（pptx）
Web・マークアップ HTML、CSV、JSON、XML
画像・音声 PNG/JPG（OCR経由）、MP3/WAV（音声認識経由）
その他 ZIP、EPub、YouTube URL（字幕取得）

YouTubeのURLを渡したら字幕を抜いて返してくれる、というのは地味だが強力な機能で、動画コンテンツをRAGに取り込みたい時の定型処理を1コマンドに畳み込んでくれる。

使い方の最小例

MarkItDownの導入は拍子抜けするほど簡単だ。Pythonパッケージをインストールして、ファイルを渡すだけで済む。

pip install 'markitdown[all]'

from markitdown import MarkItDown

md = MarkItDown()
result = md.convert("sample.pdf")
print(result.text_content)

[all]を付けると全フォーマットの依存関係が一括で入る。PDFだけ、Officeだけ、など用途を絞りたい場合はmarkitdown[pdf]やmarkitdown[docx]のように指定できる。

出力はresult.text_contentがMarkdown文字列、result.titleがドキュメントタイトル（取得できる場合）。これをそのままLLMのプロンプトに突っ込んでもいいし、チャンク分割してベクトルDBに入れてもいい。

CLIも同梱されているので、シェルから一発で変換もできる。

markitdown report.pdf > report.md

こういう「curl的に使える」インターフェースを持っていると、ワンオフの変換タスクも気軽に走らせられる。

MCPサーバーとしてClaude Codeから直接叩く

もうひとつの注目ポイントが、MarkItDown-MCPパッケージだ。これはMCP（Model Context Protocol）サーバーとしてMarkItDownを公開するもので、Claude Desktop、Claude Code、Cursor、その他MCP対応クライアントから直接呼び出せる。

設定は以下のような.mcp.jsonを置くだけ。

{
  "mcpServers": {
    "markitdown": {
      "command": "uvx",
      "args": ["markitdown-mcp"]
    }
  }
}

これでClaude Codeから「このPDFをMarkdownに変換して要約して」と頼めば、MarkItDownが裏で走って結果をClaudeに渡し、そのまま要約まで繋がる。ファイル変換→LLM投入という2ステップのワークフローが、ユーザー視点では1ステップに畳まれる。

筆者はこの使い方が一番気に入っている。単体のPythonツールとして使うと「結局この結果をどこに食わせるか」でもう一手間だが、MCP経由にすればLLMセッションの中で完結する。PDF100ページを渡して「この資料の要点と、引用可能な数字を抜いて」と頼むだけで、変換・解析・要点抽出が一気通貫で走る。

実現可能になること

MarkItDownが前処理のボトルネックを解消することで、現実的になるユースケースを3つ挙げておきたい。

1つめは、「社内文書全部RAG」の実装コスト激減。 これまでRAGを組むときの最大の工数は実はベクトルDBやLLM連携ではなく、「多様な文書フォーマットを安定してテキスト化する」部分だった。MarkItDownを使えば、WordもPDFもPowerPointも同じ出力インターフェースで扱えるため、パイプラインの冒頭が1行で書ける。中小企業がRAGを導入するハードルが明らかに下がる。

2つめは、Claude Code + MCPによる「ドキュメント駆動開発」。 仕様書PDF、設計書docx、Excelの要件表、PowerPointのフロー図、これらを全部Claude Codeに渡しながら実装を進めるスタイルが現実的になる。これまでは「仕様書を読み込ませるために手動でコピペする」工程が入っていたが、MCPサーバー経由なら仕様書のパスを渡すだけで中身がLLMコンテキストに入ってくる。

3つめは、音声・動画のテキスト前処理の統合。 MP3やYouTube URLを扱える点が、地味だが効いてくる。ポッドキャストのスクリプト化、会議録音の要約、動画マニュアルの章立て作成といった作業を、同じインターフェースで扱える。これまでWhisper + ffmpeg + 独自スクリプトで組んでいたワークフローが、ほぼMarkItDown呼び出しひとつに畳み込める可能性がある。

微妙な点・懸念

もちろん万能ではない。実際に使っていて気になる点もいくつかある。

まず、PDFの表抽出は完璧ではない。 複雑なレイアウト（結合セル、ネストした表、段組み）のPDFを変換すると、表構造が崩れたり、テキストの順序がめちゃくちゃになることがある。内部的にpdfminer.sixやpdfplumberを使っているため、それらのライブラリの限界を継承している。重要な表が入っているPDFは、変換結果を目視確認する癖をつけたほうがいい。

次に、画像OCRの精度は言語依存。 MarkItDownは画像からのOCRも扱えるが、日本語の縦書きや古い文書のOCR精度は期待しすぎないほうがいい。Tesseractベースの実装なので、日本語精度を求めるならGoogle Cloud Vision APIや他の専用OCRと組み合わせるほうが無難だろう。

そして、プロジェクト規模が急速に拡大している副作用もある。 GitHub上でkepano氏（Obsidian創業者）が言及していたように、「Microsoft公式が各フォーマット専用の高品質ライブラリを用意するほうが本来望ましい」という意見もある。現状のMarkItDownは「とりあえず色々繋いだ」構成なので、各フォーマットの抽出品質はバラつきがある。Wordは安定しているがPDFは波がある、といった差を事前に理解しておく必要がある。

最後に、MCPサーバー版は相対的にまだ新しい。 メインのPythonライブラリほど枯れておらず、エラーメッセージが分かりにくい場面がある。Claude Codeから呼んでも無反応なときは、ターミナルでuvx markitdown-mcpを単体起動してログを確認する、というデバッグが必要になることがある。

まとめ

MarkItDownは「地味だが必需品」のカテゴリに属するツールだ。GPT-5やClaude Sonnet 4.6がどれだけ賢くても、そもそも読める形でファイルが渡せなければ意味がない。その「最初の一歩」を標準化してくれるツールとして、RAGやエージェント系の開発をしている人は一度触っておいて損はない。

個人的な結論を言えば、新規でLLMワークフローを組むなら、まずMarkItDown + MCPを前提に設計するのが2026年時点での素直な選択だと思う。自前で変換ラッパーを書く時間を、もっと本質的なプロンプト設計やベクトル検索のチューニングに回せる。それが、このツールが91,000スターを集めている本当の理由だろう。

GitHub - microsoft/markitdown

関連記事