Teams のワークフローで Webhook を作り直す｜旧 Office 365 コネクタからの移り方

監視ツールや社内のシステムから Teams に届いていた通知が、来なくなった。旧 Office 365 コネクタ（日本語のページでは「Microsoft 365 コネクタ（以前は Office 365 コネクタ）」とも呼ばれます。以下「旧コネクタ」）の受信 Webhook で送っていたなら、旧コネクタは2026年5月に止まっています。ところが、Teams の［アプリ］の一覧や日本語版の Microsoft Learn には廃止前の説明が残っていることがあり、通知が来なくなった理由が旧コネクタの停止だと気付きにくい状態です。

直し方は、Teams の［ワークフロー］で Webhook を受けるワークフローを作り直し、送り元の URL を新しいものに替えることです。ただし新しい Webhook はチャネルではなく作った人に付くので、URL を替える前に、誰の名前で作るかを決めておきます。

Microsoft 365 の導入を支援している当社が、Microsoft の公式の説明と、当社の検証用の環境の画面で確かめて書いています。Power Automate のフローを一から組む方法、有料のコネクタが要る場面、Teams のアプリやボットを開発して通知する方法は扱いません。

移すときにやること

止まった通知を元に戻すためにやることを、順に並べると次のとおりです。ここだけ読めば作業は始められます。

1. 旧コネクタの URL（…webhook.office.com/… の形）を設定していた送り元（監視ツール、社内のシステム、スクリプト）と、投稿先のチャネルを一覧にする。
2. 誰の名前でワークフローを作るかを決める（下の「持ち主」の節）。
3. Teams の［ワークフロー］で、Webhook を受けて投稿するテンプレートからワークフローを作る。
4. 送っている JSON にボタンがあれば、アダプティブ カードに直す。
5. 送り元の URL を新しいものに替え、テストの文を1回送って投稿を見る。
6. 新しい URL をどの送り元に入れたかを控える。

この記事に関連するサービス

AI活用支援生成AIを、業務に組み込むところまで詳しく見る →Claude 導入支援Claudeを、会社の決まりの中で使える状態まで。詳しく見る →ChatGPT 導入支援ChatGPTを、会社の決まりの中で使える状態まで。詳しく見る →AIセキュリティ診断・規約・ルール整備AIを使う前に、出す前に。安全の確認と、規約・ルールの整備を詳しく見る →Microsoft 365 導入支援Exchange・SharePoint・Teamsの移行から権限設計・Copilot活用まで詳しく見る →

「URL を替えれば元どおり」ではない

旧コネクタの受信 Webhook は、チャネルの設定から足すもので、URL はそのチャネルに付いていました。ワークフローは違います。ワークフローは特定のユーザー（ワークフローの所有者）に結びつき、チームやチャネルには結びつきません。共同所有者がいないまま所有者がいなくなると、ワークフローは持ち主のいない「孤立した」フローになりえます（Create an Incoming Webhook）。

つまり、担当者が自分の名前で作って URL を差し替えれば、その日は元どおりに通知が届きます。けれども、共同所有者がいないまま、その人が退職などで組織からいなくなると、ワークフローは持ち主のいない状態になりえます。旧コネクタのときには考えなくてよかった「誰の名前で作るか」を、作る前に決めておく必要があります。決め方は後の節で書きます。

旧コネクタはいつ止まったか

Microsoft は 2024年7月3日に Teams の Office 365 コネクタの廃止を発表し、その後、期限を何度か延ばしました。延長のあいだに、ワークフロー側でメッセージ カード（旧コネクタで使われていた JSON の形）を受け付けるようになり、共有チャネルにも投稿できるようになっています。最後の告知（2026年4月14日の更新）では、2026年5月18日に停止を始め、2026年5月22日までに終えるとし、その後はコネクタが動かなくなると書いています（Microsoft 365 Developer Blog「Retirement of Office 365 connectors within Microsoft Teams」）。

英語版の Microsoft Learn も、受信 Webhook を含むコネクタは2026年5月に廃止されたと書いています（Create an Incoming Webhook）。一方で、当社が 2026年10月29日に見たときは、日本語版の同じページ「受信 Webhook を作成する」は「非推奨に近づいています」という廃止前の書き方のままで、当社の検証用の環境の Teams の［アプリ］で「Webhook」と検索しても、「Incoming Webhook (to be retired)」がまだ一覧に出て、説明は「The app will retire on Dec 31, 2025.」のままでした。日付を確かめるときは、英語版の Learn か上のブログを見てください。

テンプレートは「投稿先」と「呼べる人」で選ぶ

Microsoft サポートが Webhook 用に挙げているテンプレートは、チャット向け3つ・チャネル向け3つで、テンプレートごとに認証の種類が違います（受信 Webhook を使用して Teams でメッセージを送信する）。認証の種類とは、その URL に誰が送れるかのことで、誰でも、テナント（自社の Microsoft 365）の全ユーザー、テナントの特定のユーザーの3つがあります（Microsoft Teams のコネクタ リファレンス）。

旧コネクタの URL と同じ使い方、つまり外のサービスから URL に送るだけで投稿させたいなら、誰でも呼べるテンプレート（［Webhook アラートをチャットに送信する］か［Webhook アラートをチャネルに送信する］）を選びます。どのテンプレートを誰が呼べるかは、テンプレートの名前と一覧の説明文から読んだもので、当社が［誰でも］の設定を画面で確かめたのはチャット向けだけです。誰でも呼べる場合は、URL を知っていれば誰でも投稿できるので、URL はパスワードと同じに扱います。組織のユーザーや特定のユーザーに絞るテンプレートでは、送る側が要求に認証のトークンを付ける必要があり、誰でも呼べる設定でトークンを付けると失敗します。トークンを付けられない監視ツールからは送れないので、送り元の作りを確かめてから選びます。

プライベート チャネルに投稿したい場合も、ワークフローで作れます。ワークフローの Webhook はプライベート チャネルに対応していて、Power Automate のポータルからも Teams の［ワークフロー］からも設定できます（Create an Incoming Webhook）。当社の検証はグループ チャットへの投稿だけで、プライベート チャネルを含め、チャネルへの投稿は試していません。チャネルに届いていた通知を移すときは、「移すときにやること」の手順5のテストで、そのチャネルに届くかを見てください。

なお、これらのテンプレートと Teams の Webhook トリガーを使うのに、Power Automate のプレミアム ライセンスは要りません（サポート）。

テンプレートから Webhook のワークフローを作る

Teams の左の［アプリ］を開き、一覧の［ワークフロー］を選んで、上の検索に「Webhook」と入れます。当社が見たときは、アプリの検索結果と並んで「ワークフロー (10)」が出て、10個のテンプレートが並びました。チャット向け・チャネル向けの6つのほかに、名前の後ろに (TEST) が付いたもの、英語の名前のもの、［受信する Webhook を使用して Teams チャットに投稿する］もありました。この記事では (TEST) の付かない［Webhook アラートをチャットに送信する］を使いました。

テンプレートを選ぶと、［名前］と［接続］の画面が出ます。［名前］の既定はテンプレート名のままなので、何の通知かが分かる名前に替えておくと、後で一覧から探しやすくなります。［接続］には「このワークフローを実行するには、すべてのアプリに有効な接続が必要です。」とあり、Microsoft Teams の接続に作る人のアカウントが入ります。この接続が作った人のものだということが、後の「持ち主」の話につながります。

当社の検証用の環境では、Teams の中のこの画面で［次へ］を押しても先に進まなかったため、同じテンプレートを Power Automate（make.powerautomate.com）の［テンプレート］から開いて続けました。［次へ］の先の画面は、当社は見ていません。Teams の［ワークフロー］で作ったものも、中身は Power Automate のフローです。テンプレートの画面では「このフローの接続先は次のとおりです: Microsoft Teams」の後に［続行］を押し、投稿先の［Microsoft Teams グループ チャット］を選んで［作成］を押します。当社が試したときは、この欄に自分1人だけが参加しているグループ チャットが1つ出て、それを選びました。

新しい URL の形と取り出し方、呼べる人を確かめる

URL は、フローの最初の手順（トリガー）［Teams Webhook 要求を受信したとき］の［HTTP URL］にあります。保存する前は「保存後に URL が生成されます」と出ていて、保存すると「フローを開始する準備ができました。テストすることをお勧めします。」の表示とともに URL が入りました。サポートは、作成後の詳細ページで Webhook の URL をコピーできると書いています。当社が Power Automate で作ったときは詳細ページに URL が見当たらず、［編集］でトリガーを開いてコピーしました。

当社が作ったときの URL は、次の形でした（<> の中は伏せた部分）。

https://<ID>.<2桁>.environment.api.powerplatform.com/powerautomate/automations/direct/cu/<数字>/workflows/<ID>/triggers/manual/paths/invoke?api-version=1&sp=…&sv=1.0&sig=<署名>

旧コネクタの URL（…webhook.office.com/…）とはホストが違います。検証で作った2本の URL は、どちらも 255 字を超えていました（300 字前後）。Learn のトラブルシューティングも、新しい URL が 255 字を超えることがあると書いています（Power Automate トリガーに関する一般的な問題のトラブルシューティング）。送り元の URL の欄に字数の上限があるなら、貼る前に確かめます。/cu/ の後ろの数字は、2026年6月2日からの変更で URL に入るようになった処理単位の番号で、検証で作った2本では違う数字でした。

URL の末尾の sig= が署名で、誰でも呼べる設定では、これを含む URL を知っていることが送る資格になります。そのため、URL はチャットやチケットに貼らないようにします。また、Power Automate 側の基盤の変更で、URL に logic.azure.com を含む HTTP トリガー・Teams Webhook トリガーは 2025年11月30日に新しい URL へ移り、古い URL は動かなくなりました（同じトラブルシューティング）。旧コネクタからの移行だけでなく、ワークフローの URL も替わることがあります。手順の6で URL の入れ先を控えるのは、このためです。

URL の上の［フローをトリガーできるユーザー］が、この URL に送れる人です。当社が使ったテンプレートでは［誰でも］が入っていました。開くと［自分のテナントのすべてのユーザー］・［自分のテナントの特定のユーザー］・［誰でも］・［カスタム値を入力する］が選べ、テンプレートを選んだ後でもここで変えられます。

送るデータの形を確かめる：メッセージ カードのままか、アダプティブ カードに直すか

送り元は、この URL に JSON を POST で送ります。トリガーは POST だけを受け付け、GET には応じません（Microsoft Teams のコネクタ リファレンス）。本文の形は2つです。1つはアダプティブ カードを入れる形で、type に “message”、attachments の配列の中に contentType “application/vnd.microsoft.card.adaptive” とカード本体を入れます。もう1つは旧コネクタで使われていたメッセージ カード1枚の形です。

旧コネクタから移すときは、メッセージ カードの形のまま使い続けられます。ただし、メッセージ カードの中身は表示されても、HttpPost のボタンは使えません。トリガーは、旧コネクタが対応していた「操作可能なメッセージ」にも対応していません。旧コネクタで「承認」「対応済みにする」のようなボタンを押させていた通知は、アダプティブ カードに直し、押した後の処理を別に作る必要があります。当社の検証で送ったのはアダプティブ カードだけで、メッセージ カードは送っていません。

ほかに、Learn は次の制限を挙げています。1回のメッセージは 28 KB まで。1秒に4件を超えて送ると絞られます。カードの文字には基本の Markdown が使え、HTML は無視されて文字のまま出ます（Create an Incoming Webhook）。監視ツールの通知を大量に送る使い方では、送る側でまとめるか間引く作りにします。

テンプレートで作ったフローの中は、受け取った本文に attachments があるかどうかで分かれ、それぞれカードを投稿する作りでした（［Teams Webhook 要求を受信したとき］の後に、本文と attachments を取り出す手順、その後に分かれ道）。当社が通したのはアダプティブ カードの側だけです。

投稿はどう見えるか

投稿の手順の［投稿者］は［フロー ボット］で、［投稿先］はグループ チャットでした。ワークフローの Webhook で送った投稿は既定のワークフローのボット（Flow bot）として出て、アダプティブ カードでは独自のアイコンや表示名は使えません（Microsoft 365 Developer Blog）。

当社の検証では、架空の短い文（「検証用の通知（架空）」「夜間バッチが終了しました。これは動作確認のための架空の文です。」）をアダプティブ カードで送りました。URL を記録に残さないよう、ブラウザの中から POST しています（curl や PowerShell からは試していません）。応答は 202（受け付けた）で、数秒後にチャットにカードが届きました。

投稿者は「ワークフロー」と出て、カードの下には英語で「<作った人の名前> used a Workflow template to send this card.」と、作った人の名前が添えられていました。その前には、チャットに「<作った人の名前> さんがWorkflowsをここに追加しました。」という知らせも出ています。旧コネクタのように送り主の名前を「監視システム」などにはできず、作った人の名前はチャットの参加者に見えます。誰の名前で作るかは、この見え方にも関わります。

202 は「受け付けた」という意味で、カードの投稿まで成功したかは、この応答では分かりません。送った後は、フローの詳細の［28 日間の実行履歴］で［成功］になったかを見ます。

止めないために：持ち主を決め、使わなくなったら片付ける

フローの詳細には［主要な所有者］と［共同所有者］の欄があり、作った人が主要な所有者になっていました。共同所有者がいないと、所有者がいなくなったときに孤立したフローになりえます。管理者が後から共同所有者を足して全権を渡すこともできます（Create an Incoming Webhook）。ただ、後から足すのは持ち主がいなくなった後の手当てです。チャネルに届く通知のように、複数の人が頼りにするものは、作った直後に共同所有者を足しておきます。［共同所有者］の欄はフローの詳細の右側にあり、欄には［主要な所有者を設定する］と［共有］が並んでいました（下の、実行の履歴の写真）。当社は共同所有者を足していないので、その先の画面は開いていません。

もう1つ、ワークフローを作る節で見たとおり、このワークフローの Teams の接続は作った人のアカウントで入っています。有効な所有者がいなくなったフローは、そのユーザー アカウントに結びついた接続を使っていると失敗することがあります（所有者が組織を離れたときに孤立したフローを管理する）。持ち主のいないフローを引き継ぐときは、管理者が接続の認証を足したり、止まっていたフローをオンに戻したりもできます（Create an Incoming Webhook）。そのため、共同所有者を足すときに、作った人のアカウントが無くなったら接続をどのアカウントで入れ直すかも、あわせて決めておきます。

Outlook のメールを Teams に知らせるフローでも、同じく「誰の名前で動かすか」が問題になります。所有者のライセンスと接続で動くことは、Outlook×Teams メール通知のフローは誰の名前で動かすかで書いています。

使わなくなったときは、止めるか消すかを選びます。オン／オフはメニューから切り替えられ、削除は確認の画面で［削除］を押すと完全に消えます。削除の確認の画面には「このフローを削除すると、すべての共同所有者に対して削除され、すべてのユーザーからアンインストールされます。この操作は元に戻せません。」とありました。消すと URL も使えなくなり、作り直すと URL が変わります。ワークフローを作り直して置き換えるときは、送り元を全部新しい URL に替え終わってから古いほうをオフにし、届かなくなった通知が無いのを見てから消すと、戻れなくなる心配がありません。

1本作ったら、まず共同所有者を足す

旧コネクタの URL が入っている送り元を探して作り直す手順は、「移すときにやること」のとおりです。そのうえで、ワークフローを1本作ったら最初に済ませておきたいのは、共同所有者を足すことです。

理由は2つあります。トリガーの URL は Power Automate 側の変更で替わることがあり（2025年11月30日には古い URL が動かなくなりました）、作った人がいつまでその組織にいるかも、作った時点では決められません。

URL が替わったときは、フローを開ける人がもう1人いれば、作った人を待たずに送り元を差し替えられます。Learn のトラブルシューティングによると、2025年11月30日の変更のときは、対象のフローの詳細ページかデザイナーに、古い URL がその日に動かなくなると予告する警告のバナーが出る、とされていました。バナーには置き換えられた古い URL が示され、新しい URL はデザイナーのトリガーに出ます（当社はこのバナーを見ていません）。この変更の対象は URL に logic.azure.com を含むフローです。当社が作ったワークフローの URL は、logic.azure.com ではなく environment.api.powerplatform.com でした。

作った人がいなくなったときは、共同所有者が持ち主として残ります。そのうえで残るのが、持ち主の節で書いた、Teams の接続をどのアカウントで入れ直すかです。共同所有者を足すときに、あわせて決めておきます。

当社は Microsoft 365 の導入支援の中で、Teams の通知の仕組みの移し方や、ワークフローの持ち主の決め方のご相談も受けています。

この記事の確かめ方：止まった日程は英語の原文で確かめ、Microsoft の資料は、すべて 2026年10月29日に開いたものです。画面は、同じ日に当社の検証用の環境で Teams の Web 版と Power Automate を操作したものです。検証では、チャット向けのテンプレートからワークフローを2本作り、自分1人だけが参加しているグループ チャットに架空の短い文を送って投稿を確かめ、2本とも削除しました。チャネル向けのテンプレートと、チャネルへの投稿は試していません。画面の名前はその表示に合わせ、写真では組織名・人の名前と、URL の ID の部分を伏せています。