Power Automateクラウドフロー入門｜ロジック設計

第1回 Power Automate初心者向け｜Apply to each の遅さを体感する

Power Automate では、さまざまな業務を自動化できます。

たとえば、ライセンス利用数の集計、Teamsでの自動定期連絡などです。
管理業務で、さらに言えば情シスなどが「毎回手でやっている定型作業」を置き換えるにはかなり強力です。

一方で、Power Automate は処理量が多くなると遅いことがあります。

最初は 10 件しか処理しなかったからよかったが、時間がたつにつれ 100 件、200 件を超え、それにともない完了まで 1 時間、2 時間とかかるようになってしまった。しかしなぜ遅いのかはわからない。

その典型例のひとつが、PowerAutomateにおけるループ処理の遅さです。

もちろん、Power Automate のベストプラクティスは有志の情報がかなり充実しています。

Power Automate 設計・構築時のTips集
(この記事にも"不要なApply to eachは回避すべし"などとあります。

ただ、読むだけではなかなか身につきません。実際に組んで、遅さを体感して、改善してみると「なぜそのベストプラクティスが必要なのか」が腹落ちしやすいです。

そこで今回は、競技プログラミングの簡単な問題を題材にして、Power Automate でロジック設計を練習するという切り口で進めます。

この記事の狙い

この記事でやりたいことは次の 2 つです。

Power Automate でロジックを組む練習題材を持つこと
ループ処理を使う実装と、使わずに計算で済ませる実装の差を体感すること

今回は題材として、AtCoder の以下の問題を使います。

ABC447 A - One Seat Away

問題の概要

横一列に席が N 個あります。
隣り合う席には同時に座れないとします。
このとき、K 人が座れるかどうかを判定します。

要するに、

席数 N
座りたい人数 K

が与えられたとき、
最大何人まで座れるかを求めて、K 人が収まるなら Yes、無理なら No を返す問題です。

図解

例えば N = 5, K = 5 なら

図の通りNoです。

しかし N = 5, K = 2 なら

絵の通り成立しており、
そして問題定義的にもKの最大数は3、3>=2なので成立してますね。
よってYesです。

問題を愚直版：`Do until` で解いてみる

ではN,Kが与えられたとき判定するフローを組んでみます。

入力

手動トリガーで以下を受け取ります。

席数 N
座りたい人数 K

変数

previousSeatOccupied：前の席に人が座っているかどうか
- 初期値：false
maxPeople：最大何人まで座れるか
- 初期値：0
i：実行カウント
- 初期値：0

ロジック

N の席まで Do until で 1 席ずつ走査します。

処理の考え方は以下です。

前の席が空いているなら、席に座らせるのでmaxPeople を +1、
今の席に座ったので、次の判定用に previousSeatOccupied = true
逆に、前の席が埋まっているならpreviousSeatOccupied = false に戻して次へ進む
実行カウントを増やしてNの席を判定し終わったら完了

最後に、

K <= maxPeople なら Yes
それ以外なら No

として ans を作成します。

計測

以下の値で実行時間を比較します。

N = 5
N = 10
N = 50
N = 100

N	K の例	実行結果	実行時間
5	3	"Yes"	0:02
10	5	"Yes"	0:05
50	25	"Yes"	0:24
100	50	"Yes"	1:00
100	51	"No"	0:54

結果からわかること

わざわざDo untilを用いたからではありますが本実装はコードが長くなりました。
そして、Nが増えるほど比例する形で時間が延びるのがわかります。
つまり1000件なら...10分、10000件なら100分、100000件なら1000分と
伸びていくことが予想されることになります。

最適化版：計算で一発にする

この問題は、実はループしなくても解けます。

横一列の席で隣り合って座れないなら、最大人数は

ceil(N / 2) #Nを2で割って切り上げ

です。
たとえば、

N = 5 なら 3
N = 10 なら 5

となります。

Power Automate なら、たとえば次のような式で求められます。

add(int(div(N, 2)), if(not(equals(mod(N, 2), 0)), 1, 0))

※PowerAutomateにはceilなんて便利なものはないので
　なかなか関数を頑張らなければなりません…

ロジック

上記でやると

手動トリガーで N と K を受け取る
`maxnum を計算
K <= maxPeople を判定してansとしてYes or No を作る

となり、それを作ってみたのが以下です。

手動トリガーで N と K を受け取る
`maxnum を計算
K <= maxPeople を判定してansとしてYes or No を作る

再計測する

N=100のところだけ実行時間を再計測します。

N	K の例	実行結果	実行時間
100	50	"Yes"	340 ミリ秒
100	51	"No"	107 ミリ秒

コードもシンプルになり、速度が圧倒的に改善したのがわかります。

実務での実感

今回は100件でロジック次第で1分->1秒未満となりました。
実際実務においても、200 件ほどのレコードを処理するフローで、
ロジック改善によって10 時間級だった処理を 30 分未満へ短縮できたことがあります。

もちろん、状況によるので、必ず改善が出きるわけではありません。
それでも、少なくとも次のことは言えます。

ローコードでもロジックは重要
「動けばよい」だけで組むと、件数増加で詰まりやすい
早い段階で設計を見直すほど、後の保守が楽になる

Power Automate でも、しっかり考えて組めば、そこそこの件数をそこそこの速度で処理できます。

まとめ

今回は、競技プログラミングの簡単な問題を題材にして、Power Automate のロジック設計を練習してみました。

ポイントは以下です。

小さな問題でも、愚直実装とロジックを考えた実装で差が出る
Apply to each Do until は便利だが、使わずに済みそちらがよいことがある
ベストプラクティスは読むだけでなく、実際に組んで体感すると身につきやすい

Power Automate で遅いフローに出会ったら、まずは

ループを外せないか
式や集計で置き換えられないか
変数更新回数を減らせないか

を見直してみると、かなり改善することがあります。

あとがき

競技プログラミングの問題は、Power Automate の学習題材として意外と相性がよさそうと感じました。

入出力が明確
正解がある
小さく始められる
ロジック改善の効果が見えやすい

「何を題材に練習すればよいか分からない」というときは、こういう小さな問題をフローで解いてみるのはかなり有効そうです。

次回以降も、Power Automate でロジックを考えて組むと組まないでの差を、
自分自身が体感しながら説明していければと思います。