【Power Automate】再試行回数を設定する時の操作手順と制限事項

Power Automateのフローが突然失敗し、再試行回数の制限に引っかかることがあります。この問題は、クラウドフローやデスクトップフローで発生し、特にデータ処理やAPI連携で頻出です。本記事では、再試行回数の設定や制限事項を確認し、つまずいた時の具体的な操作手順を解説します。原因の切り分けから再発防止までを網羅します。

再試行回数の基本と制限事項

Power Automateでは、アクションが失敗した際に自動的に再試行(リトライ)するメカニズムが備わっています。この再試行は、一時的なネットワーク障害やサービス側の負荷など、回復可能なエラーに対して有効です。しかし、再試行回数には上限があり、その制限を超えるとフローは最終的に失敗します。既定では、クラウドフローは最大2回(合計3回の試行)、デスクトップフローは最大4回(合計5回の試行)の再試行が行われます。再試行間隔は指数関数的に増加し、初回は10秒、次は20秒、その次は40秒というように倍増します。ただし、特定のコネクタやアクションではこれらの既定値が異なる場合があり、また管理者がテナントレベルで再試行ポリシーを変更している可能性もあります。

制限事項として、再試行は冪等性が保証されていないアクションに対しては推奨されません。例えば、データベースへの挿入アクションを再試行すると、重複レコードが発生する恐れがあります。また、再試行回数の上限を超えた場合、フローは「失敗」状態となり、トリガー条件によっては再度実行されないことがあります。これらの制限を理解した上で、適切な設定と監視が必要です。

再試行ポリシーの構成要素

再試行ポリシーは主に以下の3つの要素で構成されます。最大再試行回数、再試行間隔の種類(固定または指数関数的)、そして再試行のトリガーとなるエラーコードです。Power Automateの既定では指数関数的な間隔が採用されており、失敗したら即座に再試行するのではなく、時間を置くことでサーバー負荷を軽減します。エラーコードによるフィルタリングは、特定のHTTPステータスコード(例:429 Too Many Requestsや503 Service Unavailable)のみを再試行対象とする設定です。これにより、認証エラー(401)や許可エラー(403)など回復不可能なエラーでは再試行を避けることができます。

フローの種類	既定の最大再試行回数	既定の再試行間隔	変更可能な範囲
クラウドフロー	2回	指数関数的(開始10秒)	0～4回(管理ポリシーによる)
デスクトップフロー	4回	指数関数的(開始10秒)	0～9回(管理ポリシーによる)
子フロー(呼び出し元)	親フローの設定に準じる	親フローの設定に準じる	子フロー側で個別設定不可

この表から分かるように、デスクトップフローはクラウドフローよりも多くの再試行回数が設定されています。これは、デスクトップフローがローカル環境の一時的な問題(例:アプリケーションの応答停止やネットワークの瞬断)に対処するための設計です。しかし、組織の管理ポリシーで上限がさらに制限されている場合がありますので、確認が必要です。

フロー実行履歴でエラーを確認する手順

再試行回数の問題を特定するには、まずフロー実行履歴を確認します。以下の手順でエラーの詳細を取得できます。

1. Power Automateポータル(make.powerautomate.com)にサインインし、左側のナビゲーションから「マイフロー」を選択します。
2. 該当のフローをクリックして詳細ページを開き、「実行」タブを選択します。失敗した実行が一覧に表示されます。
3. 失敗した実行の日時をクリックして、実行詳細を開きます。アクションごとのステータス(成功、失敗、スキップ)が表示されます。
4. 失敗したアクションをクリックすると、下側にエラーメッセージと再試行回数が表示されます。「再試行回数: 3/3」のように記録されています。
5. エラーコードやHTTPステータスコードを確認します。例えば「429 Too Many Requests」であればAPIレート制限、「503 Service Unavailable」であればサービス側の一時的な問題です。
6. さらに詳細な情報が必要な場合は、「生の出力を表示」をクリックしてJSON形式の応答を確認します。これにより、再試行間隔やエラー原因がより明確になります。

この手順により、再試行が行われた回数とその結果を把握できます。再試行回数の上限に達していないのに失敗している場合、別の原因(例:認証切れ、不正なデータ)が考えられます。

アクションごとの再試行ポリシー設定方法

Power Automateでは、アクションごとに再試行ポリシーをカスタマイズできます。ただし、すべてのアクションで設定可能ではなく、主にHTTPアクションやAPI操作用のコネクタで有効です。以下の手順で設定を変更します。

1. フローエディターで変更したいアクションを選択し、右上の「…」(その他)メニューから「設定」を開きます。
2. 「再試行ポリシー」セクションで、「既定値」から「カスタム」に切り替えます。
3. 「再試行回数」には0～4(クラウドフロー)または0～9(デスクトップフロー)の範囲で設定します。ただし、管理ポリシーで上限が制限されている場合は、それ以上に設定できません。
4. 「再試行間隔の種類」は「固定」または「指数関数的」を選択します。固定の場合は秒単位で指定します。
5. 「ステータスコード」には再試行の対象とするHTTPステータスコードをカンマ区切りで入力します。空欄の場合はすべてのエラーコードが対象となります。
6. 設定を保存し、フローを保存してテストします。再試行カウントが想定通り動作するか確認してください。

注意点:カスタム設定の影響

再試行回数を増やしすぎると、フローの実行時間が長くなり、コストやリソースに影響を与える可能性があります。また、再試行間隔を短く設定すると、APIのレート制限に抵触しやすくなります。特にサードパーティのサービス(例:Salesforce、Dropbox)では、短時間の再試行がアカウント停止につながるケースもあります。そのため、カスタム設定を行う前に、対象APIの利用規約や制限を確認し、必要に応じて管理者に相談してください。

設定が反映されない場合の対処

カスタム設定を保存しても、フロー実行時に既定値が適用されることがあります。これは、組織の管理ポリシーがアクション単位の設定をオーバーライドしている場合に発生します。また、子フローやトリガーアクションでは再試行ポリシーが設定できない場合があります。解決策として、管理センターの「フロー設定」でテナント全体の再試行ポリシーを確認するか、PowerShellコマンド「Get-AdminFlowSetting」を使用して現在のポリシーを取得します。管理者権限がない場合は、IT部門に問い合わせてください。

よくある失敗パターンとその対処法

再試行回数に関するトラブルには、いくつかの典型的なパターンがあります。以下に代表的な例を挙げます。

パターン1: 再試行回数上限に達してもエラーが回復しない

この場合、原因は永続的なエラーである可能性が高いです。例えば、認証トークンの有効期限切れや、参照しているデータが削除された場合です。解決策としては、トリガー条件を見直し、フローが不要なタイミングで実行されないようにするか、アクションの前に条件分岐を追加してエラーを事前に検出します。また、再試行間隔を長く設定して、サービス側の回復を待つ時間を増やすことも有効です。

パターン2: 再試行が行われずにすぐに失敗する

再試行ポリシーが「なし」に設定されているか、アクションが再試行をサポートしていない可能性があります。また、エラーコードが再試行対象外(例:400 Bad Request)の場合も再試行されません。確認手順として、アクションの設定で再試行ポリシーが「既定値」または「カスタム」になっているかチェックします。さらに、エラーコードの一覧を取得し、再試行対象に含めるべきコードがあるか検討します。

パターン3: 再試行回数が多いと予想以上に時間がかかる

指数関数的な再試行間隔では、再試行回数が増えるほど待機時間が長くなります。例えば、再試行回数3回の場合、合計の待機時間は10+20+40+80=150秒(2.5分)になります。これを超えるとタイムアウトエラーが発生する可能性があります。対策として、再試行間隔を固定(例:30秒)に変更するか、再試行回数を減らして速やかに失敗させ、後続のエラーハンドリングに任せる方法も検討します。

パターン4: 管理ポリシーで再試行回数が強制されている

テナント全体の設定で再試行回数が固定されている場合、個別のアクションで変更しても無効です。この場合、管理者に依頼してポリシーを緩和してもらうか、フローの設計を見直して再試行に頼らない方法を検討します。例えば、失敗した場合は別のフローで再実行するワークアラウンドを用意します。

再発防止のための見直しポイント

再試行回数でつまずく問題を再発させないためには、以下のポイントを定期的に見直すことをお勧めします。

• アクションの冪等性を確認する: 再試行が安全に実行できるかどうか、データの重複や二重処理が発生しないか事前に評価します。データベースの挿入ではなく更新(Upsert)を利用するなど、冪等性を高める設計を心がけます。
• エラーハンドリングを組み込む: 再試行回数上限に達した場合の処理(例:ログへの書き出し、管理者への通知、代替アクションの実行)をフロー内に追加します。これにより、失敗を検知して迅速に対応できます。
• APIレート制限を監視する: 使用しているコネクタやAPIのレート制限を把握し、再試行間隔がそれに抵触しないように調整します。Power Automateの「コネクタの使用状況」レポートで制限に近づいていないか確認できます。
• テスト環境で動作確認する: 再試行ポリシーを変更したら、必ずテスト環境で実際のエラーをシミュレートして動作を確認します。本番環境での予期せぬ動作を防ぐことができます。
• 管理者とポリシーを共有する: 社内のPower Automate管理者と定期的にポリシー設定を確認し、変更が必要な場合は申請します。特に、再試行回数の上限を変更する場合は、影響範囲を明確に伝えましょう。

管理者に確認すべき項目

再試行回数に関する問題が解決しない場合、管理者に以下の項目を確認してください。これらの情報は、問題の根本原因を特定するために役立ちます。

1. テナント全体の再試行ポリシー設定(最大再試行回数、間隔の種類)
2. 該当フローに対する環境固有の制限(例:プラン別の実行件数制限、コネクタのリクエスト制限)
3. 対象サービス(例:SharePoint、Outlook)側のAPIレート制限やメンテナンス状況
4. フローが使用しているサービスアカウントの権限や認証トークンの有効期限
5. 過去に類似の問題が発生した事例や、推奨される再試行設定値

よくある質問

Q1. 再試行回数を超過したフローは、後で再実行できますか?
A. はい、可能です。フロー実行履歴から手動で再実行できます。ただし、再試行カウントはリセットされず、同じアクションから再開されます。完全に最初から実行したい場合は、トリガーを再送する必要があります。

Q2. 再試行間隔を1秒に設定しても問題ありませんか?
A. 推奨しません。短すぎる間隔はAPIサーバーに負荷をかけ、レート制限によるブロックを招く可能性があります。また、指数関数的な間隔が既定となっている理由は、ネットワークの瞬断に対して効果的だからです。固定間隔にする場合でも、最低30秒程度は確保してください。

Q3. 再試行ポリシーはすべてのアクションで設定できますか?
A. いいえ、設定できるのは主にHTTPアクションや一部のコネクタ(例:SharePointのファイル作成アクションなど)に限られます。トリガーアクションや子フロー呼び出しアクションでは設定できません。詳細は各コネクタのドキュメントを参照してください。

まとめ

Power Automateの再試行回数でつまずく問題は、フロー実行履歴の確認とアクション設定の見直しで大半が解決します。再試行ポリシーのカスタマイズは有効な手段ですが、API制限や冪等性に注意が必要です。管理者との連携を密にし、テナント全体のポリシーを把握しておくことで、トラブルシューティングがスムーズになります。本記事の手順を実践し、安定したフロー運用を目指してください。

🔐

会社アカウント・認証トラブル完全解決データベース 職場または学校アカウント、MFA、Authenticator、VPN、権限、会社ポリシーで止まる問題を横断的に確認できます。