n8nでスケジュールフローを組んだ。定期レポートのデータを取ってきて、Teamsのチャンネルに投げるだけ——のはずが、何も届かない。ログを見るとHTTP 200が返ってきているのに、チャンネルは静かなままだ。
原因は「Incoming Webhook URL が死んでいる」ことが多い。2026年5月18日、MicrosoftはOffice 365 Connectorsを完全廃止した。それ以前に発行されたTeamsのWebhook URLは、その日を境にサイレントで無効になった。200が返るのはURL自体が残存しているためで、メッセージは届いていない。
この記事では、Teams・Slack・メールの3択をどう判断するかを整理する。設定手順と「詰まりどころ」を一通り押さえれば、配信先を選び直す判断も30分以内にできる。
この記事の検証環境
n8n バージョン
v2.33.6（Docker セルフホスト）
Teams廃止日
2026年5月18〜22日（完了）
Slack OAuthスコープ
chat:write（chat:write:bot は廃止済み）
難易度
★★☆ n8n・Webhook の基礎知識が必要
なぜTeamsに届かないのか
n8nからTeamsへ通知を送る際、多くの記事が紹介しているのは「Incoming Webhook URLにPOSTする」方法だ。TeamsのチャンネルでConnectorアプリを追加し、発行されたURLへJSONを投げるだけ——シンプルで使いやすかった。
この仕組みはOffice 365 Connectors（旧称：Microsoft 365 Connectors）と呼ばれるフレームワーク上で動いていた。Incoming Webhookはそのコネクター一覧の中の一機能に過ぎない。そしてこのフレームワーク全体が、2026年5月に廃止された。
⚠️ 旧Webhook URLは「サイレント廃止」されている
症状：n8nのHTTP RequestノードがHTTP 200を返す。エラーは出ない。しかしTeamsには何も届かない。
原因：URLのエンドポイント自体は残っているが、リクエストを受け付けても投稿しない状態になっている。Microsoftの廃止実装はエラーを返さず無視するため、n8n側でエラーが検出されない。
Office 365 Connectors廃止の経緯
Microsoftがコネクター廃止を発表したのは2024年8月だ。その後、期限延長が2度行われ、最終的な廃止完了は2026年5月22日となった。
2026年5月18〜22日
全コネクター廃止完了。既存のIncoming Webhook URLが無効化。
Microsoftが推奨する移行先はPower Automate Workflowsだ。TeamsアプリのWorkflowsから「Post to a chat when a webhook request is received」テンプレートを使うと、新しいWebhook URLが発行される。このURLにn8nからPOSTすれば、引き続きTeamsへ投稿できる。
🐝 ライセンスについて
Power Automate WorkflowsはM365 Business Basic以上のライセンスに含まれる。Power Automate Premiumは不要だ。Salesforce・SAP等のプレミアムコネクターを使う場合のみPremium（¥2,247/ユーザー/月）が必要になる。Teams通知の置き換えには標準ライセンスで十分。
3つの配信先を比較する
n8nから通知を送る現実的な選択肢は3つだ。Teams（Workflows経由）・Slack（OAuth App）・メール（Gmail/SMTP）。どれを選ぶかは「環境」と「設定コスト」で決まる。
💬Microsoft Teams
Power Automate Workflows経由
✓ M365ライセンス所持者は追加費用ゼロ
✓ 社員がすでに開いているチャンネルに届く
✗ Teams側でWorkflowsの事前設定が必要
✗ Webhook URLがロングで管理しにくい
⚡Slack
OAuth App（Bot Token）または Incoming Webhook
✓ n8nとの連携が最も安定している
✓ Incoming Webhookなら5分で設定完了
✓ Block Kit で見やすいメッセージが作れる
✗ Slackを契約していない組織には使えない
向いている組織：Slackを日常利用している。最初に選ぶべき選択肢
📧メール（Gmail / SMTP）
n8n組み込みのSendEmailまたはGmailノード
✓ 社内外どこへでも届く。環境依存ゼロ
✓ 配信リストをCSVで管理できる
✗ 読まれないリスクが高い
✗ Gmail OAuth2 の設定にGoogle Cloud Consoleが必要
向いている組織：Slack・TeamsどちらもなくメールがメインのB2B
迷ったときの判断基準はシンプルだ。Slackを使っているなら迷わずSlack。TeamsのみならWorkflows。どちらもなければメール。Teams Workflowsは移行後も動くが、設定に「Teamsの管理者権限またはチャンネルオーナー権限」が必要な点を先に確認しておく。
Teams：Power Automate Workflowsで再設定する
旧Incoming Webhook URLの置き換えは、Teams側でWorkflowsを設定してから、n8n側のURLを差し替えるという2ステップだ。
Teams側の設定（5〜10分）
1
対象チャンネルを開く → 右上「…」→「Workflows」を選択
「Workflows」が表示されない場合は Teams管理センターで「Workflows」アプリが許可されているか確認する。
2
「Post to a chat when a webhook request is received」を選択
検索バーに「webhook」と入力すると見つかりやすい。テンプレートを選んで「Next」。
3
投稿先のチームとチャンネルを選択 → 「Add workflow」をクリック
このフローはあなた（設定者）のアカウントに紐づく。退職・組織変更があった場合は再作成が必要。
4
「Copy」ボタンでWebhook URLをコピーする
n8n側の設定
HTTP Requestノードを使ってPOSTするだけだ。n8n Teams専用ノードを使う必要はない。
HTTP Request ノード設定値
Method: POST
URL: {{コピーしたWorkflow URL}}
Content-Type: application/json
Body:
{
“title”: “週次レポート”,
“summary”: {{ $json.summary }},
“date”: {{ $now.toISO() }}
}
🐝 Workflowsの落とし穴
Power AutomateのWorkflow（フロー）は作成者のM365アカウントに紐づく。担当者が退職したり部署異動した場合、フローは停止する。「共有フロー」として別のアカウントに共有しておくか、専用のサービスアカウントで作成することを検討する。
Slack：OAuth Appで動かす
Slackへの通知は2通りある。Incoming Webhook（シンプル・1チャンネル固定）とOAuth App（Bot Token）（複数チャンネルに動的に送れる）だ。週次レポートのように送り先が固定なら Incoming Webhook で十分。チャンネルを変数で切り替えたい場合は OAuth App を使う。
方法A：Incoming Webhook（設定5分・推奨）
1
App Name は任意（例：n8n-weekly-report）。ワークスペースを選択。
2
「Incoming Webhooks」→ 「Activate Incoming Webhooks」をON
ページ下部の「Add New Webhook to Workspace」で投稿先チャンネルを選択。
3
発行されたWebhook URLを n8n の HTTP RequestノードのURLに貼り付け
方法B：OAuth App（Bot Token）
チャンネルを動的に変えたい場合や、n8nのSlackノードを使いたい場合はOAuth App経由のBot Tokenを使う。
🔑
必要なOAuthスコープ
chat:write — メッセージ送信（必須）
channels:read — チャンネル一覧取得（動的送信時）
chat:write:bot は廃止
🤖
Bot User OAuth Token の取得
「OAuth & Permissions」→「Install to Workspace」後に表示される xoxb- から始まるトークンを使用する。
xoxb- 形式
⚠️
Token Rotation（トークンローテーション）は必ず無効にする
有効にするとBotトークンが12時間で期限切れになる。n8nのCredentialsがローテーションに対応していないため、定期的に認証エラーが発生する。「OAuth & Permissions」でOffのまま保つ。
必ずOFF
メール（Gmail / SMTP）：最もシンプルな選択肢
Slack・Teamsどちらもない組織、あるいは社外の関係者にも同じレポートを届けたい場合はメールが現実的だ。設定の複雑さはGmailとSMTPで異なる。
Google Cloud ConsoleでGmail APIを有効化し、OAuthクライアントIDを作成する。設定は20〜30分かかるが、一度設定すれば長期間安定動作する。
✓「安全性の低いアプリ」設定が不要
✓アプリパスワード不要
SMTP（SendEmailノード）
既存メールサーバーを使う場合
社内のExchange / sendmailサーバーがある場合はSMTPが最速。接続情報（Host/Port/User/Pass）を設定するだけで動く。
Host: smtp.example.com
Port: 587（STARTTLS）
SSL/TLS: STARTTLS
Gmailで「アプリパスワード」方式を使うケースも多いが、アプリパスワードは2段階認証を有効にしたGoogleアカウントでのみ発行できる。組織のGoogleアカウントでは管理者が許可していない場合があるので事前確認が必要だ。
週次レポートの実装パターン
配信先を選んだら、実際にワークフローを組む。以下は「毎週月曜9時に自動レポート送信」の基本構成だ。HTTP RequestノードでDify APIを呼び出しAIに本文を生成させる応用については、n8nとDifyを連携させる記事で解説している。
毎週月曜 9:00 に起動。
Cron 形式: 0 9 * * 1
NODE 2
HTTP Request（データ取得）
社内APIやスプレッドシートからレポートデータを取得する。このノードは組織ごとにカスタマイズが必要。
取得データをSlack Block Kit / Adaptive Card / メール本文の形式に変換する。
Slack/Teams/SMTPへ送信。配信先に応じてノードを切り替える。
ワークフローJSONをインポートすると、Slackへの送信ノードが有効な状態で読み込まれる。Teams・メールのノードは無効（Disabled）で同梱してあるので、切り替えたい場合はノードを右クリック → 「Enable」するだけだ。
よくある失敗と対処法
① Teams通知が届かない（200が返る）
症状：HTTP RequestノードがステータスコードHTTP 200を返すが、Teamsに何も届かない。
原因：旧Office 365 ConnectorsのWebhook URL（outlook.office.com/webhook/…またはwebhook.office.com/…形式）を使っている。
対処：URLをPower Automate WorkflowsのURL（prod-XX.westus.logic.azure.com/…形式）に差し替える。上記「Teams側の設定手順」を参照。
② Slack：「missing_scope」エラー
症状：Slackノードが missing_scope: chat:write エラーを返す。
原因：SlackアプリのBot Token Scopesに chat:write が追加されていない。または追加後にワークスペースへの再インストールを忘れている。
対処：api.slack.com/apps → OAuth & Permissions → Bot Token Scopes → chat:write を追加 → 「Reinstall to Workspace」をクリックしてトークンを再発行する。
③ Slack：12時間で認証が切れる
症状：設定直後は動いたのに、翌日から invalid_auth エラーになる。
原因：Slack AppのToken Rotation（トークンローテーション）が有効になっている。Botトークンが12時間で自動失効する。
対処：api.slack.com/apps → OAuth & Permissions → 「Token Rotation」セクション → 「Opt out of token rotation」をクリックして無効化する。
④ Teams Workflows：フローが突然停止した
症状：数週間は動いていたのに、ある日から通知が来なくなった。n8n側はHTTP 200が返っている。
原因：フロー作成者のM365ライセンスが変更されたか、アカウントが無効化された。Power AutomateのWorkflowは作成者アカウントに紐づく。
対処：Power Automateの「マイフロー」→ 対象フローを開いて「実行履歴」でエラー内容を確認する。フローを再作成するか、別のアカウントにオーナーシップを移す。
⑤ Gmail：「access denied」または「less secure app」エラー
症状：GmailのSMTP認証でエラーが出る。または「安全性の低いアプリへのアクセス」の設定が見当たらない。
原因：Googleは「安全性の低いアプリ」設定を2022年に廃止済み。パスワード直接入力によるSMTP認証は基本的に使えない。
対処：（a）2段階認証を有効にしてアプリパスワードを発行してSMTPに使う、または（b）n8nのGmailノードでOAuth2認証を設定する。どちらかを選ぶ。
まとめ・チェックリスト
配信先の選択と設定で詰まる原因は、ほぼ「旧URLの残存」か「認証設定の見落とし」に集約される。以下のチェックリストを配信先ごとに実行すれば、初回設定でのトラブルはほぼ防げる。
3つの配信先の中で、設定の安定性と維持コストのバランスがいいのはSlackだ。TeamsはWorkflowsへの移行コストがあるが、M365環境なら長期的には最適な選択になる。メールは「とにかく届ける」という場面で引き続き有効だ。
参考資料