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

根本原因：OCRは表ではなく行を読み取る

OCRエンジンは文書をスキャンし、1文字ずつ識別します。これらを単語、そしてテキスト行へと読み順に組み立てます。これは基本的に段落向けに設計された線形的な行単位の処理であり、表計算には適していません。

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

原因その1 — 行単位のスキャン vs. 二次元の表

症状：表が1つの連続した段落として抽出される。「品目 数量 単価 Widget A 2 100 Widget B 1 200 合計 400」— すべてが1行に並び、列の区切りがない。

根本原因：エンジンが最初の行で「品目」を読み終えると、「数量」「単価」、そして改行、さらに「Widget A」「2」「100」へと、すべてフラットな順序で進みます。「品目」「Widget A」「Widget B」が同じ列に属することを認識しません。なぜなら、列をまったく認識せず、改行で区切られた単語の流れとしてしか見ていないからです。

修正方法：

• お使いのツールに「表」または「スプレッドシート」モードがあるか確認する。一部のOCRエンジンには文書タイプの切り替え機能があります。「文書」から「表」に切り替えると、エンジンがグリッドレイアウトを想定し、内部処理パスが変わります。
• 表を二次元構造として処理するツールを使用する。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出力はすべてが1つの塊にまとまるか、存在しない場所にランダムな列区切りが作成される。

根本原因: 多くのOCRエンジンは、テーブル構造を検出するためのアンカーポイントとしてグリッド線（セル間の目に見える境界線）を使用します。アルゴリズムは連続した垂直線と水平線を探し、セル境界を定義し、各領域内のテキストを読み取ります。最新の請求書、財務サマリー、HTMLエクスポートによく見られる、これらの線がない場合、エンジンは空白パターンから列を推測する方法にフォールバックします。「Item」と「Description」の間の1つのスペースは、OCRエンジンにとっては意図的な列の隙間と同じように見えます。

修正方法:

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

原因その4 — マルチカラムレイアウトが誤った行を生成する

症状: 2つの独立した表が横に並んでいる、またはメインの表の右側にサマリーパネルがある文書。抽出結果では、両方の表の行が混ざり合い、無意味なデータになります。

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

修正方法:

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

原因その5 — 回転または傾いた表が列の関連付けを破壊する

症状: 表がわずかに斜めに撮影された、またはページが傾いて読み込まれた。抽出データのテキストは正しいが、値がずれている — 「合計」列にあるべき数値が「税」列に表示される。

根本原因: 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」が別々の列になるなど、表記のバリエーションごとに列が作成される。

修正方法：

• 事前にヘッダーを統一する。ツールが対応していれば、「日付」「説明」「数量」「単価」「合計」などの標準列マッピングを定義し、検出したヘッダーをこれらの正規名にマッピングするようエンジンに指示する。
• 意味ベースの列定義で抽出するツールを使う。既存のヘッダーを読み取る代わりに、カスタム列抽出では出力したい列を定義し、AIがドキュメント上の呼称に関係なく該当データを見つける。これがAIによるExcelへのテーブル抽出の仕組みです。必要なデータを指定すれば、ヘッダーテキストの一致ではなく意味に基づいてツールがデータを見つけます。
• 後処理用のマッピングテーブルを適用する。ExcelやGoogleスプレッドシートでヘッダーのバリエーションを標準名に統合するルックアップテーブルを作成し、抽出のたびに適用する。

エスカレーションのタイミング：ツール自体に問題がある場合

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

結合セル、罫線のない表、マルチカラムレイアウト、不統一なヘッダーを含む書類（実際の業務書類のほとんどが該当）を週に20～30件以上処理する場合、手作業による修正がOCRの時間節約効果を上回ります。その時点で、表を二次元構造として扱うビジョンベースの抽出ツールへのアップグレードは贅沢ではなく、数学的に見てより低コストな選択肢です。

よくある質問