Power Automate Desktop（PAD）でフローを作り始めると、かなり高確率で遭遇するのがこれです。
「フローが途中で止まった…」
特に実務では、
- Excelが開かない
- Webページが落ちる
- Outlookが反応しない
- シートが存在しない
など、エラーは必ず発生します。
そして初心者が最初にやりがちなのが、
エラーでフローが完全停止
です。
でも実務では、
- エラー内容を記録
- Teamsやメール通知
- 次処理へ継続
- 自動リトライ
まで設計します。
この記事では初心者向けに、
- エラーハンドリングとは？
- Business Exception / System Exception
- Action Level Error Handling
- Block Level Error Handling
- Retry設定
- Logging
- Monitoring
まで、実務イメージ付きでわかりやすく解説します。
エラーハンドリングとは？
簡単にいうと、
「エラーが起きても安全に処理する仕組み」
です。
例えば、
- Excelシートが存在しない
- APIがタイムアウト
- ブラウザが開かない
時に、
どう動くか
を決めます。
実務では超重要
実際のRPAでは、
「エラーが起きない」
より、
「エラー時にどう動くか」
の方が重要です。
Power Automate Desktopの例外は2種類
講義でも最初に説明されています。
① Business Exception
業務ルール側の問題。
例
- 金額が空白
- 年齢18歳未満
- 必須項目未入力
など。
特徴
リトライしても意味がない
例えば金額空白は、
何回やっても空白です。
② System Exception
システム側問題。
例
- ブラウザ起動失敗
- Outlook応答なし
- APIタイムアウト
など。
特徴
リトライすると直る場合がある
例えば、
- 再起動
- 再読込
- 再接続
で復旧するケースがあります。
実務ではRetry設定が超重要
一般的には、
3回程度リトライ
が多いです。
Power Automate Desktopのエラーハンドリングは2種類
① Action Level Error Handling
② Block Level Error Handling
まずAction Levelから理解しよう
Action Level Error Handlingとは？
名前の通り、
「1つのアクション単位」
でエラー制御します。
どこにある？
各アクションの
「On Error」
です。
初心者は意外と見落とします。
今回の例
講義ではExcel例を使っています。
処理内容
STEP1
Excel起動
STEP2
存在しないシートを指定
STEP3
エラー発生
わざと失敗させる
「dummy sheet」
という存在しないシートを指定。
すると？
「シートが見つからない」
エラーになります。
ここでOn Errorを使う
アクション右側の
On Error
をクリック。
設定できること
Retry Policy
リトライ回数設定。
Retry Interval
何秒後に再実行するか。
Continue Flow Run
エラー後も継続。
Throw Error
エラー停止。
実務でよく使う構成
エラー発生
↓
Teams通知
↓
ログ記録
↓
次処理継続
Subflowも実行できる
これかなり便利です。
エラー時に、
- メール送信
- Teams通知
- ログ保存
用Subflowを呼び出せます。
Get Last Error が超重要
これは実務でかなり使います。
「最後のエラー情報取得」
です。
取得できるもの
- Action Name
- Error Message
- Subflow Name
- Line Number
など。
実際かなり便利
例えばメール通知で、
件名
PADエラー通知
本文
- Action Name
- Error内容
- 発生箇所
まで送れます。
次はBlock Level Error Handling
Block Level Error Handlingとは？
複数アクションまとめて制御します。
イメージ
この範囲全部監視
みたいな感じ。
使い方
「On Block Error」
アクションを追加。
Blockの中に処理を書く
例えば、
- Excel起動
- 読み込み
- 更新
- 保存
全部まとめる。
エラー時の動作
Go to End of Block
ブロック終了へジャンプ。
Go to Beginning
再実行。
実務ではどっち使う？
Action Level向き
- 個別処理
- 細かい制御
- Excelシート判定
Block Level向き
- 一連処理
- 大きな業務単位
- Web操作まとめ
「Capture Unexpected Logic Errors」が超重要
これ初心者が見落としやすいです。
例えば
- 0除算
- 配列範囲外
- インデックスエラー
など。
チェックONで捕捉可能
かなり重要です。
Logging（ログ出力）
エラーハンドリングとセットです。
Log Messageアクション
PAD標準ログ機能。
記録できるもの
- Info
- Warning
- Error
など。
実務ではこう使う
成功時
「正常終了」
失敗時
「Division by Zero」
Monitoring（監視）
Power Automate Portalで確認できます。
見れるもの
- 実行履歴
- 実行時間
- エラー率
- 失敗箇所
実務では超重要
保守担当がここを見ます。
初心者におすすめ構成
最初はこれだけでOK。
① Action Level
↓
② Get Last Error
↓
③ Log Message
↓
④ Teams通知
これだけでかなり実務っぽくなる
よくある失敗
① Throw Errorだけ
結局止まる。
② Retry無限
システム負荷。
③ エラー情報未保存
原因不明になる。
実際に使って感じたこと
PADは、
「正常系」
より、
「異常系設計」
が本当に重要です。
特に業務自動化では、
- 通知
- ログ
- 継続処理
まで作るとかなり実務レベルになります。
よくある質問（FAQ）
Q. Action LevelとBlock Levelはどっち使う？
両方使います。
- 個別 → Action
- 大きな処理 → Block
が基本。
Q. Retry回数おすすめは？
3回前後が一般的。
Q. Get Last Errorは必須？
かなりおすすめです。
障害解析が楽になります。
Q. ログはどこで確認する？
Power Automate Portalの
Desktop Flow Runs
から確認できます。
