前回の続きです。今回は、実際にPower Automateの中身について解説します。
一般的なRPAは、Windows上に存在するフォームの内容（ボタンやリストボックス等のオブジェクト）を解析し、例えばボタンをクリックするような制御の場合、実際にそのフォーム上でボタンクリックのイベントを発生させ、処理を進めるようなものとなっていて、「タイトルが〇〇のフォームのリストボックス内〇行目をクリックした後、デフォルトボタンをクリックする」といった形のプログラミングを行うものが多い（筆者主観）のですが、 Power Automateの場合はMicrosoftプラットフォームを存分に活用しており、最初から様々なアプリケーションとの「コネクタ」と呼ばれるAPI（のようなもの）が準備されていて、OutlookのInbox内で「送信者が〇〇@aaa. comであるものをピックアップする」といったことが、ほんの数ステップの処理で実現できるようになっています。
フロー実行のトリガー設定例
Teamsへメッセージを投稿するアクションの例
一般的なRPAであればアプリケーションを問わずに処理の自動化を組み込む事が出来るのに対し、Power Automateの場合はコネクタが準備されたアプリケーション以外には手を出す事が出来ません。
ですので、結局閉じた世界の中では便利、という程度なのかと思ってしまいますが、一般的なRPAでもどうしても連携できないアプリケーションは発生してしまうことと、2021年12月時点のPower Automateでは、AzureやBingはもとより、Facebook, Gmail, MySQL, Oracle, PostgreSQL, Redmine, Salesforce, SAP, Slack, Twitter 等々、MS以外の多くのアプリケーションについてコネクタが準備されていることを考えると、一般的なRPA側に一方的にアドバンテージがあるわけでもないことがわかります。
その他にも数々のメリット／デメリットが双方に存在するわけですが、大がかりな開発をしなくても、Excelのマクロのようにお手軽に処理を自動化させる事が出来る、というのは大きなメリットではないかと思います。
みなさんも、たとえばPlannerやRedmineで自分にタスクがアサインされた時、自動的にそのタスクの詳細をListsに転載し、自分がやらなければならないタスクを一覧表示できるようにしたり、週1回の定例進捗会議用にMS ProjectのWBSから現在稼働中のタスクを抽出してPowerPointに纏めてみたり、TwitterのIT関連ニュースアカウントにアップされたツイートをSharePointのトップページにヘッドラインとしてリアルタイム表示したり、といった自分専用のフローを作ってみてはいかがでしょうか？