MinerU徹底解説：PDF・Office文書をLLM対応Markdown/JSONに変換するOSS

PDFをそのままLLMに渡すと、2段組が混線し、数式が消え、表が崩れ、スキャンPDFに至っては1文字も取れない——RAGやエージェントを作ったことがある人なら、必ず一度はこの「文書取り込みの壁」にぶつかります。MinerU（opendatalab/MinerU、GitHub約72,000★）は、まさにこの壁を壊すために作られたOSSです。PDF・画像・DOCX・PPTX・XLSXを、LLMが読めるMarkdown/JSONへ変換する「文書取り込み層」を一手に引き受けます。

この記事では、MinerUが①結局何ができるのか／②何を解決するのか／③何を代替できるのかの3点を軸に、レイアウト検出・数式LaTeX化・表HTML化・109言語OCRといった中核機能、素のPDF抽出との違い、インストールからCLI/Python APIまでを、公式READMEより一段深く・分かりやすく解説します。

MinerUとは何か：文書をLLM対応Markdownに変換する取り込み層

MinerUは公式に「PDF・画像・DOCX・PPTX・XLSXの入力を、検索・抽出・処理の下流工程向けに、MarkdownやJSONといった機械可読な形式へ変換する文書解析ツール」と定義されています。もともとは大規模言語モデルInternLMの事前学習プロセスの中で生まれ、科学文献における記号変換の問題を解決することに重点を置いて開発されました。つまりMinerUは、最初から「LLMに食わせるためのデータを作る」という目的で設計された文書パーサなのです。

ここで読者の最初の疑問「結局何ができるのか」に答えると、MinerUがやることは一言で言えば「人間にしか読めない見た目のドキュメント（PDFやスライド）を、機械とLLMが意味を保ったまま読める構造化テキストに翻訳する」ことです。生のPDFはレイアウト情報（どこが見出しで、どこが本文で、どこが脚注か）を視覚的なピクセル配置でしか持っていません。MinerUはこの視覚的構造を解析し、見出し・段落・リスト・表・数式・図といった論理構造へ復元します。

処理の流れをパイプラインとして見ると、入力ファイルを受け取り、まずレイアウト検出で段組や読み順を判定し、数式をLaTeX・表をHTMLとして抽出し、スキャン文書ならOCRを起動し、最終的にMarkdownとJSONを出力します。このパイプラインがあるからこそ、MinerUの出力はそのままRAGのチャンク分割やLLMのコンテキストに投入できる品質になります。

MinerUの主な特長を整理すると次の通りです。

・PDF・画像・DOCX・PPTX・XLSXの入力に対応
・ヘッダ・フッタ・脚注・ページ番号などを除去し、意味的な一貫性を確保
・単段組・多段組・複雑なレイアウトに対応し、人間が読む順序でテキストを出力
・見出し・段落・リストなど原文の構造を保持
・画像・画像の説明・表・表のタイトル・脚注を抽出
・文書中の数式を自動認識してLaTeX形式に変換
・文書中の表を自動認識してHTML形式に変換
・スキャンPDFや文字化けPDFを自動検出してOCRを有効化
・OCRは109言語の検出・認識に対応
・マルチモーダル／NLP向けMarkdown、読み順JSON、豊富な中間形式など複数の出力形式に対応
・レイアウト可視化・span可視化など、出力品質を効率的に確認できる可視化結果に対応
・CLI・FastAPI・Gradio WebUIを内蔵し、ローカルでのオーケストレーションやマルチサービス展開が可能
・純粋なCPU環境での実行に対応し、GPU/MPSアクセラレーションもサポート
・Windows・Linux・Macに対応

これらの機能はすべて公式READMEに明記された事実であり、架空の機能は含みません。MinerUの本質は、これらの個別機能が「LLM対応データを作る」という一つの目的に向かって統合されている点にあります。

素のPDFテキスト抽出との違い：MinerUが解決する課題

2つ目の読者の疑問「何を解決するのか」に答えるセクションです。多くの開発者は最初、RAGの文書取り込みをpypdfやpdfminerのような素のテキスト抽出ライブラリで済ませようとします。しかしこれらのライブラリは「PDFに埋め込まれた文字オブジェクトを座標順に拾う」だけなので、人間が見て当たり前に理解できる構造を一切復元できません。MinerUはこの「素のテキスト抽出の限界」をレイアウト解析で乗り越えます。

具体的に何が変わるのかを項目で見ていきます。

・読み順の保全：素の抽出では2段組の論文を上から座標順に拾ってしまい、左カラムと右カラムが1行ごとに交互に混ざって意味が崩壊します。MinerUは多段組レイアウトを検出し、人間が読む順序でテキストを直列化します。
・数式の保全：素の抽出では数式が文字化けして消えるか、意味不明な記号列になります。MinerUは数式を自動認識してLaTeXに変換するため、E = mc^2のような式も下流のLLMが解釈できる形で残ります。
・表の保全：素の抽出では表のセル構造が失われ、数字の羅列になります。MinerUは表をHTMLとして抽出するため、行・列・セルの対応関係が保たれます。
・ノイズ除去：素の抽出では全ページのヘッダ・フッタ・ページ番号・脚注がそのまま本文に混入し、チャンク化したときにノイズになります。MinerUはこれらを自動で除去し、意味的な一貫性を確保します。
・スキャンPDF対応：素の抽出はスキャンされた画像PDFから1文字も取れません。MinerUはスキャンPDFや文字化けPDFを自動検出してOCRを起動します。

この違いがRAGの精度に直結します。なぜなら、検索のヒット率も回答の正確さも、最終的には「LLMに渡したテキストがどれだけ原文の意味を保っているか」で決まるからです。読み順が崩れたチャンク、表が数字の羅列になったチャンク、ヘッダがノイズとして混入したチャンクは、ベクトル検索でも誤ヒットを誘発し、回答生成でもハルシネーションの種になります。MinerUはこの「取り込み層の品質」を底上げすることで、RAG全体の精度を引き上げます。

つまりMinerUが解決するのは、単なる「PDFからテキストを取る」という表層的な課題ではなく、「LLMに渡すデータの意味的忠実度をどう担保するか」という、RAG/エージェント開発の根幹にある課題なのです。

MinerUの主要機能：レイアウト検出・数式・表・OCR

ここではMinerUが文書から具体的に何を取り出せるのか、中核機能をより深く掘り下げます。読者の疑問「結局何ができるのか」への詳細な回答です。

レイアウト検出は、MinerUの心臓部です。文書のどこが見出しで、どこが本文で、どこが図や表かを判定し、単段組・多段組・複雑なレイアウトのいずれでも人間が読む順序を再現します。論文のように2段組で図表が散在するレイアウトでも、読み順を崩さずに直列化できるのは、このレイアウト検出があるからです。

数式のLaTeX変換は、科学文献を扱うRAGで決定的に重要です。MinerUはInternLMの事前学習で科学文献の記号変換問題を解くために生まれた経緯があり、文書中の数式を自動認識してLaTeX形式に変換します。これにより、数式を含む論文や技術文書でも、式の意味を保ったままLLMに渡せます。

表のHTML変換は、表構造を持つドキュメントの取り込みを大きく変えます。MinerUは表を自動認識してHTML形式に変換するため、行・列・セルの対応関係がそのまま保たれます。財務報告書や仕様書のように表が情報の主役になる文書で、これは素のテキスト抽出との決定的な差になります。

109言語OCRは、スキャンPDFや文字化けPDFへの対応力です。MinerUはこれらのPDFを自動検出してOCRを起動し、109言語の検出・認識に対応します。なお、READMEのChangelogによれば、pipelineバックエンドのOCRモデルはPP-OCRv6にアップグレードされ、OmniDocBench v1.6でOCR精度が約11%向上、OCR処理速度も約100%向上したとされています。スキャン中心の文書やOCRが多い文書のバッチ処理で効率が改善しています。

加えて、画像と画像説明・表タイトル・脚注の抽出、ヘッダ/フッタ/ページ番号の除去、レイアウト可視化・span可視化による出力品質の確認機能も備えています。主要機能を整理すると次の通りです。

・レイアウト検出：単段/多段/複雑なレイアウトで読み順を保持
・数式認識：文書中の数式をLaTeX形式へ自動変換
・表認識：文書中の表をHTML形式へ自動変換
・OCR：スキャン/文字化けPDFを自動検出し109言語で認識
・要素抽出：画像・画像説明・表タイトル・脚注を抽出
・ノイズ除去：ヘッダ・フッタ・ページ番号・脚注を除去し意味的一貫性を確保
・可視化：レイアウト可視化・span可視化で出力品質を確認

これらが一つのツールに統合されているため、従来は「PDFレイアウト解析ツール＋数式OCR＋表認識＋汎用OCR」と複数のライブラリを組み合わせていた工程を、MinerU単体で置き換えられます。これが「何を代替できるのか」への第一の答えです。

MinerUの対応形式とバックエンド：CPUからGPU/VLMまで

MinerUの実用性を左右するのが、対応する入力形式と、処理を担うバックエンドの選択肢です。ここを理解すると、自分の環境（CPUのみか、GPUがあるか）でどう使い分ければよいかが分かります。

入力形式はPDF・画像・DOCX・PPTX・XLSXの5種類で、単一ファイルでもディレクトリ単位でも処理できます。バックエンドは大きく次のように分かれます。

・pipeline：互換性が高く安定し、ハルシネーションがなく、CPUでもGPUでも動作する。最小VRAM4GBで、純粋なCPU環境でも実行可能。
・vlm-engine：高精度で、vLLM / LMDeploy / mlxといった推論エコシステムに対応する。GPUなどハードウェア要件は高め。
・hybrid：pipelineとVLMを組み合わせたバックエンドで、解析強度を指定するeffortパラメータ（medium/high）を持つ。デフォルトのmediumは日常的な文書処理に適し、highは最大精度や画像解析が必要な場面向け。

公式の対応表によれば、OmniDocBench（v1.6）のEnd-to-End評価スコアは、pipelineが約86.47、hybrid/vlmが約95（mediumで95.26、highで95.39、vlmで95.30）とされています。CPUだけでも実用的な精度が出せる一方、GPUがあればVLM系で大幅に精度を伸ばせる、という設計です。バックエンドの主な違いを表にまとめます。

RAMは最低16GB（推奨32GB以上）、ディスクは最低20GB（SSD推奨）が目安です。http-clientモードは、vLLM/SGLang/LMDeployなどで立てたOpenAI互換サーバに処理を委譲できるため、ローカルマシンのリソースが乏しくても高精度なVLMバックエンドを使えるのが利点です。さらにバージョン3.x系では、長文書のピークメモリを抑えるスライディングウィンドウ機構や、完了した解析結果を逐次ディスクへ書き出すストリーミング書き込みが追加され、数万ページ規模の文書を手動分割せずに扱えるよう改善されています。

このように、MinerUは「CPUしかない検証環境」から「GPUクラスタでの大規模バッチ処理」まで、同じツールで段階的にスケールできます。

MinerUのインストールと使い方：CLI・Python API・WebUI

3つ目の実践セクションです。MinerUの導入はpipまたはuvで完結します。ここでは導入からMarkdown出力までの最短経路と、CLI・Python API・WebUIの3つの使い方を示します。

まずインストールです。公式はuvの利用を推奨しています。mineru[all]はすべてのコア機能を含み、Windows / Linux / macOSに対応するため、ほとんどのユーザーにはこれで十分です。

# pip / uv でインストール
pip install --upgrade pip
pip install uv
uv pip install -U "mineru[all]"

ソースからインストールする場合は、リポジトリをクローンして編集可能モードで入れます。

# ソースコードからインストール
git clone https://github.com/opendatalab/MinerU.git
cd MinerU
uv pip install -e .[all]

次に、最も手軽なCLIでの文書解析です。-pで入力（ファイルまたはディレクトリ）、-oで出力先を指定します。GPUアクセラレーションの要件を満たす環境なら、これだけで解析が走ります。

# 基本：入力パスと出力パスを指定して解析
mineru -p <input_path> -o <output_path>

# GPU要件を満たさない場合は pipeline バックエンドで純CPU実行
mineru -p <input_path> -o <output_path> -b pipeline

mineruコマンドはローカルのPDF・画像・DOCX・PPTX・XLSXファイルまたはディレクトリを入力でき、CLI・API・WebUI・mineru-routerを通じて文書解析を実行できます。出力ディレクトリにはMarkdownとJSON、レイアウト可視化などが書き出されます。

Pythonコードから扱う場合は、内蔵のAPIクライアントを利用します。MinerUはバージョン3.x系でmineru-apiを基盤としたオーケストレーションクライアントとして動作し、--api-urlを渡さない場合はローカルの一時サービスを自動起動します。以下は公式デモ（demo/demo.py）に基づく、解析リクエストのフォームデータを組み立てる例です。

# MinerU の API クライアントで解析リクエストを構築する例（demo/demo.py より）
from mineru.cli import api_client as _api_client

form_data = _api_client.build_parse_request_form_data(
    lang_list=["japan"],          # 言語（109言語に対応）
    backend="pipeline",           # pipeline / hybrid / vlm から選択
    effort="medium",              # hybrid の解析強度（medium / high）
    parse_method="auto",          # 解析方法
    formula_enable=True,          # 数式を LaTeX 化
    table_enable=True,            # 表を HTML 化
    image_analysis=True,          # 画像解析
    start_page_id=0,
    end_page_id=None,
    return_md=True,               # Markdown を返す
    return_images=True,           # 画像も返す
    response_format_zip=True,     # 結果を ZIP で受け取る
)

さらにサーバとして運用するなら、mineru-apiが非同期タスク用エンドポイントPOST /tasks（タスク投入・状態照会・結果取得）と、互換性のための同期解析エンドポイントPOST /file_parseを提供します。複数サービス・複数GPUにまたがる統一入口とタスクルーティングにはmineru-routerを使い、自動的な負荷分散が可能です。手元で試すだけなら、ログイン式の公式Webアプリ（mineru.net）やGradioベースのオンラインデモから始めて、解析品質を確認してから本番のデプロイ方式を選ぶのが公式の推奨フローです。

導入・実行で詰まった場合は、まず公式FAQ（後述の参照ソース）を確認すると、多くの環境依存の問題はすでに解決策が用意されています。

MinerUのRAG/エージェント基盤での位置づけと代替対象

最後に、読者の3つ目の疑問「何を代替できるのか」に正面から答えます。MinerUを単体のツールとしてではなく、RAG/エージェント基盤の中の「層」として捉えると、その価値が明確になります。

RAGパイプラインは大まかに「①生ドキュメント → ②取り込み・構造化 → ③分割・埋め込み・ベクトルDB格納 → ④検索・LLM回答生成」という段階で構成されます。このうちMinerUが担うのは②取り込み・構造化の層です。ここで品質を落とすと、以降の埋め込みも検索も回答も、汚れたデータの上に積み上がってしまいます。MinerUはこの最上流の品質を引き上げる役割を持ちます。

具体的にMinerUが代替・統合できるのは、従来のRAG取り込みスタックで個別に必要だった次のような要素です。

・素のPDFテキスト抽出（pypdf / pdfminer など）：読み順保持とノイズ除去でMinerUが上位互換になる
・数式OCR / 数式認識ツール：数式のLaTeX変換を内蔵
・表構造認識ツール：表のHTML変換を内蔵
・汎用OCRエンジン：スキャンPDFの自動検出と109言語OCRを内蔵
・Office文書からテキストへの個別コンバータ：DOCX/PPTX/XLSXを直接入力可能
・レイアウト解析ツール：レイアウト検出と可視化を内蔵

つまりMinerUは、「複数の前処理ツールを継ぎ接ぎして作っていた文書取り込みパイプライン」を、一つのツールに置き換えられる可能性を持ちます。もちろん公式自身が「文書解析は難しく複雑なタスクであり、複雑なレイアウト・スキャンページ・手書き内容では結果が期待に届かないこともある」と明言しているため、商用クラウドサービスの完全な代替を保証するものではありません。しかし、自前でホストできるOSSとして、データを外部に出さずに高精度な取り込み層を構築できる点は、機密文書を扱う企業RAGにとって大きな価値です。

導入の判断材料としては、まず公式オンラインデモで自社の文書サンプルを解析し、品質を確認してから、CPU検証（pipeline）→GPU高精度化（hybrid/vlm）→サーバ展開（mineru-api / router）と段階的にスケールさせるのが現実的です。

まとめ

MinerUは、PDF・画像・DOCX・PPTX・XLSXをLLMが読めるMarkdown/JSONへ変換する、RAG/エージェント時代の「文書取り込み層」を担うOSSです。本記事の要点を整理します。

・結局何ができるか：レイアウト検出で読み順を保持し、数式をLaTeX・表をHTML化し、スキャンPDFを109言語OCRで処理して、構造化されたMarkdown/JSONを出力する
・何を解決するか：素のPDF抽出で起きる読み順崩壊・数式喪失・表崩れ・ノイズ混入を解消し、LLMに渡すデータの意味的忠実度を担保する
・何を代替できるか：素のテキスト抽出・数式OCR・表認識・汎用OCR・Officeコンバータ・レイアウト解析を一つに統合し、継ぎ接ぎの取り込みスタックを置き換えられる
・環境への適応力：pipelineでCPUでも動き、hybrid/vlmでGPU高精度化、http-client/routerでサーバ展開まで同じツールでスケールできる

文書取り込みの品質はRAG全体の精度の土台です。素のテキスト抽出で精度が頭打ちになっているなら、MinerUを取り込み層に据えるだけで、検索ヒット率と回答品質が変わる可能性があります。ライセンスは公式リポジトリ参照（Apache 2.0をベースに追加条項を加えた独自のMinerU Open Source License）のため、商用利用の可否は必ず最新のLICENSE.mdで確認してください。

よくある質問（FAQ）

Q1. MinerUとは何ですか？ PDF・画像・DOCX・PPTX・XLSXを、LLMが扱いやすいMarkdownやJSONへ変換するオープンソースの文書解析ツールです。レイアウト検出・数式や表の抽出・OCRを内蔵し、RAGやエージェントの文書取り込み層として使えます。

Q2. MinerUは素のPDFテキスト抽出と何が違いますか？ pypdfなどの素の抽出は読み順の崩壊・数式や表の喪失・ヘッダ混入が起きますが、MinerUはレイアウトを解析して読み順を保持し、数式をLaTeX・表をHTMLで保全し、ヘッダ/フッタ/ページ番号を自動除去します。RAGに渡すデータの意味的忠実度が大きく変わります。

Q3. MinerUはGPUがないと動きませんか？ いいえ。pipelineバックエンドを使えば純粋なCPU環境でも動作し、OmniDocBenchで約86.47の精度が出ます。最小VRAM4GBのGPUやApple Siliconがあればhybrid/vlmバックエンドで約95まで精度を上げられます。

Q4. MinerUのOCRは日本語に対応していますか？ OCRは109言語の検出・認識に対応しており、日本語を含むスキャンPDFや文字化けPDFを自動検出してOCRを起動します。言語はlang_listで指定できます。

Q5. MinerUはどんな出力形式に対応していますか？ LLM向けのMarkdown（マルチモーダル／NLP）、読み順でソートしたJSON、レイアウト可視化などの中間形式を出力できます。RAGのチャンク分割にそのまま渡せる構造化データが得られます。

Q6. MinerUのライセンスは何ですか？ ライセンスは公式リポジトリ参照（Apache 2.0をベースに追加条項を加えた独自のMinerU Open Source License）です。商用利用の可否やデータ利用の条件は、必ず最新のLICENSE.mdを確認してください。

参照ソース

・opendatalab/MinerU - GitHub（公式リポジトリ・README・LICENSE）
・MinerU Documentation（公式ドキュメント・使い方ガイド・FAQ）