Power Platform 要求数 について考えてみる

この記事は、Microsoft Power Apps Advent Calendar 2022 カレンダー1 20日目（2022/12/20 担当分）の記事です。

気ままに勉強会 #36「制限 リターンズ」と#37「制限 リターンズ Part2」 でPower Platformの制限のひとつとして、少しとりあげた「Power Platform 要求数」について考えてみようかなと思います。

なお、資料はこちらです。
制限 リターンズ | ドクセル (docswell.com)
制限リターンズ Part2 | ドクセル (docswell.com)

また、Power Platform 要求数や要求レポートのお話は、ふらりさんが以下の記事を書いてくださっていますので、合わせて読んでいただくとよいかなと思います。
【Power Automate】Power Platform 要求数を確認してみた話 – ふらりのメモ書き (hatenablog.com)
【Power Platform】Power Platform 要求使用状況の情報を表示する（プレビュー）の話 – ふらりのメモ書き (hatenablog.com)

Microsoft 365 のライセンスの1ユーザー1日あたり6000要求

まだまだ多くの方が、Microsoft 365 ライセンスで利用されていると思います。
その場合、1ユーザーの1日あたりの要求数は「6,000」です。
ただし、現在は移行期間中とのことで、1ユーザー1日あたりの要求数は適用されていません。

移行期間中は1フローあたり「10,000」要求となっています。
また、フローの場合は、あたりどのくらいの要求数が発生しているかは、フローの詳細から[分析]をクリックすることで確認できます。
（Power Appsの場合、確認する方法はなかったと思いますが、もしご存じの方がいたら教えていただきたいです。）

これに対して、1ユーザーあたり1日どのくらいPower Platform 要求数を利用しているかは、Power Platform管理センターからレポートをダウンロードすることで確認することができます。

1日どのくらいPower Platformを利用しているのか？

Power Platform要求数のお話をするとPower Automateで作成したクラウドフローの実行だけのように思われがちですが、Power Appsで作成したアプリを利用しても発生します。

Microsoft 365 ライセンスということは、Dataverse for Teams環境で利用されるアプリやフローも対象になります。Dataverse for Teams環境ということは、Power Virtual Agentsで作成されたチャットボットも対象です。
（PVAは、要求数レポート上は、Power Automateの要求としてカウントされます。）

さて、あなたは普段、Power Platformをどのくらい利用していますか？

個人で利用することが多い🦁さんの場合

🦁さんは、Dataverse for Teams環境をメインで利用しています。
既定の環境も少し利用しています。使っているものは以下だと仮定します。
No.2、3は、Microsoft が提供しているサンプルアプリです。
果たして、このようなアプリを利用している🦁さんの１日あたりの要求数はどうなるでしょうか？

No	環境	アプリ/フロー	一日あたりの利用回数	想定操作
1	Dataverse for Teams	神経衰弱（PVA） （※1）下記ブログ参照	5	勝負がつくまでに10回のやりとりが発生
2	Dataverse for Teams	従業員のアイデアアプリ （※2）	1	アイデアを１つ投稿 投票をするためにすべてのアイテムを参照し、よいものにいいね
3	Dataverse for Teams	マイルストーンアプリ （※3）	10	2つのタスクを追加 5つのタスクを更新
4	既定の環境	アダプティブカードで報告を促すフロー （※4）	1	10人が退勤ボタンをクリック
5	既定の環境	安否確認システム （※3）	24	1時間に1回実行される

一日あたりの利用回数と想定操作から導き出される要求数はどうなるでしょうか？
フローやチャットボットはアクションが実行される回数とほぼ同じと仮定します。
Dataverse for Teams環境で作成されたアプリは、Detaverseへの読み書きが発生します。

ということで要求数を想像してみます。

※ 注意：実際に実行した結果ではありませんので、まったく違う可能性があります。
※ No.2については、少し実際の検証した結果を利用しています。想定操作と同じように操作したところ、だいたい100要求ほどありました。すべての要求は、Dataverse要求数としてカウントされていました。

No	環境	アプリ/フロー	一日あたりの利用回数	要求数
1	Dataverse for Teams	神経衰弱 ボット（PVA） （※1）下記ブログ参照	5	1000
2	Dataverse for Teams	従業員のアイデア アプリ （※2）	1	100
3	Dataverse for Teams	マイルストーン アプリ （※3）	10	500
4	既定の環境	アダプティブカードで報告を促すフロー （※4）	1	50
5	既定の環境	安否確認システム フロー （※3）	24	2000

仮に、2650要求とすれば、1日あたり6000未満なので、まだまだ利用可能です。
会社でゲームをしていることは、ひとまずおいておきましょう。

100名が利用する可能性がある申請・承認フローを作成している🐼さんの場合

🐼さんは、既定の環境をメインに利用しています。使っているものは以下だと仮定します。

No	環境	フロー	フローあたりのアクション数	想定操作	要求数
1	既定の環境	出張精算承認フロー（自動実行）	100	10ユーザーが利用	1000
2	既定の環境	業務報告通知フロー（自動実行）	50	100ユーザーが利用	5000
3	既定の環境	テレワーク申請フロー（自動実行）	100	50ユーザーが利用	5000
4	既定の環境	メール添付ファイルをOneDriveに格納するフロー（自動実行）	10	10通のメール	100
5	既定の環境	体温報告通知フロー（手動実行）	50	100ユーザーが利用	50

No.1～No.4の自動実行となっているフローは、作成した🐼さんの要求数としてカウントされます。No.5は手動実行となっているので、自分が利用した分だけカウントされます。
仮に、6250要求とすれば、1日あたり6000を少し超えてしまいました。

さらに活用が広がると仮定すると

🦁さんが利用しているDataverse for Teams環境でアプリを作成したり、提供されているサンプルアプリの利用が倍になったり、利用回数が倍になったとしたらどうなるでしょうか？
Dataverse for Teams環境のアプリは、Dataverse要求が多く発生するようです。
1日あたりの要求数はギリギリ6000くらいになるのでしょうか？

Dataverse for Teams環境でアプリを利用する場合、どのアプリでどのような操作をするとどのくらいのDataverse要求が発生するかは、見ておいた方がよいと思います。
クラウドフローはだいたいアクションが実行される数という目安のようなものがありますが、アプリ、特にDataverse要求が発生するものは、目安が提示されていないため、実際の操作と要求レポートで検証することくらいしか、予想ができないのが現状です。

🐼さんが作成したフローと同じ条件のフローがプラス5つあるとしたらどうなるでしょうか？あっという間に6000を超えます。
フローの場合は、対策としていくつか考えることができます。
自動実行となるポーリングトリガーやWebhookトリガーを利用したフローは、フローの作成者の要求が消費されます。
ひとりのユーザーがフローの作成者とるするのではなく、フローの作成者を分散させるのです。
🐼さんがひとりで作成していたフローのうち、半分を🦁さんに作成してもらうと🐼さんの要求数は半分になります。一方で🦁さんは🐼さんが消費していた要求数の半分が増えるということになります。

もうひとつの対策は、手動実行となるプッシュトリガーのフローに作り直すことです。
手動実行となると、利用者の操作がすこし増えますが、実行したユーザーの要求数としてカウントされます。100人実行するのであれば、🐼さんの要求数は1/100になります。

さいごに

問いかけだけで、検証結果をご提示できませんでしたが、どのようなことが起こりえるか想像できたでしょうか。

Power Appsアプリ、特にDataverse for Teams環境で、Dataversを活用したアプリを利用している場合、Datavers要求がいまどのくらい利用しているかを把握しておく必要があると思います。
移行期間がいつ終わるのかわかりませんが、移行期間が終わり、仮に6000要求を大幅に超えている使い方をしている場合は、スロットリングが発生し、動作が遅延するといったペナルティのような状況が発生します。
（可能であればクラウドフローのようにある程度予測できる基準値をMicrosoftさんから提示いただけると嬉しいところです。）

フローの場合は、どのようなフローを誰が作っていて、どのくらいのユーザーが利用するのかといったことがいろいろ加味していきますが、作成できるひとがひとりの状態では、すぐに要求数を超えてしまうかもしれません。

6000要求というのは、Microsoft 365 ライセンスの場合の制限です。
Power Apps per userやPower Automate per userのスタンドアロンライセンスを購入すれば、「40000」要求に跳ね上がります。

Power Platform活用が広がるということはとてもよいことです。
しかし、少人数だけが作成できる状態というのは、要求数といったと制限にもひっかかりやすくなることを意味しています。
したがって、Power Platformでアプリやフローを作成できるひとを増やすことが大切です。

また、フローの場合であれば複雑な処理を行うアクション数が多くなるようなフローを作成しないということも考えないといけないのかもしれません。
Microsoft 365 ライセンスでは、ちょっとした個人レベルの改善をターゲットにしているとも言えます。

スタンドアロンライセンスを購入するといったことで要求数が6000→40000に大幅に増えます。
1ユーザー分のライセンス料金を会社が投資するのは、はたして投資として高いのでしょうか？
使っただけ課金という従量課金という選択肢もあります。

Power Platform要求数について考えていると、Power Platformの活用推進している場合、Microsoft 365 ライセンスだけでは頭打ちになる可能性が出てくるかもしれれないなと思いました。
Power Platform要求数だけではありませんが、スタンドアロンライセンスであれば、利用できるコネクタも増えます。もっとできることが増えるというメリットもあります。
ライセンス料が高いと感じるかどうかについて、改めて考えるよい機会になりました。

最初に紹介した制限リターンズ Part2 | ドクセル (docswell.com)の資料内にもPower Platformの要求数の対策について記載されているドキュメントのURLを掲載していますが、あらためてこちらにも記載しますので、合わせて確認してみてはいかがでしょうか。

ベスト プラクティス
Power Automate ライセンスの種類 – Power Platform | Microsoft Learn

だれの Power Platform 要求制限がフローで使用されますか?
Power Automate ライセンスの種類 – Power Platform | Microsoft Learn

何が Power Platform 要求と見なされますか?
Power Automate ライセンスの種類 – Power Platform | Microsoft Learn

フローが実行するアクションが多すぎるとどうなりますか?
Power Automate ライセンスの種類 – Power Platform | Microsoft Learn

フローが制限を超過している場合はどうすればよいですか?
Power Automate ライセンスの種類 – Power Platform | Microsoft Learn

低速実行フローのトラブルシューティング
低速実行フローのトラブルシューティング – Microsoft サポート

従量課金制
Power Automate ライセンスの種類 – Power Platform | Microsoft Learn