n8nとDifyを本線へ入れなかった理由 — 自動化の正本をどこに置くか
今回やったこと / この記事について
n8nとDifyを、既存のAI記事制作・公開パイプラインへ導入できるか評価した。結論は、どちらも技術的には導入可能だが、本線には入れないという判断である。理由は「動かないから」ではなく、現在の運用がgitを単一真実源とし、エージェントがファイルを編集して検証し、PRで変更を確認する構造だからだ。
本稿は、ワークフローツールを導入する前に、何が改善され、何が別の場所へ移るのかを確認するための記録である。
実測した前提と評価軸
2026年8月3日時点の評価記録では、常時稼働する環境はメモリ8GB、Node.js v24.17.0、Docker未導入、ディスク空き72GBだった。n8n 2.32.7はNode.jsの要件を満たし、DockerなしでSQLiteを使って動かせる。一方、Difyのself-hosted構成はDocker Composeが必須で、複数のAPI・worker・データベース・キューなどを含む。
| 観点 | n8n | Dify |
|---|---|---|
| 実行可能性 | Node.js上で可能 | Docker Composeが必要 |
| 本線との接続 | Execute Commandで既存スクリプトを呼べる | LLMのDAGやRAGが中心 |
| 得られるもの | GUI、実行履歴、リトライ設定 | モデル接続、ワークフロー、RAG |
| 主な懸念 | SQLite内のGUI定義が正本になる | エージェントのファイル編集と合わない |
この表から分かるように、導入できるかと、導入する価値があるかは別である。評価では、容量よりも正本・実行モデル・障害範囲を重視した。
n8nはスケジューラ層を置き換えるだけになりやすい
現在の処理で価値を生むのは、記事の検証、検索、画像処理、API呼び出し、PR作成といった個別スクリプトである。n8nへ移しても、それらをExecute Commandノードから同じように呼ぶなら、置き換わるのは主にlaunchdのスケジューラ層になる。
ポーリングをイベント駆動へ変えられる点も検討したが、記事公開はもともと時間帯を分けたバッチである。15分程度の反応遅延は、日次の公開枠を運用する上で支配的な問題ではない。47本のジョブを移植して得られるのがGUIと履歴だけなら、移植コストに見合いにくい。
さらに、n8nへ集約すると障害の境界が広がる。現状はジョブがプロセス単位で分かれているため、1本が落ちても別ジョブは動く。中央のデーモンに依存すると、メモリ不足などの影響が複数レーンへ波及し得る。
Difyは実行モデルが本線と異なる
Difyは、モデル接続・RAG・ワークフローを組み立てる用途には向いている。しかし本線で必要なのは、LLMの回答を得ることだけではない。ファイルを読み書きし、検証スクリプトを走らせ、差分を作り、PRへ渡すエージェント実行である。
Difyのワークフローへ置き換えると、記事作成の中心が「ファイルを編集するエージェント」から「ステートレスなLLMのDAG」へ変わる。既存のモデル登録、検索、履歴検索、プロンプト管理にも自前の等価物があるため、導入によって能力が増えるより、正本が複数に分かれる危険が大きい。
導入しないことも実装上の結論
評価の結果、本線へ採用しなかった。ただし調査は無駄ではなかった。n8nのリトライ機能を見たことで、既存スクリプト166本のうち、リトライやバックオフを持つものが2本しかないという別の穴が見つかった。改善対象はワークフロー全体の載せ替えではなく、外向き通信を共通のhttp_retry()ヘルパーへ寄せることになった。
導入候補を試す
↓
得られる機能を既存部品と比較する
↓
正本・障害境界・編集主体を確認する
↓
採用 / 部分採用 / 見送りを分ける
やってみてわかったこと
ワークフローツールの評価では、「インストールできるか」を最初の合否にすると判断を誤る。実行基盤を追加すると、GUIに保存された定義や別のデータベースが正本になり、gitレビューから外れることがある。これは機能不足より長期運用に効く問題である。
n8nは外部SaaS連携や限定的な可視化など、本線の外側なら候補になる。Difyも実験用の対話フローとしては使える。しかし記事制作と公開の正本を置く場所は変えない。採用しないという判断を記録しておくこと自体が、将来の重複導入を防ぐ設計資料になる。
更新履歴
- 2026-08-19: 初稿。n8n/Difyの本線導入評価を整理。
訂正履歴
- なし。