結合セルを含む表の抽出が崩れる理由
よくある4つの原因と修正方法

こんな症状、ありませんか？

このページをご覧になっているということは、今まさに以下のような状況に直面しているのではないでしょうか。

• データがあるべき列が空白。 結合されたカテゴリラベル（「第1四半期売上」）が3行にまたがっている — 1行目にテキストがあり、残り2行は空欄。
• データが誤った列に混入。 「金額」に属する値が、結合ヘッダーによる列境界の誤認識で「説明」列に紛れ込んでいる。
• 列ヘッダーが欠落または乱れている。 「商品詳細」が5列にまたがる2行ヘッダーブロック — 抽出時に1列に圧縮されてしまった。
• 行数が合わない。 元データは14行なのに出力は9行、またはその逆。結合行の境界を誤ってカウントしたため。

これらの症状はそれぞれ異なる根本原因に起因します。朗報は、どのパターンが原因か特定できれば、修正は簡単だということです。

全体像：なぜセル結合が抽出を阻むのか

テーブルとはグリッドです — 行と列で構成され、各セルが一つの値を保持します。セル結合は隣接するセルを一つの視覚的単位にまとめます。画面上では一つの大きなセルに見えますが、内部構造では依然として個別のセルとして扱われ、そのうち一つだけが実際にデータを持ちます。

この見た目と構造上の実態のギャップこそ、抽出ツールがつまずくポイントです。従来のOCRでもビジョンAIモデルでも、抽出エンジンは「この視覚的な結合範囲を、どうやってきれいなグリッドにマッピングするか？」を判断しなければなりません。その判断が誤ると、問題が発生します。

根本原因1：行単位のOCRでは2次元構造を処理できない

症状

テキスト自体はすべて存在するが、行と列の対応関係が崩れる。「部品A | 12.50ドル | 3 | 37.50ドル」となるべき行が「部品A | 12.50ドル | 」となり、残りの値が次の行に押し出される。複数行にまたがるセル結合があると、出力に空白行が発生する。

根本原因：座標の断片化

従来のOCRエンジンは文書を順次処理する——上から下へ行を、左から右へ単語を読み進める。これは段落には有効だが、表の場合、各テキストブロックを独立した行として扱い、列を定義する垂直方向の整列を理解しない。

具体例を示す。3行にまたがる結合セル「事務用品」を含む発注書を考える。

行ベースのOCRエンジンはこれを次のように読み取る：

行1：「事務用品」｜「ノート」｜「10」｜「3.50ドル」
行2：「ペン（箱）」｜「5」｜「8.00ドル」
行3：「ホッチキス」｜「2」｜「12.00ドル」

何が起きたかお気づきだろうか。「事務用品」は行1でその行の実際のデータと一緒に読み取られた。OCRが同じ垂直位置で見つけたからだ。行2と行3では、OCRエンジンは「事務用品」がまだそれらの行に適用されることを認識しない——物理的にテキストが存在しないからだ。結果として、カテゴリ列が行2と行3で空欄になり、カテゴリ別にグループ化する下流の分析が破綻する。

解決策

前処理：抽出前に結合セルの境界を検出する。 ImageToTable.aiを含む一部のツールは、テキストを読み取る前に、まず文書レイアウトを分析し、結合範囲を含む表のグリッドを特定します。完全な2次元構造を事前に把握することで、抽出エンジンは「事務用品」が1行目から3行目までを占めていることを認識し、出力の3行すべてにその値を反映できます。現在のツールがこれを行わない場合は、OCRやテキスト抽出の前にレイアウト分析を独立したフェーズとして実行するものを探してください。これが行ベースの抽出からの最大の改善点です。

根本原因2：スパンのあいまいさ — どこにでも属するセル

症状

結合された列ヘッダーにより、データが誤ったヘッダーの下に表示される。例えば、「製品詳細 | Q1 | Q2 | Q3 | Q4」というヘッダーを持ち、「製品詳細」が2つのサブ列（「品目」と「SKU」）にまたがる表で、抽出結果が2つのサブ列を1つにまとめてしまったり、値を重複させたりします。

根本原因：スパンのあいまいさ

結合セルが複数の列にまたがる場合、抽出ツールは「このセルは列1、列2、それともすべての列に属するのか？」を判断する必要があります。人間の目には明らかに見えても、アルゴリズムにとってはあいまいです。

これは、パッチベースの分析を使用するビジョンAIモデルで特に厄介です。これらのモデルは画像を小さなタイルに分割し、それぞれを独立して分析します。5列にまたがる結合セルは複数のタイルに断片化されます。各タイルは結合セルの一部しか見えず、モデルはそれらをつなぎ合わせる必要があります。これは継ぎ目ごとにエラーを引き起こす作業です。表再構築における実際の障害を分析したMediumの記事は、まさにこの問題を指摘しています。画像をパッチに分割するビジョンモデルは、「表のように、全体的な連続性に依存するオブジェクトに対してパフォーマンスが低い」と述べています。

解決策

期待される構造に合わせて抽出を設計する。 ソース文書に「商品詳細（アイテム｜SKU）」のようなヘッダーがあることがわかっているなら、ツールに階層を推測させるのではなく、それに合わせて「アイテム」と「SKU」という列名を定義しましょう。ImageToTable.aiのようなカスタム列抽出機能を持つツールでは、必要な列を正確に指定できます。AIは各フィールドの意味を理解することで、セルの結合範囲を推測するのではなく、文書内の適切なサブ列に各列をマッピングします。これにより、曖昧さの問題を完全に回避できます。「この結合セルの幅はどのくらいか？」とツールに問う代わりに、「これらが必要な列です。文書内でそれらを見つけてください」と指示するのです。

根本原因3：不規則な行の高さがリズムを崩す

症状

抽出されたテーブルの行数が多すぎる、または少なすぎる。テーブルの全幅にまたがるセクション小計行が新しい行としてカウントされたり（グリッドが拡張）、完全にスキップされたり（グリッドが縮小）します。抽出されたテーブルの総行数がソースと一致しません。

根本原因：行の高さのばらつき

ほとんどのテーブル抽出アルゴリズムは、水平線や空白のギャップを検出して行の境界を識別します。複数行にまたがる結合セルは、視覚的な高さのパターンを変化させます（結合されたコンテンツがより多くのスペースを必要とするため高くなるか、空の結合領域のため低くなります）。どちらの場合でも、行境界に関するアルゴリズムのヒューリスティックが混乱します。

これは、結合セルが対角線上の境界を作る階段パターンで特に一般的です。アルゴリズムは一貫性のない高さを認識し、ブロック全体を1つの大きな行として扱うべきか、分割すべきかを判断できません。

解決策

後処理：期待される構造と行数をクロスチェックする。 抽出後、簡単な健全性チェックを実行します。データ行の数は期待通りですか？すべての請求書に3～12行の明細セクションがあることがわかっている場合は、その範囲外の出力にフラグを立てます。Excelでは、簡単なCOUNTAチェックやピボットテーブルを使用して、バッチ間で行数を検証できます。より高度なツールには、抽出された構造を期待される行数や列数と自動的に比較し、手動レビューのために不一致を強調表示する組み込みの検証機能があります。

根本原因4：後処理の検証不足

症状

抽出は成功したように見える — エラーもタイムアウトもない — が、データを使おうとすると、値が誤った行や列に入っていることに気づく。このエラーは無音であり、抽出失敗よりも危険である。

根本原因：後処理の崩壊

多くの抽出ツールには、検出されたテキストブロックをグリッドにマッピングする最終組み立てステップがある。結合セルが上流で問題を引き起こした場合（座標の断片化、スパンの曖昧さ、行の高さの混乱）、後処理ステップはしばしば、セルを折りたたんだりパディングして長方形グリッドに適合させることで、それらを隠蔽しようとする。ここで無音のデータ破損が発生する：ツールは空のセルを隣接する値で埋め、列全体を左右にシフトし、決定したグリッド形状に合わない行を削除する。

具体的なメカニズム：後処理プログラムは、検出されたセル数から推測されたターゲットグリッド形状（例：4列×15行）を持つ。結合セルが異常を生み出した場合 — 例えば、本来4×16=64グリッドであるべきところを63セル検出 — エンジンはギャップを埋めなければならない。空白で埋めるツールもあれば（「空セル」症状の原因）、詰め込むツールもある：63セルを64スロットに再配分し、1つのデータ値を誤った列に押し込む。

修正方法

抽出後の検証を徹底する。 手動でも自動でも、結合セルを含むドキュメントからの抽出バッチごとに、クロスチェックステップを含めるべきである。最も実用的な方法：抽出したテーブルをエクスポートし、ExcelやGoogleスプレッドシートの組み込み「セルの結合を解除」機能を使って残っている結合セルを解除し、次に「フィルダウン」を使って新しく空になったセルに値を伝播させる。これにより、元のソースに対して検証可能なクリーンな長方形グリッドが得られる。

実際に効果のある3つの修正方法

上記の4つの根本原因に基づく、最も簡単なものから最も徹底的なものまでの実践的な修正手順です。

エスカレーションのタイミング：自動修正が不可能な結合セル

一部の結合セルパターンは、高度なAIでも修正が困難です。以下のケースでは、抽出の修正を試みるよりも、手動でソースドキュメントを前処理することを検討してください。

• ネスト結合（同一セル内のrowspan + colspan）： 3行かつ2列にまたがるセルは、どのツールでも完全には補完できないグリッドの穴を生みます。抽出前にドキュメントをより単純なテーブルに分割すると、良好な結果が得られることが多いです。
• 階段状の結合パターン： 行1が列A-B、行2が列B-C、行3が列C-Dを結合するような斜めの境界線は、ほとんどの抽出エンジンを破綻させます。最も効率的な対策は、抽出前にソースアプリケーションでドキュメントをフラットテーブルとしてエクスポートすることです。
• ページをまたぐ結合セルを含む複数ページのテーブル： 最良のツールでも困難です。各ページを個別に処理し、結果を手動で結合することを検討してください。

正直な回答：複雑なネスト結合や階段状の結合を含むドキュメントを月に50件以上処理する場合、これらのパターンをネイティブで処理できるツールへの変更によるROIを計算する価値があります。散発的なドキュメントの場合は、不良出力に悩むよりも、抽出前の手動前処理の方がコストが低くなります。

よくある質問

AI抽出は従来のOCRより結合セルをうまく処理できますか？

はい — ただし完璧ではありません。ビジョンAIモデルはドキュメントを行単位ではなくレイアウト全体として分析するため、行ベースのOCRよりも正確に結合セルの境界を識別します。しかし、パッチベースの分析により結合セルがタイル間で断片化される可能性があるため、スパンのあいまいさはAIモデルにとって依然として課題です。ImageToTable.aiのようにレイアウト分析とセマンティックフィールドマッチングを組み合わせたツールは、従来のOCRよりもはるかに優れた結合セル処理を実現しますが、特にネストや階段状のパターンに対しては100%の耐性があるわけではありません。

Excelで結合セルの抽出エラーを再処理せずに修正できますか？

はい、ほとんどの行結合パターンで可能です。列を選択し、ホーム → 結合して中央揃え → セルの結合を解除に進み、空白セルを選択してCtrl+D（フィルダウン）を押して値を伝播させます。列結合パターンの場合は、区切り位置やフラッシュフィルを使用します。これは応急処置として機能しますが、バッチ処理の場合は抽出元で修正してください。

PDFの結合セルはExcelの結合セルと同じ問題ですか？

構造的には同じです。しかし、PDFは単純に「結合を解除」できないため修正が困難です。PDFの結合セルはページレイアウトに組み込まれているため、ソースではなく抽出時点で修正する必要があります。

元のドキュメントに結合セルのように見える罫線があるが、実際は違う場合はどうすればよいですか？

これはよくあることです。薄いまたは途切れた表の罫線は、特にスキャン画像で別々のセルが結合しているように見えることがあります。画像を前処理してコントラストを高めてみてください。これにより、薄い罫線が検出可能になります。具体的なテクニックについては、検出精度向上のための画像前処理ガイドをご覧ください。

ツールが「テーブル抽出完了」と表示するがデータが間違っているのはなぜですか？

これは根本原因4です。後処理プログラムが検出されたテキストをグリッドに組み立てましたが、結合セルが原因で上流でエラーが発生し、それがフラグされませんでした。「成功」とは長方形のグリッドが生成されたことを意味し、グリッドが正しいことを意味するわけではありません。常にサンプル出力を検証してください。検証ワークフローの構築については、テーブル抽出の総合トラブルシューティングガイドをお読みください。