この記事で分かること：
- Power Automate のエラーハンドリング 3 パターンの仕組みと使い分け
- 後付けで入れたときにはまる設定ミスとその確認方法
- エラー通知に含めると有用な情報と
result()関数の使い方
Power Automate のフローにエラーハンドリングを追加した。設定して安心していたら、本番で一度も発火しなかった——こういうことが繰り返し起きる。
後から入れる「Run After」「スコープ」「設定の構成（Configure Run After）」の 3 パターンには、それぞれ微妙な落とし穴がある。フローが動かなかったとき、大抵は設定自体よりも「どのトリガーに対して発火するか」の理解がずれている。
Power Automate のエラーハンドリング概要
大企業環境で Power Automate の設計に関わっていると、エラーハンドリングを「後から入れてほしい」という依頼が多い。既存のフローに後付けで追加する方法は主に 3 つある。
| 手法 | 向いている場面 | 主な制約 |
|---|---|---|
| Run After（実行後） | 特定のアクションに続けてエラー処理を入れる | 接続が 1 対 1 |
| スコープ + Run After | 複数アクションをまとめてエラーハンドリング | スコープが失敗した場合のみ発火 |
| 設定の構成（Configure Run After） | フロー設計を変えずに後付けで追加 | UI が分かりにくく見落としやすい |
3 つとも「既存のフローに後から入れる」ことはできるが、それぞれ動作の前提が違う。
パターン 1：Run After（実行後）の基本と落とし穴
最もシンプルな方法。特定のアクションが「失敗した場合」に続くアクションを追加する。
設定方法：
- 失敗後に実行したいアクション（例：メール送信）を追加する
- そのアクションの「...」メニュー → 「実行後の設定」を開く
- 「成功した場合」のチェックを外し、「失敗した場合」にチェックを入れる
落とし穴：デフォルトは「成功した場合のみ実行」になっているため、チェックを切り替えないと失敗時に無視される。さらに、「失敗した場合」だけを選ぶとタイムアウト・スキップされた場合には発火しない。タイムアウトや Skipped も拾いたい場合は全チェックを入れる必要がある。
実際に多いのは「失敗した場合」だけにチェックを入れているのに、アクションがタイムアウト（TimedOut）で終わっていて通知が来なかったケース。
確認ポイント：
- [ ] 「失敗した場合」がチェック済みか
- [ ] タイムアウト・スキップも拾うか確認したか
- [ ] 「成功した場合」のチェックを外したか（外さないと成功時にも実行される）
パターン 2：スコープ + Run After（複数アクションをまとめる）
複数のアクションに対して 1 つのエラーハンドリングを当てたいとき、スコープを使う。
[スコープ（データ取得と変換）]
└── [SharePoint からリスト取得]
└── [Apply to each]
└── [Compose で変換]
↓ （スコープが「失敗した場合」に実行）
[メール通知：エラーが発生しました]
スコープ内のどれか 1 つが失敗すれば、スコープ全体が Failed になり、続くエラー通知が発火する。
落とし穴：スコープ内のアクションにそれぞれ個別の「失敗した場合」ハンドラを入れると、内側でエラーが処理済みになってしまい、スコープ自体は成功扱いになることがある。内側で拾って「Continue」にしていると外側のスコープエラーが発火しない。
悪い例：スコープ内で個別に拾って続行させる
[スコープ]
└── [HTTPアクション]
↓ （失敗した場合に実行）
└── [変数：エラーフラグを true に設定] ← 「続行」で次に進む
└── [次のアクション] ← スコープとしては成功扱いになる
良い例：スコープ内では拾わず、スコープ外でまとめて処理する
[スコープ]
└── [HTTPアクション] ← エラーハンドラなし
└── [次のアクション]
↓ （スコープが失敗した場合）
[メール通知]
確認ポイント：スコープ内のアクションに個別の「Run After 失敗」ハンドラを入れていないか確認する。入れる場合は「Terminate（終了）」を使い、スコープを意図的に失敗させる設計にする。
パターン 3：設定の構成（Configure Run After）の使い方
既存フローの任意の 2 アクション間に後付けでエラー処理を挟みたいとき、「設定の構成」を使う。これが 3 つの中で最も UI が分かりにくい。
設定方法：
- エラー処理を追加したいアクションの「...」メニューを開く
- 「実行後の設定」（または「Configure run after」）を選ぶ
- このアクションが「実行される条件」を選ぶ（どの前のアクションの、どの状態を受けて実行するか）
落とし穴 1：どのアクションの「後」に実行するかの選択が直感的でない。前のアクションが複数ある場合、どれに対して条件を設定しているかが分かりにくい。
落とし穴 2：並列ブランチの中のアクションに設定すると、ブランチ全体の成否ではなく個別アクションの成否で発火する。並列ブランチ全体が終わってからエラーを拾いたい場合は、ブランチの外に出す必要がある。
落とし穴 3：フローをコピーした場合、「設定の構成」の条件がリセットされることがある。コピー後に必ず確認する。
本番前の確認チェックリスト
エラーハンドリングを追加したら、本番に入れる前に以下を確認する：
1. 意図的にエラーを発生させて動作確認したか
→ テスト環境で「存在しないファイルを参照する」などで失敗させる
2. タイムアウト・スキップも拾うか確認したか
→ Run After の設定で全状態をチェックしたか
3. スコープ内に個別ハンドラを入れていないか
→ 入れる場合は Terminate でスコープを失敗にしているか
4. 通知先（メール・Teams）のアドレスが正しいか
→ 特に「サービスアカウントのメール」は転送設定を確認
5. フローをコピーした場合、Run After の設定がリセットされていないか
この確認をせずに本番投入して、エラーが 2 週間気づかれなかったケースを複数回見てきた。設定自体は 10 分でできるが、動作確認を省くと意味がない。
エラー情報をどう通知に含めるか
エラーが発火したとき、何が起きたかの情報を通知に含めないと、ログを掘りに行くだけで時間がかかる。最低限含めると有用な情報：
- フロー名：@{workflow().name}
- 実行 ID：@{workflow().run.name}
- 失敗したアクション：result() 関数で取得
- タイムスタンプ：@{utcNow()}
- 入力値（個人情報に注意）
result() 関数はスコープや特定のアクションの実行結果（成功・失敗・エラーメッセージ）を返す。スコープと組み合わせると、スコープ内のどのアクションが失敗したかまで追える。
Teams 通知のサンプル本文：
フロー名：@{workflow().name}
実行 ID：@{workflow().run.name}
失敗時刻（UTC）：@{utcNow()}
エラー内容：@{result('問題のアクション名')?[0]?['error']?['message']}
まとめ
| パターン | 使い場面 | 主な落とし穴 |
|---|---|---|
| Run After | 1 アクションの後に直接入れる | タイムアウト・スキップの見落とし |
| スコープ + Run After | 複数アクションをまとめて管理 | 内側でハンドルすると外側が発火しない |
| 設定の構成 | 後付けで既存フローに追加 | コピー時にリセット・並列の扱い |
どの方法を使っても、設定後に意図的にエラーを起こして動作確認するまで「入れた」と言わない——これを守るだけで、気づかないまま続く失敗はかなり減る。
Power Automate のエラーハンドリング、入れてあるのに一度も発火しなかった経験がある方、どのパターンでしたか？
参考：Power Automateシリーズ記事 https://note.com/light_tern636/n/nd807b5f274ee