AI OCRで手書き書類を扱うときは、認識結果をそのまま確定データにせず、人が誤りを見つけて修正する工程まで設計します。 対象帳票と重要項目を決め、自社の書類でテストしたうえで、確認・修正・記録の流れを整えることが基本です。

手書き文字の読み取りに対応するサービスはありますが、対応する言語や書類形式、画像の状態はサービスによって異なります。認識率だけで比較せず、「どの項目を誰が確認し、修正後の値をどう管理するか」まで検討しましょう。

AI OCRの手書き認識でできることと限界

AI OCRの手書き認識の範囲

AI OCRは、印字された文字だけでなく手書き文字も読み取り対象にできます。ただし、利用できる文字や帳票の条件はサービスごとに違い、同じ帳票でも記入の仕方や画像の状態で結果が変わります。読み取り対象にできることと、業務でそのまま使えることは別です。

認識対象と帳票条件を整理する

Microsoft Azure AI Document IntelligenceのReadモデルは、日本語（ja）の手書き文字を抽出対象としています。Google Cloud Document AIのEnterprise Document OCRは、200超の言語の手書き文字を含む文書からテキストを抽出します。これらの対応範囲だけで、自社帳票のすべての文字や記入欄が期待どおりに読めるとは限りません。

まず、帳票にある文章・数字・チェック欄などを分け、読み取りたい項目を一覧にします。たとえば受注書なら、品番・数量・納期・備考欄を別々に扱い、サービスの仕様と実際の帳票で対象にできるかを見ます。

認識結果を業務で使う際の前提

読み取りは入力作業の一部であり、確定処理とは分けて考えます。納期や数量の誤りが後続の手配に影響する帳票では、担当者が原本と照合してから確定する流れが必要です。認識結果を確定データへ直接流す場合は、誤りを止める条件も合わせて決めます。

読み取りと確定を分ける

帳票の種類と読み取り項目を先に定義します。テストでは文字の認識だけでなく、担当者が修正・確定できるかも確かめます。

手書きの読み取りミスが起きる主な要因

手書き認識の誤りにつながる要因

誤りの要因は、文字の書き方、帳票のつくり、画像の状態に分けて考えると整理しやすくなります。どの条件で間違いやすいかは帳票ごとに異なるため、一般的な精度だけで判断せず、自社で使う書類を使った確認が必要です。

文字や記入内容に関する要因

「1」と「7」のように似た形の文字、続け書き、社内略記、訂正線のある数字、書き直しが重なった箇所は、認識結果の確認候補になります。記入欄に「至急」などの補足が手書きで加わる場合も、定型項目と自由記入を分けて評価します。

帳票・画像に関する要因

記入欄からのはみ出し、印刷線と文字の重なり、かすれ、傾きは、テスト時に誤りの有無を記録したい状態です。Google Cloud Document AIは、OCRの読み取り精度を得るためスキャン解像度200 dpi以上を推奨し、一般に300 dpi以上が最良の結果につながるとしています。

Google Cloud Document AIはPDF、GIF、TIFF、JPEG、PNG、BMP、WebPに対応しています。一方、JPEGの圧縮で画質を下げると認識精度が低下する可能性があります。元画像の解像度や圧縮で文字がつぶれていないか、取り込み前に確認することが重要です。

画像の条件をそろえて比較するには、同じ帳票を異なる解像度や傾きで読み取り、どの状態で誤りが増えるかを記録します。対応形式や推奨条件はサービス単位で照合し、別サービスの条件をそのまま当てはめないようにします。

認識結果の誤りを見つけるチェック観点

認識結果の確認ポイント

誤りを見つける方法は、原本との照合だけではありません。項目ごとの形式や、帳票内の数字同士の整合性も確認に使えます。自動で検査できる範囲はサービスによって異なるため、機能の有無を確かめつつ、人が見る条件も設計します。

項目ごとの形式を確認する

日付、郵便番号、金額などは、業務ルールに沿った形式や範囲を検討します。たとえば日付欄が空欄なら要確認にする、金額が想定外の桁数なら原本を見る、といった条件です。システムで設定できるかは別途確認し、設定できない場合は確認画面や作業手順で補います。

帳票内の整合性を確かめる

内訳と合計、数量と単価など、同じ帳票内で照合できる項目を洗い出します。金額の合計が内訳と一致しない場合に担当者へ回すなど、誤りを見つける条件を具体化できます。自動照合が難しい項目は、確認者が見る箇所として明記します。

原本と認識結果を見比べる

Azure Document Intelligenceの解析結果は、単語、キーと値の組、選択マーク、領域、署名などに推定信頼度を返します。ただし、すべてのフィールドに信頼度が付くわけではありません。Azureのフィールド信頼度は0〜1の推定値で、精度が重要な項目を人手確認に回す判定に利用できます。

Google Document AIのDocumentオブジェクトも、レイアウト要素ごとのconfidenceを0〜1の範囲で返します。数値は正しさを保証する値ではなく、確認対象を振り分ける材料の一つです。画像と認識結果を並べて確認できる画面があるかも、運用に合わせて調べます。

信頼度だけで確定しない

信頼度が高くても、業務上重要な項目は原本照合の対象にする設計が考えられます。信頼度が返らない項目もあるため、空欄や形式不一致など別の条件も組み合わせます。

人が確認する箇所と優先順位の決め方

人が確認する範囲の決め方

すべての項目を同じ方法で確認するのではなく、誤りが後続業務に与える影響と、間違いを見つけやすいかで優先順位を付けます。たとえば、取引先名の誤りが受注登録に影響する場合と、備考欄の軽微な誤字では、確認の重さを分ける判断ができます。

影響の大きい項目を優先する

数量・金額・納期など、誤りが発注や出荷の判断に影響する項目は、確認対象の上位に置きます。項目ごとに「誤るとどの処理が止まるか」「誤りに気付ける後続チェックがあるか」を書き出すと、優先順位を決めやすくなります。

要確認の条件を決める

空欄、不自然な形式、帳票内の不整合を、担当者へ回す条件として定義します。信頼度に閾値を設ける場合は、Google Document AIのプロセッサ評価で調整できる信頼度の閾値も参考になります。閾値を上げると一般に適合率は上がり、再現率は下がります。つまり、要確認として拾ったものが正しい割合は上がりやすい一方、確認対象として拾える範囲は狭くなりやすいため、業務データで試して決めます。

確認者と例外時の対応を明確にする

一次確認を受注担当、修正を帳票の記入元へ照会する担当、最終確定を登録担当とするなど、作業ごとに責任者を決めます。判読できない文字を誰が判断するか、取引先へ再提出を依頼するのは誰かも明文化すると、確認待ちのまま処理が止まる事態を減らせます。

読み取りから修正までの確認工程を設計する

確認工程の基本フロー

帳票の取り込みから確定までを一続きの工程として設計します。担当者や差し戻し先のほか、認識結果・修正内容・確定データをどこで受け渡すかを明らかにし、確認待ちや二重入力が起きる箇所を洗い出します。

工程ごとの役割を決める

読み取り、一次確認、修正、最終確定の各工程で、担当者と残す情報を定めます。一次確認で原本照合、修正で変更理由の記録、最終確定で必須項目の再確認というように、役割を分けると同じ項目を複数回入力する無駄も見つけやすくなります。

帳票を取り込む
→ OCRで読み取る
→ 形式・整合性・信頼度などで要確認を抽出
→ 担当者が原本と照合して修正
→ 確定データを後続業務へ渡す

差し戻しと再確認の流れを用意する

判読できない文字や帳票の不備があった場合は、差し戻し先と再提出後の確認方法を決めます。たとえば、記入元へ修正版を依頼した後、再提出された帳票を同じ担当者が見るのか、別の確認者が見るのかまで決めておくと、修正漏れを防ぐ手がかりになります。

運用開始後も誤りを記録する

誤りの項目、原因、修正内容、帳票の状態を記録し、確認条件や帳票の見直しに使える形にします。「数量の桁違い」「印刷線と手書き文字の重なり」など原因を分類しておけば、確認対象の追加や記入欄の変更を検討しやすくなります。

修正後データの記録・再利用ルール

修正後データの管理

認識値と修正値を区別しないまま保存すると、後からどの値がOCRの出力で、どの値が確定した値なのか分かりにくくなります。元の認識結果・修正後の値・確定値の関係を追える管理方法を決め、保存期間やアクセス権、データの利用条件はサービスの仕様と社内ルールに照らします。

認識値と修正値を分けて管理する

元の認識結果を残すのか、修正後の値と併記するのかを決めます。受注書の数量を修正した場合、認識値と確定値を分けておけば、修正の有無や誤りの傾向を後から確認できます。修正後の値だけを残す運用では、元の出力との比較ができなくなる点に注意が必要です。

修正履歴に残す情報を決める

修正者、修正日時、修正理由など、必要な記録項目を定めます。誤認識の原因を見直すなら、帳票の種類や該当項目も記録対象にすると分析に使いやすくなります。誰がいつ何を直したかを追える範囲は、社内の記録ルールと利用サービスの仕様に合わせます。

修正データの再利用条件を確認する

Google Document AIのカスタム抽出器では、学習・評価用に正解ラベル付き文書を使い、独自の学習データでモデルを訓練できます。学習用データセットはGoogle管理ストレージまたは利用者指定のCloud Storageに保存できますが、作成後に保存方式を変更できません。作成時点で保存先の選択が必要です。

Googleは、顧客データをDocument AIのモデル学習に使用せず、同期処理の文書データはメモリ上で処理し、ディスクに永続化しないとしています。これはGoogle Document AIについての説明であり、利用者が作成する学習用データセットの保存方式とは分けて考えます。修正データを独自モデルの学習に利用する場合は、対象文書や利用範囲、保存先を確認します。

導入前に確認したいテストと運用条件

導入前の確認項目

導入前のテストでは、認識結果だけでなく、人による確認・修正・確定まで通して評価します。帳票の種類や記入状態を本番に近づけ、誤りの内容と担当者の作業を記録すれば、認識機能だけでは見えにくい運用負荷も把握できます。

実際の帳票で読み取りを試す

手書きの程度や記入欄の状態が異なる帳票をテスト対象にし、誤りが出た項目と状況を記録します。Google Document AIは、テストセットについて文書タイプごとに少なくとも100件を用意し、本番データの種類や頻度を代表させることを推奨しています。自社の帳票をどのようにそろえるかを考える際の目安になります。

確認・修正を含めて評価する

読み取り、原本との照合、修正、最終確定まで実際に試し、どの項目に確認が集中するか、例外処理にどれだけ手間がかかるかを記録します。Google CloudのDocument AI料金ページでは、Enterprise Document OCRは処理件数に応じた従量課金として掲載されています。利用件数を見積もるときは、対象書類や処理の範囲と合わせて料金条件を個別に確認します。

導入後の見直し方法を決める

誤りの記録を誰が見直し、帳票や確認条件をいつ更新するかを決めます。たとえば月次の業務見直しで、頻出する誤りと差し戻しの原因を確認する方法があります。対応形式や利用環境、料金などのサービス固有情報も、検討時点の仕様に基づいて判断します。

テストで見る範囲

帳票タイプごとに実データを用意し、認識結果と人の修正作業の両方を記録します。誤りの種類、要確認となった件数、例外処理を見て、確認工程を調整します。

まとめ

AI OCRの手書き認識は、読み取りの可否だけでなく、誤りを見つける方法、人が確認する項目、修正後データの管理まで含めて設計します。

次の一歩は、対象帳票と重要項目を一覧にし、誤りが業務へ与える影響から確認順位を決めることです。そのうえで自社の書類を使って、読み取りから修正・確定までをテストします。誤りの記録をもとに工程を見直せる状態にしておけば、導入後の改善にもつなげられます。

akinAI 編集部

参考・出典