RPAツールの本質とは何なのか？歴史をさかのぼってみる

「最近になってRPAツールを始めた」とか「会社にあるツールを使うことになった」という方にとってはRPAツールはなんなのか？というのがよく分からなくなっていると思いますので、もともとの歴史を辿って話してみたいと思います。

今のRPAツールは最初OpenCVに代表されるように、画像処理技術のオープンソース化から始まっていると思います。とはいえ、もともと自動化ツールはフリーのものも含めて複数あったし、画面を使わない自動化はコンピュータ発明当初からありました。というか、コンピュータ自体が自動化ツールですから当たり前です。

そういうことは置いておいて、OpenCVが登場してからSikuliXのような「記録したボタンの画像と操作対象のボタンの画像を比較して同じでありそうだったら、そこにクリックコマンドを送信して画面を操作する」といったツールが登場しています。
【参照】フリーのRPAツール「SikuliX」で自動化を始めよう

プログラムが書けるエンジニアにとっては、無料のSikuliXで充分です。オープンソースはヘルプが少なく（ほとんど英語）自分で解決しなければいけないことも多い反面、自動でアップデートすることもないし、自分にスキルさえあれば、安定して運用できます。

SikuliXは無料で使えるのですが、PythonまたはRubyでプログラムを書く必要があるので、プログラム言語を書かずに同じことができる有料のツールたちが登場しました。マウスでオブジェクトをドラッグアンドドロップで配置することでプログラムが作れるローコードのRPAツールです。

ここらへんの時期になると「誰でも簡単に自動化できる」というセールストークが世の中に広がっていきましたね。画像認識の設定もプログラミングもマウスで操作できるので、「誰でもできる」というわけです。しかし、本質的にできることは無料でできることと同じです。

RPAツールはマウスで操作できようとプログラミング言語を覚えなくてよかろうと、プログラミング能力が無いとなにもできません。「誰でも簡単に自動化できる」というトークに騙される人は多いだろうな、と考えて、ちょこちょこ発信し始めたのはこの頃ですね。

SikuliXのような画像認識型ツールの弱点は、「環境の変化に弱い」という点です。画面の解像度が変ったり、操作対象のフォントが変ったりすると元画像とのマッチングに失敗します。つまり、開発に使ったパソコン環境から別のパソコンにプログラムを移すと動作しなくなることが多いし、Windowsアップデート等で環境に変化があったら止まる、という事態も発生します。

もう1つの弱点は「動作が遅い」ということです。画面の中から、元画像とマッチングする画像を探すので、どうしても時間がかかります。画像を探す範囲を限定するテクニックも使えますが、そうすると対象画像は必ずその範囲に出現しないといけないという縛りが出てきます。

同じ画像（例えば見た目が同じボタン）が複数存在場合は、それぞれを特徴づける何らかのアンカーポイントが必要となってきますから、少し操作が複雑になってきます。

このような画像認識型ツールの弱点をUiPathやPower Automate for desktopは克服しています。UI要素での認識です。画像を使わずアプリケーションやWebサイトの階層構造を使ってオブジェクトを特定するので、フォントの変更や画面解像度の変化にも惑わされません。そのうえ、動作も早いです。画像検索の範囲を限定するとか見た目が同じボタンを区別するようなテクニックも必要ありません。

その代わり「UI要素」や「セレクター」という馴染みのない概念を理解しないといけなくなりました。非エンジニアの方は「ん？」となってくる場面ですね。もっと正確に安定して動作させるには、このセレクターを用途に合わせてカスタマイズしないといけないし、柔軟に動作させるにはセレクターに変数を組み込んだりする技術も必要です。こうなると「誰でも簡単に」とは言えなくなってきますね。結局、技術力はどこまで行っても必要なんです。

ともかくRPAツールというのは、操作対象のオブジェクト（ボタンやテキストボックス）をどのように認識するか、というテクニックの話が大事なんです。「どれだけ簡単に開発できるか？」というマーケティング要素は後付けなので、本格的に自動化しようとするとテクニックとのギャップが出てきます。

「簡単と言っていたのに、簡単じゃない」というギャップです。しかし技術者的には「UI要素の操作をマウス操作だけでできる」というのは革命的です。UI要素を画面分析ツールで解析して、WinAutomationで操作するプログラミングは面倒ですから。

加えて他アプリケーションとの連携もできるようになってきました。Office製品のオブジェクトを生成して、操作して、オブジェクトを破棄して、など書くのも面倒です。それをアクションを配置するだけでできるわけです。こういう機能も技術者にとっては楽なポイントです。

しかし、後付けで便利な連携機能が増えてきたので、今からRPAツールを使う人は「何が本質か？」が分からなくなっていると思って、話していますが、RPAツールの本質は「画面操作だよ」という話です。

ローコードは本質的ではなく、別にプログラミング言語でも構いません。Ifアクションを貼り付けてプロパティを設定して、、とするより、「If *** then」と文字で書いた方が早いですから。まぁでも、書くのが面倒なプログラムはドラッグアンドドロップで定型がパッと書ければいいですね。

「プログラミング言語は非エンジニアは覚えられない」という人がいますが、本当でしょうか？ローコードツールの使い方を覚えられるような人なら、プログラミング言語くらい覚えられると思います。本格的にプログラミングしようというのではなく、画面操作するのに必要な部分だけ覚えればいいですし。

ともかく、RPAツールとは本質的には画面操作のツールであり、そこにロジックも組める、他のアプリとの連携機能もできる、しかもローコードで！というおまけがついているわけで、すごく便利なものだということですね。ただ、簡単と思って使うと、簡単じゃないですよ、ということです。

さて、ここまでの話と「業務自動化」はまた別の話です。業務自動化するためには、業務を理解しないといけないし、日常業務の中に運用として乗らないといけないのです。画面操作の話といっしょじゃないですよね？でも、これを一足飛びで繋げてしまうから問題が発生します。

「RPAツールは業務自動化にも使えるけど、RPAツールが使えるから業務自動化できる」というわけではないのです。こんな話をしても何も売れませんし、興味がある人は1％くらいになるので、この話はまた別に書きます。