Power Automateクラウドフローの実行が終わらないときに確認するポイント
こんにちは。システムソリューション営業本部の吾妻です。
Power Automateにおいて、大量データを対象にアクションを実行するようなクラウドフローを作成すると、「いつまで経ってもクラウドフローの実行が完了しない」ことが時々あります。
クラウドフローの中に定義したアクションからデータストアや外部サービスへの、過剰なリクエスト送信が原因で生じることが多いですが、それ以外にもいくつかの要因がいくつかあるようです。
そこで今回の記事では、クラウドフローの実行時間が延びる事象の原因について、ライセンス体系やフロー運用設計の観点からご紹介していきたいと思います。
あくまでも現時点での状況について公式資料をもとにまとめたものであり、今後サービスの内容は変更される可能性があります。
詳細は、ライセンスガイドなどの公式資料をご確認ください。
フローの処理が終わらない理由
クラウドフローの処理が「実行中」のまま成功も失敗もせずに残り続ける事象は、Power Platformのライセンス上の制限事項に抵触したことに対するペナルティのようなものです。「アクション要求数の制限（Power Platform 要求の制限）」などの制限によってクラウドフローの処理がいつまでも完了しないと、今度は「続けてスロットリングされたフロー」の制限によって、14日後にクラウドフローが無効化されます。つまり、クラウドフローを利用した処理を確実に実行完了させるためには、制限に抵触することがないように実装するほかないということになります。
各種の制限
クラウドフローはサービス間連携の機能なので、抵触し得る制限については サービスごと に把握しておく必要があります。
例えば、Dataverseテーブルに対して行を追加するようなクラウドフローであれば、①Power Automateの制限、②Dataverseコネクタの制限、③Dataverseの制限の3つを確認します。
以下の表に、主要な制限についてまとめます（せっかくなのでPower Appsなどについても載せておきます）。
| 名称 | サービス | 内容 | 実績の確認方法 |
| Power Platform 要求の制限 |
以下の各回数に対する、24時間ごとの制限と5分ごとの制限、同時要求数の制限 | ||
| Power Automate | クラウドフローに定義されるトリガーとアクション（コネクタ アクション、HTTP アクション、組み込みアクションなど すべて ）の実行回数による制限 ※実行回数は、成功／失敗問わず、リトライやページングもカウントされるが、スキップされたアクションはカウントされない ※「Apply to each（For each）」アクションでは、Apply to each 自体について 1 カウント、Apply to each 内のアクションについて（アクション数）×（ループの実行回数）の分カウントされる |
フローの詳細ページから 分析 を選択し、 アクション タブを確認する | |
| Power Apps | コネクタとDataverseへのすべてのAPI要求の回数 | ||
| Copilot Studio | 会話からPower AutomateフローへのAPI要求の回数 | ||
| Dataverse | CRUD処理、割り当て、共有の操作すべての回数（ログイン、ログアウト、システムのメタデータ操作などは除く） | ||
| サービス保護 のAPI制限 |
Dataverse | 非対話型クライアントアプリケーションから大量のリクエストが送られてきた場合に備えた制限 以下の制限は、環境内のWebサーバーごとに個別に適用されるが、その環境で使用できるWebサーバーの数はユーザーライセンス数などの複数の要因で異なる |
APIからのレスポンスのステータスが429か確認する |
| 累積要求数が5分のスライディングウィンドウ内で6000回を超えない | |||
| すべての要求の合計実行時間が5分のスライディングウィンドウ内で20分を超えない ※バッチ要求を実行することで要求の数を減らすことはできるが、その分実行時間が増える |
|||
| 同時実行要求の累積数が51以下（52以上でない） | |||
| コネクタ の制限 |
コネクタ | クラウドフローでの制限やコネクタで連携する先のサービスの制限とは別に、コネクタごとに設けられている制限 ※コネクタのドキュメントの 調整制限 セクションに記載されている |
|
| Dataverse | 接続ごと300秒ごとに6000回（調整制限）を超えない | ||
| SharePoint | 接続ごと60秒ごとに600回（調整制限）を超えない | ||
Power Platform 要求の制限
パフォーマンスプロファイル判定
先程の表にある「Power Platform 要求の制限」については、ユーザーまたはフローライセンスをもとに決められている「パフォーマンスプロファイル」によって閾値が変わります。
以下の表に、パフォーマンスプロファイルおよび主要なライセンス、閾値の対応関係についてまとめます。24時間ごとの制限の閾値は、上段が移行期間の制限のものを、下段が実際の制限のものを示します。
| パフォーマンス プロファイル |
ライセンス | 閾値 （5分ごと） |
閾値 （24時間ごと） |
閾値 （同時要求数） |
| 低 | 無料 | 100,000 | 10,000 6,000 |
500 |
| Microsoft 365 プラン | ||||
| アプリごとの Power Apps プラン | ||||
| Power Automate プレミアム | ||||
| すべての試用版ライセンス | ||||
| Dynamics 365 Team Member | ||||
| 開発者向け Microsoft Power Apps | ||||
| 中 | Power Appsトリガー型フロー | 100,000 | 200,000 40,000 |
2,500 |
| 手動フロー | ||||
| 子フロー | ||||
| Power Apps Premium | ||||
| 高 | Power Automate プロセス プラン | 100,000 | 500,000 250,000 |
2,500 |
| 無制限 | 従量課金制フロー | 100,000 | 10,000,000 --- |
2,500 |
| サービス プリンシパルが所有するフロー | ||||
ユーザー判定
Power Platform 要求の制限はユーザーまたはフローライセンスに依存することが分かりましたが、この時、ユーザーとは誰を指すのかについてもまとめておきます。
- フローに フローごとのライセンス がある場合
- 常にフローごとの制限が適用される
- 作成者/所有者/呼び出し元のユーザーの制限は無関係
- 自動化フローおよびスケジュールされたフロー
- 常にフローの作成者/所有者の制限が適用される
- 呼び出し元のユーザー/フローを開始したユーザーの制限は無関係
- ソリューション内のフローであればAPI経由でフローの所有者を変更でき、所有者を変更すると、新しい所有者の制限が適用される
- 自動化/スケジュールされたフローを別のユーザーと共有した場合は、共有されたユーザーがトリガーしても元の所有者の制限が適用される
- ただし、共有されたユーザーがそのフローを利用して独自の新しいフローを作成すると、新しいユーザーの制限が適用される
- ただし、共有されたユーザーがそのフローを利用して独自の新しいフローを作成すると、新しいユーザーの制限が適用される
- インスタント フロー
- 呼び出し元のユーザーの制限が適用される
- 呼び出し元のユーザーの制限が適用される
- フローの所有者がサービスプリンシパルの場合
- ライセンスのないユーザー制限が適用される
- ライセンスのないユーザー制限が適用される
- 親子フロー
- 子フローは親フローの制限が適用される
- 親フローが自動化されたフローの場合
- 子フローには親フローの作成者/所有者の制限が適用される
- 子フローには親フローの作成者/所有者の制限が適用される
- 親フローが手動フローの場合
- 子フローには親フローの呼び出し元ユーザーの制限が適用される
- 子フローには親フローの呼び出し元ユーザーの制限が適用される
- 子フローにフローごとのライセンスがある場合
- 親フローの制限ではなく、フローごとの制限が適用される
- 親フローの制限ではなく、フローごとの制限が適用される
- 親フローにフローごとのライセンスがある場合
- 親フローとすべての子フローに、フローごとの制限が適用される
- 親フローとすべての子フローに、フローごとの制限が適用される
- フローにプロセス ライセンスがある場合
- フロー、フローのすべての子フロー、およびフローのコンテキスト内のフローに、プロセスプランの制限が適用される
サービス保護のAPI制限
現状の確認方法
現在消費しているリクエスト数は、Dataverse Web APIを呼び出した際の応答に含まれる、以下のヘッダーの値を確認します。Power Automateクラウドフローで、「行を一覧にする」などのアクションを利用している場合は、クラウドフローの実行履歴から出力（「クリックしてダウンロードします」リンク）を開くことで、値を見ることができます。
| ヘッダー | 内容 |
| x-ms-ratelimit-burst-remaining-xrm-requests | 残りのリクエスト数（6000回から減っていく） |
| x-ms-ratelimit-time-remaining-xrm-requests | 残りの実行時間（1,200.00秒から減っていく） |
| Retry-After （429エラーが返された場合のみ） | リクエストを送り直すまでに空けるべき秒数 |
Dataverse検索のリクエスト
また、Dataverseにおける「サービス保護のAPI制限」では、Dataverseテーブルのレコードに対するCRUD処理に加えて、割り当てや共有も制限対象のAPI要求と見なされる一方で、Dataverse検索のAPI要求は対象外であり、別の制限（ユーザーごとに1秒あたり1リクエスト、各組織のリクエストは1分あたり150件）が適用されます。
解決策
ここまでご紹介してきたように、Power Automateクラウドフローの実行時間が延びるという結果を生じさせる可能性のある要因はいくつかあるため、それぞれの制限ごとに、設計の際に考慮しておくべき解決策をご説明します。
①Power Automateの制限
クラウドフローに配置したアクションからのアクセスに対する制約となる、Power Platform要求の制限では、5分ごと、1日ごとの枠の中でリクエスト数や同時接続数がチェックされるので、始業直後などの特定の時間帯や月末などの特定の日にアクセスを集中させないようにします。リアルタイム処理でどうしてもピークとそれ以外のリクエスト数に開きが出るようであれば、バッチ処理に変えることを検討します。
また、市民開発でフロー開発を行っているうちに、フローの所有者になるのが特定のユーザーに固定化されているようであれば、ユーザーの偏りを減らすために、サービスアカウントを用意して所有者を切り替えたり、フローライセンスを購入することも検討します。
②Dataverseコネクタの制限
コネクタごとの制限は、接続ごとに掛けられるので、フローの所有者を変更したり、実行専用ユーザーを設定したりすることによって、認証に使用されるユーザーを分けることを検討します。
③Dataverseの制限
Dataverseアクセスに対する制約となる、サービス保護のAPI制限でも、Power Platform要求の制限と同様に、特定の時間帯にリクエストが集中しないように設計する必要があります。また、リクエスト数を減らそうとしてバッチ要求を実装すると、今度は実行時間の制限に抵触する可能性があるため、そのトレードオフを運用の中で調整する必要はあるかもしれません。
いずれの制限についても、PoCの段階や、運用初期のシステムだとなかなか問題が顕在化しないことも多いので、これらの対策をシステムに組み込んでおくことを目指すことも大切ですが、どちらかというと、制限に抵触して想定通りに動かなくなったことを検知するための運用・監視体制や、即座に不具合を修正できる保守体制を準備しておくことが、現実的には重要かと考えています。
他のデータソースの場合
ちなみに、ここまでDataverseを例にご説明してきましたが、市民開発でのデータソースとしてよく利用されるSharePointにもAPI制限（SharePoint Onlineの調整）が定められているので、ドキュメントライブラリ／カスタムリストにデータを保管するクラウドフローを作成する場合には、Dataverseと同様、制限に抵触しないようにAPIを呼び出すようにクラウドフローを設計する必要があります。
まとめ
今回は、クラウドフローの実行時間が延びる事象の原因について、Power Platformライセンスに基づく制約に着目しつつご紹介しました。
弊社の Power Platform サポート＆アプリカタログサービス では、キャンバスアプリやクラウドフローの実装に対する技術サポートから、ガバナンス管理・ガイドライン策定のご支援までを含めた、幅広いメニューをご提供しています。
まずはお気軽にお問い合わせください。
このブログで参照されている、Microsoft、Windows、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。その他の商標はそれぞれの権利者に帰属します。
