n8n×Slack×WordPressで記事自動投稿を構築する方法｜Webhook受信からYMYL判定まで実践ログ

# n8n×Slack×WordPressで記事自動投稿を構築する方法｜Webhook受信からYMYL判定まで実践ログ

n8nでSlack Webhookを使った記事自動投稿フローを作ると、「VerifiedなのにWebhookが発火しない」「Slack返信を受け取れない」といった問題に詰まることがあります。

この記事では、Jogtime向けに実際に構築したn8n×Slack×WordPress自動投稿フローを例に、Webhook受信から自己監査・YMYL判定・WordPress投稿までの構成と解決手順を実践ログとして公開します。

Webhookが発火しなかった原因と解決手順

「Verified」なのに動かない。n8nでSlack Webhookを使うとき、これが最初の難関ではないでしょうか。

私が詰まった原因は3つありました。順番に確認していくと解決できます。

原因1：Event SubscriptionsのRequest URLが間違っていた

n8nのWebhookノードには「Test URL」と「Production URL」の2種類があります。フローをPublishする前はTest URLで試していたのですが、Production URLとは別物です。

Slack AppのEvent Subscriptions → Request URLには必ずProduction URLを設定する必要があります。Test URLを貼り付けていると、フローをアクティブにしても発火しません。

確認手順：

1. n8nのWebhookノードを開き「Production URL」をコピーする
2. Slack App管理画面 → Event Subscriptions → Request URLに貼り付ける
3. 「Verified ✓」になることを確認する

原因2：Subscribe to bot eventsに`message.channels`が追加されていなかった

Slackのスレッド返信を受け取るには、ボットイベントとしてmessage.channels（パブリックチャンネルの場合）を購読している必要があります。

Event Subscriptions画面の「Subscribe to bot events」セクションにmessage.channelsが追加されているかを確認してください。追加後はアプリの再インストールが必要になります。

原因3：n8nアプリがチャンネルに招待されていなかった

Slackアプリはチャンネルに招待しないとイベントを受け取れません。対象チャンネルで以下を実行します。

/invite @アプリ名

この3点を順番に確認すると、ほとんどのケースで解決できます。

判断基準：

• Production URLが設定されていない → Slack App管理画面のRequest URLを差し替える
• message.channelsがない → Subscribe to bot eventsに追加してアプリを再インストールする
• アプリがチャンネルにいない → /invite @アプリ名 を実行する

Slackスレッド返信を正しく受け取るコード設計

Webhookが発火するようになっても、次の問題が待っています。Slackからは様々なイベントが飛んでくるため、「スレッド返信のみ」を正しく受け取るコードが必要です。

以下のコードで、不要なイベントをフィルタリングしています。

const body = $input.first().json.body;

// ボット自身の投稿は無視する
if (body.event?.bot_id) return [];

// Slackのリトライは無視する
if ($input.first().json.headers?.['x-slack-retry-num']) return [];
if ($input.first().json.headers?.['x-slack-retry-reason'] === 'http_timeout') return [];

// スレッド返信以外は無視する（thread_tsがないものはスレッド外の投稿）
if (!body.event?.thread_ts) return [];

// thread_tsとtsが一致する場合は親メッセージ（返信ではない）
if (body.event?.thread_ts === body.event?.ts) return [];

特にx-slack-retry-numのチェックは重要です。Slackは3秒以内にレスポンスがないとリトライを送ってくるため、これを無視しないとフローが二重に発火してしまいます。

n8nフロー2の全体構成と各ノードの役割

実際に動いているフロー2の構成はこうなっています。全体を把握していると、どこで詰まっているかが特定しやすくなります。

Webhook（Slack返信受信）
→ site_config（サイト設定の読み込み）
→ If（スレッド返信フィルタ）
→ 回答品質判定（OpenAI）
→ 品質判定分岐
  → NG：Slack再送依頼通知
  → OK：session.json読み込み
         → RAG読み込み
         → 02本文生成（Claude）
         → 03自己監査（Claude）+ 外部監査（OpenAI）← 並列処理
         → 監査結果統合
         → 統合リライト（Claude）
         → YMYLチェック
         → YMYL判定分岐
           → NG：Slack通知（人間確認へ）
           → OK：article.md + meta.json書き込み → publish.mjs実行
→ Google Sheets更新（status → drafted）
→ session削除
→ Slack完了通知

各ノードの役割で特に重要なのは以下の点です。

session.jsonによる状態保持： フロー1でSlackインタビューを送信した時点のデータ（キーワード・設計情報）をVPS上のsession.jsonに保存しておき、フロー2でWebhookを受信したタイミングで読み込みます。Webhookをまたぐと前段のデータが消えるため、この設計が必須です。

自己監査と外部監査の並列処理： ClaudeとOpenAIを同時に走らせ、監査観点を分散しています。自己監査だけだと見落としや思考の偏りが残る可能性があるため、別モデルを並列実行して差分を見る構造にしています。2つの監査結果を統合してから最終リライトに渡す構成です。