Marker（marker-pdf）の使い方｜PDFをMarkdown変換する手順と商用ライセンス制約

Marker は PDF・画像・Office 文書を Markdown へ変換する Python 製 OSS で、PyPI では marker-pdf の名前で配布されています。RAG の前処理や LLM 学習データ整備で採用例が増えた一方、コードと機械学習モデルで別々のライセンスが適用され、年商または累計調達総額が 200 万ドルを超える企業は無償では使えないという制約が見落とされがちです。ここでは 2026 年 7 月時点の最新版 1.10.2 を基準に、導入から実行、ベンチマークの読み方、商用可否の判定までを一次情報だけで整理します。

まとめ

Marker の要点は次のとおりです。最新版は 2026 年 1 月 31 日公開の 1.10.2 で、よく検索される「v2」は存在しません。レイアウト検出から OCR、表構造認識まで実際の推論は依存ライブラリ Surya が担っており、Marker 本体はその結果を Markdown・JSON・HTML・chunks に組み立てるパイプラインです。

導入は pip install marker-pdf と marker_single ファイル名 の 2 行で動きますが、PDF 以外の入力を扱うなら marker-pdf[full] が必要です。Python は 3.10 以上、torch は 2.7 系、GPU 利用時の VRAM はワーカーあたりピーク約 5GB を見込みます。

そして最大の判断ポイントが二重ライセンスです。コードは GPL-3.0、モデル重みは修正版 AI Pubs Open RAIL-M で、前年度の総収益または累計調達総額が 200 万ドルを超える事業体は個人利用・研究を除いて利用できません。金額条件を満たしていても、Datalab と競合するサービスを提供する事業者は対象外です。企業導入では、この条項を確認してから精度検証に進むのが順序として正しい判断になります。

Marker（marker-pdf）の現在地｜最新1.10.2とSurya依存の実体

「v2」は存在しない｜1.10.2（2026年1月31日）までのリリース系譜

PyPI の marker-pdf における最新リリースは 1.10.2（2026 年 1 月 31 日）です。GitHub リポジトリは datalab-to/marker（旧 vikparuchuri/marker）で、開発元は Datalab です。検索では「marker v2」を探す動きが見られますが、メジャーバージョン 2 系は公開されていません。

直近の変更は挙動に直結します。1.8.3 で数式に強い OCR モデルへ差し替えられて format_lines が廃止され、1.9.0 で OCR がブロック単位推論へ移行、1.10.0 で Surya ベースのレイアウトモデルが刷新され --html_tables_in_markdown が追加されました。一方で 1.10.1（2025 年 9 月 30 日）から 1.10.2 までは 4 か月空いています。アーカイブや非推奨は宣言されていないものの、機能追加のペースが落ちている事実は、長期運用の前提として押さえておくべきです。

レイアウト・OCR・表認識をすべてSuryaが担う内部構成

Marker の初期化処理 create_model_dict() が返すのは、Surya の LayoutPredictor（レイアウト検出）、DetectionPredictor（テキスト検出）、RecognitionPredictor（文字認識）、TableRecPredictor（表の行・列・セル認識）、OCRErrorPredictor（OCR の要否判定）という 5 つの Predictor です（レイアウトと認識は内部で FoundationPredictor を共有します）。Marker は OCR エンジンそのものではなく、認識処理を Surya に委譲したうえで結果を文書構造へ組み立てるパイプラインである、というのが実体です。Surya は 650M パラメータのモデル群で、olmOCR-bench で 83.3% を記録しています。

Marker 本体の役割は Providers（入力からの抽出）、Builders（ブロック生成）、Processors（ブロック種別ごとの整形）、Renderers（出力）という 4 層の組み立てにあります。埋め込みテキストを持つ電子 PDF では OCR を呼ばずに済ませるなど、必要な箇所にだけモデルを使う設計が処理速度を支えています。--use_llm を付けると Gemini（既定 gemini-2.0-flash）や Claude、OpenAI、Ollama などを補助的に併用でき、表や数式の精度が上がります。

marker-pdfのインストールと動作要件｜Python 3.10以上・torch 2.7・VRAM 5GB

要件は pyproject.toml に明記されています。Python は 3.10 以上 4.0 未満、torch は 2.7 系、transformers は 4.45.2 以上です。torch は事前にローカル環境へ入れておく必要があり、GPU を使う場合は CUDA 版ホイールを自分で選ぶことになります。実行は GPU・CPU・Apple Silicon の MPS のいずれでも可能ですが、CPU 実行はページあたりの処理時間が大きく伸びるため、大量バッチなら GPU 前提で構成します。GPU 利用時の VRAM は README 実測でワーカーあたりピーク約 5GB、平均 3.5GB です。

pip install marker-pdf
# PDF以外（PPTX・DOCX・XLSX・HTML・EPUB）も扱う場合
pip install marker-pdf[full]

素の marker-pdf が対応するのは PDF と画像だけです。[full] を付けると mammoth・openpyxl・python-pptx・ebooklib・weasyprint が追加され、Office 文書と EPUB、HTML が入力に加わります。出力形式は markdown（既定）・json・html・chunks の 4 種類で、chunks は RAG のチャンク分割をそのまま受け取れるフラットな構造です。RRF（Reciprocal Rank Fusion）とは？RAG-Fusionでの仕組み・スコア計算・実装を解説で扱ったような検索側の設計と合わせるなら、最初から chunks で出しておくと後段が楽になります。

marker_single・Python APIによる変換の実行手順

CLI 6コマンドの使い分け

pyproject の [project.scripts] に登録されている実行コマンドは 6 本です。単一ファイルなら marker_single、フォルダ一括なら marker、複数 GPU で分散するなら marker_chunk_convert、動作確認や非エンジニアへの提供には Streamlit 製の marker_gui、社内サービスへ組み込むなら REST を立てる marker_server、フォームなど構造化抽出用途には marker_extract を使います。

marker_single sample.pdf --output_format markdown --output_dir out
marker input_dir --output_dir out --workers 4
NUM_DEVICES=4 NUM_WORKERS=15 marker_chunk_convert ../pdf_in ../md_out
marker_server --port 8001   # http://localhost:8001/docs にAPIドキュメント

marker_server を立てれば FastAPI の /docs から仕様を確認でき、既存の社内システムから HTTP で呼び出せます。呼び出す側に Python 環境も GPU も要らないため、サーバ 1 台に集約して各部署へ提供する構成が取れます。

出力形式とページ範囲を制御する主要オプション

変換結果に直接効くフラグは 5 つです。--output_format で markdown・json・html・chunks を切り替え、--page_range で 0,5-10,20 のように処理対象ページを限定し、--use_llm で LLM 併用の精度補正を有効化し、--force_ocr で埋め込みテキストを無視して強制 OCR、--strip_existing_ocr で既存の OCR レイヤーを捨ててから読み直します。

スキャン PDF に他社ツールが埋めた低品質な OCR テキストが残っている場合、Marker はそれを信用してしまい変換結果が崩れます。README が --strip_existing_ocr と --force_ocr を用意しているのはこの用途で、変換結果が原文と食い違うときの最初の切り分けに使います。数百ページの資料で精度を確かめたいときは、まず --page_range で数ページに絞り、--use_llm の有無で結果を比べてから全体を回すとムダな GPU 時間を使わずに済みます。

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("sample.pdf")
text, _, images = text_from_rendered(rendered)

create_model_dict() はモデル一式をメモリへ載せる処理なので、バッチ処理ではプロセス起動ごとに呼ばず、一度読み込んだ converter を使い回します。CLI 側の実装では ConfigParser が generate_config_dict() や get_processors()、get_llm_service() を提供しており、CLI と同じ設定を Python から再現したいときはこのクラスを経由します。

公表ベンチマークの読み方｜H100の「投影値」と実測値の区別

総合変換の比較対象はDocling・Mathpix・Llamaparse

Marker の README が載せる H100 環境のベンチマークは次のとおりです。数値は 1 文書あたりの処理時間と、ヒューリスティック評価、LLM による採点です。

比較対象に MinerU・Nougat・MarkItDown は含まれていません。「Marker は MinerU より速い」といった記述を見かけたら、それは Marker 公式の測定結果ではないと考えて出典を確認してください。

表抽出はFinTabNet 0.816、use_llm併用で0.907

表の再現精度は FinTabNet で Marker 単体 0.816、--use_llm 併用で 0.907、Gemini 単体では 0.829 という結果です。請求書や財務資料のように表が主役の文書では、単体運用と LLM 併用で 1 割近い差が出ます。LLM を呼べば API コストと処理時間が乗るため、表の重要度が低い議事録や仕様書は単体、金額欄がある帳票は併用、という切り分けが費用対効果に合います。

「122ページ/秒」は投影値であり実測値ではない

スループットの数字は性質が分かれます。1 ページ 0.18 秒（1 プロセスあたり VRAM 3.17GB）は H100 での実測値ですが、単一プロセスをバッチモードで回した場合の 25 ページ/秒と、22 プロセスを並列実行した場合の 122 ページ/秒は、いずれも README が projected（投影値）と断っている推定値です。「122 ページ/秒出る」という前提でキャパシティを見積もると、算定が崩れます。

実際の処理速度は PDF がスキャンか電子かで大きく変わり、OCR が走るスキャン文書では桁が変わります。並列度にも上限があり、ワーカーあたり VRAM ピーク 5GB から概算すると、24GB の GPU で同時に動かせるのは 4 ワーカー前後という計算になります。導入判断の前に、自社の実文書を 10 ページほど流して実測してください。

商用利用の可否判定｜GPL-3.0とOpen RAIL-Mの二重制約と200万ドル基準

marker 200万ドル・Surya 500万ドルという閾値の非対称

Marker のライセンスは 2 層構造です。コードは GPL-3.0-or-later、モデル重みはリポジトリ直下の MODEL_LICENSE に置かれた修正版 AI Pubs Open RAIL-M で、前年度の総収益が 200 万米ドル超、または調達済みのエクイティ・デットの総額が 200 万米ドル超の事業体は、個人利用と研究を除いて利用できません。

ここで見落とされやすいのが、依存ライブラリ Surya との条件の食い違いです。Surya はコードが Apache-2.0 で、モデル重みだけが修正版 Open RAIL-M、その閾値は 500 万ドルと定められています。Marker の 200 万ドルとは非対称であり、Marker を使う以上は厳しい方の 200 万ドル基準が効きます。「Surya は 500 万ドルまで無料だから大丈夫」という読み替えは成立しません。

金額基準を満たしてもDatalab競合事業者は利用不可

MODEL_LICENSE には金額条項とは別に、ライセンサー（Datalab）の製品・サービスと競合する製品やサービスを提供する主体は利用できないという条項があります。売上 200 万ドル未満のスタートアップであっても、文書変換 API や OCR SaaS を自社プロダクトとして提供するなら、この条項に抵触します。金額だけを見て「うちは無料枠だ」と判断すると、事業内容の側で外れます。

判定フローとDatalabの商用ライセンス・API

企業での判定は次の順で行うのが安全です。(1) 自社が OCR・文書変換サービスを提供していないか。提供しているなら金額を問わず不可。(2) 前年度収益と累計調達額がともに 200 万ドル未満か。超えているなら不可。(3) GPL-3.0 のコピーレフトを受け入れられるか。自社の非公開製品へ組み込むなら、GPL 要件を外すために Datalab の商用ライセンスが必要です。

いずれかで外れる場合の選択肢は、Datalab のマネージド API・オンプレ提供を契約するか、ライセンスが緩い他 OSS へ移ることです。Tesseractとは？読み方・精度・商用利用とPSM/OEM設定を実務目線で解説で整理した Apache 2.0 の Tesseract のように、商用制限のない選択肢と比較したうえで、精度差がコストに見合うかを判断してください。

MinerU・Docling・MarkItDown・Nougatとの使い分け（2026年7月時点）

ライセンスとメンテナンス状況の比較

MinerU はバージョン 3.1.0 で AGPLv3 から独自の「MinerU Open Source License」へ変更されており、AGPL 前提で検討した過去の記事は現状に合いません。pipeline・vlm-engine・hybrid-engine の 3 バックエンドを持ち、OmniDocBench v1.6 で hybrid が 95.39 を記録します。必要 VRAM は hybrid・vlm エンジンで 8GB、CPU でも動く pipeline なら 4GB です。Docling は IBM Research 発で現在は LF AI & Data Foundation がホストし、MIT かつ更新が活発で、商用制限を避けたい企業の第一候補になります。MarkItDown は高精度 OCR を狙う道具ではなく、インデックス用にテキストを取り出す軽量ツールと割り切るべきです。Nougat は最終コミットが 2025 年 2 月で止まっており、新規採用は勧められません。

日本語PDF｜Suryaの日本語86.2%と縦書きの未確認領域

Marker の README は「全言語で動作する」と書いたうえで、OCR を担う Surya の対応言語リストを参照させ、埋め込みテキストがあり OCR が不要な PDF なら言語を問わないと補足しています。日本語固有の記述はここまでです。精度の判断材料になるのは Surya が公表している 91 言語ベンチで、総合 87.2% に対し日本語 86.2%、つまり全言語平均をわずかに下回る位置にあります。

一方、縦書きへの対応可否を明言した公式記述は Marker・Surya・Chandra のいずれにも存在しません。縦書きの書籍や公文書を扱うなら、対応していると仮定せず自社サンプルで必ず検証してください。日本語文書の OCR 精度を横並びで比べるなら、NDLOCR-Lite Webの使い方と精度・商用利用｜インストール不要の無料ブラウザOCRや、レイアウト解析をマルチモーダルで解く従来OCRの限界を超えるdots.mocrのマルチモーダル解析という新発想も候補に入ります。

よくある質問

marker-pdf のインストールは pip install marker-pdf だけで足りますか？

PDF と画像だけを変換するなら足ります。PPTX・DOCX・XLSX・HTML・EPUB を入力に使うなら pip install marker-pdf[full] が必要です。また torch は別途ローカルに導入しておく必要があり、GPU 環境では CUDA 対応版を選びます。

Marker は日本語のPDFに対応していますか？

README は全言語対応と記載しており、認識を担う Surya の公表値では日本語 86.2% です。ただし縦書きに関する公式な対応表明は無いため、縦組み文書は事前検証が必須です。

marker_single で特定のページだけ変換できますか？

できます。--page_range 0,5-10,20 のように指定すると、0 ページ目、5 から 10 ページ、20 ページ目だけを処理します。大きな PDF で精度を試すときは、まずこのオプションで数ページに絞ると GPU 時間を節約できます。

年商200万ドル未満の企業なら商用利用は無条件で無料ですか？

無条件ではありません。モデル重みのライセンスには、Datalab の製品・サービスと競合する事業者を除外する条項があります。文書変換 API や OCR サービスを提供する企業は、金額基準を満たしていても利用できません。加えてコード側の GPL-3.0 が自社製品へ及ぶ点も別途検討が必要です。

Marker と Docling はどちらを選ぶべきですか？

ライセンス制約を負えないなら MIT の Docling です。Marker が優位なのは変換速度（H100 で 2.84 秒対 3.70 秒）と数式・表の再現性で、README のヒューリスティック評価では 95.67 対 86.71 の差があります。200 万ドル基準をクリアでき、数式や表の精度が成果を左右する用途に限って Marker を選ぶのが妥当です。

関連記事

• 従来OCRの限界を超えるdots.mocrのマルチモーダル解析という新発想
• Tesseractとは？読み方・精度・商用利用とPSM/OEM設定を実務目線で解説
• NDLOCR-Lite Webの使い方と精度・商用利用｜インストール不要の無料ブラウザOCR
• RRF（Reciprocal Rank Fusion）とは？RAG-Fusionでの仕組み・スコア計算・実装を解説
• ベクトル検索とセマンティック検索の違い｜包含関係・仕組み・使い分けを実装目線で整理