OCRが表を認識しない？
列がずれる6つの根本原因

根本原因：OCRは行を読むものであり、テーブルを読むものではない

OCRエンジンはドキュメントをスキャンして個々の文字を識別します。文字を1つ、数字を1つずつ読み取ります。それを単語にまとめ、次に行として読み順に並べます。これは根本的に線形で行ごとの処理であり、段落向けに設計されたもので、スプレッドシート向けではありません。

テーブルは2次元構造です。「$450.00」という値はそれだけでは意味を持ちません。「Widget B」の行の「Total」列の下にあるから意味を成します。セルとその列ヘッダーの関係は空間的なものであり、順次的なものではありません。OCRは「$450.00」をテキストとして読み取りますが、この数字が3列目・2行目に属することを理解する仕組みを持ちません。一部のツールはOCR完了後にスペースと配置からテーブル構造を推測しようとしますが、推測はレイアウトが完璧でない場合に失敗する当て推量に過ぎません。以下の6つの原因は、その推測が崩れるシナリオです。

原因 #1 — 行ごとのスキャン vs. 2Dテーブル

症状：テーブルが1つの連続した段落として抽出される。「Item Qty Price Widget A 2 100 Widget B 1 200 Total 400」— 列の区切りがなく、すべて1行になる。

根本原因：エンジンが1行目の「Item」を読み終えると、「Qty」「Price」と進み、改行の後「Widget A」「2」「100」と続きます。すべてフラットな並びとして読み取られます。「Item」「Widget A」「Widget B」が同じ列に属することは認識されません。そもそも列を認識していないからです。改行で区切られた単語の流れに過ぎません。

修正方法：

• お使いのツールに「テーブル」または「スプレッドシート」モードがあるか確認する。一部のOCRエンジンにはドキュメントタイプの切り替えがあります。「ドキュメント」から「テーブル」に切り替えると、エンジンにグリッドレイアウトを想定させ、内部の処理経路が変わります。
• テーブルを2D構造として処理するツールを使う。ImageToTable.aiのような最新のビジョンベースの抽出ツールは行ごとに読み取るのではなく、ページ全体のレイアウトを一度に分析し、列・行・セルの境界を特定してからテキストを抽出します。これが従来のOCRとビジョンAIの違いです。前者は文字を順番に読み取り、後者はページを空間マップとして理解します。
• 一時的な回避策として、ゾーンOCRを使う。ツールで各列の矩形ゾーンを定義できる場合、それらを個別に抽出できます。ただし、テーブルのレイアウトが変わるとすぐに機能しなくなります。

原因2 — 結合セルが構造を失う

症状: 「ウィジェットA — 10個 — $45.99」と表示されるべき行が「ウィジェットA 10個 $45.99」となり、どの値がどの列に属するか判別できません。また、2列にまたがるヘッダーセルがあると、後続のすべての行が1列右にずれます。

根本原因: 結合セルは、見た目と実際のデータ構造の間にギャップを生み出します。セルが視覚的に3列にまたがっている場合、実際のデータは1つの位置にしか存在しません。OCRエンジンは結合されたラベルを一度読み取りますが、その下の3列にどう分配するかを判断しなければなりません。ほとんどのエンジンは、またがるすべての列に値を複製するか、すべて左寄せにまとめるか、またがる領域を空白のままにするかのいずれかで、いずれも出力を壊します。

修正方法:

• 出力メタデータを確認する。 一部のツールは生のJSON出力でrowSpanやcolSpanを返します。ツールがJSONエクスポートに対応している場合は、これらの値を確認してください。エンジンが結合を検出したかどうかがわかります。
• 文書を前処理する。 ソースファイルを管理できる場合は、OCR実行前に結合セルをラベル繰り返しの個別セルに変換してください。一部のPDFエディタには「セルの結合解除」機能があります。
• 意味ベースの抽出に切り替える。 位置マッピングに頼る代わりに、カスタム列抽出を使用するツールでは、必要なもの（例：「品目説明」「数量」「単価」）を定義でき、AIが意味を理解して各値を特定します。結合セルはこのアプローチを妨げません。AIは罫線ではなく内容を読むからです。

原因3 — 罫線がないとエンジンが推測に頼る

症状: テーブルに目に見える境界線がなく、空白だけで列を示している。OCR出力がすべてをひとまとめにしてしまうか、存在しない列区切りをランダムに作ってしまう。

根本原因: 多くのOCRエンジンは、セル間の目に見える境界線である罫線をアンカーポイントとしてテーブル構造を検出する。アルゴリズムは連続する縦線と横線を探し、セルの境界を定義し、各領域内のテキストを読み取る。最新の請求書、財務サマリー、HTMLエクスポートによく見られる、こうした罫線がない場合、エンジンは空白パターンから列を推測するしかない。「Item」と「Description」の間のスペース1つが、OCRエンジンには意図的な列ギャップと同じに見える。

修正方法:

• 最低300 DPIでスキャンする。 高解像度にすると空白の境界が鮮明になり、位置ベースのヒューリスティックが少しうまく機能する。罫線を作るわけではないが、エンジンにより多くのシグナルを与える。
• 「罫線なしテーブル」モードを有効にする。 一部のOCRエンジンには、罫線のないテーブル専用モードがあり、線検出から配置ベースの推論に切り替わる。
• レイアウト認識型抽出を使用する。 ビジョンモデルは空間関係を意味的に理解する。「Qty」の下の数字の列は、縦線ではなく文脈で認識できる。これがOCR精度が文書タイプによって異なる理由だ。従来のOCRは、すべての文書が備えているわけではない視覚的特徴に依存している。

原因4 — マルチカラムレイアウトが誤った行を作る

症状: 文書に2つの独立したテーブルが並んでいたり、メインテーブルの右側にサマリーパネルがある。抽出結果が両方の行を交互に混ぜ合わせ、意味不明なデータになる。

根本原因: OCRは左から右、上から下への読み順でスキャンする。ページに複数のコンテンツカラムがある場合（左に行項目、右に価格サマリー）、エンジンは左カラムの1行目を読み、右カラムに移り、また左の2行目に戻る。「これは別のテーブルだ」という概念はなく、さまざまな位置にテキストが存在するという認識しかない。

修正方法:

• 領域選択で一度に1つのテーブルを抽出する。 各テーブルの周囲に境界を個別に定義し、別々のアップロードまたはゾーンとして処理する。
• ページレベルのレイアウト分析を使用する。 ビジョンベースのツールはまずページ全体を分析し、個別のコンテンツブロックを特定してから、それぞれから独立してテキストを抽出する。これにより、メインテーブルとサイドバーのサマリーの分離が保たれる。
• 読み順を単一領域に制限する。 一部のエンジンでは、セクション間のジャンプを防ぐことができる。

原因5 — 回転・傾いたテーブルで列の関連付けが崩れる

症状: テーブルが少し斜めに撮影された、またはページが傾いてスキャンされた。抽出されたデータのテキストは正しいが値がずれている — 「Total」列にあるべき数字が「Tax」列に表示される。

根本原因: OCRエンジンには、読み取り前にページをまっすぐにする傾き補正ステップが含まれる。しかし、傾き補正はテキストの角度を補正するだけで、列の整列は補正しない。傾き補正後も、エンジンは垂直投影プロファイル（ピクセル密度ヒストグラム）を使って列の境界を決定する。3度の回転で投影が圧縮され、境界がにじんでしまう。エンジンは「$12,450.00」を本来あるべき列4ではなく列3に配置し、2行目以降のすべてのセルも同じずれが生じる。

修正方法:

• OCR前に強い傾き補正で前処理する。 ソースファイルの準備の詳細は、前処理ガイドを参照。
• ドキュメントのフレーミングをガイドするキャプチャアプリを使う ことで、撮影時の傾きを減らす。
• ピクセル投影に依存しないツールを選ぶ。 ビジョン言語モデルは画像全体を総合的に処理する — 斜めに撮影されたテーブルも人間の目には理解可能であり、VLMベースの抽出も同じように機能する。

原因6 — 一貫性のない列ヘッダーがデータのマッピングずれを引き起こす

症状: 抽出されたスプレッドシートにはデータがあるが、ヘッダーが重複または不一致になっている。「Invoice Date」があるファイルでは「Date」、別のファイルでは「Issued」になる — マージされた出力では日付が2つの列に散らばる。

根本原因: OCRは意味を理解しない。「Invoice Date」「Date Issued」「Issued On」が同じ意味だと判断できない。各ヘッダーを文字通りの文字列として読み取り、列キーとして使用する。複数のベンダーのドキュメントを処理すると、エンジンは表現のバリエーションごとに別々の列を作成する — 「Qty」と「Quantity」が1つの列ではなく2つの列になる。

修正方法:

• 事前にヘッダーを正規化する。 ツールが対応していれば、標準の列マッピングを定義する — 例：「Date」「Description」「Qty」「Unit Price」「Total」— そしてエンジンに、見つけたものをこれらの標準名にマッピングするよう指示する。
• 意味的な列定義で抽出するツールを使う。 既存のヘッダーを読む代わりに、Custom Column Extraction で出力したい列を定義し、AIがドキュメント内のフィールド名に関係なく対応するデータを見つける。これがAIによるExcelへのテーブル抽出の仕組みだ：欲しいものを指定すれば、ツールはヘッダーテキストの一致ではなく意味で見つける。
• 後処理のマッピングテーブルを適用する。 ExcelやGoogle Sheetsでヘッダーのバリエーションを標準名に統合するルックアップテーブルを作成し、各抽出実行時に適用する。

エスカレーションのタイミング：ツール自体が問題ですか？

上記の修正で結果は改善できます — 前処理の向上、高DPI、領域選択など。しかし、これらはすべて同じ限界への回避策にすぎません。従来のOCRはテーブルを読むために作られていません。毎バッチで3つ以上を適用しているなら、ツール自体がボトルネックです。

結合セル、罫線なしテーブル、複数列レイアウト、不統一なヘッダーを含む文書 — つまり実際のビジネス文書のほとんど — を扱い、週に20〜30件以上処理している場合、手動での修正作業がOCRによる時間節約を上回ります。その時点で、テーブルを2次元構造として扱うビジョンベースの抽出ツールへのアップグレードは贅沢ではなく、数学的に見てより安価な選択肢です。

よくある質問