OCRの結果をどう信じる？突合・例外リスト・ルール化までの考え方

電子帳簿保存法の改正やインボイス制度の導入に伴い、多くの企業がAI OCR（光学文字認識）を導入しました。しかし、現場からは「結局、全件目視で確認している」「OCRの誤認識を直す手間が、手入力と変わらない」という悲鳴が上がっています。OCRは魔法の杖ではありません。その結果をどう信じ、どう疑い、どうルール化するかという「運用設計」こそが、業務効率化の成否を分けます。

本記事では、OCRの読み取り結果を鵜呑みにせず、システム的に検証する「突合」の考え方や、自動化から除外すべき「例外リスト」の運用方法について、実務担当者の視点で詳しく解説します。

OCRの「精度」を信仰しない。実務で求められる「突合」の設計

OCR単体での100%は理論上不可能である理由

最新のAI OCRは、深層学習によって高い認識率を誇りますが、それでも100%の精度を保証することは不可能です。理由は、入力ソースとなる証憑（紙、PDF）の状態が制御不能だからです。

• かすれた印字、重なった印影
• 背景にデザインが入った領収書
• FAX経由で解像度が低下した画像
• 桁区切りのカンマとピリオドの誤認

これらの要因がある以上、OCRエンジンをどれだけ高機能なものに変えても、誤認識は必ず発生します。実務において重要なのは「OCRの精度を上げること」ではなく、「誤認識が発生した際に、システムが自動で不整合を検知できる仕組み」を構築することです。

確信度（Confidence Score）の罠と向き合う

多くのOCRツールには「確信度（スコア）」という指標があります。AIが「この文字である自信」を数値化したものですが、これを過信してはいけません。AIが高い確信度を持って「誤読」するケースがあるからです。例えば、数字の「1」を「l（エル）」と確信度99%で誤認することがあります。確信度だけで自動承認（スルー）を判断するのは、リスクの高い運用と言えます。

OCR結果を自動承認するための3つの突合ロジック

OCRの結果を信頼に値するデータに変えるためには、外部データや既存のデータベースとの「突合（マッチング）」が不可欠です。以下の3つのロジックを組み合わせることで、目視確認の対象を劇的に絞り込むことができます。

1. 【マスター突合】登録番号と社名データベースの連携

インボイス制度下において、最も強力な突合は「適格請求書発行事業者登録番号」の検証です。OCRで読み取った13桁の番号を、国税庁の公表システムとAPI連携させることで、以下の確認が自動で行えます。

• 番号が有効か（実在するか）
• 読み取った「社名」と、登録番号に紐づく「正式名称」が一致するか

もし登録番号が正規のもので、社名も一致していれば、そのOCR結果の信頼性は飛躍的に高まります。

関連記事：【完全版】「とりあえず電帳法対応」で導入したシステムが経理を殺す。Bill One等の受取SaaSと会計ソフトの正しい責務分解

2. 【発注データ突合】「3-way Matching」による検証

購買管理システムやSFA（営業支援ツール）に登録された「発注データ（PO）」とOCR結果を突き合わせます。

• 発注金額 ＝ 請求書（OCR）の合計金額
• 発注数量 ＝ 請求書（OCR）の数量明細

この2点が一致していれば、人間が内容を精査する必要はありません。この仕組みを構築するには、上流工程でのデータ整備が必要です。発注時にあらかじめ「いくら払うか」が確定しているビジネスモデルであれば、OCRは単なる「到着確認」のトリガーに過ぎなくなります。

3. 【履歴突合】過去の仕訳パターンとの不整合検知

過去1年間の同一取引先からの請求金額と、今回OCRで読み取った金額を比較します。例えば、毎月10万円前後の定額請求が来る取引先に対し、OCR結果が100万円となっていた場合、アラートを出す仕組みです。これは金額だけでなく、勘定科目や源泉徴収の有無についても同様のロジックが適用可能です。

例外リストと「前処理・後処理」のルール化

どれだけ突合ロジックを組んでも、OCRと相性の悪い証憑は存在します。それらを無理に自動化しようとせず、最初から「例外」として定義することが、運用を破綻させないコツです。

読めない取引先を「例外」として切り出す判断基準

以下の条件に当てはまる証憑は、OCRの読み取り設定を個別に行うか、最初から手入力フローに回すべきです。

• 非定型すぎるレイアウト: 明細が数ページにわたる、または表組みが極めて複雑なもの。
• 低品質な印字: ドットインパクトプリンタで出力された古い形式の伝票など。
• 手書きの追記: 印字された金額を二重線で消し、手書きで修正されているもの（AI OCRでも誤認リスクが極めて高い）。

正規表現（Regex）によるデータの正規化手順

OCRの結果には「ノイズ」が含まれることがよくあります。これを後処理（Post-processing）でクレンジングするルールを作成します。

1. 日付の正規化: 「令和6年4月1日」「2024/04/01」「R6.4.1」などバラバラな形式を、「2024-04-01」に統一。
2. 不要文字の削除: 金額項目に含まれる「￥」や「円」、「,（カンマ）」を除去して数値型に変換。
3. 全角・半角の統一: アルファベットや数字の全角・半角混在を半角に統一。

これらの処理をプログラム、またはiPaaSやETLツール上でルール化しておくことで、後の会計システム連携がスムーズになります。例えば、Google WorkspaceとAppSheetを活用して、読み取り後のデータを簡易的に補正するインターフェースを作るのも有効な手段です。

関連記事：Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド

主要AI OCRサービスの比較と特性

実務で利用される主要なサービスを比較します。各ツール、OCRのエンジンそのものよりも「その後の突合・承認ワークフロー」に特色があります。

特に「バクラク」と「freee」の連携などは、バックオフィス全体のアーキテクチャに大きく影響します。自社の既存システムとの相性を考慮して選定する必要があります。

関連記事：【徹底比較】バクラク vs freee支出管理。中堅企業が「経費精算・稟議」を会計ソフトと分ける本当の理由

ステップバイステップ：OCR自動化運用の構築手順

実際にOCR運用を開始、または改善するためのステップを解説します。

Step 1：現状の証憑種別の棚卸しとサンプル収集

まず、自社に届く請求書や領収書のうち、どの取引先がボリュームを占めているかを分析します。上位20%の取引先で、全請求書の80%を占めることが多い（パレートの法則）ため、その主要な証憑のレイアウトを事前にチェックします。

Step 2：エラー率の計測と「許容コスト」の定義

最初の1ヶ月は、OCR結果と正解データを突き合わせ、エラー率を計測します。ここでのポイントは、「100%を目指さないこと」です。1件のエラーを見逃すリスクと、100件を全件目視するコストを天秤にかけます。例えば、「1万円未満の飲食費なら、日付と金額の形式が合っていればスルーする」といった、金額によるリスク閾値を設けるのが現実的です。

Step 3：ワークフローへの組み込みと「差し戻し」基準の策定

OCRの読み取りが不明瞭な場合、誰がどのように修正するかを決めます。

• 現場担当者: 証憑をアップロードした本人が、OCR結果を確認・修正する。
• 経理担当者: 現場が入力したデータを最終承認する。

ここで重要なのは、OCRの誤認識を「システムエラー」として情報システム部門に投げるのではなく、「入力の不備」として業務フロー内で処理することです。

よくあるエラーと具体的な対処法

OCR運用で必ず直面する問題とその解決策です。

合計金額が「￥1,000」を「11,000」と誤認するケース

これは、通貨記号「￥」や「\」の縦棒を「1」と誤認するために起こります。

【対処法】：
後処理ルールにて「金額項目に不自然な連続する1がある場合」にアラートを出す、あるいはOCRエンジン側の設定で「金額項目は数値のみ（記号除外）」を適用します。

インボイス登録番号の読み取りエラー

13桁の数字の中にアルファベットの「T」が含まれているかどうかで、OCRのモードが変わることがあります。

【対処法】：
前述の国税庁APIによるバリデーションを実施します。もし番号が「12桁」や「14桁」であれば、システム側で自動的にエラーとして人間へ入力を促します。また、読み取り後のデータから「T」を除去した上で13桁の数値として扱うなど、データの「型」を厳格に管理することが重要です。

OCRを導入して「楽になった」と言える状態にするためには、ツールの導入それ自体よりも、こうした泥臭い「ルールの整備」と「例外の定義」に時間をかけるべきです。それが結果として、自動化の恩恵を最大化する唯一の道となります。