
RPAの仕組みを調べると、開発画面とかロボットとか、いろんな言葉が出てくるけど、なにがどうなっているの?全体の仕組みを、図解して教えてください。
という疑問に答えてみようと思います。
「RPAツールの仕組み」と「RPA実行環境の仕組み」の2つに分けて解説します。最後に「RPAとRDA」というトピックに簡単に触れて、終わります。
- [1] RPAツール(ソフトウェア)の仕組み
- 部品
- プログラム(シナリオ)
- シナリオ作成ツール
- ロボット
- [2] RPA実行環境の仕組み
- 全部入りパターン
- 開発実行分割パターン
- 一元管理パターン
- [3] RPAとRDA
記事を書いている僕は、RPA関連の書籍を5冊出版しているRPAの専門家です。7年以上、複数の会社でRPAの導入・開発・運用に携わっています。
RPAと一口に言っても、様々なツールがあります。
この記事では、日本でシェアが大きいUiPath、WinActorを意識して解説します。この2つはだいたい同じような仕組みですから。
それでは、どうぞ!
[1] RPAツール(ソフトウェア)の仕組み

RPAツールの仕組みについて、簡単に解説していきます。
部品
最初は「部品」からです。
RPAツールには、自動化の部品が最初から用意されています。

上図にあるように、
- Excel起動
- ブラウザー起動
- ボタンクリック
- テキスト入力
- メール送信
などが、最初から部品として用意されています。
プログラム(シナリオ)
これらの部品を並べて、プログラムを作ります。
下図のようなイメージですね。

これで、複雑な自動化処理を組むことができるわけです。
RPAではこういった処理の記述を「プログラム」とは呼ばないで、「シナリオ」と呼ぶことが多いから、今後はシナリオと呼びますね。
「業務のシナリオを書く」というイメージで、表現しているわけです。部品を組み合わせて、シナリオを作る、というところまでわかりましたね。
シナリオ作成ツール
さて、このシナリオを作るためには、専用のツールが必要。
ここでは「シナリオ作成ツール」と呼びます。

シナリオ作成ツールを使って、シナリオA、シナリオBというように、たくさんのシナリオを作ります。
ここまでOKですね? では、続きです。
ロボット
作成したシナリオは、置いておくだけでは動きません。なので、作成したシナリオを動かすためのツールが必要です。
これを「ロボット」と呼びます。

「ロボットがシナリオを動かす」というのは、システム的な言い方かな?
一般的な言い方だと、「ロボットにこういうことをしてくださいね、というシナリオを渡す」ということになります。
ともかく、ロボットがシナリオ通りに自動化を実行してくれるわけです!
ただし!
「シナリオ作成ツール」から、シナリオを実行することもできるので、シナリオ作成ツールのことをロボットと呼ぶツールもあります(UiPathやWinActorは違いますが)。
ややこしいですね。
「ロボット」の指し示す対象については、さらに色々なパターンがあるので、後ほど、もう一度出てきます。
[2] RPA実行環境の仕組み

ここまでの仕組みは、ソフトウェアについて、でした。いったん、頭の片隅に置いておいてください。
さて、ここからは、パソコン(ハードウェア)を含めた環境について、解説します。
3つのパターンがあるので、シンプルな方から順番に解説しますね。
全部入りパターン
1つ目は、全てのツールを1つのパソコン(PCと呼ぶ)に入れて、運用するパターンです。

『全部入りパターン』とでも呼びましょうか。
『全部入りパターン』では、
- シナリオ作成ツール
- シナリオ
- ロボット
が全て1台のPCに入っています。
自分のPCでシナリオを作って、自分のPCで動かすわけです。
シンプルですね。
すべて、入っているので、RPAツールがインストールされているPCのことを「ロボット」と呼ぶこともあります。
このときは、シナリオ作成ツール、シナリオもロボットですし、厳密な定義はあまり意味がありません。
けっこう、RPAに対して、この『全部入りパターン』をイメージしている人が多いかも。
開発実行分割パターン
2つ目は、「開発用のPC」と「実行用のPC」を分けるパターンです。

『開発実行分割パターン』と呼びましょう。
開発担当者は、開発PCでシナリオ作成ツールを使って、シナリオを作ります。
開発PCでテストを行って、「ちゃんと動くな、よし完成!」となったら、実行PCにシナリオを置きます。
このことを
- 実行PCにシナリオを「配置」する
- 開発PCから実行PCに、シナリオを「配布」する
などと、言います。
参照>>UiPath|パッケージ配布の問題点
実行PCでは、開発せず、シナリオを実行するだけです。
この『開発実行分割パターン』だと、開発ライセンスの数を少なくできるので、中規模(実行PCが10台未満)になってきたとき、費用面でメリットがあります。
一元管理パターン
3つ目は、複数の開発PCと実行PCを、運用管理ツールで一元管理するパターンです。

『一元管理パターン』と呼びますね。
『開発実行分割パターン』で、問題が発生するくらいの規模になったときに有効です。
たとえば、下記のような問題です。
- シナリオが多くなってきて、どの実行PCでどのシナリオが動いているか、分かりにくい
- 実行PCが多くて、シナリオの配布がめんどくさい
- ライセンス数が何十、何百になって、管理ができない
また、こういう要望も出てきます。
- シナリオのバージョン管理をしたい
- 自動的にスケジュール実行したい
- 自動実行した結果を一元管理したい
- セキュリティを強化して、部署によって実行できるシナリオを限定したり、ユーザーによって権限を制限したい
こういった課題・要望を解決するために、運用管理ツールで一元的にコントロールするわけです。大きな企業で、大規模に自動化をすすめるなら、必要ですよね。
それだけに、このツールは高価です。
[3] RPAとRDA

最後に「RPAとRDA」という名称について、少しだけ解説します。
前のセクションで、『全部入りパターン』『開発実行分割パターン』『一元管理パターン』と3つの実行環境を解説しました。
この中で、本当の意味で「RPA」と呼べるのは、『一元管理パターン』です。
『全部入りパターン』は、RDA(ロボティック・デスクトップ・オートメーション)と言われる領域です。
「自分のPCを自動化する」ことはできるけど、「業務プロセスを自動化する」という領域には至っていないよ、というニュアンスがあります。
『開発実行分割パターン』も、どちらかというとRDAですね……。
RPAとRDAの違いについて、興味がある方は以下の記事をお読みください。
[nlink url=”/rda_rpa_dif/”]はい。と、いうわけで、この記事は以上です。
だいぶ、RPAの仕組みがわかっていただけたんじゃないでしょうか?