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のユーザーは、長年の集合的な経験を要約しました。「この質問は何度もされてきました。[...] フォーマットが消えるとか何とか。この文書をDOCに変換しようと何日も試みています。」

これらは特殊なケースではありません。これらは、私たちが求めているタスクとは根本的に異なる目的のために設計されたパイプラインの予想される出力なのです。

「フォーマットを保持」ボタンがラベルであり、修正ではない理由

すべての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への変換ツールの総合比較では、同じ文書セットに対して12以上のツールをテストしました。結合セルを含むテーブルでは、すべてのツールが失敗しました。複数カラムのレイアウトでは、すべてのツールがある程度壊しました。違いは、クリーンアップがどの程度必要かという点だけであり、クリーンアップが必要かどうかではありませんでした。変換とデータ抽出が根本的に異なる操作である理由の詳細については、当社の文書変換とデータ抽出の比較をご覧ください。

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がドキュメントを読み取る仕組みのわかりやすいガイドでその仕組みを詳しく説明しています。

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

その結果は、従来の変換ベンダーが「フォーマットを保持」ボタンで実現していると主張しながら、実際には提供できなかったものです。つまり、レイアウトをゼロから作り直すことなく、コンテンツを編集できる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はどの程度対応できますか？

Vision AIはページを座標グリッドではなく、視覚的なシーンとして処理します。複数列レイアウト、ラベル付きフィールドのあるフォーム、チャートや画像が埋め込まれた文書 — モデルはこれらを再構築すべき空間的なアーティファクトではなく、意味的なパターンとして認識します。出力品質は文書の明瞭さと複雑さに依存しますが、このアプローチは座標再構築方法に固有の体系的な障害モード（列のインターリーブ、テキストボックスの断片化）を回避します。当社のレイアウト保持ガイドでは、エッジケースと制限事項を詳しく説明しています。