AIものさし

Power Automateのフローが自動停止したとき、停止理由と再開前の未処理を確認する

Power AutomateのフローがOffやSuspendedになったら、停止理由と未処理入力を確認してから再開し、再停止や未処理データの一括実行を防ぎます。

AIものさし編集部

Power AutomateのフローがOffまたはSuspendedになったときは、状態を戻す前に停止理由と停止中の入力を確認します。Suspendedは、繰り返し失敗・連続したthrottling・trigger activityの長期停止など、条件によってPower Automateが自動停止した可能性があります。停止条件を解消せずに再開すると再停止することがあり、停止中のデータを確認せずに有効化すると、connectorによっては未処理分がまとめて動いたり、逆にイベントを取りこぼしたりします。

この記事では、管理画面の実際の停止理由を最初に見て、再開前にtriggerとsource dataを照合する手順を示します。ここで挙げる日数や挙動はMicrosoftの現行資料に記載された条件です。すべてのflow・license・connectorで同一になるという意味ではありません。特に停止中イベントの扱いは、triggerの種類ごとに確認してください。

目次

最初に状態と停止理由を確定する

Power Automateで対象environmentを選び、対象flowの詳細画面で状態を確認します。Flow名だけで決めず、environment、owner、flow IDも記録します。状態がOffなら、手動で無効化した可能性があります。Suspendedなら自動停止である可能性が高く、Microsoftの案内では、run historyから失敗したactionを調べ、原因を直してから再度Onにします。

  • On：flow自体は有効。run historyに最近のrunがないなら、trigger条件、接続、開始時刻を調べます。

  • Off：誰がいつ停止したか、所有者変更や保守作業の記録を確認します。理由不明のままOnにせず、再開権限を持つ担当者を確定します。

  • Suspended：画面に表示される停止理由、通知メール、run history、Flow checkerの警告を保存し、原因を直すまで再開しません。

  • 状態を確認できない：environmentが正しいか、閲覧権限があるかを先に確認します。別環境の同名flowを誤って再開しないでください。

Microsoftの現行limits資料では、連続してエラーが発生するflowは14日で停止対象になり、trigger activityが90日ないflowは停止される可能性があります。継続的にthrottlingされているflowも14日後に停止対象となります。90日の条件にはPower Automate premium licenseまたはPower Automate Processの容量ライセンスが割り当てられたflowの例外が記載されています。所有者・共同所有者には停止前通知が行われる場合があります。これらの値をすべてのアカウントに当てはまる固定保証として扱わず、対象flowのlicense、容量、通知、最新のlimits表示を確認してください。

停止理由をrun historyと管理情報で照合する

通知メールだけで原因を確定せず、停止直前のrunを開きます。最後に成功したrun、最初に失敗したrun、同じエラーが続いた期間を確認します。失敗actionの名前、status code、エラー分類、connection名、発生時刻を記録し、必要なら接続の再認証や所有者への権限確認を行います。トークン、個人情報、接続のsecretは記録に貼り付けません。

停止理由の手掛かりとして、次を順に確認します。

  1. 繰り返しの失敗：同じactionで失敗しているか、最初の失敗箇所はどこか、connectionが期限切れ・削除・権限変更になっていないか。

  2. DLP policy：組織のData Loss Prevention policyでconnectorの組み合わせが禁止されていないか。Flow checkerや管理者のpolicy情報を確認します。DLPに該当する場合、個人で設定を回避せず、environmentまたはtenant管理者に確認します。

  3. throttling：run historyの429やconnector固有のrate limitを確認します。429が出たことだけでflow全体の停止理由を断定せず、連続性・発生期間・対象connectorを照合します。

  4. trigger activity / inactivity：最後にtriggerが起きた時刻とflowの条件を見ます。「使われていない」という表示だけでは、設計上の待機flowか不要flowかまでは判断できません。

  5. license / capacity：flowの種類、owner、割り当てられたlicenseまたはProcess capacity、request limitを管理者と確認します。支払い方法を変えれば全種類のconnector制限が解消する、とは限りません。

原因が接続・権限・DLP・license・throttlingのどれか不明な場合は、変更をまとめて試さないでください。一つの仮説に対して一つの変更だけを行い、次のrunで結果を比較します。

再開前に停止中のデータを確認する

Flowを再びOnにする前に、停止期間を決めます。最後に処理が成功した時刻から再開予定時刻まで、元データ側に何件の対象イベントやレコードが作られたかを数えます。可能なら一意なID、作成時刻、処理済みマークを一覧化し、重複を防ぐ照合表を作ります。

Triggerの種類によって未処理分の挙動は異なります。

  • Polling trigger：Microsoftのtrigger最適化資料では、flowをOffにするとpollingが止まり、再度Onにすると前回のpoll以降の新しいeventを取得する動作が説明されています。停止中にeventが多く発生していれば、再開時にまとめて処理され、遅延や性能影響が起きる可能性があります。対象connectorで同じ挙動になるか、現在の公式資料とtriggerの設定を確認します。

  • Webhook trigger：Offの間は新しい通知を受けず、Onに戻した後はその時点以降のeventを処理する動作が説明されています。停止中のeventは自動処理されない可能性があるため、元サービスの履歴や一覧から未処理分を照合します。

  • 種類が分からない：トリガー名とconnectorの公式資料を確認するまで、欠落なし・自動再送ありとは判断しません。

この違いは重要です。Polling型なら滞留eventの一括処理が重複や大量実行を生む可能性があり、Webhook型なら停止期間中のeventを別手順で回収する必要があるかもしれません。どちらも「再開すれば停止中のデータが必ず安全に処理される」と一般化できません。元データのIDとflow側の処理結果を照合してから進めます。

停止中入力の照合表

表は横にスクロールできます

確認項目記録する内容再開判断
停止期間最後の成功時刻〜再開予定時刻対象となるsource dataの検索範囲
Trigger型Polling / Webhook / recurrence / 不明公式の停止中挙動を確認
入力件数停止期間中に追加された対象IDの数再開時に処理されそうな量
処理済み成功run・source側の処理済みフラグ二重処理の除外条件
欠落候補sourceにはあるがrun/結果がないID再処理または手動照合の対象
副作用メール送信、請求、削除、更新等重複時の影響と承認が必要か

元データに処理済み記録がなく、同じ入力を再送すると二重メール送信や二重登録が起こる場合は、再開前にidempotency keyや重複判定を設計します。具体的な手段はconnectorと業務データに依存するため、未確認のflowへ「再送すれば安全」とは言えません。手動再処理が必要なら、対象IDを限定し、試験対象を少数にして結果を照合します。

再開を止める条件と進める条件

次のいずれかが残る場合は、flowを再開せず、所有者または管理者へ渡します。

  • 停止理由が不明、または同じエラーが解消されていない。

  • DLPや権限ポリシーに抵触し、変更権限がない。

  • 停止中の入力範囲や処理済みIDを確認できず、重複・欠落の影響が大きい。

  • 再開で送信、削除、金銭処理などの不可逆な副作用が起きる。

  • 対象environmentやflow ownerが特定できない。

再開条件を満たしたら、停止理由に対応する修正が保存されたことを確認し、停止中データの再処理方式を決め、担当者と監視時間を確保します。最初から全量を流すのではなく、可能であれば影響の小さい入力で限定確認し、そのrunの結果とsource側の状態を照合します。問題がなければ通常運用へ戻し、最初の数runで失敗・重複・滞留がないかを確認します。

実務で使う再開チェックリスト

再開前

  • 正しいenvironment、flow ID、ownerを確認した。

  • OffとSuspendedを区別し、停止理由・通知・run historyを保存した。

  • 失敗の最初のactionと原因候補を確認した。

  • DLP、connection、license、throttlingの該当条件を必要な担当と確認した。

  • 停止期間中のsource dataと一意IDを確認した。

  • TriggerがPollingかWebhookかを確認し、停止中eventの扱いを公式資料で確認した。

  • 重複処理や副作用が起きる範囲を特定し、必要なら再処理対象を限定した。

  • 再開担当者、監視時間、失敗時の停止方法を決めた。

再開後

  • 最初のrunが成功したかだけでなく、処理対象IDが想定どおりかをsourceと照合した。

  • 停止中の対象が漏れていないか、重複していないかを確認した。

  • 再びSuspendedにならず、同じエラーやthrottlingが続いていないかを確認した。

  • 結果、確認時刻、未処理ID、次の担当を記録した。

結論

Power Automateのflowを自動停止から再開するときは、状態をOnへ戻す前に、停止理由と停止期間中の入力を別々に確認します。連続エラー、90日間のtrigger inactivity、14日間の継続throttlingは現行の公式limits資料に示される条件ですが、licenseやflow環境による例外があります。再処理の挙動もPollingとWebhookで異なるため、connectorを特定して確認します。

停止理由を直せても、未処理データの重複・欠落が判定できないなら、再開はまだ安全とは言えません。まず対象IDと副作用を確認し、回収方法を決めてから限定再開します。

公式Sources

Checked: 2026-10-15

Editorial Note: Microsoft公式資料を確認した一般的な運用ガイド。特定tenant・connector・flowの停止理由や再開後の実動作は検証していない。