SharePoint×Teams×Power Automateで実現！社内申請の承認フローを最短で整備し、DX推進と業務効率化を加速する方法

ビジネスの意思決定を加速させるため、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を用いて「特定のドキュメントライブラリ」へ自動移動させる設計が理想的です。これにより、承認後のファイルに「読み取り専用」権限を付与し、改ざんを防止できます。

【構築編】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コストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方（事例付）

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

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

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

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

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

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

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・ジョーシスを活用した自動化アーキテクチャ

📚 関連資料

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