決まった作業を自動化することは、効率化や生産性向上を目指す企業や個人にとって欠かせないものです。
本サイトでは自動化ツールとしてSikuliXを取り上げてきました。
しかし、SikuliXでは扱いやすいとはいえ、スクリプトを自分でPython言語などを使って書いていかないといけません。
そこで、今回は、Windows標準搭載で使いやすい幅広く使える自動化ツールのPower Automate Desktop（PAD）について取り上げます。
SikuliXとPower Automate Desktop（PAD）の比較をまとめていますので、参考にしてみてください。
「PAD」は、「SikuliX」と比べてどうなのか？
ここでは、「SikuliX」と「PAD」を比較して「類似点」や「それぞれの違い」についてまとめます。
双方が得意なこと
SikuliXとPADは、いずれも主に「画面上の視覚的な情報」を基にして操作を自動化するツールです。
これにより、GUI（Graphical User Interface）を持つアプリケーションの操作をスクリプトによって自動化できます。
具体的には以下のようなことが共通して可能です。
| できること | 説明 |
| UI操作の自動化 | どちらも画面上の要素を認識してクリックや入力を自動化する機能を持っています。 ただし、主な認証方式が異なり、SikuliXは画像認識ベースで、PADは要素認識とUIフローベースです。 |
| ファイル操作 | ファイルの作成、コピー、移動、削除などの操作が可能です。 |
| キーボード・マウス操作の自動化 | キーボード操作による「ショートカットキーの送信」「テキスト入力」、マウス操作による「カーソルの移動」「クリック操作」などができます。 |
| スクリーンショット | 画面のキャプチャや、スクリーンショットの保存が可能です。 |
| ループや条件分岐 | ワークフローやスクリプトの中でループや条件分岐を用いて柔軟な処理が可能です。 |
SikuliX独自の優れた点、注意すべき点
SikuliXには、「画像認識ベースであること」「SikuliXのエディターの特徴」ゆえに優れた点、注意すべき点もあります。
ただし、苦手なことは、Pythonの実装に長けていれば、クリアするものもあります。
まずは、得意なことです。
| 優れた点 | 説明 |
| 高い画像認識能力 | 画像認識に特化しているため、UIさえ変更がなければ、内部処理の方法が変わってもスクリプトを修正する必要がなくなります。 |
| スクリプトの拡張性 | SikuliX独自のコマンドと、（基本的に）Pythonでスクリプトで作成します。 そのため、Pythonでできることは一通りできると考えて問題ないため、非常に拡張性があります。 |
| オープンソースかつ無料 | 完全無料で利用でき、ツール自体の改変も可能です。 |
| クロスプラットフォーム | Javaを使って動作するため、Windows、macOS、Linuxなど様々なOSで利用可能です。 |
次に、注意点です。
| 注意点 | 説明 |
| UI変更の影響 | SikuliXは画像認識に基づいて動作するため、「OSやブラウザの違い」「アップデート」などによるUIのちょっとした変化や解像度の違いに影響を受けやすいです。 |
| 高度なデータ処理 | 画像認識によるマウス・キーボード操作に優位性があるため、Excelやデータベースなどの高度なやり取りやデータ処理を直接行うことができません。 Pythonなどを使って実装する必要があり、他のツールに比べて難易度が高いです。 |
| 実装スキルが必須 | SikuliX独自のコマンドは基本的なものばかりです。 そのため、複雑なことをやりたければPythonによる実装をしなければなりません。 当然、実装内容に見合ったPythonによるプログラミング実装スキルが必須になります。 また、実装された内容によってはプログラミングスキルに長けていないと引継ぎなども苦労します。 |
| 多様なサービスとの統合 | 公式で他のサービスやアプリ（メールやデータベース、クラウドサービスなど）との連携が保証されていることはありません。 そのため、「ビジネスプロセス全体の自動化」には、機能が不足する可能性があります。 外部APIとのやりとりや、システム間の統合は独自にスクリプトを開発する必要があります。 |
| エラーハンドリングが難しい | 上記「要素認識の精度」に加え、環境の処理速度による操作遅延なども考慮しなければいけません。 そのため、エラーハンドリングが自動化しづらい場合があります。 スクリプトも膨大になるほど、「待機時間の調整」「認識する画像の取り直し」などの手間も増大します。 |
| オープンソースならではのサポートの限界 | SikuliXはコミュニティベースでの開発・サポートが中心であり、商用ツールほどの手厚いサポートは期待できません。 |
PAD独自の優れた点、注意すべき点
PADは、「UIフローベースであること」「Microsoft公式のツールであること」ゆえに優れた点、注意すべき点もあります。
まずは、得意なことです。
| 優れた点 | 説明 |
| Microsoft製品の連携 | Microsoft 365、Azure、Dynamics 365などのMicrosoft製品と連携し、操作・データ操作をするための機能が標準搭載されています。 そのため、企業の業務プロセス全体を自動化することが、非常に適しています。 |
| 豊富なアクションライブラリ | PADは、1つ1つの操作を「アクション」という形でプリセットされています。 このアクションを組み合わせてフローを作成しますが、このアクションは幅広い操作を網羅し、プリセット数も多いです。 |
| ユーザーフレンドリーなインターフェース | 「レコード機能」「アクションのD&D操作」「アクションの基本項目の設定」のみで作っていくことが可能なため、コーディングが苦手な人でも使いやすいです。 |
次に、注意点です。
| 注意点 | 説明 |
| アクション自体の学習・理解 | PADは「アクション」を利用してフローを作成していくので、それぞれのアクションに対する「設定しなければならない項目」「動作」の理解は必須になります。 |
| 画像認識の利用範囲 | PADはUIフローベースで主に固有のIDで認識します。 画像認識で行う操作にも対応していますが、SikuliXほど「多くの操作を扱うこと」「詳細な画像認識のカスタマイズを行うこと」はできません。 そのため、正確な画像認識を行いたい場合は、不向きと言えます。 |
| ツール自体のカスタマイズ | Microsoftの商用製品であり、オープンソースのSikuliXのようにツール自体をカスタマイズするようなことできないと考えて良いです。 |
| 利用するOS環境が限定的 | Windows環境での動作を前提としているため、他の「macOS」「Linux」での利用には不向きです。 |
| 費用が掛かる場合がある | 無料版もあり、充分な機能を搭載しています。 しかし、より多くの操作（アクション）を扱いたい場合や、ツールの機能としてスクリプトの共有をしたい場合などは有料版でなければなりません。 |
どちらを選択するべきか？
次に、「SikuliX」および「PAD」を選ぶべきケースについて、考えてみます。
SikuliXを選ぶべきケース
SikuliXの方が向いているニーズについて、以下にまとめます。
| ケース（ニーズ） | 説明 |
| 画像認識をメインに自動化したい | 特にGUIベースのアプリケーションで、画像認識に基づいた操作が求められる場合に有効です。 |
| プログラミングに抵抗がない | 「独自のコマンド」「Python」を利用してコーディングをしていくため、プログラミングに苦手意識が無い方が良いでしょう。 Pythonが扱えれば、できることの幅が一気に広がります。 |
| コストを抑えて、ツールをフル活用したい | 完全無料で利用でき、ツールの改変も考えている人におすすめです。 |
| 複数のOS環境で同じツールを使いたい | Windows以外のOSでも自動化を行いたい場合は、SikuliXがおすすめです。 |
| リモート接続先を操作したい | 画像認識のため、リモートデスクトップなどで接続した環境に対しても、操作することが可能です。 そのため、自動化対象の動作（性能）に影響を与えずに、動かすことが可能です。 |
PADを選ぶべきケース
PADの方が向いているニーズについて、以下にまとめます。
| ケース（ニーズ） | 説明 |
| コーディング未熟練者が対応する | コーディングを必要とせず、単純な操作・設定で自動化することができます。 |
| Microsoft製品を多用している人 | PADがMicrosoft製品であることもあり、Microsoft 365やAzureなどと連携した自動化に長けています。 |
| 公式の情報でサポートを受けたい | 企業ユーザーなど、確かな情報による公式サポートを受けたい場合は適しています。 |
| 社内業務全体の自動化など影響範囲が広い | Windows標準搭載ということもあり、WindowsOS利用者であれば、同じスクリプトを使いまわすことが可能です。 Microsoft製品との連携にも長けているため、社内全体で同じ方法で効率化をしたいような場合に適しています。 |
【参考】PADとその他の自動化ツールの比較
最後に、PADと他のツールや言語を比較も簡単にしてみました。
対Ranorex
Ranorex（リンク）はGUIテストの自動化が目的のツールとなっています。
特にWindowsデスクトップアプリケーション、Webアプリケーション、モバイルアプリケーションのUIテストに強みがあります。
また、テスト結果レポートとして画像・動画の記録、実行時間の計測などが可能となっています。
ただし、非常に高価であり、スクリプト（テストケース）を作成する場合は、100万（買い切り版のみ）を超えます。
対して、PADは汎用の業務プロセスの自動化が目的のツールとなっており、より広範な自動化が可能です。
なお、いずれもコードレスでのスクリプト作成が可能です。
対C#
C#はMicrosoftが開発した言語であり、特に.NETフレームワーク上でアプリケーションを開発・自動化する際に最適とも言えるプログラミング言語です。
使いこなせると非常に高い柔軟性を持っていますが、自動化するには高度なコーディングスキルが求められます。
C#で自動化を行うには、相応の学習時間と開発に要する時間が必要になるでしょう。
また、対象のアプリも自動化を前提とした作りをしないと、自動化は非常に苦労することになると思います。
対Selenium
Seleniumは、Webアプリケーションの自動化に特化しており、ブラウザ操作に圧倒的な強みがあります。
C#でも、Webアプリケーションの操作のために、Seleniumを利用することが多いです。
プログラミングスキルは必須のため、コーディングスキルが求められます。
対Appium
Appiumは、PADでは対応できないモバイルアプリケーションのテスト自動化に特化しています。
ですが、Windows Application Driver (WAD) と組み合わせて使用することで、WPFアプリケーションのUIテストを自動化することもできます。
こちらも、コーディングスキルが求められます。
まとめ
SikuliXとPADは、それぞれ異なる特徴があります。
PADはコーディングスキルがいらないとは言いますが、単なる一本のフローを除けば、条件分岐や繰り返し、エラー処理などコーディングする際に必要なフローの構造を考える力は必要になってくるかと思います。
それぞれのツールの特徴を理解しつつ、目的に応じて使い分けるヒントにしてみてください。