システム屋、Power Automateと出会う

Power Automateとは

Power AutomateとはMicrosoft社の出しているRPAツールで、クラウド版とデスクトップ版の2種類がある。

• クラウド版（Power Automate）: Microsoft 365のサービス間連携（Teams通知、SharePoint、メール等）をトリガーベースで自動化するもの
• デスクトップ版（Power Automate Desktop、通称PAD）: PC上の操作そのもの（Excel操作、アプリ操作、ファイル操作など）を自動化するもの

基本的にローコード/ノーコードで、アクションと呼ばれる部品をドラッグ＆ドロップで並べて、業務フローを作る感覚で自動化処理を組み立てられる。

システム屋にとっての Power Automate

初めての出会い

今回、私自身初めてRPAの案件に携わり、初めてPower Automateを触った。※今回はPower Automate Desktopの方。

「おお、まんまフロー書くみたいでいいじゃん。」

私はそう思った。

今までプログラムのロジックを考える際にフロー図は散々書いてきたし、それをコードに起こさなくてもドラッグ＆ドロップでそのまま動くものになる、ということに素直に感動した。条件分岐もループもある。変数もある。「フローチャートがそのまま実行できる」と言えば伝わるだろうか。

いや、こういうツールが世に広くはびこっているのは存じていた。ただ、いかんせんプログラマとしてはあまり自分から手をつけるようなものではなかった。コードを書ける人間からすると「それ、スクリプト書けばよくない？」となりがちだからだ。しかし実際に触ってみると、非エンジニアでも保守できる（可能性がある）という点で、これはこれで存在意義のあるツールだと思った。

こうして、私はPower Automateと出会った。

不満点

私はロジックを考えるのは嫌いではない。なので、「こうしたらこう」といったフロー図は簡単に書ける。……が、実際に組み始めると、Power Automateに対していろいろと不満が出てくる。必要な機能がそろっていないことや、仕様のわかりづらさを随所で感じた。以下、プログラマ視点での不満を挙げていく。

最大の不満は変数まわりだ。とにかく不親切。順に書いていく。

1. 変数の書き方が %VarName% ←は？

PADでは、変数を参照するとき % で囲う。%NewVar% のように。

この記法がわかりづらい。テキストの中に変数を埋め込むと 売上は%Total%円です のようになるのだが、どこからどこまでが変数なのか、パッと見で非常に読みづらい。

${var} でも {{var}} でもいい、せめて開きと閉じが違う記号にしてくれ。

2. 型の扱いが雑

型の存在は確かにある。テキスト、数値、Datetime、リスト、DataTable等。あるのだが、それらの概念をユーザーに意識させないような作りになっている。

普段は勝手に暗黙変換してくれる。テキストの "1" と数値の 1 をよしなに扱ってくれたりする。……くれるくせに、たまに型起因のエラーで落ちる。「テキストを数値に変換できませんでした」。じゃあ今までのよしなは何だったんだ。

意識させないなら最後まで面倒を見てほしいし、型があるならちゃんと見せてほしい。中途半端なのだ。フローを組んでいる時点では変数の型が画面上ほぼ見えず、実行して変数ビューアを見て初めて「あ、これDatetime型だったのか」と知る。静的型付け言語に慣れた身としては、この「動かすまで型がわからない」感覚が落ち着かない。

3. 変数宣言がない

変数宣言がない（ごめん、これは私が厳格な言語を好むからだよな）。

アクションの出力として、いつの間にか変数が生まれる。「Excelから読み取り」を置けば %ExcelData% が生える。自分で let も var も書いていないのに、変数ペインに変数が増えていく。

しかもスコープという概念が希薄で、フロー内の変数は基本すべてグローバル。ループカウンタだろうが一時変数だろうが、全部同じ空間に同居する。大きめのフローになると「この変数、どこで生まれてどこで使われてるんだ？」を目視で追うはめになる。

4. ドキュメントが不親切

そして、公式ドキュメントだ。

各アクションの説明が「この処理をして、以下の変数として出力します」程度のことしか書いていない。出力される変数の中身が実際どういう構造なのかが書かれていないのだ。DataTableで返ってくるのか、リストなのか、その中の列名は何なのか。結局、実行して変数ビューアを覗いて初めて「ああ、そういう形なのね」となる。

APIリファレンスなら戻り値の型と構造が書いてあるのが当たり前の世界から来ると、この「動かして確かめろ」スタイルはなかなかつらい。記法・型・宣言・ドキュメント、一事が万事この調子で、要するに変数まわりが全体的に不親切なのである。

5. デバッグ・ログ出力がしづらい

デバッグ手段が貧弱だ。ブレークポイントとステップ実行は一応あるが、それくらい。

• ログを仕込みたければ「メッセージを表示」か「ファイルに書き込み」を毎回手で置くことになる。console.log 一行の手軽さはない
• 実行時エラーのメッセージが抽象的で、「で、結局どの値が悪かったの？」となりがち
• 例外処理（エラー発生時の分岐）はあるが、スタックトレース的なものは出ないので、フローが深くなるとエラー箇所の追跡が面倒

コードなら5分で特定できそうな不具合に、変数ビューアとにらめっこしながら時間を溶かすことが何度かあった。

6. ループ処理が遅い・大量データに弱い

PADのループは、体感でわかるレベルで遅い。

数十件ならいい。だが数千行のExcelデータを1行ずつループで読んで加工して……となると、目に見えて処理時間が膨らむ。1アクションごとにオーバーヘッドがあるので、「ループ内のアクション数 × 行数」がそのまま実行時間に効いてくる。

対策としては、

• Excel操作なら1セルずつではなく範囲でまとめて読み書きする
• 重い加工処理はループで回さず、VBScriptやPowerShellのスクリプト実行アクションに逃がす
• そもそもExcel関数を埋め込んでExcel側に計算させる

といった工夫が必要になる。ただ、これをやり始めると「もうそれ、ローコードじゃなくてコード書いてるのでは？」という気持ちになってくる。実際、書いている。

とはいえ、良いところもある

不満ばかり書いたのでフォローしておくと、良い点もちゃんとある。

• 画面操作・Excel操作の自動化が手軽。UI要素の取得やExcelの起動・保存などは、コードで書くより圧倒的に楽
• 非エンジニアにフローを見せて説明できる。処理の流れが視覚的なので、業務担当者とのすり合わせがしやすい
• 環境構築がほぼ不要。会社のPCに開発環境を入れられなくても、PADなら動かせるケースが多い

要するに、「プログラマの代替」ではなく「プログラミングできない環境・できない人のための道具」として見れば、十分に価値がある。

まとめ

Power Automateでなにかやる際には、「単純だけど時間がかかる（人手だと面倒な）作業」にしておきましょう。

定型的なデータ転記、決まったフォーマットのファイル整理、毎日同じ手順のExcel作業。こういうものにはよく効く。

逆に、複雑なロジック・大量データ・厳密なエラーハンドリングが必要なものをやろうとすると、一気に「Power Automateだとできない、もしくはできるかどうかを調べるのが大変」という壁にぶつかる。そして壁を越えようとした結果、スクリプトアクションの中にコードを書き始め、「あれ、俺なにしてるんだっけ」となる。……なった。

道具には向き不向きがある。それを実感した、初めてのRPA案件でした。