TeamsでWebhookコネクタ廃止後も、通知そのものは止めずに維持できます。結論から言うと、固定チャネルに送る一般的な通知は Workflows の Teams webhook へ寄せるのが第一候補です。対話型カードや「人ではなくアプリとして送る」要件が強い通知は Teams ボット、複数部門や顧客に配る製品機能として作るなら Power Automate のカスタムコネクタ＋テンプレートが長期運用に向きます。逆に、Microsoft Graph を Webhook の単純代替として選ぶのは危険です。通常のチャネル投稿は委任権限が基本で、アプリ権限は移行用途に限定されています。なお、期限は古い記事でばらつきますが、Microsoft 365 Developer Blog の 2026年2月5日更新ではコネクタ廃止期限は 2026年4月30日まで延長されています。 (Microsoft for Developers)
この記事では、Teams の Webhook コネクタ廃止後に通知を維持するために、何を Workflows に移し、どこから Bot や別設計へ切り替えるべきかを、仕様差・判断基準・移行手順・失敗しやすいポイントまで実務目線で整理します。
2026年3月31日時点で、まず知っておくべきこと
まず大事なのは、検索結果に古い期限が混ざりやすいことです。2024年や2025年の期限が載ったページも残っていますが、現時点では Microsoft の公式ブログ追記を優先して読むのが安全です。加えて、Workflows 側はこの1年でかなり改善されており、Message Card 形式のサポートが追加され、shared channel への Flow bot 投稿も進みました。一方で、ボタン描画は非対応、private channel はなお注意領域、フローはユーザー所有という前提は残っています。 (Microsoft for Developers)
公式情報を、実務で迷わない形にまとめると次の通りです。
| 観点 | 実務上の見方 |
|---|---|
| 廃止期限 | 2026年4月30日まで延長されたが、延命前提で考えない |
| 第一候補 | 固定チャネル・定型通知は Workflows |
| カード互換 | Message Card は寄せやすくなったが、ボタンはそのまま移植しない |
| 宛先 | shared channel は改善、private channel は本番前の検証必須 |
| 運用 | フロー所有者の退職・異動を前提に owner / co-owner 設計が必要 |
この整理の根拠は、Microsoft の最新ブログ更新、Teams Learn ドキュメント、Support 記事にある最新仕様差です。Workflows ベースの incoming webhook はチャネルだけでなくチャットにも投稿でき、テンプレートでは認証方式も選べます。 (Microsoft for Developers)
まず、今の通知を4種類に分ける
Teams の Webhook コネクタ廃止後に通知を維持したいなら、最初にやるべきことは「何の通知か」を分けることです。ここを分けずに全部 Workflows へ寄せると、後で詰まります。
固定チャネルに送るだけの通知
たとえば、CI/CD の成功・失敗、夜間バッチ完了、監視アラートの要約、フォーム受信通知です。
送る先がほぼ固定で、本文も定型なら、もっとも Workflows と相性がいい領域です。
個人やグループチャットにも飛ばしたい通知
障害当番への個別通知、申請者への進捗通知、営業担当ごとのアラートなどです。
このタイプは、単なる channel webhook 置換ではなく、チャットを含めた宛先設計が必要になります。
ボタンや応答が必要な通知
「承認する」「再実行する」「チケットを起票する」といった操作をカード上で完結させていた通知です。
このタイプは、メッセージ形式の互換性だけでなく、操作後の処理まで見ないと移行で失敗します。
製品機能として複数チームや複数顧客に配る通知
SaaS 側から各社の Teams へ通知する、各部署が自分で通知先を設定できるようにする、といったケースです。
この場合は単なる webhook URL の差し替えではなく、利用者にどう設定してもらうかが主題になります。
結論：選び方はこの4択
| 方式 | 向いているケース | 強み | 注意点 |
|---|---|---|---|
| Workflows の Teams webhook | 固定チャネル・定型通知を早く移したい | Teams 内で作れて導入が早い | owner 依存、private channel は要検証、ボタン互換に注意 |
| Teams ボット | アプリ主体で送りたい、個人通知したい、対話型にしたい | 送信者を bot にでき、個人・グループ・チャネルに展開しやすい | インストール前提、実装と運用が重い |
| Power Automate カスタムコネクタ | 複数部署・複数顧客向けに再利用したい | 自社 API を Power Automate に載せられる | ライセンスとガバナンス設計が必要 |
| Microsoft Graph | ユーザー文脈の処理や周辺制御 | API で周辺制御しやすい | 一般的な unattended 通知の置換には向かない |
この比較のポイントは、Workflows の webhook テンプレートと認証方式、Bot の proactive messaging 要件、Graph の権限制約、Power Automate のカスタムコネクタ方針にあります。特に Graph は、通常のチャネル投稿では委任権限 ChannelMessage.Send が基本で、アプリ権限 Teamwork.Migrate.All は移行用途です。Webhook の置き換え先として真っ先に Graph を選ぶのは外しやすい判断です。 (マイクロソフトサポート)
Workflows を第一候補にするケース
向いている通知
次のような通知は、まず Workflows を疑って問題ありません。
- ビルド失敗やデプロイ完了の通知
- 監視アラートのサマリー
- フォーム送信、申請受付、タスク期限切れ
- 定時実行ジョブの成否
- 1つのチームやチャネルに集約したい社内通知
Workflows ベースの incoming webhook は、Teams 内でテンプレートから作成でき、チャネルやチャットに投稿できます。さらに、Teams webhook trigger は premium ライセンス不要と案内されています。まず止血したい通知には、かなり現実的です。 (マイクロソフトサポート)
認証タイプの決め方
Workflows の webhook は、作成時に呼び出し元の認証条件を選べます。
| 認証タイプ | 向いているケース | 実務上の判断 |
|---|---|---|
| Anyone | 外部サービスや既存スクリプトから早く移したい | 速いが、URL を秘密情報として厳格に扱う |
| Any user in my tenant | 社内ツールや社内 API から呼ぶ | 社内利用の標準候補 |
| Specific users in my tenant | 呼び出し元を絞りたい重要通知 | セキュリティ優先のときに有効 |
注意したいのは、認証方式で実装の難しさが変わることです。ドキュメント上も、Anyone を選んだ場合は認証トークンヘッダーを付けると失敗し、Any user in my tenant や Specific users in my tenant を選んだ場合はトークンが必要です。単純に「より厳しい設定が常に正解」とは限りません。社内システムで Entra ベースの呼び出しを用意できるかまで含めて決めるべきです。 (マイクロソフトサポート)
カード形式で詰まりやすい点
ここは一番誤解しやすいところです。
Microsoft の 2026年2月5日更新では、Workflows で Message Card サポートが利用可能になったと案内されています。一方で、button rendering は非対応と明記されています。さらに Teams コネクタのドキュメントは、Teams webhook trigger の本文スキーマを Adaptive Card 前提で説明し、deprecated Office Webhooks のような actionable messages はサポートしないと記載しています。 (Microsoft for Developers)
実務では、次のように考えると失敗しにくいです。
- テキスト中心の通知
Message Card 寄せで進めやすい - 色分け・見出し・リンク程度の装飾
Workflows へ比較的移しやすい - ボタン押下で処理が続く通知
そのまま移植せず、Adaptive Card か Bot への再設計を前提にする
「JSON が送れたから移行完了」ではありません。受信側でどう見え、押したあと何が起きるかまで確認して、初めて移行完了です。
運用で絶対に外せない点
Workflows はチーム所有ではなく、特定ユーザーの所有物です。所有者が退職・異動すると orphan flow になり、接続や実行が止まるリスクがあります。Microsoft も co-owner 追加を推奨しており、Power Automate 側では solution-aware flow にして owner を変更したり、必要に応じて service account や Service Principal application user を owner にする運用も案内しています。 (Microsoft Learn)
実務では、最低でも次の3点をセットにしてください。
- co-owner を最低2名つける
- 業務重要度が高いものは solution-aware flow 化を検討する
- 可能なら 個人アカウントではなく運用用アカウントに寄せる
高頻度通知は「送る前に絞る」
監視や CI の通知をそのまま Teams に全部流す設計は、旧 Webhook 時代よりも危険です。Teams webhook trigger のスロットリングは Power Automate の performance profile に依存し、Teams 側の投稿アクションにはおおむね 28 KB のメッセージサイズ制限もあります。Graph のドキュメントも、Teams をログファイルのように使うのは利用条件違反だと明記しています。 (Microsoft Learn)
おすすめは、次の設計です。
- 同一障害は 5分単位で集約
- 本文は 要約＋重要度＋リンク に絞る
- 詳細ログや stack trace は外部の監視基盤やチケットへ逃がす
- 瞬間的に大量発生する通知は キューやバッファ を挟む
Webhook 廃止後の移行で本当に大事なのは、「どの URL に POST するか」より、Teams に流す粒度をどこまで細くするかです。
Bot や別設計に切り替えるべきケース
Teams ボットが向く場面
次の条件があるなら、最初から Bot を検討したほうが早いです。
- 通知の送信者を ユーザーではなくアプリにしたい
- 個人チャットへ proactive に送りたい
- ボタン付きカードや返信・再実行などの対話を重視したい
- 定期通知、イベント通知、個別通知を広く扱いたい
Teams の Bot は、personal chat・group chat・channel で通知を送れます。Adaptive Card も使えます。ただし、送信先の scope に bot を含むアプリが事前インストールされていることが前提です。必要に応じて Graph やポリシーで proactive install を組み合わせる設計になります。Workflows より重いですが、「人の名前で出る通知」をやめたいときには最有力です。 (Microsoft Learn)
Power Automate カスタムコネクタが向く場面
自社サービスから Teams 通知を提供するなら、各ユーザーに webhook URL を貼ってもらう方式は長持ちしません。
このとき有力なのが、自社 API を Power Automate のカスタムコネクタとして公開し、フローテンプレートで Teams 投稿先を選ばせる設計です。
この方式が向くのは、たとえば次のケースです。
- 複数部署がそれぞれ通知先を設定したい
- 顧客ごとに Teams の投稿先が違う
- 通知以外にも、承認やデータ同期と組み合わせたい
- 将来的に Teams 以外の SaaS 連携も広げたい
Microsoft Learn でも、enterprise developers / ISVs 向けに、custom connectors、テンプレート公開、UI の埋め込みといった拡張方法が整理されています。ただし、premium / custom connectors のライセンスや Entra 認証設計が入るので、情シスと開発の両方を巻き込んだ設計が必要です。 (Microsoft Learn)
Graph API を主役にしないほうがいい場面
「Webhook がなくなるなら Graph で直接送ればよい」と考えがちですが、ここは落とし穴です。
Teams チャネルへ通常のメッセージを送る Graph API は、least privileged では delegated の ChannelMessage.Send が必要です。application permission の Teamwork.Migrate.All は migration 用で、一般的なサーバー通知の置き換えとして使う前提ではありません。しかも Microsoft は、Teams をログファイルのように使うなとも明記しています。 (Microsoft Learn)
つまり Graph は、
- Bot の proactive install
- ユーザー文脈のメッセージ送信
- Teams リソースの周辺制御
には有効ですが、無人のバックエンドから固定チャネルへアラートを打つだけなら、主役にしないほうが安全です。
失敗しやすいポイント
| よくある失敗 | なぜ危険か | 回避策 |
|---|---|---|
| 旧 connector の URL 更新だけで終える | 一時延命に近く、次の見直しがすぐ来る | URL 更新は暫定対応、本命は Workflows / Bot へ |
| ボタン付き Message Card をそのまま移す | 表示や動作が揃わない | Adaptive Card か Bot 前提で設計し直す |
| フローを個人所有のまま本番化する | 異動・退職で止まりやすい | co-owner、solution-aware、運用アカウント |
| Teams に全文ログを流す | 読まれず、制限にも当たりやすい | 要約＋リンクへ変える |
| private channel を最後まで未検証にする | 仕様差で本番直前に詰まりやすい | 先に PoC するか Bot を選ぶ |
| Workflows アプリの許可状態を見ない | テンプレートや投稿アクションが使えない | Teams 管理センターの allow 状態を確認する |
上の失敗は、実際にはすべて「移行先を機能で選んでいない」ことから起こります。旧 URL の延命や JSON の互換だけを見ると、最後に運用で破綻します。Microsoft の公式情報でも、旧 URL 更新は一時的な移行措置として扱われ、Workflows や別方式への移行が推奨されています。 (Microsoft for Developers)
止めずに移行する実践手順
| 手順 | やること | 見るポイント |
|---|---|---|
| 1 | 既存通知を棚卸しする | 送信元、送信先、件数、カード形式、ボタン有無、所有者 |
| 2 | 方式を決める | 固定通知は Workflows、対話型や個人通知は Bot、製品化は custom connector |
| 3 | 1本だけ PoC を作る | 本番に近い payload で表示確認する |
| 4 | 運用条件を先に決める | owner、co-owner、監視、障害時の連絡先 |
| 5 | 切替時の安全策を用意する | 新旧を短期間並走、失敗時の戻し方を明文化 |
| 6 | payload を見直す | 長文ログをやめ、要約＋リンクへ変える |
| 7 | 切替後に旧設定を整理する | 古い URL、手順書、接続一覧を残さない |
特に効くのは、最初の1本を「一番単純な通知」ではなく「少しクセのある通知」で試すことです。
たとえば、リンク付き、複数行、メンションあり、少し長めの本文、という通知を先に PoC すると、後続の横展開が楽になります。
迷ったら、この判断で進めれば大きく外さない
Teams の Webhook コネクタ廃止後に通知を維持するうえで、いちばん大事なのは全部を同じ方式で置き換えないことです。
- 固定チャネルの定型通知は Workflows
- 対話型・個人通知・アプリ主体の通知は Teams ボット
- 複数部署や顧客に配る製品機能は Power Automate カスタムコネクタ
この切り分けにすると、移行が速いだけでなく、半年後の運用も壊れにくくなります。期限は 2026年4月30日まで延長されていますが、private channel やカード互換にはなお注意点が残るので、先に 1 本だけでも PoC を作って、表示確認・owner 設計・エラー時のふるまいまで見ておくのが最も安全です。 (Microsoft for Developers)
まず今日やるなら、既存の Webhook 通知を一覧にして、「送信先」「ボタン有無」「1時間あたり件数」「所有者」の4列だけ埋めてください。その表ができれば、どれを Workflows に寄せ、どれを Bot や別設計に回すべきかは、かなり明確になります。
コメント