目次
先に区別する：実行中runと待機run
Power AutomateのトリガーConcurrency Controlを有効にすると、同時に実行できるフローrun数を制限できます。上限へ達した後に届くtrigger eventは、待機runとしてqueueされることがあります。ここで、実行中のrun数、待機可能数、接続先コネクタのthrottling、トリガー側の再試行は別の制御です。Concurrencyを小さく設定すれば、すべてのイベントが無期限に安全保管されるわけではありません。
最初に答える問いは「最大で何件を並列化するか」ではなく、「到着の山をどの程度の時間で処理し、待機上限を超えた場合に何をするか」です。1分当たりの到着件数、runの所要時間、下流サービスの許容量を測り、ピーク時の不足分を計算してから設定を選びます。フローの処理を遅くするアクション、再試行でrun時間が伸びるケース、同じレコードへ同時に書く競合も含めます。
現行の公式上限を読む
2026-10-15時点でMicrosoft Learnの「Limits of automated, scheduled, and instant flows」は、トリガーConcurrency Controlの並列run数を1〜100、既定値を25と説明しています。待機runはConcurrency Control有効時に「10 + degree of parallelism（1〜100）」と記載されています。上限に達した状態で届く追加triggerについて、connectorが再試行する場合があるものの、長時間上限が満杯なら再試行が成功しない可能性も明記されています。
同じ公式ページは、Concurrency Controlが既定で無効であること、いったん有効にすると無効へ戻すことができず、設定を解除するにはトリガーを削除し再追加する必要があると注意しています。設計を元へ戻す手順が通常の数値変更より重いため、既存の本番フローで試験的にONにしないでください。テストflowで運用条件を検証してから、変更影響と復旧手順を承認してください。
これらの値は公式ページ上の一般的な上限表です。フローの種類、ライセンス、環境、コネクタ、テナントで適用条件が変わる場合があります。設計時には対象環境でLimits and configを読み、実際のtrigger設定に表示される値を確認してください。この記事はMicrosoftアカウントやテナントで実測した値を示すものではありません。
到着率と処理時間から並列度を考える
まず、通常時とピーク時について以下を実行履歴や業務ログから記録します。
表は横にスクロールできます
| 指標 | 記録する値 | 何に使うか |
|---|---|---|
| 到着率 | 1分・5分あたりのtrigger件数 | 突発バーストの規模を把握 |
| run時間 | p50だけでなくp95の処理時間 | 遅いrunが占有する時間を見積もる |
| 下流上限 | connector/APIのrate limitや同時数 | 並列化の安全な上限を決める |
| 再試行 | throttling・一時失敗・待機時間 | runの占有時間と重複副作用を確認 |
| 業務期限 | 何分以内に処理されるべきか | backlogを許容できるか判断 |
| 重複時の影響 | 二重請求、二重作成、二重通知等 | 冪等化と重複排除の必要性を決める |
概算には、平均到着率λ（件/秒）と平均処理時間W（秒）を使い、同時実行の必要量をおおよそλ×Wとして考えます。これはqueueingの初期目安であり、Microsoftの保証式や上限ではありません。ピークの偏り、run時間の長い尾、再試行、下流側のcapacityを加味し、少量から負荷試験します。
例として、通常は毎分6件、ピークでは2分間に40件が来るflowを考えます。平均値だけなら低い並列度で足りそうでも、2分間の一時的なピークでは待機runが増えます。p95処理時間が3分なら、ピーク終了時にも未処理runが残る可能性があります。ここで必要なのは「Concurrencyを40にする」ことではありません。まず下流connectorがその並列数を処理できるか、同じ対象を更新する競合がないか、待機枠を超えるときイベントを再送・補完できるかを調べます。
待機上限を超えたときの復旧設計
待機上限に達する前提で、追加イベントの行き先を決めます。イベント源が再送するのか、送信側に未処理一覧が残るのか、受信側に監査ログを持つのかで復旧手段が異なります。connectorが再試行する可能性を、永続キューとして扱わないでください。Microsoft Learnが注意するように、上限が長時間いっぱいだと再試行が成功しない場合があります。
表は横にスクロールできます
| 起きたこと | 最初に確認する証跡 | 安全な復旧 |
|---|---|---|
| run数が上限に張り付く | run duration、waiting数、遅いaction | 下流制限とp95時間を調べ、処理量を段階的に調整 |
| 待機枠が満杯になる | trigger履歴、送信元の再試行・未配信記録 | 送信元から未処理IDを照合し、欠落分だけ再投入 |
| connector throttlingが増える | connector error、429相当応答、retry history | concurrencyを下げるか、delay/batch化を検討 |
| 同じ項目が重複する | 業務ID、run ID、書き込み履歴 | 一意キーで処理済み状態を照合して冪等に再開 |
| runが長時間滞留する | age、状態、最後の成功action | SLAを超えたrunを通知・隔離し、原因別に再実行 |
| 上限変更後に副作用が増える | 二重更新、順序変化、競合ログ | テスト結果とrollback可能性を確認し、広げずに停止 |
再実行前には入力ID、現在の下流状態、既に完了した副作用を照合します。失敗表示だけを根拠に最初からやり直すと、メール二重送信やレコード重複を生む場合があります。再投入するデータには元イベントIDまたは業務キーを持たせ、処理済みIDはno-opにする設計が有効です。
設定変更の前に測る
Concurrency Controlを有効にする前に、テスト環境でarrival patternを再現します。1件、連続数件、burst、下流throttling、長時間処理、同一レコード競合のケースを作り、run count、queueの増加、待機時間、失敗・retry、最終的な処理済みID集合を記録します。設定値を上げた結果、エラー率や重複が増えたら「速くなった」と判断しません。
表は横にスクロールできます
| テスト | 入力条件 | 合格させる確認 |
|---|---|---|
| 通常到着 | 実測した通常頻度 | waitingが継続増加せず、SLA内に完了 |
| 短いburst | 想定ピーク数を短時間投入 | waiting上限、滞留時間、処理後件数を記録 |
| 下流throttle | テスト接続先で一時制限を再現 | retry中も二重副作用がない |
| 長いrun | 最大側の処理時間 | 実行枠を占有し続ける影響を測る |
| 重複入力 | 同じ業務IDを再送 | 1回分だけ更新され、重複を記録 |
| 再処理 | 途中まで処理したIDを再投入 | 未完了部分だけ安全に継続 |
測定後、Concurrency値を一度に最大へしません。下流サービスの許容値より小さく開始し、一定期間のerror rate、throttle、waiting age、成功率、重複を比較します。対象flowの運用責任者は、設定変更前に元の値、変更日時、影響対象、緊急停止とトリガー再作成の手順を記録してください。
数値以外に見る設計条件
Concurrencyを下げると、処理は順番に近づく一方、待機時間が伸びます。Concurrencyを上げると、同時に動くrunと下流呼出しが増え、状態共有、API quota、ロック競合、順序依存を検証する必要があります。どの設定でも、「到着数が一時的に処理能力を超えた場合に欠落なく後から回復できるか」が設計の中心です。
待機run上限に収まるなら十分、とは限りません。queueが上限以下でも、最古runのageが業務期限を超えている可能性があります。waiting run countだけでなく、最古の待機時間、未処理イベント数、送信元の未配信件数を監視します。connectorのretryが成功したように見えても、どのイベントが最終的に処理されたかをID集合で照合してください。
また、flow全体の同時実行数とApply to each内のloop concurrencyは別設定です。trigger側を制限しても、1runの中で複数itemが並列処理されれば、下流呼出しは想定以上になり得ます。逆も同様で、loopの並列度を下げても複数runが同時に到着すれば、flow全体の負荷は増えます。両方の同時数と各connectorの利用量を合算して確認してください。
実装前のcapacity worksheet
次の表を対象flowごとに記入します。空欄が残る場合はConcurrencyを有効化する前に測定または確認します。
表は横にスクロールできます
| 項目 | 記録する内容 |
|---|---|
| Trigger / connector | 製品名、trigger名、環境、connection |
| 到着率 | 通常・p95相当ピーク・burst時間 |
| run時間 | p50 / p95、再試行を含む最大観測 |
| 下流capacity | request/min、同時接続、quota、rate limit |
| trigger concurrency | 現行値、提案値、根拠 |
| waiting | 現行件数、上限、最古run age |
| item loop | Apply to eachの件数と内部並列度 |
| 重複防止 | Event ID / business keyと処理済み記録 |
| overflow | 待機枠満杯時の未処理ID取得・再投入経路 |
| rollback | 設定変更の取り消し制約と責任者 |
capacityの根拠が不明な場合、同じ環境の既存フロー値をそのままコピーしないでください。別のtriggerやconnectorでは到着数・処理時間・rate limitが異なります。まず少量の安全なテストで測定し、production設定変更は担当者が影響と戻し方を確認してから行います。
結論：待機runをあてにせず、overflow後の回復まで決める
Concurrency Controlは、同時runを制限する道具であり、イベントを無期限保存するqueueではありません。公式の現在値を確認したうえで、到着率・p95処理時間・下流capacityから小さな候補値を作り、待機枠が満杯になるケースをテストします。待機枠を超えたtriggerを送信元から再取得できるか、IDで欠落・重複を照合できるかを完了条件にしてください。
特にConcurrency Controlは有効化後にOFFへ戻せないという公式注意があります。設定変更を既存本番flowで試さず、テストflowで設定と復旧を確認してから変更申請します。値を上げることより、未処理イベントが見えること、下流制限に沿って処理されること、失敗後に安全に再開できることを先に整えるのが実務上の優先順位です。
公式情報と確認範囲
2026-10-15にMicrosoft LearnのPower Automate limits and configを確認しました。トリガーConcurrency Control、waiting runs、Apply to each、Split onの公開上限と設定上の注意を参照しています。数値は現行ページに記載された値ですが、実際の適用条件はプラン・フロー種別・環境で確認してください。
出典・適用範囲
対象はPower Automate cloud flowのtrigger concurrencyとwaiting run設計です。個別tenantやconnectorの実測、送信元の再試行契約、下流サービスのquotaは確認していません。公式文書上の上限値を読者の環境で無条件に保証するものではありません。