Teams webhookが廃止？Workflows移行を解説！

これまでTeamsのwebhook（受信Webhook）を使って、監視ツールやフォームからの通知をチャネルへ自動投稿していた方は多いはずです。ところが、ある時期から通知がぱたりと止まってしまった、という相談が一気に増えました。

原因はとてもシンプルで、Teamsのwebhookを支えていた「Office 365 コネクタ」という仕組みが廃止されたためです。設定を間違えたわけではなく、放置していると、これまで動いていた自動通知が完全に止まってしまいます。

この記事では、Teamsのwebhookが使えなくなった背景と、代わりになるWorkflows（Power Automate）へ移行して通知を復旧させる手順、そして移行後に「通知が届かない」ときの原因まで、順番に整理していきます。

この記事で分かることは、次の4つです。

• Teamsのwebhookが廃止された理由と、いつ止まったのか
• 廃止後の代替手段であるWorkflowsとPower Automateの関係
• WorkflowsでwebhookのURLを作り直す具体的な手順
• 移行後に通知が届かないときの主な原因と対処法

順を追って読めば、止まってしまった通知を安全に復旧できます。専門的な開発の知識がなくても、画面の操作とURLの差し替えだけで対応できる内容なので、身構えずに読み進めてください。

Teams webhookが廃止された理由と現状

まずは、なぜTeamsのwebhookが使えなくなったのかを整理します。ここを理解しておくと、あわてて別のツールを探さなくても、移行で解決できることが見えてきます。「自分の設定ミス」ではなくTeams側の仕様変更が原因のケースがほとんどです。

そもそもTeamsのwebhookとは何か

Teamsの受信Webhookとは、外部のシステムからTeamsのチャネルへメッセージを自動で投稿するための入り口となるURLのことです。発行されたURLに向けて、送信元のシステムがHTTPのPOSTという方法でデータを送ると、その内容がチャネルにメッセージとして表示されます。

送るデータの本体はJSONという形式のテキストです。人が毎回書き込むのではなく、機械が決まった形で送るため、通知の自動化にとても向いています。

実際の使いどころとしては、サーバー監視ツールのアラート、問い合わせフォームの回答、定期レポートの共有などがあります。相手からの返事を受け取らない一方向の通信なので、仕組みそのものはシンプルです。この手軽さから、多くの現場で通知の土台として使われてきました。

このURLを提供していたのが、次に説明する「Office 365 コネクタ」でした。まずはwebhookはチャネルに文字を流し込む仕組みだと押さえておけば十分です。チャネルそのものの扱いに不安がある場合は、Teams共有チャネルの使い方は？外部招待も解説！もあわせて確認しておくと、投稿先の管理がわかりやすくなります。

ふつうのチャットとの違いは、人が打ち込むのではなく、決まったきっかけで機械が自動的に投稿する点にあります。ボットのように会話へ返事をする仕組みとは違い、受信Webhookは受け取ったデータをそのままカードとして表示するだけです。だからこそ設定がシンプルで、多くのツールが標準で対応してきました。返信を受け取らない一方向という性質を先に押さえておくと、移行した後の使いどころも判断しやすくなります。

なぜTeamsのwebhookは廃止されたのか

結論から言うと、セキュリティを強くするためです。Teamsのwebhookを支えていたOffice 365 コネクタ（Microsoft 365 コネクタ）という仕組み全体が、古い設計のまま残っていたことが背景にあります。

コネクタ型のwebhookは、URLさえ分かれば誰でもチャネルへ投稿できてしまう作りでした。便利な反面、URLが外部に漏れると意図しない投稿を許してしまい、誰が設定したのかを後から追いにくいという弱点があったのです。

そこでMicrosoftは、より管理と監査がしやすいWorkflows（Power Automate）へ通知の仕組みを集約する方針を打ち出しました。新しい仕組みでは、誰が作ったフローなのか、どのアカウントで動いているのかがはっきり残ります。

つまり廃止は不便にするための変更ではなく、安全に運用するための整理です。仕組みの詳しい位置づけは、MicrosoftのWebhook とコネクタの解説ページでも確認できます。理由が分かれば、移行にも納得して取り組めます。

今回廃止されたのはTeamsの受信Webhookだけでなく、Office 365 コネクタという枠組み全体です。RSSの配信など、コネクタを使っていた他の通知も同じ時期に影響を受けました。Microsoftは管理センターのメッセージで事前に案内していましたが、担当者の異動などで見落とされ、気づかないうちに止まっていたという例も少なくありません。自分の環境だけで起きた不具合ではないと分かれば、落ち着いて移行に進めます。

webhook廃止のスケジュールと停止時期

Teams webhookの廃止は、いきなり全部止まったわけではなく、段階的に進みました。大まかな流れを表にまとめます。いつ何が起きたのかを知っておくと、自分の通知が止まった理由を特定しやすくなります。

時期	起きたこと
2024年8月ごろ	コネクタ廃止の方針が告知される
2024年12月末まで	送信先URLを更新すれば期限を延長できた
2025年後半	更新していない既存Webhookが順次停止
2025年末〜現在	コネクタ型の新規作成は不可、移行が必須

ポイントは、2024年末の時点で一度URLを更新した人も、最終的には2025年のうちにコネクタ型そのものが使えなくなったという点です。「前に更新したから大丈夫」と思っていると、いつの間にか止まっていることがあります。

今この記事を読んでいる時点では、コネクタ型のwebhookは新しく作れません。すでに動いていたものも順次止まっているため、残っている通知があれば早めに移行するのが安全です。

もう一つ注意したいのは、利用しているクラウドの種類によって停止のタイミングに差があった点です。一般向けと官公庁向けなどで時期がずれたため、「まだ動いているから平気」と思っていると突然止まることがありました。過去に一度URLを更新した記憶があっても、それで恒久的に使える保証はありません。今から新しく作る場合はコネクタ型を選べないので、最初からWorkflowsで用意するのが確実です。

廃止で自動通知が止まる仕組み

コネクタ型のwebhookが廃止されると、発行済みのURLが無効になります。送信側のシステムは今まで通りそのURLへデータを送り続けますが、受け取り口がなくなっているため、チャネルには何も表示されません。

やっかいなのは、止まったことに気づきにくい点です。エラー画面が大きく出るわけではなく、単に「通知が来なくなった」という静かな止まり方をします。大事なアラートを見落とす原因にもなります。

送信側のログを確認すると、404や410といったHTTPのエラーコードが記録されていることがあります。これは「その宛先はもう存在しない」という意味の合図です。通知が急に来なくなったら、まず送信側のログでエラーが出ていないかを見てください。

逆に言えば、送信側の設定は生きているので、宛先となる新しいwebhookを用意して差し替えれば、通知そのものは復活します。止まったからといって、システムを一から作り直す必要はありません。

通知が来ないときの原因を切り分けるには、webhookが死んでいるのか、チャネル側でミュートしているだけなのかを分けて考えると早いです。自分が手動でそのチャネルに書き込めるなら、チャネル自体は生きています。それでも自動投稿だけが届かないなら、宛先のwebhookが無効になっている可能性が高いです。送信側のログと、チャネルへの手動投稿の両方を試すと、どちらの問題かを素早く絞り込めます。

廃止後に選べる3つの代替手段

コネクタ型のwebhookが使えなくなった後、通知を続ける方法はいくつかあります。用途に合わせて、次の3つから選ぶのが現実的です。もっとも近い代替はWorkflowsの受信Webhookです。

手段	向いている場面
Workflowsの受信Webhook	今までと同じ形で通知を送りたい
Power Automateのフロー	条件分岐や他サービス連携も足したい
Graph APIやBot	本格的な開発で細かく制御したい

多くの人にとっては、いちばん上のWorkflowsの受信Webhookが最適です。今まで使っていたwebhookと考え方がほぼ同じで、URLを作り直して差し替えるだけで移行が完了することが多いからです。

複雑な条件分岐やメール連携まで組みたい場合は、Power Automateのフローを直接組む方法もあります。開発チームが本格的に作り込むならAPIを使う手もありますが、通知を復旧させたいだけなら大げさになりがちです。まずはWorkflowsで置き換えるのが無駄がありません。

どれを選ぶか迷ったら、次の目安で考えると決めやすくなります。

凝った作りにするほど、あとの保守も大変になります。まずは今の通知をそのまま置き換えることだけを目標にすると、移行がぐっと現実的になります。無理に高機能へ寄せず、必要になってから育てていく進め方が結局は長続きします。

移行前に確認したい既存webhookの棚卸し

移行作業に入る前に、どのシステムが古いwebhookを使っているのかを一覧にしておくことをおすすめします。ここを飛ばすと、いくつか差し替え忘れが残り、あとから「この通知だけ来ない」と困る原因になります。

設定ファイルやスクリプトの中に、古いwebhookのURL文字列が埋め込まれていることがよくあります。プロジェクト全体を「webhook」や「office.com」で検索して、使っている場所を先に見つけておくと安心です。

投稿先のチャネルにどんなメンバーがいるかも、この機会に見直しておくとよいでしょう。メンバーの確認方法はTeamsのチャネルでメンバーを確認するには？種類別に解説！で整理しています。棚卸しを済ませてから移行に入るのが、結局いちばんの近道です。

洗い出した内容は、簡単な表にしておくと引き継ぎのときにも役立ちます。どのシステムが、どのチャネルへ、どんな用途で通知しているかを一行ずつ書き出すだけで十分です。切り替えの順番も先に決めておくと、止まっても影響の小さいものから安全に試せます。テスト用のチャネルを1つ用意し、そこで新しいwebhookの動きを確かめてから本番へ広げる、という段取りにしておくと落ち着いて進められます。

Teams webhookの移行手順と使い方

ここからは、実際にWorkflowsで新しいwebhookを作り、送信側を差し替える手順を追っていきます。特別なライセンスがなくても、多くの環境では追加の費用なしで設定できます。全体像をつかんでから、ひとつずつ進めましょう。

WorkflowsとPower Automateの関係

移行先となるWorkflowsは、Teamsの中で使えるPower Automateの入り口にあたります。Power Automateはさまざまな作業を自動化するMicrosoftのサービスで、そのTeams向けの窓口がWorkflowsだと考えると分かりやすいです。

つまりTeamsのワークフローとして作ったものは、裏側ではPower Automateのフローとして動いています。だから、あとから条件を足したり、投稿の見た目を整えたりといった発展もしやすくなっています。

気になる費用ですが、受信Webhookのトリガーは標準の機能に含まれ、多くのMicrosoft 365プランで追加課金なく使えます。有料のプレミアムコネクタを使う高度なフローを組む場合にだけ、別途ライセンスが関わってきます。

通知を今までどおりチャネルへ流したいだけなら、無料の範囲でまかなえることがほとんどです。まずは「Workflowsは実質Power Automate」という点だけ押さえておけば、次の手順で迷いません。

もう一点、Workflowsで作ったフローは、作成した人のアカウントの権限で動くという性質があります。標準コネクタと呼ばれる基本機能の範囲なら追加費用はかかりませんが、外部の有料サービスにつなぐプレミアムコネクタを使うと、別途ライセンスが必要になることがあります。通知をチャネルへ流すだけなら標準の範囲で完結するので、まずは無料でどこまでできるかを試すところから始めるのがおすすめです。

Workflowsアプリの使い方と準備

最初に、Workflowsを開ける状態を整えます。使い方は主に2通りあり、Teams左側のアプリ一覧からWorkflowsを探して開く方法と、投稿したいチャネルの「その他」メニューから入る方法があります。

チャネルから入る場合は、対象のチャネル名の横にある「…」をクリックし、メニューの中から「ワークフロー」を選びます。すると、そのチャネルを投稿先にしたテンプレートがすぐ選べる状態になります。

初めて使うときは、サインインや接続の許可を求められることがあります。これは自分のアカウントでフローを動かすための確認なので、内容を見て進めて問題ありません。どのチームのどのチャネルへ投稿するのかを、先に決めておくとスムーズです。

投稿先を新しく用意したい場合は、テスト用のチャネルを1つ作っておくのがおすすめです。本番のチャネルへいきなり送るより、まずテスト用で表示を確かめたほうが安全に切り替えられます。準備が整ったら、次のテンプレート選びに進みます。

Workflowsが一覧に見当たらないときは、Teamsの検索バーで「Workflows」と入力すると見つかります。よく使うなら、アプリを右クリックして固定しておくと次回から開きやすくなります。会社のアカウントでそもそもメニューに出てこない場合は、管理者が利用を制限していることがあるため、情報システム部門に確認するのが早道です。準備さえ整えば、あとの手順自体は数分で終わります。

Webhook用テンプレートを選んでURLを取得

Workflowsを開いたら、受信Webhook向けのテンプレートを選びます。「Webhook 要求を受信したときにチャネルに投稿する」といった名前のテンプレートを探して選択するのが基本です。次の順で進めます。

1. チャネルの「…」から「ワークフロー」を開く
2. 受信Webhookのテンプレートを検索して選ぶ
3. ワークフローの名前と、投稿先のチームとチャネルを指定する
4. 作成後に表示されるWebリンクをコピーする

ここで手に入るURLが、これまでのwebhookに代わる新しい宛先になります。作成直後にしか全体を確認しづらいことがあるため、コピーはこの場で確実に済ませておきましょう。

公式の手順は、Microsoftの受信Webhookを使ってTeamsでメッセージを送信する解説と、ワークフローで受信Webhookを作成する解説にも画像つきでまとまっています。画面の文言が変わっても、テンプレを選んでURLを取る流れは共通です。取得したURLは、次のステップで送信側に設定します。

ワークフローの名前は、あとで見て用途が分かるものにしておくと管理が楽になります。「監視アラート通知」のように具体的につけておくと、数が増えてきたときに迷いません。取得したURLはパスワードと同じくらい大切な情報なので、公開の場所に貼らないよう気をつけてください。URLを知っている人は誰でもそのチャネルへ投稿できてしまうため、共有する範囲は必要な人だけに絞るのが安全です。

送信側システムのURLと形式を直す

新しいURLが手に入ったら、送信側システムの設定を古いURLから新しいURLへ差し替えます。ここまでは比較的わかりやすい作業ですが、実はもう一つ見落としやすいポイントがあります。それは、送るデータの形式です。

古いコネクタ型では、MessageCardという形式で送るのが一般的でした。ところがWorkflowsの受信Webhookは、Adaptive Cardという新しい形式を包んだデータを受け取ります。URLだけ変えて古い形式のまま送ると、通知が届かない、または中身が表示されないことがあります。

新しい形式では、外側を{"type":"message","attachments":[...]}で包み、その中にカードの内容を入れます。旧形式の{"@type":"MessageCard","text":"本文"}とは構造が違うため、送信側のテンプレートを新形式に書き直す必要があります。

まずはシンプルなテキストを1件送ってみて、テスト用チャネルに正しく表示されるかを確かめてください。表示を確認できてから、本番のシステムを新しい形式へ切り替えるのが安全な進め方です。

Adaptive Cardは、見出しや本文、ボタンなどを部品として組み立てられる新しいカードの形式です。最初から凝ったデザインにする必要はなく、まずは短いテキストが1行だけ表示される最小の形で試すのがおすすめです。最小の形で届くことを確認してから、少しずつ項目を足していくと、どこで崩れたのかが分かりやすくなります。送信側にサンプルが用意されている場合は、それを新しい形式へ置き換えるところから始めると迷いません。

移行後に通知が届かない原因と対処

差し替えたのに通知が来ない、というときは、いくつか決まった原因があります。あわてて作り直す前に、次のチェックリストを上から順に確認してみてください。

特に多いのが、いちばん上の形式の作り直し忘れです。URLだけ直しても、旧形式のデータでは受け取ってもらえません。前のステップで説明した新しい形式に合わせているか、もう一度見直してください。

フローの所有者が異動や退職でアカウントを失うと、そのフローも止まります。長く使う通知は、個人ではなく共有アカウントで作っておくと安定します。設定を足す場所に迷ったら、投稿先チャネルの整え方としてTeamsのタブにファイルを追加するには？手順を解説！も参考になります。

それでも解決しないときは、Workflows側の実行履歴を確認すると手がかりが見つかります。フローが動いた記録が残っていれば、受け取ってから投稿までのどの段階で止まったのかが分かります。短い時間に大量の通知を送ると、一時的に制限がかかって届きにくくなることもあります。まとめて送る設計になっている場合は、送る間隔を少し空けると安定します。履歴を見れば、送信側とTeams側のどちらの問題かを切り分けられます。

Teams webhookの移行を成功させるまとめ

最後に、Teams webhookの移行で大事な考え方をまとめます。廃止されたコネクタ型のwebhookをそのまま放置せず、Workflowsの受信Webhookへ段階的に移していくのが基本の流れです。

進め方のコツは、いきなり本番を切り替えないことです。まずテスト用のチャネルで、新しいURLと新しい形式のデータが正しく届くかを確認します。ペイロードの形と投稿の権限を確かめてから、本番のシステムを切り替えれば、通知が途切れるリスクを抑えられます。

もし今まさに通知が止まっているなら、送信側のログでエラーを確認し、Workflowsで新しいwebhookを作り、URLと本文の形式をそろえて差し替える、という順で進めてください。Teamsのwebhookは廃止されましたが、Workflowsへ移行すれば通知そのものはこれまで通り続けられます。あわてず、棚卸しから一つずつ片付けていきましょう。

移行はまとめて一気にやろうとすると負担が大きくなります。棚卸しで作ったリストをもとに、影響の小さい通知から順に置き換えていけば、業務を止めずに切り替えられます。一度Workflowsに慣れてしまえば、次からの通知づくりはむしろ簡単です。廃止をきっかけに、通知の仕組みを整理し直すよい機会だと捉えて進めてみてください。

webhook移行に関するよくある質問

ここでは、Teamsのwebhook廃止とWorkflowsへの移行について、特に相談の多い疑問に答えます。細かな仕様は環境によって変わるため、最終的には自組織の設定もあわせて確認してください。

Teamsのwebhookは完全に使えなくなった？

古いコネクタ型の受信Webhookは、順次停止されて使えなくなりました。ただしwebhookという仕組み自体がなくなったわけではありません。Workflowsの受信Webhookを使えば、外部システムからチャネルへ通知を送ることは今でも可能です。名前と作り方が変わっただけで、やりたいことは引き続き実現できます。むしろ新しい仕組みのほうが、誰が作ったフローなのかがはっきり残るため、長く安全に運用しやすくなっています。止まってしまった通知があっても、作り直して差し替えれば元どおりに戻せます。

Workflowsに有料ライセンスは必要？

チャネルへ通知を送る基本的な受信Webhookは、標準の機能に含まれており、多くのMicrosoft 365プランで追加の費用なく使えます。有料のライセンスが関わるのは、プレミアムコネクタと呼ばれる高度な連携を組む場合です。単純な通知の置き換えであれば、まずは無料の範囲で試してみるとよいでしょう。実際に受信Webhookのテンプレートを選び、テスト用チャネルへ1件送ってみれば、追加の費用が要るかどうかは動かしながら確認できます。高度な連携が必要になった段階で、あらためてライセンスを検討すれば十分です。

無料版や個人のTeamsでも使える？

Workflowsは、職場や学校向けの組織アカウントでの利用が基本です。個人向けアカウントや無料版のTeamsでは、機能が制限されていたり、管理者の設定でワークフローが使えなかったりすることがあります。会社のアカウントでワークフローのメニューが出てこない場合は、管理者の許可設定を確認してもらうのが早道です。個人用のアカウントで自動通知を本格的に組みたいときは、職場や学校向けのプランへ切り替えるか、別の通知サービスを検討するほうが現実的です。まずは自分のアカウントがどの種類なのかを確かめておくと、対応の方針が決めやすくなります。

旧webhookのURLはそのまま使える？

いいえ、古いコネクタ型のURLはそのままでは使えません。Workflowsで新しく作り直し、発行された別のURLへ差し替える必要があります。あわせて、送るデータの形式もAdaptive Cardを包む新しい形へ直します。URLと形式の両方をそろえることで、通知が正しくチャネルへ届くようになります。古いURLを残したままにしておいても害はありませんが、混乱を避けるために、差し替えが済んだら送信側の設定から消しておくと安心です。新旧を並行して動かす必要はなく、確認が取れ次第、新しい方に一本化するのが分かりやすい進め方です。