概要
RPA (Robotic Process Automation)ってそもそも何でしょう？元々バッチスクリプトやオブジェクトモデル (Excel VBA etc.) を駆使してのプログラミングでの自動化を行っていた時代から、GUIが主流になりそのうえで動作するアプリケーションも大規模化してきたことから、2000年代前半からGUIのテスト自動化や、中国へのテストのアウトソースプロジェクトなどが盛んにおこなわれるようになってきました。
実はRPAの老舗といわれるBlue Prism (2001年)や、Automation Anywhere (2003年)、UiPath (2005年)といったグローバルの主要RPAベンダーは、いずれも2000年代前半に創業しています。当初はソフトウェア業界のテスト自動化のニーズから用途が広がってきたようです。
RPAの基礎技術自体は実は20年も前からある？
RPAがブームになり始めたのはAI市場と働き方改革が盛り上がってきた2017年くらいからですが、元になるソフトウェアや技術自体は20年も前からあったわけです。RPA自体のまとめについては、@nh321 さんの「RPAって結局何なのか？どうやって選べば良いのか？」がしっくり来ましたので参照してください。
ちなみに、このRPAですが、どのように動いているかについて考えてみたことはありますか？単純なバッチスクリプトやオブジェクトモデルとRPAの違いであるGUIの操作の部分の技術ですが、もともとはテストの自動化やアクセシビリティ対応の用途で提供されていたOSのサービスを使って実装されています。その性質の違いから、主に4つの種類に分けられます。RPAソフトウェアによってどの技術に対応しているかが若干違いますが、一般的な話としてまとめてみました。
1.マウスとキーボード操作のエミュレーション
最初の方法は一番基本的、かつ元々RPAの「人間のパソコン操作を模倣しよう」という発想の原点からくる方法です。この方法はRPAという名前がつくソフトウェアのほぼすべてで実装されています。
Windowsをはじめとするオペレーティングシステム (OS) は、OSの持っている基本機能を外部から呼び出すための仕組みとしてAPI (アプリケーションプログラミングインターフェイス)というものを持っています。これはOSごとにデザインが異なります。WindowsはWin32 APIというライブラリを持っており、この中にキーボード操作やマウス操作をエミュレーションするAPIが含まれています。(たとえばkeybd_event(), SendInput(), SetCursorPos() など) RPAソフトウェアで、これらのAPIの対になる、キーボード操作やマウス操作を記録するAPIを使って人間の操作を記録しておき、再生時にこれらのAPIをコールすることで、あたかもキーボードやマウスが操作されたかのようにパソコンを動かすことが可能になります。
この方法の弱点
ちょっとした画面の条件の違い (微妙にマウスがずれているとかウィンドウサイズが変わっていたとか)に弱く、うまく初期条件をあわせないと誤操作になってしまうのが弱点です。
2.画面要素分析 - UIAutomation (Windowsアプリ)やDOM (ウェブページ)など
もう少し確実な方法として、キーボードやマウスが操作された位置のUI要素を分析して、再生時に同じUI要素に対して操作を行うようにするものです。画面の構成要素として、Windowsアプリであれば本体ウィンドウの中に、以下の画像一覧にあるようなテキストボックスやコンボボックス、リストボックスなど様々な UI が全てウィンドウで構成されて、親子関係を構築しながら同期して表示されています。ウェブページも同様です。そして、それぞれの構成要素にアクセスできるAPIが UIAutomation (Windowsアプリ) やその前身であるMSAA、そして DOM (ウェブページ)というインターフェイスです。
これらのライブラリが Windows (Windows XP/Windows Server 2003以降、.NET Framework 3.x以降) や主要ブラウザーに組み込まれた (Internet Explorer 5以降) のも2000年代前半でした。
UiPath、BluePrism、Automation Anywhere はこれらの仕組みを標準で使っています。BizRobo! (Kofax RPA)は、Desktop Automation Serviceという本体と別の技術を併用することでUI Automationを使っているようです。最近まで開発環境のDesign Studioとは別の端末にインストールする必要がありましたが、2019年6月のバージョンアップ(10.4以降)でDesign Studioと同じ端末にインストールできるようになったようです。WinActorはUI Automationには対応していないようです。
UI Automation
UI Automation は、Windows/.NET Framework のライブラリで、Windowsの画面を構成する画面要素 (基本、すべてウィンドウからできている) の親子関係やプロパティを同じフォーマットで取り出すことができます。歴史的には、C/C++/Visual Basic など、使われる言語やライブラリーによって情報の取れ方が異なっていたのですが、UI Automation によって同じインターフェイスに統合され、開発者は実装の違いを気にする必要がなくなり使いやすくなりました。また、UI Automationは後述する DOM のオブジェクトも同様に取り扱うことができるため、ウェブページ内の画面要素であっても同じフォーマットで取り出すことができます。
UI Automation を使って画面要素を解析する方法は「画面スクレイピング」と呼ばれることもあります。
Windows SDK に含まれるInspect.exeというツールを使うと、この画面要素一覧とその関係をツリービューで表示させることができます。
図: メモ帳とフォントダイアログボックスを構成する画面要素の親子関係とプロパティをInspect.exeで表示
また、UiPathも同様のツール「UI Explorer」が同梱されていて、選択した画面要素の中に含まれる子供の要素やプロパティを表示します。
図: メモ帳のフォントダイアログボックスを構成する画面要素の親子関係とプロパティをUI Explorerで表示
Blue Prismも同様のツール「UI Automation Navigator」が同梱されています。
HTML DOM
ウェブページ内の画面要素の親子関係とプロパティを同じフォーマットで取り出す仕組みが DOM (Document Object Model) です。ツールとしては、Firefox のウェブ開発モードで見るとビジュアルにわかりやすく理解できるかと思います。
図: Yahoo! の検索ボックスの画面要素、プロパティ、HTMLタグの構造をFirefoxウェブ開発モードで表示
よく言う「ウェブスクレイピング」「データスクレイピング」は、この仕組みを使って情報を取ってきます。
この方法の弱点
一見、完璧に見える方法ですが、この方法も構造がないカスタムドローイングにはお手上げです。ビジネスアプリケーションの中には UI Automationがサポートする標準的なお作法に沿っていないアプリケーションが多く存在します。たとえば Windows コントロールとしての実態はウィンドウとしてないけれども、描画だけはボタンを書いている、しかも特定の位置にマウスカーソルを置いた時だけ現れる、といった場合です。SAP アプリケーションは特殊な画面描画を使っている箇所があり、特異な動きをするため、自動化には専門のテクニックが必要です。
DOMによるウェブページの解析は、URLを変えずに画面要素だけが変わっていくような非同期描画の場合にはうまくいかない場合もあります。
また、Citrix / バーチャルデスクトップや、iOS/Andoroid などのエミュレーター、Linux 画面コンソールなど、別の仕組みで描画された画面全体を転送しているようなアプリケーションでは、中の構造を UI Automation で見ることはできず、ほかの方法を使うことになります。
3.AI 画像認識や、その他のAI技術
この方法は、画面上の要素を画像としてとらえ、特定の画像があった場所に操作を行ったり (画像マッチング)、画像上から文字列を読み取って操作を行う (OCR, Optical Character Recognition、光学的文字認識)といった手法です。画像認識は比較的最近、深層学習などのAI技術の発達により精度が上がってきている領域です。商用のRPAソフトウェアは画像認識エンジンを搭載しているものが多く、WinActor、UiPath、Automation Anywhere、Blue Prismなどの主要RPAソフトウェアはいずれも機能を搭載しています。
また、画面上の認識だけではなく紙の帳票を電子的に読み込み、その中の文字列をOCRで認識させてフォームのフィールドの場所によって何の文字列なのか (名前、住所、電話番号など) も認識してパソコンの特定システムに入力するようなシナリオも実装されるようになってきました。主要な商用のRPAソフトウェアは、OCRエンジンは著名なOCRソフトウェアベンダー、AIベンダーの製品のOEMエンジンを搭載したり連携できるようにしたりする手法をとっており、RPAソフトウェアは「AI技術を実際の業務に適用するためのワークフローソフトウェア」としての役割を担っています。
この方法の弱点
OCR/画像認識の技術は、まだ精度があまり高くなく、画面上のパターンであれば Windows の解像度、画面の配色、ソフトウェアの初期設定などによっても大きく影響を受けるために、ほかの方法でうまくいかない場合の最後の手段として使われることが多いです。
その他のAI技術～変更点の自動認識、AIで考えるRPA
現在のところRPAでは、人間が定義した定型業務を自動化するに留まりますが、AIの技術も取り入れて一部非定型業務の自動化 (自然言語解析、画像解析、音声解析、機械学習、知識ベース搭載による非構造化データの認識)を行ったり、将来的には高度な自律化 (深層学習や自然言語処理を踏まえたプロセス分析/改善/意思決定/判断) までできるようになることを目指しています。
| クラス | 主な業務範囲 | 具体的な作業範囲や利用技術 |
|---|---|---|
| クラス1 RPA (Robotic Process Automation) |
定型業務の自動化 | 情報取得や入力作業、検証作業などの定型的な作業 |
| クラス2 EPA (Enhanced Process Automation) |
一部非定型業務の自動化 | RPAとAIの技術を用いることにより非定型作業の自動化 ・自然言語解析、画像解析、音声解析、マシーンラーニングの技術の搭載 ・非構造化データの読み取りや、知識ベースの活用も可能 |
| クラス3 CA (Cognitive Automation) |
高度な自律化 | プロセスの分析や改善、意思決定までを自ら自動化するとともに、意思決定 ・ディープラーニングや自然言語処理 |
参照元: 総務省ニュースレター
RPAソフトウェアベンダーの、RPAが単なる「パソコン画面操作の記録/再生」ソフトから脱却するための取り組みも始まっており、AI技術を使ったボットのメンテナンス軽減 (少し画面が変わっても追従できる)機能なども実用化しはじめています。
例: Automation Anywhere のAISenseによる画面変更への自動追随による保守性向上
4.特定アプリのAPIの利用
以上 3 つが、特にRPAソフトウェアとして特徴的な技術でしたが、4つ目として、いわゆる昔からあるバッチスクリプト、オブジェクトモデル/アプリケーション独自のAPIコールなどが、RPAソフトウェアにも使われています。
これらの技術を使って自動化できるのであれば、そもそも操作再現の確実性も高いですし処理速度も速いため、実際にはこれらの技術とも組み合わせて使われることが多いです。ただし、そもそもこういったAPIがないアプリケーションを操作したいとか、コーディングがIT開発者以外には難しいのでRPAソフトウェアが役割を担っている面もあるため、RPAの中での位置づけとしてはあくまでも補助的な側面が強いといえるでしょう。
画面操作以外に必要な技術～ボットの「個人技能」と派遣会社の「監督機能」
いままでの 4 つの技術は「ボットができること」、つまり労働者派遣業にたとえると「派遣社員個人の能力」を支える技術でした。労働者が2～3名に収まるのであれば問題ないかもしれませんが、RPAによる投資対効果を出すために数十、数百の規模でボットを働かせるのであれば、「派遣社員を管理する派遣会社の能力」(もしくは業務委託、BPOを受ける会社の監督能力)が重要になってきます。
具体的には、野良ボットを発生させない仕組み、ログインパスワードを安全に管理して配布する仕組み、スケジューリングや負荷分散機能、プロジェクトの変更管理機能、セキュリティ＆コンプライアンスを順守する仕組みなど、ボットが集団で長期間動作する環境を整えて管理監督する仕組みが実際には必要になってきます。
RPAソフトウェアの比較の際には「ボットの個人技能」の比較ばかりに目が行き意外と見落とされがちですが、監督機能をきちんと実装しているRPAソフトウェアはごく少数しかありません。 個人技能だけであればフリーの労働者 (=フリーソフト)でもよい部分もありますが、企業で組織的に導入をするとなると、管理機能なしでの運用はお勧めできません。
まとめ
いかがでしたでしょうか。一言で「RPAを支える技術」といっても、20年も昔からあるものもあれば、直近の第3次AIブームで発展してきた技術により実装が可能になってきたものもあります。また、昔からある技術はOSやプラットフォームに依存するライブラリを使っているため、Windows 以外のプラットフォーム、たとえばいまやWindows よりも多くのユーザーがいる iOS や Android などのスマートフォンOS上のRPAが出ていないのは、これらのOS上で同様のライブラリが出ていないことも関係します。
画面レコーディングのコマンドについても、RPAソフトウェアによっては複数の方法を提供しているものがありますが、これが、今まで見てきた「画面認識/操作技術」を選択させるものです。どの方法も100%正確にはできないため、何を操作するのかによってどれを選択するのが最善なのかをRPAボット作成者にゆだねているわけです。
図: UiPath の画面レコーダーの選択肢
図: Automation Anywhere の画面レコーダーの選択肢
RPAボット作成者としては、コーディングを行うほどの技術は必要ありませんが、この記事で出てきたような、Windows やウェブページのプログラミングについての基礎知識を認識したうえで操作をする必要があることがわかります。もちろん、そんな知識がなくてもごく基本的な画面操作であれば問題なく完了することはできますが、少し複雑になってくるとRPAボット作成者が知識を元に判断しなければならないことが出てくる (特にエラーが出てデバッグしないといけないとき!) ため、Windows / ウェブプログラミングを全く知らなくていいというわけにはいかないのです。
最後までお読みいただきありがとうございました。