Power AutomateのアクションがHTTP 429で失敗したら、同じフローを何度も手動再実行する前に、どのアクション・コネクタ・実行パターンが制限に達したかを確認します。429は「Power Automateの全体上限」と同じ意味ではありません。コネクタ側のスループット制限、Power Platform request allocation、Dataverseのservice protectionなど、制限主体によって対処が異なります。まず失敗した場所とエラー本文を記録し、副作用が重複しない再開方法を選びます。
目次
最初に記録する5項目
失敗したRunの詳細を開き、赤く表示されたactionを展開します。後続のactionまで含めた全体エラーだけで判断しないでください。
-
Flow名、Run ID、発生時刻、手動・自動のどちらで開始したか。
-
失敗したaction名とconnector名。Apply to each内なら対象件数も記録する。
-
HTTP status、error code、message全文。特に「Rate limit is exceeded」などの文言や、再試行までの秒数が表示されるか。
-
同じ時間帯に同一connectionを使う別Flowや、他の大量処理があったか。
-
そのactionが読取、作成、更新、削除、通知のどれか。再実行で二重登録・二重送信が起き得るか。
アクセストークン、資格情報、顧客データをメモへ貼る必要はありません。エラーの該当部分を機密情報を伏せて記録します。
制限の種類を分ける
表は横にスクロールできます
| 手掛かり | 可能性が高い制限 | 先に試すこと |
|---|---|---|
| 1つのconnector actionで429、Rate limit exceeded、再試行秒数の案内 | connector-level throttling | そのconnectorの現行上限、同じconnectionの並列呼出し、短時間のburstを確認する |
| 複数Flowで遅延し、管理レポートのrequest量が日次allocationへ近い | Power Platform request limit | 所有者/ライセンス/日次期間と、Apply to eachの総action数を確認する |
| Dataverse actionで高負荷時にservice protectionエラー | Dataverse固有制限 | 同時実行と要求率を下げ、Dataverseのservice protection資料とエラー詳細を見る |
| actionが429以外（401/403/404など） | 認証・権限・ポリシー・参照先の問題 | connection状態と対象resourceを確認し、429として再試行を増やさない |
Microsoftはconnectorごとに独自のthrottling limitがあると説明し、Power Platform request limitとconnector throttlingを区別しています。Flowが消費する日次requestが余っていても、コネクタ側の一時的なrate limitには達し得ます。逆に、Processライセンスなどの容量が関係する状況と、特定connectorの上限は同じではありません。原因を分けずにライセンスを買い足したり、別connectionへ移したりしないでください。
Run historyから失敗位置を特定する
Run historyで失敗Runを開き、どのactionが最初に失敗したかを見ます。Apply to each内なら、何件目のitemで失敗したか、失敗前に何件が成功したかを記録します。前段のactionが429を返しているのに、後続処理やConnectionの再認証を直しても解消しません。
次に、同じ時間帯のRunを数件並べ、失敗が単発か、同じactionで連続するか、並列処理の開始直後だけ集中するかを確認します。特定connectionが複数Flowで共有されていれば、1 Flowだけを見ても要求量の全体像が見えません。Run履歴の成功数・失敗数と、同一接続を使う並行Flowの開始時刻を照合します。
Power Automateの公式troubleshootingは429を「そのconnectorのAPI rate limitへ達した」症状として案内しています。個別connectorの詳細上限や適用単位はコネクタによって違うため、記事内に固定の回数を当てはめず、実際に使っているconnectorの公式ページで現在の制限を確認します。
Retry policyを使う条件
Retry policyは一時的・断続的な障害から回復するための仕組みです。Power Automateの公式guidanceでは、action設定で固定間隔または指数間隔を選べ、指数間隔は再試行間隔を徐々に広げる方式と説明されています。ただし、retryを有効にすれば恒常的な要求超過が解消するわけではありません。制限が継続しているのに短い間隔で呼び直すと、要求を増やして回復を遅らせる場合があります。
Retryを調整する前に、actionが何を変更するかを確認します。
-
読取・照会：同じ要求を再送してもデータを変更しないか。
-
作成：一度成功した後の応答だけが失われ、再送するとレコードが重複しないか。業務キーで既存レコードを照合できるか。
-
更新：更新対象が一意か、再送でカウンターや金額を二重に加算しないか。
-
メール・通知・外部API：受信者へ重複送信しない仕組みやidempotency keyがあるか。
-
削除・承認など不可逆処理：結果不明のまま再送せず、対象の現在状態を先に照会できるか。
副作用が安全で、エラーが一時的と考えられる場合に、対象actionのretry policyを使います。公式guidanceは指数間隔が一時的障害に有効な理由を説明していますが、特定のconnectorで常に最適な値を保証するものではありません。connectorの案内やerror messageに従い、成功後もRun履歴で総試行回数と処理件数を確かめます。
要求量を減らす選択肢
同じconnectorで継続して429が起こるなら、retry回数を増やす前に1 Runが送る要求を数えます。Apply to eachが1,000件を処理し各itemで3 actionを呼べば、そのloopだけで多数のconnector要求が発生します。Paginationや追加のGet itemも要求に数えられるため、Flowの見かけ上のaction数だけで見積もらないでください。
対策は状況に応じて選びます。
-
不要な列・レコードを事前filterして、後続actionへ渡す件数を減らす。
-
connectorが提供するbatch操作がある場合、個別呼出しを安全にまとめられるか調べる。batch対応やサイズはconnector資料で確認する。
-
loopのConcurrencyを下げる、または処理を時間帯・範囲ごとに分散し、同じconnectionからのburstを減らす。
-
大量処理を小さなchunkへ分け、成功位置・再開位置・未処理数を記録する。
-
日次request allocationの超過が根拠をもって確認できた場合のみ、license/capacityと処理量削減を管理者と比較する。
「別Connectionを作る」は、個別ユーザーやconnection単位で制限を分散できると確認できた場合だけ検討します。単にconnection数を増やして制限を迂回すると、組織ポリシーやデータ境界を損ねる可能性があります。また、Power Platformの日次request allocationを超えた問題には、connector数を変えるだけでは解決しません。
再実行前に二重処理を防ぐ
Runが途中失敗したときは、どこまで成功したかが最重要です。作成や通知actionで429が返っても、相手側が処理して応答だけを返せなかった可能性を、エラーコードだけで否定できません。再送の前に宛先システムで業務キー・message ID・更新日時などを照合し、処理済みか確認します。
たとえば請求書レコードを作るFlowなら、請求書番号と仕入先IDを組にしたキーで既存行を検索してから再開する方法があります。メール送信なら、送信ログへ実行ID・対象ID・送信結果を記録し、同じ組合せが既に完了していないか確認してから再送します。こうしたキーが設計にない場合、同じRunをそのままResubmitせず、所有者・管理者と安全な復旧方法を決めます。
Microsoftは失敗Runの再送について、重複データや重複メールなど副作用の可能性を確認し、入力データとFlow変更後の挙動を確かめてから実施するよう注意しています。成功済みのitemからやり直さず、未処理部分だけを特定して再開できる記録を残します。
切り分け用の実務チェック表
表は横にスクロールできます
| 確認 | 記録例 | 判断に使うこと |
|---|---|---|
| 失敗箇所 | SharePoint Create item / loop item 37 | connector・action固有か |
| Response | 429 / rate limit / retry hint | connector limitの証拠か |
| 時系列 | 10:05に同一connectionの3 Flowが並列開始 | burst・共有connectionの影響か |
| 要求量 | 対象件数、loop action数、pagination回数 | request量削減か分散が必要か |
| 副作用 | item作成済みか、メール送信済みか | retry/Resubmitの安全性 |
| 再開点 | 成功済みID、失敗ID、未処理ID | 二重処理を避けて再開できるか |
この表の目的は上限値を推定することではなく、現在の制限主体・処理位置・再送リスクを確かめることです。connectorごとの数値、期間、適用されるconnectionやアカウントは公式の現行仕様で確認します。
次に行うこと
まず失敗Runからaction・connector・エラー全文・loop件数を記録し、429がconnector levelか日次request allocationかを切り分けます。副作用があるactionは、再送前に相手側の状態を照合してください。connector上限なら要求を減らす・分散する・connector固有のretry条件を確認する。日次allocationなら全Flowのrequest消費を見直す。原因を特定できない場合はRun ID、action名、機密値を伏せたerror、同じ接続を使うFlow数、成功済み処理、再開位置を管理者へ渡します。
公式Sources
Microsoft Learn, Understand platform limits and avoid throttling: https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/understand-limits（新しいタブで開く）
Microsoft Learn, Employ robust error handling: https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/error-handling（新しいタブで開く）
Microsoft Learn, Fix connection failures in cloud flows: https://learn.microsoft.com/en-us/power-automate/fix-connection-failures（新しいタブで開く）
Microsoft Learn, Test cloud flows: https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/test-cloud-flows（新しいタブで開く）
確認日：2026-10-15。数値上限はconnector・license・accountにより異なるため本文中で固定値を一般化していない。