合同会社小村ソフト
相談する
メニュー

Power Automateのエラー処理とリトライ設計 ── 「動いていたフローが止まっていた」を防ぐ

· · Power Automate, エラー処理, クラウドフロー, リトライ, 冪等性, 運用監視, 業務自動化, 技術相談

「毎朝動いていた集計フローが、実は先週から止まっていた」「注文の登録フローが同じデータを2回処理していて、台帳に重複ができていた」。Power Automateでフローを作って運用し始めた会社から、こういう相談をよく受けます。作るのは簡単だったのに、止まったことに誰も気づかなかった、というパターンです。

Power Automateのフローは、正常系だけなら数時間で動きます。ただ、接続先のサービスは一時的に落ちますし、認証は切れますし、想定外のデータは必ず流れてきます。「失敗したときに何が起きるか」を設計していないフローは、失敗を黙って積み重ね、最悪の場合は14日で自動的にオフにされます1。この記事では、フローの失敗の分類から、標準リトライの正確な仕様、スコープを使ったTry-Catch-Finallyパターン、失敗に気づく仕組み、再実行と冪等性まで、本番運用に耐えるエラー処理の設計パターンを整理します。Power Automate全体の使い分けやUI自動化側(デスクトップフロー)のエラー処理は「Power Automateで業務を自動化する ── クラウドフロー・デスクトップフローの使い分けとエラー処理設計」で扱っているので、この記事はクラウドフローの深掘りに絞ります。

1. まず結論

  • 失敗は「一時的な障害」「データ起因」「権限・認証切れ」「仕様変更」の4つに分けて考えます。標準リトライで解決するのは最初の1つだけで、残り3つは検知と修正の仕組みが要ります2。
  • 標準のリトライポリシーは、要求がタイムアウトするか408・429・5xx応答で失敗したときだけ働きます。既定は指数バックオフで、回数はライセンスの層(パフォーマンスプロファイル)により最大2回または12回です31。
  • エラー処理の基本形はスコープ+「実行条件の構成」(run after)によるTry-Catch-Finallyです。実行条件は「成功した場合・失敗した場合・スキップされた場合・タイムアウトした場合」の4状態から選びます34。
  • Catchで失敗を処理したら、最後にTerminateアクションで実行を「失敗」として記録します。これを忘れると実行履歴上は成功に見え、失敗が握りつぶされます43。
  • 既定の失敗通知メールは「既知の修正方法がある失敗」限定・28日クールダウン付きで、頼り切るには穴が多い仕組みです。Catchブロックからの自前通知を必須と考えます5。
  • 実行履歴は既定で28日しか見えません。失敗し続けるフローは14日で自動オフになります。「止まっていたことに1か月後に気づく」は仕様上あり得ます61。
  • 再実行(再送信)と二重起動に備えて、二重に実行しても安全な冪等設計(処理済みフラグ、作成ではなくupsert、トリガー条件)を最初から入れます78。

2. フローはどう失敗するか ── 失敗の4分類

エラー処理の設計は、「どう失敗するか」の分類から始めると整理しやすくなります。Microsoftのガイダンスでも、自動化は必ず失敗し得るものとして、接続先のメンテナンス・APIの変更・パスワードの変更・瞬間的なネットワーク障害などを想定するよう求めています2。実務では次の4分類で考えると、対処がそのまま決まります。

分類 典型例 リトライで直るか 対処の方向
一時的な障害 接続先の瞬断・メンテナンス、スロットリング(429)、サーバーエラー(5xx) 直ることが多い 標準リトライに任せる(3章)
データ起因 想定外の空値・形式、参照先に存在しないID(400/404) 直らない Try-Catchで捕まえて通知(4章)、入力側の検証
権限・認証切れ 接続(コネクション)の期限切れ、パスワード変更、担当者の退職・アカウント無効化 直らない 再認証が必要。検知と通知(5章)、接続の持ち方の設計
仕様変更 SharePoint列名の変更、接続先APIのバージョン変更、フォーム項目の変更 直らない フローの修正が必要。変更管理と通知

このうち実務で一番厄介なのが権限・認証切れです。フローのアクションだけでなく、トリガー自体が失敗するようになるからです。トリガーが4xx系のエラーで失敗する典型例として、接続に使っていたパスワードの変更(期限切れ)が公式トラブルシューティングにも挙げられています。トリガーが失敗すると、フローはそもそも起動しないため実行履歴に「失敗」の行すら残らず、気づくのがさらに遅れます9。接続はそれを作ったユーザー個人に紐づくため、担当者の退職・異動で一斉に切れる事故も起きます。このあたりの組織的な対策は「Power Automateの属人化対策 ── 所有者・接続・引き継ぎの設計」で詳しく扱っています。

もう1つ知っておくべきなのは、失敗を放置するとフロー自体が止められることです。トリガーやアクションが失敗し続けるフローは14日で自動的にオフにされ、スロットリングされ続けるフローも14日でオフになります。90日間トリガーされなかったフローも(プレミアム・容量ライセンスの所有者でなければ)オフにされることがあります1。また、DLPポリシー違反や繰り返しの失敗により、フローが「中断(suspended)」状態になっていることもあります10。「動いていたフローが止まっていた」の何割かは、障害ではなくこの仕様によるものです。

3. 標準のリトライを理解する

Power Automate(基盤はAzure Logic Apps)のアクションには、最初からリトライポリシーが組み込まれています。まずこの仕様を正確に知っておくと、「リトライ設定を足すべきか」「リトライでは解決しないか」の判断ができます。

何が・いつリトライされるか

リトライポリシーが働くのは、アクション(またはトリガー)の要求がタイムアウトしたか、408(要求タイムアウト)・429(要求過多=スロットリング)・5xx(サーバーエラー)の応答で失敗したときです3。既定のポリシーは指数バックオフ(間隔を指数的に延ばしながら再試行)で、Power Automateでの既定の回数と間隔はフローのパフォーマンスプロファイル(実質的にはライセンスの層)によって異なります1。

パフォーマンスプロファイル 主な対応ライセンス 既定のリトライ
Low Microsoft 365プラン、無料プラン等 最大2回。約5分刻みで間隔が延び、最後のリトライは約10分間隔
Medium / High Power Automate Premium、Processライセンス等 最大12回。7秒から指数的に延び、最後のリトライは約1時間間隔

つまり同じフロー定義でも、所有者のライセンスによって「一時障害への粘り強さ」が変わります。プロファイルはリトライ回数だけでなく1日あたりの要求数上限にも効いてくるため、ライセンスの層の考え方は「Power Automateのライセンスと標準/プレミアムコネクタの境界」も参考にしてください。

リトライポリシーはアクションの設定から変更できます。種類は既定・なし・固定間隔・指数間隔の4つで、回数と間隔を明示的に指定できます。設定の上限は回数90回・最小間隔5秒・最大遅延1日です31。Microsoftのコーディングガイドラインでは、一時障害からの回復には固定間隔より指数間隔が推奨されています。短い間隔で叩き続けて相手側の回復を妨げないためです4。

リトライで解決するもの・しないもの

事象 リトライで解決するか
接続先の瞬断・タイムアウト(408/5xx) 解決することが多い。既定のままでよい
スロットリング(429) 間隔が延びれば解決し得る。ただし恒常的な429は設計問題(要求数の削減が必要)
データ不正(400)・存在しないリソース(404) 解決しない。何度やっても同じエラー
認証エラー(401/403)・接続切れ 解決しない。再認証というフロー外の操作が必要
業務的な失敗(承認の却下、在庫不足など) そもそもHTTPエラーではないのでリトライ対象外。フローの分岐で扱う

注意したいのは、リトライも要求数(Power Platform要求)を消費することです。成功・失敗を問わずアクション実行は要求数にカウントされ、リトライやページネーションの要求も同様です1。429に対して回数を増やす方向の調整は、スロットリングをさらに悪化させることがあるため、リトライを厚くする前に「呼び出し回数自体を減らせないか」を先に検討します。

4. Try-Catch-Finallyパターン ── スコープと実行条件の構成

リトライで解決しない失敗は、フローの中で捕まえて処理します。Power Automateにはtry-catch構文はありませんが、スコープ(Scope)と「実行条件の構成」(run after)を組み合わせて同じ構造を作れます。これはMicrosoftのコーディングガイドラインでも推奨されている定石です4。

仕組みの土台になるのが実行条件の構成です。各アクションは完了時に成功(Succeeded)・失敗(Failed)・スキップ(Skipped)・タイムアウト(TimedOut)のいずれかの状態を持ち、後続アクションは既定で「前のアクションが成功した場合」のみ実行されます。この条件をアクションごとに変更でき、「失敗した場合」「タイムアウトした場合」に実行される分岐を作れます3。

これをスコープに適用すると、Try-Catch-Finallyになります。スコープは内包するアクション全体の結果をまとめて1つの状態として持つため、「Tryスコープ内のどこかで失敗したらCatchスコープを実行する」という構成が、アクション単位で条件を設定して回るより圧倒的に保守しやすくなります34。

成功失敗 / タイムアウトはいいいえトリガーTryスコープ本処理をここにまとめるFinallyスコープ実行条件: 成功・失敗・スキップ・タイムアウトすべてCatchスコープ実行条件: 失敗・タイムアウトした場合result関数+アレイのフィルター処理で失敗したアクションと理由を抽出Teams / メールで担当者へ通知フロー名・失敗ステップ・エラー詳細・実行URL後片付け・台帳の状態列を更新Catchを通ったかTerminate状態: Failed で実行を終了正常終了

組み方のポイントは4つです。

  • Catchスコープの実行条件は「失敗した場合」と「タイムアウトした場合」の両方を選ぶ。既定の「成功した場合」は外します。失敗だけ選ぶと、承認待ちや遅延アクションのタイムアウトがすり抜けます3。
  • Catchの中で失敗の中身を取り出す。result('Tryスコープ名')関数はスコープ直下のアクションの結果(状態・入出力・エラー本文)を配列で返すので、「アレイのフィルター処理」で状態がFailedまたはTimedOutのものに絞れば、失敗したアクション名とエラーメッセージを通知に載せられます34。Failedだけで絞ると、タイムアウト経由でCatchに入ったときに抽出結果が空になり、通知から肝心の失敗ステップが抜け落ちます。あわせてworkflow()関数から実行IDを取り出して実行履歴への直リンクURLを組み立てておくと、調査が一気に楽になります4。
  • Finallyスコープの実行条件は4状態すべてを選ぶ。成功でも失敗でも必ず通したい後片付け(一時ファイルの削除、台帳の状態列の更新など)をここに置きます。
  • 失敗した実行は最後にTerminateアクションで「失敗」として終える。ここが一番忘れやすい点です。Catchが正常に完了すると、フロー実行全体としては最後のアクションが成功で終わったことになり、実行履歴上「成功」と記録されます。つまり通知だけして終わると、実行履歴では失敗が見えなくなり、監視や後からの集計から漏れます。Terminateで状態Failedとエラーメッセージを設定して終了すれば、実行履歴にも失敗として残ります43。ただしTerminateをCatchスコープの末尾に直接置いてはいけません。Terminateはその時点で実行全体を即終了させるため、後続のFinallyスコープが実行されず、エラー時にこそ必要な後片付けが飛ばされます。図のように、Catchでは失敗フラグ(変数)を立てて通知までにとどめ、Finallyの後片付けを通過した後でフラグを判定し、失敗時のみTerminateで終了する順序にします。

なお、実行条件の構成は承認フローのタイムアウト分岐(督促・エスカレーション)でも中心になる部品です。具体的な組み方は「Power Automateで承認フローを作る ── 紙とメールの稟議・申請を電子化する」で扱っています。

5. 失敗に気づく仕組み ── 通知と見える化

エラー処理を組んでも、失敗に誰も気づかなければ意味がありません。「気づく仕組み」は既定の通知に頼らず、多層で設計します。

既定の失敗通知メールを正しく理解する

Power Automateは失敗時にメール通知を送る仕組みを持っていますが、仕様を知らずに頼ると穴だらけです。通知は2種類あります5。

  • 実行単位の失敗アラート: 実行が失敗した直後に送られますが、送られるのは接続切れ・スロットリング・既知のコネクタエラーなど「既知の修正方法がある失敗」と判定された場合だけです。一般的なアクション失敗では送られません。宛先は所有者と共同所有者(実行専用ユーザーは含まれない)で、管理者には送られません。さらに、一度送られると同じフローには28日間のクールダウンがあり、その間の失敗では追加のアラートが届きません。実行単位のアラートはすべてのフローで既定で有効になっているわけでもなく、フロー設定での確認が必要です5。
  • 週次の失敗ダイジェスト: 環境をまたいだ失敗のサマリーが週1回送られます。実行単位のアラートが送られない一般的な失敗もこちらには含まれます5。

このほか、特定のエラーについては修復手順つきの「修復のヒント」メールが所有者に送られます(フローごとにオフにも設定可能)7。まとめると、既定の通知は「初回の接続切れには気づけるが、業務データ起因の失敗や2回目以降の失敗はすり抜けやすい」仕組みです。重要なフローでは、4章のCatchブロックからの自前通知を必須と考えてください。

Catchからの通知設計 ── 通知フロー自体が失敗するケース

自前通知にも設計ポイントがあります。

  • 宛先を個人にしない。担当者個人宛てだと、不在・退職で誰にも届かなくなります。共有メールボックスかTeamsチャネルへ送るのが公式ドキュメントでも推奨されています10。
  • 通知の経路を本処理と分ける。ありがちな事故が「Outlook接続が切れてフローが失敗し、失敗通知も同じOutlook接続なので送れない」という共倒れです。認証切れが原因の失敗では、同じ接続を使う通知アクションも同時に失敗します。通知はTeams投稿など本処理と別コネクタ・別接続にする、あるいは通知専用の小さなフローに分けて呼び出すと、共倒れのリスクを下げられます。それでも「通知の通知」は無限には作れないので、最後の砦として次の定期確認を置きます。
  • 通知には調査に必要な情報を全部載せる。フロー名、失敗したアクション名、エラーメッセージ、実行履歴への直リンク。これがないと通知が来ても「何かが失敗した」以上のことが分からず、放置されがちです4。

見える化と定期確認

  • フローチェッカー: 保存前にフロー定義のエラーや警告を検出してくれます。作り込んだ後は一度チェックする習慣にします11。
  • 実行履歴の定期確認: フローの実行履歴は既定で28日しか表示されません6。ソリューションに含めたフローはDataverseに実行履歴のメタデータを残せますが、こちらも既定の保持は28日で、延長は管理者側の設定です12。本番フローについては、失敗だけでなく「キャンセル状態の実行」(同時実行制御が原因のことがある)や「実行数の急減」(トリガーが動いていない兆候)を含めて週1回程度確認する運用が推奨されています10。
  • 管理者の一元監視: 実行単位のアラートメールが送られない失敗も含めて全件を見るには、Power Platform管理センターのMonitor(監視)が最も網羅的です。フロー単位・環境単位で失敗件数とエラー詳細を確認できます5。

定期実行フローの場合は「そもそも起動したか」の監視も必要になります。営業日判定や月末処理を含む定期実行の設計は「Power Automateの定期実行フローと営業日設計」で扱っています。

6. 再実行と冪等性 ── 「二重に実行されても壊れない」を作る

失敗への対処は、検知して終わりではありません。「失敗した分をやり直す」操作と、「やり直しても壊れない」設計がセットで必要です。

再送信(resubmit)の仕様

失敗した実行は、実行履歴から再送信(Resubmit)でやり直せます。同じトリガーデータで実行し直す操作で、一時的な障害(500/502など)ならそのまま再送信、フロー定義の誤りが原因なら修正して保存した後に再送信すれば修正後の定義で再実行されます7。実行履歴の一覧からは一度に最大20件までまとめて再送信でき、大量失敗時の復旧に使えます。手動起動(インスタントトリガー)のフローについては、自分の実行はいつでも再送信できますが、他のユーザーが起動した実行の再送信はテナント設定で管理者が許可する必要があります13。

ここで重要なのは、再送信はフローを最初から実行し直すことです。10ステップ中8ステップ目で失敗した実行を再送信すると、成功していた1〜7ステップ目も再度実行されます。「メール送信は済んでいたのにもう一度送られた」「台帳に同じ行が2行できた」という事故はここから起きます。

冪等性 ── 二重実行しても安全な設計

そこで、同じ入力で何度実行しても結果が同じになる(冪等な)設計を最初から入れておきます。再送信だけでなく、トリガーの重複起動や並行実行に対しても効く、エラー設計の本丸です。

  • 処理済みフラグを持つ。SharePointリストなどの台帳に「状態」列(未処理/処理中/処理済み)を持たせ、フローの先頭で状態を確認して処理済みならそこで終了、処理を終えたら状態を更新します。こうしておけば、再送信しても二重処理になりません。ただしフラグは更新の順序まで決めて初めて機能します。メール送信や基幹システムへの登録のような外部への副作用は、直前に「処理中」へ更新してから実行し、完了してから「処理済み」にします。副作用の後・フラグ更新の前で失敗した実行は「処理中」のまま残り、副作用が済んだかどうか分からない状態です。この行を機械的に再送信すると二重送信になり得るため、「処理中」の行は自動の再実行対象から外し、実際の送信結果・登録結果と突き合わせてから「処理済み」か「未処理」へ人が戻す運用にします。安心して再実行してよいのは「未処理」で止まっている行だけです。
  • 「作成」ではなく「あれば更新、なければ作成」(upsert)にする。一意になるキー(注文番号、申請IDなど)で既存行を検索し、ヒットすれば更新、なければ作成する分岐にします。無条件の「項目の作成」は、再実行のたびに重複行を積み上げます。逆に言うと、一意キーのないデータは冪等にできないので、台帳設計の段階でキー列を決めておくことが前提になります。
  • トリガー条件で不要な起動を止める。「アイテムが作成または変更されたとき」トリガーのフローが自分自身の書き戻しで再起動する、といった多重起動は、後段の条件分岐ではなくトリガー条件(trigger conditions)で止めます。トリガー条件を満たさないイベントでは実行自体が発生しないため、実行回数も要求数も消費しません8。

1つ注意があります。処理済みフラグやupsertのような「確認してから書く」方式は、再送信のような逐次のやり直しには効きますが、単体では原子的な保護ではありません。重複したトリガーイベントがほぼ同時に2つ起動すると、両方の実行が「未処理」を読んでから両方が処理を進める競合が起きえます。並行起動があり得るフローで確実に重複を防ぐには、次項の同時実行制御で並列度を1にして直列化するか、保存先側で一意キー制約を強制できる仕組み(データベースの一意制約など)を使い、重複の作成を書き込み時点で失敗させる設計を併用してください。

同時実行制御(concurrency control)と順序のトレードオフ

二重実行と並んで問題になるのが「同時実行」と「順序」です。既定では、トリガー条件を満たすイベントが同時に多数発生すると、フローは並行して何個でも実行されます1。台帳の同じ行を複数の実行が同時に読み書きすると、古い値を読んで上書きする(ダーティリード)不整合が起きることがあります14。

トリガー設定の同時実行制御(Concurrency Control)をオンにすると、並列実行数(並列度)を1〜100で指定できます。並列度を1にすれば実行は一度に1つになり、順序どおりの処理に近づきます114。ただし、このスイッチには重い注意点があります。

  • 一度オンにすると元に戻せない。オフに戻すにはトリガーを削除して作り直すしかありません1。同時実行制御は不可逆であるため、適用するならアクション数の少ないフロー(必要なら子フローに切り出して)に限定することが推奨されています14。
  • 取りこぼしのリスクが生まれる。同時実行制御がオンのとき、待機できる実行数は「10+並列度」までで、この上限に達している間に到着したトリガーはコネクタ側で再試行されるものの、上限超過が長く続くと実行に至らない可能性があります。すべてのトリガーを確実に実行へつなげたいフローでは、同時実行制御をオフのままにするよう公式ドキュメントが明記しています1。実行履歴がキャンセル状態だらけになっている場合、この設定が原因のことがあります10。

つまり「順序を守る」と「取りこぼさない」はトレードオフです。並列度1の直列化は、流量が少なく順序が重要な処理(台帳の連番採番など)には有効ですが、ピーク時に大量のイベントが来る処理に安易に使うべきではありません。順序と網羅の両方が厳密に必要なら、8章で述べるとおりPower Automateの外で設計すべき領域に入ってきます。

7. 本番投入前の設計チェックリスト

新しいフローを本番に乗せる前に、最低限ここまでを確認します。

# 確認項目 関連章
1 失敗の4分類(一時障害/データ起因/認証切れ/仕様変更)ごとに、このフローで何が起きるか想定したか 2章
2 リトライポリシーは既定のままでよいか。429が出る前提の接続先なら要求数自体を減らせないか 3章
3 本処理はTryスコープにまとまっているか。Catchの実行条件に「失敗」と「タイムアウト」の両方を選んだか 4章
4 Catchの最後にTerminate(状態: Failed)を置いたか。失敗を握りつぶしていないか 4章
5 失敗通知は自前で組んだか。宛先は共有メールボックス/Teamsチャネルか。本処理と別経路か 5章
6 通知にフロー名・失敗アクション・エラー詳細・実行URLが入っているか 5章
7 実行履歴の週次確認(失敗・キャンセル・実行数の急減)を誰がやるか決めたか 5章
8 再送信されても安全か。処理済みフラグまたはupsertで冪等になっているか。一意キーはあるか 6章
9 自己トリガーや多重起動をトリガー条件で止めているか 6章
10 同時実行制御を使う場合、不可逆であることと取りこぼしのリスクを理解した上か 6章
11 接続は誰のものか。共同所有者を設定し、担当者不在でも再認証・修正できるか 2章
12 フローが自動オフ(連続失敗14日等)になった場合に気づける手段はあるか 2・5章

12項目もあるのかと思われるかもしれませんが、半分以上は最初の1回だけ考えれば済む項目です。逆に、これを飛ばして本番に乗せたフローの「後付け」は、動いているものを触る怖さも相まって、たいてい実施されないまま事故を迎えます。

8. どこまでPower Automateでやるか

エラー処理を突き詰めていくと、Power Automateの守備範囲を超える要件が見えてきます。線引きの目安を挙げます。

状況 判断
失敗したら通知して、人が確認して再送信すればよい業務 Power Automateで十分。この記事のパターンで足りる
複数システムを順に更新し、途中で失敗したら更新済みの分を巻き戻す必要がある(補償トランザクション) フローでの作り込みは複雑化しやすい。処理をまとめて受けるAPI側の整備か、受託開発の領域
順序保証・排他制御・取りこぼしゼロが同時に求められる(採番、在庫引当、会計連携など) 同時実行制御のトレードオフ(6章)を踏まえると、キューやデータベースのトランザクションを使える開発領域が安全
失敗時の挙動を含めた自動テスト・変更履歴・レビューが必須 フロー定義の単体テストは難しい。Git管理できるPowerShellや.NETへ
数万件規模のデータを毎回処理し、失敗行だけ再処理したい フローのループは大量データに不向き。バッチ処理の設計が必要

判断の感覚としては、「失敗したときのリカバリー手順を口頭で説明できるうちはPower Automate、図を描かないと説明できなくなったら開発領域」くらいで見ています。とくに補償トランザクション(A社システムには登録済み、B社システムは失敗、さてAを取り消すか?)が要る業務は、フローの見た目以上に複雑で、Terminateと通知では収まりません。タスクスケジューラやPowerShellとの使い分けも含めた判断は「Power AutomateとPowerShell・タスクスケジューラの使い分け」で整理しています。

9. まとめ

「動いていたフローが止まっていた」は、不運ではなくほぼ設計の問題です。フローは必ず失敗します。失敗の4分類のうちリトライが面倒を見てくれるのは一時的な障害だけで、データ起因・認証切れ・仕様変更は、Try-Catchでの捕捉、Terminateでの記録、自前の通知、そして週次の実行履歴確認という多層の仕組みで拾うしかありません。既定の失敗通知メールは条件付き・28日クールダウン付きの限定的な仕組みであり、これに頼った運用は必ずすり抜けを起こします。

そして、失敗への備えの本丸は通知よりも冪等性です。処理済みフラグとupsertで「二重に実行されても壊れない」形にしておけば、再送信もトリガーの重複も怖くなくなり、復旧は「失敗分を選んで再送信」で済むようになります。逆に、補償トランザクションや厳密な順序保証が要る業務は、Power Automateで無理に作り込まず、開発領域へ切り出す判断が長期的には安くつきます。動き始めた日にこそ、このチェックリストを一周してみてください。

関連記事

関連する相談領域

合同会社小村ソフトでは、Power Automateフローのエラー処理・運用設計のレビューから、フローでは収まらない順序保証・トランザクション要件のシステム化まで扱っています。

参考リンク

  1. Microsoft Learn, Limits of automated, scheduled, and instant flows. 既定リトライポリシーがパフォーマンスプロファイル別(Lowは最大2回・約5分刻み、Medium/Highは最大12回・7秒から約1時間まで)であること、リトライ設定の上限(90回・最小間隔5秒・最大遅延1日)、実行期間30日、失敗し続けるフロー/スロットリングされ続けるフローが14日でオフになること、90日間トリガーされないフローがオフになり得ること、同時実行制御が既定オフで並列度1〜100(オン時の既定25)・トリガーを削除して作り直さない限り元に戻せないこと、待機実行数が「10+並列度」で超過トリガーが実行に至らない可能性があること、リトライやページネーションを含む成功・失敗すべてのアクションが要求数にカウントされることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11

  2. Microsoft Learn, Reducing risk and planning for error handling. 自動化は必ず失敗し得るという前提、コネクタ利用時の失敗要因(メンテナンスによる停止、ソフトウェア不具合、APIバージョン変更)、あらゆる自動化に共通する失敗要因(パスワード変更、瞬間的なネットワーク障害)、リトライポリシーの存在について。 ↩ ↩2

  3. Microsoft Learn, Handle workflow errors and exceptions in Azure Logic Apps. リトライポリシーが408・429・5xx応答とタイムアウトを対象とすること、既定が指数間隔のポリシーであること、リトライ種類(既定/なし/固定/指数)、実行条件の構成(run after)の4状態(Succeeded/Failed/Skipped/TimedOut)、スコープの状態評価とrun afterによる例外捕捉、result()関数とアレイのフィルター処理による失敗アクションの抽出、ブランチが失敗で終わらなければ実行全体が失敗にならない状態評価について。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  4. Microsoft Learn, Employ robust error handling. スコープによるTry-Catchパターン、実行条件の構成での失敗分岐、指数リトライの推奨、Terminateアクションで状態Failedを設定して実行を失敗として終了させること、workflow()関数による実行URLの組み立て、エラーのログ記録と通知の推奨について。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  5. Microsoft Learn, Understand flow failure notifications. 実行単位の失敗アラートが「既知の修正方法がある失敗」(接続切れ・スロットリング等)に限られること、宛先が所有者・共同所有者で実行専用ユーザーと管理者には送られないこと、同一フローへの28日クールダウン、実行単位アラートがすべてのフローで既定有効ではないこと、週次失敗ダイジェスト、Power Platform管理センターのMonitorで全失敗を確認できることについて。 ↩ ↩2 ↩3 ↩4 ↩5

  6. Microsoft Learn, Missing runs or triggers history for a flow. フローの実行履歴データが既定で28日間しか保存されず、実行履歴ページに表示されなくなることについて。 ↩ ↩2

  7. Microsoft Learn, Troubleshoot a cloud flow. 修復のヒント(repair tips)メールが所有者に送られフローごとにオフにできること、28日の実行履歴から失敗ステップを特定する手順、500/502のような一時的エラーでの再送信、フロー修正・保存後の再送信で修正後の構成により再実行されることについて。 ↩ ↩2 ↩3

  8. Microsoft Learn, Customize your triggers with conditions. トリガー条件により条件を満たさないイベントでは実行自体が発生しないこと、後段の条件分岐で捨てる方式では実行とAPI要求を消費してしまうことについて。 ↩ ↩2

  9. Microsoft Learn, “There is a problem with the flow’s trigger” error shown in a flow’s run history. トリガー自体が失敗するとフローが実行されないこと、4xx系のトリガー失敗は接続の変更(パスワード期限切れ等)などユーザーが修正すべき問題であり、5xx系は一時的なシステム問題であることについて。 ↩

  10. Microsoft Learn, Fix connection failures in cloud flows. フローの中断(suspended)状態、実行条件の構成を使った失敗通知の並列分岐、重要フローの通知を共有メールボックスやTeamsチャネルへ送る推奨、週次の実行履歴確認(失敗・キャンセル・実行数急減)、キャンセル状態の実行が同時実行設定に起因し得ること、サービスプリンシパル接続がパスワード変更や退職の影響を受けないことについて。 ↩ ↩2 ↩3 ↩4

  11. Microsoft Learn, Tools to test your automation. フローチェッカーによる作成時のエラー検出、修復のヒント、実行条件の構成を使った独自のエラー通知の設定について。 ↩

  12. Microsoft Learn, Manage cloud flow run history in Dataverse. ソリューション対応フローの実行履歴がDataverseのFlowRunテーブルに保存されること、既定の保持期間が28日で管理者が保持期間を変更できることについて。 ↩

  13. Microsoft Learn, Cancel or resubmit flow runs in bulk. 実行履歴から一度に最大20件まで再送信・キャンセルできること、インスタントトリガーで他ユーザーが起動した実行の再送信にはテナント設定(Power Automate flow run resubmission)の有効化が必要なことについて。 ↩

  14. Microsoft Learn, Optimize Power Automate triggers. トリガーが既定で条件を満たす実行を同時に走らせること、ダーティリードによる不整合、同時実行制御が既定でオフであること、並列度1で一度に1実行となり順序が必要な処理に有効なこと、同時実行制御が不可逆でありアクション数の少ないフロー(子フロー)への適用が推奨されることについて。 ↩ ↩2 ↩3

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

Power Automateのフローが失敗したら、自動で通知メールは届きますか？
限定的にしか届きません。実行単位の失敗アラートメールは、接続切れやスロットリングなど「既知の修正方法がある失敗」と判定された場合に所有者・共同所有者へ送られる仕組みで、一般的なアクション失敗では送られません。さらに一度送られると同じフローについては28日間のクールダウンがあり、その間は追加のアラートが届きません。実行単位の失敗アラートはすべてのフローで既定で有効になっているわけでもありません。確実に気づくには、Catchブロックから自前でTeamsやメールに通知する設計を組み込むことをお勧めします。
Power Automateの標準リトライは何回・どんな間隔で行われますか？
アクションの要求がタイムアウトするか、408・429・5xx系の応答で失敗した場合に、既定では指数的に間隔を延ばしながら自動リトライされます。回数はフローのパフォーマンスプロファイル(実質的にはライセンスの層)によって異なり、Microsoft 365ライセンス等の低プロファイルでは最大2回、Power Automate PremiumやProcessライセンス等の中・高プロファイルでは最大12回です。アクションの設定でリトライポリシーを「なし・固定間隔・指数間隔」に変更でき、回数は最大90回まで設定できます。400や404のようなデータ・設定起因のエラーはリトライの対象になりません。
失敗したフロー実行をやり直す(再送信する)にはどうすればよいですか？
実行履歴から失敗した実行を開き、「再送信」を選ぶと同じトリガーデータで実行をやり直せます。フロー定義の誤りが原因の場合は、フローを修正して保存してから再送信すると修正後の内容で再実行されます。実行履歴の一覧からは一度に最大20件までまとめて再送信できます。注意点は、再送信はフローを最初から実行し直すため、途中まで成功していた実行では成功済みの処理がもう一度実行されることです。二重に実行されても結果が壊れない冪等な設計(処理済みフラグ、作成ではなく更新優先の書き込み)にしておく必要があります。
フローが知らないうちに無効化されることはありますか？
あります。トリガーやアクションが失敗し続けるフローは14日で自動的にオフにされます。スロットリング(制限超過)が続くフローも同様に14日でオフになります。また90日間一度もトリガーされなかったフローも、プレミアムライセンスや容量ライセンスの所有でない場合はオフにされることがあります。失敗の放置がフロー停止に直結するため、失敗に気づく仕組みと、実行履歴(既定28日)の定期確認を運用に組み込んでおくことが重要です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る