5つのPDFからWordへの変換失敗
何時間もの手直しを生む原因

OCRの罠：なぜコンバーターは文書ではなく文字を見るのか

このリストにあるすべての失敗モードがなぜ起こるのかを理解するには、一つだけ理解する必要があります：PDFとWordは根本的に互換性のない方法で文書を表現しています。

PDFは本質的にデジタル印刷物です。文字、線、ロゴなど、すべての要素を2次元平面上の固定X/Y座標を持つオブジェクトとして保存します。PDFは「H」という文字が11ptのHelveticaで位置(124, 587)にあることを「知っています」。しかし、「H」が見出しの最初の文字であること、その見出しがセクションに属していること、そのセクションが特定の情報階層を持つ文書内に存在することを知りません。これらは人間の概念であり、PDFは設計上、それらをエンコードしません。

あるRedditユーザーが述べたように：「PDFをWordに変換するのは、言語を翻訳するというより、焼き上がったケーキを小麦粉、卵、砂糖に戻そうとするようなものです。」

従来のOCR（光学文字認識）はこれをさらに悪化させます。OCRはページ上のピクセルを読み取り、既知の文字パターンと照合しようとします——しかし、座標上の文字しか見えません。PDFからWordへの変換で書式が失われる理由を理解する概念はなく、文書を理解するように設計されたことはありません。OCRはナンバープレートやスキャンされた書籍のページを読むために設計されたもので、「この段落は何を意味するのか？」という問いは問題定義に含まれていませんでした。

その結果、PDFからWordへの書式に関する苦情のほぼすべてを占める5つの繰り返し発生する失敗パターンがあります。それぞれがどのようなものか、なぜOCRがそれを引き起こすのか、そして根本的に異なるアプローチ——ビジョンAI——がどのように根本原因を排除するのかをご説明します。

失敗1：フォントの喪失と置換

どのような状態か

美しく組版されたPDF——たとえば、Calibriで太字のセクションヘッダーと斜体の財務数値を使ったクライアント提案書——を変換し、結果のWordファイルを開くとします。文書全体がTimes New Romanになっています。さらに悪いことに、フォントサイズがわずかにずれており、Wordのリフローエンジンが作動し、慎重にページ付けされた12ページの文書が14ページになり、見出しがページ下部に孤立して取り残されています。

場合によっては、ほぼ正しいが完全ではないフォントになることもあります——サンセリフの本文テキストがわずかに狭いサンセリフの代替フォントになり、すべての改行が1〜2語ずれます。文書は技術的には読めますが、その状態でクライアントに送ることはできないでしょう。

OCRが原因で起こる問題

OCRエンジンは文字の形を認識しますが、フォントは認識しません。OCRがPDFページを処理する際、既知のグリフ（様々な形の文字「a」など）に一致するピクセルパターンを認識し、対応するUnicode文字を出力します。フォントのメタデータ（使用された書体、太さ、スタイルセット）は、PDFのフォント辞書に保存されていてもOCRは無視するか、フォントがPDFに埋め込まれていない場合は完全に失われます。

Adobe自身のドキュメントでは、その後に何が起こるか説明されています。フォントが見つからないか埋め込まれていない場合、システムはMultiple Master書体（セリフ体の場合はAdobeSerifMM、サンセリフ体の場合はAdobeSansMM）で代替します。これらの代替フォントは「行やページの改行を維持するために伸縮します」が、「元の文字の形状に常に一致できるわけではありません」。その結果、構造は保持されるものの、視覚的には正しくないドキュメントが生成されます。

スキャンされたPDFの場合、問題はさらに深刻です。フォントのメタデータが存在しません。OCRエンジンはピクセルパターンから文字の正体を推測しており、フォント情報は単に復元できません。すべての文字は、コンバーターが割り当てるデフォルトのフォントになります。

Vision AIが解決する方法

Vision AIはフォント名を特定しようとはしません。代わりに、ドキュメントを視覚的に処理します。つまり、特定のテキストが周囲のテキストよりも大きく、太く、または薄く見えることを認識し、その視覚的な関係を出力に保持します。PDFで視覚的に大きく太い見出しは、Word出力でも大きく太い見出しとしてレンダリングされます。「Calibri Bold 16pt」であることを知る必要はなく、人間の読者が見る視覚的な重みの階層を再現すればよいのです。

これは根本的に異なる戦略です。OCRは「これは何のフォントか？」と問い、答えられないと失敗します。Vision AIは「このテキストは、ページ上の他のすべてのテキストと比べてどのように見えるか？」と問います。これは、人間の読者と同じ方法でドキュメントを処理するため、常に答えられる質問です。

失敗2: テーブル構造の崩壊

どのような状態か

きれいにフォーマットされたテーブル（6列にわたる四半期売上データ、結合されたヘッダーセル、小計行を含む）を含む財務レポートを変換するとします。変換後のWord文書では、各セルの内容が独立した段落になり、列の関係性が失われ、「Q1売上: $142,000」が「Q3売上: $156,000」の隣に、かつて異なる列にあったという兆候もなく配置されます。元のテーブルに目に見えない境界線（プロのレポートでは一般的なデザイン選択）があった場合、コンバーターはテーブルが存在したこと自体を検出できないことさえよくあります。

この問題についてのRedditスレッドで、あるユーザーは「テーブルは変換中に最初に壊れることが多い」と指摘しており、テーブル中心の文書では、すべてのフォーマットを削除してテーブルをゼロから手動で再構築することが最もクリーンなアプローチであるというのが一致した見解でした。それは解決策ではなく、降伏です。

OCRが原因となる理由

すべてを説明する重要な技術的詳細は次のとおりです: PDFにはネイティブの「テーブル」構造がありません。 PDF内のテーブルは、グリッド状に配置されたテキストオブジェクトの集合に過ぎず、オプションで線描画コマンドによって目に見える境界線が作成されます。「これらの6つのテキストオブジェクトが同じ行に属する」とか「このセルは2列にまたがる」といったメタデータは存在しません。

OCRベースのコンバーターは、視覚的な手がかりからテーブルをリバースエンジニアリングする必要があります: 整列したテキスト列を探し、罫線を検出し、どのセルが互いに関連するかを推測しようとします。列間隔が不規則な場合、セルが結合されている場合、境界線が見えない場合、またはセル内容が複数行に折り返される場合、推論は失敗します。各セルは、隣接するセルとの関係性のない独立したテキストブロックになります。

これが、スキャン文書をテーブルを維持したままWordに変換することがこれほど根強い課題であった理由です: OCRパイプラインはテキストストリーム用に設計されており、視覚的な座標だけから2次元のデータ構造を再構築するようには設計されていません。

Vision AI が解決する方法

Vision AI は人間と同じように表を処理します。つまり、ページを見てグリッド構造を理解します。整列したテキスト列、一貫した水平間隔、行ごとの繰り返しを検出すると、目に見える境界線の有無にかかわらず、表として認識します。個々のテキスト断片の座標だけでなく、表の視覚的な構造を理解するため、結合セル、列スパン、階層ヘッダーも保持します。

境界線のない表（事実上すべての OCR ベースの変換ツールを困難にする形式）に対して、Vision AI は特に効果的です。線検出のヒューリスティックではなく、視覚的なパターン認識に依存するため、コンテンツの配置と間隔のみから表構造を識別できます。

問題 3: 画像の位置ずれ

発生する現象

3 ページにグラフがあり、その周りに 2 段落の説明文がきれいに回り込んでいる PDF があるとします。Word に変換すると、グラフは 5 ページに移動し、無関係な本文の上に重なって表示されます。また、グラフの周りに回り込むはずだった 2 段落は、上に積み重なって乱雑なブロックになっています。さらに悪い場合、画像が単に消えてしまい、四半期業績グラフがあった場所には空白や画像切れのプレースホルダーが表示されます。

これは、マーケティング用パンフレット、図解入りの技術レポート、図とキャプションを含む学術論文など、画像の多いドキュメントで特に厄介です。必要なテキストは存在しますが、画像とその周囲のコンテンツとの関係というドキュメントの視覚的な論理が破壊されています。

OCR が原因となる理由

PDF では、画像とテキストは同じ座標空間を占有しますが、完全に別個のオブジェクトタイプとして保存されます。画像はその境界ボックスの座標とピクセルデータで定義され、周囲のテキストは独自のテキストランの座標で定義されます。「この画像はこの段落に固定されている」という明示的な関係はなく、ドキュメント作成者はその関係を意図していましたが、PDF 形式はそれをエンコードしません。

OCR はこれをさらに複雑にします。OCR エンジンはテキストを処理するように設計されており、画像は無視されるか、テキストフローにおける障害物として扱われます。コンバーターが Word ドキュメントを再構築する際、各画像をどこに配置するかを決定する必要があります。画像と近くのテキストとの空間的な関係を理解しないまま、画像を任意の位置に固定したり、配置ロジックが有効なアンカーポイントを見つけられない場合に画像を完全に削除したりすることがよくあります。

Vision AI が解決する方法

Vision AI は文書を全体的に処理します。「テキストチャンネル」と「画像チャンネル」を別々の処理ストリームとして扱い、後で調整する必要があるとは考えません。空間的な関係を持つ視覚要素が配置された1ページとして認識します。左側にテキストが回り込んだグラフは配置パズルではなく、「左側に2段組みテキストが回り込んだグラフ」という単一の視覚シーンとして理解します。

出力では、画像は周囲のコンテンツに対して正しい位置に保持されます。これは、モデルが文書を視覚的に理解するためです。まるで、見えない人にページレイアウトを説明するのと同じです。「右側に棒グラフがあり、テキストはその左側に回り込んでいます」というように。

失敗例4: 段落の結合

どのような現象か

これは最も厄介な失敗の一つです。ざっと見ただけでは見逃しやすいからです。契約書やレポートをPDFからWordに変換すると、一見すべてが正しく見えます。しかし、読み始めると問題に気づきます。段落区切りがあるべき場所に、途切れのないテキストの壁があります。本来2つか3つの論理的な段落が1つに結合され、段落区切り（Enterキー）ではなく、単なる改行（WordのShift+Enter）で区切られているだけです。インデントも消えています。議論、証拠、結論という文書の修辞的構造が、区別のないテキストの流れに平坦化されています。

法的文書ではこれは危険です。結合された段落は、条項とその例外の境界を曖昧にします。ビジネスレポートでは読みやすさを損ないます。どの文書でも、編集者は全文を読み直し、手動で段落区切りを再挿入する必要があります。これは文書を最初から打ち直すのとほぼ同じ時間がかかる作業です。

OCRが引き起こす理由

OCRは文字とその座標を記録します。段落の境界は記録しません。PDFの段落区切りは特殊文字ではなく、単に2行のテキスト間のより大きな垂直方向のギャップです。OCRエンジンはこれを「Y=540のテキスト行、Y=520のテキスト行、20単位のギャップ」として記録します。これは段落内の改行とまったく同じデータ構造で、Yオフセットがわずかに大きいだけです。

コンバーターは不可能な分類問題に直面します。18ポイントの垂直ギャップは段落区切りなのか、それとも単に行間が広いだけなのか。24ポイントのギャップとインデントは新しい段落なのか、それともセクション見出しなのか。テキストの意味を理解しないまま、コンバーターはヒューリスティックなしきい値（「ギャップがXより大きければ段落区切りを挿入」）を適用するしかありません。これは一部の文書では機能しますが、他の文書では壊滅的に失敗します。

マルチカラムレイアウトは問題を倍増させます。2つのカラムが並んでいるとき、OCRエンジンの行単位の左から右への読み取り順序は無意味な出力を生成します。カラムAの最初の行とカラムBの最初の行が連結され、次に各カラムの2行目が続きます。コンバーターはカラムを認識しません。2次元平面上の文字座標だけを認識します。

ビジョンAIが解決する方法

ビジョンAIは人間と同じようにページを読み取ります。列を認識し、インデントのパターンを把握し、段落の区切り（「一つの考えの終わり、次の考えの始まり」）と行の折り返し（「同じ考えが横のスペースに収まらない」）を区別します。文書全体のパターン（新しい段落の始まりの一貫したインデント、セクション間の広い間隔、セクション見出しの配置）を特定し、これらの視覚的な手がかりを使って文書の論理構造を再構築します。

複数列の文書の場合、ビジョンAIは各列を独立した読み取りゾーンとして処理し、その後で正しい順序（列Aの全文、次に列Bの全文）に結合します。異なる列の行を交互に混ぜることはありません。

問題5：ヘッダー、フッター、ページ番号が消える

症状

変換されたWord文書を開きます。スクロールしていくと、何かがおかしいと感じますが、すぐには特定できません。そして気づきます。PDFのすべてのページにあった「Confidential — Q3 Internal Review」というランニングヘッダーがどこにも見当たりません。ページ番号も消えています。文書参照コードが入ったフッターも消えています。元の文書のすべてのページに一貫して表示されていたこれらの要素が、変換後の出力から単に消えてしまったのです。

別のケースでは、消えるのではなく誤認識されます。ヘッダーのテキストが1ページ目の本文にランダムな文章として挿入され、「Page 3 of 12」というページ番号が3ページ目の段落の途中に、まるで文の一部であるかのように配置されます。

OCRが原因となる理由

ヘッダーとフッターは、OCRエンジンが苦手とする空間領域を占めています。理由は2つあります。第一に、ページの余白に位置しています。多くのOCRエンジンは、余白のコンテンツは情報ではなくノイズであると想定し、テキスト抽出中に低優先度として扱うか、単にスキップします。第二に、反復的であることです。同じテキストがすべてのページのほぼ同じ位置に表示されます。一部の変換ツールはこの反復を印刷のアーティファクトと解釈し、意図的に抑制します。

PDFには、「このテキストはヘッダーである」と「このテキストは本文である」という構造的な区別はありません。両方とも特定の座標に配置されたテキストオブジェクトです。変換ツールは、どのテキストがWordのヘッダー/フッターセクションになり、どのテキストが本文に残るべきかを推測する必要があります。この推測は、位置（ページの上部/下部）と反復（複数ページの同じテキスト）に関する脆弱なヒューリスティックに依存しています。これらのヒューリスティックが失敗した場合（セクションごとに一意のヘッダーがある文書、または本文テキストが誤ってヘッダーゾーンにある場合）、結果は予測不能になります。

ビジョンAIが解決する方法

ビジョンAIは、ヘッダーとフッターをその視覚的な役割によって識別します。各ページの上部または下部の余白ゾーンに一貫して配置され、ページをまたいで繰り返されるテキストです。「Confidential — Q3 Internal Review」が毎ページ同じY座標に表示される場合、それは本文ではなく、繰り返し表示されるヘッダーであると認識します。ページ番号は、その内容パターン（各ページの同じ位置にある増分する数字）と空間的コンテキスト（通常はフッターゾーンにあり、「Page X of Y」というテキストを伴うことが多い）によって検出します。

出力では、これらはネイティブのWordヘッダーおよびフッターセクションとして保持され、正しく機能します。すべてのページに表示され、ページを追加または削除すると自動的に更新され、ヘッダーとフッターとして期待どおりに動作します。

症状への対処を超えて：ツールよりもアプローチが重要な理由

一歩下がって、これら5つの障害モードに共通する点を見てみましょう。どのケースでも、根本原因は同じです：OCRは文書を文字座標として処理し、視覚情報としては処理しません。フォントは、OCRが書体メタデータを識別できないために失敗します。テーブルは、OCRが1次元のテキストストリームから2次元構造を推論できないために壊れます。画像は、OCRがそれらを要素ではなく障害物として扱うために移動します。段落は、OCRが段落間隔と行間隔を区別できないために結合されます。ヘッダーは、OCRが空間的な繰り返しパターンを認識できないために消えます。

これらは、5つの別々の修正が必要な5つの別々のバグではありません。1つのアーキテクチャ上の制限が、5つの異なる方法で現れているのです。そして、その意味は重要です：OCRパイプラインの上にパッチやヒューリスティックをいくら追加しても、これを解決することはできません。段落間隔のしきい値を調整し、テーブル検出アルゴリズムを改善し、フォント置換ルールを追加しても、基盤となる処理パラダイム（文書理解を伴わない文字認識）が変わっていないため、依然として失敗ケースに遭遇します。

ここで、ビジョンAIと従来のOCRの違いが、単なる学術的な区別以上のものになります。ビジョンAIは、文字座標から文書構造を再構築しようとはしません。文書を視覚的に見て、人間の読者がするようにレイアウトを理解します。段落は、垂直方向のギャップのしきい値ではなく、視覚的なパターンによって認識します。テーブルは、線検出アルゴリズムではなく、グリッド構造によって識別します。フォントは、書体名を調べるのではなく、視覚的なウェイト階層を再現することで保持します。

レイアウトを保持した文書からWordへの変換の完全ガイドでは、ワークフローは簡単です：文書をアップロードすると、ビジョンAIエンジンがページ全体（テキスト、テーブル、画像、ヘッダー、フッター）を単一の視覚シーンとして分析します。各要素が何であるか、そして他のすべての要素とどのように関連しているかを理解することで、編集可能なWord形式で文書を再構築します。座標データから推測するのではありません。

これはまた、同じエンジンがOCRパイプラインを完全に壊すエッジケースも処理することを意味します：スクリーンショットを編集可能なWordに変換（PDFフォントメタデータがまったくなく、ピクセルだけの場合）、または手書きと印刷コンテンツが混在する文書などです。文書を視覚的に処理する場合、ソース形式はそれほど重要ではありません。特定のツールを比較している場合は、レイアウトを保持するWord変換ツールの比較で、各アプローチがこれら5つの障害モードにどのように対処するかを詳しく説明しています。

よくある質問

PDFは完璧に見えるのに、変換後のWord文書が乱れるのはなぜですか？

PDFが完璧に見えるのは、固定レイアウト形式だからです。すべての要素が正確な座標に固定されています。Word文書が乱れて見えるのは、変換ツールが生の座標データから段落、表、書式を再構築する必要があり、その再構築は文字レベルのOCRでは本質的に情報が失われるためです。文書が画面で素晴らしく見えるのは、PDFとして実際に素晴らしいからです。編集可能な形式に変換することは、文書の論理構造をゼロから再構築することを意味し、これは根本的に異なる課題です。

PDFに全フォントを埋め込めば、フォント置換の問題は解決できますか？

フォントの埋め込みは、PDFが元々デジタルソース（Word文書をPDFとして保存し、フォントを埋め込んだ場合など）から作成された場合に役立ちます。しかし、スキャンしたPDF（紙の文書をデジタル化したもの）には、埋め込むフォントが存在しません。「テキスト」は画像の中のピクセルに過ぎないからです。OCRは文字の形を認識してUnicode値に割り当てる必要がありますが、文書がスキャンされた時点で元の書体情報は失われているため、それを復元することはできません。このような場合、ビジョンAIが書体の特定を試みるのではなく、視覚的な重みの階層を保持するアプローチが、適切にフォーマットされた出力を得るための唯一の実行可能な方法です。

オンライン変換ツールによって、特定の文書での性能が異なるのはなぜですか？

変換ツールによって、テーブル検出のヒューリスティック、段落間隔のしきい値、フォント置換ルールが異なります。行間が広い単一カラムのレポート向けに調整されたツールは、その文書タイプではきれいな出力を生成できますが、間隔が狭い複数カラムのニュースレターでは完全に失敗する可能性があります。これが、ツール間を行き来することになる理由です。各ツールは、異なる文書レイアウトの前提に合わせて調整されているからです。ビジョンAIアプローチは、レイアウト固有のヒューリスティックに依存しないため、この問題を回避します。

スキャン解像度を上げれば、PDFからWordへの変換のフォーマット問題は解決しますか？

スキャン解像度を上げる（300 DPI以上）と、OCRの文字認識精度は向上します（「0」と「O」の混同が減るなど）。しかし、このリストにある構造的な失敗は解決されません。600 DPIでスキャンしても、OCRに段落の開始位置と終了位置、テーブルセル同士の関係、出力内でのヘッダーの配置場所を教えることはできません。解像度はテキストの精度を向上させますが、レイアウトの理解は向上させません。これらは別々の能力であり、根本的に異なる処理アプローチが必要です。

Wordに変換すべきですか、それとも構造化テーブルに変換すべきですか？

出力をどう使うかによって異なります。元のレイアウトで文書を編集、レビュー、再利用する必要がある場合（修正が必要な条項を含む契約書、内容の更新が必要なレポート、テキスト変更が必要なパンフレットなど）は、Word出力が視覚的な文書を保持します。複数の文書にわたってデータを分析する必要がある場合（請求書の合計をスプレッドシートに抽出する、ベンダーの見積もりを列で比較するなど）は、構造化テーブル出力（Excel/CSV）が適切なターゲットです。当社のWordに変換 vs テーブルに変換の意思決定フレームワークでは、具体的なユースケースに基づいた選択方法を説明しています。

Vision AIは複数カラムや複雑なレイアウトの文書を処理できますか？

はい — ここがOCRとVision AIの最大の差です。OCRは左から右へ一行ずつ読み取るため、複数カラム文書では異なるカラムのテキストが混ざり、意味不明な出力になります。Vision AIは各カラムを独立した視覚ゾーンとして処理し、正しい順序で並べるため、元の読みやすさを保ちます。画像の周りにテキストが流れる文書、サイドバー、コールアウトボックスなど、非線形レイアウトにも同様に対応できます。