RPA適用業務は半分近くがOCRと絡むともいわれており、帳票を読み取って電子化して自動化をしたいというニーズは多い。RPAソフトウェアの多くもOCR機能を標準で内蔵して、これに応えている。しかし、OCR関連のプロジェクトでPoCを実施する際には「はまりポイント」が存在し、検証段階で頓挫してしまうプロジェクトも結構あるという。筆者もいくつかのプロジェクトを見てきたが、このはまりポイントの事を「精度100%の壁」と仮に呼ぶことにした。OCRプロジェクトがはまってしまう理由を、OCRエンジンの現状を踏まえながら見ていき、対応策を考えてみることにする。
主なAI-OCRエンジンの種類とその精度
まず、日本市場でRPAソフトウェアと一緒に使われることが多い主なOCRを見てみよう。AI-OCRというのは、最近のOCRエンジンは従来の技術に加えてディープラーニングの技術を使って文字の認識や帳票レイアウトの認識を行うことで精度を向上させているためにそう呼ばれているが、要はAIで機能が向上したOCRエンジンということである。また、帳票をたくさん集めて自分でトレーニングを行うことで、運用開始後に精度を向上させることができることが特徴である。
以下の表にOCRの製品名をまとめてみた。「連携する(予定の)RPA」には、連携する主なRPAソフトウェアを入れた。カッコがついていないものは標準機能としてRPAソフトウェアに同梱もしくは呼び出し用の標準コマンドがついている。カッコがついているものはメーカーとして連携することを発表しているものだ。ただし、OCRエンジンで読み込んだ画像をバッチでRPAソフトウェアに渡すことでどのようなOCRソフトウェアとも連携は可能なので、ここで記載がないからと言って連携ができないわけではない。
| 製品名 | 製造元 | 連携する(予定の)RPA | 説明 |
|---|---|---|---|
| Amazon Computer Vision API | AWS | AWSのクラウドOCR API。 | |
| Flexcapture Engine | ABBYY | UiPath1、Automation Anywhere2 | 広く普及しているOCRエンジンの老舗。活字であれば英語も日本語も精度は高いが手書きは対応していない。 |
| DX Suite | AI inside | (WinActor3)、(UiPath4) | クラウド。日本語手書きの精度が高く日本でシェアNo.1と自称している。認識精度は98%程度3。 |
| Flax Scanner | シナモン | オンプレミス。クラウドにデプロイも可能。日本語手書きの精度が高いと定評がある。 | |
| Google Vision API | グーグル | UiPath1 | クラウドAPI。手書きは英数字、日本語とも高いようである。 |
| Microsoft Computer Vision API | マイクロソフト | UiPath1、Automation Anywhere5 | クラウドAPI。手書き英数字の精度は高いが日本語には対応していない。 |
| Microsoft Office Document Imaging (MODI) | マイクロソフト | UiPath1、Automation Anywhere2 | Microsoft Office 2007まで付属していたOCRエンジン。オンプレミス。NuanceのOmniPageがベースになっている。精度はそこそこ。Office 2007はすでに延長サポートが終了しているので、SharePoint Designer 2007のダウンロードも終了しており、現在MODIは入手できない。 |
| Tegaki | CogentLab | (Automation Anywhere6) | オンプレミス。クラウド構成も可能。日本語の手書き文字で精度が高いと定評がある。 |
| Tesseract OCR | Open Source | UiPath1、Automation Anywhere2、Blue Prism7 | オープンソースのフリーのエンジン。オンプレミス。精度はそこそこ。日本語にも対応している。 |
読者が気になるところは、それぞれのOCRエンジンの精度であろう。活字の場合、手書きの場合、もしくは利用シナリオによって精度は異なってくるので一概にいうのは難しいが、いままでのプロジェクトで検証してきた経験でいうと、「そこそこの精度」と記載しているものは90%前半未満、「高い精度」と記載しているものは95%以上といったところが目安である。最も精度が高い部類のもので98%くらいまで出るようであるが、98%というと高いように聞こえるかもしれないが、たとえばA4 400文字のテキストを読み込むと数文字は間違っている可能性がある、という精度である (単語辞書により文字の修正/補完ができる場合がある)。
また、上記の前提として、原稿の取り込み時の解像度が200DPI 以上あることが多くのOCRソフトウェアの前提となっている。たとえばFAXで取り込んだ原稿は100DPI以下のことが多く、漢字などはつぶれていて人間でも読みにくいことが多い。このようなケースでは精度が大きく落ちることも覚えておこう。
「精度100%の壁」～結局は人による再チェックが必要?
そこでユーザーから出てくる声は、たいてい「精度は100%にならないのか。ならないと使えないではないか。結局人が再度チェックして品質保証をする必要があるのではないか。」ということである。そうなのである。これは、どのOCRソフトウェア、どのRPAソフトウェアを選んでも必ずぶちあたる課題である。ちなみに、RPAソフトウェア自体はOCRエンジンを独自では持っておらず、OCR専門メーカーのエンジンをOEMで内蔵していたり、クラウドAPIをコールしているだけなので、RPAソフトウェアの選定は精度には影響しない (RPAソフトウェアが独自で帳票レイアウト認識機能を持っている場合は別であるが)。そして、どのOCRエンジンを使っても現状は精度は98%程度よりもよくはならない。すると、PoCをやっては見たものの、思った通りの精度が出ないで頓挫してしまう、これが「精度100%の壁」である。
対応策
それでは、RPA+OCRによる紙文書の電子化は、紙のアーカイブをするくらいで取り込んだテキストからの自動化は難しいのかというと、シナリオを選んで設計をきちんと考えれば対応できるケースもある。以下の2通りのケースを紹介しよう。
1. 異なる複数の方法で検算できるシナリオで使う
「精度が100%ではないから人間が再度チェック」の部分をさらに別のRPAのロジックで検証できる場合がある。たとえば、配送先住所の伝票であれば、郵便番号辞書、電話番号辞書から住所の検索ができるため、OCRで郵便番号を読み込みそこから検索した住所と、OCRで読み込んだ住所のテキストを比較して検証することができる。電話番号があれば、そこからも住所テキストを得ることができる。正しいことが検証できればパスさせ、正しくない場合はもう一方のデータで補完してパスさせる。補完できない場合はエラーとして人間のチェックに回す。このような手順を踏むと、実際に人間が再チェックしないといけないケースをかなり抑えることができる。
このようなことができるのは、一般に検証用のデータベースが使える場合である。(一般的にデータベースが出回っていない場合は、作ることでも対応できる場合がある。)
例:
- 住所 / 郵便番号 / 電話番号の読み取り
- 部品番号 / 品名の読み取り
- 駅名、地名の読み取り
- 学校名の読み取り
ちなみに、一般的に手書きよりも活字、日本語文字よりも英数字の方が精度が出る。時には98%よりももっと優れた精度が出せるときがあり、そのようなシナリオに絞って利用する手もある。
2. 精度が出なくても使えるシナリオで使う
もうひとつのケースは、精度がでなくても使えるシナリオで使うことである。たとえば、OCRで読み込んだテキストを検索エンジンにフィードして紙文書を検索可能にしたり、それを元にタグ付けをするような場合である。タグ付けは必要に応じて後で人間が付け替えることもできる。
まとめ
OCRとRPAを組み合わせたシナリオで検証を始めようとする場合は、PoCを始める前に、このプロジェクトではどれくらいの精度が必要なのか、精度が出ない場合はどのような検算の仕組みが可能なのか、精度は妥協できるのかをあらかじめ設計してから始めたほうが良いだろう。また、現在のOCRの精度はそんなに高いわけではないので、精度に過度な期待はしないほうが良いだろう。