【Power Automate】その承認フロー、監査に耐えられますか？｜非エンジニアでも作れる「壊れない」設計
はじめに
「Power Automateを使えば、プログラミングなしで承認フローが作れる」
これは事実ですが、半分は幻想です。
多くの入門記事にある「簡単なフロー」をそのまま実務に投入すると、以下のような地獄が待っています。
- 承認者が休暇に入ると業務が完全にストップする
- 数ヶ月前の承認履歴がどこにも残っておらず、監査で指摘される
- 申請内容が複雑になると、フローのメンテナンスが不可能になる
本記事では、IT歴20年・M365サポート7年の現場経験から、「非エンジニアでも作れるが、実務で絶対に壊れない」 堅牢な承認フローの構築手順を解説します。
この記事の対象者
- Power Automate初心者〜中級者
- 社内の承認フローを自動化したい人
- 「動くフロー」ではなく「運用できるフロー」を作りたい人
前提条件
- Microsoft 365 Business Basic 以上
- Power Automate の標準ライセンス（M365に含まれる）
- SharePoint サイトの編集権限
所要時間
約45分（設計理解含む）
実務投入前に知っておくべき「3つの不都合な真実」
初心者が陥る「動けばいい」レベルのフローには、以下の致命的な欠陥があります。
1. 履歴の揮発性
標準機能の通知だけでは、誰がいつ承認したかの証跡が「メールの中」にしか残りません。
メールが削除されたら？退職者のメールボックスが消えたら？
→ SharePointリストへの自動記録は必須です。
2. 例外処理の欠如
- 金額が1円でもオーバーしたら？
- 承認者が退職したら？
- 申請者が部署異動したら？
これらの例外への備えがないフローは、運用開始後に「技術的負債」に変わります。
3. 通知の埋没
メール通知だけでは、多忙な上司の受信トレイに埋もれます。
Teamsへの二重通知や、リマインダーの自動化までが「実務レベル」の最低ラインです。
Step 1: 監査に耐える「SharePointリスト」の設計
なぜSharePointリストなのか
| 保存先 | 履歴管理 | 検索性 | 監査対応 | 自動化連携 |
|---|---|---|---|---|
| メール | ✗ | ✗ | ✗ | ✗ |
| Excel | △ | △ | △ | △ |
| SharePointリスト | ◎ | ◎ | ◎ | ◎ |
1-1. リストの作成
- SharePointサイトを開く
- 「新規」→「リスト」→「空白のリスト」
- リスト名：
経費申請
1-2. 列の設計（理由付き）
| 列名 | 種類 | 必須 | なぜ必要か |
|---|---|---|---|
| 申請者名 | 1行テキスト | ✓ | 申請者の特定 |
| 申請日 | 日付 | ✓ | 申請タイミングの記録（既定値=今日） |
| 金額 | 数値 | ✓ | 承認ルート分岐の判定基準 |
| 申請理由 | 複数行テキスト | ✓ | 承認判断の根拠 |
| 承認者 | ユーザー | - | 動的に取得するため後述 |
| 承認ステータス | 選択肢 | ✓ | 進捗の可視化（申請中/承認済/却下/差戻し） |
| 承認日時 | 日付と時刻 | - | 監査証跡として必須 |
| 承認コメント | 複数行テキスト | - | 却下理由の記録（トラブル回避） |
「承認コメント」列を省略するな
却下時に「なぜ却下されたか」の記録がないと、後から「言った言わない」のトラブルになる。監査でも指摘されるポイント。
1-3. 列の追加手順
- リストを開く
- 「+ 列の追加」をクリック
- 列の種類を選択
- 列名と設定を入力
- 「保存」
Step 2: 堅牢なフローの構築
2-1. Power Automateを開く
- https://make.powerautomate.com にアクセス
- 「作成」→「自動化したクラウドフロー」
2-2. トリガーの設定
トリガー： 「アイテムが作成されたとき」（SharePoint）
| 設定項目 | 値 |
|---|---|
| サイトのアドレス | SharePointサイトのURL |
| リスト名 | 経費申請 |
2-3. 金額による承認者分岐
重要：金額の閾値は「会社の規定」に合わせる
この記事では1万円を例にしていますが、実際には自社の決裁規程に従ってください。将来的には「変数」や「構成テーブル」で管理することを推奨します。
「条件」アクションを追加：
条件: 金額が 10000 より小さい
├─ はいの場合 → 課長に承認依頼
└─ いいえの場合 → 部長に承認依頼
設定方法：
- 「条件」アクションを追加
- 左辺：動的なコンテンツから「金額」を選択
- 演算子：「次の値より小さい」
- 右辺：
10000
2-4. 承認アクションの設定
「はいの場合」に「開始して承認を待機」を追加：
| 設定項目 | 値 |
|---|---|
| 承認の種類 | 承認/拒否 - 最初の応答 |
| タイトル | 【経費申請】@{triggerOutputs()?['body/申請者名']}様からの申請 |
| 担当者 | ※下記参照 |
| 詳細 | 下記参照 |
詳細欄の記述例：
申請者: @{triggerOutputs()?['body/申請者名']}
金額: @{triggerOutputs()?['body/金額']}円
申請理由: @{triggerOutputs()?['body/申請理由']}
※このメールに返信せず、承認ボタンから操作してください。
承認者のメールアドレスを「直書き」するな
kacho@example.com のようにハードコードすると、人事異動のたびにフローを修正する羽目になる。
推奨： SharePointリストに「承認者マスタ」を作成し、そこから動的に取得する。
2-5. 承認結果の処理
承認アクションの後に、さらに条件分岐を追加：
条件: 結果が「Approve」と等しい
├─ はいの場合
│ ├─ SharePointを更新（承認済）
│ ├─ 承認日時を記録 ← 監査対応
│ └─ 申請者に承認通知
└─ いいえの場合
├─ SharePointを更新（却下）
├─ 却下コメントを記録 ← トラブル回避
└─ 申請者に却下通知
2-6. SharePointリストの更新
「項目の更新」アクション：
| 設定項目 | 値 |
|---|---|
| サイトのアドレス | （トリガーと同じ） |
| リスト名 | 経費申請 |
| ID | @{triggerOutputs()?['body/ID']} |
| 承認ステータス | 承認済（または却下） |
| 承認日時 | @{utcNow()} |
| 承認コメント | @{outputs('開始して承認を待機')?['body/responses'][0]['comments']} |
2-7. 通知の二重化（メール + Teams）
メール通知だけでは埋もれる。Teamsにも通知を飛ばせ。
「チャットまたはチャネルにメッセージを投稿する」アクションを追加：
| 設定項目 | 値 |
|---|---|
| 投稿先 | Chat with Flow bot |
| 受信者 | 申請者のメールアドレス |
| メッセージ | 経費申請が承認されました。金額: @{triggerOutputs()?['body/金額']}円 |
Step 3: テストと動作確認
3-1. テスト方法
- Power Automateの画面右上「テスト」をクリック
- 「手動」を選択して「テスト」
- SharePointリストに新しいアイテムを追加
- フローが動作するか確認
3-2. 確認ポイント
| 確認項目 | 期待結果 |
|---|---|
| 承認依頼メールが届く | ✓ |
| Teams通知が届く | ✓ |
| 承認後、リストが更新される | ✓ |
| 承認日時が記録される | ✓ |
| 承認コメントが保存される | ✓ |
3-3. よくあるエラーと対処
| エラー | 原因 | 対処 |
|---|---|---|
| 接続エラー | 認証切れ | 接続を再認証 |
| 項目が見つからない | リスト名の誤り | リスト名を確認 |
| 式が無効 | 動的コンテンツの選択ミス | 式を再設定 |
| 承認が届かない | メールアドレスの誤り | 担当者設定を確認 |
応用：プロの現場で求められること
この記事で紹介したのは、あくまで「基本の型」です。
実際のエンタープライズ環境では、さらに以下の対策が必要になります。
1. 複数段階承認
条件: 金額 < 10,000
├─ 課長承認のみ
条件: 金額 < 50,000
├─ 課長承認 → 部長承認
条件: 金額 >= 50,000
└─ 課長承認 → 部長承認 → 役員承認
2. 代理承認設定
承認者が休暇中に業務がストップしないよう、「代理承認者」を設定する仕組み。
SharePointリストに「代理承認者」列を追加し、フロー内で「承認者が不在なら代理者に回す」ロジックを実装。
3. エラーハンドリング
フローが失敗した際、システム管理者に即座にアラートを飛ばす設定。
「スコープ」アクションと「構成済み実行」を使用。
4. リマインダー自動化
3日間放置された承認依頼を、自動でリマインド通知。
完成したフローの全体像
トリガー: SharePointリストにアイテム作成
│
▼
条件: 金額 < 10,000?
│
├─ はい → 承認依頼（課長）
│ │
│ ▼
│ 条件: 承認された?
│ │
│ ├─ はい → リスト更新（承認済）→ 承認通知（メール+Teams）
│ └─ いいえ → リスト更新（却下）→ 却下通知（メール+Teams）
│
└─ いいえ → 承認依頼（部長）
│
▼
条件: 承認された?
│
├─ はい → リスト更新（承認済）→ 承認通知（メール+Teams）
└─ いいえ → リスト更新（却下）→ 却下通知（メール+Teams）
まとめ
Power Automateで承認フローを作ること自体は簡単です。
しかし、「監査に耐える」「運用で壊れない」 フローを作るには、以下が必須です。
| 要件 | 対策 |
|---|---|
| 履歴の永続化 | SharePointリストへの自動記録 |
| 例外処理 | 金額分岐・代理承認・エラーハンドリング |
| 通知の確実性 | メール + Teams の二重通知 |
| メンテナンス性 | 承認者の動的取得・変数管理 |
「やり方を知ること」と「実務でミスなく運用すること」の間には、膨大な工数の差があります。
まずはこの記事の「基本の型」を実装し、自社の要件に合わせて拡張してください。
関連リソース
本記事で紹介した設計の事前チェックに使えるPowerShellスクリプトをGitHubで公開しています。
- MFA設定状況の一括確認
- 非アクティブユーザーの検出
- ライセンス割当状況のエクスポート
もっと体系的に学びたい方へ
本記事の内容は、「属人化ゼロの教科書」の一部を抜粋・再構成したものです。
- 教科書 第1章（無料）
- AIプロンプト5選（無料）