【OCRxRPA】OCRが読み込んだ結果の検証（誤りの検知と訂正）を、フローのどこでやるのか問題

はじめに

先日、以下の記事の中で、「OCRをかけた結果をRPA後続システムに入力する場合は、フローのどこで検証をやるかをよく整理すべし」という話を書きました。

うまく整理して構築しないと、こういう話になります、と。

「それはわかったけど、じゃあ、具体的にどうやって整理すればいいの？」と悩む方も多いかと思います。

そんなわけで、この記事では OCR x RPA 案件において、**「検証をフローのどこでやるのか問題」**について、掘り下げて考えていきたいと思います。

万能薬はない

「こうしておけば絶対正解！」というような、あらゆるケースにあてはまる万能な対策を期待している方はゴメンナサイ。

OCR案件のPoCを年間100件やっている筆者といえど、そんな万能な対策を知っているわけではありません。
（知っている人いたら教えてください！　と言いつつ、そんな対策があれば誰も悩んでいないだろうとも思っていますが）

したがって、最後は「その業務の実態に合わせて最適な手段を選びましょう」という話になってしまいます。

ですが、以下を把握しておくことで、「最適な手段」を選ぶ助けにはなるかと思います。

• フローの中で検証を行う箇所の選択肢
• 上記の選択肢それぞれのメリデメ

そんなわけでここからは、フローの中で検証を行う箇所にどんな選択肢があるのかと、それぞれのメリデメを見ていきます。

前提：OCR x RPA の一般的な処理フロー

大前提として、OCR x RPA の一般的な処理フローを描いてみます。

基本的には、以下のように3つの段階に分けてBotを作ると思います。

• Bot①：帳票の画像データをOCRに読み込ませるBot
• Bot②：OCRの出力結果を後続処理用に編集するBot
• Bot③：後続処理（画面入力等）を実行するBot

上記は概念的な整理なので、実際には②と③をひとつのBotで処理していたり、①～③までをすべて同じBotで処理しているケースもあるでしょう。
（"ひとつのBotはひとつの仕事"の原則に照らすと、あまりオススメはできませんが）

ですが、「フローのどこに検証を組み込むか」を考えるときに、上記の整理は非常に重要です。

検証を組み込む箇所　-３つの選択肢-

OCR x RPA のフローに検証を組み込む場合、その選択肢は大きく分けて3か所あります。

• ポイント①：OCR備え付けの検証機能でエラーを訂正
• ポイント②：OCRの処理結果をRPAで件祖父する
• ポイント③：後続処理の入力エラー（画面入力エラーなど）を検知する

図を見ると、ポイント①～③が先述のBot①～③に対応しているのがわかると思います。

仮にBot①～③をひとつのBotで処理していたとしても、ポイント①～③の区別は重要です。
なぜなら、各ポイントに応じて、エラーを検知する根拠と、検知したエラーを訂正するときに人が見る画面が変わってくるからです。

以下の表が、それをまとめたものです。

ポイント	エラー検知の根拠	訂正時に人が見る画面
①	OCRに組み込まれたエラー検知機能 例：確信度、型違反、帳票上の数字同士の検算など。 　　何ができるかはOCR製品による。	OCR製品が提供しているエラー訂正画面
②	RPAのロジック 例：DB上に存在しないID、変換エラーなど。	OCRの処理結果（csv、Excelなど） （RPA側の作り込みによる）
③	後続処理側の入力チェック機能 （画面の入力エラーなど）	後続処理次第だが、通常はエラー画面

この整理を見ただけで、ピンと来る人には来てしまったかもしれませんが、
以下、各ポイントでエラーを検知する際のメリデメを掘り下げていきます。

① OCRに備え付けの機能でエラーを検知→訂正する場合

まず最初に、OCR備え付けの検証機能でエラーを検知→訂正する場合を考えてみます。

図を見ればわかるとおり、OCRは通常、処理フローのいちばん上流に来ます。
「データの品質は上流で確保」はシステム処理の原則なので、システムに強い人ほど、「この時点でデータを完璧にしておきたい」という考えを持つと思います。

筆者も、この時点でデータを完璧にしておくことが現実的なケースであれば、ここで訂正をやりきるに越したことはないと思います。
（ただ、実際には現実的じゃないことが多いから悩ましいのです）

ポイント	エラー検知の根拠	訂正時に人が見る画面
①	OCRに組み込まれたエラー検知機能 例：確信度、型違反、帳票上の数字同士の検算など。 　　何ができるかはOCR製品による。	OCR製品が提供しているエラー訂正画面

メリット：帳票とデータを見比べやすい

OCRに組み込まれた検証機能を使う最大のメリットは、帳票とデータを見比べやすいことです。

OCRの検証機能は大抵、帳票と取得結果を対応させて画面表示する機能を標準装備しているためです。

以下は筆者がいつも使っている IQ Bot の検証画面です。

画面左型が、OCRの取得結果です。誤りを検知した項目は赤枠で表示されます。
画面の右側では、抽出の元となった帳票のイメージです。抽出結果の項目にカーソルを当てると、該当項目の帳票上の場所をハイライトで表示してくれます。

画面の作り方は各OCR製品によって様々ですが、いずれの製品も、帳票と取得結果を見比べて修正しやすい画面をそれぞれに工夫して作っています。

こうした画面を自前で作ろうとすると、かなり大がかりな開発になってしまうでしょう。

そのため、抽出結果と画面の見比べやすさを重視するのであれば、OCR備え付けの検証機能を使う手段は最適であるといえます。

デメリット：OCRが検知できる誤りには制約がある

帳票と抽出結果の見比べやすさはたしかに大きなメリットですが、OCR備え付けの検知機能は万能というわけではありません。

特に、検知できる誤りの種類に制約があるという点は抑えておくべきでしょう。

以下に、OCR備え付けの誤り検知機能で検知できる誤りと、できない誤りを列挙してみます。

※一般的な傾向を述べたものです。製品によって差がありますので、検討中の製品が下記のとおりであるかどうかは個別に確認してください。

OCR備え付けの検証機能で検知できる誤り

#	検知の種類	詳細
1	必須チェック	必ず書かれているはずの項目が空欄となっている場合に検知
2	型チェック	数字しか書かれないはずの項目に数字以外が入っている、などの場合に検知
3	正規表現によるパターンチェック	電話番号、メールアドレスなど形式が決まっている項目が、その形式に合致しない場合に検知
4	項目同士の相互検算	「税抜価格＋消費税が税込価格になっていなかったらエラー」、「明細行の合計が合計欄の金額と一致していなかったらエラー」など、帳票の中にある数字の読み取り結果を検算する
5	リストチェック	都道府県の名前や部署名など、特定の選択肢の中に読み取り結果と合致するものがない場合に検知
6	OCRの確信度によるチェック	検出した文字のOCR上の確信度が一定の水準を満たさない場合に検知

OCR備え付けの検証機能では検出できない誤り

上記の「検出できる誤り」はいずれも、「帳票とOCRの世界だけで判断できる誤り」であることにお気づきでしょうか。

逆に、**「誤りかどうかを判断するために、外部のデータとの突合が必要」**というケースは、OCR備え付けの検証機能では検出できないことが多いです。

具体的には、以下のようなチェックが、OCR備え付けの検証機能では実現できないことが多いです。

• 顧客名が顧客データベース上に存在しているかのチェック
• 見積番号をもとに、見積時の金額を受注管理システムから読み取り、帳票上の金額と合っているかをチェックする

上記もあくまで一般論です。

製品によっては、API連携などによって外部システムと連携した誤り検知機能があるかもしれませんし、予算があるのなら、そうした誤り検知を含めてカスタマイズをしてくれる業者を選ぶというのもひとつの手だと思います。

ですが、一般的にOCRに備え付けのエラー検知機能は、できる検出方法に制約があるという点は押さえておくとよいでしょう。

「どういう種類の誤りを検知できるか」という点は、精度などに比べると見過ごされがちですが、実はOCR製品選定の大きなポイントのひとつです。

② RPAのロジックで検証する場合

OCRに備え付けの機能では対応できない誤り検知が必要な場合は、別の方法を検討することになります。

よく候補に浮上するのは、RPAによる処理結果の検証です。

RPAで処理結果を検証する場合は以下のように、検知のロジックをRPA側で持つことになります。

ポイント	エラー検知の根拠	訂正時に人が見る画面
②	RPAのロジック 例：DB上に存在しないID、変換エラーなど。	OCRの処理結果（csv、Excelなど） （RPA側の作り込みによる）

メリット：多彩な検証が可能

OCR結果の検証をRPAで行うメリットは、多彩な検証が可能なことです。

OCRに備え付けの機能では賄いきれない、外部データ・外部システムへの問い合わせを含むデータの検証も、RPAであればお手のものです。

デメリット①：帳票とデータの見比べはしづらい（見比べをしやすくする仕組みの開発が必要）

誤りの検知においては万能感の強いRPAですが、検知された誤りを人に見やすく表示するという部分では、弱みが出やすいです。

例えば画面の構築機能がないRPAの場合、検知したエラーを人が修正する際には、帳票やシステム、データベースなどの情報を結局手動で漁り、直すべき部分を探し、直すという作業が必要になります。

これはけっこう面倒です。

RPAの製品によっては、以下のような画面を簡単に作れるものもあります。

こうなると、手動で必要なデータを拾ってくるよりはかなり確認が楽です。

それでも「取得結果と帳票上の位置を連動させてハイライト表示する」というような、OCRの備え付け機能ほど芸の細かい作り込みは難しいでしょう。

もちろん、RPA以外のシステム（プログラミングなど）を駆使して、予算や工数をかけて画面を作り込めば、OCRの備え付け機能に引けを取らない画面を作ることが技術的に不可能というわけではないはずです（OCR側のAPIの仕様にもよります）。

長くなりましたが、まとめると以下です。

• OCRの備え付け機能なみの見やすい画面をRPAだけで作ることは難しい
• RPAも製品によっては画面を作ることができるが、OCRの備え付け機能ほどの器用さはない
• OCRの備え付け機能なみの見やすい画面を自前で作ることは可能かもしれないが、予算や時間が必要

言い換えれば、OCRの備え付け機能なみの画面を自前で作り込むだけの技術力や、予算や時間があるのであれば、このデメリットはあまり気にしなくてよいとも言えます。

デメリット②：後続の入力システムにも組み込まれているであろう業務ロジックを二重に持つことになる

RPAで誤りをチェックするデメリットの２点目は、後続システムの入力チェックにも組み込まれているであろう業務ロジックを二重に持つことになるという点です。

先述の画面の件に比べると地味ですが、より本質的な（＝技術力や予算では解決できない）問題です。

具体的には、どういうこと？

例えば、帳票から読み取った得意先コードが正しいかどうかを確認するために、「得意先マスタに存在する番号かどうかを確認する（ヒットしなければエラー）」というロジックをRPAに組み込むとしましょう。

もちろん、RPAで得意先マスタを検索して、ヒットしたかどうかをチェックすることは可能です。

ですが、その結果をもとに受注管理システムに自動入力する、というような処理を想定していたとしましょう。
すると受注システム側でも当然、「入力された得意先コードが得意先マスタにあるか」というチェックはかけているわけです。

RPAにチェック機能を組み込むことによって、もともと受注管理システムに備わっているエラーチェックを、RPA側でも二重に持つことになるというのはそういう意味です。

何が問題なの？

同じロジックを異なるシステムで二重、三重に持っていると、そのぶん保守が大変になっていきます。

あるシステムの仕様を変更したときに、二重、三重に持っているシステムも同様に直す必要が出てくるからです。
少なくとも、直さなくてよいかどうかの影響確認は必要になります。

こうした二重・三重の修正や影響確認は、いわゆるレガシーシステムに多額の保守費用がかかっている元凶にもなっている問題です。

③ 後続処理の入力チェックでエラーを検知する場合

最後のパターンが、後続処理の入力チェックでエラーを検知する方法です。

これは、②に挙げたRPAによるチェックの逆を行く方法です。

「どのみち後続処理にはエラーチェックが組み込まれているのだから、エラーの検知はそこに任せよう」と割り切り、RPA側では後続処理側でエラーが出たときに、人に通知する部分だけを担当します。

ポイント	エラー検知の根拠	訂正時に人が見る画面
③	後続処理側の入力チェック機能 （画面の入力エラーなど）	後続処理次第だが、通常はエラー画面

メリット：無駄が少ない（どのみち最終的なチェックはここでかけることになるため）

この方法の最大のメリットは、無駄が少ないことです。

すでに現行システムに組み込まれているエラーチェック機能を活用し、RPAはその結果をハンドリングするだけなので、RPA側の作り込みが軽くてすみます。

デメリット：処理のボトルネックになりやすい

一方、デメリットとしては、処理のボトルネックになりやすいという点が挙げられます。

後続処理が画面入力の場合を想定すると、以下のようなケースでエラーが大量発生すると、特にボトルネックになりやすいです。

• 処理対象のデータが大量にある
• 画面の挙動が遅い、または画面を使用できる端末（ユーザー）数が限られている

まとめ：メリデメを押さえて、「自分たちはどうするのか」を考えよう

以上、OCRが読み込んだ結果の検証（誤りの検知と訂正）を組み込むフロー中の位置と、それぞれのメリデメを見てきました。

何度も繰り返しますが、この記事で書いたメリデメは、あくまでも一般的なものです。
各メリットやデメリットがどれほど重要な影響を持つかは、自動化したい業務によって異なります。

例えば処理するデータのデータ量もそれほど多くなく、後続処理の入力画面も挙動が早く、端末やユーザーの数も問題ないのであれば、パターン③のデメリットは極めて小さくなるといえるでしょう。

逆に、帳票の処理量が非常に多く、予算も十分にかけられるプロジェクトであれば、パターン②でエラーを検知するRPAを組み込みつつ、専用の検証画面を作り込むという手段もあるでしょう。

この記事で紹介した検証方法と各種のメリデメを参考に、みなさんの構築したいフローにあてはめながら、「どこに検証を組み込むのがいいのか」を考えてみてください。