AI PDF要約ツールとは何ですか？

PDFドキュメントをAI（LLM）で解析し、要約・質問応答・構造化データ抽出を行うツールです。OCR機能を持つものはスキャンPDFにも対応します。

OSSと商用ツールの違いは？

OSSはデータがローカルに留まり、カスタマイズ自由で無料ですが、セットアップや保守コストがかかります。商用はセットアップが簡単でGUIが充実していますが、データをクラウドに送信する必要があり、料金が発生します。

AGPL-3.0ライセンスは商用利用できますか？

条件付きです。自社内ツール（社内PoC等）は問題ありませんが、AGPL-3.0のOSSを組み込んだSaaSをユーザーに提供する場合、自社コードも含め全ソースコードの公開義務が発生します。MinerUとPyMuPDF4LLMはAGPL-3.0のため、商用SaaS組み込みには注意が必要です。

スキャンPDFに一番精度が高いOSSはどれですか？

MinerUが最も高精度です。109言語に対応し、PaddleOCRとの組み合わせで日本語縦書きPDFにも対応します。ただしAGPL-3.0ライセンスであるため、商用サービスへの組み込みには法務確認が必要です。

AI PDF要約ツール8選｜OSS vs 商用を用途・コスト・ライセンスで比較

PDFをAIに読ませる——それだけのことなのに、「どのツールを選ぶか」で結果が大きく変わる。2026年現在、AI PDF要約の選択肢はOSSから商用SaaSまで急増している。しかし「AI PDF 要約」で検索して出てくる記事の9割は、「ChatPDFに投げるだけ」「ClaudeにPDFを貼ればいい」という表面的な紹介で終わっている。

RAGパイプラインに組み込んで月数千件のPDFを処理したい、スキャン済みの法的文書を安全にローカル解析したい、研究論文の表と数式を崩さずMarkdown化したい——そういった実務の問いには答えていない。

本記事では8ツール（OSS 5つ + 商用 3つ） を、精度・コスト・ライセンス・チーム適合性の4軸で比較する。さらに見落とされがちなAGPL-3.0ライセンスの商用落とし穴と、「OSSは無料」という幻想を覆す隠れたコスト構造についても踏み込む。

この記事でわかること
OSS 5ツール（LlamaParse・MinerU・Marker・PDF Craft・PyMuPDF4LLM）の精度・特性・ライセンスの実態
商用 3サービス（ChatPDF・Claude・Gemini）の料金・制限・本当に向いているシーン
AGPL-3.0ライセンスが商用SaaSに与えるリスクと回避パターン
チーム規模・業種・用途別のツール選定フロー

AI PDF要約ツール 8選の全体像

まず8ツールをひと目で把握できる比較表から始める。詳細な評価は後述するが、最初に「地図」を持っておくと判断が速くなる。

ツール	種別	GitHubスター	OCR	日本語	ライセンス	GPU	RAG統合
LlamaParse	クラウドAPI（SDK: OSS）	3.6k	◎	○	MIT（SDK）	不要	◎
MinerU	OSS	57k	◎	◎	AGPL-3.0 ⚠️	推奨	○
Marker	OSS	19k	○	○	GPL-3.0 ⚠️	推奨	○
PDF Craft	OSS	1k+	△	△	MIT	不要	△
PyMuPDF4LLM	OSS	28k（PyMuPDF）	△	○	AGPL-3.0 ⚠️	不要	◎
ChatPDF	商用SaaS	—	◎	○	利用規約	不要	△
Claude	商用API	—	◎	◎	利用規約	不要	○
Gemini	商用API	—	◎	◎	利用規約	不要	○

⚠️ = 商用SaaS組み込みに制限あり（後述）

「OSSは無料」は幻想
MinerUを本番環境で動かすには、GPU搭載サーバー（A10G 1台 = AWS月$800〜）や保守エンジニアのコストが発生する。LlamaParseは無料枠を超えると従量課金。「無料ツール」の実態を後半のコスト分析で整理する。

ツール選定フロー — 最初の3つの問いに答えるだけ

8ツールの中から自分に合うものを選ぶには、3つの問いに答えるだけでよい。

graph TD A["AI PDF要約ツールを選びたい"] --> B{"機密文書を扱う？
（医療・法務・社内機密等）"} B -->|"Yes"| C{"RAGパイプラインに
組み込む？"} B -->|"No（一般文書）"| D{"主な利用規模は？"} C -->|"Yes"| E{"GPU環境あり？"} C -->|"No（要約のみ）"| F["PyMuPDF4LLM
CPU動作・ローカル完結
AGPL-3.0確認必要"] E -->|"Yes"| G["MinerU
OCR精度最高
AGPL-3.0確認必要"] E -->|"No"| F D -->|"月数十ファイル以下"| H["ChatPDF / Claude
セットアップ不要
ブラウザから即使用"] D -->|"月数百ファイル以上"| I{"エンジニアが
コードを書ける？"} I -->|"Yes"| J["LlamaParse + LlamaIndex
RAG統合が最もスムーズ
MIT・無料枠1000P/日"] I -->|"No"| K["Gemini + NotebookLM
ノーコードで
複数PDF横断検索"]

このフローで「機密文書 × RAG × GPU あり」という条件に当てはまるなら MinerU が最有力候補だ。しかし選ぶ前に、ライセンスの章を必ず読んでほしい。

OSS 5ツールの実態 — スペックシートに書かれていないこと

LlamaParse — 「OSS」だが実態はクラウドAPI

LlamaParseのSDKはMITライセンスで公開されているが、実際の解析処理はLlamaCloud（クラウドAPI）で行われる。 ローカルで完結するツールではない。この点は意外と見落とされる。

つまりLlamaParseは「クラウドAPIの使いやすいラッパー」であり、機密文書をローカルで処理したいという要件には合わない。データは一度LlamaCloudのサーバーに送信される。

では何が強みか。LlamaIndexエコシステムとのシームレスな統合だ。parser.load_data("doc.pdf")の戻り値が直接Documentオブジェクトとして返り、そのままベクトルインデックスに投入できる。RAGとは何かを学ぶ記事でも紹介しているが、パースからチャンク分割・インデックス構築まで一連の流れを最も少ないコードで実装できる。

LlamaParseが向いているチーム:

LlamaIndexベースのRAGシステムを構築している
機密性の低いドキュメント（技術仕様書、マーケティング資料など）を扱う
無料枠（1日1,000ページ）の範囲内で収まる
GPUを持たず、ローカルMLモデルを動かしたくない

LlamaParseが向いていないチーム:

医療・法務・金融などの機密文書を扱う（データがクラウドに送られる）
月10万ページ以上の大量処理（コストが急増する）

MinerU — OCR精度の王者、ただしAGPL-3.0

MinerUのGitHubスター57,000は伊達ではない。PDF→Markdown変換の精度でOSSの中での頭一つ抜けた存在だ。109言語OCR、クロスページ表の結合、LaTeX数式変換——「難しいPDF」への対応力が圧倒的に高い。

しかしMinerUを商用サービスに組み込む前に、必ずAGPL-3.0ライセンスの条件を確認してほしい。後述するライセンス章で詳しく解説するが、AGPL-3.0はSaaS提供に制限を課す可能性がある。

MinerUのもう一つの特徴は、スキャンPDFと電子PDFを自動判別して処理方法を切り替える点だ。通常のテキストPDFには高速なテキスト抽出エンジンを使い、スキャンPDFにはPaddleOCR+Tesseractを使う。ユーザーがモードを意識しなくてもよい。

日本語縦書きPDFへの対応も、OSSの中では最も成熟している。公文書、昭和時代の技術文書、縦組み書籍など、他のツールでは崩れやすいレイアウトにも対応する。

MinerUが真価を発揮するシーン:

研究機関での論文PDF大量処理（数式・表の精度が重要）
製造業の設備マニュアル（スキャンPDFが混在）
公共機関の公文書デジタル化（縦書き・OCR対応）
機密性が許す限りのRAGナレッジベース構築

MinerUが向かないシーン:

GPU環境のない開発者PCでの軽量処理
商用SaaSへの組み込み（AGPL-3.0確認必須）
リアルタイム処理（OCRモード時はバッチ向き）

Marker — マルチフォーマットの柔軟性

Markerの最大の差別化はPDF以外のフォーマットにも対応する点だ。EPUB、MOBI、DOCX、PPTX、HTML——書籍・スライド・ウェブページを一括でMarkdown化できる。

GitHubスター19,000という人気は、「PDFだけ」という制約のない汎用性が評価されている。出版社や教育機関が複数フォーマットのドキュメントを統一的に処理するケースで採用事例が多い。

ライセンスはGPL-3.0。AGPL-3.0より制限は緩いが、MITやApache 2.0と比べると商用利用の条件がある。詳細はライセンス章で扱う。

Markerが向いているシーン:

PDF・EPUB・DOCXが混在するドキュメント群を一括処理
CUDA / MPSに対応したGPUマシンがある環境
書籍・マニュアル・スライドのMarkdown化

PDF Craft — 書籍に特化した職人ツール

PDF Craftは小説・技術書などの「書籍形式PDF」に特化したOSSだ。目次構造の保持、ヘッダー・フッター・ページ番号の高精度除去に長けている。

MITライセンスで商用利用への制限が少ない点は強みだが、OCR機能は限定的でスキャンPDFへの対応は薄い。GitHubスターも1,000台と他のツールより少なく、コミュニティの成熟度で劣る。

PDF Craftが向いているシーン:

技術書・小説など、書籍形式のPDFを大量処理
テキストベースPDF（OCR不要）の目次付き変換
MITライセンスが必須の商用プロジェクト

PyMuPDF4LLM — 「退屈だが信頼できる」選択肢

PyMuPDF4LLMはPyMuPDF（fitz）の拡張で、LLMに最適化されたMarkdown出力を行う。依存パッケージが極めて少なく、GPUなしでCPU動作する。

他のMLモデルベースのツールと比べると機能は地味だ。しかしCI/CDパイプライン、サーバーレス関数、メモリ制限のあるコンテナ環境では、これが最も安定して動く。デプロイの複雑さを最小化したい本番環境向けの選択肢だ。

LlamaIndexとの統合も用意されており、page_chunks=TrueオプションでページごとのDocument形式出力ができる。LangChainを使ったRAGパイプラインにも直接組み込める。

注意点はMinerUと同じAGPL-3.0ライセンス。商用SaaSへの組み込みは後述するライセンス章を先に確認すること。

# PyMuPDF4LLM: 最小限の実装例（GPUなし・依存小）
import pymupdf4llm

# テキストPDF → Markdown（LlamaIndex Document形式）
docs = pymupdf4llm.to_markdown("report.pdf", page_chunks=True)

# 各要素は {text, metadata} の辞書形式
for doc in docs[:3]:
    print(f"p.{doc['metadata']['page']}: {doc['text'][:80]}")

PyMuPDF4LLMが向いているシーン:

サーバーレス・コンテナ環境（軽量が正義）
テキストベースPDF（OCR精度は不要）
LlamaIndexやLangChainへのシンプルな統合
CI/CDパイプライン内での自動化処理

商用3サービスの現実 — 便利さの対価を正確に理解する

ChatPDF — 「手軽さ」と「スケール限界」のトレードオフ

ChatPDFは最もセットアップが簡単なAI PDF対話サービスだ。ブラウザでPDFをアップロードするだけで質問応答が始まる。エンジニアでないチームメンバーに使ってもらうには最適な選択肢の一つだ。

しかし無料プランの制限は厳しい。1日3ファイル、1ファイル120ページ、1日50質問まで。月次レポートや研究論文を日常的に処理するには、すぐに壁に当たる。

プラン	月額	ファイル/日	ページ/ファイル	質問/日
無料	$0	3	120	50
Plus	$20	50	2,000	1,000

ChatPDFは「APIプログラム的利用」よりも「個人・小チームのアドホック使用」に向いている。月数回、PDFに質問したいだけなら十分だ。

Claude — 大規模文書理解の現実的な最強候補

AnthropicのClaudeは、200Kトークン（約500ページ相当）のコンテキストウィンドウでPDFを丸ごと処理できる。他のツールがページ分割・チャンク化・ベクトル検索という複雑なパイプラインを必要とするところを、Claudeはシンプルに「全部読む」アプローチで解決する。

RAGパイプラインを構築するエンジニアリングコストと比較したとき、「APIに投げるだけ」のClaudeは意外とコスト効率が良い場合がある。特に数百ページ規模の文書を月数十件処理するユースケースでは、パイプライン構築の人件費を考えるとClaudeの直接利用のほうが総コストが低い。

# Claude API: PDFを直接アップロードして要約（base64経由）
import anthropic, base64
from pathlib import Path

client = anthropic.Anthropic()
pdf_data = base64.standard_b64encode(Path("report.pdf").read_bytes()).decode()

message = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=2048,
    messages=[{
        "role": "user",
        "content": [
            {"type": "document", "source": {"type": "base64", "media_type": "application/pdf", "data": pdf_data}},
            {"type": "text", "text": "この文書の主要な発見を日本語で5点にまとめてください。"},
        ],
    }],
)
print(message.content[0].text)

Claudeの料金（Claude 3.5 Sonnet）:

入力: $3 / MTok
出力: $15 / MTok
500ページのPDF（約15万トークン）= 約$0.45/回

大量処理になるとコストは積み上がるが、月数十件なら許容範囲内だ。

Gemini + NotebookLM — 「複数PDFを横断して調べる」に最強

Geminiの1Mトークンコンテキストは、大量ドキュメントの横断検索で効果を発揮する。しかしGeminiの真の強みはNotebookLMとの組み合わせだ。

NotebookLMでは複数のPDFをソースとして登録し、「このプロジェクトの全仕様書にまたがる質問」ができる。エンジニアがRAGパイプラインを組まなくても、ノーコードで複数文書横断のQ&Aが実現する。

Geminiが向いているシーン:

複数のPDFを横断的に調べたいビジネスユーザー
NotebookLMでチームと共有したいドキュメントナレッジベース
数百ページの長文文書（1Mトークンの余裕）
RAGパイプライン構築のエンジニアリングコストをかけたくないチーム

AGPL-3.0という「時限爆弾」 — OSSライセンスの商用落とし穴

この章はエンジニアリングマネージャーやCTOに特に読んでもらいたい。

MinerU、PyMuPDF4LLM、そして間接的にMarker（GPL-3.0）は、コピーレフト型ライセンスを採用している。これはオープンソースの恩恵を受けたコードを公開する義務を課すライセンスだ。

AGPL-3.0の核心的な条件は以下だ:

AGPL-3.0の商用SaaSリスク
AGPL-3.0のライブラリを組み込んだソフトウェアをネットワーク越し（SaaS）にユーザーへ提供する場合、そのソフトウェア全体のソースコードをAGPL-3.0で公開する義務が生じる可能性があります。自社の独自アルゴリズムや顧客データモデルも含む可能性があります。

具体的なシナリオで考えよう。

シナリオ1: 社内RAGシステムへの組み込み（リスク: 低〜中） MinerUを使って社員が社内文書を検索するシステムを構築する。社外ユーザーへのSaaS提供でなければ、AGPL-3.0の「ネットワーク提供」条件は通常発生しない。法務確認を推奨するが、多くの社内ユースケースは許容範囲内だ。

シナリオ2: PDF解析SaaSへの組み込み（リスク: 高） 「PDFをアップロードすると要約してくれるサービス」にMinerUを組み込む。これはAGPL-3.0の「ネットワーク越しにユーザーへ提供」に該当する可能性が高い。ソースコード公開義務が発生しうる。

回避パターン:

状況	推奨対応
社内PoC・社内ツール	そのまま使用可（法務確認推奨）
商用SaaSへの組み込み	MITのLlamaParseへ切り替えを検討
商用SaaS × 高精度OCR必須	MinerUの商用ライセンス交渉（opendatalab）or LlamaParseのElastic Tier
ライセンスリスクを完全回避	Claude API / Gemini API（利用規約に従う）

LlamaParseのSDKはMITライセンスで商用制限がない。「精度はMinerUが欲しいが、ライセンスがネック」というチームには、LlamaParseのProプランへの移行が現実的な選択肢だ。

「OSSは無料」という幻想 — 総所有コスト（TCO）の現実

OSSを本番環境で動かすコストは、ライセンス料ゼロだけでは語れない。

graph LR A["OSS PDF解析ツール
（MinerU / Marker）"] --> B["初期コスト"] A --> C["運用コスト"] A --> D["機会コスト"] B --> B1["GPU環境構築
AWS A10G: $1000-2000"] B --> B2["セットアップ工数
エンジニア 2〜5日"] B --> B3["モデルダウンロード
数GB〜数十GB"] C --> C1["GPU電気代・クラウド費
A10G on-demand: $1.32/h"] C --> C2["バージョンアップ対応
月1〜2日"] C --> C3["障害対応・監視
エンジニア常駐コスト"] D --> D1["LlamaParse Pro
$0.003/ページ"] D --> D2["Claude API
$0.45 / 500ページ"]

月1,000ページを処理するユースケースを例に試算する。

選択肢	初期費用	月額費用	1年総コスト（概算）
MinerU（AWS A10G）	$1,500（セットアップ工数）	$950（A10G 720h/月）	$12,900
LlamaParse Pro	$0	$3（$0.003 × 1,000P）	$36
Claude API（Sonnet）	$0	$4.5（$0.0045 × 1,000P）	$54
ChatPDF Plus	$0	$20（月額固定）	$240

月1,000ページ以下なら、商用APIのほうが圧倒的に安い。 MinerUの本領が発揮されるのは月数十万ページを超える大量処理か、機密文書でクラウド送信が絶対NGな場合だ。

業種・チーム別おすすめ構成

抽象的な比較より、「うちはどれを使えばいい？」への直接的な回答を用意した。

研究機関・大学

論文PDFの数式・表・引用構造を正確に取り出すことが重要。MinerUの精度が必要。機密文書ではなく、AGPL-3.0のリスクも低い。

推奨: MinerU + PyMuPDF4LLM（軽量処理との使い分け）

法律事務所・コンプライアンス部門

文書の機密性が最高レベル。クラウド送信が原則NG。契約書・判決文のOCR精度も重要。

推奨: MinerU ローカル環境（AGPL-3.0 → 社内利用のみで回避）。クラウド可ならClaudeのプロセッシングポリシー確認後にClaude API。

スタートアップ（PDF関連SaaS構築）

AGPL-3.0ライセンスリスクを避けながら高精度を求める。エンジニアコストも最小化したい。

推奨: LlamaParse（MIT、LlamaIndexとの統合が最速）+ Claude APIによるハイブリッド。精度が足りなくなったらLlamaParseのElastic Tierに移行。

大企業の情報システム部門

大量の社内文書をRAG化したい。月数万ページ規模。機密性高い。GPU環境は調達可能。

推奨: MinerU（ローカル） + ベクトルDB（Qdrant or pgvector） + Claude APIで回答生成のハイブリッド。RAGFlowのようなエンタープライズRAGシステムとの連携も検討。

個人・小チームの研究者・ライター

月数十ファイルを手軽に処理したい。セットアップに時間をかけたくない。

推奨: ChatPDF（無料プラン）またはGemini + NotebookLM（無料枠あり）。技術的な限界を感じたらClaude APIへ移行。

OSS vs 商用の精度比較 — どのPDFで何が変わるか

「どのツールが一番精度が高いか」という問いへの正直な答えは「PDFの種類による」だ。以下の比較表を判断材料にしてほしい。

PDFの種類	最高精度	次点	商用ならこれ
テキストPDF（デジタルネイティブ）	PyMuPDF4LLM	LlamaParse	Claude API
スキャンPDF（日本語）	MinerU	Marker	Claude API
論文（数式・表あり）	MinerU	LlamaParse	Claude API
書籍（目次付き長文）	PDF Craft	Marker	Claude API
スライド・PPTX混在	Marker	LlamaParse	Gemini API
500ページ超の長文	MinerU + 分割処理	LlamaParse	Claude / Gemini（1M CTX）

Claudeは「最高精度」ではなく「どのPDFでも安定して使える汎用性」が強みだ。OCR特化のMinerUには劣るが、コンテキスト理解・要約・質問応答の質ではLLMの強みを活かせる。

よくある3つの失敗とその対処

失敗1: スキャンPDFをPyMuPDF4LLMに投げてテキストゼロ

PyMuPDF4LLMはテキストPDF向きで、OCR機能は持たない。スキャンPDF（画像PDF）を投げると、ほぼ何も取得できない。

# PDFの種類を事前判定する1分チェック
import pymupdf
doc = pymupdf.open("input.pdf")
text = doc[0].get_text()
print("スキャンPDF → MinerU推奨" if len(text.strip()) < 50 else "テキストPDF → PyMuPDF4LLMでOK")

失敗2: 表の結合がずれてRAGの回答が崩れる

PDF内の複数ページにまたがる表や、セル結合のある表は、多くのツールで解析が崩れる。LLMが崩れた表を読むと「第1四半期売上」と「第2四半期コスト」が混在した誤った回答を返す。

対処: MinerUのクロスページ表結合機能を使う。それでも崩れる場合はClaudeの視覚的理解に委ねる（PDFをbase64でClaudeに直接送信し、表部分の解釈を任せる）。

失敗3: 大量処理でメモリ不足

数百ページのPDFをそのままMinerUやMarkerに投入するとメモリ不足でクラッシュする。本番環境では必ずページ範囲を分割して処理する設計にすること。Difyでも大量ファイルのキュー詰まりが報告されているが、根本原因は同じだ。処理単位を小さく保つことが安定運用の鉄則。

ハイブリッド構成のすすめ — 「どれか一つ」より「組み合わせ」

実務で最も費用対効果が高いのは、単一ツールの選択ではなくハイブリッド構成だ。

graph LR A["PDF群"] --> B{"PDFの種類判定"} B -->|"テキストPDF"| C["PyMuPDF4LLM
高速・軽量"] B -->|"スキャンPDF"| D["MinerU
高精度OCR"] B -->|"500ページ以上
かつ機密文書"| E["MinerU ローカル
+ 分割処理"] B -->|"手軽に試したい
機密性低い"| F["LlamaParse
or Claude API"] C --> G["Markdownテキスト"] D --> G E --> G F --> G G --> H["LlamaIndex / LangChain
RAGパイプライン"] H --> I["Claude / GPT
回答生成"]

たとえばテキストPDFはPyMuPDF4LLM、スキャンPDFはMinerU、緊急で試したいものはClaude APIに直接投げるという3層の振り分けを自動化するだけで、コストと精度を両立できる。

LightRAGのような知識グラフRAGと組み合わせると、PDF内のエンティティ（人名・組織名・技術用語）間の関係性を構造化でき、単純な類似検索より深い質問への回答精度が上がる。

まとめ — 選定の3原則

AI PDF要約ツールを選ぶ際の判断基準を最後にシンプルにまとめる。

原則1: 機密文書は必ずローカル処理 医療・法務・金融の機密文書はクラウドAPIに送ってはいけない。MinerUかPyMuPDF4LLMをローカルで動かす。AGPL-3.0の社内利用は通常問題ないが法務確認を。

原則2: 月1,000ページ以下なら商用APIが安い MinerUのGPUサーバーより、LlamaParse ProやClaude APIのほうが圧倒的に安上がり。エンジニアリングコストを含めて計算してから判断すること。

原則3: 商用SaaS組み込みはMITを選ぶ LlamaParseのSDK（MIT）は商用SaaSへの組み込みに制限がない。MinerU・PyMuPDF4LLMのAGPL-3.0は商用SaaSへの組み込みに法務リスクがある。

次のステップ
RAGとは？仕組み・構築・ベクトルDB選定まで — PDF解析後のパイプライン全体を理解する
LangChainでRAGパイプラインを構築する — PDF解析後のベクトル検索・質問応答の実装
LightRAGで知識グラフRAGを構築する — PDF内のエンティティ関係を構造化して検索精度を向上
RAGFlowでエンタープライズRAGを構築する — GUIで高精度なドキュメント検索を実現
MinerU詳細解説 — OCR精度最高クラスのOSSを深掘りする