はじめに
こんにちは。
RPAベンダーの社員でありながら、OCR関係のPoCを年間100件ほどやっているIQぼっちです。
OCRに対する認識度や関心は日々高まっているのを肌で感じている一方で、以下のようなつまづきを感じている人もまた非常に多く目にしてきました。
- 紙を使っている業務を効率化したいのでOCRを検討してみたが、ニーズに合う製品がない
- 精度以外に、どういう観点で製品を選べばいいのかわからない
- RPAと組み合わせて運用したいが、どういう部分に気をつけて構築すればいいのかわからない
また、「紙＝OCR」という定式が広まりすぎたせいなのか、実は解決したい課題に馴染むのはOCRとは別の技術領域なのに、「紙だから」という理由だけで「OCRで解決しよう」という考えに凝り固まってしまっているように見える人もかなりいました。
この記事では、OCRを使って何がしたいのかを切り口に、
- 本当にOCRで解決するべき課題なのか
- OCRでないとしたら、どのような解決策があるのか
- OCRで解決する場合に、注意するべきポイント
を考えていきます！
やりたいこと別・OCR導入時の留意点
さて、本編です。
ここでは、OCR導入の要件としてポピュラーな5つの利用ケースを挙げて、各ケースに固有の注意点や効果的な解決方法を見ていきます。
- データを単純に保管したい場合
- 紙の情報をシステムに入力したい場合
- 紙に書かれた内容の正当性を確認したい場合
- 記入・押印・印紙等の有無を確認したい場合
- 画像やPDFの内容からファイル名をつけて整理したい場合
上記のどのパターンであっても、処理したい帳票のタイプによって実現の難易度や、要件に対応できるOCRの種類も変わってきます。
OCRにどのような種類があり、それぞれがどのような帳票に対応しているかを知りたい方は、以下の記事をあわせて参照してください。
それではいよいよ、利用ケース別の留意点を見ていきましょう。
1.データを単純に保管したい場合
最初の例は、いま紙で保管している情報を「単純にデータとして保管したい」というケースです。
それも、紙をPDFにして保管、とかではなく、文字ベースの情報として保管したい、というケースですね。
一件シンプルに見えるこのユースケースですが、正確性の要件が最もシビアになりがちなのがこのパターンです。
「データとして保管はしますが、データの正確性は80%程度ですがいいですか？」と聞かれて、首を縦に振れる人はあまりいないでしょう。
そして、こうしたデータを100％の正確性で保管したいとなった場合に、問題となるのが「何をもって正解／不正解を判断するのか」ということです。
後述する「システムへの入力」のケースのように、鏡になるデータと突合するなどして機械的に正確性をチェックできればよいのですが、アーカイブされている帳票を単純に保管するというケースの場合、突合する相手がいないことがほとんどです。
したがって、このユースケースで特に注意した方がいいのは以下の点です。
単純なデータ保管の際の留意点
- 正確性をどこまで求めるかの基準を明確にしておく
- 100%の正確性を求める場合、人の目による検証が不可欠であることを踏まえてフローを構築する
2.紙の情報をシステムに入力したい場合
次は、おそらくOCRの利用目的の中でもっともポピュラーであろうパターンです。
OCRによるデータ化をしたあと、何かしらのシステムに入力をしたいというパターンですね。
「現状、人が紙を見ながらシステムに転記をしているような作業を自動化したい」というパターンです。
OCR x RPA の典型的なユースケース
このケースはまさに、今流行りの「OCR x RPA」で対応することになるパターンです。
それゆえ、OCRとRPAをそれぞれ単品で検討してあとでくっつけるよりも、RPAとOCRを検討段階から一緒に比較し、入力まで含めた一気通貫のフローを最も効率的に実現できるソリューションは何かという視点で考えるとよいでしょう。
OCRの精度が高くても、RPAとの相性によっては、一気通貫で処理するフローの構築が難しいケースがあるためです。
このケース特有の注意点 ： 「検証をどこで行うか」をきちんと整理しよう
製品を問わず、この利用ケースに全般的に当てはまる注意点は、**「検証をどの時点で行うかをきちんと整理すべし」**ということです。
ここがうまく整理できていないと、こんな事態になりかねません。
データの正確性をどの時点で保証するのが最も効果的なのか、言い換えれば、どうすれば最も人の仕事を減らせるかを考えて、フローを整理しておきましょう。
以下がその整理の例です。
もちろん、上記はあくまでも一例であって、「OCRの誤り検知機能を使うべきじゃない」とか「既存データとの突合処理を独自に組むのは意味がない」と言っているわけではありません。
紙の情報をシステム入力する際の留意点（まとめ）
- OCRとRPAを組み合わせた一気通貫のフローで、何が一番スムーズかを考える
- 入力データの正確性をどの時点で担保するのか、最も効果的な方法を考える
3.紙に書かれた内容の正当性を確認したい場合
続いてこちらは、紙に書かれている内容が「正しいかどうか」が確認できればOKというケースです。
例えば、「請求書をOCRで処理したいんです」というユースケースをよくよく掘り下げて聞いてみると、単純に「合計金額が納品された金額と合っているか否かが確認できれば良い」という要件である場合が一定の割合であります。
これをOCRで処理するということは、掘り下げるとこういうことですね。
この考え方、決して間違いではないです。
緑の部分が目的で、その目的を達成するために紫のフローを構築する。
そのためにOCRが必要だ、と。
確かに。間違いではないです。
ただ、**「単純に合っているか否かだけを確認したいという目的に対して、回りくどい手段をとりすぎ」**の感も否めません。
シンプルに目的を考えると……
上記の図の中で、シンプルに目的を考えるとこういうことですよね。
上記の図の中で「もうちょいシンプルな何か」と示した部分が現状、なぜシンプルじゃないのかを考えると、こういうことだと思います。
図の吹き出しと重複しますが、
- 請求書（紙）の画像データを開くのが面倒
- 請求書と鏡になるデータを探してくるのが面倒
- 請求書とデータを突合した結果、処理を振り分けるために必要な作業が面倒
というあたりが、どうやら解決したい真の課題のようです。
ストレートに課題を解決！
そうだとすれば、OCRなどという回りくどい手段をとらなくても、現状課題になっているポイントをもう少し直接的に解決する方法もとれます。
たとえば以下のようにです。
画面の左側には紙をスキャンした画像／右側には突合対象のデータが表示され、「合っているか合っていないか」をチェックするだけのシンプルな画面です。
OCRを使ってはいませんが、こういう画面があるだけで人間の確認作業が各段にラクになります。
「結局、人間が確認するんかーい！」というツッコミの声も聞こえて来そうですが、仮にOCRを入れる場合でも、人間の確認は基本的には、ゼロにはなりません。
上記の画面は2021年2月19日の「AA de Knight」で紹介した、Automation Anywhereの「AARI（Automation Anywhere Robotic Interface）」という機能のデモの一部です。（そのうちYoutubeで動画が公開されるそうです。公開されたらリンクを貼ります。）
AARIは要するに、「Botと対話的に使える画面を簡単に開発して使えますよ」というだけの話なのですが、「金額が合っているかどうかさえ確認できればいい」というようなケースであれば、このような機能で十分という考え方もできます。
確認するべき項目が多い場合は？
これまでは、請求書の合計金額など、帳票上のただ１つの項目があっているか否かを確認したいという要件を例に考えてきました。
項目が２つ、３つに増える程度であれば、上記のような簡単な画面を作るだけでも対応できるかもしれません。
ただ、確認する箇所が5か所、10か所と増えていくごとに、画面だけでは確認が大変になります。
目的が突合や正当性の確認であっても、１帳票あたりの確認するべき項目がある程度多い場合は、OCRを使う価値があるかもしれません。
紙情報の正当性を確認する際の留意点（まとめ）
- OCRにこだわらず、シンプルに「確認を楽にする」という手段もあわせて検討する
- 項目があまりにも多い場合は、OCRの利用も視野に入れる
4.記入・押印・印紙の有無を確認したい場合
続いて、今度は署名や見積番号などの情報が「書いてあるか書いていないか」や、「押印があるかないか」という、「あるかないか」の確認のためにOCRを使いたいというケースですね。
ひとつ上で紹介した「正当性を確認する」というケースとかなり似た面がありますが、更に輪をかけてOCRという手段のまわりくどさが際立ちます。
押印や印紙の有無の検出は、OCRとは別の技術領域
OCRは Optical（光学式） Character（文字） Recognition（認識）の略です。
「光の力で文字を読むよ」、要するに文字を読むためのソリューションなわけです。
一方、押印や印紙の検出となると、文字というよりは、ハンコや印紙（切手）の絵があるかないかを判断せいという話ですよね。
こうした絵を判断する技術は、画像認識、あるいはオブジェクト検出といって、OCRとはまた違ったAI技術の領域になってきます。
どこまで自動化するかは、費用対効果次第
押印や印紙の有無を確認しなければならない書類の数が莫大であれば、それらのオブジェクト認識をするAIを個別に開発（発注）して実装するのもよいでしょう。
とはいえ、個別にモデルを作り込むような画像認識のAIは一般的に、OCRと比べると高額になります。
「そこまでお金をかけられないよ！」という場合は、先ほど紹介したような「簡単に設計できる画面」＋「人の確認」で代用するという手もあります。
記入・押印・印紙等の有無を確認する際の留意点（まとめ）
- 「有無の確認」と「OCR」は技術的にはマッチ度が低いことを心得る
- 大量の処理をさばくのであれば、画像認識などの別のOCR技術を開発（発注）するのも手
- そこまで予算をかけられない場合は、単純に「人間の目視をしやすくする」という発想で対応するのも手
5. 画像やPDFの内容からファイル名をつけて整理したい場合
利用目的の最後のパターンは、「画像やPDFの中の文字をベースに、ファイル名をつけて整理したい場合」です。
これも比較的よくあるニーズです。
こちらも、もしOCRでやるとしたら、「OCRxRPA」の利用が必須になるパターンです。
要件のシンプルさと、実装の難易度のバランスはどうか
このユースケースは要件がシンプルなだけに、あたかも実装も簡単かのように錯覚されているケースが多いです。
「サクッと拾って、サクッと自動でネーミングできればそれでいいからさ♪」というノリです。
ですが、「サクッと拾って、サクッと自動でほしい項目を拾ってくる」というのは、実はOCRにとっては非常に技術的難易度が高い要求だったりもします。
なぜそれがそんなに難しいのかがピンと来ない方は、こちらの記事を参考にしてみてください。
現状、ファイル名をつける作業にかなりの人手や負荷がかかっていて、「是が非でもこの作業を自動化したい！」という場合なら、OCRを利用する価値はもちろんあると思います。
ですが、もしもこの利用ケースを思いついたのが「サクッとできると思ったから」という理由であれば、ちょっと考え直した方がいいかもしれません。
すみません。サクッとできると思ってました。。。という方へ
すみません。サクッとできると思ってました。。。
でも、OCRではサクッとできないとしても、何かサクッとできるやりかたで今より効率化したいんです！
という場合は、次のようなやりかたも考えられます。
上記のような画面とファイルネーミングのBotであれば、小一時間もあれば作れてしまいます。
「結局、入力は人じゃねーか」と言われそうですが、「ファイルを開いて→帳票の種別と取引先を覚えておいて→ファイルを閉じてから名前を変更する」という作業に比べたらずいぶん楽にできます。
まとめ：やりたいこと応じて、広い視野で実現手段を考えよう
以上、一般的にOCR案件として考えられがちな様々な利用ケースについて、
- 本当にOCRで解決するべき課題なのか
- OCRでないとしたら、どのような解決策があるのか
- OCRで解決する場合に、注意するべきポイント
を見てきました。
また、OCRを利用する場合にどのような製品を選べばよいかについては、以下の記事が参考になるかと思います。
「紙＝OCR」という考えに凝り固まらず、「業務効率化」という広い視野で最適な手段を選ぶ一助となれば幸いです。