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は無料」という幻想を覆す隠れたコスト構造についても踏み込む。

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

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

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

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

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

このフローで「機密文書 × 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質問まで。月次レポートや研究論文を日常的に処理するには、すぐに壁に当たる。

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の核心的な条件は以下だ:

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

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

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

回避パターン:

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

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

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

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

月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の種類による」だ。以下の比較表を判断材料にしてほしい。

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でも大量ファイルのキュー詰まりが報告されているが、根本原因は同じだ。処理単位を小さく保つことが安定運用の鉄則。

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

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

たとえばテキスト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への組み込みに法務リスクがある。

参照ソース

• LlamaParse GitHub リポジトリ — LlamaIndex公式PDF解析エンジン（MIT）
• MinerU GitHub リポジトリ — 高精度PDF→Markdown変換（AGPL-3.0・57kスター）
• Marker GitHub リポジトリ — ML駆動マルチフォーマット変換（GPL-3.0・19kスター）
• PyMuPDF4LLM ドキュメント — LLM向けPDFテキスト抽出（AGPL-3.0）
• PDF Craft GitHub リポジトリ — 書籍PDF特化変換（MIT）
• ChatPDF 公式サイト — PDF特化の対話型AIサービス
• Anthropic Claude API — PDF サポートドキュメント — Claude PDF処理の公式ガイド
• AGPL-3.0 ライセンス全文（SPDX） — ライセンス条文の一次ソース