Teamsで承認ワークフローを作る方法｜承認アプリ・テンプレート・Power Automate

2026年4月30日2026年8月14日

【元情シスが直伝】実務で使えるTeams承認ワークフローの作り方！標準機能の限界と自動化のコツ

SkillStack Lab（スキスタ）運営者のスタックです。

Microsoft Teamsを使っていると、「紙の稟議やメール決裁をTeamsへ移せないか」「備品購入や経費申請をTeams上で承認できないか」と考えることがありますよね。

Teamsには「承認（Approvals）」アプリが用意されており、簡単な申請であればPower Automateのフローを一から作らなくても始められます。

一方、申請金額によって課長・部長・役員へ承認ルートを切り替えたり、承認後のデータをSharePointへ自動保存したりする場合は、Power Automateとの組み合わせが必要です。

つまり重要なのは、最初から複雑なワークフローを作ることではありません。

「Teams標準の承認で足りる業務」と「Power Automateまで作り込む業務」を分けることが、運用を複雑にしないポイントです。

この記事では、Teamsの承認アプリ、テンプレート、SharePoint・Microsoft Lists、Power Automateを使った条件分岐まで、実務で使う順番に整理して解説します。

この記事で分かること

Teams標準の承認アプリでできること
承認テンプレートを使って申請項目を統一する方法
標準承認とPower Automateの使い分け
金額によって承認者を変える条件分岐の考え方
30日を超える可能性がある承認フローの注意点
Power Automateの属人化を防ぐ運用方法

Teamsの承認アプリとPower Automateを使った承認ワークフローの作り方を解説するタイトル画像

Teamsで承認ワークフローを作る4つの方法

Teamsを使った承認といっても、すべて同じ仕組みではありません。

まずは、目的によって次の4つに分けて考えると整理しやすくなります。

方法	向いている用途	難易度
Teams承認アプリ	その都度行う簡単な確認・承認	低い
承認テンプレート	備品購入・出張・社内申請など定型業務	低い
Lists・SharePointの承認	一覧データや文書と承認結果を紐づけたい業務	低〜中
Power Automate	条件分岐・多段階承認・通知・データ連携	中〜高

「Teamsで承認したい」というだけなら、いきなりPower Automateを開く必要はありません。

まず標準承認を試し、足りない要件が見つかった段階でPower Automateへ進む方が、構築と保守の負担を抑えられます。

Teams標準の承認アプリでワークフローを作る方法

最も簡単なのが、Teamsに用意されている「承認（Approvals）」アプリです。

承認アプリから新しい要求を作成するほか、Teamsのチャットやチャネルから直接承認を作成することもできます。

Microsoftの現在の仕様は、Teamsのチャット・チャネルから承認を作成するMicrosoft Learnでも確認できます。

承認アプリの基本的な作り方

Teamsを開く
「アプリ」から「承認」を検索して開く
「新しい承認要求」を選択する
タイトル・詳細・承認者を入力する
必要に応じてファイルを添付する
承認順序や全員承認の要否を設定する
送信する

送信後は、承認アプリの「送信済み」から進行状況を確認できます。

承認者側には承認要求が表示され、「承認」「拒否」などのアクションを実行できます。

チャットから承認を作成した場合は、その会話に参加しているユーザーが承認者の候補になります。

また、添付したファイルはTeamsで通常ファイル共有するときと同様に、OneDriveまたはSharePointへ保存されます。

複数人の承認と承認順序にも対応する

以前のTeams承認は「簡単な確認だけ」という印象を持たれがちでしたが、現在の基本承認では複数の承認者を指定できます。

また、申請作成時に承認順序を設定したり、複数人全員の承認を要求したりすることもできます。

設定	使い方
1人へ承認依頼	上司による簡単な確認
複数人のうち1人が応答	担当者グループの誰か1人が判断すればよい場合
全員の応答を要求	関係者全員の確認が必要な場合
承認順序を指定	上司から順番に確認してもらう簡単な承認

そのため、「上司→部長」のような比較的シンプルな承認であれば、まず標準承認で要件を満たせないか確認する価値があります。

承認順序と条件分岐は別物です

順番に承認してもらうことはできても、「10万円以上なら部長を追加する」「申請者の所属部署によって承認先を変える」といった入力内容による動的な分岐は別です。

こうした処理はPower Automateで組み立てます。

Teamsモバイルでも承認を確認できる

Teamsの承認アプリは、管理者のアプリポリシーによってデスクトップだけでなくモバイルのアプリバーにも配置できます。

外出や出張が多い管理職でも、パソコンへ戻るまで申請を放置しなくてよいことは、紙の稟議から移行するメリットの一つです。

ただし、組織のTeamsアプリポリシーや端末管理設定によって利用できるアプリは異なるため、全社展開前に実際のスマートフォンで動作を確認してください。

Teamsの承認テンプレートで申請を標準化する

自由入力の承認は手軽ですが、会社の定型業務として使うと「必要な項目が入力されていない」という問題が起こります。

そこで使えるのが承認テンプレートです。

テンプレートでは、あらかじめ必要な入力項目を設定した承認フォームを用意できます。

Microsoftも、割引申請や経費申請などをテンプレートの用途例として案内しています。

テンプレートに向いている申請

備品購入申請
出張申請
在宅勤務申請
名刺発注
システム利用申請
社外への情報公開確認
値引き申請

入力項目を統一しておけば、「金額を書き忘れた」「利用目的が分からない」といった差し戻しを減らせます。

チーム向けと組織全体向けを使い分ける

現在のTeams承認では、チーム所有者が自分のチーム向けテンプレートを作成できます。

一方、Teams管理者などは組織全体で利用するテンプレートを管理できます。

そのため、すべてのテンプレートを全社員へ公開する必要はありません。

公開範囲	用途例
特定チーム	情報システム部門だけで使うアクセス権申請
特定部署	営業部独自の値引き申請
組織全体	全社員が利用する共通申請

なお、承認テンプレートの設定にはMicrosoft Formsも利用されます。Microsoftの管理者向け資料では、テンプレート作成者にはFormsのライセンスも必要とされています。

最新の管理要件は、Microsoft Teamsの承認アプリ管理ドキュメントで確認してください。

Teamsの承認履歴とデータ保存の仕組み

会社で承認を使うなら、「ボタンを押せるか」だけでなく、承認データがどこへ保存されるのかも確認しておきたいところです。

Teamsの承認アプリから作成された承認は、組織の既定のMicrosoft Dataverse環境へ保存されます。

また、承認アプリでは自分が送った要求と受け取った要求を一覧で確認できます。

テンプレートではFormsにもデータが保存される

承認テンプレートを利用した場合、承認のタイトルや詳細、テンプレートIDなどはDataverseに保存され、フォームへの回答はMicrosoft Formsにも保存されます。

そのため、会社の正式な申請基盤として採用する場合は、Teamsの画面だけを見るのではなく、データ保存・保持・監査の要件も確認しておきましょう。

Microsoft Purviewの監査ログも確認できる

Microsoftの管理者向け資料では、承認アプリに関するアクティビティをMicrosoft Purviewの監査から確認できることも案内されています。

ただし、「Teams承認を使えば自社の内部統制要件を自動的に満たす」という意味ではありません。

会社によって必要な保存期間、承認権限、改訂履歴、証跡、監査方法は異なるため、正式な稟議システムとして採用する場合は自社要件との照合が必要です。

チャット履歴だけを承認台帳にしない

経理・購買・人事など、後から一覧で検索・集計したい申請では、承認結果をSharePointリストなどの構造化された場所へ保存する設計も検討しましょう。

Lists・SharePointの承認を使う方法もある

2026年時点では、Microsoft ListsやSharePointのリスト・ドキュメントライブラリから承認を要求し、その承認をTeamsの承認アプリで処理する方法もあります。

これは、「申請データを一覧表として管理したい」という業務と相性があります。

たとえば備品購入申請なら、次のような列を持つリストを作成できます。

申請者
申請日
購入品
金額
利用目的
承認状況

データ本体と承認を同じ項目に紐づけられるため、後から一覧表示や検索をしたい場合は、チャットだけで完結する承認より管理しやすいケースがあります。

TeamsとSharePointのデータ保存の違いについては、SharePointとTeamsの違いと使い分けでも詳しく解説しています。

Teams標準承認では足りないケース

標準承認は以前より柔軟になっていますが、すべての社内稟議を置き換えられるわけではありません。

特に次のような要件がある場合はPower Automateを検討します。

申請金額によって承認者を変えたい
申請者の所属部署によって承認先を変えたい
一次承認後に別部署へ回したい
承認後にSharePointへ自動記録したい
否認された場合だけ担当者へ通知したい
期限前に自動リマインドしたい
他のMicrosoft 365サービスと連携したい

Power AutomateでTeams承認ワークフローを作る方法

Power Automateを利用すると、「何かが起きたら承認を開始し、その結果に応じて次の処理を実行する」という一連の業務を自動化できます。

申請フォームとしてMicrosoft Formsを利用する構成もありますが、一覧管理や後からのデータ利用を重視するならSharePointリストを起点にする方法もあります。

基本構成は5ステップで考える

申請データを受け取る
条件を判定する
承認要求を作成する
承認・否認の結果によって処理を分ける
結果を保存して関係者へ通知する

申請データ、Power Automate、Teams承認、SharePointへの記録を組み合わせるワークフロー設計図

金額によって承認ルートを変える

Power Automateが必要になる代表例が、決裁金額による条件分岐です。

たとえば会社の規程が次のようになっているとします。

申請金額	承認ルート例
10万円未満	課長
10万円以上50万円未満	課長 → 部長
50万円以上	課長 → 部長 → 役員

Power Automateでは「条件」などを使って申請金額を判定し、それぞれ別の承認処理へ進められます。

申請金額を判定して承認ルートを自動的に振り分けるPower Automateの考え方

こうしておけば、申請者が決裁規程を見ながら承認者を毎回選ぶ必要はありません。

ただし、金額の境界値や税込・税抜、代理承認、役職変更時の扱いなど、実際の決裁規程をそのままフローへ落とし込む前に、ルールそのものを整理しておくことが重要です。

Power Automateには複数の承認タイプがある

Power Automateの標準承認コネクタには、用途に応じた承認タイプがあります。

承認方法	動作	用途例
全員が承認	原則として必要な承認者全員の回答を待つ	関係部署全員の同意
最初の回答	指定した承認者のうち最初の回答で終了	担当者の誰か1名が判断

Microsoft 365グループを承認先として利用する方法もあるため、特定個人への依存を減らせる場合があります。

承認後の結果をSharePointへ保存する

管理部門で利用するなら、承認した後のデータまで考えておきましょう。

たとえばSharePointリストへ次の情報を記録しておけば、後から検索・集計しやすくなります。

申請番号
申請者
申請日
申請内容
申請金額
承認者
承認結果
承認日時
承認コメント

Teamsでの承認結果をPower AutomateからSharePointリストへ自動記録する仕組み

ただし、SharePointに保存すれば自動的に会計ソフトへ取り込めるわけではありません。

給与・会計・購買など別システムへ連携する場合は、相手側が必要とするCSV形式やAPI仕様に合わせた設計が必要です。

Teams承認の30日制限は正しく理解する

Power Automateの承認を調べると、「30日でタイムアウトする」という情報を見かけます。

ここは誤解しやすいポイントです。

30日の制限を、Teams承認アプリで作ったすべての承認が30日後に消える仕様と考えないようにしてください。

問題になるのは、Power Automateのフローが「承認されるまで待機し続ける」ような設計です。

Microsoftは、フローが30日以上続く可能性がある承認について、承認を作成するフローと、その応答を処理するフローを分け、Dataverseを利用する構成を案内しています。

詳しくはMicrosoft LearnのPower Automate承認ワークフローを確認してください。

通常の社内申請なら、まず処理日数を測る

備品購入や経費申請が30日以上止まること自体が業務上の課題である場合もあります。技術で長期間待てるようにする前に、承認期限や代理承認のルールを見直すことも重要です。

Power Automateは無料でどこまで使える？

Teams承認の導入時に気になるのがライセンスです。

Power Automateの「標準承認」コネクタはStandardコネクタに分類されています。

Microsoft Learnでは、Office 365などPower AutomateとStandardコネクタの利用権を含むライセンスで、標準承認フローを作成できると案内されています。

Teams、SharePoint、FormsなどMicrosoft 365内のStandardコネクタだけで構成するシンプルなフローなら、既存ライセンスの利用権に含まれる場合があります。

一方、Premiumコネクタ、カスタムコネクタ、オンプレミスゲートウェイ、RPAなどを利用する場合は、Power Automate PremiumやProcessなど追加ライセンスが必要になるケースがあります。

Microsoft 365の契約プランごとに権利が異なるため、「Power Automateなら全部無料」と判断せず、構築前に現在のライセンスを確認してください。

現在のライセンス体系は、Microsoft公式のPower AutomateライセンスFAQで確認できます。

Power Automateの属人化を防ぐ運用方法

Power Automateはローコードで作れるため、Excel関数やVBAより気軽に自動化を始められる場面があります。

一方、作った人しか分からない条件式や接続情報が増えると、担当者の異動・退職時に保守できなくなる問題が起こります。

管理部門で使う承認フローでは、「作れること」より「担当者が変わっても管理できること」を重視しましょう。

共有サービスアカウントだけに依存しない

以前は「退職しても止まらないように共有のサービスアカウントを所有者にする」という運用も見られました。

しかし、Microsoftは現在、サービスアカウントをPower Automateの推奨ベストプラクティスとはしていません。

重要な業務フローでは、用途に応じて共同所有者、ソリューション対応フロー、サービスプリンシパルなどを検討します。

特に部門・全社で利用する重要なフローでは、個人ユーザーのライフサイクルから切り離す方法としてサービスプリンシパル所有もMicrosoftから案内されています。

最低限残しておきたい管理情報

フローの目的
業務責任者
管理担当者
利用している接続先
承認ルートと条件
エラー時の連絡先
変更履歴
テスト方法

また、重要なフローでは所有者を1人だけにせず、必要な担当者を共同所有者として設定しておく方法もあります。

本格運用ではソリューション対応フローを検討する

Power Automateには、フローを「ソリューション」の中で管理する方法があります。

ソリューション対応フローでは、接続参照、環境変数、バージョン管理など、本番運用しやすい仕組みを利用できます。

小さな個人自動化まで最初から大規模な運用管理を行う必要はありませんが、会社の稟議や購買を止められないフローに育った段階では検討する価値があります。

承認業務の整理、承認経路の設計、TeamsとPower Automateによる実装までのステップ

Teams承認ワークフローの選び方

ここまでの内容を、実際の選定基準としてまとめます。

やりたいこと	おすすめ
上司に単発で確認したい	Teams承認アプリ
毎回同じ項目を入力させたい	承認テンプレート
申請内容を一覧管理したい	Lists・SharePoint＋承認
複数人へ順番に回したい	まずTeams標準承認を確認
金額で承認者を変えたい	Power Automate
承認後に別システムへ連携したい	Power Automate
30日を超える長期承認	Power Automateの長期承認設計を検討