なぜPDFからWordへの変換で書式が崩れるのか
多くのユーザーが気づいていない深刻な問題

PDFは段落を保存しない

Microsoft Wordは文書を意味要素の階層として保存します。見出し、段落、番号付きリスト、3列の表といった構造です。各要素は独自の書式ルールと周囲の要素との関係を持ちます。段落に文章を追加すると、Wordは段落とは何かを理解しているため、ページレイアウトをゼロから再計算します。

PDFはそのような情報を一切保存しません。

PDF仕様書（ISO 32000-1:2008、この形式を定義する国際規格）では、ページを描画命令の連続として記述します。PDF内のテキスト要素は「段落3、文2」ではありません。代わりに「文字'A'を座標(124.5, 356.2)にHelvetica 10ptで描画、続いて文字'c'を(131.8, 356.2)に、続いて'c'を(137.2, 356.2)に...」という形式です。各文字はページ上に独立して配置されます。PDFは、どの文字がどの単語に属するか、どの単語がどの行に属するか、どの行が段落を形成するか、どの段落が見出しかという情報を一切保存しません。

広く引用されているPDF技術入門書はこれを率直に述べています。「PDFは段落、書式、ヘッダー、フッター、インデント、単語の分割（改行）を認識しない。テキストは最小で1文字、最大でも1行の断片に分解される。」

タグ付きPDF（ISO 32000の条項14.8で定義）と呼ばれるオプションの拡張機能があり、見出しレベル、段落境界、表のセマンティクスなどの論理構造をPDFファイルに埋め込むことができます。しかし、タグ付きPDFは主にアクセシビリティ機能であり、流通しているPDFの大部分はこれを使用せずに作成されています。Adobe自身のサポートフォーラムでも、変換品質は「PDFの構造ツリーがどれだけ適切に形成されているか」に依存すると専門家が説明しており、ほとんどのPDFには構造ツリーがないことが暗に示されています。

これが、ほとんどのPDFからWordへの変換ツールベンダーが教えてくれない最初の事実です。画面上で見える文書構造はファイル内に存在しません。すべての変換ツールは、散在する個々の文字の(x,y)座標のみを使用して、ゼロからそれを再構築する必要があります。そして、その再構築は3段階の推測の連鎖であり、各段階で前の段階の誤差が増幅されます。

3つのエラーチェーンがすべての変換を台無しにする

PDFを編集可能なWord文書に変換するには、3つの連続した再構築ステップが必要です。各ステップで、ソフトウェアは不完全な情報に基づいて判断を下します。誤った判断が次のステップに連鎖し、出力は元の文書から徐々に乖離していきます。

エラー1：文字レベルのOCR — 誤った文字の認識

スキャンされた画像ベースのPDF（テキストがピクセルとして存在し、選択可能な文字ではない場合）では、最初のステップは光学文字認識（OCR）です。これは、ページ画像の微小領域を調べ、そこに含まれる文字を識別しようとするソフトウェアです。OCRは1文字ずつ処理します。3,000文字のページでは、3,000回の独立した認識判断が行われます。

高品質なOCRエンジンでもエラーは発生します。スキャナガラス上の小さなゴミがピリオドをカンマに変えます。コントラストの低いテキスト部分では「rn」が「m」と読み間違えられます。珍しいフォントでは「I」（大文字のアイ）と「l」（小文字のエル）と「1」（数字のイチ）が区別できなくなります。OCRエンジンが99%の文字精度（優れた水準とされる）を達成しても、3,000文字のページで30文字の誤認識が発生します。

しかし、文字の誤認識は目に見える問題に過ぎません。より深い問題は、OCRがすべての文字を正しく認識した場合でも発生します。それは、各文字のページ上の位置だけを記録し、それ以外の情報を持たないことです。この位置データが次の再構築ステップに直接渡されます。

エラー2：座標再構築 — 何が何と結びつくかの推測

コンバーターが文字とその(x,y)座標のリストを取得した後、データだけでは決定的な答えが出せない一連の質問に答える必要があります。

• どの文字が単語を構成するか？物理的に近い文字は同じ単語に属する可能性が高いですが、均等割り付けされたテキストのように単語間のスペースが大きく異なる場合はどうでしょうか？小数点が前の数字よりも次の数字に近い場合は？
• どの単語が行を構成するか？おおよそ同じy座標にある単語は同じ行に属する可能性が高いですが、属する行の上の行と同じy位置にある上付きの脚注マーカーの場合はどうでしょうか？
• どの行が段落を構成するか？左マージンが似ていて垂直方向に近い行は同じ段落の可能性が高いですが、他の行より短い段落の最終行はどうでしょうか？1列目の下部が2列目の上部よりも1列目の次の行に物理的に近いマルチカラムレイアウトの場合は？

これらの判断はすべて、空間的な近接性のみに基づいて行われます。ソフトウェアはテキストの意味を理解していません。上付きの脚注引用（例：「¹⁴」）は、空間的に近いため段落テキストに統合されます。大きなテキストのサイドバーのプルクオートは、y座標が重なるため本文に混入します。コンバーターは散布図から文書構造を構築しているのです。間違いを犯さない方が驚くべきことでしょう。

エラー3：レイアウトの推測 — 存在しない構造をでっち上げる

文字が単語に、単語が行にまとめられた後、コンバーターは最も困難な課題に直面します。それは、ドキュメントのレイアウトが実際に何であるかを判断することです。この大きく太字のテキストは見出しなのか、それとも大きなフォントの1行段落なのか？画像の下にあるこのテキストブロックはキャプションなのか、それとも次のセクションの始まりなのか？この数字のグリッドは表なのか、それともたまたま列に揃っているだけのテキストなのか？

ソフトウェアは推測します。一定の間隔で繰り返される行、行と列に揃うテキスト、本文と異なるフォントサイズなど、パターンを探します。しかしこれらはヒューリスティックであり、確実性ではありません。余白が豊富で意図的なタイポグラフィが施された、よくデザインされたページは、アルゴリズムにとって曖昧なレイアウトシグナルを生成します。コンバーターは間違った推測をします。繰り返し。

これが、ほとんどの目に見える書式の崩れが発生するステップです。PDFとしては完璧に見えたドキュメントが、Wordファイルとして出力されると、テキストボックスがページ中に散らばり、それぞれが絶対位置に固定されて、編集しようとするとすぐに崩れてしまいます。これは変換の失敗ではなく、コンバーターが与えられた唯一の情報で、設計されたとおりに動作した結果です。情報が単にタスクに対して不十分なのです。

表：システム全体が崩壊する場所

3段階のエラーチェーンがテキストレイアウトの崩れ方を説明するなら、表はその壊滅的な失敗モードを表します。問題は根本的です：PDFには表という概念がありません。

PDFが表のように見えるもの（列ヘッダーとグリッド線を持つデータ行）を表示するとき、実際には独立した視覚要素の集合を描画しています。つまり、境界線用の水平および垂直の線分と、結果としてできるグリッドセル内に配置された個々のテキスト文字です。PDFファイルには、3行目「金額」列のセルと値「$1,247.00」を結びつける情報は一切含まれていません。単に「'$'という文字をX位置に、次に'1'をX+7の位置に...」というレンダリング指示と、境界線の描画指示が保存されているだけです。

つまり、コンバーターは以下を行う必要があります：

1. 線分がグリッドを形成していることを検出する — 境界線が細いか存在しない場合、必ずしも明らかではない
2. そのグリッドが何行何列かを判断する — セルの結合や列幅のばらつきで簡単に狂う
3. 各文字を正しいセルに割り当てる — 1文字の位置ずれがグリッド全体に連鎖する
4. 類似した内容のセルを結合すべきか推測する（例：2列にまたがるヘッダー）
5. 列の読み取り順序を決定する — 左から右？右から左？折り返し行はセル内で改行するのか、新しい行を開始するのか？

推測に推測を重ねた連続です。PDF解析ツールを構築する開発者たちによるHacker Newsの議論では、その感覚が的確に捉えられていました：「PDFは常に文字を順番に配置するとは限らず、個々の文字が絶対配置されていることもある。」ある開発者は、このプロセス全体を「馬鹿げている」と表現しました。

Redditでは、ユーザー体験は一貫した不満の声で溢れている。r/MicrosoftWordの投稿者は、PDFからDOCXへの変換結果を「奇妙な書式」と表現し、あらゆる修正が効かなかったと述べている。また、r/Acrobatの別の投稿者は、PDFをWordに書き出した後、「段落が奇妙なテキストボックスに分解され、編集しようとするとすべてがずれる」と報告している。r/TechnologyProTipsのあるユーザーは、長年の経験をこう総括している。「この質問は何度も受けてきた。[...] 書式が消える、云々。この文書を何日もかけてDOCXに変換しようとしているんだ。」

これらは特殊なケースではない。まったく別の目的で設計された処理工程に、本来とは異なるタスクを無理に実行させた場合の、当然の結果なのだ。

「書式を保持」ボタンはラベルであって、解決策ではない理由

どのPDF→Word変換ツールにも、「書式を保持」や「ページレイアウトを維持」といったオプションがある。Adobe Acrobatにも、Smallpdfにも、ILovePDFにもある。このオプションにチェックを入れれば、変換後の文書が元の見た目を保つ、という含みがある。

これらのオプションが実際に行っていることを理解すれば、なぜ結果が脆く感じられるのかが明らかになる。Adobe Acrobatの書き出し設定で「ページレイアウトを維持」を選択しても、変換ツールが文書の論理構造を魔法のように再構築するわけではない。代わりに、すべてのテキストをWordの絶対配置されたテキストボックスに配置する。つまり、PDFの座標系をWord文書内に再現しているに過ぎない。

開いたときの見た目は正しい。しかし、編集しようとした瞬間——単語を追加する、文を削除する、余白を調整する——レイアウト全体が崩壊する。各テキストボックスが、周囲のコンテンツではなく、ページ上の固定位置に固定されているからだ。あなたが手にしたのは編集可能な文書ではない。テキストボックスで作られたスクリーンショットなのだ。

Microsoft自身のドキュメントは、この点について異例なほど率直だ。Microsoft Q&Aの公式回答はこう述べている。「PDFをWordに変換し、Wordの適切な書式設定方法を使用させる方法はありません。それは、処理方法に1対1の対応関係がないからです。」別の回答はさらに続ける。「異なるプログラムのファイル構造から変換された文書には、常に書式の異常が含まれ、編集が非常に困難になることがよくあります。」

これはAdobeやMicrosoftがソフトウェアアップデートで修正できる限界ではない。元の形式（PDF）と目的の形式（Word）が、文書を根本的に異なる方法で表現しているという、カテゴリレベルの制約なのだ。一方は見た目を保存し、もう一方は構造を保存する。元の構造データなしに見た目を構造に変換する問題は、解決不可能であり、さまざまな失敗の度合いで近似する以外に方法はない。

当サイトのPDF→Word変換ツールの総まとめでは、同じ文書セットに対して10以上のツールをテストした。結合セルを含むテーブルでは、すべてのツールが失敗した。マルチカラムレイアウトは、程度の差こそあれ、すべてのツールで歪んだ。違いは、どれだけ修正が必要かという点だけであり、修正が不要かどうかではなかった。変換とデータ抽出が根本的に異なる操作である理由の詳細については、文書変換とデータ抽出の比較をご覧ください。

Vision AIがエラーチェーン全体を回避する仕組み

ここまで説明してきたこと、つまり文字レベルのOCR、空間再構築、ヒューリスティックなレイアウト推測は、従来のPDF変換ツールがすべて使用するパイプラインです。これは、「個々の文字とその座標のリスト」を出発点とする場合に利用可能な唯一のパイプラインです。

しかし、根本的に異なるアプローチが存在します。それは、ソフトウェアが最初に注目する対象を変えることで、エラーチェーン全体を回避します。

Vision AI、具体的には数百万のドキュメント画像で訓練された視覚言語モデル（VLM）は、文字を一つずつ読み取りません。人間と同じように、ページ全体を視覚的な単位として捉えます。OCRが次のように見るのに対し：

Vision AIは次のように見ます：

その違いは決定的です。OCRは文字の位置を生成します。Vision AIはドキュメントの理解を生成します。

Vision AIは見ているものを理解するため、ネイティブなWord文書を生成できます。つまり、配置されたテキストボックスの集まりではなく、実際のWord段落、実際のWord見出し、正しい行数と列数を持つ実際のWordテーブルです。出力は最初からWordで作成された文書のように動作します。段落にテキストを追加すれば下のテキストは自然に流れ、テーブルの列をサイズ変更すれば隣接する列が調整され、新しい見出しスタイルを適用すれば文書全体に反映されます。

これがImageToTable.aiのWordに変換モードの機能です。従来のPDFからWordへの変換ツールとは異なり、OCR→座標再構築→レイアウト推測のパイプラインをまったく試みません。代わりに、視覚言語モデルがページ画像全体（デジタルPDF、スキャン文書、スクリーンショット、印刷ページのスマホ写真など）を分析し、段落、見出し、テーブルがそのままの構造化Word文書を出力します。テンプレートも、トレーニングも、ドキュメントごとの設定も不要です。AI視覚モデルがOCRとどのように異なる方法でドキュメントを処理するかについての技術的な詳細を知りたい場合は、AIがドキュメントを読み取る仕組みのわかりやすいガイドでその仕組みを詳しく説明しています。

このアプローチにより、To Wordモードはスキャン文書とデジタルPDFを同一に扱います。どちらもビジョンモデルにとっては単なる画像です。文字認識とレイアウト理解が同時に行われるため、「OCRしてから変換」という別個のステップはありません。これは、モデルが文書の仕組みを理解していることに基づいています。OCR技術の進化と過去3年間の変化について詳しくは、OCR後の展開に関する分析をご覧ください。

その結果、従来の変換ベンダーが「フォーマット保持」ボタンで謳いながら実現できなかったことが可能になります。つまり、レイアウトを一から作り直すことなく、内容を編集できるWord文書です。レイアウトを保持した文書からWordへの変換に関する完全な技術情報（基礎的な仕組み、アプローチの比較、選択ガイドを含む）については、レイアウト保持型文書からWordへの変換完全ガイドをご覧ください。

よくある質問

スキャンPDFでも使えますか？それともデジタルPDFのみですか？

Vision AIは両者をまったく同じように扱います。スキャンPDFはページの画像であり、デジタルPDFを画面に表示したものもページの画像です。ビジョンモデルは見た目を直接処理するため、スキャン文書とデジタル生成PDFの間で出力品質に差はありません。従来の変換ツールはスキャン文書では大幅に品質が低下します。なぜなら、レイアウト再構築とは別に、まずOCRを実行しなければならず、前述のエラーチェーン全体が再び発生するからです。

手書き文書や注釈はどうですか？

Vision AIは文字の形をフォントライブラリと照合するのではなく、文脈を理解するため、OCRよりも手書き文字を堅牢に処理します。OCRは手書きのメモを、個別に解読すべき曖昧な形状の連続として扱います。Vision AIは周囲のテキストを読み、文書の目的を理解し、その文脈を使って手書きの記号を解釈します。これは人間の読者が行うのと同じ方法です。パフォーマンスは手書きの読みやすさによって異なりますが、そのアプローチはOCRとは根本的に異なります。

Word出力は本当に編集可能ですか？変更を加えると壊れませんか？

出力はネイティブのWordです。位置指定されたテキストボックスではなく、実際の段落、見出し、表です。段落にテキストを追加すると、その下の内容は自然にリフローします。表の列幅を調整することもできます。Wordスタイルを適用することもできます。文書はWordで作成されたかのように動作します。これがVision AIの出力と従来の変換ツールの出力との構造的な違いです。後者は見た目を保存しますが（編集しやすさを犠牲に）、前者は構造を保存するため（見た目が自然に追随します）。

複雑なレイアウト（マルチカラムのレポートやフォームなど）はどの程度うまく処理できますか？

Vision AIはページを座標グリッドとしてではなく、視覚的なシーンとして処理します。マルチカラムレイアウト、ラベル付きフィールドのあるフォーム、埋め込みチャートや画像を含む文書など、モデルはこれらを再構築すべき空間的な人工物としてではなく、意味的なパターンとして認識します。出力の品質は文書の明瞭さと複雑さに依存しますが、このアプローチは座標再構築手法に内在する体系的な障害モード（カラムのインターリーブ、テキストボックスの断片化）を回避します。詳細なエッジケースと制限事項については、レイアウト保存ガイドをご参照ください。