TeamsのWorkflowsアプリとは？承認アプリとの使い分け

TeamsのWorkflowsアプリは、Power Automateのフローを、Teamsの画面から直接作成・管理するための入口です。Power Automateのポータルを開かずに、メッセージやチャネルを起点とした定型処理をテンプレートから追加できます。承認業務で使う場合、標準の「承認（Approvals）」アプリとは役割が異なるため、どちらを使うべきかは目的によって変わります。

この記事の要点

• Workflowsアプリは「Teamsの中に置かれたPower Automateの入口」であり、別の自動化エンジンではない。
• 承認（Approvals）アプリが承認そのものを扱うのに対し、Workflowsは承認を含む一連の処理の流れを組む。
• テンプレートから4手順で始められる反面、条件分岐や承認ルートの作り込みが必要になった時点でPower Automateのポータルに戻ることになる。
• 申請承認を全社で回す用途では、作れるかどうかではなく、組織変更のたびに誰が直すのかで判断する。

WorkflowsアプリとApprovalsアプリは何が違うのか？

Teamsで「承認」に関係するアプリは2つあり、混同されやすいので最初に整理します。

承認（Approvals）アプリ＝承認そのものを扱うアプリ

Approvalsアプリは、承認依頼の作成・送信・承認・却下・履歴の確認までを担う専用アプリです。テンプレート（休暇申請・購買申請など）を選ぶか、自由項目で依頼を作り、チャットまたはチャネルに送信します。承認者はメッセージ上のボタンで意思決定でき、結果はアプリ内の履歴に残ります。

この仕組みで完結するのは、「承認を取ること」自体が目的の場合です。承認後に何かを自動実行する必要がないなら、Approvalsアプリだけで十分に運用できます。

Workflowsアプリ＝処理の流れを組むアプリ

一方のWorkflowsアプリは、Power Automateのフローをテンプレートから追加し、Teams内で管理するための入口です。「チャネルに投稿されたらタスクを作る」「毎週決まった時刻にリマインドを流す」「フォームが送信されたら承認を開始し、結果をリストに書き戻す」といった、複数の処理をつなげた流れを扱います。

つまり、Approvalsは承認という1つの行為、Workflowsは承認を含む一連の処理、という役割分担になります。承認後に発注・登録・通知といった後続処理が必要な業務では、Workflows（＝Power Automate）側の出番になります。

テンプレートは3系統に分かれている

Workflowsアプリのテンプレート一覧は数が多く、最初は目的のものを見つけにくいはずです。承認業務の観点では、次の3系統だけ押さえれば足ります。

第1が通知系で、チャネルへの投稿やメンションをきっかけに、別のチャネルや個人へ通知を流すものです。承認そのものは含みませんが、申請の発生を関係者に知らせる用途で使えます。第2がタスク化系で、メッセージをPlannerやTo Doのタスクに変換します。第3が承認系で、フォームの回答やリストへの行追加をきっかけに承認を開始します。実務で使うのはほぼ第3系統です。

使い分けの目安

申請の種類が少なく、承認を取ること自体がゴールであればApprovalsアプリ。承認の前後に自動処理を挟みたい、承認結果を他のシステムに書き戻したいといった要件があればWorkflowsアプリ、という切り分けが実務的です。両者は排他ではなく、Workflowsで組んだフローの中からApprovalsの承認アクションを呼び出す構成もよく使われます。この場合、承認者に届くのはApprovalsのカードなので、承認者側の体験は変わりません。

Workflowsアプリで承認フローを作る手順

ここからは、フォームの回答を承認に回す構成を例に、4つの手順で組み立てます。

【手順1】テンプレートを選び、接続を承認する

TeamsのアプリからWorkflowsを開き、テンプレート一覧から目的に近いものを選びます。承認関連では「フォームの回答に対して承認を求める」「チャネルの投稿を承認に回す」といったテンプレートが用意されています。

テンプレートを選ぶと、接続するアカウントの確認画面が出ます。Teams・SharePoint・Formsなど、そのテンプレートが使うサービスへの接続をここで承認します。**この接続は、作成したユーザーの資格情報で確立される点に注意してください。**フローはその後もこの資格情報で動き続けるため、作成者が退職してアカウントが無効化されると、フロー全体が止まります。業務で使うフローは、最初から共有アカウントで作るか、後述する所有者の追加を済ませておきます。

【手順2】トリガーを設定する

トリガーは「何をきっかけにフローを動かすか」の定義です。承認フローでよく使うのは、Microsoft Formsの回答送信、SharePointリストへの項目追加、そしてTeamsのメッセージへのアクションの3つです。

ここで決めておくべきなのは、申請の入口を1つに絞ることです。「フォームからも申請できるし、チャットからも依頼できる」という状態にすると、申請データの保存先が分かれ、後から一覧で集計できなくなります。入口はフォームかリストのどちらかに寄せ、もう一方は使わない運用にしてください。

【手順3】承認者を設定する

承認アクションでは、承認の種類（全員の承認が必要か、いずれか1人でよいか）と、承認者を指定します。

**承認者はユーザー個人ではなく、可能な限りグループやSharePointリストから引く形にしてください。**フロー内にメールアドレスを直接書き込むと、異動・退職・組織改編のたびにフロー本体を編集することになり、触れる人が作成者1人に固定されていきます。承認者マスタ用のSharePointリストを用意し、部門コードや金額帯をキーに承認者を引く構成にしておけば、以降の変更はリストの更新だけで済みます。

あわせて、承認依頼に載せる項目もここで決めます。申請者・金額・用途・添付・予算残のように、承認者が別画面を開かずに判断できる情報を揃えておくと、後回しにされる確率が下がります。

【手順4】テスト実行と、止まったときの見方を決める

テスト実行は、Workflowsアプリの一覧から個別のフローを開き、実行履歴を確認します。ここで見える情報はPower Automateのポータルと同じもので、どのアクションで止まったかを追えます。

テストでは、正常系だけでなく次の3つを一度は通してください。**承認者が不在のケース、差し戻して再申請するケース、途中でエラーが出たケース。**本番で最初に問題になるのは、ほぼこの3つです。

承認フローが途中で止まる原因はパターンが決まっているので、Power Automateの承認フローが止まる原因10選の切り分け手順をそのまま使えます。また、フロー自体は動いていても承認依頼が承認者に届かない・見落とされるという別種の問題については、Teamsの承認通知が届かない・見落とす原因と対策で扱っています。

Workflowsアプリで作り込もうとすると何が起きるか

分岐が増えるとテンプレートの外に出る

テンプレートが想定しているのは、トリガー→承認→通知といった直線的な流れです。金額が10万円未満なら課長、100万円以上なら役員まで、といった分岐を入れようとすると、Teams内の簡易編集では足りず、Power Automateのポータルでフローを開いて条件アクションを組むことになります。ここから先はWorkflowsアプリの画面で完結しません。

稟議として求められる要件をPower Automateでどこまで表現できるかは、Power Automateで稟議フローは作れる？内製の限界で詳しく整理しています。

承認の履歴が業務単位で散らばる

Workflowsで組んだフローから承認を出すと、承認履歴はApprovalsアプリ側に、申請データはSharePointリストやDataverseに、実行ログはPower Automateに、とそれぞれ別の場所に残ります。日々の運用では問題になりませんが、監査で「過去1年分の購買申請を、承認者と金額つきで一覧にしてほしい」と求められた時に、3か所を突き合わせる作業が発生します。

しかも実行履歴には保持期間の上限があり、無期限には残りません。監査要件が数年単位であれば、承認結果をフローの中で別途リストに書き出しておく必要があります。この設計についてはTeams承認の履歴・監査証跡はどこまで残せるかで詳しく扱っています。

ライセンスの境界が後から効いてくる

Microsoft 365の多くのプランには標準のPower Automate利用権が含まれており、基本的な承認フローはその範囲で動きます。境界になるのはプレミアムコネクタで、HTTPアクションや外部データベースへの接続を使う場合は別途ライセンスが必要です。

問題は、この境界が設計の初期には見えないことです。「承認まで」であれば標準の範囲で収まりますが、承認後に外部システムを呼ぶ段階でプレミアムが必要になります。連携先を決める段階で、標準コネクタが用意されているかを先に確認してください。

承認の後ろ側は結局つなぎ込みになる

購買申請であれば、承認後に発注が続きます。Workflowsから発注先のシステムを叩くには、対応するコネクタがあるか、HTTPアクションでAPIを呼ぶことになります。つなぎ先が1つなら成立しますが、購買サイトが複数に分かれている場合、その数だけフローと認証情報を管理することになります。

承認と発注の分断が実務でどう効いてくるかは、Microsoft 365で購買申請を自動化する設計の勘所とTeamsで購買申請から発注までを完結させる方法でも扱っています。

運用に入る前に決めておく2つのこと

フローの所有者をチームに移す

Workflowsで作成したフローは、作成者が所有者になります。個人所有のまま業務で使うと、その人が異動・退職した際にフローが止まり、しかも他の人が中を見ることもできません。

業務で使うフローは、早い段階で共同所有者を追加してチーム所有に切り替えてください。目安として、自分以外の1人が触れる状態になっていれば最低限は確保できます。あわせて、フローが使っている接続（コネクタ）の資格情報が誰のものかも確認しておきます。所有者を追加しても、接続が個人のままなら同じ問題が残ります。

止まっていることに気づく仕組みを持つ

承認フローの運用で最も困るのは、止まったこと自体に誰も気づかない状態です。申請者は「承認待ちなのだろう」と思い、承認者には依頼が届いておらず、数日経ってから発覚する——という流れがよく起きます。

対策としては、フローの失敗時に情シスの共有チャネルへ通知を送るフローを別途用意しておくのが簡単です。あわせて、一定期間承認されていない申請を週次で洗い出す仕組みがあると、止まっているのか単に承認が遅いのかを切り分けられます。

内製とサービス利用の判断軸

Workflowsアプリは、追加のライセンス負担なく始められる点が最大の利点です。定型業務の自動化、通知の自動化、部門内で完結する軽い承認といった用途では、これ以上に手軽な選択肢はありません。

判断が必要になるのは、次の3つが同時に当てはまるときです。

1. 承認ルートが組織変更のたびに変わる
2. 承認結果を外部のシステムに反映する必要がある
3. 監査や内部統制で、申請から支払までの証跡をまとめて出す必要がある

この3つが揃うと、フローの保守が特定の担当者に集中し、その人が異動した時点で誰も触れない資産になります。承認ルートを設定画面で扱える仕組みに寄せるか、承認と実行が最初から一体になっているサービスを使うかを検討する段階です。

1Approval for Teamsは、Teamsのチャットを申請承認の入口として使いながら、承認と同時に発注・決済までを確定させる構成を取ります。承認ルートは管理画面から変更でき、申請から支払までの証跡は1本につながった状態で残ります。

よくある質問（FAQ）

WorkflowsアプリとPower Automateは別物ですか？

別物ではありません。WorkflowsアプリはPower Automateのフローを、Teamsの画面から作成・管理するための入口です。作られるフローの実体はPower Automateのものなので、ポータル側から開いて編集することもできます。

Workflowsアプリを使うのに追加ライセンスは必要ですか？

Microsoft 365の多くのプランには標準のPower Automate利用権が含まれており、基本的なフローはその範囲で動きます。ただしHTTPアクションや一部の外部データベース接続などプレミアムコネクタを使う場合は、別途ライセンスが必要です。連携先を決める段階で条件を確認してください。

承認（Approvals）アプリとWorkflowsアプリは併用できますか？

併用できます。むしろ実務では、Workflowsで組んだフローの中から承認アクションを呼び出し、承認者にはApprovalsアプリのカードが届く、という構成が一般的です。

Workflowsアプリで作ったフローは誰が管理しますか？

作成者が所有者になります。個人所有のまま運用すると、その人が異動・退職した際にフローが止まるため、業務で使うフローは早い段階で共同所有者を追加し、接続の資格情報もあわせて確認しておくことを推奨します。

作ったフローを他の部門に展開できますか？

フローのエクスポートとインポートは可能ですが、接続先のリストIDやチャネルIDが環境ごとに異なるため、そのままでは動きません。展開を前提にするなら、環境ごとに変わる値を設定用のリストに切り出しておくと、移行時の書き換えが最小限で済みます。

まとめ

Workflowsアプリは、Teamsの中からPower Automateを扱えるようにした入口であり、承認そのものを扱うApprovalsアプリとは役割が異なります。テンプレートの範囲で回る業務であれば、これ以上に手軽な自動化手段はありません。

一方、承認ルートの分岐、承認後の実行、証跡の一元管理という3点が要件に入ってきた時点で、内製の保守コストが効いてきます。作れるかどうかではなく、3年後も誰かが直せるかどうかで判断してください。

Teamsの承認体験をカードレベルで作り込む方法はTeamsのAdaptive Cards実装手順｜承認カードの作り方、全社展開の選択肢の整理はMicrosoft 365の承認ワークフロー｜Teams標準の限界をあわせてご覧ください。