PDF を Markdown に変換する方法
PDF と Markdown は、ドキュメントのスペクトルの両端に位置します。PDF はすべてのグリフをページ上の位置に固定し、どこで開いてもまったく同じ見た目になります。一方 Markdown は構造だけを記述するプレーンテキストで、レイアウトは読み手側に委ねます。両者の変換とは、PDF ファイル自身が保存していない構造を組み立て直す作業です。
このガイドでは、その再構築で何が復元できて何が復元できないのか、このサイトのブラウザ内コンバーターで PDF を変換する方法、LLM 最適化スイッチが何を変えるのか、そしてコンバーターがそもそも適さない場面について順に解説します。
PDF と Markdown が対極にある理由
PDF は印刷の末裔です。あるグリフが特定のフォント・特定のサイズで座標 x, y に置かれている、という情報を記録します。ファイルのどこにも「これは見出しである」とか「この 3 列が表を構成する」とは書かれていません。画面に見える構造は閲覧アプリが再構築したもので、ファイルが保存しているのはインクの跡だけです。
Markdown はその逆です。見た目に関する情報をほとんど持たず、構造のすべてを保持します。ハッシュで始まる行は見出し、パイプは表の区切り、インデントはリストの入れ子。フォントや余白はレンダラーが決めます。
つまり PDF から Markdown へのコンバーターは、実質的に構造検出器です。位置情報付きのテキストを読み取り、どの行が大きく太く組まれたか、どの隙間が段落を分けるか、どの罫線がグリッドに整列しているかを見抜き、その結果を Markdown 記法で表現し直します。コンバーターの品質とは、この検出の品質のことです。
良い変換が保つもの
まず読み順です。PDF、とりわけ 2 段組みのレイアウトでは、テキストは人間の読む順序とは無関係な順番で格納されています。コンバーターは視覚的な流れに従わなければなりません。左の段を最後まで読み、次に右の段へ。見出しは順番通り、段落も順番通りに。ここを間違えると、出力は文法的には正しいのに意味不明な文章になります。
次に見出しレベルです。本文、キャプション、見出しはフォントサイズとウェイトが異なり、コンバーターはその差を #、##、### に対応づけます。デザイナーが 13 ポイントの太字を本文に使った文書で完璧な対応は不可能ですが、実際の文書の多くは一貫した規則に従っており、検出器はそれを拾えます。
段落の境界は見た目以上に重要です。PDF の改行は文が終わる場所ではなく、ページ上でその行がたまたま終わった場所で起きます。こうした行を 1 行の段落につなぎ直すことが、そのまま編集できる Markdown と、1 行ずつ修理が必要な Markdown を分ける境目です。
このツールで PDF を変換する
コンバーターは完全にブラウザ内で動作します。PDF 解析エンジンは Rust からコンパイルされた WebAssembly で、ファイルがデバイスの外に出ることはありません。.pdf ファイルを 1 つでも複数でもページにドロップすれば、順番に Markdown へ変換され、結果はプレビューパネルに表示され、不審な箇所には警告が示されます。
始める前に知っておきたい警告がひとつあります。抽出可能なテキストを含まないページ、典型的にはスキャンやページの写真は、何も出力できません。その場合、ツールは半分空のドキュメントを黙って渡すのではなく、影響を受けるページ番号を明示します。このケースは別の記事で扱っています。修正は変換の途中ではなく、変換の前に行うものだからです。
変換が終わったら、Markdown ファイルをそのままダウンロードするか、複数の PDF を変換して 1 つのアーカイブにまとめて取得できます。すべてローカルで処理されるため、デバイスのメモリ以外にファイルサイズの制限はなく、待ち行列もありません。
LLM 最適化スイッチ
デフォルトでは、テキスト出力は読みやすい幅に収まるよう折り返されます。pandoc や多くのテキストツールが何十年もそうしてきた挙動です。この折り返しはレンダリング表示では見えませんが、機械にとってはトークンの消費を増やし、diff を複雑にします。
LLM 最適化スイッチはこの折り返しを無効にし、各段落を 1 つの長い行にします。ChatGPT や Claude、ローカルモデルにドキュメントを渡すなら、1 行段落のほうがトークン化がわずかに効率的で、段落境界でクリーンに分割でき、元ドキュメントが変わったときの diff もきれいになります。
このスイッチは同時に、PDF エンジンの抽出プロファイルをコンパクトモードに切り替えます。レイアウト忠実な冗長さより、引き締まった簡潔な出力を優先するモードです。出力先がモデルならオンに、人間がエディターで編集するならオフに。エディター側が勝手に折り返してくれるからです。
表：いちばんの難所
表は単独の記事に値します。パイプライン全体で紛れもなく最も難しい対象だからです。PDF フォーマットに表という概念はありません。表とは行と列に配置されたグリフにすぎず、間に罫線が引かれていることもあれば、配置だけで成り立っていることもあります。
このコンバーターは、そうした配置に表構造認識を適用し、GitHub スタイルのパイプテーブルを出力します。ヘッダー下と行間に線のある単純な罫線表は、たいてい無傷で残ります。罫線のない表、多段ヘッダー、結合セルは情報が失われたり平坦化されたりする部分で、FAQ の表に関するセクションが詳細を解説しています。
実践的なアドバイスは、きれいな表形式データには正しさを期待し、数値は必ず検算することです。見事にレンダリングされる表でも、セルが 1 つずれていることがあり、Markdown を目視しただけでは気づけません。変換した表を本番で使う前に、いくつかのセルを原本と照合してください。
Markdown の先へ：HTML、RST、LaTeX
Markdown がデフォルトの出力先ですが、同じパイプラインは出力を第 2 段階、pandoc エンジンに渡すこともできます。これが、このサイトが PDF ソースから reStructuredText や LaTeX を生成できる仕組みです。PDF エンジンが Markdown を生成し、pandoc がその Markdown を読み込んで要求されたフォーマットを書き出します。
パイプラインが直接変換せず Markdown を経由するのには理由があります。Markdown は最も堅牢な中間形式で、pandoc の Markdown リーダーはそこから抽象的なドキュメントモデルを再構築し、そのモデルが他のすべてのライターを駆動します。一手間増える代わりに、実績ある経路が使えます。
レンダリング済みのコンテンツを Web ページやメールに貼りたいときは HTML 出力、Sphinx のドキュメントには RST、論文には LaTeX を使います。ただし多くの PDF ソースにとって、プレーンな Markdown こそが成果物であり、他のフォーマットは目的というより便利なおまけです。
変換が間違いである場合
そもそも入力として不向きな PDF もあります。入力可能なフォームはデータを流れるテキストではなくフィールド構造に保持しているため、変換するとラベルだけが残り、回答は得られません。デザインの凝ったドキュメント、グラフが主役の年次報告書、意図的な改行を持つ詩のように視覚的な配置そのものが意味を持つものは、平坦化されて出てきます。
証明書、スキャンした身分証、画像中心のスライドは、PDF の皮をかぶった画像ドキュメントです。ピクセルとして保存されたテキストは、どんな変換ロジックでも取り出せません。そこには OCR が必要で、このツールは OCR をあえて専用ソフトウェアに任せる前処理と位置づけています。
それ以外のもの、契約書、論文、レポート、ドキュメンテーション、マニュアルページであれば、変換は機能し、しばしば良好に機能します。あなたのドキュメントがどちら側かを知るいちばん速い方法は、一度変換して警告を読むことです。フラグの付いたページのないクリーンな実行は、出力がそのまま使える強いシグナルです。