Power Automate Desktop（長いので以下PADと略す）は、無料で使えるRPA（Robotics Process Automation）ツール。Windowsで動くGUIアプリケーションを使った作業を記録し、「フロー」と呼ばれるスクリプトを作成して自動実行を行える。ただし、注意すべき点があり、PADは、クラウドサービスであるPower Automateの一部を抜き出して作られたものであるということだ。つまり、「フロー」には、クラウド側で実行される「クラウドフロー」と、ローカルマシンで実行される「デスクトップフロー」がある。
PADはこのうちデスクトップフローだけを作成でき、スケジュールやさまざまなイベントによるデスクトップフローの起動などはPADだけでは行うことができず、クラウドフロー側から行わねばならない。ちゃんと使うのであれば、クラウドサービスも含めて利用環境を整える必要がある。クラウドサービスであるPower Automateは有料のサービスだが、制限はあるものの無料で使える「コミュニティプラン」が用意されている。
・Power Automate フローの種類の概要（クラウドフローとデスクトップフロー）
https://docs.microsoft.com/ja-jp/power-automate/flow-types
・Power Apps Community Plan
https://powerapps.microsoft.com/ja-jp/communityplan/
マクロとスクリプト
アプリケーションが一連の作業を自動で行う「マクロ」は、MS-DOSの時代からある。MS-DOS時代の表計算ソフトLotus 1-2-3もマクロ機能を装備していたし、Excelはそのデビュー時には、1-2-3のマクロを読み込んで実行できるというのが「売り」の1つだった。RPAなどと名前を変えているものの、やっていることは昔から変わらない。
明確な定義があるわけではないが、単純にコマンドを並べたものを「マクロ」と呼ぶことが多い。たとえば、キーボード操作を記録して再生するようなことを「キーボードマクロ」などという。これに対して、条件判断が可能であるなど、コンピューター言語のレベルに達しているものを「スクリプト」などと呼んで区別することがある。
マクロとスクリプトの定まった定義はなく、Excelのマクロで使われているVisual BASIC for Application（VBA）のように、言語としての仕様を持ちながらマクロの名称をいまだに使うものもある。話を円滑にすすめるため、とりあえず、上記のようなマクロ、スクリプトの意味でこれらの用語を使うことにする。
PADでGUIを操作
マクロやスクリプトは、Excelなど特定のアプリケーション内部の機能として実現されてきたが、PADは、これをWindowsのレベルで、GUIアプリケーションを対象に行うものとして作られた。機能としては大きく2つ。フローを編集する「デザイナー」（写真01）と、ユーザーが行う操作を記録する「レコーダー」（写真02）である。
-
写真01: Power Automate Desktop（PAD）のデザイナーウィンドウ。ここでフローを作成編集する。左側のツリーからステートメントをドラッグ&ドロップしてフローを作成する「ビジュアルプログラミング」が可能
-
写真02: Power Automate Desktop（PAD）のレコーダーウィンドウ。ユーザーがGUIアプリなどに対して行った操作をフローのステートメントとして記録していく
レコーダーを使うことで、ユーザーが行った操作をフローとし記録することができる。ただし、レコーダーで作られるフローは、単純に操作を並べただけの「マクロ」レベルのものでしかない。しかし、デザイナーを使ってユーザーがこれにさまざまなコンピューター言語の要素を追加し、「スクリプト」化することも可能だ。
寡黙にしてLinuxではPADに相当するようなRPAツールの存在を聞かないのだが、WSL2のGUIアプリケーション（Windows Insider Programプレビュー版の機能）の操作もPADでは可能だ（写真03）。その他、Edgeと同じレンダリングエンジンを使うChromeや、Seleniumに対応したブラウザーの制御やコマンドライン実行もPADから行える。
-
写真03: Windows10のプレビュービルド（Dev Channel）では、WSL2でGUIアプリを動作させるWSLgのプレビューが開始されている。PADは、こうしたLinux GUIアプリも操作することが可能だ
なぜいまさら「オートメーション」なのか？
少し年配の方であれば、「OA」(Office Automation）という言葉を聞いたことがあるだろう。実際には、職場にワープロが入るといった程度のことであったが、それでも手書きのビジネス文書が電子化されたという意味は大きい。その後、16 bit CPUを搭載したPCが普及すると、マクロは、労働者一人一人のオートメーションを可能にするものとして登場した。
しかし、自動化という点では、ここで停滞が始まる。誰もがプログラムを作成できるわけではないし、手順を並べるだけのマクロだって敷居が低いわけでもない。さらにGUIの普及でマクロやスクリプトでは自動化が行いにくくなった。そもそも、ユーザーが視覚的にさまざまな機能を選択して実行しやすいように作られたGUIは、コンピューターが自動で操作するようには作られていなかったからだ。GUIの自動化とはボタンを押すだけの家電をロボットが操作するようなものだ。
最近になって、「DX:Digital Transfomation」なる用語が「流行り」はじめた。これを産経省は「業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」と定義する。
・DX 推進ガイドライン
https://www.meti.go.jp/press/2018/12/20181212004/20181212004-1.pdf
企業は生き残るために、労働者一人一人の生産性を上げなければならなくなり、そのためには、プログラムを書けない「ノンプログラマー」も生産性を上げるため、業務の自動化に参加してもらう必要がある。
コンピューター利用の分水嶺はプログラミング
人間のコンピュータ利用に関しての境界線は、プログラミングができるかどうかにある。世の中には「プログラマー」と「ノンプログラマー」の2種類の人間しかいない。そして、プログラマーは、コンピューターの黎明期から常に足りない。ソフトウェア工学の発展やさまざまな開発環境の整備などで、プログラマーの生産性はあがったが、こんどは、対象とするコンピューターの台数がPCの普及で爆発的に増えた。
現在、さまざまな仕事がPCの上で手作業で行われている。ある意味、集計用紙や鉛筆、ソロバンが電子的になって効率化しただけで、手作業であることは変わらず「誰かが」やらねばならないのである。これらを自動化すれば、組織としての作業効率を高くできるというのが「RPA」の基本的な考えかただ。
PCにOfficeが普及した1990年から2000年台にかけて、Excelなどのマクロを作ることができる「非職業的」プログラマーは増えた。しかし、筆者が見ている感じでは、PCの操作に長けていても、プログラミングには関わらない人がいる。適性とか才能とか必要性とか、そういうレベルの話ではなく、もっと根源的な性格的なレベルで決まっているような印象を受ける。世の中に几帳面な人とそうでない人がいるように、プログラミングする人とそうでない人がいる。
最近の流行語の1つ「ノーコード、ローコード」もこうした状況を反映したものだ。プログラマーが「プログラムを書かない」でシステムを作るのではなく、ノンプログラマーが自分の作業を自動化してシステム作りに参加してもらうということだ（それがうまくいくのか？ というのは、また別の話）。PADでいえば、デスクトップフローは、個々のノンプログラマー利用者が作り、プログラマーがクラウドフローを書いてどう動かすかを決めるという世界なのだろう。
PADのようなRPAで実現される「デジタルトランスフォーメーション」とは、条件判断のためのIF文などがないマクロで作られていくものなのだろう。IFのないマクロの世界、まあ、そのうちAIがマクロをスクリプトにしてくれるのかもしれないが、少なくとも、書き方に個性が出るスクリプトを後で他人が解読してメンテナンスするよりは、操作を記録したマクロのまま、使い捨てて行くほうがマシかもしれない。
