表認識とは何か：表の中の数字を業務データに変える方法の完全整理

表認識（Table Recognition）とは、文書に描かれた表から行と列の境界および結合セルの範囲を判別し、それぞれの値がどの項目に属するかまで復元して、機械がそのまま利用できる構造データに変換する処理です。

表認識が必要な理由

文字は読めたのに数字が合いません。

文書からテキストを取り出す技術は以前からありました。印刷された文書であれば文字単位の精度が高く出ることも難しくなく、実際にテキスト類似度が高く記録された公共文書の評価事例もあります。ところが同じ評価で表構造類似度ははるかに低い水準にとどまりました。文字はほぼ読み取れているのに、その文字がどのマスにあったかを復元する部分で大きく開いたわけです。

この差が業務でどのような結果を生むかが問題です。付加価値税の申告書には大分類と中分類、区分、項目番号、金額、税率、税額が一つの表に入ります。ここで5,000,000という数字を正確に読んでも、その値が税額のどの区分に属するかが結びつかなければ業務には使えません。むしろ担当者が原本を開き直して確認することになり、作業が一つ増えます。表認識は値を読む問題ではなく、値の居場所を復元する問題です。

表認識の正確な定義：OCRと何が違うのか

OCRと表認識、三つの軸の違い

第一に、対象が異なります。OCRは画像上の文字を対象とします。表認識は文字に加えて、セルの境界線と結合範囲、ヘッダーとデータ領域の区分、そして各値が置かれた座標の関係までを併せて対象とします。罫線が描かれていない表も多いため、目に見える線だけでなく余白と揃えによって示された境界まで判別する必要があります。

第二に、目標が異なります。OCRの目標は記載された文字を漏れなく写し取ることです。表認識の目標は元の表と同じ構造を持つデータを作り出すことです。同じ表を処理しても、OCRはセル内の文字列を順に並べ、表認識は行と列の座標を持つ格子を復元したうえでその中に値を埋めます。

第三に、成果指標が異なります。OCRは文字単位の精度や類似度で測ります。表認識は表構造類似度で測ります。この指標は抽出した表を木構造に変換し、元の表の木構造とどれだけ一致するかを測るため、セルの値がすべて合っていても結合範囲が誤っていれば点数が下がります。テキスト精度だけを見て導入を決めると、表が中心の文書で想定と異なる結果になる理由がここにあります。

二つの技術は置き換えの関係にはありません。OCRが読めなかった文字は表認識でも埋められず、表認識が失敗すれば正確に読んだ文字も置き場所を失います。文字認識の上に構造復元を載せる順序が適切です。

表認識を業務に投入するために必要なこと

実運用に入る表認識の6つの条件

第一に、結合されたセルの範囲を正確に判別することです。行方向と列方向に同時に結合されたセルは、一つの値が複数行を代表する構造を作ります。ある自治体の支出金返納手続の文書では、区分列の一つの値が下の三行をすべて包含し、国費と道費の下に残額と利子が再び分かれ、その下に歳入科目と歳出科目がさらに分岐します。結合範囲を誤ると、委託事業の返還科目が直轄事業の科目に付け替わります。

第二に、多層ヘッダーで値が属する項目の経路を復元することです。官公庁様式と税務申告書はヘッダーが二段や三段に積み上がることが少なくありません。値を一つ取り出すのに必要なのは列名一つではなく、上位ヘッダーから続く経路の全体です。

第三に、表を覆う要素を処理することです。実際の受付文書では表の上に印影が押され、取り消し線が引かれ、透かしが重なります。人は印影の下の数字を自然に読み取りますが、構造を判別するモデルにとって印影はセル境界を消す妨害要素です。印影一つのために表全体の行区分がずれると、その下のすべての値の項目対応が押し出されます。

第四に、表の外側の情報とつながることです。金額の単位が表題に千円と記されていたり、注記記号で例外条件が付いていたり、合計の検証式が表の下に文章で書かれている場合が多くあります。表だけを切り出すとこの情報が失われ、値の桁が千倍ずれる事態が生じます。

第五に、構造指標で性能を測ることです。導入検討の段階で受け取る数値が文字精度だけであれば、表の性能は確認されていない状態です。表構造類似度を別途求め、自社文書で測定した値を受け取る必要があります。公共文書の評価でも表構造の復元の水準が事例ごとに大きく異なるという事実は、この指標が文書の種類によって大きく振れることを意味します。

第六に、各値の原文位置を併せて返すことです。表から取り出した値が原本のどの座標から出たかを確認できなければ、検収者は疑わしい値一つを確かめるために表全体を読み直すことになります。

表認識の実際の適用方法

出力形式を先に決めます

プロジェクトの最初の決定はモデルの選択ではなく出力形式です。表をHTMLで受け取るか、Markdownで受け取るか、JSONスキーマで受け取るかによって以降の工程がすべて変わるためです。

結合セルのある表はHTMLで受け取るほうが安全です。行結合と列結合を属性として表現できるため構造の損失がほとんどありません。Markdownは人が読みやすく言語モデルにそのまま投入しやすい一方、結合を表現する方法がないため、結合セルを値の反復で展開するか構造を諦めることになります。検索と生成に用いる文書であれば二つの形式を併せて生成しておく方式が実用的です。業務システムに値を入力することが目的であれば、最初から項目経路をキーとするJSONで受け取るほうが適しています。

文字認識ではなくレイアウト解析の上に載せます

表認識は独立した機能ではなく、レイアウト解析の結果の上で動作します。ページから表領域をまず検出し、その中で行と列の構造を判別したうえで、各セルの文字を認識する順序です。したがって前段である要素検出の精度が表の性能の上限を定めます。評価要素をすべて検出し位置も正確だった事例でも表構造類似度は低かったという点は、表領域を見つけることと表の内部を復元することが異なる難易度の問題であることを示しています。

技術方式で見ると、座標を規則で指定する方式は様式が固定された表でのみ通用します。文書の配置と文脈を併せて解釈するモデルは、罫線のない表や結合が複雑な表で差を生みます。

検収画面で構造を確認します

表認識は結果を目で見なければ品質を測りにくい処理です。セルの値の一覧だけが並んだ画面では、結合が正しく取れているかヘッダー経路が合っているかを判断できないためです。

そこで検収環境には原本画像と復元された表を並べて置き、値を選ぶと原本の該当セルが表示される構成が必要です。ここにヘッダー経路も併せて示せば、値一つがどの項目に属するかが一目で確認できます。検収者が表全体を読み直さず疑わしいセルだけを確認できるようになれば、表の多い文書でも例外中心の運用が可能になります。

日本の環境における表認識

日本の文書には、海外のソリューションが想定していない条件がいくつかあります。

まず文書の作り方です。多くの企業と官公庁でExcelのセルを方眼紙のように細かく区切った帳票が使われており、見た目は一つの表でも、内部では多数の結合セルで組み立てられています。PDFや画像に変換されると結合の情報が失われるため、原本の形式から処理できるかを確認する必要があります。

次に様式そのものの構造です。申請書や届出書は一つの表の中に項目名と記入欄、「※」で始まる注記や記入例が併記されます。表の一マスがデータではなく記入方法の案内である場合も珍しくありません。こうしたマスを値として抽出すると業務データが汚染されるため、案内文と入力値を区別する判断が併せて必要です。縦書きの見出しを持つ表もあり、読む方向の判定も欠かせません。

最後に文書の状態です。FAXで受け付けた低画質のスキャン、机の上で撮影して影が入った画像、印影が罫線に重なった書類が実際の受付箱に届きます。こうした条件では罫線が途切れたりにじんだりするため、線をたどる方式だけでは表を復元できません。

加えて、金融機関はFISCの安全対策基準を、自治体は三層の対策を踏まえてシステムを構成するため、外部APIの呼び出しが制限される場合があります。表認識を含む文書処理の全体を閉域網や社内で実行できるかが、技術検討の最初の関門になります。

よくあるご質問