Teamsの承認通知が届かない・見落とす原因と対策

Teamsで承認フローを回し始めると、必ず「承認依頼が承認者に届いていない」という声が上がります。原因は1つではなく、通知設定・ライセンス・フローの実装・運用設計という4つの階層に分かれています。どの階層の問題かを切り分けないまま対策を打つと、リマインドを増やしただけで根本的には変わらない、という結果になりがちです。

この記事の要点

• 「届かない」と「見落とす」は別の問題で、対処も別。まずどちらかを切り分ける。
• 技術的に届いていないケースの大半は、通知設定・ライセンス・承認者アカウントの状態のいずれか。
• 届いているのに見落とされるケースは、通知の量と承認者の可処分時間の問題であり、リマインドの追加では解決しない。
• 社外メンバーやTeams未利用者が承認者に含まれる場合は、Teams以外の経路を用意する必要がある。

まず「届いていない」のか「見落としている」のかを切り分ける

対策の前に、承認依頼が承認者の画面に表示されているかどうかを確認します。切り分けは単純で、承認者のTeamsで承認アプリの「受信」一覧を開き、当該の依頼が存在するかを見ます。

一覧に依頼がある場合は、通知としては届いており、承認者が気づかなかった、あるいは後回しにした状態です。一覧に依頼そのものがない場合は、フローが承認アクションまで到達していないか、承認者の指定が誤っています。この2つは原因も対策もまったく違うので、ここを飛ばさないでください。

実務では、この確認を申請者や情シスが代わりに行えないのが厄介な点です。承認アプリの受信一覧は本人しか見られないため、承認者に「承認アプリを開いて、この件名の依頼があるか見てください」と依頼する必要があります。問い合わせ対応の定型文として用意しておくと、切り分けが早くなります。

依頼そのものが届いていないときに見るところ

フローが承認アクションまで到達していない

もっとも多いのがこれです。Power Automateの実行履歴を開き、承認アクションの手前で失敗していないかを確認します。典型的な失敗は、接続の認証切れ、直前のデータ取得アクションでの権限エラー、必須項目の空値によるエラーです。

実行履歴に「実行中」のまま何日も残っている場合は、承認アクションには到達していて、承認者側の応答を待っている状態です。この場合は次の項目を確認します。原因の切り分け手順はPower Automateの承認フローが止まる原因10選で網羅的に整理しています。

承認者のアカウントが無効・ライセンス未割当

退職・休職に伴うアカウントの無効化や、ライセンスの再割り当てによって、承認者が承認アプリを利用できない状態になっているケースです。フロー側は承認依頼を送信済みとして扱うため、実行履歴上はエラーになりません。承認依頼だけが宙に浮きます。

この問題は、承認者をユーザー個人で指定していると必ず起きます。承認者をMicrosoft 365グループやセキュリティグループ、あるいは承認者マスタのリストから引く構成にしておけば、メンバーの入れ替えはグループ側の更新だけで済みます。

承認者にTeamsのライセンスがない、または社外メンバー

業務委託先や取引先が承認に関わる場合、そもそもTeamsの承認アプリが使えません。標準の承認機能はTeams／Microsoft 365のアカウントを前提としているため、ゲストアカウントの状態によっては通知が届かないか、届いても操作できないことがあります。

社外の承認者が恒常的に存在する業務では、Teamsだけで完結させる設計自体を見直す必要があります。メールでの承認経路を併設するか、外部の関係者も同じ画面で承認できるサービスを使うことになります。なお、メールのリンクをクリックすると承認が成立する方式を採る場合、URLを知っていれば誰でも承認できてしまう点に注意してください。本人確認をどう担保するかは、Google Chatで承認フローを回す方法と実装の勘所で別ツールを例に整理していますが、論点はTeamsでも同じです。

通知設定でオフになっている

承認アプリの通知は、Teamsのアプリごとの通知設定とOSの通知設定の両方に影響されます。承認者本人が過去にバナー通知をオフにしている、モバイル側で通知を切っている、というケースは珍しくありません。確認は承認者の端末上でしかできないため、運用側では検知できない点に注意してください。

確認してもらう箇所は、次の3つに絞れます。Teamsの設定にあるアプリ単位の通知設定、Teams全体のバナー表示の設定、そして端末側（Windows・macOS・iOS・Android）のTeamsアプリに対する通知許可です。集中モードやおやすみモードが有効になっているだけ、という例も一定の割合であります。

切り分けの順序

確認の順序を決めておくと、問い合わせ対応が定型化できます。実行履歴（フローが到達しているか）→ 承認者アカウントの状態 → 承認者の種別（社内か社外か）→ 端末の通知設定、という順です。前の3つは情シス側で確認でき、最後の1つだけが本人依頼になるため、この順に進めると本人の手を煩わせる回数が減ります。

届いているのに見落とされるときの考え方

通知の総量が承認者の可処分時間を超えている

管理職のTeamsには、チャット、チャネルのメンション、会議のリマインド、各種アプリの通知が1日に何十件も届きます。その中に承認依頼が紛れると、重要度に関係なく上から順に流れていきます。この状態でリマインド通知を追加しても、通知の総量が増えるだけで、承認までの時間は縮まりません。

効果があるのは、承認者に届く件数そのものを減らす設計です。金額帯で承認の要否を分け、少額は事前承認を不要にして月次のモニタリングに回す、同一申請者の複数件をまとめて1件の承認にする、といった方向です。金額帯で統制の重さを変える設計の考え方は、消耗品購買の内部統制｜リスクと承認フロー設計で詳しく扱っています。

承認の判断に手間がかかる

もうひとつの見落とし要因は、通知を見ても即断できないことです。申請の内容を確認するために別のシステムを開く必要がある、添付の見積書をダウンロードしないと金額がわからない、という状態だと、承認者は「あとで見る」を選びます。

承認カードの上に、判断に必要な情報（申請者・金額・用途・予算残・過去の類似申請）を揃えておくと、この後回しが減ります。カードの作り込み方はTeamsのAdaptive Cards実装手順｜承認カードの作り方で解説しています。AIによる一次チェックを挟んで、確認すべき点だけを注記する方法はMicrosoft Teamsのチャット承認とAI活用方法を解説で扱っています。

承認が本業の外側にある

3つめの要因は構造的なものです。承認者にとって、承認は自分の業務の成果に直結しない「割り込み」であることが多く、優先順位が下がります。とくに、承認したあとで別の誰かが発注や手配を行う運用だと、承認が遅れても困るのは他部署の誰かであり、承認者自身には跳ね返りません。

この非対称を放置したまま、通知の工夫だけで承認を速くするのには限界があります。後述のとおり、承認を業務の流れの中に戻せるかどうかが分かれ目になります。

標準機能で組めるリマインドとエスカレーション

期限つきリマインドを送る

Power Automateの「並列分岐」と「遅延」アクションを使うと、承認待ちのまま一定時間が経過した場合にリマインドを送る構成が組めます。承認アクションと遅延アクションを並列に置き、どちらかが完了したら次に進む形にします。

注意点として、リマインドの間隔を短くしすぎると前述の「通知の総量」問題を悪化させます。営業日ベースで1日〜2日に1回程度が現実的です。また、リマインドの文面に申請の要約（申請者・金額・期限）を含めておくと、通知を開かずに優先順位を判断できます。

期限超過で上位者にエスカレーションする

リマインドを一定回数送っても応答がない場合に、上位の承認者へ依頼を回す構成です。設計上決めておく必要があるのは、エスカレーション先を誰にするか、元の承認者の承認権限をどう扱うか（無効にするのか、並列で残すのか）の2点です。

ここを曖昧にしたまま実装すると、「部長も課長も承認できる状態」が常態化し、誰が承認したのかが業務上追えなくなります。統制の観点では、エスカレーションの発生自体をログに残し、月次で件数を見る運用まで含めて設計してください。エスカレーションが特定の承認者に偏っているなら、その人の承認範囲が広すぎるという別の問題の表れです。

承認者の不在情報を先に拾う

もっとも確実なのは、そもそも不在の人に依頼を送らないことです。Outlookの予定表から不在情報を取得し、不在なら代理承認者に回す構成が組めます。ただし予定表の権限設定によっては情報を取得できないため、導入前に組織のポリシーを確認してください。

エスカレーションの前に、承認者の人数を見直す

技術的な作り込みの前に確認したいのが、承認者の人数です。承認者を1人に固定している業務は、その人の不在がそのまま停止につながります。「いずれか1人の承認で成立する」形で2〜3人を指定できる業務であれば、リマインドもエスカレーションも不要になることがあります。

全員承認が必要な業務と、いずれか1人でよい業務を棚卸しし、後者に該当するものから承認者を複数指定に変えていくのが、最も費用対効果の高い対策です。

通知の問題を「設計」で消す

ここまでは、Teams上で承認を回す前提での対策です。一段引いて見ると、承認通知の問題の多くは、承認が業務の流れから切り離された独立したイベントになっていることに起因します。

たとえば購買であれば、承認者が判断するのは「買ってよいか」です。承認が下りた後に別の誰かが発注する運用だと、承認は業務の途中に挟まる中断であり、承認者にとっては本業の外側の作業です。一方、承認した瞬間に発注が確定する仕組みなら、承認は意思決定そのものになり、遅延の影響が承認者自身にも即座に返ってきます。

1Approval for Teamsは、Teamsのチャットを申請の入口としながら、承認と同時に発注・決済までを確定させる構成を取ります。承認者に届く情報は金額と在庫を含めて確定済みのため、判断に必要な確認作業が減り、後回しにされにくくなります。

よくある質問（FAQ）

承認依頼はメールでも届きますか？

標準の承認アプリで作成した依頼は、TeamsとOutlookの両方に通知が届くのが既定の動作です。ただしユーザー側の通知設定やメールボックスのルールによって届かないことがあるため、届いていない場合はまずTeams上の承認アプリ一覧で依頼の存在を確認してください。

承認者が退職した場合、承認待ちの依頼はどうなりますか？

依頼は承認待ちのまま残り、誰も操作できない状態になります。フロー側でタイムアウトを設定していなければ、期限なく待ち続けます。承認者をグループで指定するか、タイムアウトと再割り当ての処理を用意しておくことで回避できます。

リマインドを自動で送ることはできますか？

Power Automateの遅延アクションを承認アクションと並列に置くことで実装できます。標準の承認アプリ単体にはリマインド機能はありません。

社外の取引先を承認者にできますか？

標準の承認アプリでは、ゲストアカウントの構成によっては通知が届かず、実質的に運用できないことがあります。社外の承認者が恒常的に必要な場合は、メールなどTeams以外の経路でも承認できる仕組みを用意してください。

承認待ちの件数を一覧で把握できますか？

承認アプリ上では、自分が関わった依頼しか見られません。全社の承認待ち件数を把握するには、フローの中で承認開始と完了をSharePointリストなどに書き出し、その差分を見る仕組みを別途用意する必要があります。

まとめ

承認通知の問題は、「届いていない」のか「見落とされている」のかで原因も対策も分かれます。前者は実行履歴・承認者アカウントの状態・承認者の種別・端末の通知設定を順に確認すれば切り分けられます。後者は通知の量と判断の手間の問題であり、リマインドを増やしても解決しません。

承認者に届く件数を減らす、判断に必要な情報をカード上に揃える、承認者を複数指定にする、そして承認を業務の流れの中に戻す——この4つが、通知の問題に対する根本的な打ち手です。