TeamsのApprovalsで申請テンプレを使いやすくするコツは、テンプレを増やすことではなく、申請者が迷わず入力できて、承認者がすぐ判断できる粒度に絞ることです。具体的には、1テンプレ1判断を基本にし、公開範囲、入力項目、承認者の固定範囲、回答ボタンの言葉まで先に設計すると、現場で定着しやすくなります。
Approvalsには基本承認、テンプレ承認、e-sign承認があり、テンプレではカテゴリ・説明・フォーム設計・承認順・承認者・カスタム回答まで整えられます。一方で、テンプレ作成にはMicrosoft Formsライセンスが必要で、テンプレの裏側はDataverseやForms、チームのライフサイクルにも影響を受けます。この記事では、TeamsのApprovalsで申請テンプレを使いやすく設計するコツを、仕様差・注意点・代替策まで含めて実務目線で整理します。(Microsoft サポート)
TeamsのApprovalsで申請テンプレを設計する前に押さえる前提
2026年4月時点で公開されているMicrosoftの公式情報では、Approvalsのテンプレは管理者であれば Org wide Specific people Team wide の3つの公開範囲を選べます。チーム所有者が新規作成できるのは Team wide のみです。また、テンプレではアイコン・名前・説明・カテゴリを設定でき、フォーム設計とワークフロー設定で承認順、承認者、カスタム回答を整えられます。つまり、使いやすさは「フォームの見た目」だけでなく、誰にどこまで標準化を強制するかでほぼ決まります。(Microsoft サポート)
| スコープ | 主に作成できる人 | 向く運用 | 典型例 |
|---|---|---|---|
| Org wide | 管理者 | 全社で共通化したい申請 | 経費精算、出張申請、備品購入 |
| Specific people | 管理者 | 部門限定や試験導入 | 営業部だけの値引き申請、段階導入 |
| Team wide | 管理者、チーム所有者 | チーム固有の申請 | 制作チームのレビュー依頼、運用チームの変更申請 |
このスコープ差を理解せずに作り始めると、全社向けなのにTeam wideで作ってしまったり、逆に部門ごとに運用が違うのにOrg wideで固めすぎたりして、後から使いにくくなります。(Microsoft サポート)
見落としやすい前提もあります。
- テンプレ作成にはMicrosoft Formsライセンスが必要です。
- テンプレ経由の承認では、タイトルや詳細、テンプレートIDなどはDataverseに保存され、回答はFormsに保存されます。
- 元のFormsテンプレートを削除すると、Approvalsテンプレが壊れ、起票できなくなることがあります。
- Team wideテンプレはチームと同じ寿命なので、チームを完全削除すると関連テンプレも失われます。
- 2026年4月時点の公式情報では、1チームあたり最大400テンプレ、1テンプレあたり最大50,000件までが案内されています。(Microsoft Learn)
まずはTeams標準で十分かを見極める
申請テンプレを作る前にやるべきなのは、本当にTeamsのApprovalsテンプレが最適かを見極めることです。ここを間違えると、テンプレ設計の問題ではなく、選定ミスで運用が詰まります。
| 手段 | 向くケース | 強み | 注意点 |
|---|---|---|---|
| 基本承認 | 単発・都度依頼 | すぐ起票できる | 定型入力の標準化には向きにくい |
| テンプレ承認 | 同じ申請が繰り返し発生 | 入力欄や承認ルールをそろえやすい | 固定しすぎると例外処理に弱い |
| Lists / Document Libraries の承認 | リスト項目やファイル自体を承認したい | アイテム単位で状態管理しやすい | 権限共有や編集時の挙動に注意が必要 |
| Power Automate承認 | 条件分岐、差し戻し、他システム連携 | 自動化の自由度が高い | 設計と保守の負荷は上がる |
| e-sign承認 | 署名が必要 | DocuSign / Adobe Signと連携できる | 別途プロバイダーの契約や保管設計が必要 |
この整理は、Microsoftの現行ドキュメントで公開されている機能差を実務向けにまとめたものです。基本承認はハブやチャットからすぐ起票でき、テンプレでは定型項目やカスタム回答を設計できます。Lists / Document Libraries の承認はアイテムやファイルに紐づいた承認に強く、Power AutomateはSharePointやWordPressなど他サービス起点の承認や条件分岐に向きます。署名が必要ならe-sign承認を選ぶのが素直です。(Microsoft サポート)
TeamsのApprovalsで申請テンプレを使いやすく設計する8つのコツ
1テンプレ1判断に絞る
もっとも失敗しやすいのが、「社内申請共通」「承認依頼共通」のような万能テンプレを1本作る設計です。申請者から見ると入力欄が多くなり、承認者から見ると判断材料が散らばります。
たとえば、次の2つは分けた方が運用しやすくなります。
- 値引き申請
- 出張申請
どちらも「承認」ではありますが、承認者が見たい情報が違います。値引き申請では割引率や粗利影響、出張申請では目的・期間・概算費用が重要です。判断基準が違うなら、テンプレも分ける方が自然です。
ただし、細かく分けすぎるのもよくありません。2026年4月時点の公式情報では、1チームあたり400テンプレの上限があるため、年度別・拠点別・担当者別の派生テンプレを量産すると、利用者も管理者も迷いやすくなります。業務単位で分け、属性の違いは入力項目やカテゴリで吸収するくらいがちょうどいいです。(Microsoft Learn)
スコープは「利用者数」より「標準化の強さ」で決める
TeamsのApprovalsテンプレ設計では、誰が使うかよりも、どこまで同じルールを押し通せるかでスコープを決める方が失敗しません。
- 全社で承認ルールがほぼ同じなら Org wide
- まだ試したい、または部門だけで回したいなら Specific people
- チームごとにやり方が違うなら Team wide
たとえば、経費精算のように全社で近いルールに寄せやすいものは Org wide が向きます。一方、制作チームのレビュー依頼や運用チームの変更申請のように、チームごとに承認者や判断基準が違うものは Team wide の方が自然です。しかも Team wide テンプレはチームの寿命に依存するため、組織横断で長く残したい申請を試験用チームに置くのは避けた方が安全です。(Microsoft サポート)
名前・説明・カテゴリで迷わせない
Approvalsのテンプレは、アイコン、名前、説明、カテゴリを設定できます。ここを雑にすると、中身が良くても使われません。検索や一覧で選ばれる前提で設計するのが大切です。(Microsoft サポート)
実務では、次のような付け方が分かりやすいです。
- 悪い例: 申請1、承認テンプレ、営業用
- 良い例: 値引き申請（案件単位）、経費精算（5万円未満）、出張申請（国内）
説明文には「誰が」「どんな時に」「何を添付するか」を短く入れると迷いが減ります。
- 例: 課長承認が必要な国内出張向け。領収書見込みがある場合は添付必須。
カテゴリは部署名よりも、利用者が探す言葉で分けると使いやすくなります。たとえば「営業」「人事」より、「経費」「契約」「購買」「レビュー」の方が選びやすいケースが多いです。
必須項目は「承認判断に必要な情報」だけにする
テンプレの入力欄は、申請者のためではなく、承認者が短時間で判断するために置くものです。フォーム設計ができるからといって、何でも入れればよいわけではありません。(Microsoft サポート)
たとえば、出張申請なら次のように整理すると使いやすくなります。
| 必須にしやすい項目 | 任意にしやすい項目 |
|---|---|
| 出張目的 | 詳細背景 |
| 期間 | 代替案 |
| 訪問先 | 補足メモ |
| 概算金額 | 関係者への共有事項 |
| 添付資料の有無 | 社内向けメモ |
ポイントは3つです。
- 承認可否に直結しない情報は任意にする
- 既に別システムで分かる情報は重複入力させない
- 申請後に差し戻しが起きやすい項目だけ必須にする
「申請者名」「所属」「申請日」などがTeamsや別システムで追えるなら、入力欄としては極力増やさない方が現場では使われます。
承認者の固定は最小限にする
テンプレで承認者をあらかじめ指定すると、運用は安定します。ただし、固定しすぎると例外処理に弱くなります。Microsoftのサポート文書でも、テンプレで特定の受信者が選ばれている場合、利用者が受信者を追加・削除できないことがあると案内されています。(Microsoft サポート)
固定しやすいのは、次のようなケースです。
- 毎回同じ管理職が承認する
- コンプライアンス担当が必ず入る
- 小規模チームで承認者が変わらない
逆に固定しにくいのは、次のようなケースです。
- 案件や金額で承認者が変わる
- 部門ごとに承認ルートが違う
- 一時的な代理承認が多い
こうした業務を無理にTeamsのApprovalsテンプレだけで吸収しようとすると、テンプレが増えすぎるか、例外対応だらけになります。条件で承認者を切り替えたいなら、Power Automateに寄せた方が整理しやすいことが多いです。
回答ボタンは現場の言葉にする
Approvalsテンプレでは、ワークフロー設定でカスタム回答を設けられます。ここは地味ですが、使いやすさに直結します。(Microsoft サポート)
たとえば、単純な「Approve / Reject」だけでは足りない業務があります。そういう時は、次のように業務語に寄せると運用しやすくなります。
- 承認
- 差し戻し
- 条件付き承認
この設計の利点は、承認者が何を選べばよいか迷いにくいことです。「差し戻し」と「却下」は意味が違いますし、「要再申請」と「追加資料提出」も実務では別物です。ボタン名が曖昧だと、後続のやり取りが増えます。
起票場所と閲覧範囲を切り分ける
TeamsのApprovalsは、ハブ、チャット、チャネルから起票できます。ただし、どこで起票するかで見える人が変わる点は見落とされがちです。Teamsの管理ドキュメントでは、チャットやチャネルで作られた承認では、その場の参加者がビューアー権限を持つ場合があると案内されています。また、チャットから承認を作る場合、追加できる承認者はそのチャット内のメンバーに限られます。(Microsoft Learn)
このため、次のように分けると安全です。
- 機密性が高い申請
例: 人事、評価、個別契約、価格例外
→ Approvalsハブから起票する - チームで共有しながら進めたい申請
例: 制作レビュー、軽微な運用変更
→ 必要に応じてチャットやチャネル起票を使う
「Teams内だから気軽にチャネルで起票」は便利ですが、誰が見えるのかを意識しないと、テンプレ設計以前の問題になります。
フォームとテンプレの寿命を別物と考えない
Approvalsテンプレは、表面上はTeamsの機能ですが、裏側ではDataverseとFormsが関わります。しかも、元のFormsテンプレートを削除するとApprovalsテンプレが壊れるとMicrosoftは案内しています。さらに、Team wideテンプレはチームと同じ寿命です。(Microsoft Learn)
実務では、次の3点を先に決めておくと事故を防げます。
- テンプレのオーナーは誰か
- 元フォームを誰が削除してよいか
- Team wide で作ったテンプレをどのチームに置くか
2026年4月時点の公開ドキュメントでは、Approvalsが使う既定Dataverse環境はバックアップ非対応と案内されています。重要な承認プロセスほど、「とりあえず作る」ではなく、管理者・チーム所有者・業務責任者の役割を決めてから公開した方が安心です。(Microsoft Learn)
失敗しやすい設計パターン
| 失敗パターン | 起きやすい問題 | 修正の考え方 |
|---|---|---|
| 万能テンプレを1本だけ作る | 入力欄が増え、差し戻しも増える | 1テンプレ1判断に寄せる |
| 全社申請をTeam wideで作る | チーム削除時にテンプレも消える | 長期運用はOrg wideを検討する |
| 承認者をすべて固定する | 例外時に回らない | 固定すべき承認者だけ固定する |
| 機密申請をチャネル起票する | 閲覧範囲が広がりやすい | ハブ起票を基本にする |
| ファイル承認をテンプレだけで回す | 元ファイルとの関係が見えにくい | Lists / Document Librariesの承認も検討する |
特に「どこで起票するか」と「どの単位でテンプレを公開するか」は、使いやすさだけでなく情報公開範囲にも効いてきます。設計レビューでは、フォーム項目より先にこの2点を確認した方が失敗が少なくなります。(Microsoft Learn)
定着させるための運用ポイント
テンプレは作って終わりではありません。利用率を上げたいなら、管理側の設定も必要です。
- ApprovalsアプリをTeamsのアプリバーにピン留めする
- 使わない既定テンプレは無効化する
- テンプレの作成・編集・有効化 / 無効化を監査対象にする
- テンプレの棚卸しを定期的に行う
Microsoftの管理ドキュメントでは、Approvalsアプリは既定で利用可能で、Teamsのアプリ設定ポリシーでピン留めできます。サポート文書では、チーム所有者や管理者が既存テンプレの編集や不要テンプレの無効化も行えます。さらにPurview監査では、承認作成や承認結果だけでなく、テンプレの作成・編集・有効化 / 無効化も追えると案内されています。(Microsoft Learn)
現場での体感としては、テンプレそのものよりも、「Approvalsが見つからない」「どれを選べばよいか分からない」で使われなくなるケースが多いです。だからこそ、UI上の見つけやすさとテンプレ数の整理は、設計と同じくらい大事です。
TeamsのApprovalsでは足りないケースと代替策
条件分岐や差し戻し後の再処理が必要ならPower Automate
Power Automateの承認は、Start and wait for an approval を使って任意のフローに組み込めます。SharePoint、OneDrive、Dynamics 365、Salesforce、Zendesk、WordPressなど複数サービスを起点にでき、カスタム回答も設計できます。承認者はメール、TeamsのAdaptive Card、Power Automate側から応答できます。(Microsoft Learn)
しかも、Microsoftのサポート文書では、Power Automateで作成した承認もApprovalsハブに表示されると案内されています。つまり、裏側の自動化はPower Automateに移しつつ、利用者の見える場所はApprovalsに寄せる、という設計も可能です。(Microsoft サポート)
ファイルやリスト項目そのものを承認したいならLists / SharePoint
契約書、申請台帳、原稿、申請レコードのように、承認対象そのものがリスト項目やファイルなら、Lists / Document Librariesの承認が向きます。承認状態をアイテムに紐づけて見やすいからです。(Microsoft サポート)
ただし、注意点もあります。Microsoftの文書では、承認者に元アイテムの閲覧権限が自動で付与されるわけではなく、進行中に項目を更新すると承認がリセットまたは自動キャンセルされると案内されています。ファイル中心の承認に強い反面、権限設計や編集中の運用ルールは別途必要です。(Microsoft サポート)
署名が必要ならe-sign承認
承認ではなく署名が必要なら、Approvalsのe-sign承認を使う方が筋が良いです。Microsoftのサポート文書では、Adobe SignやDocuSignを使って、署名者や承認者を役割付きで設定し、順番も指定できると案内されています。(Microsoft サポート)
ただし、e-signはApprovals単体で完結するわけではありません。利用にはプロバイダー側のアカウントやライセンスが必要で、保存先や保持もプロバイダー側のクラウドに依存します。単なる上長承認なのにe-signを選ぶと、運用が過剰になりやすいです。(Microsoft サポート)
迷ったら最初の1本はこう作る
最初から全社の申請を作り込む必要はありません。まずは、次の順番で1本だけ作るのが安全です。
- 月に何度も発生し、承認者が比較的安定している申請を1つ選ぶ
例: 経費精算、出張申請、軽微な値引き申請 - スコープを決める
全社共通なら Org wide、試験導入なら Specific people、チーム固有なら Team wide - 必須項目を絞る
目安は「承認者が判断に必要な情報だけ」。不要なら5〜7項目以内に収める - 回答ボタンを実務に合わせる
単純な承認 / 却下ではなく、差し戻しや条件付き承認が必要かを考える - 公開後に見直す
申請者が迷った項目、承認者が追加で聞いた項目、差し戻し理由を見て修正する - 使う導線も整える
Approvalsをピン留めし、不要テンプレを減らし、「どれを使えばよいか」を一覧で分かるようにする
TeamsのApprovalsで申請テンプレを使いやすく設計する本質は、凝ったフォームを作ることではありません。申請者の迷いを減らし、承認者の判断時間を短くし、管理者が壊しにくい構造にすることです。まずは1つの定型申請を選び、スコープ、必須項目、承認者固定の範囲、公開場所の4点だけを先に決めて試すと、失敗しにくくなります。
コメント