複数のPDFをまとめてMarkdownに変換する

量に合わせて方法を選ぶ

適切な方法は、PDFの中身よりも、数と作業が繰り返されるかどうかで決まります。大まかな目安は次の通りです。

• 数個から数十個、1回きり： ブラウザの一括変換ページ。インストール不要で、ファイルはパソコンに残ります。
• 数百個、または毎週： フォルダーを回すPythonのループ。スケジュール実行、ログ記録、フォルダー構成の維持ができます。
• スキャン、フォーム、数式、特殊なレイアウト： marker のようなモデルベースのツール。普通のノートパソコンではかなり遅くなります。テキスト層のないページをOCRで読むために作られていますが、私たちのCPUでの実行ではスキャンしたページは空のままだったので、まず数ファイルで試してください。

3つの方法を公平に比べるため、20ファイル・40ページのテストセットを使いました。表とレイアウトのサンプル12個、英語のガイド、11ページの中国語のレポート、繰り返しヘッダーのある4ページのレポート、テキスト層のないスキャン1ページ、そして2つのフォルダーにある、どちらも notes.pdf という名前の別々のファイル2つです。すべて私たちのビルド用マシン（Linux x86_64, 8 vCPU, 16 GB RAM, no GPU）で実行しました。

ブラウザで複数のPDFをMarkdownに変換する

始める前に、PDFを2、3個開いて文を選択してみてください。テキストを選択できればファイルにはテキスト層があり、下のどの方法でも使えます。何も選択できなければ、ファイルはスキャンか画像で、言葉を取り出せるのはOCRツールだけです。前もって中身の内訳を知っておけば、2回目の処理をせずに済みます。

一括変換ページを開き、「ファイルを選択」をクリックして（または選んだファイルをドロップ欄にドラッグして）、すべてのPDFを一度に選びます。各ファイルはタブの中で1つずつ変換され、ページはPDFごとに .md が1つずつ入った1つのZIPを用意します。作業はローカルで行われるので、速度はアップロードではなくパソコン次第です。すべてのファイルが1台のパソコンにあるなら、これが複数のPDFをまとめてMarkdownに変換する最速の方法です。

私たちのテストでは、ファイルの選択からZIPの完成まで、セット全体で約0.8秒かかりました（Chrome 155.0.8059.84、3回の実行で0.8〜1.0秒）。ZIPには20個のMarkdownファイルが入っていました。2つの notes.pdf は notes.md と notes-2.md として出力され、互いに上書きされることはなく、スキャンしたページは黙って失敗するのではなく一覧で印が付きました。

限界：ブラウザはそのままではフォルダーのツリーを読めないので、複数のフォルダーのファイルは1つのZIPに並んで入ります。また、非常に大量のファイルはタブのメモリに制限されます。数百ファイルなら、選択を何回かに分けるか、スクリプトに切り替えてください。

pymupdf4llm を使ったPythonのループ

この作業のためのPythonスクリプトは数行で済みます。次のスクリプトはPDFでいっぱいのフォルダーをMarkdownに変換します。フォルダーを順にたどり、出力でも同じ構成を保ち（2つの notes ファイルは別々のまま）、1つのファイルが失敗しても処理を続けます。

import pathlib, pymupdf4llm

src, out = pathlib.Path("pdfs"), pathlib.Path("markdown")
for pdf in sorted(src.rglob("*.pdf")):
    dest = out / pdf.relative_to(src).with_suffix(".md")
    dest.parent.mkdir(parents=True, exist_ok=True)
    try:
        dest.write_text(pymupdf4llm.to_markdown(str(pdf)), encoding="utf-8")
    except Exception as e:
        print(f"skipped {pdf}: {e}")

同じ20ファイルで、このループは私たちのテストでPythonの起動とライブラリの読み込みを含めて5.3秒で終わりました。書き出したファイルは20個です。そのうち2つは空でした。読み取れるテキストのないスキャンしたページと、90度回転した表のあるページです。数千のファイルなら、各ファイルは独立しているので、同じループをプロセスプールでCPUコアごとに1ワーカーで動かせます。Pythonガイドでは表とページ範囲のオプションを、ライブラリの比較では pymupdf4llm と2つの代替ライブラリの比較を紹介しています。

marker のフォルダーコマンド

marker にはフォルダー全体を処理するコマンドがあります：marker /path/to/pdfs --output_dir out。フォルダーの最上位だけを読む（スクリプトは os.listdir で一覧を取る）ので、事前にファイルを平らなフォルダーにコピーしました。便利なオプションは、並列処理の --workers、中断した処理を再開する --skip_existing、試し実行のための --max_files です。

GPUのない私たちのマシンで初期設定のまま実行したところ、フォルダーの処理にはモデルの読み込みを含めて5分51秒かかり、20個の出力を書き出しました。Pythonのループの約66倍の時間です。回転した表は救い出しましたが2回書き出し、スキャンしたページについては、私たちの実行でもやはり空のファイルを返しました。対応するGPUのあるマシンなら話は違いますが、ノートパソコンでは marker を必要なファイルだけに使いましょう。

ファイル名、重複、フォルダー構成

• 重複： たくさんのPDFをまとめて変換するときは、2つのフォルダーにある同じファイル名をどう扱うかを決めておきます。私たちの一括変換ページは番号を付け、上のループはサブフォルダーを保ちます。素朴なスクリプトは警告なしに最初のファイルを上書きします。
• 構成： フォルダーのツリーに意味がある（顧客ごと、年ごとのフォルダーなど）なら、上のように relative_to を使うか、一括変換ページをフォルダーごとに1回ずつ使って、構成を保ちます。
• 名前： .md にはPDFの基本名をそのまま使えば、いつでも元のファイルを見つけられます。読みやすさのための名前変更は、あとでノートアプリで行いましょう。
• MarkdownファイルのZIP は他の人に渡すのに最も簡単な形です。出力を別のスクリプトに渡すなら、フォルダーのほうが向いています。

品質の確認：スキャンや空の出力を見つける

複数のPDFを1回でMarkdownに変換すると、1ファイルならすぐ気づく問題を見落としがちです。テストしたどのツールも、空かほぼ空のファイルを少なくとも1つ返し、OCRなしで読めないページをテキストにできるものはありませんでした。大きな処理のあとは毎回、短すぎるファイルを探しましょう。

# Markdown files under 100 bytes are usually scans or image-only pages
find markdown -name '*.md' -size -100c

その後、いくつかの出力を無作為に開き、PDFと比べます。見出し、表を1つ、最後の段落です。ファイルをチャットモデルに渡すなら、ChatGPTに最適な文書形式の記事で、きれいなMarkdownのためにこの確認をする価値を説明しています。

20ファイルでの計測結果

ほとんどの人にとって結論はシンプルです。複数のPDFを一度にMarkdownに変換するなら、まずブラウザで始め、作業が繰り返されるならスクリプト化し、モデルベースのツールは他の方法で読めないページのために取っておきましょう。