「55 本」は達成ではなく、墓場の数でもある。
今日時点で俺の n8n には 55 本のワークフローが存在する。
「すごい数ですね」と言ってもらえることがある。でも実態は違う。55 本のうち、今日も毎日稼働している「生きている WF」は 22 本だ。残りの 33 本は停止中・廃棄待ち・実験中のどれかだ。
この記事は「55 本全部が動いている」という成功談ではない。何が動いていて、何が死んでいて、なぜそうなったのか——その全部を書く。
WF の分類と系統図
まず全 55 本を俯瞰する。
俺はWFを「フェーズ」で分類している。コンテンツ生成・収益直結・データ収集・監視・実験の 5 フェーズだ。
n8n ワークフロー全体 (55本)
[コンテンツ生成] 15本
├─ ブログ系 (6本)
│ ├─ WF-BLOG-AUTO-PUBLISH ✅ 稼働中
│ ├─ WF-BLOG-PUBLISH-HOOK ✅ 稼働中
│ ├─ WF-BLOG-X-ANNOUNCE ✅ 稼働中
│ ├─ WF-BLOG-SEO-AUDIT ⚠️ 実験中
│ ├─ WF-BLOG-INTERNAL-LINK ❌ 廃棄
│ └─ WF-BLOG-DRAFT-REVIEW ❌ 停止中
├─ X投稿系 (5本)
│ ├─ WF-X-SCHEDULER ✅ 稼働中
│ ├─ WF-X-TAISHOKU-GEN ✅ 稼働中
│ ├─ WF-X-DRAFT-REVIEW ✅ 稼働中
│ ├─ WF-X-PERSONA-GEN ❌ 廃棄
│ └─ WF-X-THREAD-AUTO ❌ 停止中
└─ note/Zenn系 (4本)
├─ WF-NOTE-DRAFT-GEN ✅ 稼働中
├─ WF-ZENN-TRIAGE ⚠️ 実験中
├─ WF-NOTE-COVER-GEN ❌ 停止中
└─ WF-ZENN-SEO-PUSH ❌ 廃棄
[収益直結] 12本
├─ アフィリエイト系 (5本)
│ ├─ WF-AFFILIATE-CONTENT-GEN ✅ 稼働中
│ ├─ WF-AFFILIATE-TRACKER ✅ 稼働中
│ ├─ WF-PROLINE-LEADS-GEN ✅ 稼働中
│ ├─ WF-TAISHOKU-LINE-PUSH ✅ 稼働中
│ └─ WF-ASP-REPORT-DAILY ⚠️ 実験中
├─ LINE系 (4本)
│ ├─ WF-LINE-STEP-SEQUENCE ✅ 稼働中
│ ├─ WF-LINE-BROADCAST-CRON ✅ 稼働中
│ ├─ WF-LINE-LEAD-CAPTURE ✅ 稼働中
│ └─ WF-LINE-UPSELL-TRIGGER ⚠️ 実験中
└─ 広告・LP系 (3本)
├─ WF-LP-HEATMAP-FETCH ❌ 廃棄
├─ WF-AD-SPEND-MONITOR ❌ 停止中
└─ WF-CTA-AB-TEST ❌ 廃棄
[データ収集] 10本
├─ WF-AI-NEWS-INGEST ✅ 稼働中
├─ WF-AUTOCLAW-INGEST ✅ 稼働中
├─ WF-GH-TREND-CLIP ✅ 稼働中
├─ WF-COMPETITOR-RSS ⚠️ 実験中
├─ WF-KEYWORD-TRACKER ❌ 停止中
├─ WF-SCRAPER-X-UGC ❌ 廃棄
├─ WF-SEMRUSH-PULL ❌ 停止中 (API制限)
├─ WF-OBSIDIAN-EMBED-PIPE ✅ 稼働中
├─ WF-OBSIDIAN-MOC-BUILD ⚠️ 実験中
└─ WF-SUPABASE-BACKUP-DAILY ✅ 稼働中
[監視・インフラ] 10本
├─ WF-AUTOCLAW-CRON ✅ 稼働中
├─ WF-AUTOAGENT-OPTIMIZER ✅ 稼働中
├─ WF-ERROR-HANDLER ✅ 稼働中
├─ WF-DLQ-RETRY ✅ 稼働中
├─ WF-HEARTBEAT ✅ 稼働中
├─ WF-VERCEL-DEPLOY-WATCH ✅ 稼働中
├─ WF-SUPABASE-HEALTH ⚠️ 実験中
├─ WF-COST-REPORT-WEEKLY ✅ 稼働中
├─ WF-N8N-SELF-HEALTH ❌ 停止中
└─ WF-SLACK-ALERT-ROUTER ❌ 廃棄
[実験・スクラップ] 8本
└─ 全部 ❌ 停止中 / 廃棄待ち
凡例: ✅ 稼働中 | ⚠️ 実験中 | ❌ 停止・廃棄
最重要 WF TOP5
55 本の中で「これが止まったら困る」WF を正直に順位付けした。
1位: WF-ERROR-HANDLER
全 WF の Error Workflow に設定している。 これが止まると、他の WF がエラーを出しても誰も気づかない。
「エラーを検知するシステムが壊れている」状態は、他の何が壊れていても気づけない最悪の状況だ。
設計のポイントは**「このWF自体が落ちた時のフェイルセーフ」**を別の方法(Uptime Kuma の外部監視)で担保していることだ。二重化しない監視は監視と言えない。
2位: WF-AUTOCLAW-CRON
autoclaw のヘルスチェック。毎時実行。
autoclaw が落ちると、コンテンツ生成系の WF が全部詰まる。ブログ下書きも、X 投稿候補も、アフィリ素材も、全部止まる。
このWFは「autoclaw が 3 分以内に返答しなければ Slack に緊急通知」という設計になっている。タイムアウト設定が肝だ。
3位: WF-LINE-STEP-SEQUENCE
LINE のステップ配信管理WFだ。
新規 LINE 登録者が来た日から、Day1・Day3・Day7・Day14 と自動でメッセージが届く仕組みを制御している。これが止まると収益に直結する。
Supabase の line_subscribers テーブルと連動していて、配信ログも全部記録されている。1 通も取りこぼしていない。
4位: WF-BLOG-PUBLISH-HOOK
記事公開後のフック処理全体を担う。
Vercel のデプロイ完了 → Supabase 更新 → X 告知トリガー → Slack 通知、この連鎖を制御している。このWFが落ちると「記事は公開されているのに誰にも知らせていない」状態になる。
5位: WF-COST-REPORT-WEEKLY
毎週月曜に LLM / VPS / API の使用コストを集計して Slack に送る。
地味に見えるが、コスト超過に気づかないまま月 ¥10,000 以上払っていた、という事故を防いだのがこのWFだ。 3 月に autoclaw の設定ミスで Claude API を大量に呼んでいた週があったが、このレポートで当日中に発見できた。
廃棄したWFの話
廃棄した 15 本の WF について、正直に理由を書く。
WF-BLOG-INTERNAL-LINK(廃棄)
記事内の内部リンクを自動で提案する WF だった。記事全文を Claude に渡し、「この記事から内部リンクできる記事を探して」と依頼するものだ。
廃棄理由: コストに見合わなかった。
記事 1 本あたり約 ¥30 の Claude API コストがかかった。月 20 本の記事で ¥600。「内部リンクの質が上がっているかどうか」を測る方法がなかった。効果が見えないコストは切る。
WF-X-PERSONA-GEN(廃棄)
X のペルソナ別投稿文を自動生成する WF だった。「エンジニア向け」「副業初心者向け」「非エンジニア向け」と 3 パターンを生成していた。
廃棄理由: 生成したものを使わなかった。
3 パターン生成しても、俺が選んで投稿するのは結局 1 パターンだ。選ぶコストが生成のコストを上回った。今は 1 パターンだけ生成して、気に入らなければ手直しする方が速い。
WF-SCRAPER-X-UGC(廃棄)
X の UGC(ユーザー生成コンテンツ)をスクレイピングする WF だ。競合アカウントの人気ツイートを収集し、傾向を分析しようとしていた。
廃棄理由: X の利用規約問題 + データが使えなかった。
スクレイピングで取れるデータは断片的で、分析に使えるほどの精度がなかった。そもそも利用規約上グレーな部分がある。ROI がゼロだったので廃棄した。
WF-LP-HEATMAP-FETCH(廃棄)
LP のヒートマップデータを自動取得して Slack に送る WF だった。
廃棄理由: ヒートマップツールとの API 接続が不安定すぎた。
2 日に 1 回はエラーになり、その都度 DLQ に入る。修正コストと得られる情報を比べたとき、Google Analytics のデータを週次で手動確認する方が確実だと判断した。
実験中WFから見える「次のステージ」
⚠️ 実験中の WF が 6 本ある。これは「動いているが、本番採用するか判断中」のものだ。
WF-BLOG-SEO-AUDIT
公開済み記事の SEO スコアを定期チェックし、「タイトル変更推奨・meta description が短い・見出し構造が浅い」といった改善提案を Slack に送る WF だ。
現在精度を確認中。Claude の SEO 判断が「実際の検索順位と相関があるか」を 2 週間追っている。
WF-LINE-UPSELL-TRIGGER
LINE 登録者の行動履歴(メッセージ開封・クリック)を Supabase で分析し、購入可能性が高いユーザーに絞ってアップセルメッセージを送る WF だ。
まだセグメント精度が低い。「高可能性ユーザー」の定義を磨き中。
運用コストの実態
月額コストを全部出す。
| 項目 | 月額 | 備考 |
|---|---|---|
| VPS (n8n + autoclaw) | ¥700 | ConoHa VPS 2GB |
| Claude API | ¥300〜¥800 | autoclaw ルーティング後の実績値 |
| LINE 公式アカウント | ¥0 | フリープラン(1000通/月以内) |
| Supabase | ¥0 | Free Tier |
| Vercel | ¥0 | Hobby プラン |
| Uptime Kuma | ¥0 | VPS 内で自前運用 |
| GitHub Actions | ¥0 | 無料枠内 |
月合計: ¥1,000〜¥1,500
システム全体で月 ¥1,500 以内で動いている。この規模で運用できているのは、autoclaw のコスト最適化と、Supabase / Vercel の無料枠が大きい。
3 ヶ月運用して気づいた本質
数ではなく、「どのWFが毎日動いていてほしいか」を最初に定義すべきだった。
WF を作ることが目的になると、「動いているが誰にも使われていない WF」が増える。最初から「このWFが止まったら何が困るか」という問いで設計すれば、廃棄率はもっと下がった。
もう一つ。エラー監視は最初から作れ。
WF を 10 本作ったあとに監視を追加しようとすると、全部に設定し直す手間がかかる。最初の 1 本目から WF-ERROR-HANDLER を作って、全 WF の Error Workflow に設定する。これが正しい順番だ。
まとめ
- 55 本のうち毎日稼働しているのは 22 本。33 本は停止・廃棄・実験中
- 最重要WF: WF-ERROR-HANDLER → WF-AUTOCLAW-CRON → WF-LINE-STEP-SEQUENCE
- 廃棄理由の TOP は「コストに見合わない」と「生成したものを使わなかった」
- 月のランニングコストは ¥1,000〜¥1,500
- 数より先に「止まったら困るWFは何か」を定義することが本質
55 本という数字は、うまくいったことと失敗したことの両方の合計だ。廃棄した 33 本は「何が無駄か」を学んだコストだと今は思っている。
LINE 公式アカウント
稼働中22本のWF構成リストと、廃棄判断チェックシートをLINEで無料配布しています