OCRで小数点と通貨記号が欠落するのはなぜ？
5つの失敗モードとそれぞれの修正方法

小数点が一つ欠けるだけで、誤差は10倍になります。そして厄介なのは、他の抽出結果はきれいに見えることです。ベンダー名、日付、明細項目はすべて正しく抽出されています。しかし、最も重要な数字—合計、税額、単価—だけが、静かに1桁または2桁ずれてしまっています。その影響は決して抽象的なものではありません。$156の代わりに$15,600が計上されれば、資金が拘束され、照合作業が発生し、自動化プロセスへの信頼が損なわれます。

文書処理の研究から得られる核心的な洞察は一貫しています。小数点、通貨記号、マイナス記号などの小さな記号は、OCRエンジンの解像度の限界付近で動作するため、大きな文字よりも先に失敗するのです。これらはランダムなエラーではありません。それぞれ既知の根本原因を持つ、予測可能な障害モードに従います。どのモードに対処しているかを特定できるかどうかが、迅速な正規表現による修正と、ERPに検出されずに到達するデータ災害の違いを生みます。

この記事では、小数点と通貨記号の欠落に関する5つの異なる障害モードを取り上げます。それぞれに固有の診断サインと修正方法があります。テキストが明確に読めるのに抽出ツールが誤った数値を返す理由の全体像については、誤った抽出数値を引き起こすフィールド設計のミスに関する姉妹記事をご覧ください。その記事は曖昧な列名に焦点を当てており、この記事は記号レベルの障害に焦点を当てています。

障害モード1：エンジンが認識できないほど小数点が小さい

症状：「3.50」が「350」または「3 50」として抽出されます。「19.99」は「1999」になります。数字自体は完全に読み取れますが、小数点だけが存在しません。欠落したドットにより、スプレッドシート内のすべての数値が2桁ずれてしまいます。

発生理由：従来のOCRエンジンは、文字を読み取る前にノイズフィルター、コントラスト調整、2値化を適用して画像を前処理します。高さ8〜10ピクセルの小数点—サーマルレシート、低解像度スキャン、FAX文書で一般的—は、これらの前処理ステップのノイズフロアを下回ります。エンジンのフィルターは、2つの数字の間にある小さな点を、ほこり、紙繊維、または圧縮アーティファクトとして分類します。72 DPIでは、小数点の幅は約2〜3ピクセルです。そのサイズでは、どの2値化アルゴリズムにとっても、ほこりの粒子と視覚的に区別がつきません。

これは認識の失敗ではなく、前処理の失敗です。小数点はエンジンが確認する前に除去されるため、認識段階に到達することはありません。

修正方法：最も確実な修正は、OCRエンジンの前処理を変更しようとするのではなく、抽出後の検証です。フィールドレベルの正規表現チェックを実装し、抽出されたすべての金額が期待されるパターンに一致するかを検証します。

# チェック：この値には小数点以下2桁が正確にありますか？
pattern = r'^\d+\.\d{2}$'
if not re.match(pattern, extracted_value):
    flag_for_review(extracted_value)

正規表現を超えて、抽出された値を期待される規模と比較します。請求書の合計が通常50ドルから5,000ドルの範囲で、抽出結果が500,000ドルだった場合、整合性チェックで会計システムに到達する前にエラーを検出できます。多くの抽出ツール（ImageToTable.aiを含む）では、抽出時に金額を標準化する出力フォーマットルールを定義できます。小数点の位置は、生のOCR出力が保持しなければならないものではなく、出力スキーマの一部になります。

小数点が6ピクセル未満の極端に低解像度のスキャンでは、後処理による修正は完全には信頼できません。正直な答えは、ソース画像に正確な抽出に必要な情報が含まれていないということです。そのような場合、300 DPI以上で再スキャンすることが唯一の恒久的な解決策です。

障害モード2：先頭の数字に密着した通貨記号が欠落する

症状：「$156.00」が「156.00」として抽出される（記号が欠落）、または悪化したケースでは「$15600」として抽出される（記号と数字が単一トークンに結合され、小数点がマージで失われる）。通貨のコンテキストが消え、下流システムはUSD金額を単位のない数値として扱います。

発生理由：通貨記号（$、€、£、¥、R$）は数字とタイポグラフィ的に異なります。多くの場合、異なる書体やウェイトで設定され、数字と同じベースライン上にありますが、視覚的なプロファイルが異なります。OCRエンジンが行をトークン化するとき、「$」が数字の一部か別のエンティティかを判断する必要があります。近接ベースのトークナイザーは記号を先頭の数字と結合し、「$156」のような単一トークンを生成することがよくあります。エンジンは内部の文字分類器が後続の数字よりも「$」記号に対する信頼度が低いため、そのトークンを誤読します。エンジンは低信頼度の文字（通貨記号）を破棄し、高信頼度の数字を保持することで混乱を解決します。

一部のビジョンベースの抽出エンジンは、文字ごとにトークン化するのではなく、視覚的なコンテキスト全体を処理するため、従来のOCRよりもこの問題をうまく処理します。しかし、通貨記号と最初の数字が密接なバウンディングボックスを共有している場合や、記号が一般的でない書体（一部のレシートプリンターのカールした「$」など）で表示される場合、最新のモデルでも苦労することがあります。

修正方法：抽出後のステップとして通貨記号の正規化マップを実装します。金額フィールドの期待される出力形式を定義します（例：「USD 156.00」または「$156.00」）— そして抽出された値をその形式に正規化します：

# ドキュメントコンテキストによる既知の通貨記号
currency_map = {
    'USD': r'[\$]',
    'EUR': r'[€]',
    'GBP': r'[£]',
    'JPY': r'[¥]'
}
# 抽出された値に数字があるが記号がない場合、
# ドキュメントメタデータから期待される通貨を割り当てる
if re.match(r'^\d+\.\d{2}$', value) and not has_currency_prefix(value):
    normalized = f"{doc_currency} {value}"

重要なのは、記号が属するかどうかをOCRに判断させないことです。抽出スキーマレベルで定義し、それに対して検証します。

障害モード3：桁区切りの混乱による小数点の逆転

症状：米国の請求書の「1,234.56」が「1.23456」または「1234.56」として抽出される（カンマが失われる）。欧州の文書の「1.234,56」が「1.23456」または「1234.56」として抽出される——ピリオドが小数点として扱われ、値が1,000倍に膨らむ。同じ句読点がロケールによって逆の意味を持つため、OCRエンジンはどちらのルールを適用すべきか判断できない。

発生理由：OCRエンジンは句読点を文字として扱い、数学的表記としては認識しない。ピリオドとカンマは視覚的に明確な異なる文字だが、エンジンは文書のロケールにおける小数点の区別をネイティブに理解していない。これは特定のエンジンの限界ではなく、Tesseractから商用クラウドAPIまで、すべての主流OCRツールが同じ方法で句読点を処理する：表示されたものを出力し、その句読点の解釈は後段のロジックに委ねる。 その結果、同じ抽出パイプラインが米国の請求書では$1,234.56を、ドイツの請求書では1.234,56€を生成し、後段のシステムがどちらの形式を想定しているかを知らなければ、両方とも誤って解析される。

この問題は、複数の国の請求書を処理する際にさらに複雑化する。米国、ドイツ、フランスのサプライヤーからの50件の請求書の単一バッチには、3つの異なる小数点形式が含まれる可能性がある。抽出エンジンは、どの文書にどの形式が適用されるかを自動的に検出しない。

修正方法：2つのアプローチがある。1つ目はスキーマレベルでの対応：抽出実行前に、サプライヤーまたは文書タイプごとに期待される小数点形式を定義する。ドイツのサプライヤーからの請求書がカンマ小数点を使用することが分かっている場合、その文書グループに対してカンマを小数点区切り、ピリオドを桁区切りとして解釈する解析ルールを設定する。

2つ目のアプローチは、桁の大きさの検証——多言語抽出の精度低下に関する記事で詳しく説明している手法で、文書ソース間の形式のばらつきがどのように連鎖的なエラーを生むかを扱っている。実際には、抽出された合計が明細項目の合計の妥当な範囲内にあるかを確認する。明細項目の合計が$12,345.67であるのに合計が$1,234,567.89になる場合、小数点と桁区切りの逆転が明確に示される。

# 検証：合計は明細項目の合計と妥当な許容範囲内で一致するか？
line_sum = sum(line_items)
total = extracted_total
# 合計がline_sumの約1000倍の場合、小数点が桁区切りとして読み取られた
if abs(total - line_sum) / max(line_sum, 1) > 100:
    flag_decimal_ambiguity(extracted_total)

障害モード4：負符号と括弧 — 見えない指標

症状：クレジットメモに"(156.00)"と表示されている場合、抽出結果は負符号なしの"156.00"になります。銀行取引明細書の残高"1,247.30-"は、末尾のマイナスが欠落して"1,247.30"と抽出されます。数値自体は正しいものの、符号が誤っているため、クレジットがデビットに、返金が請求に変わってしまいます。

原因：OCRエンジンは括弧を独立した句読点として扱います。負の値を示す標準的な会計表記で数値が括弧で囲まれている場合、開始括弧は最初の桁の前の別の文字として、終了括弧は最後の桁の後の別の文字として読み取られます。データ抽出時、これらの括弧は数値フィールドの期待される文字クラスと一致しないため、多くの場合破棄されます。末尾のマイナス記号も同様で、数字の後に配置されるため、数値トークンの範囲外となり、抽出ロジックが数値と関連付けない別のテキスト断片として分類されます。

修正方法：フィールドレベルの符号検出ルールを定義します。抽出値が通常クレジット、割引、または負の調整を含むフィールドに現れる場合、または元のドキュメントに金額の周りに括弧が含まれている場合、抽出後に符号反転を適用します。これをフィールド命名規則と組み合わせます。"Credit Amount"や"Discount"という列は絶対値を期待し、OCRが返した内容に関係なく自動的に負符号を適用する必要があります。

# ドキュメントのコンテキストが負の値フィールドを示しており、
# 抽出値が正の場合は符号を反転する
negative_context_fields = ['credit_memo', 'discount', 'refund', 'adjustment']
if field_name in negative_context_fields and extracted_value > 0:
    extracted_value = -extracted_value

故障モード5：上付き文字と下付き文字 — 行間で消える銭

症状：「$99⁹⁹」（銭を上付き文字で表した$99.99）という価格タグが「$99」または「$9900」として抽出される。小計の横に小さな上付き文字で印刷された税額が完全に欠落する。基本数値は正しいが、正確な金額を定義する端数部分が消失する。

原因：上付き文字は主数値と同じ水平領域を占めるが、ベースラインより上に位置し、サイズは主数字のポイント数の40～60%と小さい。OCRエンジンは垂直位置が主ベースラインからずれているため、これらを別のテキスト行または断片として検出する。テキスト抽出時、この断片は別の出力行に割り当てられるか、レイアウト解析で外れ値として除外される。小売価格タグや一部の請求書明細行で一般的な銭表記が最も頻繁に影響を受ける。

下付き文字の値 — 金額コンテキストではあまり一般的ではないが、税率や参照コードでは頻出 — も逆方向で同様の問題に直面する：ベースラインより下の文字が独立したテキスト領域として分割され、主数値との関連性を失う。

修正方法：最も実用的なアプローチは、狭い垂直範囲内で同じ水平位置を共有するすべてのテキスト断片を結合し、結合値を期待される金額パターンに対して検証することである。主数値「99」の後に同じ列領域に上付き文字「99」がある場合、結合「99.99」は有効な金額となる。これを空間マージルールとして実装する：主数値のX座標範囲の150%以内かつ定義された垂直オフセット内にあるテキスト断片は、抽出フィールド値にマージする。

# 同じ水平領域内の断片をマージ
# 狭い垂直帯域内で
def merge_superscript(main_number, fragments, y_threshold=15):
    """主数字クラスタを近傍の断片と結合する。"""
    combined = main_number
    for frag in fragments:
        if abs(frag.y - main_y) < y_threshold and \
           abs(frag.x - main_x) < main_width * 0.5:
            combined += frag.text
    # マージ後に検証
    if re.match(r'^\d+\.\d{2}$', combined):
        return combined
    return main_number  # マージが無効な場合は元の値にフォールバック

よくある質問

次のステップ：診断から予防へ

小数点の欠落は偶然の出来事ではありません。これは、5つの既知の失敗モードのいずれかによって発生する予測可能な結果です。これらのエラーを検出できるチームとできないチームの違いは、使用するツールではなく、診断フレームワークを持っているかどうかにあります。自分が直面している失敗モードが5つのうちどれかを把握できれば、修正方法は通常、AIエンジンを変えるのではなく、後処理ルールを追加することです。

まずは簡単な監査から始めましょう。パイプラインから抽出した直近50件の金額データを取得し、各エラーを失敗モードごとに分類します。エラーの80%が1つまたは2つのカテゴリに集中している場合、数行の検証ロジックを追加するだけで済む、コストのかからない修正に絞り込めます。エラーが5つのモードすべてに分散している場合、問題はおそらく取り込み品質にあり、修正方法はツールの変更ではなくスキャン基準の見直しです。

文書フォーマットによる抽出精度の違いと、曖昧さを最小限に抑えるフィールド設計の方法について詳しく知りたい場合は、間違った抽出数値を生むフィールド設計のミスに関するガイドと、文書ソース間のフォーマット差異が精度低下を引き起こす仕組みの分析をご覧ください。フィールド設計、フォーマット差異、そして今回のシンボルレベルの失敗モードという3つの診断軸を組み合わせることで、パイプラインのあらゆる段階で抽出精度をデバッグするための完全なフレームワークが完成します。