Power Automateで承認フローを作る ── 紙とメールの稟議・申請を電子化する

「稟議書を印刷して、押印して、隣の部署に回して、戻ってくるのが1週間後」「Excelの申請書をメールに添付して送り、承認は返信メールの『OKです』」。Microsoft 365を導入済みの会社から、こういう申請・承認業務を何とかしたいという相談をよく受けます。

Power Automateには承認(Approvals)という専用の仕組みがあり、TeamsやOutlookから承認ボタンを押すだけの承認フローを、追加費用なしのライセンス範囲で組めることが多いです。ただ、最初のフローが動くことと、業務として安心して回ることの間には距離があります。承認の記録はどこに残るのか、承認者が放置したらどうなるのか、担当者が退職したらフローは誰が直すのか。この記事では、承認フローの基本部品から、実務でつまずきやすい設計ポイント、そしてPower Automateでやるべき範囲の線引きまでを整理します。

1. まず結論

• Power Automateの承認は 「開始して承認を待機」アクションが基本です。承認の種類は「全員の承認が必要」「最初の応答」「カスタム応答(全員/1人)」「順次承認」の5つから選べます。¹
• 承認者は Teams・Outlook・Power Automateポータル・モバイルアプリのどこからでも応答できます。承認のためだけに新しい画面の使い方を覚えてもらう必要はほぼありません。²³
• 申請の受け口は Microsoft Forms / SharePointリスト / Teamsの承認アプリの3択が現実的です。後から一覧・集計したいならSharePointリストを軸にするのが定石です。
• フローの実行履歴は既定で28日しか見えず、1回の実行は最長30日でタイムアウトします。承認の証跡を実行履歴に頼らず、結果をSharePointリスト等へ書き戻す設計を最初から入れておきます。⁴⁵
• フロー所有者の退職・異動は承認フロー最大の運用リスクです。共同所有者の設定と接続の扱いを、動き始めた日のうちに済ませておきます。⁶
• 条件分岐が多い多段承認、代理決裁や監査要件が厳しい稟議規程をそのまま実装しようとすると、Power Automateでは保守しきれなくなります。その場合はワークフローシステムや受託開発の領域です。

この記事の知識マップ

Power Automateの承認(Approvals)機能はクラウドフローの一部として提供され、Microsoft Dataverseに要求・応答のレコードを保存しながら、TeamsやOutlook、SharePointリスト、Microsoft Formsと組み合わせて紙・メールの稟議を電子化する。クラウドフロー1回の実行は30日で打ち切られるため承認待ちも遅くともタイムアウトし、督促と再要求によるエスカレーション設計が対策として推奨される。フローの実行履歴は既定28日しか残らないため承認証跡としては使えず、結果をSharePointリストへ書き戻す設計が推奨される。承認結果によるリストの更新自体がトリガー条件を満たしてフローを再起動させる自己トリガーのループが起こり得るため、トリガー条件による絞り込みが欠かせない。承認者の一時的な不在は再割り当てで、フロー所有者の交代リスクは共同所有者の設定で軽減する。

flowchart LR
    accTitle: Power Automateの承認フローの知識マップ
    accDescr: Power Automateの承認(Approvals)機能がクラウドフロー・Dataverse・SharePointリスト・Teams・Outlook・Formsとどう関わり、30日の実行期間上限によるタイムアウトや自己トリガーの無限ループといったリスクを、トリガー条件・共同所有者・証跡の書き戻しでどう防ぐかを示す図。
    power_automate_approval["承認(Approvals)機能"]
    power_automate_cloud_flow["Power Automate クラウドフロー"]
    dataverse["Microsoft Dataverse"]
    microsoft_teams["Microsoft Teams"]
    outlook["Outlook"]
    sharepoint_list["SharePointリスト"]
    microsoft_forms["Microsoft Forms"]
    flow_run_duration_limit["クラウドフローの実行期間上限(30日)"]
    approval_timeout["承認アクションのタイムアウト"]
    approval_timeout_escalation["タイムアウト時の督促・エスカレーション設計"]
    rejection_resubmission_loop["差し戻し・再申請ループ"]
    trigger_condition["トリガー条件(Trigger Conditions)"]
    self_trigger_loop["自己トリガーによる多重起動"]
    flow_run_history["フローの実行履歴"]
    approval_audit_trail["承認の証跡・監査記録"]
    approval_reassign["承認の再割り当て(Reassign)"]
    approver_unavailability["承認者の不在・恒常的な変更が必要な状況"]
    flow_co_owner["フローの共同所有者"]
    power_automate_cloud_flow -.->|"利用する"| power_automate_approval
    power_automate_approval -->|"前提とする"| dataverse
    power_automate_approval -->|"に保存される"| dataverse
    power_automate_approval -.->|"利用する"| microsoft_teams
    power_automate_approval -->|"利用する"| outlook
    power_automate_cloud_flow -.->|"利用する"| sharepoint_list
    power_automate_cloud_flow -.->|"利用する"| microsoft_forms
    flow_run_duration_limit -->|"原因になり得る"| approval_timeout
    power_automate_approval -.->|"原因になり得る"| approval_timeout
    approval_timeout_escalation -->|"推奨される対応"| approval_timeout
    rejection_resubmission_loop -->|"前提とする"| trigger_condition
    power_automate_cloud_flow -.->|"原因になり得る"| self_trigger_loop
    trigger_condition -->|"防止する"| self_trigger_loop
    flow_run_history -->|"用いるのは非推奨"| approval_audit_trail
    sharepoint_list -->|"推奨される対応"| approval_audit_trail
    approval_audit_trail -->|"利用する"| power_automate_approval
    approval_reassign -->|"軽減する"| approver_unavailability
    flow_co_owner -->|"推奨される対応"| power_automate_approval
    flow_co_owner -->|"推奨される対応"| approver_unavailability
    rejection_resubmission_loop -->|"利用する"| power_automate_approval
    power_automate_cloud_flow -->|"利用する"| trigger_condition

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全21件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 紙・メール稟議の何が問題か

紙の稟議書やメール添付Excelの承認がつらいのは、手間そのものよりも「状態が見えない」ことです。相談を受けていて共通するのは、だいたい次の3つです。

• 今どこで止まっているかわからない。稟議書が誰の机にあるのか、メールがどの受信トレイに埋もれているのか、申請した本人には見えません。催促は口頭か電話になり、催促される側も気分がよくありません。
• 記録が散る。承認の証跡が、紙のキャビネットと個人のメールボックスに分散します。監査や後からの照会で「あの申請、誰がいつ承認したか」を調べるのに、人のメールボックスを漁ることになります。担当者が退職すればメールボックスごと消えます。
• 差し戻しが追えない。却下や修正依頼が口頭・メールで行われると、どのバージョンの申請書に対する指摘だったのかが混ざります。修正版を再送すると、また最初から回覧です。

これらは「申請の状態と記録を1か所に集める」ことでほぼ解決します。そしてMicrosoft 365を導入済みなら、その置き場所(SharePoint)と通知経路(Teams/Outlook)と自動化(Power Automate)はすでに手元にあります。

3. Power Automate承認の基本部品

「開始して承認を待機」アクション

承認フローの中心は、承認(Approvals)コネクタの「開始して承認を待機(Start and wait for an approval)」アクションです。承認要求のタイトル・詳細・承認者を指定すると、フローはそこで停止し、承認者の応答を待ってから次のアクションへ進みます。¹

承認の種類は5つあります。¹

カスタム応答を使うと、「承認」「却下」の2択ではなく「承認」「差し戻し」「保留」のような選択肢を定義できます。後述する差し戻しループの部品になります。

なお、承認機能を使うにはMicrosoft Dataverseのデータベースが必要です。承認要求や応答のレコードはDataverseに保存され、既定の環境では承認フローを最初に作ったときに自動的に用意されるため、通常は意識せずに使い始められます。承認コネクタは標準コネクタなので、標準コネクタを使えるライセンス(Office 365等)で承認フローを作成できます。¹

Dataverseとは ── どこで意識が必要になるか

ここで初めて出てきたDataverse(データバース)は、Power Platform共通のデータ保存基盤です。ざっくり言えば、自社のMicrosoft 365テナントの中に用意されるクラウドのデータベースで、Power Appsのアプリやフローが扱うデータの置き場所として使われます。承認機能はこの上に載っていて、「誰に・いつ承認を依頼し、誰がどう応答したか」はDataverseのテーブルにレコードとして書かれます。

日常の作成・運用でDataverseを意識する必要はほぼありませんが、次の3つの場面だけは顔を出します。

• 新しい環境で承認を初めて使うとき。既定の環境なら自動で用意されますが、部門用に新しく作った環境ではDataverseデータベースの有無を確認する必要があります。¹
• 承認履歴が溜まってきたとき。承認履歴は環境の記憶域を消費し、容量の都合で削除の対象になり得ます。証跡を実行履歴にもDataverseにも頼らない理由がここにあります(次章)。⁷
• 承認レコードを直接読み書きしたくなったとき。Dataverseコネクタでテーブルを直接触る構成にすると、そのコネクタはプレミアム層に分類されるため、追加ライセンスの話が発生します。⁸

つまり「承認を普通に使う分にはライセンス追加なし、Dataverseそのものを触り始めると話が変わる」という線引きです。

承認者はどこから応答するか

承認者には、メールとPower Automateモバイルアプリで承認要求が届きます。³ Outlookでは整形された承認メールが届き、そこから応答できます。⁹ 個人ユーザー宛ての承認はTeamsにも通知され、Teamsのチャットや承認アプリから承認・却下・コメント入力ができます。² 「承認のために専用サイトへログインしてもらう」というハードルがないことが、承認フロー定着の一番の推進力になります。

一点注意があります。承認先をMicrosoft 365グループにした場合、Teams通知は送られません。Teams通知が届くのは個人ユーザー宛ての承認だけです。¹⁰

フロー全体像

購買申請を例にすると、全体はこういう形になります。

flowchart TD
    Submit[申請者が入力<br/>Forms送信 / SharePointリストに登録] --> Trigger[クラウドフロー起動<br/>新しい応答・アイテム追加トリガー]
    Trigger --> Record[申請内容をSharePointリストへ記録<br/>状態: 承認待ち]
    Record --> Approval[開始して承認を待機<br/>承認者へ要求送信]
    Approval -- Teams / Outlook / モバイル --> Response{応答}
    Response -- 承認 --> UpdateOK[リストの状態を「承認済み」に更新<br/>承認者・日時・コメントを列へ記録]
    Response -- 却下/差し戻し --> UpdateNG[状態を「差し戻し」に更新<br/>申請者へ理由を通知]
    Response -- タイムアウト --> Remind[督促通知 / エスカレーション]
    UpdateOK --> NotifyOK[申請者へ結果通知]
    UpdateNG --> Resubmit[申請者が修正して再申請]
    Resubmit -- トリガー条件で<br/>「再申請」のみ起動 --> Trigger

ポイントは、承認アクションの前後に「記録」のステップを挟んでいることです。理由は5章で説明します。

4. 申請の受け口をどう設計するか

承認フローの使い勝手は、承認側よりも申請側の入力の受け口で決まります。現実的な選択肢は3つです。

判断の目安はこうです。

• とにかく都度の承認だけ電子化したいなら、フローを作らなくてもTeamsの承認アプリで足ります。承認アプリはチャットからその場で承認要求を送れる機能で、Power Automateの基盤上で動きますが、フローの作成は不要です。¹¹
• 申請書の置き換えなら、Formsを受け口にして、応答をフローで受け取り承認に回すのが最短です。Formsの応答内容を承認要求に差し込むテンプレートも用意されています。¹³
• 申請台帳として管理したいなら、SharePointリストを軸にします。Formsを入口にする場合でも、フローの最初で応答をリストに転記しておけば、状態列(承認待ち/承認済み/差し戻し)とビューで「今どこで止まっているか」が誰にでも見えるようになります。冒頭に挙げた紙・メール稟議の課題への答えは、実質ここにあります。

小規模に始めるなら「Formsで受けてSharePointリストに記録し、承認結果もリストに書き戻す」構成が、入力の手軽さと台帳管理の両取りができて扱いやすいです。

5. 実務で効く設計ポイント

承認記録をどこに残すか ── 実行履歴に頼らない

一番大事な設計判断です。フローの実行履歴は、既定では28日しか表示されません。⁴ ソリューションに含めたフローであれば実行履歴のメタデータをDataverseに残せますが、こちらも既定の保持は28日で、管理者が保持期間を調整する仕組みです。¹⁴

つまり「誰がいつ承認したか」を実行履歴で後から調べる運用は、1か月で破綻します。承認要求・応答のレコード自体はDataverseに保存されますが¹⁵、監査対応や日常の照会のたびにDataverseのテーブルを覗くのは現実的ではありませんし、承認履歴は環境の記憶域を消費するため、容量都合で削除の対象になることもあります。⁷

実務では、承認アクションの直後に、結果・承認者・応答日時・コメントをSharePointリストの列へ書き戻すステップを必ず入れます。「開始して承認を待機」アクションは応答・承認者・コメントを出力として返すので¹⁵、それをそのまま列に記録するだけです。申請と承認記録が同じリストの同じ行に揃い、保持期間はリストの運用次第で何年でも持てます。

1点だけ注意があります。「全員の承認が必要」やカスタム応答(全員)のような複数承認者の種類では、応答(Responses)は人数分の配列で返ってきます。³ これを1組の列に順に上書きで書き込むと最後の応答しか残らないため、複数承認者の記録は、応答ごとに履歴用リストへ1行ずつ追記するか、全員分の応答を1つのテキストに整形してから列へ記録する形にします。

タイムアウトとリマインダー ── 「期限のない承認」は作れない

クラウドフローの1回の実行は最長30日です。この30日には承認待ちのような保留中のステップも含まれ、30日を過ぎると保留中のステップはタイムアウトします。⁵ 承認者が放置すれば、フローは黙って失敗で終わる。これを知らずに運用を始めると、「申請したのに何も起きない」という一番信頼を損なう事故が起きます。

対策は2段階です。

1. 承認アクションに明示的なタイムアウトを設定する。アクションの設定でISO 8601形式(例: P3Dで3日)のタイムアウトを指定し、実行条件の構成で「タイムアウトした場合」の分岐を用意します。¹⁶ ここで注意したいのは、タイムアウトした時点で元の承認待ちは終了していることです。その後に承認者が応答しても、この実行の後続ステップ(結果の書き戻しなど)には流れません。つまりタイムアウト分岐は「待ち続けながら督促する」場所ではなく、「一度打ち切って次の手を打つ」場所です。督促するなら、タイムアウト分岐で通知を送った上で新しい承認要求を出し直します。
2. 30日を超える可能性がある承認は、フローを2本に分ける。「承認の作成(v2)」アクションで承認要求だけ送って1本目のフローは終了し、応答への後続処理は別フローで行う構成が公式に案内されています。承認レコードはDataverseにあるため、元のフローの実行が終わっても応答は処理できます。待機を打ち切らずに柔軟な督促を組みたい場合も、この2本構成のほうが素直に作れます。¹⁷ なお、2本目のフローの起動方法には設計の余地があり、承認テーブルの変更をDataverseコネクタのトリガーで直接拾う構成にする場合は、Dataverseコネクタがプレミアムライセンスの対象になる点に注意してください(承認コネクタ自体のアクションは標準の範囲です¹)。⁸

タイムアウトと分岐の設定手順

文章だと分かりにくいところなので、デザイナー上の操作を順に書き出します。

1. 「開始して承認を待機」アクションのカード右上の「…」から設定(Settings) を開き、タイムアウト(Timeout) の欄にISO 8601形式の期間を入れます。3日ならP3D、12時間ならPT12Hです。空欄のままだとフローの実行期間の上限(30日)まで待ちます。
2. 承認アクションの下に、タイムアウトしたときにやりたい処理(督促通知など)のアクションを1つ置きます。
3. そのアクションのカード右上の「…」から実行条件の構成(Configure run after) を開き、直前の承認アクションについて「タイムアウトしました」だけにチェックを入れます。既定は「正常終了しました」なので、これを外すのを忘れないでください。
4. 承認された場合の処理(結果の書き戻し・申請者への通知)は、承認アクションからのもう一方の分岐として並べ、こちらは「正常終了しました」のままにします。実行条件の構成で枝分かれさせると、デザイナー上では2つの分岐が並列に表示されます。

「3日で督促、7日で上位者へ」の作り方

いちばん作りたいのがここだと思うので、直列2〜3段の構成を具体的に示します。1段目で3日待ち、無応答なら督促して同じ上長へ出し直し、さらに4日経ったら上位者へ回す形です。

flowchart TD
    A1[開始して承認を待機 1段目<br/>承認者: 直属の上長<br/>設定のタイムアウト P3D] --> Q1{応答があったか}
    Q1 -- 承認・却下 --> Rec[結果をSharePointリストへ書き戻し<br/>申請者へ通知]
    Q1 -- 3日間 無応答 --> R1[督促通知を送る<br/>実行条件の構成: タイムアウトしました]
    R1 --> A2[開始して承認を待機 2段目<br/>承認者: 同じ上長<br/>設定のタイムアウト P4D]
    A2 --> Q2{応答があったか}
    Q2 -- 承認・却下 --> Rec
    Q2 -- さらに4日間 無応答 --> R2[エスカレーション通知を送る<br/>実行条件の構成: タイムアウトしました]
    R2 --> A3[開始して承認を待機 3段目<br/>承認者: 上位者<br/>タイムアウト設定なし]
    A3 --> Rec

作るときのポイントは3つです。

• 2段目・3段目は「新しい承認要求」です。1段目の要求は3日で終了しているので、承認者のTeamsやOutlookには別の要求として届きます。要求のタイトルに「【督促】」「【エスカレーション】」を付けて、申請日と経過日数を本文に入れておくと、受け取った側が状況を理解できます。
• タイムアウトの合計をフローの30日に収めます。上の例は1段目3日+2段目4日で7日を使うので、3段目に残っているのは23日弱です。段数を増やすほど3段目の余裕が減ります。
• 結果の書き戻しを1か所にまとめたいなら変数を使います。承認の結果は段ごとに別のアクションの出力になるため、そのまま書くと書き戻しのステップが3か所に増えます。フローの先頭で文字列変数(例: 承認結果)と承認者を初期化しておき、各段の承認アクションの直後で「変数の設定」を1つずつ置いてから、最後にまとめて1回だけリストへ書き戻すと、後の保守が楽になります。

「タイムアウト→督促→再要求」をDo untilループで巻く形も作れますが、Do untilにはループ自体の上限(既定で60回・1時間)が別にあり、承認待ちのような長時間のアクションを中に入れる場合は「制限の変更」でループのタイムアウトを明示的に延ばさないと、1周目のあと2周目以降が始まりません。⁵¹⁸ この「制限の変更(Change limits)」はDo untilアクションのカードの中にあるリンクで、開くとカウント(Count) とタイムアウト(Timeout) の2つを指定できます。カウントは反復回数(既定60)、タイムアウトはループ全体の制限時間をISO 8601で書く欄(既定PT1H)です。3日待つ承認を3周させたいなら、カウントを3、タイムアウトをP10Dのように「想定する周回時間の合計より長い値」にします。ただしここを延ばしても、フロー全体の30日は延びません。

中小企業の稟議であれば、まず「3日で督促、7日で上長へエスカレーション」のような社内ルールを決め、それを再要求ループまたは2本構成で実装するのが現実的です。

不在時の再割り当て

承認者が長期不在のケースは必ず起きます。承認要求を受け取った本人は、Power Automateポータルの承認一覧から要求を他の人へ再割り当て(Reassign)できます。一方、要求を出した側での立て直しは、要求のキャンセルと承認者の変更・再実行という手順になります。⁹ 注意したいのは、この記事のような自動起動のフローでは、これは申請者ではなくフロー所有者側の作業になることです。承認要求はフローの接続に使ったアカウントから出ており、承認者の変更にはフローの編集権限が必要なためです。「承認者が休職したときは誰がフローを直すのか」を、次章の共同所有者の話とセットで決めておく必要があります。

ただし、再割り当ては「受け取った本人が操作できる」ことが前提なので、突発の休職などには効きません。恒常的な備えとしては、承認者を個人1名に固定せず、複数名をセミコロン区切りで指定して「最初に応答」型にするか、グループ宛てにする設計が安全です。⁹ グループ宛てはTeams通知が飛ばない制約¹⁰があるため、通知の確実性を重視するなら複数名指定を選びます。

却下時の差し戻しループ

紙の稟議で一番追いにくかった「差し戻し→修正→再申請」は、状態列を持つ設計なら素直に表現できます。基本形はこうです。

• カスタム応答で「承認」「差し戻し」を定義する¹
• 差し戻しの場合、リストの状態列を「差し戻し」にし、承認者のコメントを列に記録して申請者へ通知する
• 申請者はリストのアイテムを修正して状態を「再申請」に変える(またはFormsから再送信する)
• アイテム更新をトリガーにフローが再度走り、承認へ回る

この形で1つ注意が要るのは、フロー自身の書き戻しでフローが再起動してしまうことです。「アイテムが作成または変更されたとき」トリガーのままだと、フローが状態列を「承認待ち」や「承認済み」に更新した瞬間、その更新自体がトリガー条件を満たし、二重の承認要求や無限ループが起きます。クラウドフローは自分自身をトリガーでき、Power Automateも保存時に無限ループの可能性を警告してきます。¹⁹ 対策は、後段の条件分岐で捨てるのではなく、トリガー条件(trigger conditions)で「状態列が『再申請』(または新規作成)のときだけ起動する」とトリガー側に書くことです。トリガー条件を満たさない更新ではフローの実行自体が発生しないため、実行回数も消費しません。²⁰

トリガー条件は、トリガーのカード右上の「…」から設定(Settings) を開き、トリガーの条件(Trigger Conditions) に@で始まる式を1行ずつ書きます。SharePointリストの選択肢列ApprovalStatusが「再申請」のときだけ起動させるなら、こうなります。

@equals(triggerOutputs()?['body/ApprovalStatus/Value'], '再申請')

新規作成(状態列が空)でも起動させたいなら、orで束ねます。

@or(equals(triggerOutputs()?['body/ApprovalStatus/Value'], '再申請'), empty(triggerOutputs()?['body/ApprovalStatus/Value']))

書き方で押さえておく点が3つあります。

• @は先頭の1回だけです。中に入れ子にするequalsやemptyには付けません。
• 選択肢列は/Valueまで指定します。選択肢列は文字列ではなくオブジェクトとして返るため、body/ApprovalStatusで比較しても一致しません。1行テキスト列なら/Valueは不要です。
• 列の内部名に日本語を使わない。SharePointは列名に日本語を使うと内部名が_x72b6__x614b_のようなエンコード文字列になり、式に表示名をそのまま書いても一致しません。フローで参照する列は英数字の名前で作ってから表示名を日本語に変えると、この手の式で消耗せずに済みます。内部名はリスト設定の列詳細ページのURL(Field=の後ろ)で確認できます。

修正履歴はリストのバージョン履歴に残るため、「どの版に対する指摘か」が混ざる問題も解消します。フロー内でDo untilループを組んで1回の実行内で差し戻しを回す作りも可能ですが、30日の実行期間制限に差し戻しの往復時間も含まれてしまうため、差し戻しのたびに実行を終え、再申請で新しい実行を始める設計のほうが安全です。

6. 運用とガバナンス ── フローは「作った人のもの」にしない

承認フローは業務の基幹に入り込むため、属人化すると影響が大きくなります。最低限、次の2点は稼働初日に済ませます。

• 共同所有者を設定する。フローの所有者は実行履歴の確認、フローの編集・停止、接続の資格情報の更新までできます。作成者1人のままだと、退職・異動した瞬間に誰も直せないフローになります。情報システム担当者や後任候補を共同所有者に追加しておきます。なお、SharePointリスト自体を共同所有者にして「リストの編集権限を持つ人=フローを編集できる人」に揃える機能もありますが⁶、この記事のように申請者全員が書き込む受け口のリストでこれをやると、申請者全員にフローの編集権限を渡すことになってしまいます。承認フローでは使わず、共同所有者は運用を担う担当者個人か管理者用のグループに限定してください。
• 接続の扱いを理解しておく。フローで使う接続(SharePointやOutlookへの認証)は作成したユーザーに紐づき、共有された接続はそのフロー内でしか使えません。また共同所有者は他の所有者が作った接続の資格情報を変更できません。⁶ 承認結果の通知メールが「退職した人のアカウント」から送られ続ける、アカウント無効化と同時にフローが止まる、といった事故はここから起きます。通知や書き込みに使うアカウントをどうするかは、フローを作る前に決めておくべき論点です。

なお、フローを他部署にも使ってもらう場合でも、申請する人たちにフローを共有する必要はありません。この記事の構成では、受け口(FormsやSharePointリスト)に入力できさえすればフローは自動で起動します。共有の対象は編集・運用に関わる人だけに絞り、共同所有者は必要最小限にとどめるのが原則です。²¹

ライセンス、環境分離、DLPポリシーといったPower Automate全体のガバナンスについては、別記事「Power Automateで業務を自動化する ── クラウドフロー・デスクトップフローの使い分けとエラー処理設計」で整理しています。承認フローもクラウドフローの一種なので、同じ考え方がそのまま適用されます。

7. どこまでPower Automateでやるか

Power Automateの承認は強力ですが、稟議規程をそのまま実装する道具ではありません。線引きの目安を挙げます。

判断の感覚としては、「フローの分岐を紙に描いてA4に収まらなくなったら、Power Automateの守備範囲を超え始めている」くらいで見ています。無理にフローを育てるより、承認ルートの決定ロジックだけ外(Dataverseのテーブルや別システム)へ出す、あるいは専用システムへ移る判断のほうが、結果的に安く済むことが多いです。

また、承認フローの電子化は、社外との紙・FAXのやり取りを見直す入り口になることもよくあります。社内の稟議が電子化できたら、次はFAX受注や請求書のやり取りが候補です。このあたりは「FAX受注をWebに移すには ── 二重運用期間の設計と段階移行の実務」や「EDIとは？企業間の受発注をどう楽にするのか ── FAX・メール・手入力からデータ連携へ」で扱っています。

8. まとめ

紙とメールの稟議の本当の問題は、手間ではなく「状態が見えない・記録が散る・差し戻しが追えない」ことでした。Power Automateの承認フローは、この3つを「申請と承認記録をSharePointリストに集め、承認の操作はTeams/Outlookで済ませる」形で解決します。追加のシステム投資なしに始められることが多いのも、Microsoft 365導入済みの会社には大きな利点です。

一方で、実行履歴28日・実行期間30日という制約を知らずに作ると、「証跡が消える」「申請が黙って失敗する」承認フローができあがります。結果の書き戻し、タイムアウト分岐、複数承認者、共同所有者。この4点を最初から設計に入れておけば、承認フローは長く安心して回せます。そして、稟議規程の複雑さをそのまま実装したくなったときが、専用システムや受託開発を検討するタイミングです。

関連記事

• Power Automateで業務を自動化する ── クラウドフロー・デスクトップフローの使い分けとエラー処理設計
• FAX受注をWebに移すには ── 二重運用期間の設計と段階移行の実務
• EDIとは？企業間の受発注をどう楽にするのか ── FAX・メール・手入力からデータ連携へ
• デジタルインボイスとは？ ── 「請求書のPDFをメールで送る」と何が違うのか

関連する相談領域

合同会社小村ソフトでは、Microsoft 365を活かした業務フローの電子化の相談から、Power Automateでは収まらない承認・帳票要件のシステム化まで扱っています。

• 技術相談・設計レビュー
• Windowsアプリ開発
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

Power Automateの承認フローはMicrosoft 365のライセンスだけで作れますか？

作れます。承認(Approvals)コネクタは標準コネクタなので、標準コネクタを使えるライセンス(Office 365等)があれば承認フローを作成できます。ただし承認データの保存先としてMicrosoft Dataverseのデータベースが必要で、既定の環境では承認フローを最初に作成したときに自動的に用意されます。SharePointリストやForms、Teams、Outlookとの組み合わせも標準コネクタの範囲で構成できます。

承認者が応答しないまま放置されるとどうなりますか？

クラウドフローの1回の実行は最長30日で、承認待ちのような保留中のステップも30日を過ぎるとタイムアウトします。そのため「期限を設けない承認」は作れません。実務では承認アクションに明示的なタイムアウトを設定し、『実行条件の構成』で「タイムアウトした場合」の分岐を用意します。タイムアウトすると元の承認待ちは終了し、その後の応答は後続ステップに流れないため、この分岐では督促通知とあわせて新しい承認要求を出し直す(繰り返し回数に応じて上位者へエスカレーションする)設計にします。30日を超えて待つ必要があるなら、承認の作成(v2)アクションと応答を処理する別フローの2本構成に分けます。

承認の記録はどこに残りますか？監査に使えますか？

承認要求や応答はMicrosoft Dataverseにレコードとして保存され、フロー自体の実行履歴は既定で28日しか表示されません。監査や後からの照会を実行履歴に頼るのは危険です。実務では、承認結果・承認者・承認日時・コメントをフローの最後でSharePointリストの列に書き戻し、申請データと承認記録を1か所で一覧できるようにしておく設計をお勧めします。

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

承認要求を受け取った本人は、Power Automateの承認一覧から他の人へ再割り当て(Reassign)できます。依頼した側は再割り当てできませんが、要求をキャンセルしてフローの承認者を変更して再実行できます。恒常的な不在に備えるなら、承認者を個人1名に固定せず複数名やグループへ送る設計にしておくと詰まりにくくなります。フロー自体の所有者の退職に備えて、共同所有者を最初から設定しておくことも重要です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。