AI OCRが使えないと感じたら、精度だけを見直すのではなく、帳票の形式・画像の状態・読み取り後の運用に分けて原因を探します。まず同じ帳票で誤り方を記録し、条件を一つずつ変えて結果を比べるのが基本です。帳票、画像、後工程の順に切り分ければ、どこを見直すべきか判断しやすくなります。

「使えない」と感じたら、帳票・画像・読み取り後に分けて確認する

不調の原因を分けて見る

読み取り結果の不安定さを、すぐに「OCRの精度が低い」とまとめないことが出発点です。文字自体を間違えているのか、帳票上の別の欄を拾っているのか、認識後の転記で値がずれているのかによって、見直す場所は異なります。

  • 帳票：項目の位置、定型・非定型、手書きや欄外の記入
  • 画像：文字のかすれ、汚れ、傾き、端の切れ
  • 読み取り後：確認・修正・転記の担当と手順

たとえば、請求書の金額欄で数字そのものが違うなら、画像の見え方や文字の種類を先に調べます。金額は正しく読めているのに別の項目として出力されるなら、項目の位置や読み取り後の処理も確認対象です。

切り分けの順番

帳票の形式、画像の状態、読み取り後の作業の順に見ます。最初に誤りの種類を記録しておくと、どの条件を変えるべきか決めやすくなります。

帳票の形式が読み取りに合っているか確認する

帳票側の確認ポイント

帳票が定型か非定型か、項目の位置が帳票ごとに変わるか、記入欄にどのような文字が入るかを分けて見ます。同じ「請求書」でも、取引先ごとに日付や合計金額の位置が違う場合は、帳票ごとに誤りの傾向を記録します。

レイアウトや項目位置を確認する

まず、読み取り対象を帳票の種類と項目に分けます。たとえば、注文書の「品番」「数量」「納期」について、帳票ごとに記載位置が同じかを見比べます。製品が対応する帳票形式はそれぞれ異なるため、定型・非定型のどちらを扱えるか、対象の帳票で確かめる必要があります。

Google Document AIがサポートするファイル形式にはPDF、GIF、TIFF、JPEG、PNG、BMP、WebPがあります。HTML・DOCX・PPTX・XLSXはLayout Parserでのみ対応するため、ファイル形式が読み取り処理に合っているかも確認項目です。対応形式であることと、帳票の項目を期待どおりに抽出できることは分けて検証します。

手書きや欄外記入を確認する

記入欄からはみ出した数字、欄外に追記された納期、印字と手書きが混在する項目などを、読み取り結果と照らし合わせます。Google Document AIのEnterprise Document OCRは、文字に加えて段落・ブロック・行・単語を検出し、手書き文字にも対応します。ただし、対応機能があることだけで、自社帳票の手書きが期待どおりに読めるとは判断せず、実際の帳票で確認します。

帳票の見分け方

帳票の種類と項目をひも付け、項目位置が固定か変動かを記録します。手書き、欄外記入、枠からはみ出した文字も、帳票条件の一つとして扱います。

画像の状態に起因する読み取りミスを確認する

画像状態の確認ポイント

帳票の形式を変えず、元画像の状態だけを見直します。読み取りたい文字が人の目で判別できるかを確認し、かすれ、汚れ、傾き、端の切れがあれば、同じ帳票の画像を条件違いで比べます。FAX由来の汚れやかすれも確認対象です。

元画像を目視で確認する

画像を開き、誤りが出た欄を原本と照らし合わせます。文字の一部が薄い、欄の境界が見えにくい、帳票の端が欠けているといった状態を、誤りが発生した項目と一緒に記録します。

画像条件は製品ごとに異なります。GoogleはDocument AIのOCRについて、スキャン画像は最低200 dpi、一般に300 dpi以上を推奨しています。また、精度は解像度、最小フォントサイズ、文書品質などに依存すると案内しています。これはGoogle Document AIの案内であり、他製品の要件と混同しないようにします。

Azure AI Document Intelligenceでは、画像入力は50×50～10,000×10,000ピクセルです。1024×768画像の場合、読み取り対象文字の最小高さは12ピクセルとされています。画像の解像度だけでなく、実際の文字がどの程度の大きさで写っているかも確認材料になります。

条件を変えて結果を比べる

同じ帳票を使い、画像の状態を見直す前後で結果を比較します。JPEGなどの非可逆形式でファイルを縮小すると、画質とGoogle Document AIの結果精度が低下する可能性があります。画像を小さくする変更と、別の条件変更を同時に行うと、どちらが影響したか分からなくなります。

Google Document AIの画質分析では、ぼやけ・ノイズ・暗さ・薄さ・小さすぎる文字・文書や文字の切れ・反射の8種類を検出します。画質スコアは0～1で返され、0.5未満の場合は欠陥理由のリストも返されます。利用できる場合は、誤りが出た画像と画質分析の情報を照らし合わせます。

画像要件に注意

dpiやピクセル数などの条件は、ここで挙げた製品の仕様に基づくものです。別のAI OCR製品にそのまま当てはめず、対象製品の要件と実画像の状態を照合してください。

誤り方を分類して、どの段階に原因があるか絞る

誤り方から原因を探る

読み取り結果は、文字の誤認識、読み落とし、項目の取り違えに分けて記録します。同じ帳票で誤りが出た項目と内容を並べると、帳票形式と画像状態のどちらを先に見直すか判断しやすくなります。

同じ帳票で誤りの傾向を比べる

複数の結果がある場合は、帳票の種類、項目名、誤りの内容、画像の状態を記録します。たとえば、同じ納品書の「数量」だけで読み落としが続くのか、特定の取引先の帳票だけで項目がずれるのかを分けて見ます。記録項目は、現場で原本と結果を照合する作業に合わせて決めます。

読めない箇所と項目のずれを区別する

原本の文字と出力された文字が異なるなら、文字の認識を中心に確認します。文字は合っているのに別の項目に入っているなら、項目位置や帳票のレイアウトを見直します。Google Document AIのEnterprise Document OCRが段落・ブロック・行・単語を検出することも、文字単位の誤りと文書内の位置関係を分けて確認する際の参考になります。

Google Document AIでは、言語や手書きのヒントを設定できます。Googleは、読み取り対象データの特性に基づくヒントが精度向上に役立つと案内しています。日本語の印字か、手書きの数字を含む帳票かなど、対象の特徴を整理して、設定の有無や影響を一つずつ比べます。

PDFでは、既存のテキスト情報を使う処理を有効にする設定項目として、Google Document AIにenableNativePdfParsingがあります。スキャン画像のOCRと、PDF内のテキスト情報を使う処理を同じものとして扱わず、対象ファイルと設定を記録して比較します。

Google Document AI：enableNativePdfParsing

Google Document AIのOCRモデルは、バージョンによって読み取り動作が変わる可能性があります。厳密な一貫性が必要な場合はモデルバージョンを固定できます。比較検証の途中でモデルのバージョンが変わっていないかも、条件として記録します。

読み取り後の確認・修正・転記を分けて見る

読み取り後の作業を点検

読み取り精度だけでは、担当者の作業負担を判断できません。認識結果の確認、修正、Excelや業務システムへの転記を分けて、どの作業が残っているかを見ます。

誰が何を確認・修正しているか整理する

担当者ごとに、確認している項目、修正が多い箇所、修正後に行う作業を記録します。認識結果の誤りを直しているのか、業務ルールに沿って内容を確かめているのかを区別すると、OCRの改善で減らせる作業と、業務上残る確認を分けて考えられます。

出力後の作業やシステム連携を確認する

読み取ったデータをExcelへ転記してから販売管理システムへ入力している場合は、読み取り後の受け渡しも作業として記録します。連携できるシステムや方法は製品ごとに異なるため、対象製品の連携仕様を確認します。読み取り結果が正しくても、転記や受け渡しが手作業で残っているなら、課題は読み取り精度だけではありません。

作業を分けて記録

認識結果の確認、誤りの修正、業務ルールに基づく確認、システムへの転記を別々に記録します。修正件数だけでなく、どの工程に作業が残っているかが見える形にします。

条件をそろえて検証し、改善の影響を確かめる

切り分け検証の進め方

実際の業務で使う帳票を選び、帳票形式や画像状態、読み取り後の手順を一度に変えずに比較します。条件を一つずつ変えることで、何を見直したときに結果が変わったのかを追いやすくなります。

検証する帳票と確認項目を決める

対象帳票の種類と、確認する項目を先に決めます。たとえば、注文書なら「品番」「数量」「納期」など、現場で照合している項目を使います。誤りは、文字の誤認識・読み落とし・項目の取り違えに分けて記録します。検証対象と評価基準は、業務内容に合わせて設定します。

変更する条件を一つずつにする

帳票の形式、画像状態、読み取り後の手順など、変更する条件は一つずつにします。たとえば、同じ帳票のまま画像だけを見直した結果を比べ、その後に帳票条件や設定を検証します。

帳票の種類：
確認する項目：
誤りの分類：誤認識／読み落とし／項目の取り違え
変更した条件：
読み取り結果：
確認・修正・転記で残った作業：

読み取り結果以外の作業も比較する

比較するのは、認識した文字の正誤だけではありません。人が確認・修正した項目や、Excel・業務システムへの転記など、後工程に残った作業も記録します。評価に使う時間や指標は、自社の帳票処理の流れに合わせて決めます。

Google Document AIを使う場合、OCRモデルのバージョンや言語・手書きのヒント、enableNativePdfParsingの設定も検証条件に含められます。モデルのバージョンを固定できるケースでは固定し、変更した設定と結果を同じ記録に残します。

改善しても合わない場合は製品と運用を見直す

見直し時の確認項目

帳票や画像の条件を見直しても課題が残る場合は、製品の対応範囲と必要な機能、読み取り後の業務の流れが合っているかを検討します。トライアルの有無、サポート体制、セキュリティ、費用も比較項目になりますが、提供条件は製品ごとに確認が必要です。

対応する帳票や必要な機能を確認する

定型・非定型、手書き文字の有無、扱うファイル形式を整理してから、製品の対応範囲と照らし合わせます。必要な帳票形式が読み込み対象に含まれるかと、その形式で必要な項目を処理できるかを分けて確認します。

導入後の運用条件を確かめる

読み取り操作だけでなく、確認担当者が結果を見やすいか、修正後のデータをどこへ渡すか、問題が起きたときのサポート窓口があるかを検討します。Azure AI Document Intelligenceは、有料S0層で解析ファイルの上限が500 MB、無料F0層では4 MBです。PDF・TIFFは最大2,000ページとされています。対象のファイルサイズやページ数が上限に収まるかは、製品選定時の具体的な確認点です。

費用、トライアルの提供条件、セキュリティ、他システムとの連携は、ここで挙げた仕様だけでは判断できません。候補製品ごとに、実際に使う帳票と後工程を使って条件を確かめます。

まとめ

AI OCRが使えないと感じたときは、帳票形式、画像状態、読み取り後の運用の順に確認し、誤認識・読み落とし・項目の取り違えを記録します。Google Document AIやAzure AI Document Intelligenceの仕様は製品ごとの判断材料として使い、自社の帳票で結果を比較することが重要です。

まずは実際に使っている帳票を一種類選び、確認項目と誤りの分類を決めます。そのうえで条件を一つずつ変え、読み取り結果だけでなく確認・修正・転記の作業も見比べます。原因を分けて検証することが、AI OCRを見直す次の一歩です。

akinAI 編集部

参考・出典