PDF の表が Markdown 変換で崩れる理由と直し方【7 文書で実測】

PDF を Markdown に変換したら表が崩れた。これは変換のやり方が悪いからではありません。PDF の側が、見た目の表を「表」として持っていないことが多いためです。この記事では、崩れが起きる仕組みと、7 文書で実測して分かった崩れ方の実例、崩れたときに何をすればいいかを説明します。

PDF は見た目の表を「表」として保存していないことが多い

PDF の中身は、文書の構造ではなく描画の手順です。ページの内容は content stream と呼ばれる列に格納され、そこに並ぶのは「この位置にこの文字を置く」「ここに線を引く」といった描画演算子とその引数です（Adobe PDF Reference 1.7別タブで開きます の Graphics / Text の章）。表の罫線は線を引く命令であり、セルの中身はその近くに置かれた文字です。両者を結びつける情報は、標準では入っていません。

このことは、PDF を読むライブラリが何を返すかにも表れています。pdf.js の getTextContent() が返す TextItem が持つのは str（文字列）、transform（変換行列）、width、height、hasEOL などで、行番号も列番号もセル ID もありません（PDF.js API ドキュメント別タブで開きます）。つまり変換ツールは、文字とその位置、そして線の位置から、表の構造を推定するしかありません。

例外はあります。アクセシビリティのためにタグ付けされた PDF（Tagged PDF）は、Table / TR / TH / TD という構造要素を持てます。結合セルには RowSpan / ColSpan 属性も指定できます（W3C の技術文書 PDF6: Using table elements for table markup in PDF Documents別タブで開きます）。ただしこれは作成者が意図してタグを付けた場合の話で、手元の PDF に付いている保証はありません。付いていなければ、推定に戻ります。

7 文書を 2 系統で変換すると、系統ごとに違う壊れ方をしました

推定が失敗するとどうなるかを実際の PDF で確かめました。学術論文、政府の技術文書、記入フォーム、統計表、スライド、中央銀行のレポートという性格の違う 7 文書を選び、性質の異なる 2 系統に通しています。

• テキスト抽出系: pdf.js（pdfjs-dist 6.2.108）+ pdf2md（@opendocsg/pdf2md 0.2.7）。表を組み立てる処理を持ちません
• 構造推定系: pdf-inspector（@firecrawl/pdf-inspector-wasm 0.1.3）。矩形とフォント・座標から表構造を推定します

測定日は 2026-08-02、実行環境は Apple M5 Pro / macOS（Darwin 25.5.0）/ Node v26.3.1 です。対象 7 文書はいずれも文字情報を持つ PDF で、スキャンした PDF は含んでいません。サンプルの取得スクリプト、測定スクリプト、生の結果は本サイトのリポジトリ内 scripts/benchmarks/pdf-table-extraction/ に置いてあります。

この表から読み取れるのは、崩れ方が 2 系統で正反対だということです。テキスト抽出系は 7 文書すべてで表行が 0、つまり表を一切作りません。構造推定系は必ず表を作りますが、その行数が正しさを意味しません。

行数だけを見て良し悪しを判定できない例を挙げます。段組の中央銀行レポートは、タイトルも本文も表のセルに入り込む形で壊れましたが、出力全体に占める表行の割合は 0.43 でした。一方、本物の表を持つ記入フォームは 0.45 です。この 2 つを閾値で分けることはできません。表として出た行が多いことは、表が正しく取れたことの証拠になりません。

崩れ方 1 — 表があきらめられ、本文だけが並ぶ

1 つ目の崩れ方は、表が表として出てこないものです。セルの中身は文字として拾われますが、行と列の区切りが失われ、数値と項目名が地の文のように連なります。実測ではテキスト抽出系がこの挙動で、7 文書すべてで表行 0 でした。

この崩れ方には利点があります。読めば壊れていることがすぐ分かる点です。「表があるはずの場所に表がない」のは見落としようがなく、原本を見に戻る判断がしやすくなります。

ただし副作用が出ることもあります。表の 1 行 1 行を見出しとして扱ってしまうケースです。実測では、多段の統計表でテキスト抽出系が 1360 個の見出しを出力しました。本来の見出しは目視で 4 個程度です。目次が数百項目に膨らんでいたら、この副作用を疑ってください。

崩れ方 2 — 表の形にはなるが、セルの割り当てが誤る

2 つ目は、Markdown の表としては成立しているのに、どの値がどのセルに入るかが違っているものです。実測では構造推定系がこちらでした。多段の統計表は 405 行の表になりましたが、複数年の数値が 1 つのセルにまとまっています。

|15～ 64歳 6625 5878 6678 5893 6732 5912 …|15～ 24歳 595|25～ 34歳 1168|

こちらのほうが危険です。パイプと区切り行が揃っているので Markdown としては正しく描画され、そのまま資料に貼れてしまいます。値が 1 つ隣の列にずれていても、原本を知らない読み手には判別できません。壊れているのに壊れて見えないという点で、崩れ方 1 とは質が違います。

図や段組の本文が表として出てくることがある

推定は、表でないものを表と判定することもあります。実測で確認できた具体例を 2 つ挙げます。

NIST Cybersecurity Framework 2.0 の円環図（Fig. 1 CSF Core structure）は、図の中に置かれた文字が表として出力されました。しかも頭文字が落ちています。

| Fig. 1. CSF Core structure |||
| --- | --- | --- |
| DENTIFY | ROTECT | ETECT ESPOND |

正しくは IDENTIFY / PROTECT / DETECT / RESPOND です。円環に沿って配置された文字が分断され、先頭の 1 文字が別の要素として扱われた結果、意味の通らない語が並んでいます。

もう 1 つは、文書全体が表になる例です。段組の中央銀行レポートでは、タイトルも本文も表のセルに入りました。

|||||2025 年５月１日|
| --- | --- | --- | --- | --- |
||【基本的見解】|1|経済・物価情勢の展望（2025 年４月） ＜概要＞|日本銀行|

この文書で構造推定系が出した見出しは、末尾の「以 上」1 個だけでした。段組のレイアウトが、複数列を持つ 1 つの表として解釈されたためです。

変換方法を変えて直る崩れと、変えても直らない崩れ

変換のやり方を変える価値があるかどうかは、崩れの原因によって変わります。

大まかな傾向として、「表が出るか出ないか」は方法を変えれば変わります。「出た表が正しいか」は、元の PDF に構造情報がなければどの方法でも推定のままなので、変えても保証は得られません。

自分の PDF がどちらの崩れ方をするかは、実際に通してみるのが確実です。PDF to Markdown はブラウザの中だけで変換するので、ファイルをどこかへ送らずに手元の PDF で確かめられます。

崩れた表を直す

変換結果は必ず原本と照合する

表を含む PDF を変換したら、結果をそのまま使わず、原本と突き合わせてください。崩れ方 2 は見た目で気づけないため、この照合が唯一の検出手段になります。

照合の順番は次のとおりです。

1. 行数と列数が原本と一致しているか数える
2. ヘッダー行の項目名が、原本の並び順と同じか確認する
3. 各行の先頭のセルと末尾のセルを原本と比べる。ずれは端に出やすいためです
4. 結合セルがあった箇所を個別に見る。結合は Markdown の表では表現できないので、必ず何らかの形で変形されています

数値の表は作り直したほうが速い

金額や集計値のように、1 セルのずれが意味を変える表は、直すより作り直すほうが確実です。原本の表をコピーして表計算ソフトに貼り、CSV として書き出してから Markdown の表に変換すると、セルの対応関係が保たれます。

Markdown の表の記法そのもの（パイプの置き方、区切り行、配置指定、セル内のパイプのエスケープ）は Markdown 表の書き方 にまとめてあります。表の記法は CommonMark の本体ではなく GitHub Flavored Markdown の拡張として定義されているので（GFM 仕様の Tables extension別タブで開きます）、貼り付け先が対応しているかも合わせて確認してください。

崩れにくい PDF の見分け方

これは保証ではなく、崩れる確率を下げるためのチェックリストです。

変換する前に見るところ

• PDF ビューアで表の中の文字をドラッグして選択できるか。選択できなければ文字情報がなく、変換の対象になりません
• 表に罫線が引かれているか。罫線のない表は、セルの区切りを推定する手がかりが減ります
• ページが 1 段組か。2 段組や 3 段組のレイアウトは、段組そのものが表と解釈されることがあります
• 表がページをまたいでいないか。またいでいる表は、ページ単位で別々の表として出ることがあります
• 結合セルがあるか。結合セルは Markdown の表に対応する書き方がないため、必ず変形されます
• 表の中に図やアイコンが混ざっていないか。図の中の文字は表のセルとして拾われることがあります

変換した後に疑うところ

• 列数が行によって違う。区切りの推定が行ごとにぶれた跡です
• 空のセルが不自然に多い、または区切り行の直前に ||||| のような空だけの行がある
• 見出しの数が異様に多い。本文行が見出しとして扱われた可能性があります
• 意味の通らない単語が並んでいる。実測の DENTIFY のように、文字が分断された跡かもしれません
• 表の中に、明らかに本文である長い文が入っている

スキャンした PDF は文字情報を持たないため変換できません

紙をスキャンして作った PDF は、ページ全体が 1 枚の画像です。人間の目には文字が見えていても、ファイルの中に文字のデータは入っていません。この場合、表が崩れるという話以前に、抽出できる文字がありません。

必要なのは変換ではなく文字起こし（OCR）です。FormatArc の PDF ツールは OCR を持たないため、この種の PDF は変換できないことを表示して、推測で作った出力を返さないようにしています。誤った内容が出てくるより、変換できないと分かるほうが安全だという判断です。

自分の PDF がスキャンかどうかは、ビューアで文字をドラッグしてみれば分かります。選択できなければ画像です。

よくある質問

別の変換ツールを使えば表は直りますか

崩れの原因によります。表が 1 つも出てこない場合は、表構造を推定する方法に変えれば表の形にはなります。セルの割り当てがずれている場合は、元の PDF に構造情報がない限りどの方法でも推定なので、直る保証はありません。

Tagged PDF なら表は崩れませんか

タグが正しく付いていれば、Table / TR / TH / TD という構造をそのまま読めるため、推定に頼らずに済みます。ただしタグの有無は PDF の作成者側の設定で決まり、読む側では選べません。またタグが付いていても、内容が実際の見た目と一致しているかは別の問題です。

スキャンした PDF を変換できますか

FormatArc ではできません。スキャンした PDF は文字情報を持たず、文字起こし（OCR）が必要になるためです。このツールは OCR を持たないので、その旨を表示して変換を行いません。

表だけを取り出す方法はありますか

PDF から表だけを切り出す機能はありませんが、原本の表を選択してコピーし、表計算ソフト経由で CSV にしてから Markdown へ変換すると、セルの対応関係を保ったまま移せます。数値の表ではこちらのほうが確実です。

まとめ

PDF の表が Markdown で崩れるのは、PDF が見た目の表を再利用できる構造として持っていないことが多く、変換ツールが文字と線の位置から推定するしかないためです。実測では、表を作らずに散文にする崩れ方と、表の形にはなるがセルの割り当てを誤る崩れ方の両方が出ました。後者は見た目で気づけないため、表を含む PDF を変換したら結果は必ず原本と照合してください。

手元の PDF がどう変換されるかは PDF to Markdown で試せます。ファイルはブラウザの中だけで処理され、どこにも送信されません。