ぐん税ニュースレター vol.30　page02　-RPA通信-

これ、データにできる？　そう言って見せられたのは10ページほどのPDF。
プリントに手書きをしてスキャンしたのか、ノイズや傾きがあってキレイとは言えず、所々が黒塗りでマスキングされたものでした。
できますよー、と答えて、私の頭に浮かんだ方法は２つ。
 
1．GoogleのCloudVisionAPIやMicrosoftのReadAPIを利用する
2．既にインストールされている読取革命を利用する
 
読取革命は古めのバージョンなので、精度で言えば１の方が良いに決まっています。しかし、１の方法だとプログラムなりRPAなりをいじって使えるようにしないといけないんですが、どうやら急ぎらしい……。という訳で、この時は読取革命を使うことにしました。
単なる文章ではなく、表形式や左右でパラグラフが分かれているページが多かったため、読取革命を使っても、まあまあ時間が掛かりました。
 
それは良いとして、誰でも気軽に使えるようなOCRシステムを作りたいな、と思いました。ベースとなるツールがどれだけ凄くても、普通の人はそれだけでは使えません。目に見えるUIが必要になるわけです。
もちろん、探せば無料のサービスもあります。そこはまぁ、休日のお遊びということで。

レシートや医療費領収書のOCRにはCloudVisionAPIを使っているんですが、今回は以前の記事（vol.24 page.6）でもご紹介したComputerVisionのReadAPIを使っていきます。
UIにはkintoneを利用することにして、画像をアップロードしてプロセスを進めると、OCR結果がレコードに反映されるようにします。

最初はPowerAutomateのkintoneコネクタを使って、プロセスを進めたときに起動するように組んでみました。動作としては上手く行ったのですが、処理時間が掛かりすぎました。
OCRのレスポンスは見たままの文章として返されるのではなく、1文字1文字の座標、確度、種類といった諸情報がまとまっています。

この中から文字自体を拾いつつ、座標情報をもとに並び変える処理が必要になるわけです。
PowerAutomateでも何とか実装したのですが、処理に5分以上掛かってしまい実用的ではありません。
 
そこで、kintone側（Javascript）単体で構築しようとしたのですが、今度はAPIからレスポンスを受け取るところが上手くいかず。
最終的に kintone（アップロード） -> PowerAutomate（OCR） -> kintone（整理） という形になりました。

別ウインドウで再生されます

どうでしょう？　速度的には充分なレベルになったのではないでしょうか。
まだ、1行の長い文字列または改行した文字列にしかできず、画像ファイルにしか対応していないので実用性は低いですが、たまに使う程度なら充分です。
 
もっとも、これが活かせる業務がなければ無用の長物なのですが……。
 
※画像領域を設定している機能はこちらを参考にさせていただきました。

システム部　田中