Power Automateクラウドフロー入門｜ロジック設計(1) Apply to each の遅さを体感する

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 つです。

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

今回は題材として、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 席ずつ走査します。

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

1. 前の席が空いているなら、席に座らせるのでmaxPeople を +1、
2. 今の席に座ったので、次の判定用に previousSeatOccupied = true
3. 逆に、前の席が埋まっているならpreviousSeatOccupied = false に戻して次へ進む
4. 実行カウントを増やして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なんて便利なものはないので
　なかなか関数を頑張らなければなりません…

ロジック

上記でやると

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

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

1. 手動トリガーで N と K を受け取る
   

2. `maxnum を計算
   

3. 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 でロジックを考えて組むと組まないでの差を、
自分自身が体感しながら説明していければと思います。