【Power Automate】再試行ポリシーが想定外に繰り返される時の入力値と条件分岐の直し方

Power Automateのフローを作成していると、再試行ポリシーが思ったよりも多く繰り返されて困った経験はないでしょうか。特にHTTP要求やAPI呼び出しを含むフローでは、一時的なエラーを想定して再試行を設定しますが、条件分岐の設計や入力値の扱い方によって無限に近いループが発生することがあります。この記事では、再試行ポリシーが想定外に繰り返される原因を整理し、入力値と条件分岐の具体的な直し方を解説します。

再試行ポリシーの基本と想定外の繰り返しが起きるメカニズム

Power Automateの再試行ポリシーは、アクションが失敗したときに自動的に再実行する仕組みです。既定では最大3回、指数関数的に待機時間が増える設定になっています。しかし、この再試行が「想定外に繰り返される」と感じる状況は、大きく分けて二つあります。一つは再試行ポリシーの設定値が実際の許容範囲より大きいケース、もう一つはアクションが成功扱いにならずに再試行を繰り返すケースです。後者は特に条件分岐や入力値の設計に問題がある場合に発生します。たとえば、アクションの出力を条件の判定に使っているにもかかわらず、その出力が毎回同じエラーを返す場合、再試行を続けても状況が改善されません。また、変数の更新を忘れると、同じ入力値で何度もアクションが呼び出され、結果として再試行ポリシーの上限に達する前にフローがタイムアウトしたり、予想外の課金が発生したりします。

再試行ポリシーはあくまで一時的な障害への対策であり、根本的なエラーを解決するものではないことを理解しておく必要があります。想定外の繰り返しを防ぐには、ポリシーの設定だけでなく、フロー全体の条件分岐と入力値の流れを適切に設計することが重要です。

再試行ポリシーの種類	既定の最大再試行回数	待機時間	想定外繰り返しの原因例
指数関数的再試行	3回	10秒→20秒→40秒	条件分岐が常に失敗を示すため、再試行後も同じ結果
固定間隔再試行	3回	指定秒(例:30秒)	入力値が変わらず、毎回同じエラーが発生
なし	0回	なし	再試行しないため、想定外の繰り返しは起きないが、失敗時の処理が必要

原因1:条件分岐における出力値の誤った比較

再試行の繰り返しで最も多い原因は、条件分岐でアクションの出力を正しく評価できていないことです。たとえばHTTPアクションのステータスコードやエラーメッセージを条件に使う場合、出力がオブジェクトや配列であることを忘れて単純な文字列比較をしてしまうと、常に条件が偽となり、再試行後も同じエラーが発生し続けます。また、成功時に返される値と失敗時に返される値の型が異なるケースにも注意が必要です。

具体的な失敗パターンとして、「ステータスコードが200以外なら再試行する」という条件を書いた場合、ステータスコードが実際には文字列型なのに数値型と比較してしまい、常に不一致になることがあります。Power Automateの動的コンテンツでは、出力の型が推測されますが、実データと異なる場合があるため、式エディタで型変換を行う必要があります。

失敗パターン:ステータスコードを数値として比較

例えば、HTTPアクションの出力からステータスコードを取得する際、式にoutputs('HTTP')?['statusCode']と指定した場合、返ってくる値は多くの場合文字列です。しかし、条件分岐で@{outputs('HTTP')?['statusCode']} equals 200のように数値の200と比較すると、型の不一致で常にfalseになります。その結果、再試行ポリシーが発動し、同じHTTP要求が繰り返されます。

この問題を解決するには、型変換を行うか、比較方法を変更します。正しい式は@{int(outputs('HTTP')?['statusCode'])} equals 200のように、数値に変換してから比較します。または、文字列のまま比較する場合は@{outputs('HTTP')?['statusCode']} equals '200'とします。

原因2:変数や入力値を更新しないまま再試行

再試行ポリシーはアクションが失敗したときに自動的に再実行しますが、その際に入力値が変わっていなければ、同じ失敗を繰り返すだけです。たとえば、あるAPIに対してトークンを取得するアクションがあり、トークンの有効期限が切れている場合、再試行しても同じ無効なトークンを使うため、毎回認証エラーになります。このようなケースでは、再試行前にトークンを更新するロジックを入れるか、そもそも再試行ポリシーに頼らずにエラー処理を別途実装する必要があります。

もう一つの典型的なパターンは、ループ内で再試行ポリシーを使っている場合です。ループの各イテレーションで同じ変数を使いまわしていると、一度失敗したあとも同じ値で再試行が繰り返され、指定回数を超えてループ自体が終了しなくなることがあります。この場合、ループの条件を適切に設定し、再試行カウントを手動でインクリメントするなどの対策が必要です。

対処手順:変数の初期化と更新を確認する

1. フローの先頭で、再試行に関係する変数(例: retryCount)を初期化することを確認します。例えば「変数を設定」アクションで0を代入します。
2. 再試行対象のアクションの前に、変数に現在の再試行回数を保持するようにします。「適用する各」ループを使う場合は、イテレーションごとに変数をインクリメントします。
3. アクションが失敗した場合、条件分岐で変数が最大許容回数に達したかどうかをチェックします。達した場合はフローを終了するか、別のエラー処理に分岐します。
4. 再試行後に成功した場合は、変数をリセットするか、次の処理に進むようにします。変数をリセットしないと、後続のアクションで異常な値が残る可能性があります。
5. 最後に、再試行ポリシーの設定自体を「なし」または最小回数(1回など)に変更し、手動の再試行ロジックで制御することを検討します。

原因3:再試行ポリシーの設定とアクションのタイムアウトの不一致

再試行ポリシーはアクションごとに設定できますが、アクション自体のタイムアウト設定と矛盾している場合があります。例えば、HTTPアクションのタイムアウトが30秒に設定されているのに対し、再試行ポリシーの最大待機時間が60秒だと、再試行の待機中にタイムアウトが発生し、さらに再試行がトリガーされるという無限ループが起きることがあります。この現象は、Power Automateのドキュメントでは明確に説明されていない部分ですが、実際の運用でよく見られます。

解決策としては、アクションのタイムアウトを再試行ポリシーの最大待機時間より長く設定するか、逆に再試行ポリシーの最大待機時間をタイムアウトより短くします。理想的には、再試行ポリシーの総待機時間(初期待機+増加待機)がアクションのタイムアウトを超えないように設計します。

管理者に確認すべき設定と注意点

会社のテナントでPower Automateを利用する場合、管理者によっては特定のコネクタにアクセス制限やスロットリング制限がかけられていることがあります。再試行ポリシーが想定外に繰り返される背景に、これらの制限値に引っかかっている可能性も考えられます。また、データ損失防止ポリシー(DLP)によって、特定のコネクタの使用が制限されていると、アクションが失敗しやすくなります。

管理者に確認すべき情報を以下にまとめます。

• 使用しているコネクタのAPI制限(1分あたりの呼び出し回数など)。
• テナント全体のPower Automate実行制限(同時実行数や1日あたりの実行数)。
• コネクタのカスタムコネクタを使用している場合、その認証情報の有効期限やスコープ。
• フロー共有の設定で、他のユーザーがフローを編集できる場合に、意図しない変更が入っていないか。
• 監査ログの確認方法。想定外の繰り返しが発生している時間帯に、同時に他のフローが大量実行されていないか。

よくある質問

再試行ポリシーを「なし」にするとどうなりますか?

再試行ポリシーを「なし」にすると、アクションが一度失敗した時点でフローが停止します。その後のエラー処理は「実行後のタイムアウト」や「条件分岐」で自分で実装する必要があります。想定外の繰り返しを避ける最も確実な方法ですが、一時的な障害で停止してしまうリスクがあります。

再試行ポリシーの最大間隔はどのくらいが適切ですか?

最大間隔は、対象となるAPIやサービスの推奨待機時間に応じて設定します。一般的なサードパーティAPIでは30秒から60秒程度が推奨されることが多いですが、Power Automateの既定(指数関数的で最大60秒)で十分な場合がほとんどです。ただし、外部サービスが過負荷状態の場合、この間隔では改善しないことがあります。

再試行中にフローがタイムアウトするのを防ぐには?

フロー全体のタイムアウトは最長で30日間ですが、HTTPアクションのタイムアウトは個別に設定できます。再試行ポリシーの総待機時間がアクションのタイムアウトを超えないように調整してください。また、長時間の再試行を避けるために、手動の再試行カウンタを実装し、一定回数で諦めるロジックを組み込むことを推奨します。

まとめ

Power Automateの再試行ポリシーが想定外に繰り返される原因は、条件分岐での型不一致や変数更新の欠如、アクションタイムアウトとの不一致に集約されます。まずはアクションの出力を正しく比較できているか、再試行ごとに入力値が変化しているかを確認してください。再試行ポリシーの設定を変更する前に、手動の再試行ロジックで制御する方法も検討しましょう。また、管理者と連携してテナント全体の制限値を把握することで、予期しない繰り返しを未然に防ぐことができます。