n8n×Claude×WordPressで記事自動投稿パイプラインを作った全記録
結論：n8n×Claude×WordPressで記事自動投稿は実装できます
n8n×Claude×WordPressで記事自動投稿は実装できます。ただし、ほぼ全員が同じ3箇所で詰まります。
「Slack承認フロー・状態管理・LLMモデル設計」の3点がないと必ずどこかで止まります。この記事では、全体構成と詰まりポイントごとの解決記事だけ整理します。
パイプラインの全体構成——まず流れを把握してください
私のパイプラインは以下の流れで動いています。
[Schedule Trigger]（毎日定時）
↓
[00 キーワード取得] → keyword_queue.csvから対象KWを取得
↓
[01 記事設計] → タイトル・H2構造・内部リンク候補を生成
↓
[01.5 インタビュー生成] → 記事テーマに沿った質問をSlackに送信
↓ ← ここで一時停止（人間のSlack返信を待つ）
[Webhook受信] → Slackの返信を受け取り処理を再開
↓
[02 本文生成] → 回答をもとに記事本文を生成
↓
[03 自己監査] ─┐ 並列実行
[03 外部監査] ─┘
↓
[統合リライト] → 監査結果を統合して最終稿を生成
↓
[WordPress投稿] → REST APIで下書き投稿モデルの割り当て：
- gpt-4o-mini：キーワード取得・記事設計・外部監査
- claude-sonnet-4-6：インタビュー生成・本文生成・自己監査・統合リライト
なぜこの構成にしたのか——設計の理由を3点だけ
①品質責任を人間に残すため
全自動にすると記事の内容に誰も責任を持てなくなります。インタビューへの返信という1アクションを残すことで、記事の一次情報に私が責任を持つ設計になっています。
②シンプル構成を優先するため
ノードが増えるほど止まるリスクが上がります。「動く最小構成」を先に完成させてから機能を追加する順序で作りました。
③止まらない設計を優先するため
外部依存が多い構成は採用しませんでした。プロンプトは各ノードに直接組み込んでいます。
この設計思想の背景は以下の記事で詳しく整理しています。
詰まるポイントTOP3と解決記事——あなたはどれですか
パイプライン構築中に最も詰まりやすい3点を整理します。
詰まりポイント①：バイナリが読めない（filesystem-v2問題）
✔ こんな人はここ：Read Fileのあとにデータが取れない人・binaryToStringでエラーになる人
症状： Read File(s) From Diskノードの後、Codeノードでデータを取得しようとするとbinaryToStringエラーになる。
原因： binaryDataMode=filesystemの環境では、バイナリデータはディスク上に別管理されておりCodeノードから直接読み取れない。
解決策： Read File(s) From Diskの直後にExtract from Fileノードを挟む。
→ n8n binaryToStringエラーの原因と解決法
詰まりポイント②：Webhook後にデータが消える（状態管理問題）
✔ こんな人はここ：Slack返信後に処理が再開されない人・フロー間でデータが引き継げない人
症状： Slackへの送信時に持っていたデータが、Webhook受信のタイミングで消えて後続処理に引き継げない。
原因： n8nはワークフローの実行をまたいでデータを保持しない。Webhook待機中に実行が終了する。
解決策： session.jsonでSlack送信時のデータを保存し、Webhook受信時にthread_tsをキーに読み込む。
→ n8nでWebhook後にデータが消える原因とsession.jsonで解決する方法
詰まりポイント③：ClaudeのSystemプロンプトが機能しない
✔ こんな人はここ：Claudeが拒否する人・出力が不安定・意図した形式で出力されない人
症状： AnthropicノードにSystemプロンプトを設定しても拒否されたり意図した出力にならない。
原因： MCP向けの操作指示の混入・未置換のプレースホルダー・1ノードへの複数役割の詰め込みが主な原因。
解決策： プロンプトをノードの役割に特化した形に分割し直す。
→ n8nでClaudeのSystemプロンプトが拒否される原因と解決法
承認フローの仕組み——詳細はリンク先へ
Slackを使った承認フローの概要です。
- n8nがSlackにインタビュー質問を送信（tsをsession.jsonに保存）
- スマートフォンのSlackからスレッドに返信
- Slack Event SubscriptionsのWebhookがn8nに通知
- thread_tsをキーにsession.jsonを読み込んで処理を再開
challenge処理・thread_ts管理・session.json連携の実装詳細は以下を参照してください。
モデル使い分けの設計——判断基準は1問です
gpt-4o-mini：情報処理タスク（キーワード処理・記事設計・外部監査）
claude-sonnet-4-6：思想判定タスク（インタビュー・本文生成・自己監査・リライト）
この使い分けによりLLMコストが約40%削減できました。判断基準の詳細は以下を参照してください。
完成後の運用イメージ——人間は判断だけになります
毎朝、定時にパイプラインが自動起動します。インタビュー質問がSlackに届いたら、スマートフォンから返信するだけです。所要時間は3〜5分程度。返信後は本文生成・監査・リライト・WordPress投稿まで自動で走り、気づいたときには下書きが完成しています。
以前は記事1本の作成に2〜3時間かかっていたものが、今は私の作業時間は実質5分以内です。
まとめ——詰まっているポイントから解決してください
詰まっているポイントがある方は、該当の記事を参照してください。
- バイナリが読めない → binaryToStringエラーの解決法
- データが消える → session.jsonで状態管理する方法
- プロンプトが動かない → Systemプロンプトが拒否される原因と解決法
- 承認フローを作りたい → SlackとWebhookで承認フローを作る方法
- モデルの使い分けで迷っている → LLMモデルを使い分ける判断基準
このパイプラインは動きます。ただし「なぜこの構成なのか」という設計思想は別の話です。
bizinets.biz
記事を読んで「もっと知りたい」と思ったあなたへ
bizinets.biz では、ビジネスの仕組みづくりを体系的に学べるコンテンツを用意しています。まずは一度、覗いてみてください。
bizinets.biz へ行く →
