みなさん、こんにちは!業務ハックLabのようです。
この記事は「Microsoft Power Automate Advent Calendar 2025」の12月2日担当分の記事です。(シリーズ2がオープンになってたけど空いてたので枠取らせてもらいました！)
今回は、Power Automateを使っている皆さんなら一度は経験したことがある、あの恐怖のシナリオについてお話しします。
フローが止まっていても気づかない?恐怖の「サイレント停止」
「自信満々で作ったフローが、実は先週から動いていなかった…」
そんな経験はありませんか?
僕も何度か経験があるんですが、これ、本当に怖いんですよね。(気づいた時の冷や汗がヤバい…)
承認フローが止まっていて誰も承認できない、データ連携が止まっていて情報がズレている、定期レポートが送られていない…
気づいた時には業務が滞り、データの整合性も崩れている。
これが「サイレント停止」の怖さなんです!
Power Automateは便利ですが、標準の設定のままでは、エラーが起きても誰も教えてくれません。
実行履歴を開いて初めて「あ、失敗してる…」と気づくわけです。(これじゃ遅いんですよね)
この記事を読むとどうなるか
この記事(前編)を読めば、以下のことができるようになります!
- エラーが起きた時に、自動的に通知を受け取る仕組みが作れる
- どこでエラーが起きたかを特定しやすくする設計ができる
- プログラミング経験がなくても「Try-Catch(トライ・キャッチ)」という堅牢な設計パターンが実装できる
プログラミング経験がなくても大丈夫です。
Power Automateの標準機能だけで実現できますので、ぜひ最後まで読んでみてください!
【初級編】エラー処理の基本「実行条件の構成」とは?
まずは、Power Automateのエラー処理の基礎となる「実行条件の構成」について解説していきます。
アクションは「成功」した時しか動かない(デフォルトの挙動)
皆さん、Power Automateのフローで、アクションって何も設定しなければ、いつ実行されるかご存知ですか?
答えは、「直前のアクションが成功(Succeeded)した場合のみ」です。
これ、実はとても重要なポイントなんです!
例えば、こんなフローがあったとします:
- SharePointリストからアイテムを取得する
- そのデータをExcelに書き込む
- Teamsに通知を送る
もし、「2. Excelに書き込む」でエラー(Failed)が発生したら、どうなると思いますか?
「3. Teamsに通知を送る」は実行されません!
なぜなら、デフォルトでは「直前のアクションが成功した時だけ」次のアクションが実行されるからです。
(ここ、意外と知らない人が多いんですよね…)
つまり、どこかでエラーになると、それ以降のアクションはすべて無視され、フロー全体が停止してしまうんです。
(これが「サイレント停止」の正体!)
「実行条件の構成」の使い方
では、どうすればエラーが起きた時に通知を送ることができるのか?
ここで登場するのが「実行条件の構成」です!
設定手順
設定方法は簡単です。
- エラー時に実行したいアクション(例:Teams通知やメール送信)の「設定」をタブをクリックする
- 「このあと実行する」で表示されているアクションをクリックする
- 「実行条件の構成」の設定ができるようになる
設定画面には、4つのチェックボックスがあります:
- 成功しました– デフォルトでチェックが入っている
- タイムアウトした – 処理が時間切れになった場合
- スキップ済みである – 条件分岐などでスキップされた場合
- 失敗しました – エラーが発生した場合
デフォルトでは「成功しました」だけにチェックが入っているんですね。
だから、成功した時しか次のアクションが実行されないわけです!
初心者向けの簡易パターン
では、実際にエラー通知を実装してみましょう。
一番シンプルな方法は、こんな感じです:
- 通常のフローを作る(承認フロー、データ登録など)
- フローの最後に「Teams通知」や「メール送信」のアクションを追加する
- その通知アクションの「このあとに実行する」を開き、「実行条件の構成」を以下のように設定する
- 「失敗しました」にチェックを入れる
- 「成功しました」のチェックを外す
- 必要に応じて「タイムアウトした」や「スキップ済みである」にもチェックを入れる
こうすると、どこかでエラーが起きた時だけ、通知アクションが実行されるようになります!
通知の本文には、こんな感じで書いておくと良いでしょう:
【エラー通知】フロー実行に失敗しました
フロー名: 承認依頼フロー
実行日時: (動的コンテンツで「タイムゾーンの変換」を使って日本時間を取得)
詳細は実行履歴を確認してください。
はい、これだけでも十分に実用的なエラー通知が実装できますね!
(初めてこれを知った時は「え、こんな簡単だったの!?」って思いました)
でも、この方法には限界があります。
例えば、フローが複雑になって、アクションが30個、50個と増えていったらどうでしょう?
すべてのアクションの後ろにエラー通知を付けるのは、現実的ではありませんよね…
(メンテナンスも大変だし、フローがごちゃごちゃになる)
そこで登場するのが、次の「スコープ」を使った方法です!
【中級編】「スコープ」を使ったTry-Catchパターンの実装
さあ、ここからが本番です!
プログラミングをやったことがある人なら「Try-Catch」って聞いたことがあるかもしれませんね。
(知らなくても全然大丈夫です!これから丁寧に解説しますので)
なぜ「スコープ (Scope)」が必要なのか?
簡易パターンの限界
先ほどの簡易パターンは、アクションが少ない時は有効です。
でも、実際の業務フローって、もっと複雑ですよね?
- 承認処理
- データの検証
- 外部システムへの連携
- 複数の条件分岐
- ループ処理
こんな感じで、アクションが数十個になることも珍しくありません。
すべてのアクションにエラー処理をつけるのは、とても非効率です。
(コピペだけで1日終わりそう…)
スコープのメリット
そこで使うのが「スコープ(Scope)」アクションです!
スコープは、複数のアクションを「箱」にまとめることができる特殊なアクションです。
スコープを使うと、何が嬉しいか?
- 箱全体の結果判定ができる
- 中のアクションのどれか1つでも失敗すれば、スコープ全体が「失敗」になる
- エラー処理を1箇所にまとめられる
- スコープに対して1回だけエラー処理を設定すればOK
- フローが読みやすくなる
- 関連するアクションがまとまっているので、何をしているかが分かりやすい
これがプログラミングで言う「Try-Catch」の構造になるんです!
(実はPower Automateでも、同じような設計パターンが使えるんですよ!)
3つのスコープで作る最強の枠組み
では、実際にTry-Catchパターンを実装していきましょう。
基本的には、以下の3つのスコープを使います:
- Try スコープ – メイン処理を入れる箱
- Catch スコープ – エラー処理を入れる箱
- Finally スコープ – 必ず実行したい処理を入れる箱(任意)
順番に解説していきますね!
1. Try スコープの作成
まず、「Try」という名前のスコープを作ります。
- フロー編集画面で「+新しいステップ」をクリック
- 「スコープ」で検索して、「スコープ」アクションを選択
- スコープの名前を「Try」に変更する
このTryスコープの中に、実行したいメインの処理をすべて入れます。
例えば:
- SharePointリストからデータを取得
- データの加工・変換
- 承認プロセスの開始
- Excelへの書き込み
- 外部APIの呼び出し
こういった「普段フローでやっていること」を、すべてこのTryスコープの中に入れるわけです。
(既存のフローを改修する場合は、既存のアクションをドラッグ&ドロップでスコープの中に入れればOK!)
2. Catch スコープの作成と設定
次に、エラーが起きた時の処理を入れる「Catch」スコープを作ります。
- Tryスコープの下に、もう1つスコープを追加する
- スコープの名前を「Catch」に変更する
- ここが重要! Catchスコープの「実行条件の構成」を設定する
Catchスコープの「実行条件の構成」では、以下のように設定します:
- 「成功しました」のチェックを外す
- 「失敗しました」にチェックを入れる
- 「タイムアウトした」にチェックを入れる(タイムアウトも考慮)
- 「スキップ済みである」にチェックを入れる(条件分岐でスキップされた場合も考慮)
こうすることで、「Tryスコープが失敗・スキップ・タイムアウトした時だけ」Catchスコープが実行されるようになります!
Catchスコープの中には、エラー時にやりたいことを入れます:
- Teams通知やメール送信
- エラーログをSharePointリストに記録
- 管理者への通知
- エラー情報の取得(これは後編で詳しく解説します!)
シンプルな例だと、こんな感じ:
- Catchスコープの中に「Teams通知」アクションを追加
- 通知内容を設定:
⚠️ エラー発生!
フロー名: (フロー名を記載)
エラーが発生しました。
至急、実行履歴を確認してください。
これで、Tryスコープ内のどこかでエラーが起きると、自動的にTeams通知が飛ぶようになりました!
(もう「気づかずに放置」はありませんね!)
3. Finally スコープの作成(任意)
最後に、「Finally」スコープです。
これは任意なので、必要ない場合はスキップしてもOKです。
Finallyスコープは、成功・失敗に関わらず、必ず実行したい処理を入れる箱です。
例えば:
- 処理の完了ログを記録する
- 変数のリセット
- 一時ファイルの削除
- ステータスの更新
こういった「後片付け」的な処理を入れます。
設定方法は:
- Catchスコープの下に、もう1つスコープを追加する
- スコープの名前を「Finally」に変更する
- Finallyスコープの「実行条件の構成」を設定する
Finallyスコープの「実行条件の構成」では、すべてのチェックボックスにチェックを入れます:
- 「成功しました」にチェック
- 「失敗しました」にチェック
- 「タイムアウトした」にチェック
- 「スキップ済みである」にチェック
こうすることで、Tryが成功しても失敗しても、Catchが実行されても、とにかく必ずFinallyが実行されるようになります!
完成形のイメージ
はい、これで基本的なTry-Catch-Finallyパターンが完成しました!
フロー全体の構造はこんな感じになります:
トリガー(手動実行など)
↓
【Try スコープ】
- アクション1: SharePointからデータ取得
- アクション2: データ加工
- アクション3: 承認開始
- アクション4: Excelに書き込み
↓
【Catch スコープ】← Tryが失敗・スキップ・タイムアウト時のみ実行
- Teams通知
- エラーログ記録
↓
【Finally スコープ】← 常に実行
- 処理完了ログ記録
- 変数リセット
これで、どこでエラーが起きても、確実にCatchスコープが実行されて通知が飛びます!
(これがあるだけで、運用の安心感が全然違うんですよね)
まとめ:まずはシンプルなTry-Catchから始めよう
はい、如何でしたでしょうか?
今回(前編)では、Power Automateのエラーハンドリングの基礎として、以下の内容を解説しました:
- 実行条件の構成の基本
- アクションはデフォルトで「成功時のみ」実行される
- 「実行条件の構成」で「has failed」にチェックを入れればエラー時に実行できる
- スコープを使ったTry-Catchパターン
- 複数のアクションを「Try」スコープにまとめる
- 「Catch」スコープでエラー処理を一元管理
- 「Finally」スコープで必ず実行したい処理を設定
この構造を作っておくだけで、フローの信頼性が大幅に向上します!
次回の後編では、さらに一歩踏み込んで:
- result()関数を使ったエラーの詳細情報の取得
- workflow()関数で実行履歴への直リンクを作成
- エラーメッセージをピンポイントで特定する方法
- 運用で失敗しないための注意点
こういった応用テクニックを解説していきます!
(result()関数とか、知ってるとめちゃくちゃ便利なんですよ!)
まずやってみよう!
まずは、あなたが運用している重要なフローの1つに、今日紹介した「Tryスコープ」と「Catchスコープ」を追加することから始めてみてください。
シンプルなTeams通知だけでも、十分に価値があります!
(エラーに気づけないより、気づけた方が100倍マシですからね)
それでは皆さん、良い業務ハックライフを～
コメント