Power Automate の承認フローで差し戻しができない — 複数人承認・代理承認など、日本の稟議で詰まる5つの限界

Power Apps や SharePoint で業務データの管理基盤が整ってきた。次は承認フローだ。Power Automate の承認アクション（Approvals）を使えば標準機能でいけるだろう――そう考えて実際に稟議フローを組んでみた結果、いくつかの壁にぶつかった話を共有します。

同じ道を通ろうとしている方の参考になればと思い、共有します。

まず、Power Automate の承認フローで稟議を組んでみた

Power Automate Approvalsの基本的な構成はシンプルです。「承認の作成」アクションで承認者を指定し、応答を待ち、結果に応じて分岐する。Dataverseトリガーと組み合わせれば、レコードのステータス変更をきっかけに承認フローを起動できます。

課長承認 → 部長承認のような2段階の直列承認なら、Approvalsアクションを2つ並べるだけ。Teams上で承認通知が届き、その場で承認・却下ができる。ここまでは快適でした。

問題は、日本企業の稟議でよくある要件を実装しようとしたときに出てきます。

限界1: 複数人承認（合議）で、否認されても止まらない

Power Automate Approvalsの承認タイプは「全員の承認が必要」と「最初の応答者による承認」の2つです。一見すると「全員の承認が必要」で合議に対応できそうに見えますが、これは単に全員がアクションするまで待つだけであって、「全員が承認したら合議成立」という判定ロジックではありません。

日本の稟議でよくある「経営会議メンバー全員の承認で決裁」のような合議は、1人でも否認したら即座に否決、残りの承認は不要、という動きが求められます。Approvalsではこの「途中打ち切り」ができないため、否認が出ても全員の応答を待ち続けるか、フロー側でタイムアウトやポーリングを組む必要があります。

結果として、フローが複雑になる割に挙動が不自然になります。

限界2: 差し戻しができない（戻し先を選べない）

Approvalsの応答は「承認」か「却下」の二択です。却下するとフローは否認ルートに進みますが、「2つ前のステージに差し戻す」「起案者に戻す」といった柔軟な差し戻しはできません。

実務では、部長が「内容はいいけど、課長の確認コメントが不足しているから課長承認に戻して」というケースは珍しくありません。Approvalsでこれをやろうとすると、フローを最初から再実行するしかなく、それまでの承認履歴は失われます。

差し戻し先の指定は、日本の稟議における「手戻り」の文化と密接に結びついていて、ここが対応できないのは実用上かなり痛いところです。

限界3: 代理承認がない

承認者が休暇中だとどうなるか。Approvalsには代理承認の仕組みがありません。承認タスクは指定された承認者に紐づいたままで、他の誰かが代わりにアクションすることはできません。

「来週から2週間休暇なので、その間の承認は〇〇さんに委任する」という運用は、日本企業ではごく一般的です。Approvalsでこれに対応しようとすると、休暇のたびにフローを修正するか、共有メールボックスのような回避策を取ることになりますが、どちらも「誰が代理で承認したのか」の記録が残りません。

監査の観点からも、代理承認は「本人の承認」とは区別して記録する必要があります。

限界4: 承認履歴が監査に使える記録として残らない

Approvalsの承認結果はDataverse上のApprovalテーブルに保存されますが、このテーブルのレコードは更新・削除が可能です。つまり、承認後に「誰が・いつ・何を承認したか」の記録を後から変更できてしまいます。

内部統制や監査対応を考えると、承認履歴は不変であるべきです。一度記録された承認アクションが事後的に改ざんされないことを保証できないと、「この決裁書類は本当に適切な承認を経たのか？」という問いに答えられません。

Dataverseの監査ログ機能で補完する手はありますが、それは「変更された事実の検出」であって「変更を防止する」こととは異なります。

限界5: 条件分岐で承認者を変えるとフローが膨らむ

「100万円以上は役員承認が必要」「人事関連は人事部長の承認を追加」といった条件分岐は、稟議フローでは当たり前の要件です。

Approvalsでこれを実現するには、フロー側に条件分岐を書き、金額やカテゴリに応じて承認者と承認段数を動的に変える必要があります。条件が増えるたびにフローは肥大化し、Switch文の入れ子やスコープの連鎖が続く、いわゆる「スパゲッティフロー」が完成します。

さらに、Power Automateのswitch/conditionは5パスが上限（ネスト除く）なので、金額帯が6段階ある場合はそれだけで構造的な限界に当たります。ルーティングロジックとフロー制御が混在することで、保守性は急速に悪化します。

私たちはどうしたか

上記の限界に直面した結果、Dataverseネイティブの承認フローエンジンを自前で構築する判断に至りました。設計思想を簡単に紹介します。

ルート定義とフロー実行の分離。承認ルート（誰が・何段階で・どの条件で）はDataverseテーブルで定義し、実行時にインスタンスとしてコピーする構造にしました。ルート定義を変えても実行中のフローには影響しません。

ステージタイプで合議・回覧に対応。各ステージに「直列・並列・合議・回覧」のタイプを持たせ、合議なら全員承認で通過、1人でも否認なら即時否決。回覧は確認のみで否認不可。フロー側で判定ロジックを書く必要はありません。

差し戻しはルート定義で制御。差し戻しモード（最初から／任意ステージ）をルート定義に持たせ、承認者は差し戻しアクションを実行するだけ。どこに戻るかはエンジンが判断します。

代理承認はルールテーブルで管理。委任者・代理者・有効期間・対象ルートをテーブルで定義。代理承認時は「誰が代理で承認したか」を明示的に記録します。

承認履歴は不変。履歴テーブルは作成のみ、更新・削除をPluginで禁止。監査に耐える不変記録として機能します。

条件分岐はルート条件テーブルで。金額やカテゴリに応じたルート選択を、フローではなくテーブルデータとして定義。条件の追加・変更にフロー修正は不要です。

技術的には、Custom APIは使わずCRUDトリガーPlugin方式を採用しています。承認アクションは標準の Xrm.WebApi.updateRecord で実行でき、Power Automateからも標準のDataverseコネクタで連携可能です。

まとめ

Power Automate Approvalsは、シンプルな承認フローには十分に機能します。2段階の直列承認、承認・却下の二択で完結するケースなら、Teamsとの統合も含めて優れた選択肢です。

ただし、日本企業の稟議文化――合議、差し戻し、代理承認、監査対応、複雑な条件分岐――を真面目に実装しようとすると、標準機能の枠内では収まらない場面が出てきます。フロー側で無理に作り込むと、保守コストが承認フローの価値を上回る、という本末転倒な状態になりかねません。

Power Automate の承認フローでお困りのことがあれば、お気軽にご相談ください。同じ課題を通ってきた立場から、お力になれることがあるかもしれません。