Power Automate の承認フローは、使いこなすまでの道のりが意外と長いです。基本の作り方を覚えた後も、申請者名が自分の名前になってしまう、30日で勝手に止まる、コメントが取得できない、といった問題が次々と出てきます。
この記事では、承認フローの全体像を把握するためのハブ記事として、作り方の種類・通知先の選び方・よくあるトラブルと解決策・上級テクニックまでを一気に整理します。それぞれの詳細は各サテライト記事で解説しているので、気になるテーマに合わせて読み進めてください。
承認フローの基本構造
Power Automate の承認フローは、承認コネクタが提供する承認の開始と待機アクションを中心に組み立てます。このアクションが承認者に通知を送り、承認者がボタンを押すまでフローが一時停止し、応答を受け取ったら後続の処理（記録・通知・ステータス更新など）に進む、という流れです。
トリガーの種類は大きく2つに分かれます。Forms の回答をトリガーにするフォーム型と、SharePoint リストのアイテム作成・変更をトリガーにするリスト型です。どちらを選ぶかは申請の入口（申請者がどこで入力するか）によって決まります。
| 種類 | 申請入口 | 向いているケース |
|---|---|---|
| フォーム型 | Microsoft Forms | 社外からの申請・シンプルな1回限りの申請 |
| リスト型 | SharePoint リスト | ステータス管理が必要・証跡を一覧で管理したい |
| Power Apps型 | Power Apps アプリ | 入力UIをカスタマイズしたい・複雑な申請フォーム |
Power Automate 全体の入門についてはPower Automate 入門——変数・データ処理・通知・デバッグの全体マップで解説しています。承認フローを作る前にフロー全体の基礎を押さえておくと、設計がスムーズになります。
承認の種類：1人・並列・多段
承認コネクタには、承認の種類として単一の承認・全員の承認・最初に応答した人の承認・連続した承認の4種類があります。フローの要件に合わせて選びます。
単一承認と全員承認
単一の承認は、承認者として指定した誰か1人が応答すればフローが進みます。複数人を指定した場合は最初に応答した人の判断が採用されます。全員の承認は、指定した全員が承認しないと次に進みません。役員全員の合意が必要な稟議などに適しています。
連続した承認（多段承認）
連続した承認は、承認者が複数のステップに分かれて順番に承認していく多段承認を実現します。第1承認者が承認したら第2承認者に通知が届く、という直列フローを1つのアクションで組めます。途中で誰かが拒否した時点でフローが終了します。詳しくは多段承認の設定方法と連続した承認の実装で解説しています。
通知先：Teams か Outlook か
承認依頼の通知先は Teams と Outlook の2択です。承認者が Teams を日常的に使っている組織では Teams 通知が圧倒的に反応が早く、メール文化が根強い組織では Outlook 通知のほうが自然に受け取ってもらえます。
どちらを選ぶべきか、それぞれのメリット・デメリット・ハイブリッド設計のアイデアはTeams と Outlook どっちが正解？最適な通知設計でまとめています。
フォーム型承認の作り方
初心者が最初に試すなら、Microsoft Forms と承認フローを組み合わせるフォーム型がおすすめです。Power Automate にはテンプレートが用意されており、Forms の回答を承認して Excel 台帳に記録する、という一連の流れをゼロから作らずに始められます。
テンプレートの使い方・接続設定のポイント・判定ロジックの修正まで、テンプレートで始める Forms 承認フロー作成法で丁寧に解説しています。承認フローを初めて作る方はここから読んでください。
リスト型承認の作り方
証跡管理や複数申請の一覧把握が必要な場合は、SharePoint リストをデータソースにするリスト型が向いています。申請ごとにステータス列を持たせ、フローがステータスを自動更新する設計にすることで、承認待ち・承認済み・却下の状態を一覧で管理できます。
ステータス列の設計・催促機能・取り下げ機能の実装まで、SharePoint リストで構築する本格承認ワークフローで解説しています。
よくあるトラブルと解決策
承認依頼の要求元が開発者の名前になる
自動トリガーで起動する承認フローで起きやすい問題です。承認コネクタの要求元プロパティを指定していないと、コネクタ接続に使われているアカウント（フロー作成者）の名前が表示されてしまいます。トリガーから申請者のメールアドレスを取得して要求元に差し込む設定で解決します。詳細は承認依頼の要求元が開発者になる問題の解決法を参照してください。
30日でフローが止まる
承認者が30日以内に応答しないと、フローが強制終了してエラーになります。役員承認や長期休暇をまたぐ申請で特に起きやすいです。次の実行条件でタイムアウト時の通知を送る設定と、Do Until ループを使った高度な設計の両方を承認フロー30日の期限切れ対策で解説しています。
承認依頼の詳細欄を読みやすくする
承認依頼の詳細欄に申請内容をベタ書きすると、承認者の画面では改行なし・装飾なしの読みにくいテキストになります。Markdown 記法（太字・改行・箇条書き・リンク）と concat 関数を組み合わせることで、承認者が判断しやすい見やすい詳細欄を作れます。
実践的なテンプレートとデバッグ手順は承認依頼を読みやすく装飾する Markdown 実践術にまとめています。
承認コメント・履歴を記録に残す
承認者のコメントを後から参照したい、誰がいつ承認したかを記録したい、という要件は実務でよく出てきます。承認データは Dataverse の4つの標準テーブルに保存されており、コメントは承認応答テーブルを参照しないと取得できません。
Dataverse テーブルの構造・コメント取得の方法・プレミアムライセンスの必要性については承認コネクタの裏側と Dataverse テーブルの仕組みで詳しく解説しています。
まとめ：読む順番のガイド
承認フローに初めて取り組む方は、まずフォーム型承認の記事から手を動かして動くフローを作り、その後でリスト型・多段承認と段階的に発展させていくのが着実です。トラブルが出たら要求元問題・30日制限の記事を参照してください。
運用が安定してきたら、詳細欄の Markdown 装飾・通知先の設計・Dataverse の裏側という順で深掘りしていくと、承認フローの設計力が一段上がります。市民開発は一度に完璧を目指さず、動くものを作りながら改善していくのが長続きのコツです。
