RPA＋AIで紙文書を自動処理する時代がすぐそこに！　UiPathの「Receipt and Invoice AI」プレビュー版を試す

　残念ながら、まだ英語しか処理できないが、日本語対応が実現すれば、RPAの需要は劇的に伸びるだろう。UiPath Studio向けにプレビュー版が公開された「Receipt and Invoice AI」を実際に試してみた。

「UiPath Studio」にベータ版のパッケージを追加すると、AIを使って請求書や領収書から情報を取り出せるようになる

紙文書に意味を持たせるRPAに期待すること。

　その中の1つに間違いなく含まれるのは、「文書の自動処理」だろう。

　受け取った注文書を元に発注処理をする、届いた請求書を元に支払いの処理を進める、応募された履歴書をデータ化して選考に活用する、などなど……。

　数え上げればキリがないこうした処理は、どの企業でも時間と人手を取られるやっかいな業務だ。

　ここにこそITの力を借りたいところではあるが、注文書や請求書、領収書など、企業に集まる文書は、デザインや文言がバラバラで、ここから情報を取り出すのは、なかなかやっかいだ。

現状はRPAでもまだやっかいな文書の処理が、AIによって自動化される時代がすぐそこに来ている

　封筒から取り出した文書をチラリと見て、「ああ、●日までに××円、■■宛てに振り込まなきゃ」なんて判断ができるのは、人間だからであって、これを自動化しようとすると、文書から日付を取り出したり、単価、小計、税額、合計金額などの似たような数値データから、合計金額を識別しなければならないなど、なかなかやっかいだ。

　とはいえ、OCRでテキストを抽出し「合計金額：」などの見出しを手掛かりに数値を取り出すようにするなど、それなりに方法はある。しかし、複数のフォーマットに対応させたり、「合計」「合計金額」「TOTAL」など異なる文言に対応させるのは、やはり面倒な作業が必要で、さらに、取引先の都合でデザインが途中で変わる度に、処理に手を加えなければならないこともある。

　もちろん、今はAIの時代なのだから、クラウド上の各種サービスを活用するという手もある。だが、請求書を処理したければ、請求書用のエンティティを定義したり学習に時間をかけてモデルを作ったり、意外に手間が掛かる。

　筆者もIBMの「Watson」を使って、いろいろチャレンジをしてはみたものの、学習のベースに使うサンプルを集めるのが大変（自分のところにある請求書だけだと種類が限られる）なので、なかなか難航している。

　そんな中、RPAベンダーとして知られるUiPathから、「Receipt and Invoice AI」のベータプログラムが公開されたわけだ。

「Receipt and Invoice AI」のプレビュー版は、UiPathのフォーラム「Receipt and Invoice AI - Now available in Public Preview!」で入手できる

　具体的には、「Machine Lerning Extractor」と呼ばれるアクティビティ（UiPath Studioでさまざまな処理を実現するパーツの1つ）で、領収書または請求書のデータを入力として与えると、クラウド上のAIサービスと連携し、その中から「billing-addr」「invoice-no」「date」「total」など、あらかじめ定義した分類情報から、欲しいデータを自動的に抽出してくれるものだ。

　前述した「ああ、●日までに××円、■■宛てに振り込まなきゃ」というシーンで、目と脳の役割をRPAに持たせることができるわけだ。

　冒頭でも触れたように、請求書は英語とスペイン語、領収書は英語とルーマニア語にしか対応していないので、日本で使えるようになるのはまだ先だが、非構造化文書をRPAで手軽に扱えるようになる日は、どうやら遠くなさそうだ。

シンプルなワークフローのサンプルを作ってみる

ベータ版のパッケージを追加する

今回作ったワークフロー

　動作条件や事前の準備については、前掲したUiPathのフォーラムへの投稿を参照して欲しいが、簡単に言えば、パッケージマネージャーにベータフィードをソースとして追加した状態で、「UiPath.IntelligentOCR.Activities」と「UiPath.MachineLearningExtractor」を追加すればいい。

　フォーラムには、アクティビティの使い方と動作する様子のビデオ、サンプルのワークフローも掲載されている。ただし、説明は英語で、サンプルもそれなりに複雑なものとなっているので、今回はもう少しシンプルなサンプルを作成してみた。

　UiPath.IntelligentOCR.Activitiesは日本語化されているので、だいぶ見やすくなったが、大きな流れとしては、以下6つのステップとなる。

2.タクソノミーのロード

　タクソノミーは、分類の定義だ。これをあらかじめ読み込んでおく。

　タクソノミーとして読み込むデータは、「タクソノミーマネージャー」と呼ばれる専用のUIを使って、あらかじめ定義しておく。

　例えば請求書なら、送付元の企業名（name）、住所（Vendor-Addr）、請求書番号（invoice-no）、日付（date）、合計金額（total）、税額（tax）などといった具合だ。加えて、それぞれに格納するデータの型（TextやNumber）を定義しておく。

　要するに、文書から取り出したい項目を定義しておく部分だ。

項目を定義するタクソノミーマネージャー

英語の請求書は正確に認識する

　というわけで、英語の請求書のサンプルをインターネット上からダウンロードして試してみたが、なかなか正確だ。

　請求書の場合、表形式になっている明細の部分が認識されにくいようで、同じ請求書で試しても、表の部分が認識されたりされなかったりする。ただし実際の処理で使いそうな、名前や日付、合計金額などのデータは、ほぼ確実に拾ってくれる。

　PDFだけでなくJPGも処理可能で、郵送で届いた請求書などでも、スキャンして取り込んだデータを読み込ませれば、同様に処理できる。

英語版の請求書はかなり正確に読み取ってくれる

試しに日本語の請求書をリクエストしてみたが、日付しか認識できなかった

　クラウドへリクエストを投げるので、1つ1つの処理には数秒を要する。大量処理を行うには工夫が必要となりそうだが、それでも人が請求書を見て、宛先や金額を判断して、別のシステムに入力し直すといった操作よりも、はるかに高速な処理ができそうだ。

　個人的には、今すぐにでも日本語版が欲しいところだ。

　請求書、領収書、注文書など、いろいろな処理に応用できれば、RPAの適用の幅は飛躍的に広がるし、中小零細、個人事務所などでも、これさえあればRPAによる自動処理を自前で導入できる。

　繰り返しになるが、UiPathの日本法人には、最優先で、この日本語化に取り組んで頂きたいところだ。