Power Automate の承認フローを運用していると、ある日突然フローがエラーで止まっていた、という経験をした方は多いと思います。原因の大半は30日の壁です。承認者が長期間応答しなかっただけで、フロー全体が強制停止してしまうのです。
この記事では、Power Automate の承認フローに存在する30日タイムアウト制限の仕組みを整理したうえで、運用でカバーする方法からエラーハンドリング、さらには高度なフロー設計まで3段階の対策を解説します。
Power Automate の30日の壁とは何か
Power Automate のアクションには、最大実行時間という制限があります。承認（Approvals）コネクタの承認の開始と待機アクションも例外ではなく、承認者が応答しないまま30日が経過すると、アクションが強制的にタイムアウトしてフローはエラー終了します。
問題は、フローがエラーで終了した後に申請者も承認者も気づきにくい点です。Teamsやメールに通知が飛んでいたとしても、30日間放置されていた場合、申請自体が完全に宙に浮いた状態になります。月をまたぐような役員承認や、長期休暇中の代理対応が必要なケースでは特に起きやすい問題です。
私自身も社内の稟議フローを Power Automate で構築した直後、年末年始をまたいだ申請がそのまま止まってしまい、年明けに発覚するという経験をしました。原因を調べるまでフローが壊れたと思っていたほどです。これは仕様なので、最初から対策を組み込んでおくことが大切です。
対策①：運用でカバーする——催促と周知の徹底
一番シンプルな対策は、30日以内に必ず承認してもらうよう運用ルールを整備することです。技術的な対応を入れる前に、まずここから始めるのをおすすめします。
申請時に期限を明示する
承認依頼の詳細欄に「このフローは30日以内に応答がない場合、自動的にエラー終了します」という一文を入れておくだけで、承認者の意識が変わります。システムの制約を明示することは、運用上の誠実さにもつながります。
詳細欄の文字列を組み立てる方法については、作成（Compose）アクションを使って整形するのが便利です。承認依頼の本文をどう作るかという観点は、承認フロー全体の設計を扱ったPower Automate 承認フロー完全ガイドにまとめているので、合わせて参照してください。
Teamsのフォローアップ機能を活用する
Teams の承認通知には、フォローアップのリマインダー設定ができます。承認者が通知を受け取った後、自分でリマインダーをセットできるため、うっかり忘れを防ぐ補助線として有効です。ただしこれはあくまで承認者側の操作に依存するため、申請者が積極的に声がけすることも併用するのが現実的です。
また、承認フローのトリガー起動から一定日数後（たとえば20日後）に自動でリマインドメールを送る、という仕組みを別フローで作っておくと安心です。スケジュール（繰り返し）トリガーと SharePoint リストの申請日を組み合わせれば、承認待ち一覧を定期的にスキャンして催促することもできます。
対策②：エラーハンドリングで止まっても通知する
タイムアウトが発生したとき、フローが黙って止まるのが一番困ります。せめてタイムアウトしました。再申請してくださいという通知を申請者に送れれば、対応の起点にできます。これを実現するのが、アクションの次の実行条件設定です。
次の実行条件でタイムアウト時の分岐を作る
Power Automate では、各アクションに次の実行条件という設定があります。通常は前のアクションが成功したときだけ実行されますが、ここを失敗した場合やタイムアウトした場合に変更することで、エラー発生後の処理を追加できます。
具体的な手順は以下のとおりです。
- 承認の開始と待機アクションの直後に、メール送信またはTeams通知アクションを追加する
- 追加したアクションの右上の「…」から設定を開く
- 次の実行条件セクションでタイムアウトした場合にチェックを入れる（「成功した場合」のチェックは外す）
- 通知の本文に承認フローが30日間応答なしのためタイムアウトしました。お手数ですが再申請をお願いします、などのメッセージを入れる
この設定をしておくだけで、30日後に自動で再申請依頼の通知が届くようになります。フローが止まっても気づけるだけで、運用の安全性がぐっと上がります。
スコープ（Scope）を使ってエラー処理をまとめる
フロー全体のエラーハンドリングを整理したい場合は、スコープ（Scope）アクションを使う方法が便利です。スコープは複数のアクションをグループ化できるコンテナで、グループ全体が失敗した場合に別処理を走らせるという設計が可能になります。
承認フローの本体をスコープAに入れ、スコープAが失敗したときだけスコープBのエラー通知が動く、という構成にしておくと、フローの見通しがよくなります。スコープを使ったエラー処理の詳しい設計パターンはスコープを使ったエラーハンドリングの実装で解説しているので参考にしてください。
対策③：Do Until ループで30日前に自己完結させる
より根本的な解決策として、フローの設計自体を変えてしまう方法があります。Do Until（実行条件を満たすまで繰り返す）ループと変数を組み合わせて、30日が来る前にフローを一旦正常終了させ、必要なら再トリガーする設計です。
ただしこの方法は実装の難易度が上がるため、まず対策①②を試してから、どうしても解決しない場合の選択肢として考えるのが現実的だと思っています。
Do Until ループの基本的な考え方
通常の承認フローは承認の開始と待機で承認者の応答を待ちますが、この方法では承認の開始と承認の待機を別々のアクションに分割します。承認の開始後、Do Until ループで一定時間ごとに承認状況を確認し、応答があれば後続処理へ、応答がなければリマインド通知を送って再度ループする、という設計です。
Do Until アクションの詳しい使い方についてはDo Until ループで繰り返し処理を実装する方法で解説しています。承認フローに応用する前に、基本的な動作を理解しておくと実装がスムーズです。
変数で経過日数を管理する
Do Until ループの中で変数を使って経過日数をカウントし、たとえば25日を超えたらループを終了してタイムアウト直前の警告通知を送る、という設計が可能です。
変数の初期化で日数カウンターを作り、ループのたびに変数の値を増やすで1日ずつ加算します。Do Until の終了条件として承認済みになっている、またはカウンターが25以上になったを設定するイメージです。
// Do Until の終了条件（式）
@or(equals(variables('ApprovalStatus'), 'Approved'), greaterOrEquals(variables('DayCount'), 25))上記はあくまで考え方を示すコード例です。実際には Power Automate のデザイナー上でアクションを組み合わせて実装します。フローが複雑になるため、デバッグ時はフロー実行履歴を活用して各ステップの状態を確認しながら進めることをおすすめします。
3つの対策を組み合わせるのが現実解
対策①②③をまとめると、以下のような使い分けになります。
| 対策 | 難易度 | 効果 | おすすめのケース |
|---|---|---|---|
| ①運用ルール・催促 | 低 | 中 | まずはここから。全フローに共通して有効 |
| ②次の実行条件＋エラー通知 | 低〜中 | 高 | タイムアウト発生時に気づける最低限の保険 |
| ③Do Until ループ | 高 | 最高 | 月またぎ・役員承認など長期化が確実なフロー |
個人的には、まず全フローに対策②を入れておき、長期化が想定されるフローだけ対策③を追加する、という進め方をおすすめします。対策①はどんなフローでも前提として意識しておきたいところです。
承認フローは一度動いたら終わりではなく、運用しながら改善し続けるものです。タイムアウトのエラーログが出たらそのつど記録し、再発防止の設計を積み重ねていくことが大切です。市民開発とはこういう地道な事柄の積み重ねだと思っています。
