結合セルを含むテーブルの
抽出が失敗するのはなぜ？よくある原因4つと修正方法

心当たりはありますか？

このページにたどり着いたということは、今まさに以下のいずれかの状況に直面している可能性が高いです。

• データが入っているべき列に空白セルがある。 3行にまたがる結合されたカテゴリラベル（「Q1売上」）— 1行目にテキストがあり、残りの2行は空欄です。
• データが誤った列にずれ込んでいる。 「金額」に属する値が「説明」に入ってしまっている — 結合されたヘッダーが列の境界検出を混乱させたためです。
• 列ヘッダーが欠落または乱れている。 2行のヘッダーブロックで「製品詳細」が5列にまたがっている — 抽出処理が1つの列にまとめてしまいました。
• 行数が合わない。 元データは14行なのに出力は9行、またはその逆 — 結合された行の境界を誤って数えたためです。

これらの症状はそれぞれ異なる根本原因を示しています。良い知らせは、どのパターンが原因か分かれば、修正は簡単だということです。

全体像: 結合セルが抽出を壊す理由

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

この視覚的な見た目と構造的な実態のギャップこそが、抽出ツールがつまずくポイントです。従来の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でその行の実際のデータと一緒に読み取られました。しかし行2と行3では、OCRエンジンは「事務用品」が依然としてそれらの行に適用されることを認識しません。物理的にそのテキストが存在しないからです。その結果、カテゴリ列が2行目と3行目で空になる抽出結果となり、カテゴリ別にグループ化する後続の分析がすべて壊れます。

修正方法

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

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

症状

結合された列ヘッダーにより、データが誤ったヘッダーの下に表示されることがあります。たとえば、「Product Details | Q1 | Q2 | Q3 | Q4」というヘッダーを持つテーブルで、「Product Details」が2つのサブ列（「Item」と「SKU」）にまたがっている場合、抽出結果は2つのサブ列を1つにまとめるか、値を重複させます。

根本原因：スパンの曖昧さ

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

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

修正方法

期待される構造に合わせて抽出を設計します。 ソース文書に「Product Details (Item | SKU)」のようなヘッダーがあることが分かっている場合は、ツールに階層を推測させるのではなく、それに合わせて「Item」や「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です。後処理プロセッサが検出されたテキストをグリッドに組み立てましたが、結合セルによって上流でエラーが発生し、それがフラグされませんでした。「成功」とは長方形のグリッドが生成されたことを意味し、グリッドが正しいことを意味するものではありません。常にサンプル出力を検証してください。検証ワークフローの構築については、テーブル抽出の包括的なトラブルシューティングガイドをお読みください。