n8nでAI記事生成パイプラインを作った全体設計と判断理由

n8nでAI記事生成パイプラインを作り、実際に稼働させています。キーワードを入れたら記事が自動で生成・投稿されるというシンプルな仕組みではなく、GSC/GA4による分析、Slackを使った人間介在、AI監査、WordPress自動投稿、投稿後の改善ループまでを含む3フロー構成です。

この記事は、個別ノードの設定手順ではなく、n8nでAI記事生成パイプラインを実運用するための全体設計を整理したハブ記事です。個別の実装手順は、各セクションから関連記事へリンクしています。

なぜその構成にしたかという設計判断を中心に記録します。気になる部分から読んでいただけます。

この記事でわかること：

• n8nでAI記事生成パイプラインをフロー0・1・2に分けた理由
• Slackインタビューで一次情報を記事に入れる設計
• Webhookをまたいで状態を保持するsession.jsonの役割
• ClaudeとOpenAIを役割分担した理由
• Google DriveをマスターにしてVPSを実行環境にした理由
• 完全自動ではなく「止まる設計」にした思想

AIで記事を自動生成するだけでは足りないと感じた

AIで記事を書くこと自体は、今や難しくありません。LLMにプロンプトを渡せば、それなりの文章は出てきます。ただ、そのまま公開してもSEOで戦えるかというと、そう簡単ではありませんでした。

問題は内容の薄さです。AIが生成する記事は、検索上位にある記事の情報を再配置したものになりやすい。独自の一次情報がない記事は、他の記事と差別化できません。

さらに、記事を作るだけでなく、作った後に改善する仕組みも必要でした。公開した記事の順位・クリック率・読了率を見て、何を直すか、次に何を書くかを判断するプロセスを自動化したかったのです。

そこで、記事量産ツールではなく、AI編集システムとして設計することにしました。一次情報を入れる、監査する、投稿後に改善候補を出すという一連の流れを、n8nでつなぐパイプラインです。

全体構成：フロー0・1・2に分けた理由

パイプラインは3つのフローで構成しています。

フロー0：週次データ分析（Schedule Trigger）
  GSC/GA4取得 → リライト候補 / 新規キーワード候補 → Slack通知
  ↓
keyword_queue.csvへ候補を追加

フロー1：記事生成前半（Schedule Trigger）
  keyword取得 → 市場調査 → 記事設計 → インタビュー生成 → Slack送信
  ↓
session.json保存（VPS）

フロー2：記事生成後半（Webhook Trigger）
  Slack返信受信 → session.json読み込み → 本文生成 → 監査 → WP投稿
  ↓
Google Drive管理ファイル更新

1つの巨大フローにしなかった理由は、役割の分離と保守性です。

「分析」「設計・人間介在」「投稿・更新」を分けることで、失敗したときの原因が切り分けやすくなります。フロー2でWP投稿が失敗しても、フロー0やフロー1は影響を受けません。また、フローごとにSlack通知を設けることで、どのステップで止まっているかが即座にわかります。

フロー0：GSC/GA4から改善候補を出す分析フロー

フロー0は週次で自動実行される分析フローです。

VPS上のPythonスクリプト fetch_metrics_json.py をn8nのExecute Commandノードから実行し、Search ConsoleとGA4のデータを performance_cache.json として保存します。その後、公開済み記事の台帳である summary_cache.json と照合して、リライト候補と新規キーワード候補を出力します。

GSCとGA4のデータを見るだけでは「次に何をすべきか」の判断がつきにくいため、既存記事台帳とJOINして「直すべき記事」「書くべきテーマ」という形に変換するのが目的です。

フロー0の詳細な設計はn8nでGSC/GA4からリライト候補を自動抽出するフローを作ったに記録しています。

フロー1：キーワード取得から記事設計・Slackインタビューまで

フロー1は記事生成の前半です。週次のSchedule Triggerで起動します。

主な処理の流れ：

1. keyword_queue.csv からキーワードを1件取得
2. Google Driveから管理ファイルを並列取得（internal_links.csv / _index.json / summary_cache.json など）
3. slugをLLMで生成
4. 市場調査LLM（検索意図・想定読者・既存記事との差分を整理）
5. 記事設計LLM（検索意図・H2構成・内部リンク候補を設計）
6. インタビュー質問3問を生成
7. Slackに質問を送信
8. session.jsonをVPS上に保存して終了

フロー1で「記事をいきなり書かない」ことが設計上の重要な選択でした。まずキーワードの意図を分析し、構成を設計し、人間に質問する。この順序があることで、AIが書く記事に方向性と一次情報が入ります。

Slackインタビューを挟んだ理由

AIだけが記事を書くと、実体験が出てきません。実際に詰まった経験、判断した瞬間、計測した数値の変化。こうした情報は人間が持っています。

そこで、Slackに3問のインタビュー質問を送り、回答が届くまでフローを止める設計にしました。人間がSlackのスレッドに回答すると、Webhookでフロー2が起動します。

ただし、Slack返信を受け取るだけでは実運用に耐えられませんでした。url_verification対応、誤送信対策（文字数チェックとLLM品質判定）、Slackリトライによる二重実行対策が必要でした。

詳細はn8nでSlack返信を使った承認フローを実装したに記録しています。

これは「完全自動化しないための設計」でもあります。人間が回答するまでフローは進みません。人間の判断が入ることで、記事に一次情報が加わります。

Webhookをまたぐためにsession.jsonで状態を保持した

フロー1はSlack質問を送った時点で終了します。フロー2はSlackの返信を受け取るWebhookで別の実行として起動します。

n8nの1回の実行コンテキストは、トリガーから終了まで独立しています。フロー1が終了した後にフロー2が起動しても、フロー1で作ったkeyword・slug・記事設計データは自然には残っていません。

そこで、フロー1の最後にこれらのデータを /files/sessions/session_{ts}.json として保存します。フロー2ではSlackの thread_ts を使って対応するsession.jsonを読み込み、前段データを復元してから記事生成へ進みます。

Webhookをまたいだ状態保持の詳細と詰まりポイントはn8nでWebhook後にデータが消える問題をsession.jsonで解決したに記録しています。

Mergeノードの罠と直接参照で安定させた

フロー1でGoogle Driveから4ファイルを並列取得してMergeする構成にしたとき、後続のCodeノードで $input.all() を使っても全データが揃わない問題が繰り返し起きました。

MergeノードのAppendモードでRunが複数に分割されると、$input.all() は現在のRunの範囲しか見ません。解決策は $('ノード名').first() で必要なノードを直接参照することでした。

詳細と注意点はn8nのMergeノードでデータが取れない原因と直接参照で解決したに記録しています。

フロー2：Slack返信から記事生成・監査・WordPress投稿まで

フロー2はSlackのスレッド返信をWebhookで受け取ることで起動します。

主な処理の流れ：

1. url_verification / リトライヘッダー / スレッド返信の判定
2. session.json読み込みとthread_tsの照合
3. Slack回答テキストと記事設計データを統合
4. Claudeで本文生成（02_write）