Teamsに通知が届かない｜Incoming WebhookをWorkflowsに替える手順

「Teamsに来ていたフォームの通知が春から1件も来ていない」と気づいて、Incoming Webhookの廃止を調べている担当者は多いです。TeamsのIncoming Webhookは2026年5月に止まっていて、古いURLに送られた通知は待っていても届きません。Teamsの中のWorkflowsで新しいURLを作り、通知を送っている側の設定に貼り替えれば通知は戻ります。

Microsoftの開発者向けのお知らせでは、Office 365コネクタ（Incoming Webhookを含む）は2026年5月18日から順に止められ5月22日に止め終わったと案内されています（Microsoft 365 Developer Blogのお知らせ・2026年4月14日の最終更新）。止める時期は2024年の発表から何度も延びていて、この日付が最後の予定でした。

この記事では、止まった通知を見つける方法とWorkflowsでの作り直しの手順を順に説明します。そのうえで作り直したあとに気をつける上限と持ち主の決め方をお伝えします。

Teamsの古いWebhookは2026年5月に止まった

Incoming Webhookは、外のサービスからTeamsのチャネルに文章を送るためのURLでした。問い合わせフォームや監視のサービスの設定にこのURLを貼っておくと、何かあるたびにTeamsに知らせが出ていました。

Microsoftは2024年7月にこの機能を終えると発表しました。その後は2025年12月まで・2026年3月31日まで・2026年4月30日までと期限を延ばし、最後に2026年5月18日から22日にかけて止めています。

同じお知らせでは、この日付のあとはOffice 365コネクタは動かなくなると書かれています。古いURLを使い続ける方法はありません。

Office 365コネクタで作ったTeamsのWebhookのURLは、作った時期にかかわらずすでに使えなくなっています。

通知を送っていた側は止まったことを知らせてくれない

前の節のとおり古いURLは止まっていますが、困るのは止まったことが目に見えにくい点です。通知は「来ないこと」が普通の日もあるので、1か月来なくても静かなだけだと思われがちです。

送っている側のサービスによっては、送れなかったときに管理画面へエラーを残すものもあります。ただしその画面を見る人がいなければ、誰も気づきません。

止まっているかを確かめる一番早い方法は、Teamsのチャネルで最後に通知が来た日を見ることです。最後の通知が2026年5月の半ばで止まっているなら、この廃止が原因の可能性が高いです。

通知が5月半ばから来ていないチャネルは、送り元が古いURLのままだと考えて確かめます。

Workflowsで新しいURLを作る手順

止まった通知を戻すには、Teamsの中で通知を受け取るための新しいURLを作ります。代わりに使うのは、TeamsのWorkflows（日本語の画面ではワークフロー）です。Workflowsは、Power Automate（Microsoftの自動化のサービス）をTeamsの中から使えるようにしたものです。

Microsoftの説明では、次の手順で新しいURLを作れます（Microsoft LearnのTeamsのWebhookの説明・2026年10月28日の更新）。

1. Teamsで通知を受けたいチームとチャネルを開く
2. チャネルの名前の横の「…」を押し、Workflowsを選ぶ
3. テンプレートの検索で「Send webhook alerts to a channel」のようなWebhookのテンプレートを選ぶ
4. 投稿するチームとチャネルを選んで保存する
5. できあがったWebhookのURLをコピーする

コピーしたURLを、通知を送っていたサービスの設定画面で古いURLと入れ替えます。入れ替えたら送り元から試しの通知を1件送り、チャネルに出るかを確かめます。

冒頭のMicrosoftのお知らせでは、2026年2月からは古い形式の文面（MessageCard）もWorkflowsでそのまま受けられるようになったとされています。多くの場合はURLを替えるだけで済み、送る文面を作り直す必要はありません。

作り直しの中身は新しいURLを作って送り元に貼り替えることで、送り元ごとに1回ずつ行います。

作った人が辞めるとフローが失敗することがある

前の節の手順で作ったWorkflowsは、作った人のフロー（自動で動く手順のまとまり）として作られます。ここが古いIncoming Webhookとの一番の違いです。

Microsoftの説明では、持ち主がいなくなったフローはその人のアカウントにひもづく接続を使っていると失敗することがあるとされています（Microsoft Learnの持ち主が退職したフローの扱い・2026年6月15日の更新）。担当者が1人で作ったまま退職すると、また同じように通知が止まるおそれがあります。

同じ説明では、管理者がフローの共有から新しい持ち主を足す方法が案内されています。作った直後に、もう1人の社員か管理者を共同の持ち主に足しておきます。

Workflowsで作ったら、作った人の名前と共同の持ち主をその日のうちに決めておきます。

1秒に4回と1日6,000回の上限

Workflowsには使える量の上限もあります。TeamsのWebhookの説明では、1秒に4回を超えて送ると一時的に受け付けが止められます。1回の文面は28KBまでとされています。

もう1つはPower Automateの上限です。Microsoftの説明では、Microsoft 365のライセンスで動かすフローは1人あたり24時間に6,000回までの要求が上限です（Microsoft LearnのPower Platformの要求の上限・2026年10月14日の更新）。

問い合わせや監視の知らせが1日に数十件なら、この上限を気にする場面はまずありません。気をつけたいのは、機械が1秒に何件も送る通知や1件の文面が長いログのような通知です。

人が読む量の通知ならWorkflowsの上限に届くことはなく、届きそうなのは機械が大量に送る通知だけです。

Workflowsで足りる会社と送り方を見直す会社

ここまでの話を表にまとめます。御社の通知を当てはめてください。上司に説明するときにもそのまま使えます。

4つとも左の列なら、Workflowsで足ります。今日のうちに新しいURLを作り、送り元に貼り替えて試しの通知を送ってください。

1つでも右の列があるなら、送り方を見直す側です。通知の量を減らすか送り元の設定を触れる人を決めてから作り直してください。

御社が今日やること

次の4つは今日確かめられます。

1. Teamsのチャネルごとに最後に通知が来た日を見て、5月半ばで止まっているものを書き出す
2. 止まった通知ごとに送り元のサービスと設定画面に入れる人を確かめる
3. Workflowsで新しいURLを作り、送り元に貼り替えて試しの通知を1件送る
4. 作ったフローに共同の持ち主を足し、誰が作ったかを社内の手順書に書き残す

やりがちな失敗は、1つのURLを作り直して安心してしまうことです。送り元が3つあれば作り直しも3回必要なので、書き出した一覧を全部終えるまで続けてください。

フォームの通知そのものが届いているかを確かめる方法は、フォームが止まったことに早く気づく方法の記事で紹介しています。LINEに送っていた通知が止まったときはLINE Notifyの代わりの記事も参考にしてください。

弊社がやっていること

弊社では社内の作業をいくつか自動化して毎日使っています。たとえば保守先のサイトが開けるかを10分おきに確かめ、2回続けて開けなければ弊社に通知が届く監視を動かしています。どの自動化も人が最後に確認してから先へ進む形にしています。

つないだサービスの仕様が変わったりアクセストークンの期限が切れたりすると、自動化は止まります。TeamsのIncoming Webhookのようにつないだ先の機能そのものが終わることもあります。そのため止まったことに気づく監視と直しまでを自動化の一部と考えています。

一方で弊社をすすめない場合もあります。

• 送り元が1つか2つでURLを自分で貼り替えられるなら、この記事の手順で足りるので弊社に頼む必要はありません
• Microsoft 365の契約や管理者の設定は御社で行うもので、弊社の作業には含まれません

送り元が多い場合や通知の量が多い場合は、送り方から作り直す自動化の出番になります。弊社で動いている自動化の例は業務の自動化のページに載せています。御社の通知の作り直しで迷うときは相談の窓口からご連絡ください。初回の30分は無料です。