AI OCRは例外処理で選ぶ
目次
はじめに
紙の帳票をなくしたい。PDFの請求書を自動で読みたい。申込書の手入力を減らしたい。AI OCRの相談は、たいていこのあたりから始まる。
ところが、導入後に詰まる場所は「読めるか」だけではない。むしろ現場で効いてくるのは、読めなかったとき、迷ったとき、読み取った値をどこへ渡すかだ。精度だけを比較して選ぶと、後ろの業務で人間が吸収する負荷が残る。
この技術は、帳票を文字にする部品として見るより、例外を含む業務フローとして見た方がよい。読み取り、確認、補正、承認、登録、差戻し。この流れを先に閉じると、ツール選定も要件定義もかなり楽になる。
読み取り精度だけで選ぶと後工程が荒れる
比較ページを見ると、読み取り精度、手書き対応、非定型帳票、料金、連携先が並ぶ。もちろん見てよい。Google CloudはOCRを、単なる文字認識ではなく文書を理解し、整理し、データを豊かにする処理として説明している。Document AIの Enterprise Document OCR も、テキストとレイアウト情報の抽出を扱う。
Azure AI Document Intelligenceの Read model では、段落、座標、span情報まで返せる。つまり、主要クラウドはすでに「文字列だけ」より深いところへ進んでいる。
それでも、業務で最後に問題になるのは読み取り結果の扱いだ。
- 請求書番号が読めないときに止めるのか
- 金額と税額が合わないときに誰が見るのか
- 同じ取引先名が複数候補に分かれたらどうするのか
- 読み取り結果をそのまま基幹シス テムへ登録してよいのか
ここを決めずに「精度が高いツール」を入れると、例外だけが人間の机に積まれる。ツールが悪いのではない。例外を処理する仕様がないまま、読み取りだけを自動化したのがつらい。
先に分けるのは入力、判断、出力の3つ
要件定義では、最初に3つを分ける。
1つ目は入力だ。PDF、画像、FAX、スキャン、スマホ撮影。帳票の状態によって読み取り結果は変わる。Google Cloudの OCR with AI でも、文書から情報を抽出し、整理する流れが説明されている。入力の揺れを無視すると、あとで精度評価がぶれる。
2つ目は判断だ。読み取った値をどう解釈するか。たとえば「株式会社A」と「(株)A」を同じ会社として扱うのか。請求日と支払期日の前後関係が変なら止めるのか。ここはOCR単体ではなく、業務ルールの話になる。
3つ目は出力だ。CSVに出すのか、会計システムへ登録するのか、CRMへ添付するのか、人間の確認キューへ戻すのか。日立の AI OCR/RPA連携の記事 でも、帳票をデータ化した後に業務システムへの入力や集計へつなぐ流れが語られている。読み取りで終わらせず、後続システムまで設計する発想だ。
この3つが分かれていれば、ツール比較はかなり現実的になる。読み取り精度が少し高いツールより、例外を人間へ戻しやすいツールの方が、現場では勝つことがある。
選定軸を先に置く発想は、AI要件定義ツールの選び方 と同じだ。機能表を眺める前に、自社の業務で何を判断し、何を止めるかを決める。その順番にすると、比較表の見え方が変わる。
例外処理は5種類で見る
帳票処理で見るべき例外は、だいたい5種類に分けられる。
| 例外 | 何が起きるか | 先に決めること |
|---|---|---|
| 低信頼度 | 読み取り値に自信がない | 信頼度しきい値と確認担当 |
| 欠損 | 必須項目が読めない | 差戻し条件と再アップロード手順 |
| 矛盾 | 金額、日付、明細が合わない | 自動補正する範囲と停止条件 |
| 名寄せ揺れ | 取引先や品目が複数候補になる | 候補提示か、人間確定か |
| 外部登録前 | 基幹システムや会計へ反映する | 承認者とログの残し方 |
この表を作るだけで、会話が変わる。「どのツールがよいか」から、「どの例外をどこで止めるか」に移る。
RoboTANGOのAI OCR解説 でも、100%の認識精度は保証されず、人による確認や修正が発生する可能性に触れている。だったら、最初から人間確認を敗北扱いしない方がいい。人間が見るべき例外だけを薄く残し、通常処理を流す。そこまで含めて設計する。
導入前に1枚の処理表を作る
大きな要件書はいらない。まずは1枚でよい。
| 工程 | 自動化すること | 人間が見ること | 止める条件 |
|---|---|---|---|
| 受領 | PDFを取り込む | ファイル種別の確認 | 破損、パスワード付き |
| 読み取り | 項目を抽出する | 低信頼度項目 | 必須項目欠損 |
| 照合 | マスタと突合する | 候補が複数ある行 | 金額不一致 |
| 登録 | 下書きへ保存する | 外部反映前の承認 | 承認者不在 |
| 学習 | 修正履歴を残す | 例外パターンの整理 | 個人情報の混入 |
この処理表があると、PoCの見方も変わる。読み取り率だけを見るのではなく、例外が何件出たか、どの例外が人間に戻ったか、修正に何分かかったかを見る。実務では、そこが費用対効果の見積もりに効く。
生成AI PoCの成功基準は本番化の前に決める でも同じ話をしている。PoCは「動いたか」ではなく、本番に進める条件が見えたかで判断する。帳票処理でも、読み取れた枚数だけで合格にしない方がよい。
ツール選定より先に、責任境界を置く
AI OCRは帳票処理の入口だ。だが、入口だけが賢くなっても業務は終わらない。
責任境界を先に置く。AIが読む。AIが候補を出す。人間が確定する。システムが保存する。外部反映の前で承認を挟む。この流れを分けると、導入後の事故が減る。
特に、個人情報、請求、契約、支払いに触る帳票では、外部登録前の確認を残した方がよい。AI要件定義は権限境界から考える で書いた通り、読む権限と書く権限を混ぜると、便利さの裏で責任が曖昧になる。
もう一つ効くのは、例外条件を要件の先頭に置くことだ。AI要件定義は例外条件を先に決める の考え方をそのまま使える。通常系はAIがかなり埋めてくれる。人間が先に決めるべきなのは、止める線と戻す線だ。
AI OCRは「読むAI」ではなく「流す業務」として設計する
この種のツールを入れるとき、最初に欲しくなるのはデモだ。帳票をアップロードして、文字が抽出される。見た目にも分かりやすい。
でも、本番で効くのはその先だ。読んだ結果を、どの業務フローに流すのか。どの条件なら止めるのか。誰が確認すれば次へ進めるのか。そこが決まっていないと、「よく読めるけれど運用に乗らないツール」になる。
選定前に、まず例外処理表を1枚作る。次に、自社の帳票を20〜50枚ほど集めて、低信頼度、欠損、矛盾、名寄せ揺れ、登録前確認を数える。最後に、通常系と例外系を分けてPoCを見る。
AI OCRの導入は、紙をデータにするだけの話ではない。紙から業務へ戻す線を、AIが読める仕様として整える話だ。そこまで設計できれば、読み取り精度の比較はようやく意味を持つ。
株式会社Atsumellでは、AI OCRを含む業務自動化を、帳票、判断ルール、例外処理、承認境界まで分けて設計する。ツールを決める前に、業務フローと停止条件を一緒に整理したい場合は相談してほしい。
