OCR リソースの選び方
画像から文字を読み取る処理は、対象の書類が何かで難易度がまったく変わる。印刷された定型文書なら実用水準にあるが、手書き・低解像度・複雑な帳票では精度が落ちる。汎用の評価ではなく、実際に扱う書類のサンプルで検証するしかない。
日本の書類が難しい理由
日本の業務書類には、汎用 OCR が苦手とする条件が揃いやすい。
- 罫線が多い — 表組みの帳票は、セルの区切りと文字の判別が混ざりやすい
- 縦書きが混ざる — 横書き前提のモデルでは読み順が崩れる
- 手書きの記入欄 — 印字部分は読めても記入部分で精度が落ちる
- 和暦 — 「令和6年」のような表記の解釈
読み取り結果は後処理込みで設計してください
OCR の出力をそのまま使える場面はほとんどありません。金額のカンマ、日付の形式、全角半角の揺れ、誤認識しやすい文字（0とO、1とlなど）——これらの正規化処理が必ず要ります。読み取り精度の比較だけでなく、その後の整形にどれだけ手間がかかるかまで含めて評価してください。
汎用と帳票特化の使い分け
汎用の画像認識サービスは、写真の中の文字や看板の読み取りには強い。一方、請求書や申込書のように「決まった位置に決まった項目がある」書類では、帳票特化のサービスのほうが項目単位で構造化して返してくれる分だけ実装が楽になる。扱う書類が定型かどうかが最初の分岐点だ。
全自動にしない
読み取り結果には必ず誤りが混ざる。金額や日付のように誤りが実害に直結する項目は、確信度が低いものを人間の確認に回す設計にしておく。完全自動を前提にすると、誤読の責任をどこが引き受けるのかという問題に突き当たる。