目次

「RPA」は「AI」を含むが、「RPAツール」は「AI」を含まない

「RPAツール導入」のホントのとこ

「AI」と「RPAツール」のおいしいレシピ

まとめ

「RPA」は「AI」を含むが、「RPAツール」は「AI」を含まない

言葉遣いは大切だ。

とかく「AI」というテーマにおいて、併せて語られがちな「RPA」。確かに「RPA」は、「自動化に向けた【取り組み】」を指すため、「AI」を含む文脈で語られることに間違いはない。しかし大抵の場合、「RPA」が「取り組み」という概念的な話ではなく、実際の手段として「AI要素を含んだソフトウェア」の意味で語られており、それは明らかに間違いである。

「RPAの実現手段の一部であるソフトウェア」（※以後「RPAツール」とする）には、現状、私の知る限り「AI」の要素はない。あくまでも、ルール化された作業を自動的に実行するためのツールである。ツールが自己判断でそのルールを変えたり、追加で設定したりはしない。
もし、あなたの身の回りで、こういった認識が誤ったまま、言葉だけが先行した形で「RPA導入」話が進んでいる場合、または進めようとしている場合、後々、利用者から「なんだAIじゃないのか」「全部設定しないとだめじゃないか」「こんな手間がかかるものは使えない」という反響が寄せられるのは必定なので、早いうちに関係者で言葉の再定義とすり合わせを行うべきだ。

「RPAツール導入」のホントのとこ

Wikipediaを見てみると、「コード不要」・「無停止」・「ユーザビリティ」の３つが「RPAソフトウェア」の特徴とされているが、ハッキリ言ってうそだ。こんなうたい文句を真に受けてはいけない。

まず、「コード不要」についてだが、GUIによる設定が可能でプログラムは書かなくても良いとはいえ、実際はプログラムを書くに等しい行為（処理フローの設計、各画面項目の入出力設定と処理のマッピング、等々）とそのための知識が必要で、業務ユーザが【数週間のトレーニング】でそういった知識を身につけることができるわけがない。
「無停止」についてもうそっぱちで、連携ファイルや画面項目がちょっと変われば止まるし、逆に、エラーハンドリングをきっちり組めるわけでもないので何かが起こった場合に止まることなく処理が流れてしまう危険性もある。
そして、「ユーザビリティ」についてだが、「RPAは容易に扱うことができ、技術的なサポートをあまり要求されない」とあるが、前述の通りで、まぁ、そんなわけがないというのはお察しである。

現状、世の中に存在する「RPAツール」とは、端的に言えば
『GUIで設定可能で、画面操作ができるExcelマクロ』
である。

業務部門の担当者から「集計がうまく動かないんだけど、どうにかしてくれ」と、見たことも聞いたこともないExcelを添付送付され、VBAの辞書片手に修正対応。そしてその後、今度は「この前はどうも。ところで、〜〜みたいな事ができないと困るんだけど、これちょっと直してくれない？」と知らぬ間に専属マクロ係にされてしまった…といったような経験を少なからずお持ちであろう読者諸兄姉に、今こそお伝えしたい。

『「RPAツール」をバラまくと、そのつらい経験が周辺システムも巻き込んだ形でスケールアップしてやってくるぞ』

と。

そこで、章タイトルに戻るわけだが、実際問題、果たしてこんなモノが業務方のメンバーに扱えるだろうか？
仮に扱える猛者がいたとして、皆さんの預かり知らぬところで独自に自由な進化を遂げ、シン・ゴジラが如く手の付けようもない立派な野良RPA（管理者の手を離れて、独自に複雑に進化して、のちに誰も管理できなくなった状態）として再び現れるのを黙って見過ごして良いものか？
数回の全体説明での操作トランスファやルール説明で、統制を利かすことが可能であろうか？
答えはいずれも「No」のはずだ。

というわけで、「RPAツール」の全社展開だけは絶対にやってはいけない。取り返しのつかないことになるし、なにより本来出せるはずの効果が出ない。
通常のシステム導入と同様に設計・運用・保守を含め、専任チームにて対応するべきだ。

「AI」と「RPAツール」のおいしいレシピ

さて、「RPAツール」の導入について、少々熱く語ってしまったが、この連載のタイトルは「AI導入、ホントのとこ」であったことを今思い出したので、この章では「AI」と「RPAツール」を一緒に扱う場合について所見を述べたいと思う。

先述の通り、「AI」と「RPAツール」は別物なので、並び順としては①「AI」→「RPAツール」か②「RPAツール」→「AI」になる。

①「AI」→「RPAツール」の場合
まず、①「AI」→「RPAツール」の場合については、「AI」を「RPAツール」起動のためのトリガーとして使う、というのが最もポピュラーな形であろう。
例えば、問い合わせメールの内容を「AI」にて解析・分類し、「RPAツール」にて自動返信・問い合わせ対応をさせる、といったような使い方である。具体的には、「AI」処理の結果をCSVファイルなりDBなりに出力し、それを定期的に「RPAツール」が監視し、変化があった場合に処理実行する仕組みを構築する。
一気通貫での完全自動化を実現できるので効果的かつ導入効果が数値化しやすいため「AI」導入のユースケースとしては優れているが、「AI」に100％は無いのでクリティカルな用途での利用は避けた方が良いということと、先述の通り「RPAツール」は異常系に弱いため、人手による運用体制は残しておく必要があるということには注意いただきたい。

②「RPAツール」→「AI」の場合
次に②「RPAツール」→「AI」の場合では、「RPAツール」に学習用データ収集や前処理（データ加工）を実施させるケースが想定される。しかしながら、「RPAツール」には非機能面での不安があるため、あくまでも、システム化の前段階、すなわちPoTやPoCにおける暫定手段としての利用にとどめるのが良いだろう。システム化にあたっては、専用のバッチ処理をきちんと作ったほうがよい。

まとめ

正直なところ、AI関連サービスの開発を生業としている会社以外が、「画像認識」「文字認識」の開発に手を出すのは、筆者は控えるべきだと考えている。
「画像認識」は金がかかって難しすぎるし、「文字認識」は業務個別の要素が少なく一企業が独自に作る理由がない。
つまり、この記事の読者諸兄姉におかれては、避けて通るが吉ということだ。
素晴らしいサービスが世の中に出てきたら、それを使ってどうしようかを考えるスタンスがオススメである。