Power Automateで稟議フローは作れる？内製の限界

「稟議をPower Automateで回したい」という相談は、Microsoft 365を全社導入している企業でほぼ必ず出てきます。結論から言えば、直列の多段階承認も、金額に応じた承認者の分岐も、複数人の合議も、標準機能の範囲で実装できます。問題は「作れるかどうか」ではなく、自社の稟議規程を再現したときにフローがどこまで複雑になり、その後何年保守できるかです。本記事では、稟議に必要な要件ごとの実装パターンを整理したうえで、内製を続けるか専用ツールへ移行するかの判断基準を示します。

この記事の要点

• 直列の多段階承認、金額による承認者の分岐、複数人の合議は、いずれもPower Automateの標準機能の範囲で実装できる。
• 問題は「作れるかどうか」ではなく、自社の稟議規程を再現したときフローがどこまで複雑になり、その後何年保守できるか。
• 稟議要件は「標準機能で実装しやすい層」「作り込めば実装できる層」「内製だと重くなりやすい層」の3層に分かれ、多くのプロジェクトは1層目だけを見て判断してしまう。
• 組織改編への追随、合議体の動的決定、稟議書の様式・版管理、監査用レポート出力が内製の破綻ポイントになりやすい。
• 内製継続か専用ツール移行かは、機能の有無ではなく保守可能性で判断する。

稟議の要件はPower Automateのどの機能に対応するのか？

日本企業の稟議は、海外製ツールが前提とする「承認（Approval）」より要件が多くなりがちです。よくある要件を分解すると、次の3つの層に分かれます。

• 標準機能で実装しやすい：直列の多段階承認、金額による承認者の分岐、全員承認の合議、承認履歴の記録、Teamsでの承認操作
• 作り込めば実装できる：承認者マスタからの取得、代理承認、差し戻し後の再申請、リマインドとエスカレーション、条件付きの承認省略、分割申請の検知
• 内製だと重くなりやすい：組織改編への追随、合議体の動的な決定、稟議書の様式・版管理、監査用のレポート出力、承認ルートを非エンジニアが変更できる状態の維持

多くのプロジェクトは、1層目だけを見て「作れる」と判断し、2層目と3層目の存在に運用開始後に気づきます。要件定義の段階で、この3層のどこに自社の要件が分布しているかを確認しておくことが重要です。

実装パターン：4つの承認アクションの使い分け

Power Automateの「承認の開始と待機」には、承認の種類が複数用意されています。稟議の要件に対する使い分けは次のとおりです。

承認の種類	挙動	稟議での使いどころ
承認/拒否 - 最初に応答	指定した承認者のうち、最初に応答した1人の結果で確定する	同格の担当者が複数いて、誰か1人が処理すればよいケース
承認/拒否 - 全員の承認が必要	指定した全員が承認して初めて次へ進む	合議・関係部署の同意が必要なケース
カスタム応答 - 1人の応答を待機	承認/却下以外の選択肢を定義できる	「条件付き承認」「保留」など独自の決裁区分がある場合
カスタム応答 - すべての応答を待機	独自の選択肢で、全員の応答を待つ	合議かつ独自の決裁区分がある場合

直列の多段階承認（上長 → 部門長 → 役員）

最も基本的な稟議の形です。承認アクションを順番に並べ、前段が承認された場合のみ次段へ進むよう条件分岐でつなぎます。段数が増えるほどアクション数は増えますが、構造としては素直です。

注意点は、却下された時点でどうするかを各段で決めておくことです。フローを終了して申請者に通知するのか、差し戻して修正後に再申請させるのか。後者を実装する場合はループ構造と状態管理が必要になり、難易度が一段上がります。

金額に応じた承認者の分岐

条件分岐（If）またはスイッチ（Switch）で金額帯ごとに処理を分けます。

• 〜3万円：上長のみ
• 〜30万円：上長＋部門長
• 30万円超：上長＋部門長＋役員

ここで重要なのは、金額帯ごとに承認アクションを丸ごと複製しないことです。分岐の中では「承認者の配列を組み立てる」ことだけを行い、承認アクション自体は分岐の後に1つだけ置く構成にすると、フローの見通しがよくなり、後の改修も局所化できます。

合議（関係部署の同時承認）

複数部署の同意が必要な場合は、「全員の承認が必要」を選び、承認者に関係者全員を指定します。ただし、1人でも未対応であればフローは先へ進みません。誰が未対応なのかを申請者や事務局が把握できる仕組み（リマインドと一覧化）をセットで用意してください。

承認者をマスタから取得する

稟議フローで最も効いてくる実装が、承認者をフロー内に直書きしないことです。部門コードや役職をキーに、SharePointの承認者マスタから取得する構成にします。

この構成にしておくと、異動・組織改編への対応がマスタの更新だけで済み、フローを開いて編集する必要がなくなります。承認者の指定ミスによる実行時エラーも減らせます。フローが止まる原因とその予防策はPower Automateの承認フローが止まる原因10選と対処法【切り分け手順つき】で整理しています。

代理承認・不在時の扱い

代理承認は、次の2通りの実装があります。

1. 代理者マスタを持つ：承認者ごとに代理者を登録し、不在フラグが立っている場合は代理者へ回す
2. タイムアウトで回す：一定期間応答がない場合に、代理者や上位者へ改めて承認依頼を出す

1は事前の設定が必要な代わりに確実で、2は設定漏れがあっても止まりません。実務では両方を併用するのが安全です。なお、自動で承認者を差し替えることが内部統制上許容されるかは、実装前に監査部門と合意しておいてください。

代理承認を「誰の権限で押されたことになるか」から設計する話——委譲・代行・移管の使い分け、期間と範囲の区切り方、監査で問われる権限委譲の記録——は代理承認の設計｜承認者不在で止めない、証跡を壊さないにまとめています。

フローエディタ上での具体的な設定手順はMicrosoft 365で承認ワークフローを設定する方法【画面付き】で画面キャプチャつきに解説しています。

内製が破綻し始めるサインとは？

「どこまでならPower Automateで作るべきか」は、機能の有無ではなく保守可能性で決まります。次の5つの軸で、2つ以上が右側に当てはまるようであれば、内製の保守コストが機能の魅力を上回り始めています。

判断軸	内製で回る目安	移行を検討する目安
承認の段数	2〜3段まで	4段以上、部門で段数が変わる
分岐パターン数	金額帯のみ、5パターン程度	金額×部門×カテゴリの掛け算になる
ルートの改定頻度	年1回程度	四半期ごと、組織改編が多い
保守できる人数	2名以上が中身を理解している	作った1人しか触れない
承認の先の業務	承認まででよい	発注・支払い・精算まで続く

分岐の掛け算がフローを壊す

金額帯5パターン × 部門10 × カテゴリ3を素直に条件分岐で表現すると、組み合わせは150通りになります。実際には承認者マスタで吸収するため分岐そのものは減らせますが、**例外規程（特定部門だけ承認者が違う、特定カテゴリは情シス承認を追加）**が増えるほど、マスタでは吸収しきれない個別処理がフローに残っていきます。

「作った人しか触れない」が最大のリスク

Power Automateのフローは画面上では追えても、数十アクションに育つと、条件式・変数・動的なコンテンツの依存関係を把握するのは容易ではありません。作成者の異動・退職で保守できなくなり、誰も直せないまま動き続けるフローが残る——という展開は、内製ワークフローで最もよく聞く失敗です。少なくとも共同所有者を設定し、設計の意図をドキュメント化しておいてください。

承認ルートを総務が自分で直せるか

稟議ルートの変更は、本来は総務・経営企画の業務です。それが「情シスにフロー修正を依頼する」作業になっている状態は、運用として持続しません。承認ルートの変更を非エンジニアが画面操作だけで完結できるかは、内製と専用ツールを分ける決定的な境界線です。

承認の先までつなぐとどうなるのか？

もうひとつ見落とされがちなのが、5つ目の判断軸である「承認の先の業務」です。稟議の多くは、承認して終わりではなく、その後に発注・手配・支払い・精算が続きます。Power Automateで承認を自動化しても、承認後に担当者が購買サイトを開いて手配し直す運用が残るなら、リードタイムは思ったほど短くなりません。購買稟議での具体的な設計はMicrosoft 365で購買申請・発注承認を自動化する方法と設計の勘所で、経費精算での同種の課題はPower Automateで経費精算を自動化する方法と注意点で整理しています。

1Approval for Microsoft 365は、この「承認と実際の購買・手配をつなぐ層」を担う仕組みです。承認ルートや代理承認は管理画面から設定できるため、組織改編のたびにフローを編集する必要がありません。そして承認が完了した時点で購買や手配が実行されるため、「承認済みの申請」と「実際の発注」が別々に存在する状態そのものが生まれません。購買データは実行時点で経費データとして自動生成され、会計・経費精算システムと連携できるほか、複数サービス・複数取引先の利用料を月1回の法人一括請求にまとめられます。

標準機能・内製・専用ツールという3つの選択肢の比較はMicrosoft 365の承認ワークフロー｜Teams標準機能の限界と全社展開の3つの選択肢でも整理しています。稟議ルートの複雑さと保守体制を踏まえて検討したい方は、1Approval for Microsoft 365の詳細を見るから具体的な仕組みを確認してみてください。

よくある質問（FAQ）

Power Automateで4段階以上の承認フローは作れますか？

作れます。承認アクションを順に並べ、条件分岐でつなぐだけです。ただし段数が増えるほどアクション数と分岐が増え、保守が難しくなります。部門によって段数が変わる要件がある場合は、承認者の配列をマスタから組み立て、承認アクション自体は1つにまとめる設計を検討してください。

金額によって承認者を変えるにはどうすればよいですか？

条件分岐（If）またはスイッチ（Switch）で金額帯ごとに処理を分けます。分岐の中では承認者を決めるだけにとどめ、承認アクションは分岐の後に置く構成にすると、フローの見通しがよくなり改修も局所化できます。金額は自由入力にせず、単価×数量の計算値にしておくと判定がぶれません。

複数部署の合議はどう実装しますか？

承認の種類で「全員の承認が必要」を選び、関係者全員を承認者に指定します。1人でも未対応だと先に進まないため、誰が未対応かを可視化するリマインドの仕組みをあわせて用意してください。

差し戻し後の再申請はPower Automateで扱えますか？

扱えますが、難易度は上がります。却下時に申請者へ差し戻し、修正後に再度承認へ戻すループ構造と、どの段階まで戻すかの状態管理が必要になるためです。「却下されたら新規申請として出し直す」と運用で割り切るほうが、フローはシンプルに保てます。

組織改編のたびにフローを修正する必要がありますか？

承認者をフロー内に直書きしていると必要になります。部門コードをキーに承認者マスタから取得する構成にしておけば、改編時の対応はマスタの更新だけで済みます。稟議フローを内製する場合、この設計にするかどうかが長期的な保守コストを大きく左右します。

まとめ

Power Automateは、直列の多段階承認、金額による分岐、合議といった稟議の基本要件を標準機能の範囲で実装できます。一方で、代理承認、差し戻し、組織改編への追随、監査レポートといった要件は作り込みが必要で、その分だけ保守負担が積み上がっていきます。

判断のポイントは、承認の段数、分岐パターン数、ルートの改定頻度、保守できる人数、そして承認の先に発注・支払いが続くかどうかの5つです。2つ以上が「移行を検討する目安」に当てはまるなら、フローの作り込みを続けるより、承認ルートを画面から変更でき、承認の先の業務までつながる仕組みへの移行を検討する段階といえます。