n8nとSlackを連携して作業結果を通知するには

通知先と通知する内容を先に決める

接続前に、どのワークスペースの、どのチャネルへ、どの状態を届けるかを固定します。最初の試験に向くのは、自分たちが管理し、テスト投稿を許可したチャネルです。

全社向けチャネル、他社と共有するSlack Connect、個人へのDMは、最初のダミー送信先に選ばないでください。チャネル名だけでなくIDも控えれば、同名の場所や別ワークスペースへの取り違えを減らせます。

この値は説明用の仮例であり、実記事や実際の通知先ではありません。確認先にURLを載せる場合は、共有先の人が閲覧できる範囲を確かめ、秘密のトークンを含むリンクは外してください。

Gmail通知と違い、会話への参加と親投稿を扱う

Slack通知では、メールアドレスの代わりに会話のIDと参加条件を扱います。送信者を認証できても、目的のチャネルに投稿できるとは限らない点が違いです。

メールで受け取りたい場合は、Slackの接続設定へ無理に置き換える必要はありません。通知を見る場所を先に決めると、必要な認証や確認手順も絞れます。

認証方式を選び、通知に必要な権限へ絞る

n8n公式が通常のSlackノードで推奨する認証方式はOAuth2です。一方、管理者が通知専用アプリを用意でき、既知のチャネルへ短文を投稿するだけなら、bot access tokenを使う限定構成も選べます。

Slack TriggerはSlackからの受信を開始条件にする機能で、結果を送るだけなら不要です。応答待ちを行うSend and Wait for Responseも、単純な通知のSendとは目的が異なるため、最初の設定には混ぜないでください。

主作例は、参加済みチャネルへ投稿する通知専用bot

Slack APIのchat.postMessageでbotが投稿するための基本スコープはchat:writeです。本記事では、一覧検索を行わず、管理者が確認したチャネルIDを直接指定する構成にします。

1. 管理者の規則に沿って通知専用アプリを作る

   Slackのアプリ管理画面で対象ワークスペースを選び、必要ならFrom scratchからアプリを作成してください。アプリ名と送信主体は、通知用だと分かるものにする方針です。

2. 投稿に必要なbotスコープを設定する

   OAuth & PermissionsのBot Token Scopesで、用途に対応するchat:writeを設定します。n8n公式の多機能なmanifest例を、そのまま通知の必須権限一覧と考えないことが大切です。検索・履歴・ファイル・ユーザー管理の権限を追加する前に、何の操作で必要なのかを確かめてください。

3. 承認された方法でアプリを導入し、接続を保存する

   管理者の承認を得てワークスペースへインストールし、Bot User OAuth Tokenをn8nのSlack用CredentialのAccess Tokenへ保存します。トークンは本文のExpressionや通常の入力データに置かず、接続情報として管理するのが原則です。

4. botをテストチャネルへ参加させる

   対象チャネルの管理規則に従い、アプリの追加や招待を行います。投稿先を確認したチャネルIDへ固定し、認証したワークスペースも照合するのが最後の準備です。

このbot構成は、通知用途を限定するための編集上の選択であり、n8n全般でaccess tokenの方が優れるという意味ではありません。既存のOAuth2接続が承認済みで用途にも合うなら、その接続を使う方針も妥当です。

Cloudの用意されたOAuth2接続を使う場合は、接続ボタンから認可へ進み、対象ワークスペースと実際に求められる権限を確認してください。セルフホストでOAuth2アプリを自分で用意する場合は、Client ID・Client Secretと、n8nが示すOAuth Callback URLを対応させる別の準備になります。

期限切れや更新方式、共有範囲まで関係する場合は、Slackの投稿設定とCredentialの管理を分けて整理します。トークン更新の仕組みを確かめず、ローテーション設定だけを変更しないでください。

非公開チャネルではIDとbotの参加を両方確認する

非公開チャネルへ送るには、その場所にアクセスできる投稿主体を使い、必要な参加や招待を済ませることが前提です。IDが正しくても、botが未参加なら投稿できない場合があります。

一覧に出ないことだけを理由に、履歴や全チャネルへの投稿権限を増やさないでください。まずワークスペース、チャネルID、アプリの参加、組織側の制限を順に照合します。

既存メンバーや管理者による正規の招待が必要な場合は、その手順を利用する判断です。通知だけのためにchat:write.publicや送信者の見た目を変える権限まで追加する必要はありません。

Slackノードで短い結果メッセージを組み立てる

最初のフローは、手動の開始、ダミー入力、送信前の重複判定、Slack送信、結果保存の順に組みます。ここで使うデータは1件だけにして、宛先や内容を確認しやすくする設計です。

画面名や欄の配置は、導入したn8nとSlackノードの版によって変わります。2026年10月31日に確認した公式実装にもBy IDなどの設定がありますが、手元の画面と対応を見てから入力してください。

状態がレビュー待ちなのに「公開完了」と送ると、受け取る人の行動が変わってしまいます。表示したい文言だけでなく、どの処理結果を条件に送るかも一致させることが重要です。

通常textを基本にし、Block Kitは必要なときに使う

短い結果なら、通常のtextで必要事項を読める形が扱いやすいでしょう。状態・担当・確認リンクなどを区画で整理する必要が出た段階で、Block Kitを検討します。

blocksと一緒にトップレベルのtextを指定する構成では、通知表示・読み上げに必要な内容もtextへ含めることが重要です。見た目のブロックだけに情報を置かず、本文を読めない状態にならないかを確かめてください。

Slackのメンションやリンク表記は独自の構文を持ち、通常のMarkdownと完全に同じではありません。特に@hereや@channelに相当する表記、ユーザーメンションを、外部入力から無検証で渡さないでください。

リンクやメディアの展開が不要なら、ノード側に対応するUnfurl Links／Unfurl Mediaの設定を確認します。自動変換の設定だけで明示的なメンション構文まで無効になると考えず、入力を限定することも必要です。

親投稿のchannelとtsを保存し、続報をスレッドへ返す

親となる投稿の送信後は、成功応答に含まれるchannelとtsを記録します。返信に使うのは、同じチャネルの親投稿のtsです。

たとえば最初の「処理開始」を親にし、後から「レビュー待ち」をその下へ返信すれば、同じ記事の経過を追いやすくなります。返信そのもののtsへ順に付け替えるのではなく、最初の親投稿を参照する方針でそろえてください。

Slackノードの出力に、送信前の記事IDや版がそのまま残るとは限りません。送信前のノードや通知台帳から業務キーを参照できるようにし、返されたchannel・tsと同じ通知へ結び付けて保存します。

1. 親投稿が成功したら、業務キーとchannel・tsを対応させて保存
2. 続報の送信先に、保存した同じchannelを指定
3. Reply to a Messageに相当する欄で、親tsをMessage Timestamp to Reply Toへ渡す
4. Also Send to Channelは通常オフにし、チャネル全体への表示が必要な場合だけ明示的に判断

Slack APIのthread_tsには親投稿のtsを渡し、tsは文字列のまま扱うのが基本です。日付へ変換したり、小数として計算したりせず、返された桁を保ってください。

入力欄でtsが丸められる場合は、返信経路を見直す

導入版の入力・出力でtsが同じ値を保つかを確認します。公式リポジトリの更新中の定義には、返信先の入力がnumber型で記述された部分もあるため、画面へ値が入っただけで正しく対応したとは判断できません。

桁が変わる場合は、そのまま返信を続けず、文字列を保つAPI呼び出し経路などを検討してください。HTTP Requestでは既定のCredentialとJSON本文を使う設計が候補ですが、接続方法とエラー分岐を含めた別の確認が必要です。

作業キーと送信状態を記録し、同じ通知を増やさない

再実行を抑えるには、「この作業の、この通知を、ここへ送ったか」を保存する台帳が必要です。n8nの実行IDだけではなく、業務上の同じ通知を識別するキーで判定します。

説明用のキーは記事ID＋版＋通知種別＋送信先です。同じ記事・版のレビュー依頼をやり直しても同じキーになり、新しい版や別の通知種別は別に扱えます。

これは重複を減らすための運用設計であり、n8nやSlackの標準機能だけで一度限りの配信を保証する仕様ではありません。送信直後、台帳へ成功を書き込む直前に処理が止まれば、投稿の有無を確認する余地が残ります。

並行実行がある場合、単純な「検索してなければ送る」という方法の弱点は、二つの処理が両方とも未送信と判断し得ることです。一意制約や排他を備えた保存先を選び、単なるGet→Insertだけで同時送信を防げたとしないでください。

処理中の時間が長いだけでは、未送信だと決めつけられません。結果不明を自動再試行だけで解決しようとせず、保存先と投稿を照合する順序が必要です。

429とタイムアウトは、同じ再送条件にしない

Slackの投稿は通常チャネル当たり1秒1件が目安で、ワークスペース全体にも別の制限があります。短時間のバーストを前提に大量送信せず、必要に応じて結果をまとめる方針です。

Retry On Failを有効にするだけでは、送信済み判定や重複の問題は解決しません。利用中のノードがどうエラーを返すか、再試行の待機でRetry-Afterを満たすかも確認してください。

最小権限のbotに履歴閲覧がない場合は、権限を持つ人がチャネルを確認する方法を選べます。確認のためだけに無断で検索・履歴スコープを追加せず、人が調べる経路と自動照合する経路を分ける考え方です。

ダミー1件で、宛先・返却値・再実行の動きを確かめる

テストでは、投稿が見えるかに加え、どの作業の通知かを記録できることまで確かめてください。次の項目はこれから行う確認計画であり、実際の送信成功を示す記録ではありません。

• 自管理のテストチャネルとbot参加、送信先ID、閲覧範囲を照合する
• 秘密を含まないダミー1件を用意し、キーと入力の版を記録する
• 送信応答の成功・エラー相当を確認し、channelとtsを保存する
• 実際のチャネルで、正しい内容が一件だけ表示されたかを確かめる
• 同じ通知キーで再実行し、追加投稿せずスキップするかを確認する
• 続報を使う場合は、保存した親tsの同じスレッドへ返るかを照合する
• テスト後に開始条件や接続を必要な範囲で止め、本番へ自動移行しない

Slack APIを直接使う経路では、HTTP 200だけで成功と決めないでください。応答のokやerrorに相当する結果と、channel・ts、実際の表示を組み合わせて判断します。

上限に到達させる大量送信や、他者への誤送信を試験として行う必要はありません。権限不足や空本文などは、ダミーデータでの設計確認と、実行前の条件点検も組み合わせて確かめてください。

問題が起きた場合は、該当する送信元フローを止め、接続・宛先・本文のどこを変えたかを見て戻します。停止しても、すでに投稿したメッセージが自動で回収されるわけではない点に注意が必要です。

漏えいなどがあれば、関係者の手順に従いメッセージ削除や資格情報失効を行ってください。削除できても、閲覧済みの内容まで取り消せたとは扱えません。

エラー通知は、障害の検知と送信の役割を分ける

Error Triggerなどの仕組みは失敗を検知し、Slackノードはその結果を届ける役割です。通常の結果通知とエラー通知は別の種別にし、台帳でも見分けられるようにします。

失敗した場所や実行の保存条件によっては、エラー情報に実行IDやURLがない場合もある点に注意が必要です。存在しない項目を前提に本文を組み立てず、取得できた範囲で通知が読める形へ整えてください。

通知フロー自身の失敗が、同じ通知を再び呼び続けない構成も必要です。元の処理の原因診断と、Slackへの配送失敗を分けて記録すると切り分けやすくなります。

Slack通知で迷いやすい点

送信できるかと、通知が運用に合うかは別の確認です。方式や機能を追加する前に、次の違いを整理しておいてください。

まとめ｜固定した宛先へ短く届け、送信記録で重複を防ぐ

n8nのSlack通知は、承認した接続と固定チャネルを選び、Message → Sendで必要な結果だけを届ける構成から始めます。投稿の成功と、同じ作業を再送しない判断を分けて記録することが運用の要点です。

まだ接続していない場合は、テストチャネルと通知する状態を一つ決め、必要な権限を照合してください。すでに重複している場合は、再送設定を増やす前に業務キー、送信状態、結果不明時の照合を見直します。

続報には同じchannelと親tsを使い、タイムアウトでは未送信と即断しない方針です。通知の量を増やすことより、必要な状態と次の行動が一目で分かる設計を優先すると、日々の確認に使いやすくなるでしょう。

通知設定の先で継続運用の費用も判断したい場合は、n8nの費用をCloud・VPS・APIに分けて整理すると、通知の設定とは別に、どの支出を見込むかを比べられます。契約変更を通知の必須条件にせず、必要な人だけ次の解説も確認してください。

関連記事

n8nの費用は？Cloud・VPS・APIを分けて考える

n8nの費用は、Cloudの契約料、セルフホストのサーバー・保存費、外部APIの従量費を分けると見積もれます。サーバーの管理を任せたい人はCloud、自分で設定・更新・バックアップと復元を担える人はセルフホストが候補です。Com[…]