こんにちは、Power Platform サポートチームの山田です。
本記事では 下記公開情報でご案内のPower Automate クラウドフローの制限について、具体例などを用いてわかりやすく説明いたします。
自動化フロー、スケジュールされたフロー、インスタント フローの制限事項
本記事は上記公開情報の制限内容を補足・説明したものとなります。
実際の制限値などは上記公開情報をご確認ください。
目次
スループットの制限
スループットの制限とは、単位時間あたりに処理できる数をチェックする、現時点で適用中のPower Automate 単独の制限でございます。
全てフロー単位での制限となり、フロー実行中にチェックされる制限となります。
この項目でご案内する制限は「スループットの制限」に該当いたします。
スループットの制限には下記3種類がございます。
- Power Platform 要求の制限
- ランタイムエンドポイント要求
- コンテンツスループットの制限
制限に抵触した場合の動作、制限の緩和可否などは各種類によって異なります。
制限を決定する制限値は、ライセンスに基づくパフォーマンスプロファイルによって決定されます。
パフォーマンスプロファイルについては下記公開情報をご参照ください。
パフォーマンス プロファイル
パフォーマンス プロファイルとは何ですか?
制限の解除について、Power Automate のクラウドフローの場合はライセンス割り当て後にフローを再保存することで、新しいライセンスに紐づく制限を適用いたします。
再保存を行わなかった場合は、週に1度のバックグラウンド処理により適用いたします。
Power Platform 要求の制限
Power Platform 要求の制限とは、フロー実行時のアクションに関する制限となります。
フロー単位での制限となります。
制限に抵触すると、フローが低速実行（スロットリング状態）となります。
また、低速実行が14日間連続で発生した場合は、クラウドフローは自動でオフとなります。
下記の２種類がございます。
- 5分ごと、および24時間ごとのPower Platform要求
- 同時発信呼
5分ごと、および24時間ごとのPower Platform要求
詳細については下記記事をご参照ください。
Power Automate / Power Platform 要求数制限
同時発信呼
同時発信呼とは、ひとつのフローで同時に実行できるアクション数を指しております。
具体例として、フロー内でアクションが並列に実行されるよう構成されている場合や、複数のユーザーが同時にフローを実行する場合にこの制限に抵触する可能性が考えられます。
制限に抵触した場合、フローの実行が失敗します。
回避策として、例えば、コンカレンシー制御=同時実行管理をオンにすることが挙げられます。
同時実行する処理数を制限することで、同時発信呼の制限への抵触を回避いただけます。
または、ユーザー側で実行時間をずらす=ユーザー側でフローをトリガーするタイミングをずらすことも有効です。
制限の緩和策としては、パフォーマンス プロファイルをより高いものにしていただくこととなります。
ランタイムエンドポイント要求
ランタイムエンドポイントとは、フロー自体のエンドポイントを指します。 (例: https://prod-00.westus.logic.azure.com:443/)
例えば、下図の「HTTP要求の受信時」トリガー(manual)を使用するフローがある場合、「HTTP URL」に直接POSTリクエストを送信することで、フローを起動することが可能でございます。
上記の例のように、フロー実行時のエンドポイントへ (から) の直接のアクセスをランタイムエンドポイント要求と呼びます。
エンドポイントごとに制限対象となり、制限に抵触した場合、フローの実行が失敗します。
ランタイムエンドポイント要求には3つの制限がございます。
- 同時着信
- 5分ごとに通話を読み取る
- 5分ごとの Invoke 呼び出し
同時着信
同時着信とは、ひとつのフローのランタイムエンドポイントにて、同時に受付可能な要求数を指します。
そのため、例えば、複数ユーザーでボタントリガーのフローを共有しており、1,000 名以上のユーザーが同時刻にフローを起動した場合、この制限に抵触いたします。
制限に抵触した場合、フローの実行が失敗します。
回避策としては、例えば、コンカレンシー制御=同時実行管理をオンにすることが挙げられます。
同時に実行する数を制限することで、同時着信の数を減らし、制限への抵触を回避いただけます。
または、ユーザー側で実行時間をずらす=ユーザー側でフローをトリガーするタイミングをずらすことも有効です。
コンカレンシー制御=同時実行管理は、フロー編集画面でのトリガーの「設定」タブにてご利用いただけます。
重要
サービス保護の制限のため、緩和策はございません。
回避策をご対応ください。
5分ごとに通話を読み取る
5分間に実行可能なランタイムエンドポイントへの読み取り要求を指します。
例えば、フローの実行履歴から生の入力や出力を取得する際がこれにあたります。
例として、SharePoint コネクタの複数の項目の取得アクションを実行し、大量のデータを取得した場合、
生の出力データを確認するには、実行履歴詳細ページにて、「クリックしてダウンロードします」リンクをクリックする必要がある場合がございます。
リンクをクリックすると、ランタイムエンドポイントへの要求が実行され、生データをブラウザにて直接確認することが可能となります。
この要求が、ランタイムエンドポイントへの読み取り要求にあたります。
下図は「クリックしてダウンロードします」リンクをクリックした場合の例ですが、URL よりランタイムエンドポイントへの要求が実行されていることがわかります。
制限に抵触した場合、フロー実行が失敗します。
回避策としては、例えば、コンカレンシー制御=同時実行管理をオンにすることが挙げられます。
同時に実行する数を制限することで、5分ごとの読み取り数を削減し、制限への抵触を回避いただけます。
または、ユーザー側で実行時間をずらす=ユーザー側でフローをトリガーするタイミングをずらすことも有効です。
制限の緩和策としては、パフォーマンスプロファイルをより高いものにしていただくこととなります。
5分ごとの Invoke 呼び出し
5 分間に実行可能なランタイムエンドポイントへの呼び出し要求を指します。
例えば、上記にご案内した 「HTTP 要求の受信時」トリガーを呼び出す場合など、フローを起動する操作がこれにあたります。
制限に抵触した場合、フロー実行が失敗します。
回避策としては、例えば、コンカレンシー制御=同時実行管理をオンにすることが挙げられます。
同時に実行する数を制限することで、5分ごとの呼び出し数を削減し、制限への抵触を回避いただけます。
または、ユーザー側で実行時間をずらす=ユーザー側でフローをトリガーするタイミングをずらすことも有効です。
制限の緩和策としては、パフォーマンスプロファイルをより高いものにしていただくこととなります。
コンテンツスループットの制限
コンテンツスループットとは、フロー内の各アクションを実行後の入力および出力のデータサイズを指しております。
よって本制限は、フローの各実行において、単位時間に処理できるアクションで取り扱う情報量の制限となります。
例えば、フロー内で SharePoint コネクタの「項目の取得」アクションが使用された場合、
実行履歴に表示される入力 (SharePoint に対して送信されたアドレスやリスト名など) と出力 (SharePoint から取得した項目の詳細情報) のデータサイズがカウントされます。
フロー毎に、全てのアクションをカウントした合計サイズによる制限となります。
継続した5分、または24時間におけるフローごとに制限対象となります。
制限に抵触すると、フローが低速実行（スロットリング状態）となります。
回避策としては、例えば、コンカレンシー制御=同時実行管理をオンにすることが挙げられます。
同時に実行する数を制限することで、制限時間内の実行数を削減し、制限への抵触を回避いただけます。
または、ユーザー側で実行時間をずらす=ユーザー側でフローをトリガーするタイミングをずらすことも有効です。
制限の緩和策としては、パフォーマンスプロファイルをより高いものにしていただくこととなります。
Note
低速実行が14日間連続で発生した場合は、クラウドフローは自動でオフとなります。
要求の制限
HTTP要求の制限になります。
フロー実行では各アクションの中でHTTP要求を実行し、処理を行っております。
要求の制限は、各HTTP要求を実行するときにチェックされる制限でございます。
タイムアウトの制限
この項目ではタイムアウトとなる制限をご紹介します。
制限に抵触した場合、フローの実行が失敗します。
下記3種類の制限がございます。
- 送信同期要求
- 送信非同期要求
- 受信要求
重要
サービス保護の制限のため、いずれの制限にも緩和策はございません。
タイムアウトの制限は緩和できない＝タイムアウトまでの時間を延ばすことはできないものとなっております。
送信同期要求
フロー内の同期処理の待ち時間となります。
リクエストを投げてから待ち時間以内に応答がない場合、制限に抵触します。
INSERTやGET要求などAPIごとに制限対象となります。
制限に抵触した場合、フロー実行が失敗します。
例えば、DataverseやSQLテーブルの読み取りや書き込み時などが挙げられます。
テーブルに対する各操作をリクエストし、待ち時間以内に操作が完了せず、応答がない場合、フローの実行が失敗します。
送信非同期要求
アクションで実行されるHTTP要求（またはAPI）の非同期処理の待ち時間となります。
実行しているアクションごとでの時間となります。
例えば、承認アクションなどが挙げられます。
承認コネクタを通じて、承認リクエストを投げると、承認者からの承認完了を待ちます。
制限に抵触した場合（＝待ち時間以内に承認完了の応答がない場合）、フローの実行は失敗します。
重要
制限の回避策はございません。
受信要求
応答アクションがフロー内で使用されている場合、受信要求120秒の制限が適用される場合がございます。
当制限は制限された時間のみ受信要求を待機する動作となります。
フロー実行単位での制限となります。
制限に抵触した場合、フロー実行が失敗します。
フローの実行開始からカウントし、受信要求の120秒を超えて、応答アクションを実行できない場合、
応答アクションで設定したレスポンスではなく、504 Bad Gateway Timeoutを返します。
応答アクションが使用されていないフローの場合は、呼び出し元にすぐに202 Acceptedを返します。
例えば、下記のような構成のフローがございます。
- 「Power Apps がフローを呼び出したとき (V2)」トリガー
- トリガーに続いて、いくつかのアクション
- 最後に「Power App またはフローに応答する」アクション
上記フローはPower Appsキャンバスアプリから対象クラウドフローが呼び出され、「Power App またはフローに応答する」アクションによってそのフローからアプリに応答を返します。
トリガーと「Power App またはフローに応答する」アクションまでの間に、多くのアクションが設定されている場合、「Power App またはフローに応答する」アクションが実行されるまでに時間がかかることが想定されます。
トリガーが発動してから、「Power App またはフローに応答する」アクションを実行するまでに120秒を超える場合、制限に抵触いたします。
回避策としては、「Power App またはフローに応答する」アクション前までのアクションを子フローとして実行します。
子フローでの実行時間は待機時間にカウントされないため、制限対象の時間の短縮が可能でございます。
メッセージサイズの制限
1つのアクションでの、 HTTP要求可能なメッセージサイズの制限になります。
この制限に抵触した場合、フロー実行が失敗します。
下記のようなメッセージと共にエラーが発生します。
1 | HTTP 要求に失敗しました: 'Cannot write more bytes to the buffer than the configured maximum buffer size: 104857600.' |
回避策としては、アクションで処理するデータサイズを小さくします。
よりサイズが小さいデータを対象にアクションを設定ください。
緩和策として、通常は100MBまでとなりますが、下記条件を満たす場合、この制限は1GBとなります。
・アクションがチャンクをサポートしている
・アクションの設定でチャンクを許可している
再試行ポリシー
フローが失敗した場合の再試行数の制限になります。
上限以上の設定は不可となり、フローが保存できません。
再試行ポリシーに「指数の間隔」を設定しますと、設定された最小間隔、最大間隔の間でランダムに再試行が行われます。
例えば、「間隔」に “PT7S”＝7秒と設定した場合、7秒に指数をかけて、以下のように最小間隔と最大間隔を算出します。
最小間隔 ～ 最大間隔
- 1回目0秒 ～7秒（7×0～7×1）
- 2回目7秒 ～14秒（7×1～7×2）
- 3回目14秒 ～28秒（7×2～7×4）
- 4回目28秒 ～56秒（7×4～7×8）
- 5回目56秒 ～112秒（7×8～7×16）
- 6回目112秒 ～224秒（7×16～7×32）
- 7回目224秒 ～448秒（7×32～7×64）
算出された、最小間隔から最大間隔の間のどこかで、処理が再試行されます。
「最小間隔」「最大間隔」はオプション項目となり、設定しない場合は既定値で動作いたします。
「最小間隔」は、再試行させたい最小の間隔を設定します。「5秒」と設定しますと
再試行間隔は「間隔」から算出された最小間隔に関わらず、前の実行から5秒経過後となります。
「最大間隔」は、再試行させたい最大の間隔を設定します。
「1日」と設定しますと、「間隔」から算出された最大間隔に関わらず、1日以内に再試行されます。
「1時間」と設定しますと1時間以内に再試行されます。
下記公開情報もご参照ください。
指数間隔の再試行ポリシー
Note
再試行ポリシーの間隔、最小間隔、最大間隔は「ISO 8601」という形式を利用して設定します。
継続時間ということを表すため、「P」を先頭につけます。
時分秒を設定する時は「P」＋「T」＋数字＋「時分秒」という形で記載します。
例）
1時間 →PT1H
2時間 →PT2H
15分 →PT15M
30秒 →PT30S
日を設定する時は、「P」＋数字＋「D」という形で記載します。
例）
1日 →P1D
制限対象単位と制限抵触時の動作まとめ
| 制限種類 | 制限対象単位 | 制限抵触時の動作 |
|---|---|---|
| 5分ごと、および24時間ごとのPower Platform要求 | Power Automate / Power Platform 要求数制限を参照 | フローの実行が低速化 |
| 同時発信呼 | フローごと | フローの実行が失敗 |
| 同時着信 | エンドポイントごと | フローの実行が失敗 |
| 5分ごとに通話を読み取る | エンドポイントごと | フローの実行が失敗 |
| 5分ごとの Invoke 呼び出し | エンドポイントごと | フローの実行が失敗 |
| コンテンツスループットの制限 | フローの実行ごと | フローの実行が低速化 |
| 送信同期要求 | 実行するAPI≒アクションごと | フローの実行が失敗 |
| 送信非同期要求 | 実行するAPI≒アクションごと | フローの実行が失敗 |
| 受信要求 | フローごと | フローの実行が失敗 |
| メッセージサイズの制限 | アクションごと | フローの実行が失敗 |
| 再試行ポリシー | フローごと | フローの保存が不可 |
補足
本手順は執筆時点でのユーザー インターフェイスを基に紹介しています。バージョンアップによって若干の UI の遷移など異なる場合があります。その場合は画面の指示に従って進めてください。
※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。