AIものさし

Power Automateの429 TooManyRequestsを接続先の制限と同時実行から切り分ける

Power Automateの429 TooManyRequestsが出たとき、接続先APIの制限、アクション応答、同時実行と再試行を分けて調べます。

AIものさし編集部

目次

429を受けたら、まず失敗したactionの応答を見る

Power Automateのクラウドフローで429 TooManyRequestsが出たとき、最初にフロー全体へ一律の待機を足すのではなく、実行履歴から失敗したactionの出力を開きます。HTTP status、応答本文のerror、接続先の説明、再試行情報が含まれていればその値を記録し、同時刻の実行数と対象サービスの状態を合わせて確認します。

429は「要求が多すぎる」という応答ですが、どの制限主体が返したかで対処が変わります。接続先connectorのrate limitなら呼び出しを時間に分散する、batch化する、並列度を下げるなどが候補です。Power Platformのrequest上限なら、そのフローだけでなく同じユーザーや環境の他フローを含めた実行量を確認します。Dataverseのservice protectionや外部API固有の上限は、別の制限として扱います。

したがって、「429＝Power Automateのライセンス不足」「429＝connectorが必ず原因」「並列度を下げれば必ず解決」とは断定できません。run historyの実応答とAnalytics / 管理画面の利用状況を根拠に、原因別に手を選びます。

429の発生箇所を切り分ける

A. 接続先connectorまたは外部APIからの429

失敗したactionの出力に接続先固有のrate limitメッセージがある場合、対象サービスの使用量・時間窓・接続アカウント・他の呼び出し元を確認します。Power Automateの公式ガイダンスでは、connectorが429とrate limit超過のメッセージを返した場合、呼び出しを時間へ分散する、batch化する、別connectionを使うことを対処候補として挙げています。

ただし、別connectionへ切り替えるのは、その接続を使う権限とデータアクセスが正当な場合だけです。複数アカウントへ処理を分散して制限を回避する方法として使ってはいけません。connector固有の制限や契約を確認し、同じアカウントでの業務上の上限を守ります。

B. Power Platform requestの上限

Power Platform requestsはconnector actionだけでなく、HTTP actionや組み込みactionも含めて数えられる場合があります。成功したactionだけでなく失敗したaction、retry、paginationによる追加の処理もrequestを消費します。ループの中のactionは処理件数に応じて積み上がるため、フロー単体の実行回数だけでなく、各runで何個のactionが走るかを見ます。

Microsoftの現行ガイダンスでは、Power Platform request limitとconnector throttling limitは別の制限として説明されています。platform request制限はライセンス等の条件に依存し、複数フローにまたがる使用量を含むため、特定のconnectorの429とは調査範囲が異なります。具体的な利用枠や割当は契約・ライセンス・管理画面の最新表示で確認し、古い固定数値をすべての環境へ当てはめないでください。

使用量を見るときは、flow detailsのAnalyticsでActionsを確認し、管理者向けレポートが利用できる場合は同じユーザーや環境の使用量を照合します。短期間に急増したrun、Apply to eachの反復、pagination、retry、triggerが想定より頻繁に起動していないかを記録します。

C. Dataverseや接続先サービス独自の保護制限

Dataverseなどのサービスには、Power Platform全体のdaily request枠とは別に、サービス固有のservice protection limitsがあります。全体のrequest量が少なくても、特定ユーザー・操作・短時間の集中によって制限に達することがあります。Power Automate Processなどのフロー容量を増やせば全てのconnector制限が上がる、とは考えないでください。Microsoftのガイダンスもplatform request limitとconnector / Dataverse側の制限を分けています。

この場合は失敗actionが呼んだサービス、同一ユーザーの連続操作、応答内のサービス固有メッセージ、対象コネクタの公式制限を確認します。Dataverseならservice protectionの公式説明、外部APIならその提供元のAPI制限資料へ進みます。確認できない上限を推測して記事内に数値で書くことは避けます。

D. 同時実行・バーストによる短時間の集中

同じトリガーから複数runが重なったり、Apply to eachの並列度が高かったりすると、単一の時間帯へ要求が集中します。Microsoftの429トラブルシューティングは、短時間に多く実行した場合の対処としてフローのConcurrency Controlを下げる例を示しています。並列度を落とすことは、接続先が処理できる速度へ近づけるための有力な手段ですが、累積daily request上限や入力データの誤りは解決しません。

Concurrency Controlの設定を変える前に、どこで並列性が発生しているかを確認します。trigger設定の同時run、Apply to eachの並列実行、複数フロー、外部システムからの一括イベントは別々の入口です。変更の影響として処理時間、trigger待ち、run retention、業務上の完了期限も確認してください。

実行履歴で取るべき証拠

失敗したrunを開き、失敗actionとその直前の入力・出力を確認します。記録する項目は、run ID、開始時刻、action名、status code、error code/message、対象connector、再試行回数、並行していたrun数、対象データ件数です。秘密情報、個人情報、接続token、完全なpayloadは記録から除外するかマスクしてください。

エラーが親フローの最後のActionFailedだけなら、親の要約で原因を決めず、子actionや子フローまで開きます。最後に失敗した表示と、実際に429を返した下流サービスが異なることがあります。外部API actionなら、応答本文とheadersのうち非機密のstatus / throttling情報を確認します。応答にRetry-After等の再試行指示がある場合は、対象APIが定める意味を確認して尊重します。常にそのheaderがあると仮定せず、固定時間を全サービスへ流用しないでください。

同じactionが自動retry中に何度も実行される場合、接続先の負荷が増えることがあります。run historyでretry前後の実行時刻・回数・成否を見て、再試行ポリシーの設定がエラー種別に合うか確認します。書き込み・送金・メール送信などの副作用を持つ操作では、再試行による重複実行を防ぐidempotency keyや重複検出の仕組みがあるかも確認してください。存在しない場合に安全だと決めつけて自動retryを増やさないでください。

429原因別の対処表

表は横にスクロールできます

観測された証拠調査先対応の方向
1 connectorのactionにrate limit超過が明記connector / 接続先の制限、同じconnectionの使用量呼び出しを時間へ分散、必要な単位でbatch化、過剰な並列を減らす
flow Analyticsでrequest量が大きく複数フローにも集中Power Platform Analytics、ライセンス・request割当triggerを絞る、loop/pagination/action数を減らす、契約上必要な容量を評価
Dataverseを高頻度に呼び、service protection情報があるDataverse公式limitsとactionの実行主体request rateや処理パターンを見直し、該当するサービス制限に沿って調整
同じ時刻に大量runまたはloop parallelismが見えるtrigger Concurrency Control、Apply to each、外部イベント量ピークをならす。性能と待ち行列を測り、再実行の安全性を検証
親actionだけがActionFailed、子出力に別coderun historyの下位action・child flow実際に429を返した下流actionを特定してから対応
429が再試行後に成功、実行が重複する恐れretry history、下流操作の副作用APIのretry指示に従い、必要ならidempotency / 重複検出を設計

表は観測結果から確認先を決めるためのものです。複数の制限が同時に存在することもあり、単一原因と決めつけないでください。

要求数を減らすときの見直し順

まず不要なrunを減らします。トリガーが広い条件で起動してから後段のConditionで大半を捨てている場合、可能ならtrigger conditionなどで対象を絞ります。Microsoftのガイダンスは、data source側でfilterを使い、不要な項目をApply to eachへ渡さない方法を案内しています。

次に、loop内のconnector actionを洗い出します。100行を1行ずつ取得する設計と、適切なfilterや対応可能なbatch endpointを使う設計では、action/request数と接続先への負荷が変わります。ただし、batch化は接続先APIが提供し、同じ意味で処理できる場合に限ります。HTTP request数が必ず減る、またはデータの部分失敗が起きないとは限らないため、応答形式と再試行の単位を確認します。

その次に、不要なretryとpaginationを点検します。成功しない要求を短時間で繰り返す設定は負荷を増やすことがあります。一方で、retryを外せばデータ損失や一時障害が増える可能性もあります。どのエラーをretryするか、最大回数、間隔、最終失敗の通知、再実行手順をセットで設計してください。

最後に並列度を調整します。小さい値から安全に試し、完了時間、429率、失敗件数、重複処理、待ち行列、接続先の応答を比較します。並列度を最大にすることを目的にせず、SLAを守りながら失敗と二重処理が少ない設定を選びます。

再開前のチェックリスト

  1. run historyでHTTP 429の返却元となった実際のactionを特定した。

  2. error bodyと利用できる応答headerを確認し、秘密情報を除外して記録した。

  3. connector、Power Platform request、Dataverse service protection、trigger/loop concurrencyのうちどの層を示す証拠があるか整理した。

  4. flow Analyticsや管理レポートで、失敗時刻のaction数・run数・loop処理量を確認した。

  5. retryが接続先の指示に沿い、書き込みの重複を起こさない設計か確認した。

  6. 修正を開発または低リスクのテストflowで試し、429率だけでなく欠落・重複・処理時間も測った。

  7. 本番のConcurrency Control、ライセンス、接続、API制限を変える必要がある場合は、変更の影響とrollbackを整理した。

再開は、429の発生原因を完全に証明できなくても、現在の証拠と安全な暫定策が明確な場合に限ります。処理途中からの再実行で同じレコードを二重登録しないよう、最後に成功したcheckpoint、未完了item、再実行可能なactionを確認します。

現場での判断例

例として、ファイル作成triggerの後、Apply to eachで複数行を処理し、各行で同じSharePoint connectorを複数回呼ぶflowを考えます。429のaction出力にconnectorのrate limit超過があり、同時刻に多数のrunが集中しているなら、まずtriggerまたはloopの並列度を一段下げ、処理を時間へ分散し、少数のテストデータで再実行します。429が消えても、全itemが処理されたか、重複・欠落がないかを別に確認します。

一方、エラーは出るが失敗actionがPower Platform API request limitの警告を示し、他の複数flowも高いrequest量を使っているなら、connector単独のrate limit対策だけでは不十分です。Analyticsとライセンス条件を見て、不要なtrigger、loop内action、pagination、retryを削減するか、管理者と容量の選択を検討します。Service protectionの429であれば、そのサービスに対する実行速度を調整します。どの場合も根拠が異なるので、対処前にrun historyの証拠を保存します。

公式資料と確認範囲

次のMicrosoft公式資料を2026-10-15に確認しました。Cloud flow error referenceは下位actionの出力から原因を確認する考え方を示し、Too many requests guidanceは短時間の過剰実行とConcurrency Control低減を説明しています。Understand platform limitsはplatform request、connector throttling、Dataverse service protection、同時実行を分けています。個別環境のライセンス、管理レポート、connection、run historyは未確認です。

・Cloud flow error code reference：https://learn.microsoft.com/en-us/power-automate/error-reference（新しいタブで開く）

・Too many requests error in Power Automate：https://learn.microsoft.com/en-us/troubleshoot/power-platform/ai-builder/power-automate/too-many-requests-error-in-power-automate（新しいタブで開く）

・Understand platform limits and avoid throttling：https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/understand-limits（新しいタブで開く）

・Limits of automated, scheduled, and instant flows：https://learn.microsoft.com/en-us/power-automate/limits-and-config（新しいタブで開く）