前回は、RPAの業務継続性を検討する上で網羅すべき観点について説明しました。RPAが停止する原因の大半はシステム障害ではなくアプリケーションエラーであること、RPAにおいては数分程度のダウンタイムが許容されない状況はほとんど発生せず、待機用のマシンを用意しておけば十分であることなどをお伝えしました。
最終回となる今回は、RPAの今後について考えてみます。
RPAは疎結合の手段!?
筆者が社会人になりたての2000年頃、SOA(Service-Oriented Architecture:サービス指向アーキテクチャ)の活用がいかに重要であるかがしきりに喧伝されていました。複数のアプリケーションを、ガチガチなコーディングによって密結合するのではなく、Webサービスなどの汎用的なAPIを活用してネットワーク経由で連携すべきですよ、という考え方です。
翻ってRPAを考えるとき、筆者は、当時と類似するトレンドをRPAのなかに見い出しています。つまり、「RPAは、疎結合にできるアプリケーションの種類を爆発的に増やした」という捉え方です。
シンギュラリティとRPA
RPAを人間の代替として進化させようという論調が、昨今の流行となっているようです。
しかし筆者は、この発想はやや短絡的であると考えています。RPAのクラス2、クラス3に相当するAI機能が、将来的にRPAに組み込まれることは当然であるかのように論じられていることに、違和感を覚えます。
クラス | 主な業務範囲 | 具体的な作業範囲や利用技術 |
---|---|---|
クラス1 RPA (Robotic Process Automation) |
定型業務の自動化 | 情報取得や入力作業、検証作業などの定型的な作業の自動化 |
クラス2 EPA (Enhanced Process Automation) |
一部非定型業務の自動化 | RPAとAIの技術を用いることによる非定型作業の自動化 (自然言語解析、画像解析、音声解析、マシンラーニングの技術の搭載。非構造化データの読み取りや、知識ベースの活用も可能) |
クラス3 CA (Cognitive Automation) |
高度な自律化 | プロセスの分析から改善、意思決定までを自動化(ディープラーニングや自然言語処理を利用) |
出典:総務省『RPA(働き方改革:業務自動化による生産性向上)』
その違和感の1つの原因は、この議論の出発点が、業務ではなく、RPAそのものであるせいかもしれません。「なぜRPAがAIの要素を持たなくてはいけないのか?」「なぜRPAがディープラーニングや自然言語処理をできないといけないのか?」。その必然性に疑問が残ることは、第1回でも触れたとおりです。RPA自身がどんどん進化していくことは、「何かすごそう!」ではあるものの、「その進化は本当に実用的な意味があるのか?」、「その進化はシステム全体の開発効率の観点で本当に最適なのか?」といった追求が、まだまだ不十分であるように思うのです。
2045年には、コンピュータ(AI)が人類の能力を超えると予想されています。このタイミングを、世の中では「シンギュラリティ」と呼ぶようです。その頃には、もしかしたらRPAは現在のようなかたちを取っていないかもしれません。RPAに内包されたAIという考え方はもはや過去のものとなり、物理的なロボットがAIを内包し、物理的な世界全般を自動化しているのかもしれません。
先ほど、SOAからRPAに至った技術的ブレークスルーについて述べましたが、このような物理的なロボットは、それと比べ物にならないスケールのブレークスルーを人類にもたらすでしょう。
技術革新がもたらす技術的ブレークスルーの変遷を、予想も含め、表にまとめてみました。
時期 | 連携手段 | 連携対象 | ||
---|---|---|---|---|
アプリ(API) | アプリ全般 | 物理世界全般 | ||
2000年頃~ | SOA | ○ | ― | ― |
2015年頃~ | SOA+RPA | ○ | ○ | ― |
2045年頃~(?) | SOA+RPA+物理ロボット(AI)(?) | ○ | ○ | ○ |
SOAやRPAが2045年まで存続する保証はありませんが、これらを包含する何らかの機能は残るでしょう。
技術はいつ爆発的にヒットするのか
技術の商業的な成功には、さまざまな外的要因があります。その成否を事前に知ることは、条件が十分に与えられていない方程式を解くのと同様、非常に難しいことです。
例えば、自己学習アルゴリズムの1つとして現在活用されている「ベイズ推定」は、その元となる理論が発表されたのは18世紀のことです。ベイズ推定とは、条件付き確率を発展させた考え方です。その後、この理論は統計学へ応用されました。しかし、この理論が実際に機械学習に応用され始めたのは、コンピュータが世の中に登場してからしばらく経った、ここ数十年のことです。コンピュータの性能が、ベイズ推定を実用化するところまで、ようやく追いついてきたということなのでしょう。これに加え、AIの流行や、ベイズ推定の適用対象となる具体的なユースケースの存在なども、ベイズ推定が活用されようになった理由に挙げられるでしょう。
別の例として、iPhoneの成功の背景には、製品デザインやユーザビリティに対する消費者の共感がありますが、それに加えて、通信を支える基盤技術や、ネットワーク通信環境、コンピュータの小型化など、さまざまな外的要因も無視できません。
逆の発想をすると、AIを内包する非常にインテリジェントなRPAがあったと仮定して、それを商業的に成功させるための外的要因が、今の世の中にあるでしょうか。具体的かつ説得力のあるユースケースは何でしょうか。AI機能は、本当にRPA(のみ)から呼び出すべきものでしょうか。筆者はAIがRPAに内包されていくことが当然と考える方向性の議論が、あまりにもRPAだけに焦点を当てたアカデミックな発想に思えてなりません。
RPA礼賛から、RPAの真の有効活用へ
昨今、Web記事の論調が「RPAに対する手放しの礼賛」から徐々に「RPAだけでなく、BPMなどの外部の仕組みを導入すべき」「RPA導入には、業務プロセスの見直しが不可欠」「業務改革において、RPA導入そのものが目的化してしまってはいけない」といったものに変わってきていると感じます。これは、望ましい傾向なのではないかと思います。
RPAは、手段の1つに過ぎません。RPAありきで議論を進めるのではなく、本当に必要とされているものは何なのかを冷静に見極め、業務の全体最適を図っていきたいものです。
* * *
筆者が本連載を通じてお伝えしてきたことは、実際の顧客とのやり取りを通じて得られた知見がベースとなっています。そのため、内容が技術的に尖り過ぎていてトレンドから大きく外れているということはないですし、観点が極度に偏っているということもないと考えています。
本連載が、読者の皆様がRPAを考える上での一助となれば幸いです。
著者紹介
![]() |
ペガジャパン株式会社
シニア ソリューション コンサルタント
金井 盛隆 (Moritaka Kanai)
2012年11月より現職。ペガジャパンの親会社である米ペガシステムズ社が2016年4月にオープンスパン社を買収したことに伴い、同年6月よりRPAのプリセールス活動を開始。これまでの提案企業は50社を超え、導入検証、実プロジェクトでの実装経験もある。
小さい頃から大きな車を運転することが夢だったため、学生時代に大型免許を取得。しかし、現在に至るまで活用シーンはなし。趣味はビール、ラーメン(主に二郎系)、映画鑑賞。
前職は日本オラクル (2000年4月~2012年11月)。2児の父。