こんにちは。システムソリューション営業本部の吾妻です。



Power Automateクラウドフローを活用している 大規模な組織 において頻発するエラーの代表的なものに、 429 エラーがあります。

今回の記事では、この 429 エラーを例として、Power Automateクラウドフローでエラーが起こる原因や、トラブルシューティングの方法について、ご紹介していきたいと思います。

3桁のコード

Power Automateクラウドフローも含めて、HTTPプロトコルでデータをやり取りするサービスでは、リクエストが正常に完了したどうかを示すステータスコードをレスポンスの中で返します。 429 も、そのような HTTPレスポンスステータスコード の1つです。

HTTPレスポンスステータスコードで定義されているコードは、必ずしもエラーを示すものだけでなく、百番台の数ごとに分類して定義されています。

429 エラーの場合、「4」百番台のエラーなので、クライアント側に何らかの問題があることが分かります。

仕様書を確認してみると、「429 Too Many Requests」は、一定の時間内にユーザーが送信したリクエストの数が多すぎる（レート制限に引っ掛かっている）ことを示す」と定義されています。

そのため、Power Automateクラウドフローのどこかで、大量にリクエストを送信している箇所が存在する、ということになります。



429 エラー以外の、Power Automateクラウドフローでよく目にするようなエラーコードを挙げてみます。 

クライアントサイドとサーバーサイド

Power Automateクラウドフローで少々混乱しやすいのが、クラウドフローから外部サービスにリクエストを送信する場合は、クラウドフローが「クライアント側」となることです。




普段、私たちがブラウザを利用してWebページを閲覧する場合、 利用者（ブラウザ） は「クライアント側」、Webページを公開している Webサーバー は「サーバー側」となります。ですので、Webサーバーに対してリクエストしたWebページが、ブラウザにきちんと返されれば、ステータスコード「200 OK」となり、ブラウザに送られてきたWebページの内容が表示されます。ブラウザの場合と同様に、PowerShellなどを用いてGraph APIやSharePoint REST APIにアクセスする場合も、 利用者（PowerShell） は「クライアント側」、Graph APIなどを公開している APIサーバー は「サーバー側」となります。


一方で、Power Automateクラウドフローの中で外部サービスにリクエストを送信する場合は、利用者（ブラウザ）は関係なく、 クラウドフロー が「クライアント側」、外部サービスを公開している APIサーバー が「サーバー側」となります。つまり、 クラウドフローから外部サービスにリクエストを送信するのは、利用者のブラウザではなく、Power Automateクラウドフロー （が実行されているAzureサービス）となります。


公式資料に「Power Platform の URL と IP アドレスの範囲」として「アクセス元」のURLやIPアドレスが公開されていることからも、外部サービスにアクセスしにいくのはブラウザではなくクラウドフローであることが分かります（余談ですが、Azureなどのクラウド上に独自に実装したサービスでIP範囲によるアクセス制限をかけている場合は、この資料に記載されているIPアドレスをホワイトリストに追加しておく必要があります）。





最初の 429 エラーの例に話を戻します。

429 エラーは「4」百番台のエラーなので、クライアント側に問題があって処理に失敗したことを示していますが、この場合の「クライアント側」とは、クラウドフローと外部サービスの間での「クライアント側」なので、クラウドフローの実装を見直してみる必要がある、ということになります。

原因箇所の特定

Power Automateクラウドフローに定義したトリガー・アクションのうち、エラーを発生させているものを特定します。


まず、Power Automateのマイフローから、フローの詳細画面を開き、クラウドフローの実行履歴を確認します。「状況」が「失敗」となっている実行履歴をクリックして開きます。





実行履歴を開くと、エラーが発生したトリガー／アクションに (！) アイコンが表示されています。

下図の場合だと、HTTPアクションに 429 エラーが表示されていることが分かります。この場合、HTTPアクションでパラメーターとして指定されたURI（URL）に対して、クラウドフローからリクエストを送信したところ、指定したURIを公開しているサーバーから 429 ステータスコードが返された、という状況を示しています。そのため、クラウドフローの中で、「リクエストを送信する処理」に何らかの変更を加えなければなりません。HTTPアクションに限らず、DataverseやSharePointに対してリクエストを送信するようなアクションであれば、同様のエラーが生じることがあり得ますし、同様にトラブルシューティングすることができます。

原因と対応策

Power Automateで 429 エラーが発生する原因としては、主に以下のようなものが挙げられます。

• 開発者が 意図せず 組み込んでしまった処理によるもの
  • アクションのパラメーターに指定する値として「動的なコンテンツ」を選択する際に、誤って配列型の要素を選択してしまい、「For each（それぞれに適用する）」アクションが自動的に追加された場合（例）
    
    
  • トリガーに設定する「トリガーの条件」を指定する際に、仕様よりも条件を甘く指定してしまい、想定よりも多くトリガーが起動されてしまう場合
    
    
• 開発者が 意図して 組み込んだ処理によるもの
  • 組織内の全ユーザーを対象としたり、Teamsに投稿された全メッセージを対象としたりというように、そもそも大量のレコードを想定した処理を組込んだが、導入済のライセンスなどの理由によって想定した仕様を実現できない場合

いずれの場合も、一定時間内に送信するリクエストの数を減らさない限り、 429 エラーが解消することはありません。

開発者が意図せず組み込んでしまった処理が原因の場合は、処理を見直すことで解消する可能性がありますが、意図して組み込んだ処理が原因の場合は、繰り返しの対象とする配列の要素（ユーザー、Microsoft 365グループ、Teamsメッセージ、…）の数を予めフィルタリングして減らしておく、クラウドフロー（と所有者）を分割して1フローあたり担当する要素の数を減らす（クラウドフロー自体を並列実行させる）、といった仕様の再検討が必要となります。



このように、組織内での市民開発の進展とともに、クラウドフローで実行されるタスクが、メールを受け取ったらTeamsで通知する、添付ファイルをSharePointドキュメントライブラリに格納する、といった 個人単位のタスク から、Formsでアンケートが送信されたらExcelに転記する、Dataverseテーブルのレコードが更新されたら所有者を変更する、といった 組織全体のタスク へと移り変わっていくことで、クラウドフローそのものの実装だけでなく、クラウドフローをどのように配置、管理し、ライセンスやフローの作成者・所有者を管理していくか、ということも考えなければなりません。

ガバナンス管理の一環として、市民開発が活発になる前に予めルールを策定しておくとスムーズです。

まとめ

今回は、市民開発が盛んになってくると頻発する 429 エラーを題材として、Power Automateクラウドフローでのトラブルシューティングの方法について簡単にご紹介しました。

弊社の Power Platform サポート＆アプリカタログサービス では、キャンバスアプリやクラウドフローの実装に対する技術サポートから、ガバナンス管理・ガイドライン策定のご支援までを含めた、幅広いメニューをご提供しています。

まずはお気軽にお問い合わせください。

Power Apps/Power Platform サポート＆アプリカタログサービス ｜ 株式会社QUICK E-Solutions
Power Apps/Power Platform サポート＆アプリカタログサービス｜QESは、日本経済新聞社グループNo.1のITプロ集団として、日本を代表する金融情報サービス会社、QUICKのシステムの開発･運用･保守を担うとともに、金融･証券、事業会社など幅広いお客様に様々なICTソリューションとオフィスソリューションを提供しています。