36歳中小ベンダーSEが社内SEに転職しました！

チャットボットの記事も久々ですね。

ここ数ヶ月、どちらかというと自作RPAの方に注力していたので、チャットボットの取り組みは停滞していました。

それもある意味仕方ありません。
RPAの方は提供したら必ずかつすぐに効果が表れるのに対し、チャットボットの方は効果があるかどうかも未知数なものですから。
なので、どうしても作業の優先度が低くなってしまうのです。

とは言っても、全く何もやっていなかったわけではなく、チャットボットによって問合せを自動応答できるようなネタが無いか、デモを交えながら様々な部門にヒアリングして回っていました。

で、結果はと言うと・・・

我がシステム部門以外は、自動化できず。（汗）

意外と、定型的な問合せって、少ないもんですねぇ。。。
各部門とも、数個ぐらいずつは定型的な問合せがあるんですが、その程度のものをチャットボット化したところで、誰も使いません。

システム部が比較的多いものの、それでも全体の問合せの約3割程度。
3割と聞くと意外と多いように思う人もいるかもしれませんが、私が他部門の社員だったとすると、たぶんボットには質問せず、直接システム部門に電話で聞くと思います。（苦笑）

このため、少なくとも当社においては、チャットボットは殆ど業務改善に貢献しないというのが、私の印象でした。



その上、もう一つ問題が発覚しました。

それは、Slackのセキュリティの甘さにあります。

①ユーザーのファイルアップロードを禁止できない
②接続元のグローバルIPを限定できない

当社は、業種の特性上、多くの個人情報を扱っています。
このため、セキュリティ対策は他の業種よりもかなり厳しく、社内のPCから外部にファイルを持ち出すなど論外。

なのに、チャットボット導入のためにSlackを全社展開してしまうと、このセキュリティ対策に穴を空けてしまうことになるのです。

実は、①のファイルアップロード制限ができないことは、元々知っていました。
でも、接続元のグローバルIPが限定できれば、社外へのファイル持ち出しはできないので、問題は無いと考えていたのです。

が、、、

よくよく見たら、グローバルIPを指定できるのって、ボットに対してだけやん。（汗）

ボットに対してだけは、社内PCからしかつながらないように設定可能です。
しかし、Slackユーザー同士は、普通に自宅PCやスマホからでもつながってしまうのです。

なんつー無意味な設定項目・・・

事前調査が甘かったですね。
色々ググってみると、アップロードされたファイルを監視して日次で削除するようなバッチを作って運用しているケースもあるようですが、当社の場合はアップロードから削除までのタイムラグがある時点でアウトです。

Slackを通じての社内情報漏洩が完全に防げないとなると、残念ながらチャットボットを導入するわけにはいきません。
効果が無いかもしれないとなれば、尚更です。

そんなわけで、期間的には半年ちょい取り組んできたAIチャットボットですが、ここであえなく導入見送りとなりました。
今後、Slackのセキュリティ機能が強化されたら再検討するかもしれませんが、望み薄っぽいですね。。。

還元率の高いポイントサイトで、ハイペースでポイントが貯まります

AIチャットボット導入の実現が難しくなったのは、前回書いた通りです。
ただ、これでAI関連の取り組みが終了すると、経営層からは非難を浴びそうな気がしたので、代わりのネタを用意しておきました。

それが、今回のタイトルでもある、「AI画像認識を活用した、手書き文字のテキストデータ化」です。

つまり、文書のOCR読み取りをAIでやるってことです。

ご存知の方も多いと思いますが、この分野は今やRPAに並ぶ勢いで市場が伸びています。

特に、日本の役所や銀行、それに民間企業では、とにかく紙で書かせる文書が多い。。
ハンコも押させないといけないからっていうのもあるんでしょうけど、これが長年の間、日本の生産性向上の足枷になってきたのです。

で、当社においても例外ではなく、やはり毎月数百枚に及び手書き文書を回収し、それを見ながら担当者がシステムに手入力していくっていう業務があちらこちらにあるのです。

が、1年ほど前から、このどうしようもないと思われた業務の改善に、クモの糸が垂らされました。

AI画像認識の技術で、画像中の文字だけを抽出することができるようになったのです。
で、これを皮切りに、OCRとして活用しようという動きが盛んになってきています。

一応、市販製品としては、ベンチャー企業のコージェントラボが開発した「tegaki」がかなり評判が良く、導入企業も増えているらしいです。

が、月20万円～かぁ。。。
これを高いと見るか安いと見るかは、対象の手書き文書の枚数によるでしょうねぇ。

これも一応視野には入れつつ、やはりここはチャットボットやRPAと同様に、まず自作で安く仕上げる方法を模索してみましょう。（笑）



現在では、Watsonをはじめ、AzureやGoogle Cloudなんかでも、OCR用のAPIが公開されています。

識字率を調べてみたところでは、Google＞Azure＞Watsonらしく、Watsonは日本語非対応なので、実質GoogleかAzureになると。
で、Googleは無料枠が月1000トランザクションしかなく、超過後は1000トランザクションごとに300円ぐらいかかります。
で、Azureだと、無料枠は月5000トランザクションで、超過後は1トランザクションごとに0.15円ぐらいずつかかると。

そう考えると、当社の規模ならAzureだとずっと無料で使い続けられそうな気がするので、まずはAzureで試してみることにしました。

早速、Freeプランでアカウントを作り、画像認識サービスであるComputer Vision APIのリソースを作成。
ここで、エンドポイントURLとAPIキーを控えておきます。
ちなみに、ここまでで約5分ぐらい。
（色々説明書きを読みながら進めたので、それがなければ1分ぐらいで終わってしまう・・・）

その後、認識を試してみるために、Postmanをインストールして、ちょこちょこ設定した後、いざ画像を送信。

で、で、できとる・・・（驚）

JSON形式のレスポンスを確認すると、ちゃんと座標位置と抽出された文字が返ってきてました。
しかも、今まで使っていたOCRソフトでは手書き文字が誤認識されることが多かったんですが、かなりの精度で正しく認識されています。

Googleの方がさらに認識率は高いらしいですが、Azureでも十分すぎる結果でした。
ちなみに、ここまでで約20分ほど。

チャットボットのときも思いましたが、ホントもうベンダー要らずの時代が来そうだな、コレ。

最大の懸念点だった認識精度ですが、今回Computer Vision APIを試してみて、あっさりとこの点がクリアされていたところに、時代の流れを感じました。

ちなみに、Computer Vision APIの日本語認識では、1文字ずつしか認識されません。
つまり、「日本語」という文字が書かれた画像を読み取ると、「日」「本」「語」という感じで、1つの文言にならずに分割されてきます。
これは仕様なので、これを自力で連結する仕組みを開発しなければなりません。

考え方としては、認識された文字の座標がセットで返ってくるので、「この座標範囲にある文字群は1つの文言と見なし、連結する」というプログラムを作る感じです。
まさしく、OCRの考え方ですね。

ネットを見ると、結構Pythonで連携プログラムを作っているケースが多いようですが、VBAからでもAPI連携してJSONを解析することが割と簡単に実現可能です。
なので、ユーザーの利便性も考慮し、Excelマクロで諸々のプログラムを開発してみようと思います。

還元率の高いポイントサイトで、ハイペースでポイントが貯まります

前回、AIによるOCRの手始めとして、Azureの「Computer Vision API」を試してみました。

テスト用のサンプル画像を読み込ませた感じでは、結構正しく識別できてそうでしたが、果たして業務で使用する文書はどうか。。。

ということで、今回は実際に当社で使われている手書き文書のうち、勤務表を読み込ませてみることにしました。

当社の場合、社員はWEB勤怠を使って打刻をするのですが、パートやアルバイトの方々については、手書きの勤務表が使われています。
理由は、所属長の承認印が必要なためです。

まぁ、ここでも日本のハンコ文化という悪しき風習がムダな業務を生んでいるわけですが、一旦それは置いておきます。

実務で使っている文書の中から、勤務表を最初の実験台に選んだのには、理由があります。

それは、勤務表から読み取ればよい文字は、基本的に数字・記号だけでOKなため、識別の難易度が低いと考えたからです。
逆に言うと、このレベルの文書が上手く読み取れないとなれば、他の文書には適用できないということになります。

さて、では早速勤務表を読み込ませてみよう・・・の前に、事前準備が必要。

前回触れた通り、Computer Vision APIでは、日本語識別モードにすると結果のテキストが1文字ずつ返ってきます。
なので、勤務表の結果をそのままJSONファイルで検証しようとすると、途方もない行数を見ることになってしまい、効率的ではありません。

なので、今回はPostmanではなく、Excel VBAで連携処理と結果の文字結合処理を作りました。
文字結合処理は、前回の最後に書いた「この座標範囲にある文字群は1つの文言と見なし、連結する」というロジックになります。

構想はこの土日で固まっていたので、今日他の業務をやりながらでも、だいたい半日ぐらいでプログラミングできました。



前置きが長くなりましたが・・・いざ実行！

そして項目ごとに結合された文字列を恐る恐る見てみる。。。

結果は、ハーフハーフってとこですかね。（苦笑）

うーん、、、
プレ印字されている数字は完璧に読み取れているんですが、肝心の手書きの認識結果があまり良くないですねぇ。

例えば、"1"の書き方にちょっとクセがあると"["として誤読されてしまうのは、まぁご愛敬。
確かに、そう見えなくもないので。

しかし、なぜか日付によっては、誤読どころか全く読み取られていない日もあったりします。
せめて、多少間違っててもいいから何か読み取ってくれれば、プログラムで補正しようもあるんですが。
全く読み取られていないと、欠勤しているのか読み取りミスなのかが判別できません。
（文字の濃さも、ちゃんと読めているところと同じぐらい）

前回、サンプル画像で試したときの結果が割と良好だっただけに、ちょっと予想外。
ほぼCompute Vision APIで行こうと決めていたのに、どうやらWatsonやGoogleも真剣に試してみた方が良さそうです。

結果は、また後日。

還元率の高いポイントサイトで、ハイペースでポイントが貯まります