この記事で分かること：

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