RPAってナンデスカ？
この質問、RPAを語る上で、意外と核心を突いていると思います。
たとえば、「放置状態のPCに、何かをやらせる」手法・技術などで言えば、
- スクリプト
- マクロ
- 自動化
- バッチ
等、いろいろな用語・方式・技術があります。
その中で、「RPA」の立ち位置は、何なのか、と考えてみたとき。
たとえば、「使用している技術」という観点では、自動化やバッチ処理と、さほど変わりません。
「適用範囲」でも、多くは、スクリプトやマクロと、類似しています。
では、RPAがRPAである所以は、何でしょうか？
最初に、結論を書くと、「既存の技術を、組み合わせて、新しい価値・概念を創造している」のが、前述のような、スクリプト等との違いで、RPAの特徴と、考えられます。
この記事では、その具体的な意味について、記載していこうと思います。
Robotの定義
RPAは、Robotic Process Automationの略語です。ここは、Blue Prism社（現在はVista社に買収されました）が、定義・提唱した用語なので、異論は出ないと思います。
上記の、文脈として、Processは、業務プロセスを指しています。また、Automationは、自動化です。
これらも、比較的、ITや、業務効率化、あるいは情報工学などの分野では、一般的に使われる用語で、意味の補足は、さほど必要ないと考えます。
問題は、"Robotic"の解釈、つまり、Robotとは、どのようなものを指すのか？です。
「ロボット」というと、日本では、フィクションの「ロボット」の、イメージが強いと思います。
たとえば、鉄腕アトムやドラえもん、ターミネーターのような、人間に近い感情や動作をするものだったり。
マジンガーＺや、ガンダムのように、大型で、人が乗り込み、操縦するものだったり。
実在の機器だと、ルンバのような掃除ロボットや、Pepperのような汎用よりのロボットが、馴染み深いでしょうか？
とはいえ、RPAでのロボットは、ほとんどの場合、前述のような、物理的なロボットではありません。基本的には、ソフトウェアです。
もしかしたら、今後、人間のように画面を見て、キーボードやマウスを操作する、ロボットが作られ、RPAに適用されるかもしれません。ですが、2021年現在、そういう製品や機器は、今のところは販売されていないので、ハードウェアによるRPAの可能性は、いったん無視します。
少し前置きが長くなりましたが、ロボットのイメージとしては、「人間の代理として」動くこと、は共通認識たり得ると思います。
フィクションの例で言えば、思考・行動も含めて代替する、鉄腕アトムやドラえもんのような存在と、あくまで人間が操作するものの、その機能を（主に大きさや、力などで）拡張する、マジンガーZやガンダムのようなパターンがありますが、どちらも、方向性はやや異なるとはいえ、「人の能力を機械により再現・拡張し、（限定的な場合もありますが）人間の代理として、機能している」点で、共通しています。
では、RPAの、ロボットに、その点を置き換えると。これも、RPAを提唱した、Blue Prismの概念として、「デジタルレイバー」という、ピッタリのものがあります。つまり、RPAのいう、ロボットは、デジタル労働者（labor）として、人間の代理で、機能することにあります。
更に深掘りしてみましょう。
今のところ、RPA、というよりは、コンピューターは、本質的には、創造的な業務は、できません。
たとえば、デザインを行うにしても、既存の良いとされたデザインから、学習して、新しく「良いと思われる可能性が高い」デザインを作ることは、できます。
あるいは、乱数での生成で、人間が「これは新しい、良いデザインだ」と、感じるものを、出力する可能性はあります。
しかし、コンピューターが、ゼロから判断し、良いデザインを良いデザインと認識して、出力するような、高度な作業ができるには、もう暫くかかるでしょう。
かわりに、ルールが定められている中での、反復的な操作は、コンピューターにも行えます。むしろ、コンピューターは、人間に比べて、疲労しにくい、デジタルデータにおいては誤認識がない等の、利点があります。
但し、「ルール」も、厳密さや、精度に、ある程度の幅はあり、人間が考える「ルール」と、コンピューターが判断する「ルール」には、差異があります。
わかりやすい例で言えば、文字認識機能である、OCRは、たいていの場合、人間の眼で読み取る精度には、敵いません。あるいは、自然言語（人間が、普通に使う言語）の、意味を解することも、制限があります。
つまり、「文章を読んで、その指示に従う」といったルールは、人間には可能ですが、コンピューターには、簡単にはなし得ません。今のところは。
それでも、単純な計算作業など、コンピューターが理解できる「ルール」であれば、コンピューターは作業を行えます。そして、それを「仮想的な労働者」として、管理できることが、RPAの肝になります。
Robot（デジタルレイバー）の意味と価値
次に、ロボットを、デジタルレイバーとして管理できることの、意味と価値を、いくつかの観点から、説明します。
内部統制
たとえば、自動化の技法とは異なる観点で、内部統制という要素が、組織（企業など）の業務では、発生します。すなわち、仕組み作りや、その遵守の確認・維持です。
前述のように、人間には、自然言語を理解し、従う能力がありますが、コンピューターにはありません。つまり、社内規則などを、文章で作成しても、コンピューターに、それを遵守させることは、できないのです。
また、最初に挙げた、「スクリプト」や「マクロ」、あるいはただの「自動化」や「バッチ」処理にも、それ自体に、内部統制へのサポート機能は、まずありません。
しかし、RPAを実現するソフトウェアは、通常、管理・監視機能を備えています。
そのため、直接的な（自然言語による）内部統制への対応こそ困難にせよ、人間の指揮下で、一元的に管理されることで、組織のルールに、則ったことを担保したまま、人間と協調して、業務がこなせる（プロセスを遂行できる）、というメリットがあります。
（裏を返せば、上記のような機能がない「（自称）RPAツール」は、社内ルールの遵守などを考えない社員と同じで、かなり問題があることになります）
つまり、内部統制のプロセス・手順の中に、RPAの存在を、人間と同じレイヤーで、組み込み、検証できることは、RPAの価値となります。
また、プロセスの、変更履歴なども、管理できますので、そちらも併せて、内部統制面での、メリットは、無視できません。
コスト管理
次に、コスト管理の観点で、考えてみましょう。
人間と、協調動作するパターンもありますが、基本的に、RPAソフトウェアは、（物理的か、仮想上かはともかく）PCを使用します。協調動作するパターンは、1台のPCを、人間が複数人で操作するケースと、似ていると考えられます。
また、特にRPAが得意とする、単純作業においては、業務の成果は、定量化しやすいです。つまり、RPAを使うか、人間が作業するかの、コスト比較が容易という点が挙げられます。
人間にとっては、時として、シビアな観点になってしまいますが、「人がやる方が安いか、ロボットにやらせる方が安いか」を、常に確認しながら、運用できる点は、無視できません。
この観点については、スクリプトや、マクロ等でも、ある程度の比較は可能です。但し、それぞれは単機能になるため、1つのPC上で動くロボットに、適宜、事前に定義された複数のプロセスを、業務の状況に応じて処理させて、その上で効率・成果を管理する、といった運用を、支援する機能はありません。
RPAツールは、ダッシュボード等で、ロボットごとの動作状況を管理することで、ロボットの稼働率や、生産性を確認できます。（できないとしたら、これまた、RPAとしては「どんな作業をしたか、きちんと報告できない社員」と同じで、問題を孕んでいることになります）
プロセスの可視化
基本的に、RPAソフトウェアの、実行単位は、「プロセス」です。だからこそ、Robotic Process Automationなのです。（OSの管理する「プロセス」ではありません。ビジネスプロセスです）
一般的に、個々のプロセスには、多数の細かい「操作」や「判断」で成り立ちます。これを、何かしらの方法（多くは、いわゆる「ノーコード」や「ローコード」的な手法）で、RPAでは、ユーザーが定義し、その上で、業務プロセスを遂行させるために、実行します。
つまり、経論すれば、RPAソフトウェアに対する認識で、よくある「既存ソフトウェアやツールを操作するのがRPAソフトウェア」というのも。
導入の、容易さだけでなく。人間が行う、業務プロセスとの整合性や、確認のしやすさや。プロセスの変更時に「人間と同じように」変更を、受け入れられるという、メリットがあります。
RPAは、簡単ですか？
さて、ここまでで、RPAは、ただの「アプリケーションの操作を、代行するツール」に留まらず、人間と同じように、監査や、業務プロセスの遂行、コスト管理ができる、存在であることを、書いてきました。
よくある、RPAの、セールストークに、「プログラミングより簡単」というのが、あります。
誤解を恐れずに言うなら、RPAは、プログラミングより、遙かに難しいです。
それは、プログラミングという、作業は、あくまで「プログラムの作成」であるのに対して、RPAを、理解し、運用するには、業務プロセスの把握と運用、内部監査の対応、コストマネージメント等、様々な要素を、理解する必要があるからです。
「RPAツールを、使って、プロセス（または、プロセスの一部）を、自動化する」という、作業だけに、絞れば、プログラミングより簡単ですが、それは、RPAという概念の、一部でしかありません。
そして、最初に例示した、マクロや、スクリプト等との、比較についても。
ここまでの情報で、そもそも、適用範囲が違うので、意味がないことが、伝わるのではないかと、思います。
単純に、プロセスの自動化を、行うための、工数や精度、技術的な難易度だけで、比較することに、価値はありません。
RPAは、技術的には目新しいものがない？
はい、ありません。ですが、組み合わせで、新しい価値を、創造しています。
ですので、「RPAは、技術的に新しい要素がない、バズワード」というのは、前半は正しくても、後半は正しくありません。
最後に
この記事で書いた、RPAの、あり方・使い方は、極端に言えば、理想論です。
実際の運用で、最初から、この全てを網羅して、導入するのは、至難と言って良いと思います。つまり、現実的ではありません。
それは当たり前のことで、多くの技術や、ツールを使う中での、現実は、得てしてそのようなものだと、思っています。
Windowsにしたって、WordやExcelにしたって、機能を全て、完全に使い倒している人というのは、そうそう居ないでしょう。
だからといって、RPAの価値、つまり「ただの自動化ではなく、デジタルレイバーとして、人間と同じフレームワークに乗せて、運用できる、ソリューションである」ことを、見失っては、RPAの価値や、どのように使えば良いか、あるいは、何を目指すべきかを、比較したり、語ったりはできません。
どうか、安直に「RPAは自動化のこと」とか、「RPAは業務改善のため」という、全体像の一部しか見ない、比較や宣伝に、流されず。
最終的に「RPAが、提供できる価値と、そのためのコスト」を、理解し。
そのビジョンと、組織の性質や、投じられるコスト、最終的な規模感を、加味して。RPAの導入の要・不要を検討して。
必要なら、製品を比較・検討した上で、その性質も加味しながら、導入していくことが、RPAの価値を、最大限に生み出すことになる点を、お伝えしたいと、思っています。