Power Automateのエラー処理とリトライ設計の知識マップ(知識グラフ)
Power Automateのクラウドフローは、基盤であるAzure Logic Appsの標準リトライポリシーにより一時的な障害の多くを自動的に吸収しますが、データ起因の失敗・権限や認証の切れ・仕様変更にはリトライが効かず、スコープによるTry-Catch-Finallyパターンで捕まえて通知し、Terminateアクションで実行を失敗として記録する必要があります。既定の失敗通知メールは既知の修正方法がある失敗に限られるため当てにできず、失敗の放置はフローの自動無効化や中断につながります。復旧の要となる再送信は処理を最初からやり直すため、処理済みフラグやupsert、トリガー条件による冪等な設計と、必要なら同時実行制御による直列化を組み合わせて、二重実行に強いフローにしておくことが実務上の要点です。
クラウドフロー
Power Automateにおいて、クラウド上で動作しトリガーによって自動実行されるフロー(自動化フロー・スケジュールフロー・インスタントフロー)の総称。
標準リトライポリシー
アクション(またはトリガー)の要求がタイムアウトするか408・429・5xx応答で失敗したときに、指数バックオフ等で自動的に再試行するPower Automateの既定の仕組み。
リトライポリシー
Azure Logic Apps
Power Automateのクラウドフローが基盤とする、Azureのワークフロー自動化サービス。
一時的な障害
接続先の瞬断・メンテナンス、スロットリング(429)、サーバーエラー(5xx)など、標準リトライで解決することが多い失敗の分類。
データ起因の失敗
想定外の空値・形式や参照先に存在しないIDなど、リトライしても直らない失敗の分類。
権限・認証切れによる失敗
接続の期限切れ、パスワード変更、担当者の退職・アカウント無効化など、再認証が必要でリトライでは直らない失敗の分類。
仕様変更起因の失敗
SharePoint列名の変更や接続先APIのバージョン変更など、フローの修正が必要でリトライでは直らない失敗の分類。
スコープによるTry-Catch-Finallyパターン
Tryスコープの失敗を実行条件の構成でCatchスコープに分岐させ、Finallyで後片付けを行う、Power Automateのエラー処理の定石。
実行条件の構成(run after)
各アクション(またはスコープ)が、直前のアクションの成功・失敗・スキップ・タイムアウトのどの状態で実行されるかを設定するPower Automateの機能。
Terminateアクション
フロー実行全体を指定した状態(Failed等)で即座に終了させるPower Automateのアクション。
フローの自動無効化(14日ルール)
トリガーやアクションが失敗し続ける、またはスロットリングされ続けるフローが14日で自動的にオフにされる仕組み。
フローの中断(suspended)状態
DLPポリシー違反や繰り返しの失敗によって、フローが動作を止められる状態。
データ損失防止(DLP)ポリシー
コネクタを業務データ専用・業務データ利用不可・ブロックに分類し、異なる分類のコネクタを同じフロー内で組み合わせられないようにするPower Platformのガバナンス機構。
DLPポリシー
クラウドフローの失敗通知
既知の直し方がある原因と判定された場合に限り実行単位のアラートが所有者・共同所有者へ送られる、Power Automate標準の失敗通知の仕組み。
失敗アラート
フローの実行履歴
クラウドフローの各実行の成否や詳細を確認できる画面で、既定では28日間しか表示されない。
実行履歴
再送信(Resubmit)
実行履歴から失敗した実行を選び、同じトリガーデータでフローを最初から実行し直す操作。
冪等な設計
同じ入力で何度実行しても結果が同じになるよう、処理済みフラグやupsert、トリガー条件などを組み合わせるフローの設計。
upsert(あれば更新、なければ作成)
一意になるキーで既存行を検索し、ヒットすれば更新、なければ作成する分岐にする設計パターン。
トリガー条件(Trigger Conditions)
`@`で始まる式でトリガーの起動条件を絞り込み、条件を満たさないイベントではフローの実行自体を発生させないPower Automateの設定。
トリガー条件(trigger conditions)
自己トリガーによる多重起動
フローが自分自身の書き戻しによって再びトリガーされ、意図せず多重に起動してしまう現象。
フローの自己トリガーによる無限ループ
自己トリガーループ
同時実行制御(concurrency control)
トリガー設定で並列実行数(並列度)を1〜100で指定できる、Power Automateの機能。一度オンにすると元に戻せない。
フロー実行間のダーティリード
台帳の同じ行を複数のフロー実行が同時に読み書きし、古い値を読んで上書きしてしまう不整合。
Power Automateのクラウドフローの基盤はAzure Logic Appsであり、リトライポリシーや実行条件の構成などのエラー処理機構はこの基盤の仕様に従う
クラウドフローのアクションの場合、最初から既定のリトライポリシーが組み込まれている。トリガーの失敗にはこの既定リトライは適用されず、フロー自体が起動しないまま終わる。
標準リトライは、要求がタイムアウトするか408・429・5xx応答で失敗したときに指数バックオフで再試行し、接続先の瞬断やスロットリングなど一時的な障害の多くを自動的に解消する
400や404のようなデータ・設定起因のエラーは何度リトライしても同じ結果になるため、標準リトライを対処として当てにすべきではない
認証エラーや接続切れはリトライでは解決せず、再認証というフロー外の操作が必要になる
SharePoint列名の変更や接続先APIのバージョン変更のような仕様変更起因の失敗は、フローの修正が必要でリトライでは直らない
本記事は、想定外の入力など直らないデータ起因の失敗をスコープによるTry-Catchで捕まえて通知する対処を推奨する
権限・認証切れの失敗もTry-Catchで検知し、通知につなげることが推奨される
スコープによるTry-Catch-Finallyパターンは、各スコープの実行条件の構成(run after)を成功以外の状態に変更することで成り立つ
Catch-Finallyパターンでは、Finallyの後片付けを終えたあとTerminateアクションで実行を状態Failedとして終了させ、失敗を実行履歴に残す
トリガーやアクションが認証切れなどで失敗し続けるフローは14日で自動的にオフにされる
繰り返しの失敗により、フローがDLPポリシー違反時と同様に中断(suspended)状態になっていることがある
DLPポリシーの変更は予告なく即座に適用され、違反したフローを中断(suspended)状態にする
実行単位の失敗アラートは接続切れやスロットリングなど「既知の修正方法がある失敗」の場合に限られ、一般的なデータ起因のアクション失敗では送られないため、検知手段として当てにできない
フローが失敗を放置されて自動無効化に近づいていないかは、実行履歴の定期確認で確認できる
再送信は実行履歴の画面から対象の失敗した実行を開いて選ぶ操作であり、実行履歴を前提とする
再送信はフローを最初から実行し直すため、途中まで成功していた処理も再度実行される。二重に実行されても壊れないよう、冪等な設計を組み込んでおくことが本記事の推奨である
冪等な設計は、無条件の「作成」ではなく一意キーで検索してあれば更新・なければ作成するupsertの形にすることで実現する
冪等な設計は、トリガー条件で自己トリガーなど不要な起動そのものを止めることも含む
トリガー条件は、フローが自分自身の書き戻しで再起動するような多重起動を、実行自体を発生させないことで防ぐ
処理済みフラグやupsertだけでは同時に発生する重複トリガーへの原子的な保護にならないため、並行起動があり得るフローでは同時実行制御で並列度を1にして直列化することを併用する
同時実行制御で並列度を1にして直列化すると、複数の実行が台帳の同じ行を同時に読み書きして起きるダーティリードを防げる