Power Automateのエラーハンドリングはスコープ（Scope）＋実行条件で解決

Power Automateのエラーハンドリングは、スコープ（Scope）アクションと実行条件を組み合わせることで実現できます。エラーが出たときに何もせず止まるフローより、原因をキャッチして通知まで飛ばせるフローのほうが実運用ではずっと使いやすいです。

スコープ（Scope）アクションとは

Scopeアクション（スコープ）は、複数のアクションをひとつのグループにまとめるコンテナです。フォルダのようなものです。グループ内のいずれかのアクションが失敗すると、スコープ（Scope）自体も失敗扱いになります。この仕組みを使うと、このスコープが失敗したら別の処理を動かすという条件分岐が書けます。

スコープを使わずに個々のアクションに実行条件を設定することもできますが、アクションが増えると管理が煩雑になります。スコープでグループ化してからエラー時の処理を設定するほうが、フロー全体が見やすくなります。

RunAfter（実行条件）の設定

Power Automateの各アクションには実行条件（RunAfter）を設定できます。デフォルトは成功した場合に実行ですが、これを変更することでエラーハンドリングが可能になります。

複数の条件を同時に選択することもできます。たとえば「失敗した場合」と「タイムアウトした場合」の両方にチェックを入れると、どちらの状態でも次のアクションが実行されます。

基本的なエラーハンドリングの構成

実務でよく使う構成を紹介します。

1. メイン処理をスコープでまとめる（スコープ: メイン処理）
2. エラー時の処理をスコープでまとめる（スコープ: エラー処理）
3. エラー処理スコープの実行条件を「失敗した場合」に設定する
4. エラー処理スコープ内にTeams通知やメール送信アクションを入れる

この構成だと、メイン処理のスコープが失敗したときだけエラー処理が走ります。Teams通知の本文にエラーメッセージを含めることで、何が原因で失敗したかをその場で把握できます。

エラーメッセージの取り出し方

エラー処理のスコープ内でエラーの詳細を取得するには、以下の式を使います。

result('スコープ名')

この式でスコープの実行結果（エラーコードやメッセージを含むオブジェクト）が取得できます。作成（Compose）アクションと組み合わせて内容を確認してから、通知文に組み込むと使いやすいです。

よくあるパターン：エラー時に管理者へTeams通知

個人的には、本番運用しているフローには必ずこのパターンを入れるようにしています。フローが失敗しても気づかずに放置してしまうリスクを防げます。

構成はシンプルで、メイン処理のスコープ失敗時にTeamsのアダプティブカードを管理者チャネルに投稿するだけです。本文にはフロー名・実行日時・エラーメッセージを入れておくと、原因特定がかなり速くなります。実行履歴の見方についてはデバッグのコツも合わせて参考にしてください。

スコープを使うときの注意点

スコープのネストに注意

スコープ内にスコープを入れることもできますが、深くなると可読性が下がります。2階層までを目安にすることをおすすめします。

スキップ状態の伝播

条件分岐でスキップされたアクションが含まれるスコープは、スコープ全体もスキップ扱いになることがあります。RunAfterの条件にスキップも含める必要があるケースがあるので注意してください。

変数はスコープの外で初期化する

変数の初期化はスコープの外に置く必要があります。スコープ内に入れるとエラーになります。これは初心者がよく詰まる点なので、変数を使う場合はフローの冒頭で初期化してからスコープを作るようにしましょう。詳しい変数の使い方は変数命名規則の記事でも触れています。

まとめ

スコープ＋実行条件の組み合わせは、Power Automateのエラーハンドリングにおける基本中の基本です。最初は少し難しく感じますが、一度構成を作ってしまえばコピーして使い回せます。本番フローにはエラー時の通知を必ず入れる習慣をつけると、運用の安心感が大きく変わります。