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ピクセルの小数点——サーマルレシート、低DPIスキャン、FAX文書によく見られる——は、これらの前処理工程のノイズフロアを下回る。エンジンのフィルターは、2つの数字の間にある小さな点を認識し、それをゴミ、紙繊維、圧縮アーティファクトとして分類する。72DPIでは、小数点の幅は約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」（記号と数字が結合し、小数点が失われる）として抽出されます。通貨のコンテキストが消失し、下流システムが米ドル金額を単位なしの数値として扱います。

原因：通貨記号（$、€、£、¥、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つの対策で、小数点や通貨記号の欠落の大半はカバーできる。しかし、後処理のルールでは正しい値を確実に復元できない文書も存在する。それは、小数点の物理的なサイズが、キャプチャ方式の最小解像度よりも小さい場合だ。72 DPIのサーマルレシート上の小数点は約2ピクセル幅になる。このサイズでは、従来のOCRでもビジョンAIでも、画像内に情報が物理的に存在しないため、信頼性の高い読み取りは不可能だ。

サーマルレシート、ファックス文書、2世代目のコピーを扱う場合は、一部の小数点は手動確認が必要だと認識しておこう。 実用的な方法は、抽出された金額に対して桁数チェックを実施し（合計が想定範囲外、明細の合計と一致しない、通貨と小数点以下の桁数が合わないなど）、フラグが立ったものを人間がレビューする仕組みだ。フラグが立った値の30秒レビューは、キャプチャ時に失われた情報を後処理で復元しようとするよりも、迅速かつ信頼性が高い。

低解像度の文書を常時処理するチームにとって、最も効果的な投資は抽出ツールの改善ではない。それは、入稿文書に300 DPI以上を求めるスキャン基準の策定だ。300 DPIでは小数点は8〜10ピクセルになり、最新の抽出エンジンのノイズフロアを上回る。