SharePoint×Teams×Power Automate 承認フロー構築ガイド 2026：申請データ基盤・複雑要件対応

ビジネスの意思決定を加速させるため、Microsoft 365（以下M365）を活用した「承認フローのデジタル化」は、もはやIT部門だけの課題ではありません。SharePoint、Teams、Power Automateの3層構造を正しく組み合わせることで、従来の紙やメールによる申請の停滞を解消し、業務効率を劇的に向上させることが可能です。

本ガイドでは、実務者が直面する「API制限」「権限設計」「トラブルシューティング」に深く踏み込み、公式サイトのスペックに基づいた確かな構築手法を解説します。

SharePoint×Teams×Power Automate承認フロー構築の設計思想

承認フローを構築する際、単に「動けば良い」という設計では、組織変更や申請件数の増加に耐えられません。M365のエコシステムを最大限に活かすには、各ツールの役割を明確に分担させる「責務の分離」が重要です。

Microsoft 365連携が選ばれる理由とコストメリット

最大のメリットは、既にM365（Business Standard以上等）を導入済みであれば、追加のライセンス費用を最小限に抑えて「カスタムワークフロー」を構築できる点にあります。特にTeamsとの連携は強力で、承認者が専用アプリを開くことなく、チャット画面からワンクリックで決裁を完了できる利便性は、他の専用ツールにはない強みです。

Microsoftの公式事例によれば、アサヒグループホールディングスではPower Platformを活用した業務アプリの内製化により、グループ全体で大きな業務効率化を実現しています。

【公式事例URL】

アサヒグループホールディングス：Power Platform 活用事例

専用ワークフロー製品との比較

Power Automateによる自作フローと、バクラクやマネーフォワード等の専用SaaSを比較検討する際は、以下の表を参考にしてください。

承認フロー構築ツールの比較

比較項目	Power Automate (M365)	専用SaaS (バクラク/マネーフォワード等)
初期費用	0円 (ライセンス内)	数万円〜
柔軟性	極めて高い（自社開発）	中（標準機能の範囲内）
電帳法対応	設定次第（自前で要件定義）	標準対応（JIIMA認証あり）
メンテナンス	自社IT担当が必要	ベンダーが自動アップデート

関連記事：【徹底比較】バクラク vs freee支出管理。中堅企業が「経費精算・稟議」を会計ソフトと分ける本当の理由

【準備編】SharePointリストによる申請データ基盤の構築

承認フローの「データベース」となるのがSharePointリストです。ここでの設計が、後の自動化の成否を分けます。

入力漏れを防ぐ「列の型」と「バリデーション」の設計

申請の不備による差し戻しを減らすため、以下の設定を推奨します。

• 選択肢列の活用： 「経費区分」や「申請種別」は自由入力ではなく選択肢に限定し、集計を容易にします。
• 数値列の範囲制限： 「金額」列には最小値・最大値を設定し、桁間違いを防止します。
• 必須項目の設定： 申請に必要な情報は全て「この列に情報が含まれている必要があります」を「はい」に設定します。

添付ファイルの保存場所と権限管理の最適解

SharePointリストに添付されたファイルは、既定でリストアイテムの一部として保存されますが、監査証跡として長期保存が必要な場合は、Power Automateを用いて「特定のドキュメントライブラリ」へ自動移動させる設計が理想的です。これにより、承認後のファイルに「読み取り専用」権限を付与し、改ざんを防止できます。

SharePoint・Teams承認フローの構築、運用ルール整備まで支援できますAurant のグループウェア支援は、Microsoft 365 の導入・移行設計から社員研修、運用ルールの整備・定着までを一貫して支援します。✓ 導入・移行の設計✓ 社員研修と定着支援✓ 運用ルールの整備グループウェア支援を見る →

【構築編】Power Automateによる承認フローのステップバイステップ

次に、具体的なフロー構築手順を解説します。ここでは、最も汎用的な「アイテム作成をトリガーとした承認」を例に取ります。

ステップ1：トリガーの設定

Power Automateで「自動化したクラウドフロー」を作成し、トリガーに [SharePoint – アイテムが作成されたとき] を選択します。サイトのアドレスとリスト名を入力する際、リスト名が表示されない場合は「カスタム値の入力」でリストのGUIDまたは内部名を指定してください。

ステップ2：承認アクションの使い分け

アクション [承認 – 開始して承認を待機] を追加します。ここで重要なのが「承認の種類」の選択です。

• 全員の承認が必要： 全員の「承認」が揃わないと次のステップへ進みません。誰か一人が「拒否」した時点でフローは終了（または拒否ルート）となります。
• 最初の応答： 複数人に通知を送り、誰か一人が反応した時点で決裁が完了します。

ステップ3：Teams通知とアダプティブカード

承認アクションを配置すると、承認者にはTeamsの「承認」アプリから通知が飛びます。さらに、Teamsチャネルへ詳細情報を投稿したい場合は [チャットまたはチャネルにアダプティブカードを投稿する] アクションを組み合わせることで、申請内容（金額や理由）をリッチなUIで表示できます。

【応用編】実務で直面する複雑な要件への対応策

単純な1ステップの承認では解決できない、実務特有の要件を自動化に落とし込みます。

条件分岐：金額や部門に応じた動的ルート

たとえば「10万円以上の場合は部長承認、それ未満は課長承認」というルートを作成する場合、[条件] コントロールを使用します。
SharePointの「金額」列を動的なコンテンツから選択し、「100000 以上」という条件で分岐させます。

期限切れ・リマインダーの設定

承認が放置される問題は、[実行条件の構成] を活用して解決します。
承認アクションの直後に「遅延（3日間）」を設定し、その後「承認がまだ完了していない場合」のみ、リマインダーを再送するループ（Do until）を構築します。これにより、督促作業を自動化できます。

関連記事：Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド

【運用編】トラブルシューティングとAPI制限の回避

運用開始後に遭遇する「フローが動かない」「エラーで止まる」といった事態を未然に防ぐ知識は不可欠です。

フローが動かない時のログ確認手順

Power Automateの管理画面にある「実行履歴」を必ず確認してください。エラー箇所は赤色の感嘆符で表示されます。よくあるエラー「BadRequest」は、SharePointの内部名（英数字）と表示名（日本語）の乖離によるスキーマ不一致が原因であることが多いです。

リクエスト制限（API制限）を突破しないための設計

Power Automateには、24時間あたりのアクション実行数に制限があります。
【公式URL】Power Automate の制限と構成

• 無料版/シード版： 1ユーザーあたり 6,000 リクエスト/日（2024年4月現在の目安）
• Per Userプラン： 40,000 リクエスト/日

大規模な組織で「1分おきにデータをチェックする」ようなフローを作ると、すぐに制限に達します。回避策として、トリガーの「分割（Split On）」設定を有効にするか、子フロー（Child Flow）に処理を分散させる設計を推奨します。

メンテナンス性を高める「子フロー」の活用

複雑な条件分岐が続くフローは、1枚のキャンバスに描くと可読性が著しく低下します。承認後の「会計ソフトへのデータ連携」などは、別のフロー（子フロー）として切り出し、親フローから呼び出す形にすることで、機能ごとのデバッグが容易になります。

関連記事：SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方（事例付）

よくある質問（SharePoint × Teams × Power Automate 承認フロー）

まとめ：自社開発か外部SaaSかの判断基準

SharePointとPower Automateによる構築は、コストを抑えつつ「自社独自の商習慣」にフィットしたフローを作れる点が魅力です。しかし、API制限やメンテナンス工数を考慮すると、以下のような判断基準が適切です。

• 内製が向いているケース： ライセンス費を抑えたい、複雑な独自ルールがある、IT担当者が保守に時間を割ける。
• 外部SaaS（バクラク等）が向いているケース： 導入スピードを最優先する、電帳法・インボイス制度への完全対応をベンダー任せにしたい。

自社の要件を整理し、M365のポテンシャルを最大限に引き出す設計を行うことが、真の業務改善への第一歩となります。

承認フロー複雑度・組織規模別 × Power Automate承認フロー設計パターン × 実務運用の落とし穴と対策 早見表

前のセクションでSharePoint×Teams×Power Automateによる承認フロー構築の設計・構築・応用ステップを説明しましたが、「シンプル1段階承認」「多段階承認」「条件分岐承認」「複数部門横断・マトリクス承認」では最適なPower Automate設計パターンと運用上の落とし穴が異なります。承認フローの複雑度に合わない設計は「承認が途中で止まる」「通知が届かない」「誰が承認すべきか分からない」という運用トラブルを引き起こします。承認フロー複雑度・組織規模別の設計パターンと実務上の注意点を整理しました。

承認フローの複雑度・組織規模	Power Automate承認フローの推奨設計パターン	実務運用で発生しやすい落とし穴とその原因	安定稼働のための設計上の対策と確認ポイント
シンプル1段階承認 （10〜30名以下の部署・1名の上司が全申請を承認・経費精算・有休申請等）	シンプル1段階承認のPower Automate設計は「SharePointリストで申請データを受け取る→承認者1名にTeamsまたはOutlookで承認依頼通知を送信→承認または却下の結果をSharePointリストに書き戻す→申請者に結果を通知する」という最小構成のフローが最も推奨。Power AutomateのApproval ConnectorのアクションタイプはStart and wait for an approval（単一承認者）を使い、承認者のメールアドレスをSharePointリストの「上長メールアドレス」フィールドから動的に取得する設計にすることで部門異動・人事変更時のフロー変更コストを最小化できる。1段階承認でもリマインダー機能（承認依頼後3営業日経過で自動リマインド）を実装することで「承認忘れ」による申請の停滞を防ぐ設計が長期運用の安定性を高める	1段階承認で発生しやすい落とし穴は「承認者が長期休暇・病欠・退職した際に承認が止まってフローが永遠に待ち続ける状態（承認タイムアウトが設定されていない）」と「承認者がTeamsやOutlookの通知を見逃して申請が何週間も放置される（リマインダーなしの設計）」の2点。長期待機が発生するとPower Automateのフロー実行履歴が「実行中」のままフロー数の上限に近づく問題も発生する。また承認者が退職してAzure ADからアカウントが削除されると、そのアカウントに紐づく承認コネクタが機能停止する問題が退職後に発覚するケースが多い	1段階承認の安定稼働対策は①Power AutomateのApprovalアクションにタイムアウト設定（ISO 8601形式でP7D等）を必ず設定してタイムアウト後の処理（申請者への通知・代理承認者への再送）を設計する②承認者の代理設定（代行承認者）をSharePointリストに「代理承認者メールアドレス」フィールドとして追加して長期不在時に代理承認者に自動切り替えする条件分岐を実装する③承認者のAzure ADアカウントが削除された際のフロー停止を防ぐために承認コネクタの接続アカウントは「サービスアカウント（退職しない共用アカウント）」を使う設計を採用する④月次でPower Automateの実行履歴を確認して「実行中のまま停止しているフロー」がないかを定期監視するの4点
多段階承認 （部門承認→部長承認→役員承認等・金額・重要度によってルートが変わる）	多段階承認のPower Automate設計は「Start and wait for an approval（シリアル承認）をApply to eachループ内で使って承認者リストを順番に処理する設計」が最も保守性が高い。承認者リストをSharePointの「承認者テーブル（承認レベル・承認者メール・承認順序）」として外部管理することでフローを修正せずに承認ルートを変更できる設計になる。金額によって承認段階数が変わる場合（30万円未満は部長まで・30万円以上は役員まで等）はSwitch条件またはIf条件で「承認者配列の件数」を動的に決定するフローが保守性と拡張性を両立できる設計。多段階承認では各段階でのリジェクト時の処理（差し戻し先・修正依頼の通知フロー）を全段階分設計しないと「リジェクトされた申請がどこに戻るか分からない」問題が発生する	多段階承認で発生しやすい落とし穴は「前の段階でリジェクトされた申請の修正・再申請フローを設計していなかったことで申請者が再申請方法を把握できない状態」と「承認者が代替者なしで休暇中に申請が停滞して後段の承認者が待ちになる多段階詰まり問題」の2点。また多段階承認でPower AutomateのAPI制限（1分あたりの呼び出し数上限）に達するケースがある。多段階承認が連続で大量に発行される場合（月末の経費精算集中期等）はフローのトリガーにキューイング（Delay Untilアクションで実行を分散させる）を設定しないとフロー実行エラーが頻発する状態になる	多段階承認の安定稼働対策は①各承認段階のApprovalアクションに個別のタイムアウト設定を設けてタイムアウト時の「代理承認者への自動エスカレーション」を実装する②リジェクト時の再申請フローを申請フローと同じSharePointリストで管理して「差し戻し中」ステータスが申請者に可視化されるダッシュボードをSharePointまたはPower BIで実装する③多段階承認フローのメンテナンスはフローの「コピーと修正」ではなくPower Automate環境のソリューション管理（ソリューションとして一元管理・DevOpsパイプラインでのデプロイ管理）を採用する④月末等の申請集中期を予測してPower AutomateのトリガーにScheduled Triggerで申請受付を時間分散させる設計を検討するの4点
条件分岐承認 （申請金額・部門・種別によって承認者・承認ルートが動的に変わる）	条件分岐承認のPower Automate設計は「承認ルーティングロジックをPower Automateのフロー内に直接ハードコードせず、SharePointの承認ルーティングテーブル（条件・承認者・承認段階数）として外部化してフローから参照する設計」が長期保守性を確保する最も重要な設計原則。具体的には「申請種別・金額範囲・部門コード」の組み合わせで承認者リストを返す承認ルーティングマスターをSharePointリストに作成し、Power AutomateがGet itemsアクションでフィルタリングして動的に承認者を決定するフローにする。条件分岐承認では「フローが複雑になるほどエラー発生箇所の特定が困難になる」ため、各分岐の入口と出口でSharePointのステータスフィールドを更新するログ記録設計を実装する	条件分岐承認で発生しやすい落とし穴は「条件ロジックをフローの中にIF-ELSE-IFとしてネストし続けた結果、フローが巨大化して読めなくなり誰もメンテナンスできなくなること（スパゲッティフロー問題）」と「条件の境界値（ちょうど30万円の申請はどちらのルートになるか等）の設計が曖昧なままフローを作成してトラブルになること」の2点。また申請内容に「複数の条件が交差する申請（海外出張かつ100万円以上）」が発生した場合の優先ルールが設計されていないと承認者決定が矛盾するケースが発生する。条件分岐承認フローは本番運用前にすべての条件ブランチをテストデータで検証する境界値テストが必須	条件分岐承認の安定稼働対策は①承認ルーティングマスターをSharePointで管理して条件変更はフロー修正ではなくSharePointリストの更新で対応できる設計にすることで業務担当者がフローに触れずに条件変更できる運用体制を確立する②フロー内のアクション名に「条件」「ルート番号」「処理内容」を含む命名規則（例：「承認者取得/ルートA/50万円未満部長止まり」）を設定してフロー図を読むだけで全条件分岐の意図が理解できるドキュメント設計にする③すべての条件ブランチの組み合わせをカバーするテストシナリオ一覧を設計書として管理してフロー変更時のリグレッションテストチェックリストとして運用する④条件分岐が増えて複雑化した場合は1つのフローを「条件振り分けフロー（子フローを呼び出す）」と「承認処理フロー（汎用化した子フロー）」に分割する設計リファクタリングを検討するの4点
複数部門横断・マトリクス承認 （複数部門の承認が必要・並列承認・全員の合意が条件等）	複数部門横断・マトリクス承認のPower Automate設計は「Start and wait for an approval（並列承認・Everyone must approve）を使って複数部門の承認者に同時に承認依頼を送り、全員の承認が揃った時点でフローを進める並列承認設計」が最も効果的。Power AutomateのApproval ConnectorのTypeをEveryoneまたはFirst to respondの2種類を使い分けて「全員承認が必要な稟議案件」と「誰か1名が承認すればよい緊急申請」でフロー設計を分ける。複数部門横断承認では「どの部門が何を承認するか」の責務設計（承認する観点・承認権限の根拠）をSharePointの承認者テーブルに明記して承認者側が「なぜ自分に来たか」を理解できる通知設計にすることが承認品質を確保する最重要設計	複数部門横断承認で発生しやすい落とし穴は「並列承認で1名がリジェクトした際の残りの承認者への処理（承認依頼のキャンセル通知・リジェクト理由の共有）が設計されておらず承認者が永遠に承認依頼が表示され続ける状態になること」と「全員承認条件で1名が長期不在の場合にフロー全体が無期限停止するボトルネック問題」の2点。また複数部門の承認者が同時に同じ申請を見ると「誰かが承認したからもうすぐ終わる」と思って自分の承認を後回しにする「承認の先送り心理」が発生して全体の承認完了が遅延するケースが多い	複数部門横断承認の安定稼働対策は①並列承認でリジェクトが発生した場合は残りの承認者への「承認依頼キャンセル通知（誰がリジェクトしてフローが止まったかの通知）」をフローに組み込んで承認者に無用な作業が発生しないように設計する②全員承認条件の並列承認フローには「最終承認期限（全員の承認期限）」を設定してタイムアウト時は申請者と全承認者に「期限超過による差し戻し通知」を送るフローを実装する③各承認者の承認完了状況をSharePointリストにリアルタイムで記録して申請者・管理者が「誰が未承認か」をSharePointビューまたはPower Appsで確認できる進捗可視化設計を実装する④マトリクス承認の承認ルールは法令・稟議規程に基づいて設計されているか法務・コンプライアンス担当者のレビューを必ず得てから本番稼働させるの4点

この表でPower Automate承認フロー設計において最重要の原則が「承認フローの複雑度が上がるほど『承認ロジックをフロー内にハードコードせず外部テーブルで管理すること』と『全ての異常系（タイムアウト・リジェクト・不在代理）を正常系と同等に設計すること』の2点を設計の出発点にすることで、運用開始後に承認が止まって業務が停滞する問題を構造的に防ぐことができること」です。特にSharePointの承認ルーティングマスターによる動的承認者解決と、タイムアウト時の自動エスカレーション設計は、承認フローが年単位で安定稼働し続けるための最も費用対効果の高い初期投資です。

実務担当者が陥りやすい「運用の盲点」と解決策

構築した承認フローを形骸化させず、組織のインフラとして定着させるためには、技術的な実装以外に「権限」と「ライフサイクル」の設計が不可欠です。現場で頻発するトラブルを未然に防ぐためのチェックポイントをまとめました。

1. 組織変更・人事異動への対応設計

Power Automateのフロー内で「承認者」をメールアドレスで直接指定（ハードコーディング）するのは避けるべきです。異動のたびにフローの編集が必要になり、メンテナンス負荷が爆発するためです。

• 推奨： SharePointの「ユーザー選択」列を参照するか、Office 365 Groupsを活用して「特定のロール（役職）」に紐づく設計にします。
• 注意： 承認者が退職し、アカウントが無効化されると、その人が承認ステップに含まれるフローは「一時停止」状態になります。

2. 「サービスアカウント」でのフロー所有権管理

個人のアカウントでフローを作成すると、その社員の退職・ライセンス削除に伴い、全ての承認フローが停止するリスクがあります。重要な業務フローは「共有所有者」にチームメンバーを追加するか、専用のサービスアカウントで作成・実行することを強く推奨します。

Microsoft 365 ライセンスと承認機能の制約

利用するライセンスプランによって、標準で利用できる範囲が異なります。特に「Dataverse」を利用するかどうかでコスト構造が大きく変わるため、事前の確認が必要です。

プラン別・承認フロー関連の機能差（要確認）

機能・制限	M365 標準ライセンス（Business等）	Power Automate 有償ライセンス
標準コネクタ（SharePoint/Teams）	利用可能（リクエスト制限内）	フル活用可能（高いリクエスト上限）
プレミアムコネクタ（SQL/外部SaaS）	不可（別途購入が必要）	利用可能
承認プロセスの有効期間	最大30日間（タイムアウト）	最大30日間（共通の制限）
Dataverse（高度なデータ管理）	限定的な利用のみ	本格的な利用が可能

※30日を超える長期の承認が必要な場合は、フローを一時終了させ、再開用の子フローを呼び出すといった高度な設計が必要になります。

公式リファレンスとさらなる自動化へのステップ

承認アクションの詳細な仕様や、タイムアウト時の挙動については、以下のMicrosoft公式ドキュメントを常に最新のリファレンスとして参照してください。

【公式ドキュメント】
Power Automate での承認の概要

承認フローのデジタル化が進むと、次に課題となるのが「アカウントの棚卸し」や「SaaS間のID連携」です。フローの利便性を高める一方で、ガバナンスを維持するためには、ID管理の自動化もセットで検討することをお勧めします。

関連記事：SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

📚 関連資料

このトピックについて、より詳しく学びたい方は以下の無料資料をご参照ください：