【実録#06】PADのエラー処理・リトライ設計|止まるフローを自動復旧させて手動対応を月4時間→20分に

2026年7月16日 16:25

夜中にPower Automate Desktop(PAD)のフローがエラーで止まって、朝イチで原因調査と再実行…というのを週2〜3回やっていました。エラー処理とリトライをちゃんと設計し直したら、フローの9割が勝手に復旧するようになり、手動対応は月4時間→20分くらいまで減りました。

この記事でわかること

PADの「エラー発生時」設定でできること(再試行ポリシー・続行・ラベル)
try-catchっぽく使える「ブロックエラー発生時」の使い方
リトライ設計でハマった点3つ(症状→原因→解決)

1. 困りごと:週2〜3回、フローが夜中に止まる

このシリーズで作ってきた締切監視やExcel読み取りのフロー、平日は毎朝タスクスケジューラで自動実行しています(前回の記事参照)。ただ、動かし始めて2週間くらいで気づいたのが「けっこうな頻度で途中で死んでる」こと。

原因はだいたいこの3つでした。

Webページの読み込みが遅くて、クリック対象のUI要素が見つからない
共有フォルダのExcelを誰かが開いていて、読み取りに失敗する
ネットワークが一瞬切れる

どれも「もう1回やれば普通に通る」系のエラーです。なのに1回失敗しただけでフロー全体が止まる。止まると、朝出社してからログを見て、原因を確認して、手動で再実行。1回あたり20分くらい、週2〜3回なので月に4時間くらい溶けていました。もう1回やれば通るものに、です。

2. 構成:PADのエラー処理は「アクション単位」と「ブロック単位」の2段構え

PADにはエラー処理の仕組みが大きく2つあります。

アクション単位の「エラー発生時」設定
複数アクションをまとめて囲む「ブロックエラー発生時」

アクション単位:再試行ポリシー

各アクションの編集ダイアログを開くと、左下に「エラー発生時」というリンクがあります。ここで設定できるのが、

再試行ポリシー:「なし」を「固定」に変えると、回数と間隔(秒)を指定できる
フロー実行を続行する:エラーでも止めずに先へ進める(次のアクションへ移動、ラベルへ移動など)
新しいルール:エラー時に「変数の設定」や「サブフローの実行」を差し込める

一時的なエラーで落ちやすいアクション(クリック、Excelを開く、ファイルコピーなど)には「固定・3回・間隔10秒」を基本にしました。

ブロック単位:try-catchっぽく囲む

「フローコントロール」グループにある「ブロックエラー発生時」を置くと、そこから「終了」までの間で起きたエラーをまとめて拾えます。私は処理のかたまりごとにこれで囲んで、エラー時は通知用サブフローを実行 → 後続へ進む、という形にしています。

エラー時に呼ぶサブフロー(Notify_Error)では、前々回に書いたBurntToastのトースト通知と、ログファイルへの書き込みをやっています。つまり全体はこんな流れです。

アクション単位:一時的エラーは再試行ポリシーで自動リトライ(3回×10秒)
ブロック単位:リトライしても駄目なら「ブロックエラー発生時」で拾う
拾ったら:通知サブフローでトースト+ログ → 影響のない処理は続行、駄目なら安全に終了

3. ハマった点

PAD 再試行しても一瞬で全部失敗する

症状:クリックアクションに再試行3回を設定したのに、3回とも即失敗して合計数秒で落ちる。

原因:再試行は「同じアクションをもう一度やる」だけで、ページの読み込みを待ってくれるわけではないから。要素がまだ表示されていない状態で3連打しても、全部同じ理由で失敗します。

解決:2段構えにしました。まずクリックの前に「Webページのコンテンツを待機」(デスクトップアプリなら「ウィンドウのUI要素を待機」)を置いて、要素が出るまで待つ。そのうえで再試行の間隔を10秒にして、待ち時間としても機能させる。これで「読み込みが遅いだけ」のエラーはほぼ消えました。

PAD フロー実行を続行するで失敗に気づかない

症状:エラーは出なくなったのに、ある日Excelの中身が空っぽのまま後続処理が走っていた。

原因:「フロー実行を続行する」は便利ですが、エラーを握りつぶす設定でもあります。読み取りに失敗しても知らん顔で先へ進むので、失敗したことに誰も気づけない。

解決:続行させる場合は、エラー時の「新しいルール」→「変数の設定」でフラグ変数(ErrorFlagなど)をtrueにして、ブロックの最後にIfで判定。フラグが立っていたら通知して、後続のメール送信などはスキップするようにしました。「続行するなら必ず痕跡を残す」がルールです。

PAD リトライの積み上げでフローが終わらない

症状:リトライを入れまくったら、エラーの日はフローが30分以上走りっぱなしに。タスクスケジューラ側のタイムアウトにも引っかかりそうになった。

原因:「5回×30秒待ち」みたいな設定をあちこちに入れると、直列で積み上がって最悪ケースの実行時間が爆発するから。リトライで直らないエラー(パスワード切れ、ファイルが存在しない等)は、何回やっても直りません。

解決:リトライは「一時的エラーが起きうるアクションだけ」に絞って、上限は3回×10秒に統一。それで駄目なものは粘らず、すぐ通知して安全に終わらせる方針にしました。「粘るのは機械、判断するのは人」で割り切ると設計がシンプルになります。

4. 動いた結果

フローが止まる頻度:週2〜3回 → 月1回程度(9割は自動リトライで復旧)
手動リカバリー作業:月4時間くらい → 月20分くらい
失敗に「気づかない」事故:フラグ+通知にしてからゼロ

なにより「朝、フローが死んでないか確認する」という地味なストレスがなくなったのが大きいです。エラー処理は機能が増えるわけじゃないので後回しにしがちですが、自動化を"放置できる"ようにする仕上げの工程だと思います。

おわりに

この考え方は、PowerShellスクリプト側でも同じように使えます(try-catchとリトライループで組めます)。次回は、その運用を支える「自動化スクリプトのログ設計」の話。Transcriptで実行記録を丸ごと残す方法を書く予定です。

読んでもらえるだけで嬉しいですが、スキを押してもらえると次を書く燃料になります!