--- title: "Marker（marker-pdf）の使い方｜PDFをMarkdownに変換する手順と商用ライセンス【2.0.0対応】" url: "https://www.issoh.co.jp/tech/details/12109/" published: 2026-05-14 updated: 2026-10-14 categories: ["LLM・RAG"] publisher: "株式会社一創" --- # Marker（marker-pdf）の使い方｜PDFをMarkdownに変換する手順と商用ライセンス【2.0.0対応】 Marker（PyPIのパッケージ名はmarker-pdf）は、米Datalabが開発するPDF→Markdown変換ツールです。`pip install marker-pdf`で入れ、`marker_single 入力.pdf`の1行で見出し・表・数式を残したMarkdownが出ます。2026年7月20日の2.0.0で内部構成・動作モード・ライセンス・ベンチマークがまとめて変わったため、1.x時代の解説記事は手順も商用条件も現状と合いません。この記事は2.0.0を基準に、導入の落とし穴と、CPUだけの環境で日本語PDFを変換した結果まで扱います。 ## まとめ - 最新版は2.0.0（2026年7月20日）。Python 3.10以上とPyTorch 2.7以上が必要。 - 2.0.0から変換モードが3つになった。GPU向けの`balanced`、CPU向けの`fast`、VLMを一切使わない`--disable_ocr`。既定はGPUならbalanced、CPU・Apple Siliconならfast。 - OCRと数式認識はsuryaのVLMをローカルの推論サーバーで動かす。NVIDIA GPUならvLLM（Docker）、CPUとApple Siliconならllama.cppの`llama-server`が要る。 - Intel Macでは`pip install marker-pdf`が2024年の0.2.6を黙って入れる。PyTorch 2.7以降にIntel Mac用のwheelが無いため。 - GPUの無い4 vCPUの検証環境で処理時間を抑えられたのは`--disable_ocr`。53ページの日本語PDFを24秒で変換できたが、テキスト層から組み立てられない表は本文から抜ける。 - コードはApache-2.0、モデル重みは改変版OpenRAIL-M。前年の総収入か累計調達額が500万ドルを超える企業の業務利用と、Datalabと競合する事業者の利用には有償ライセンスが要る。 ## Marker 2.0.0の変更点｜3つの変換モードとsurya VLM ### 1.10.2から変わった4点 [2.0.0のリリースノート](https://github.com/datalab-to/marker/releases/tag/v2.0.0)は、速度・CPU対応・精度を目的とした書き直しだと説明しています。1.x系（最終は2026年1月31日の1.10.2）から使い方に効く変更は次の4つです。 - **ライセンス**：コードがGPL-3.0からApache-2.0へ。重みの無償利用の上限は200万ドルから500万ドルへ（後述）。 - **モード**：`--mode balanced|fast`が追加され、既定値が実行デバイスで変わるようになった。 - **推論の仕組み**：レイアウト・OCR・表認識を1つのsurya VLM（約6億5,000万パラメータ）に集約し、ローカルの推論サーバー経由で呼ぶ方式になった。 - **削除**：構造化抽出用のコンバーター（1.xの抽出機能）が無くなった。リリースノートはDatalabのAPIか`--use_llm`を使う方法を案内しています。 コマンドは[pyproject.toml](https://github.com/datalab-to/marker/blob/master/pyproject.toml)に登録された4本（`marker`・`marker_single`・`marker_gui`・`marker_server`）です。GitHubのリポジトリは旧名のVikParuchuri/markerから[datalab-to/marker](https://github.com/datalab-to/marker)へ移っています。 ### balanced・fast・–disable\_ocrの処理の違い | モード | レイアウト判定 | VLMを呼ぶ場面 | 想定環境 | | ------------- | ----------------------- | --------------------- | ----------------- | | balanced | surya VLM | 文字化けがあるページを丸ごと再OCR・数式 | GPU | | fast | 軽量なrf-detr（2,000万パラメータ） | スキャンページ・化けたブロック・数式だけ | CPU・Apple Silicon | | –disable\_ocr | 軽量なrf-detr | 呼ばない | CPUのみ | どのモードも、まずPDFに埋め込まれたテキスト層をpdftextで読みます。[README](https://github.com/datalab-to/marker#usage)によると、fastは「数式のない綺麗なデジタル文書ならVLMサーバーを起動しない」設計です。表もテキスト層から組み立て、自信の低いものだけVLMに回します。`--disable_ocr`はこの最後の段も含めてVLMを止めるため、数式とスキャンページは出力されません。 ## marker-pdfのインストール｜動作要件とIntel Macの落とし穴 ### Python 3.10以上とPyTorch 2.7以上 ``` pip install marker-pdf # PDFと画像 pip install "marker-pdf[full]" # DOCX・PPTX・XLSX・EPUB・HTMLも扱う場合 ``` [PyPIの2.0.0](https://pypi.org/project/marker-pdf/)はPython 3.10以上4未満を要求し、`torch>=2.7.0`と`surya-ocr>=0.22.1,<0.23.0`に依存します。PyTorchは先に[公式の手順](https://pytorch.org/get-started/locally/)でCUDA版かCPU版を選んで入れておくと、不要なGPU用ライブラリを引き込みません。 CPU版のPyTorchを専用インデックスから入れた場合は、torchvisionも同じインデックスから入れてください。torchだけCPU版にしてtorchvisionをPyPIから入れた環境では、変換の途中で`RuntimeError: operator torchvision::nms does not exist`が出て止まりました（torch 2.14.1+cpuとPyPIのtorchvision 0.29.1の組み合わせ）。 ``` pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu pip install marker-pdf ``` ### Intel Mac・Python 3.12での0.2.6への依存解決 PyPIで配布されているPyTorchのmacOS用wheelは、2.7.0以降がApple Silicon（arm64）だけです。Intel Mac（x86\_64）でmarker-pdfを入れると、pipもuvもエラーを出さずに、PyTorch 2.2.2で動く古い版まで遡って解決します。Intel Core i9-9880HのMacとPython 3.12で確かめた結果は次のとおりです。 ``` $ pip install --dry-run marker-pdf → marker-pdf 0.2.6 / surya-ocr 0.4.5 / torch 2.2.2 が選ばれる $ pip install --dry-run "marker-pdf==2.0.0" → torch>=2.7.0 has no wheels with a matching platform tag … unsatisfiable ``` 0.2.6は2024年5月の版で、`marker_single`の引数（出力先を位置引数で渡す・`--langs`で言語を指定する）も2.0.0と違います。古い解説の手順が「動いてしまう」ので気付きにくい点が厄介です。導入後は`pip show marker-pdf`で版を確かめ、Intel MacならLinuxのDockerコンテナか、GPUのあるLinuxマシンで動かすのが確実です。 ### VLMを使うための推論サーバー OCRと数式認識を使うには、suryaのVLMを動かす推論サーバーが別に要ります。[suryaのREADME](https://github.com/datalab-to/surya)の指定は、NVIDIA GPUならDockerとNVIDIA Container Toolkit（vLLMのコンテナを自動起動）、CPUとApple Siliconならllama.cppの`llama-server`です。初回の利用時に自動で起動し、macOSなら`brew install llama.cpp`で入ります。 サーバーが無い環境では、fastモードでもVLMが必要なページに来た時点で`SpawnError: llama-server binary not found`で止まり、それまでの変換結果も保存されません。後述の日本語PDFはテキスト層のあるデジタルPDFでしたが、fastモードはVLMを呼びに行きました。初回はVLMの重み（GGUF形式で本体1.27GBと画像用0.2GB）のダウンロードも走ります。 ## marker\_singleとPython APIによるPDF→Markdown変換 ### marker\_singleの主要オプション ``` marker_single 入力.pdf --output_dir out marker_single 入力.pdf --output_dir out --disable_ocr --page_range "0,5-10" marker_single 入力.pdf --output_dir out --output_format json ``` | オプション | 役割 | | --------------------------- | ------------------------- | | –mode balanced\|fast | 変換モード。省略時は実行デバイスで決まる | | –disable\_ocr | VLMを使わずテキスト層だけで変換 | | –page\_range | 0始まりのページ指定（例 “0,5-10″） | | –output\_format | markdown・json・html・chunks | | –force\_ocr | テキスト層があっても全ページをOCR | | –disable\_image\_extraction | 画像を書き出さない | | –use\_llm | 外部LLMで表や数式を補正 | 出力先には`ファイル名.md`と`ファイル名_meta.json`、抽出した画像（`_page_0_Picture_1.jpeg`のような名前）が並びます。ページのヘッダーとフッターは既定で除かれ、ヘッダーを残すには`--keep_pageheader_in_output`、フッターを残すには`--keep_pagefooter_in_output`を付けます。`chunks`形式はページ直下のブロックを平らなリストにしたもので、RAGに取り込むときの分割単位にそのまま使えます。 フォルダ単位の一括変換は`marker 入力フォルダ --output_dir out`です。複数のワーカーが1つの推論サーバーを共有し、`--skip_existing`で変換済みを飛ばして再開できます。 ### Python APIのPdfConverter ``` from marker.converters.pdf import PdfConverter from marker.models import create_model_dict from marker.output import text_from_rendered converter = PdfConverter(artifact_dict=create_model_dict()) rendered = converter("入力.pdf") text, _, images = text_from_rendered(rendered) ``` モードやページ範囲を指定するときは`ConfigParser`に辞書で渡し、`config=config_parser.generate_config_dict()`を`PdfConverter`に与えます。表だけを抜き出す`TableConverter`、OCRだけを行う`OCRConverter`も同じ書き方で使えます。`pip install -U uvicorn fastapi python-multipart`で追加依存を入れてから、`marker_server --port 8001`で起動するHTTPサーバーもありますが、受け付けるのは`page_range`・`mode`・`force_ocr`・`paginate_output`・`output_format`だけで、`--use_llm`と`--disable_ocr`は使えません。 ### –use\_llmによる補正内容とLLMの接続先 `--use_llm`を付けると、ページをまたぐ表の結合、インライン数式、フォームの値の抽出をLLMで補正します。既定の接続先はGeminiの`gemini-3.5-flash`で、Claude・OpenAI互換・Azure OpenAI・Vertex・OpenRouter・Ollamaに切り替えられます。社内で動かすOllamaやOpenAI互換サーバー以外を選ぶと文書の内容が外部APIに送られるので、社外秘の文書では接続先を社内の規程と照らしてから使ってください。 ## CPUだけの環境で日本語PDFを変換した結果 GPUの無い環境で2.0.0がどこまで使えるかを確かめるため、内閣府の[事業継続ガイドライン（令和5年3月）](https://www.bousai.go.jp/kyoiku/kigyou/pdf/guideline202303.pdf)（53ページ・テキスト層ありのデジタルPDF・表13個）を変換しました。環境はIntel Mac上のDocker（Linux x86\_64・4 vCPU・メモリ5.8GB）、Python 3.12、torch 2.14.1+cpu、marker-pdf 2.0.0です。 | 条件 | 結果 | 所要時間 | | -------------------------- | -------------------- | ---------------------- | | –disable\_ocr（53ページ） | 成功・Markdown 67,330文字 | 33秒（CLI全体）・24.0秒（変換ログ） | | fast・llama-serverなし | SpawnErrorで停止・出力なし | 49秒で停止 | | fast・llama-serverあり（10ページ） | VLMの生成速度1.56トークン/秒 | 最初のVLM呼び出し1件で約10分 | ### –disable\_ocrでの表・和文空白・見出し階層の崩れ 本文の文字や目次・章見出し・脚注番号は取り出せました。ただし、表の欠落とセルの分割、和文中の空白、見出し階層の不整合が見られました。 - **表が抜ける**：13個の表のうちテキスト層から組み立てられたのは6個（ログの`tables_pdftext: 6, tables_total: 13`）。残りは本来VLMに回る表で、`--disable_ocr`ではそのまま捨てられます。「表1.2-1 企業における従来の防災活動とBCMの比較表」は表題だけが残り、中身の6行が丸ごと消えました。ソースの`marker/processors/table.py`も、`disable_ocr`のときはOCRへのフォールバックを呼ばない作りです。 - **結合セルのある表が崩れる**：「策定時期」の列が「平成」「17 年」「8」「月」と別々の行に分かれました。 - **改行位置に半角空白が入る**：PDFの行末だった位置が「強 い地震動」「影 響」のように空白になり、和文の途中に650か所入りました。RAGに入れる前に、和文どうしに挟まれた空白を消す後処理を足すと検索の取りこぼしが減ります。 見出しの階層も揃いません。「1.2」がh2、「1.3」がh4になるなど、文字の大きさの違いをそのまま階層にしています。目次から章立てを取る用途では、見出しの番号から階層を振り直すほうが確実です。 ### 4 vCPU環境でのVLM生成速度と大量処理の限界 llama-server（llama.cpp b11598のLinux x86\_64版）を入れてfastモードで10ページを変換すると、VLMの生成速度は1.56トークン/秒にとどまり、最初の呼び出し1件（772トークンの生成）だけで約10分かかりました。2件目に進んだ時点で計測を打ち切っています。suryaのREADMEは1ページの全文OCRを平均約2,400トークンとしているので、スキャンページ1枚に25分前後かかる計算です。同じREADMEのApple Silicon（Metal）の公表値は、8並列で0.108ページ/秒、1ページの応答時間の中央値が約59秒です。GPUを使うMetalの値なので、今回のCPU実測とは条件が異なります。 今回と同程度のCPU環境で処理時間を優先するなら、テキスト層のあるPDFを`--disable_ocr`で使い、表が欠けていないかを確かめる運用が現実的です。スキャンPDFや表の多いPDFを大量に処理するなら、NVIDIA GPUのLinuxマシンでbalancedを使うか、DatalabのホストAPI（変換は1,000ページあたり4ドル）に回すほうが早く済みます。日本語のスキャンPDFだけをOCRしたい場合は、[Tesseract OCRの使い方｜インストール・日本語設定・コマンドとPython/C#連携【5.5.3対応】](/tech/details/8204/)も比較の候補になります。 ## ベンチマークの読み方｜olmOCR-bench 76.0%とB200のスループット 2.0.0のREADMEは、Ai2が公開するolmOCR-bench（1,403個のPDF・約8,400件の合否テスト）の8分類の平均で精度を示しています。数値はDatalab自身が計測したものです。 | システム | 総合 | デジタルのみ | スループット | | ---------------------- | ---- | ------ | --------- | | Marker balanced（GPU） | 76.0 | 83.5 | 2.9ページ/秒 | | MinerU pipeline（GPU） | 72.7 | 83.3 | 0.54ページ/秒 | | Marker fast（GPU） | 66.6 | 71.6 | 7.4ページ/秒 | | docling（GPU） | 50.3 | 64.0 | 2.1ページ/秒 | | Marker fast・OCRなし（CPU） | 43.6 | 55.8 | 23.7ページ/秒 | 読むときの注意は3つあります。スループットはNVIDIA B200を1基使い、多数のワーカーを同時に走らせた持続値で、1本だけ流したときのbalancedは約0.3ページ/秒とREADME自身が書いています。比較相手のMinerUはpipelineバックエンドの値で、READMEはMinerUのVLMバックエンドの方が高得点だと認めています。分類別では、fastは数式（arXiv math）が23.4点まで下がり、OCRなしは数式とスキャン数式が0点です。数式の多い論文を変換するならbalancedを選んでください。 1.x時代の記事に出てくる「25ページ/秒」「122ページ/秒」はH100での推定値で、2.0.0のREADMEからは消えています。 ## 商用利用の条件｜コードApache-2.0とモデル重みの500万ドル基準 ### 重みのライセンスにある3つの制限 コードはApache-2.0で、業務でも自由に使えます。制限があるのはモデル重みです。重みには改変版のAI Pubs Open RAIL-Mが付き、[MODEL\_LICENSE](https://github.com/datalab-to/marker/blob/master/MODEL%5FLICENSE)の別紙A（Attachment A）が次の利用を禁じています。 - (a) 利用者（雇用主・所属する組織を含む）の前年の総収入が500万ドルを超える場合 - (b) 利用者（同上）の株式・借入による累計調達額が500万ドルを超える場合 - (c) 利用者（同上）がDatalabやその関連会社の製品・サービスと競合する製品・サービスを提供している場合 (a)と(b)は個人利用と研究目的に限れば適用されません。(c)にはその例外がありません。また、ここでいう「利用」には、モデルが出力した結果の利用も含まれます。[Datalabの料金ページ](https://www.datalab.to/pricing)も「収入と調達額の両方が基準を下回れば商用でも無料、どちらかを超えれば商用ライセンスが必要」としており、基準はMarkerとsuryaが500万ドル、上位モデルのChandraが200万ドルです。 ### 商用ライセンス判定の対象組織・使用モデル・競合条項 - **会社の規模で決まる**：社員が業務で使う場合、判定の対象は個人ではなく雇用主です。年商が約7億5,000万円（1ドル150円換算）を超える会社なら、社内ツールでの利用でも有償ライセンスの対象です。 - **–disable\_ocrでも重みは使う**：OCRなしでも、レイアウト判定にHugging Faceの`datalab-to/surya_layout2`の重みをダウンロードして使います（実測でキャッシュに保存されました）。このモデルのライセンス表記もOpenRAILで、「OCRを切れば重みのライセンスと無関係」にはなりません。 - **文書処理SaaSは規模に関係なく対象**：OCRや文書変換のサービスを提供する会社は、(c)の競合条項で、収入が500万ドル未満でも無償では使えません。 基準を超える場合の選択肢は、Datalabの有償ライセンス（オンプレミス向け・価格は営業との個別見積もり）、ホストAPI、または他のツールへの切り替えです。社内規程との照合は法務部門と行ってください。 ## MinerU・Docling・MarkItDown・PyMuPDF4LLMとの使い分け | ツール | 最新版（PyPI） | ライセンス | GPU | | ----------- | ------------------- | ---------------- | --------- | | Marker | 2.0.0（2026-07-20） | Apache-2.0＋重みに制限 | OCRには実質必要 | | Docling | 2.138.0（2026-10-12） | MIT | 任意 | | MinerU | 4.0.12（2026-10-11） | MinerU独自ライセンス | 推奨 | | MarkItDown | 0.1.8（2026-09-21） | MIT | 不要 | | PyMuPDF4LLM | 1.28.2（2026-08-06） | AGPL-3.0か商用 | 不要 | 選び方は、ライセンスの制約と手元の計算資源で先に絞り込めます。 - **年商500万ドル超の会社で、有償契約を結ばない**：Markerの重みは使えません。コードがMITのDoclingが第一候補です。ただし、使用モデルのライセンスも個別に確認してください。導入と採用判断は[Doclingとは？PDFをMarkdown化してRAGに載せる実装手順と採用判断](/tech/details/17736/)にまとめています。 - **GPUがあり、数式や表の多い文書を大量に処理する**：Markerのbalancedか、[MinerUとは？PDFをMarkdownに変換するOSS文書解析ツールの使い方](/tech/details/6505/)。MinerUのライセンスは独自のものなので、条文を確認してから採用してください。 - **GPUが無く、テキスト層のあるPDFが中心**：[PyMuPDF4LLMの使い方｜PDFをMarkdownに変換する手順と日本語PDFの注意点【1.28.2】](/tech/details/2325/)はCPUだけで表をMarkdownにできます。AGPLの扱いは[PyMuPDF（fitz）とは｜インストールから使い方・ライセンスまで解説【2026年版】](/tech/details/4017/)を参照してください。 - **Word・Excel・PowerPointも含めて手早く変換したい**：[MarkItDown（マークイットダウン）とは｜各種ファイルをMarkdownに変換するMicrosoft製Pythonツール](/tech/details/4810/)。複数形式を共通のAPIやCLIでMarkdownに変換したい場合の候補です。 日本語の精度については、suryaが91言語の社内ベンチマークで日本語86.2%と公表しています。ただしこの値だけでは縦書き文書での精度を判断できず、MarkerとsuryaのREADMEにも縦書きへの言及はありません。縦書きの多い資料は、候補のツールに同じPDFを通して出力を見比べてから決めてください。社内文書を検索や生成AIに使えるデータへ整える工程を含めて相談したい場合は、[RAG構築支援](/service/ai/rag/)でも承っています。 ## よくある質問 ### marker-pdfは pip install marker-pdf だけで使えますか？ テキスト層のあるPDFを`--disable_ocr`で変換するだけならpipだけで動きます。OCRや数式認識を使うには、NVIDIA GPUならvLLMのDockerコンテナ、CPUとApple Siliconならllama.cppの`llama-server`が別に必要です。Intel Macでは0.2.6が入るので、`pip show marker-pdf`で版を確認してください。 ### Markerは日本語のPDFに対応していますか？ 対応しています。OCRを担うsuryaは日本語で86.2%（91言語の社内ベンチマーク）と公表しています。テキスト層のある日本語PDFは`--disable_ocr`でも本文を取り出せますが、改行位置に半角空白が入り、組み立てられない表は抜けます。縦書きへの対応はMarkerとsuryaのREADMEに記載がありません。 ### marker\_singleで特定のページだけ変換できますか？ `--page_range "0,5-10"`のように指定します。ページ番号は0始まりで、カンマ区切りと範囲指定を組み合わせられます。 ### Markerの最新版で「v2」は出ていますか？ 出ています。2026年7月20日に2.0.0が公開され、変換モードの追加、コードのApache-2.0化、重みの無償利用の基準の500万ドルへの引き上げが行われました。2026年10月14日時点の最新版も2.0.0です。 ### MarkerとDoclingはどちらを選ぶべきですか？ 年商または累計調達額が500万ドルを超える会社で有償ライセンスを結ばないならDoclingです。制限に当たらず、GPUがあって数式や表の精度を重視するなら、Datalabの公表値ではMarkerのbalancedが上回っています（olmOCR-bench総合76.0対50.3）。ただしDatalab自身の計測なので、自社のPDFで両方を試してから決めてください。 ## 関連記事 - [PyMuPDF4LLMの使い方｜PDFをMarkdownに変換する手順と日本語PDFの注意点【1.28.2】](/tech/details/2325/) - [Doclingとは？PDFをMarkdown化してRAGに載せる実装手順と採用判断](/tech/details/17736/) - [MinerUとは？PDFをMarkdownに変換するOSS文書解析ツールの使い方](/tech/details/6505/) - [MarkItDown（マークイットダウン）とは｜各種ファイルをMarkdownに変換するMicrosoft製Pythonツール](/tech/details/4810/) - [OCRとは？光学文字認識の仕組み・種類・精度と実装での組み込み方を解説](/tech/details/13582/) --- 出典: [Marker（marker-pdf）の使い方｜PDFをMarkdownに変換する手順と商用ライセンス【2.0.0対応】]()（株式会社一創）