Power Automateの承認フローが止まる原因10選

Power Automateで承認フローを本番運用し始めると、「申請したのに承認依頼が届かない」「承認したのに後続の処理が動かない」「気づいたらフローがオフになっていた」といった相談が情シスに集まり始めます。厄介なのは、原因がフローの作り方だけでなく、接続・ライセンス・組織変更・承認者の不在など複数のレイヤーにまたがることです。本記事では、まず実行履歴を使った切り分け手順を示したうえで、実務でよく遭遇する10の原因と対処法、そして同じ停滞を繰り返さないための設計のポイントを整理します。

この記事の要点

• 原因を当てにいく前に「フローは実行されたか → 承認アクションまで到達したか → 承認者に届いたか → 承認後の処理が動いたか」の順で切り分けると、確認箇所を絞り込める。
• 承認フローが止まる原因は10種類に整理でき、そのうち原因1〜4は設計段階で予防できる。
• 止まったときはまずフローの実行履歴を確認し、承認アクションが成功しているかを見る。
• 切り分けと設計で停滞は確実に減らせるが、それでも残る「運用の重さ」は別途扱う必要がある。

まず何を確認すればいい？「どこで止まったか」の切り分け

原因を当てにいく前に、どこまで進んで、どこで止まったかを特定してください。これだけで疑うべき原因は大きく絞り込めます。

1. そもそもフローが実行されたか：フローの実行履歴に行が増えているかを見ます。増えていなければトリガー側の問題です。
2. 承認アクションまで到達したか：実行履歴を開き、失敗している赤いアクションを特定します。承認の作成で失敗しているなら、承認者の指定や環境設定の問題です。
3. 承認者に届き、操作できる状態か：Teamsの承認アプリで、該当の依頼が承認者の「未対応」に出ているかを確認します。
4. 承認後の処理が動いたか：承認済みなのに後続が動かない場合は、条件分岐の判定を疑います。

フローエディタでの基本的な組み立て方（トリガー、「承認の開始と待機」、条件分岐）はMicrosoft 365で承認ワークフローを設定する方法【画面付き】で画面キャプチャつきに解説しています。

承認フローはなぜ止まるのか？原因10選と対処法

原因1：承認者が長期間応答せず、実行時間の上限に達した

最も多いのがこれです。Power Automateのフロー実行には時間の上限があり（既定で30日）、承認者が放置したまま上限に達すると、フローはエラーで終了します。申請者から見ると「申請が消えた」ように見えるため、再申請が発生し、二重申請の原因にもなります。

対処：発生してしまった分は再申請で回収するしかありません。恒久対策は、承認アクションにタイムアウトを設定し、期限前にリマインドを送る構成へ変更することです（後述の「設計で止まらなくする」を参照）。

原因2：承認カードが期限切れになり、ボタンが反応しない

Teamsやメールに届いた承認カードは、一定期間を過ぎるとフロー側から更新できなくなります。承認者が古い通知を掘り起こしてボタンを押しても反応しない、というのはこのパターンです。

対処：承認操作は通知カードからではなく、Teamsの承認アプリ（Approvals）の一覧から行うよう周知します。あわせて、リマインドで新しい通知を送り直す仕組みを入れておきます。

原因3：承認者の指定が誤っている

承認者はユーザーのメールアドレス（UPN）で指定します。表示名や、配布リスト・メーリングリストのアドレスを入れていると、承認の作成時点でエラーになります。複数人を指定する場合は、区切り文字の形式にも注意が必要です。

対処：承認者はフロー内に直書きせず、SharePointの承認者マスタから取得する構成にします。マスタ側に入るのがメールアドレスに限定されるため、指定ミス自体が起きにくくなります。

原因4：承認者のアカウントが無効・退職・ゲストユーザー

退職者や異動でアカウントが無効化された人が承認者に指定されていると、承認は作成できても誰も操作できません。外部のゲストユーザーを承認者にしている場合も、環境やライセンスの条件によって承認アプリを開けないことがあります。

対処：承認者マスタの棚卸しを定例化し、「承認者に退職者が残っていないか」を月次で確認します。進行中の案件は、代理者に引き継ぐか、いったん却下して再申請する運用を決めておきます。

原因5：接続（コネクション）が切れている

接続トークンの期限切れ、パスワード変更、多要素認証や条件付きアクセスポリシーの変更、DLPポリシーによるブロックなどで、フローが使う接続が無効になることがあります。この場合、トリガーそのものが動かなくなります。

対処：フローの詳細画面で接続の状態を確認し、再認証します。フローの所有者を個人アカウントのままにしない（共同所有者を設定する、サービスアカウントで運用する）ことが、退職・異動時の停止を防ぐ現実的な対策です。

原因6：フローが自動的にオフになっている

Power Automateは、連続してエラーが発生したフローを自動的に中断することがあります。また、長期間実行されていないフローは、所有者への通知を経て無効化される場合があります。「先週まで動いていたのに、今週から誰も気づかないまま止まっていた」というケースの多くがこれです。

対処：オンに戻す前に、実行履歴で根本原因を潰します。運用面では、業務に必須のフローを一覧化し、停止時に気づける仕組み（管理者への通知フローや定期点検）を用意しておきます。

原因7：トリガーが発火していない

履歴に何も残っていない場合は、トリガー側を疑います。よくあるのは次のパターンです。

• トリガー条件を設定していて、条件に合致していない
• SharePointの「アイテムが作成または変更されたとき」で、フロー自身の更新が新たな実行を生むループを避けるために条件を入れた結果、意図した更新でも発火しなくなっている
• 自動トリガーのポーリング間隔の分だけ遅延している（即時に動くとは限らない）
• 一度に大量のアイテムが作成され、処理が順番待ちになっている

対処：トリガー条件を一時的に外して発火するかを確認すると、切り分けが早く進みます。

原因8：環境側の前提（Dataverse・ライセンス）を満たしていない

承認機能は承認データをDataverseに保存します。環境にDataverseが用意されていない、あるいは利用者が承認機能を使える状態になっていない場合、承認アクションはエラーになります。また、標準コネクタの範囲を超える構成では、追加ライセンスが必要になることもあります。

対処：テスト環境と本番環境で前提条件が異なっていないかを確認します。ライセンスの考え方はPower Automateで経費精算を自動化する方法と注意点でも整理しています。

原因9：実行回数の上限やスロットリングに達している

短時間に大量の実行が走ると、API要求数の上限に達して処理が待機状態になったり、失敗したりします。月初・月末に申請が集中する業務では、特定の時期だけ不安定になるという形で表面化します。

対処：不要なループやポーリングを減らし、1件の申請あたりのアクション数を見直します。全社展開の規模になる場合は、ライセンス面の見直しも含めて検討が必要です。

原因10：承認後の条件分岐が正しく判定できていない

「承認されたのに後続が動かない」「却下なのに承認扱いになる」といった症状は、条件分岐で比較している値が実際の応答と一致していないことが原因です。カスタムの応答オプションを使っている場合は特に起きやすくなります。また、承認の種類を「全員の承認が必要」にしていると、1人でも未対応であればフローは先へ進みません。

対処：実行履歴で承認アクションの出力（応答の値）を実際に確認し、その値と条件式を突き合わせます。

なお、フロー自体は正常に動いていても、承認依頼が承認者に届かない・届いても見落とされるという別種の問題があります。切り分けと対処はTeamsの承認通知が届かない・見落とす原因と対策にまとめています。

止まらないフローはどう設計する？（4つのポイント）

ここまでの10原因のうち、原因1〜4は設計で予防できるものです。個別に直すより、次の4点を設計に組み込むほうが結果的に工数は下がります。

1. 期限とリマインドをセットで持つ

「承認の開始と待機」を、承認の作成と完了待機に分け、待機側にタイムアウトを設定します。タイムアウトしたらリマインドを送って再度待機する構成にすれば、承認者の放置がそのままフローの失敗になる状態を避けられます。実行時間の上限に達する前に、必ず決着（承認・却下・取り下げ）がつく設計にしておくことが重要です。

2. エスカレーションのルールを先に決める

一定期間応答がない依頼を、上位者や代理者に回すのか、督促だけ送るのか。これは技術の問題ではなく業務ルールの問題です。自動で承認者を差し替えることが内部統制上許容されるかは、監査部門と先に合意しておきます。回した履歴が証跡として残る形にしておくことも忘れないでください。

3. 不在・代理・退職を前提に設計する

承認者本人の不在設定任せにせず、部門ごとの代理者を定義しておきます。承認の委任機能を使う場合も、設定するかどうかが個人任せになっていないかが運用の分かれ目です。あわせて、フローの所有者を共同所有にしておくと、担当者の退職でフローごと止まる事態を防げます。

4. 承認者をマスタ化する

承認者をフロー内に直書きせず、SharePointリストから部門コードをキーに取得します。組織改編のたびにフローを直接編集する運用がなくなり、改修ミスによる停止も減らせます。多段階承認や金額分岐を含む場合は特に効果が大きく、購買稟議での具体的な設計はMicrosoft 365で購買申請・発注承認を自動化する方法と設計の勘所で整理しています。

それでも残る「運用の重さ」はどう扱うのか？

ここまでの対処と設計を入れれば、承認フローの停滞は確実に減らせます。一方で、対策を入れるほどフローは複雑になり、フロー自体の保守という別のコストが発生します。リマインド、エスカレーション、代理承認、承認者マスタ、エラー通知と積み上げていくと、当初の「ノーコードで手軽に作れる」という前提からは離れていきます。

さらに、承認が止まらなくなっても、その先の発注・支払い・精算が手作業のままであれば、業務全体のリードタイムは短くなりません。承認のトラブル対応に情シスの工数が慢性的に取られている場合は、フロー内製の限界に近づいているサインです。標準機能・内製・専用ツールの三択をどう判断するかはMicrosoft 365の承認ワークフロー｜Teams標準機能の限界と全社展開の3つの選択肢で、SaaS利用申請や監査証跡の観点はMicrosoft 365 SSO申請承認、標準機能の限界と解決策で整理しています。

1Approval for Microsoft 365は、承認の仕組みそのものを提供するだけでなく、承認が完了した時点で購買や手配の実行までつなぐことを前提とした仕組みです。承認ルートや代理承認の設定は管理画面から行えるため、組織改編のたびにフローを編集する必要がありません。承認後は購買が実行され、購買データは経費データとして自動生成されて会計・経費精算システムと連携し、複数サービス・複数取引先の利用料は月1回の法人一括請求にまとめられます。承認フローの保守に追われている状態を根本から見直したい方は、1Approval for Microsoft 365の詳細を見るから具体的な仕組みを確認してみてください。

よくある質問（FAQ）

承認依頼が承認者に届きません。何を確認すればよいですか？

まずフローの実行履歴を確認し、承認アクションが成功しているかを見てください。成功しているのに届いていない場合は、Teamsの承認アプリの一覧に依頼が出ているかを確認します。アクションが失敗している場合は、承認者の指定（メールアドレスになっているか、配布リストを指定していないか）と、アカウントが有効かを確認します。

承認者が長期不在のときはどうすればよいですか？

事前の対策としては、部門ごとの代理承認者を定義し、承認依頼にタイムアウトとリマインドを設定しておくことです。代理承認そのものの設計（期間と範囲の区切り方、証跡の残し方）は代理承認の設計｜承認者不在で止めない、証跡を壊さないで扱っています。すでに滞留している案件については、代理者に引き継ぐか、いったん却下して再申請する運用をルール化しておくと、判断で迷わなくなります。

フローが勝手にオフになっていました。原因は何ですか？

連続したエラーによる自動中断か、長期間実行されていないことによる無効化が代表的な原因です。オンに戻すだけでは再発するため、実行履歴で失敗したアクションを特定し、根本原因を修正してから再開してください。

承認は完了しているのに後続の処理が動きません。

条件分岐で比較している値が、承認アクションの実際の出力と一致していない可能性が高いです。実行履歴で承認アクションの出力を確認し、条件式の比較対象と突き合わせてください。カスタムの応答オプションを使っている場合は特に注意が必要です。

承認フローのトラブルを減らすために、最初にやるべきことは何ですか？

承認者をフロー内に直書きせず、マスタ用のリストから取得する構成に変えることです。承認者の指定ミス、退職・異動による停止、組織改編時の改修ミスという、頻度の高いトラブルをまとめて減らせます。

まとめ

承認フローが止まったときは、原因を当てにいく前に「フローは実行されたか」「承認アクションまで到達したか」「承認者に届いたか」「承認後の処理が動いたか」の順で切り分けると、確認すべき箇所を絞り込めます。原因の多くは、タイムアウト、承認者の指定・不在、接続の失効、条件分岐の判定ミスに集約されます。

そのうえで、期限とリマインド、エスカレーションのルール、代理承認、承認者のマスタ化という4点を設計に組み込めば、同じ停滞は繰り返さなくなります。ただし対策を積み上げるほどフローの保守コストは増えていくため、どこまでを内製で維持するのかは定期的に見直しておくことをおすすめします。