n8n：20万スターのワークフロー自動化プロジェクト、セルフホスト前に知っておくべき4つのこと

n8n は「ワークフロー自動化」をオープンソースプロジェクト化したプラットフォームです。GitHub 上の n8n-io オーガニゼーションがメンテナンスする n8n リポジトリは 20 万スターを突破し、今最もホットな自動化インフラプロジェクトの一つとなっています。「オープンソース版 Zapier」と理解するのが手っ取り早いですが、プラットフォーム全体を自社サーバーに載せられる点が違います。データは社外に出ず、セルフホストに実行回数の制限はありません。

n8n とは

一言で言えば、ビジュアルキャンバスとコードノードを組み合わせたワークフロー自動化プラットフォームであり、AI エージェントのオーケストレーションをネイティブにサポートします。

キャンバス上でノードをドラッグしてワークフローを組み立てます。スケジュール起動、Webhook、API 呼び出し、データベースの読み書き。複雑なロジックは Code ノードに JavaScript や Python で直接記述でき、npm パッケージも使えます。近年は AI に軸足を移しており、LangChain ベースの AI エージェントノードでワークフローから直接大規模言語モデルを呼び出し、ツールを接続し、マルチステップ推論を実行できます。公式テンプレートライブラリには 9000 以上のワークフローが揃っています。n8n は nodemation の略で、「n-eight-n」と読みます。

なぜこれほど人気なのか

第一に、AI エージェントの実用化には「オーケストレーション層」が必要だからです。考えるのは大規模言語モデルですが、実際に働くのはツール呼び出し、分岐判断、人間の承認といったプロセスです。LangGraph のようなエージェントオーケストレーションが解くのも同じクラスの問題であり、n8n は非エンジニアチームにも使えるビジュアルインターフェースを提供します。第二にデータ主権。金融や医療の現場ではデータを第三者の SaaS に預けられません。第三に料金体系。公式クラウドは実行回数課金、セルフホストはサーバー代だけ。実行量の多いチームは試算して乗り換えます。

向いている人・向いていない人

向いている：基礎的な運用スキルを持つ個人開発者や小規模チーム。データを社外に出せない企業。AI エージェントを既存システムに組み込み、内部 API やデータベースを頻繁に叩くケース。実行量が多く、SaaS の従量課金が気になるチーム。

向いていない：サーバーに一切触れたくない人。セルフホストではアップデート、バックアップ、セキュリティを自分で担います。自動化が 2〜3 個だけで、チームが非エンジニア中心なら、Zapier や Make の純粋 SaaS の方が楽です。もう一点、n8n のライセンスは fair-code（Sustainable Use License）であり、ソースは公開されていますが OSI 認定のオープンソースライセンスではありません。法務がライセンスに厳しい企業は導入前に条文を確認してください。

デプロイコスト：実際のお金の話

導入は一瞬です。Docker コマンド一発で起動し、デフォルトは SQLite、ブラウザで 5678 番ポートを開けば使えます。これが「試用コスト」です。

本番環境は別の帳簿になります。軽い試用は 1 vCPU・メモリ 2GB から、本番運用なら 2 vCPU・4GB 以上に PostgreSQL への切り替えが推奨されます。同時実行が多い場合や AI の実行時間が長い場合はキューモードを使い、Redis をタスクキューとして、メインプロセスと worker を分離します。要件を満たす VPS は月 4〜10 ドル程度。実行回数に上限のある公式クラウドのスタータープラン（月 24 ユーロ）と比べれば、ハードウェアコストは確かに安い。モデルもローカルで動かしたい場合はOllama のセルフホストコスト分析を参照してください。隠れコストもお忘れなく。セキュリティパッチ、バージョンアップ、バックアップ、深夜のアラート対応は継続的な人的コストです。

セルフホスト前に知っておくべき4つのこと

1. 暗号化キーを失くすと、保存済みの認証情報は全滅します。 n8n はサードパーティの認証情報をすべて N8N_ENCRYPTION_KEY で暗号化し、キーは /home/node/.n8n ディレクトリに置かれます。公式ドキュメントは警告しています。起動時にこのディレクトリが見つからなければ、n8n は新しいキーを自動生成し、古い認証情報は二度と復号できません。シングル構成からキューモードへの移行時にキーを失くし、一夜にして全接続が死んだというコミュニティ報告もあります。対策：初日にキーを明示的に設定してサーバー外にバックアップし、移行時はデータより先にキーを移します。

2. メジャーバージョンアップの破壊的変更は日常茶飯事です。 n8n のリリースは速く、メジャー間では破壊的変更が珍しくありません。2.0 ではタスクランナーがメインイメージから分離され、セルフホストには n8nio/runners イメージの追加が必要です。2026 年 10 月予定の 3.0 ではセルフホストに Docker が必須となり、npm インストールはサポート外、レガシーノードも整理されます。データベースのマイグレーションは前進のみで、公式のロールバック経路はありません。対策：本番環境ではイメージバージョンを固定し、アップグレード前にデータベースをバックアップ、公式の移行レポートで影響を受けるワークフローを事前に洗い出します。

3. デフォルト構成では同時実行と高負荷に耐えられません。 デフォルトの SQLite＋シングルプロセスでは、同時実行が増えたり単一ワークフローのデータ量が大きくなったりすると、メモリの高騰やコンテナのクラッシュがコミュニティで最も多い訴えです。本番環境では PostgreSQL への切り替え、実行履歴の自動クリーンアップ、苦しければサブワークフローへの分割を。AI エージェント利用者は特に注意。長時間実行や多段階のツール呼び出しは従来の自動化よりはるかにメモリを食います。キューモードでは worker 1 台あたり 1〜2GB で計画してください。

4. セルフホストはセキュリティ責任の全部引き受けを意味します。 2026 年 9 月の GitGuardian の調査では、公開 Git コミットのスキャンで 4576 件の漏洩した n8n API トークンが見つかり、129 台の公開インスタンスが漏洩済みの弱い暗号化キーを使い続けていました。ポートの公開、リバースプロキシ、HTTPS、パッチ適用。SaaS 時代にプラットフォームが肩代わりしていた作業は、今や全てあなたのものです。対策：5678 番ポートを直接公開せず、トークンやキーは環境変数とシークレット管理で扱い、本番環境では HTTPS を必須にします。