n8nでSlack返信を使った承認フローを実装した方法

n8nでAI記事生成フローを作るとき、「AIだけで記事を書いてもどこかで見た内容になる」という課題がありました。差別化するには、実際に経験した失敗・判断・数値の変化など、その人にしか書けない一次情報が必要です。そこで考えたのが、Slackにインタビュー質問を送り、スレッドへの返信を受け取ってから記事生成へ進む承認フローでした。

この記事でわかること：

• n8n Slack Events APIとWebhookをつなぐ方法
• url_verificationチャレンジの処理方法
• スレッド返信だけを処理対象にする絞り込み設計
• 誤送信・テスト返信でフローが動いてしまう問題への対策
• LLM品質判定で回答の質をチェックする方法
• Slackリトライによる二重実行を防ぐ方法

Slackを「人間が回答する入口」にしたかった

AIに記事を書かせるフローはシンプルに作れます。ただ、完全自動で生成した記事は、既存の情報を整理したものにとどまりがちです。

そこで「Slackに3問のインタビューを送り、回答が届いたらその内容をAIに渡して記事を書かせる」という設計にしました。フローの途中に人間の回答待ちポイントを作る、いわゆる人間介在型の自動化フローです。

これは単なる通知フローではありません。Slackへの投稿はあくまで「質問を届ける手段」であり、スレッドへの返信が来るまでフローを止めておく必要があります。n8nのWebhookを使えば、Slackの返信イベントをトリガーにしてフロー2を起動できます。

ただし、「Webhook URLを設定してSlack返信を受け取る」だけでは実運用で壊れやすいことが分かりました。url_verification、誤送信、品質判定、リトライ対策まで含めないと、安定した承認フローにはなりません。

今回の構成：SlackインタビューからWebhookでフロー2を起動

フロー全体の構成はこうです。

フロー1（Schedule Trigger起点）：

• keyword_queue.csvからキーワードを1件取得
• 記事設計・市場調査をLLMで実行
• インタビュー質問3問をSlackチャンネルに投稿
• session.jsonを保存してフロー1終了

フロー2（Webhook起点）：

• Slackのスレッド返信をWebhookで受信
• url_verificationなら challengeを返して終了
• リトライヘッダーがあれば停止
• スレッド返信かどうかを確認
• 文字数チェック・LLM品質判定
• session.jsonを読み込んで前段データを復元
• 返信テキストと設計データを統合して記事生成へ

Slackが「人間確認の入口」と「フロー再開のトリガー」を兼ねています。フロー間のデータ保持についてはsession.jsonで状態保持する実装で詳しく書いています。並列ノード取得のMerge設計についてはMergeノードの直接参照設計も参考にしてください。

Slack Events APIのWebhook URLをn8nに向ける

まずSlack App側の設定から始めます。

1. Slack APIでAppを作成（または既存のAppを使用）
2. 左メニューの「Event Subscriptions」を有効化
3. Request URLにn8nのWebhook URLを入力
4. Subscribe to bot eventsで message.channels を追加
5. Bot Token Scopesで必要な権限を付与。必要なスコープは構成によって変わりますが、今回のようにBotがSlackへ質問を投稿しチャンネル内の返信イベントを扱う構成では、投稿用の chat:write と、対象チャンネルの履歴を扱うための権限（channels:history など）を確認しました

n8n側では、Webhookノードを用意してURLを発行します。HTTPメソッドはPOST、Authentication設定はなしで受けています。この記事では動作確認を優先してAuthentication設定なしで進めていますが、本番運用ではSlackのSigning Secretを使った署名検証や、受信元IPの検証を追加する方が安全です。

受信するイベントは message.channels にします。これによりチャンネル内のメッセージとスレッド返信の両方を受け取れます。

ただしこのままでは、チャンネルのすべての投稿をWebhookが受け取ります。次のステップで不要なイベントを絞り込んでいきます。

詰まり1：url_verificationを返さないとWebhookが有効化できない

最初の詰まりがここでした。

Slack Event SubscriptionsでRequest URLを登録しようとすると、Slackは確認のために url_verification タイプのリクエストを送ってきます。このリクエストに対して、ボディの challenge の値をそのまま返す必要があります。

これを処理しないと、Request URLの欄に「Verified」と表示されず、イベント受信が始まりません。

n8n側の対応はこうです。

Webhookノードの後にIFノードを置き、type === "url_verification" を判定します。

条件：{{ $json.body.type }} equals "url_verification"

trueルートでは、Respond to Webhookノードを使って challenge の値をそのまま返します。Slack側が求める形式に合わせて、challengeの値をレスポンス本文として返します。n8nではRespond to Webhookノードで、JSONまたはテキストとしてchallengeを返す設定にします。

{ "challenge": "{{ $json.body.challenge }}" }

falseルートは、通常のメッセージ処理フローへ進みます。

この分岐を入れるまで、Slackのリクエスト検証が通らず、イベントが一切届きませんでした。Slack連携で最初に詰まるポイントとして、必ず対応が必要です。

スレッド返信だけを処理対象にする絞り込み設計

message.channels では、チャンネルへの通常投稿もスレッド返信もすべて届きます。

今回処理したいのは「インタビュー質問投稿へのスレッド返信」だけです。不要なイベントを後続処理に流さないよう、絞り込みを入れます。

確認するポイント：

1. thread_ts が存在するか → スレッド返信かどうかの判定
2. bot_id が含まれていないか → Bot自身の投稿を除外
3. チャンネルIDが対象チャンネルか → 別チャンネルのイベントを除外

IFノードまたはCodeノードで、これらの条件を順に確認します。

const event = $json.body.event;

// スレッド返信かどうか
if (!event.thread_ts) return false;

// Bot自身の投稿を除外
if (event.bot_id) return false;

// 対象チャンネルかどうか
if (event.channel !== 'C0AV96NMES2') return false;

return true;