「n8nというツールを社内で入れたいと言われたのですが、何なのでしょうか」——情報システムのご担当者や、DX推進を任された方から、こうした相談をよく受けます。若手が使いたがっている。無料らしい。AIエージェントも作れるらしい。ただ、自分が理解していないものを社内に通すわけにはいかない。そこで止まっている方は少なくありません。
先に結論を書きます。n8nとは、外部のサービスやAIを「ノード」としてつなぎ、決めた条件で自動的に走らせるワークフロー自動化ツールです。そして、この記事でいちばん丁寧に書きたいのはライセンスの話です。n8nは、ソースコードが公開されている一方で、一般的なオープンソースライセンスではありません。 Sustainable Use License, Version 1.0 という独自のライセンスが適用されており、自社の社内業務で使うことは認められる一方、第三者へホスティングサービスとして提供することは認められていません。「オープンソースだから自由に使えます」と説明して導入すると、後から法務に指摘される可能性があります。
この記事では、n8nの仕組み(ノード・トリガー・実行)から始めて、ライセンスとセルフホスト/クラウドの違い、料金体系、ZapierやMakeとの違い、AIエージェント用途、社内で運用するときに先に決める3つのこと、そして自動化ツールで足りる範囲と開発が必要になる境界までを順に扱います。ノーコードという考え方そのものの定義や、ツールの分類と限界については、別記事『ノーコードとは』が担当しているのでそちらに譲ります。この記事は「n8nという具体的なツール」に集中します。
料金・機能・ライセンスの記述は、すべて2026年9月15日にn8n公式サイト、公式ドキュメント、GitHubのライセンス表記を直接確認したものです。n8nは改定が頻繁なので、導入を検討される際は必ず公式で最新の内容をご確認ください。確認できなかった数値は、この記事には書いていません。
私はTALENTBASE VIETNAMでCOOを務めています。人材業界の出身で、2018年からホーチミンを拠点に、約100社の開発体制づくりを支援してきました。その立場から最後にひとつだけ申し上げると、自動化ツールで足りるなら開発する必要はありません。当社にご相談いただいても、ツールで済む内容であればその旨を率直にお伝えしています。大事なのは、どこまでがツールの仕事で、どこからが開発の仕事なのかを先に知っておくことです。
目次
- n8nとは——ノード・トリガー・実行で動くワークフロー自動化ツール
- 定義: サービスとサービスをつなぎ、決めた条件で自動的に走らせる仕組み
- ノード——処理のひとかたまり。500を超える連携先が用意されている
- トリガーと実行
- n8nでできること、できないこと
- n8nのライセンスと提供形態
- 適用されているのは Sustainable Use License, Version 1.0
- fair-code はライセンスの名前ではない
- セルフホスト
- クラウド版——運用を任せる代わりに実行回数で課金される
- 料金体系【2026年9月15日確認】
- ZapierやMakeとの違い
- 課金単位の違い
- 拡張性の違い
- 運用負荷の違い
- AIエージェント用途でのn8n
- AI Agentノード
- 業務でよく使われる形
- 向かないのは、間違いが許されない処理と、説明責任が要る判断
- 社内で運用するときに先に決める3つ
- 認証情報——暗号化キーを失うと、つないだサービスすべてを登録し直すことになる
- 実行ログ——どこまで残すか、誰が見られるか
- 可用性——1台構成のままでは、止まったときに気づけない
- n8nで足りる範囲と、開発が必要になる境界
- 5つの問いで、ツールで足りるかを確かめる
- 開発が必要になったときの受け皿
- 当社が向かないと判断する案件
- n8nに関するよくある質問
- Q1. n8nの読み方は何ですか
- Q2. 本当に無料で使えますか
- Q3. 商用利用はできますか
- Q4. 日本語の情報は十分にありますか
- Q5. n8nで組んだ自動化を、開発に置き換えるべきかどうか相談できますか
- まとめ: n8nは仕組みとライセンスを押さえてから入れる。ツールで足りるなら作らないほうがよい
n8nとは——ノード・トリガー・実行で動くワークフロー自動化ツール

n8nという名前を社内で聞いたとき、多くの方が最初に思うのは「それはRPAなのか、SaaSなのか、開発ツールなのか」という疑問です。結論から言えば、外部のサービス同士をつなぎ、決めた条件で自動的に走らせるワークフロー自動化ツールです。仕組みそのものは、ノード・トリガー・実行という3つの言葉を押さえれば理解できます。この3語は、後半で扱う料金の考え方や他ツールとの違いにも直結します。
定義: サービスとサービスをつなぎ、決めた条件で自動的に走らせる仕組み
n8nの公式ドキュメントは、n8nを「AI機能とビジネスプロセスの自動化を組み合わせた、fair-codeライセンスのワークフロー自動化ツール」と説明しています。画面上で組み立てる操作と、必要な箇所でコードを書く操作の両方が使えることが特徴で、「UIで済むときはUIで、コードが必要なときはコードで」という考え方です。なお、ここに出てくる fair-code という語の意味は、次の章で詳しく扱います。この語を「オープンソース」と同じ意味で受け取ると、判断を誤ります。
読み方について補足しておきます。公式ドキュメントには名前の由来や読み方の説明はありませんが、日本語の記事や解説では「エヌエイトエヌ」と表記されるのが一般的です。社内の会議で口頭で説明するときは、この読み方で通じます。
n8nを一言で説明するなら、業務のなかで人が手で行っている「あのサービスを見て、この内容をあちらに転記する」という作業を、画面上の図として組み立て、自動で走らせるための道具です。何かを新しく作るというより、すでにある道具同士をつなぐ位置づけだと考えてください。
ノード——処理のひとかたまり。500を超える連携先が用意されている
ノード(node)は、ワークフローを構成する部品です。公式ドキュメントの用語集は、ノードを「ワークフローを作るために組み合わせる個々の構成要素。ノードはワークフローがいつ動くかを定義し、データの取得・送信・加工を行う」ものと説明しています。
具体的には、Gmailからメールを取得するノード、Slackにメッセージを投稿するノード、Googleスプレッドシートに行を追加するノード、といった単位です。これらを線でつなぐと、ひとつの業務の流れになります。
連携先の数については、公式サイト内でも数え方によって表記が異なります。2026年9月15日時点で、公式のインテグレーション一覧ページには2,174件が掲載されており、トリガーノード、通常のノード、コアノード、AI向けノード(エージェント、チェーン、埋め込み、言語モデル、メモリ、ベクトルストアなど)が含まれます。一方、公式トップページの表記は「500を超える連携」です。数え方の違いだと考えられますので、自社が使いたいサービスのノードがあるかどうかは、件数ではなく一覧ページで名前を直接探して確認してください。 なお、汎用のHTTPリクエストノードがあるため、APIが公開されているサービスであれば専用ノードがなくてもつなげます。
もうひとつ、n8nの特徴として押さえておきたいのがコードを書けるノードの存在です。JavaScriptまたはPythonで処理を書き足せるため、標準のノードだけでは表現できない加工を挟めます。ここは後で扱うZapierとの違いにも関わってくる部分です。
トリガーと実行——「いつ動くか」と「1回動いた記録」
トリガーノード(trigger node)は、ワークフローの起点です。公式ドキュメントは「特定の条件に応じてワークフローを実行する役割を持つ。本番運用するワークフローには最低1つのトリガーが必要」と説明しています。
トリガーには主に次の種類があります。
トリガーの種類 | 動くきっかけ | よくある用途 |
|---|---|---|
スケジュール | 決めた時刻・間隔 | 毎朝9時のレポート送信、1時間ごとの在庫チェック |
Webhook | 外部から届いたHTTPリクエスト | フォーム送信、決済サービスからの通知 |
ポーリング | 一定間隔で外部を見に行き、新しいデータがあったとき | 新着メール、新規レコードの検知 |
手動 | 人が実行ボタンを押したとき | 開発中の動作確認 |
実行(execution)は、ワークフローが1回動いたことを指します。公式ドキュメントは実行を「ワークフローの1回の走行」と定義し、本番実行のみが利用枠(クォータ)の対象で、手動のテスト実行は数えないとしています。さらに、サブワークフローやエラー処理用のワークフローは親の実行1回として数えられます。
この数え方は、料金の話に直結します。トリガーの種類によって数え方が変わる点も重要です。公式ドキュメントによれば、スケジュールトリガーは起動するたびに1回、ポーリングトリガーは新しいデータが見つかったときのみ1回、Webhookトリガーは受け取ったリクエストごとに1回と数えられます。1時間ごとに在庫を見に行くワークフローを組むと、何も起きなくても月に720回の実行が発生する、という計算になります。
n8nでできること、できないこと
得意と不得意を先に整理しておきます。
内容 | |
|---|---|
得意なこと | 複数のSaaSをまたいだデータの受け渡し、定型的な通知と集計、外部APIの呼び出し、LLMを挟んだ文章の生成・分類、社内向けの簡易な自動処理 |
不得意なこと | 顧客に提供する画面(UI)を持つアプリケーション、自社固有のデータモデルの設計と保持、厳密なトランザクション処理(途中で落ちたら全部戻す種類の処理)、多数のユーザーが同時に使う本番システムとしての可用性 |
この線引きは、記事の最後で扱う「開発が必要になる境界」の話につながります。いま押さえていただきたいのは、n8nが担うのはつなぐ仕事であって、作る仕事ではないということです。
なお、ノーコードという考え方そのものの定義や、ツールの分類、どこで限界が来るのかといった一般論については、当ブログの『ノーコードとは』の記事で扱っています。n8nはその中の「自動化型」に当たるツールです。本記事では、一般論には立ち入らず、n8nという具体的なツールの中身に集中します。
仕組みが分かったところで、次に多くの方が確認したいのは「本当に無料で使えるのか」という点でしょう。ここにはライセンスという、避けて通れない論点があります。
n8nのライセンスと提供形態——「オープンソース」と単純に呼べない理由

n8nを紹介する日本語の記事の多くは、「オープンソースなので無料で使えます」と書いています。半分は正しく、半分は不正確です。ソースコードは公開されていますが、適用されているライセンスは一般的なオープンソースライセンスではありません。ここを曖昧にしたまま社内で説明すると、後から法務に指摘される可能性があります。この節が、この記事でいちばん丁寧に書きたい部分です。
適用されているのは Sustainable Use License, Version 1.0
n8nの公式リポジトリに置かれているライセンス表記(2026年9月15日確認)によれば、適用されているのは Sustainable Use License, Version 1.0 です。MITでもApache 2.0でもGPLでもありません。
このライセンスは、利用者に対して「非独占的・ロイヤリティ無料・世界的・サブライセンス不可・譲渡不可の、使用・複製・配布・提供・二次的著作物の作成を行う権利」を与えたうえで、次の3つの制限を置いています。
制限 | 条文の要点 | 実務上の意味 |
|---|---|---|
1. 利用目的 | 「自分自身の内部業務目的、または非商用・個人利用に限って、ソフトウェアを使用または改変できる」 | 自社の業務を自動化するために使うのは問題ない。営利企業が社内業務に使うことも「内部業務目的」に含まれる |
2. 配布 | 「ソフトウェアを配布または他者に提供できるのは、非商用目的で無償で行う場合に限る」 | n8nを組み込んだものを有償で他社に売る、n8nをホスティングして顧客に使わせる、といった形は認められない |
3. 表示 | 「ライセンス表示、著作権表示その他の通知を、変更・削除・隠蔽してはならない」 | ロゴや表記を消して自社製品のように見せることはできない |
加えて、これらの制限に違反した場合、またはソフトウェアに対して特許の主張を行った場合には、ライセンスが自動的に終了する条項が置かれています。
事業会社の担当者にとって重要なのは、次の一点です。自社の社内業務を自動化する目的でn8nを使うことは、この条文のもとで問題ありません。 一方、n8nを自社サービスの一部として第三者に提供する構想がある場合は、この無償ライセンスの範囲を外れます。その場合はn8n社との商用契約が必要になります。
私が申し上げたいのは、「使ってはいけない」ということではありません。どこまでが無償で、どこから先が契約なのかを、導入前に社内で共有しておいてくださいということです。稟議を通したあとで構想が変わり、そこで初めて気づく——これがいちばん面倒な形になります。
fair-code はライセンスの名前ではない
n8nは自社の提供モデルを「fair-code」と呼んでいます。この語を見て「fair-codeライセンス」という名前のライセンスがあるのだと理解している方がいますが、そうではありません。
fair-code を定義している faircode.io は、冒頭で明確に「fair-code はソフトウェアライセンスではない」と述べています。fair-code とは、次の4つの性質を持つソフトウェアの提供モデルを指す呼び名です。
- 一般に無料で使え、誰でも配布できる
- ソースコードが公開されている
- 公開・非公開のコミュニティで誰でも拡張できる
- 作者によって商用利用が制限されている
そして、このモデルを実現するために使われる実際のライセンスとして、Business Source License、Elastic License 2.0、Server Side Public License などが挙げられています。n8nの場合、それが Sustainable Use License に当たります。
つまり、fair-code は「考え方」の名前、Sustainable Use License は「契約」の名前です。社内で説明するときは後者の名前を使ってください。faircode.io 自身も、fair-code をOSI(Open Source Initiative)の定義に沿うオープンソースだとは主張しておらず、従来のオープンソースに対する「代替のモデル」と位置づけています。
セルフホスト——無料で使えるが、無料なのはソフトウェアだけ
n8nには、自社のサーバーで動かすセルフホストと、n8n社が運用するクラウド版の2つの使い方があります。公式ドキュメントは、セルフホストを「デプロイと設定を完全に自分で管理したい場合」「無料でn8nを動かしたい場合」に向くとしています。
セルフホストで使える無料の版はCommunity edition(コミュニティ版)と呼ばれ、公式ドキュメントは「ほぼ完全な機能セット」を含むと説明しています。ただし、含まれない機能があります。2026年9月15日時点で公式ドキュメントが挙げているのは次の通りです。
- カスタム変数
- 環境(Environments)
- 外部シークレット管理
- バイナリデータの外部ストレージ
- ログのストリーミング
- マルチメイン構成(multi-main mode)
- プロジェクト
- SSO(SAML、LDAP)
- ワークフローと認証情報の共有
- Gitによるバージョン管理
このうち、SSO・プロジェクト・ワークフローの共有・Gitによるバージョン管理あたりは、複数名のチームで運用を始めると欲しくなる機能です。1人で試すぶんには困りませんが、組織で使う段階では有償プランの検討対象になります。なお、メールアドレスを登録して無償のまま使えるようになる機能として、フォルダ、エディタ上でのデバッグ、カスタム実行データの3つが公式に挙げられています。
そしてもうひとつ、当たり前ですが見落とされやすい点があります。無料なのはソフトウェアのライセンスであって、運用は無料ではありません。 サーバー、データベース、バックアップ、バージョン更新、障害時の復旧。これらは自社の仕事として残ります。ここを見積もらずに「無料だから」と決めるのは失敗のもとです。
クラウド版——運用を任せる代わりに実行回数で課金される
クラウド版は、n8n社が「ホスティング、更新、スケーリングを引き受ける」フルマネージドのサービスです。公式ドキュメントは、素早く始めたい場合や、技術的な知見を持つ担当者がいない場合に向くとしています。14日間の無料トライアルがあり、その期間はPro相当の機能を試せます。
セルフホストとクラウド版の選択は、機能の差というより、サーバー運用を自社で持つかどうかの選択だと考えてください。個人情報や機密情報を扱うため外部に出せない、という要件がある場合はセルフホスト、そうでなければクラウド版から始めるのが現実的です。
料金体系【2026年9月15日確認】
n8n公式の料金ページで確認した内容は次の通りです。金額はユーロ建てで、いずれも年払いの場合の月額です。
プラン | 月額(年払い) | 月間の実行回数 | 同時実行 | 共有プロジェクト | 備考 |
|---|---|---|---|---|---|
Community(セルフホスト) | 無料 | 制限なし(自社サーバーの性能次第) | — | — | 上記の非対応機能あり |
Starter | 20ユーロ | 2,500回 | 5 | 1 | ユーザー数・ワークフロー数は無制限 |
Pro | 50ユーロ | 10,000回 | 20 | 3 | 同上 |
Business | 667ユーロ | 40,000回 | — | 6 | セルフホストの選択肢あり |
Enterprise | 個別見積もり | 個別 | 200以上 | 無制限 | セルフホスト/クラウドの両方 |
ここで効いてくるのが、前の節で説明した実行の数え方です。n8n公式は「1回の実行とは、ワークフロー全体の1回の走行のこと。ステップがいくつあるか、どれだけのデータを処理するかは関係ない」と明記しています。
つまり、20ステップのワークフローも2ステップのワークフローも、1回動けば同じ1回です。この考え方が、次の節で扱うZapierやMakeとの決定的な違いになります。
金額と機能は改定されます。稟議に使う数字は、必ず公式の料金ページで当日の表示を確認してください。当社が単価を公開しているのと同じ理由で、私は料金の話を曖昧にしたくありません。ただし他社の料金については、こちらで断定するより、読者ご自身が一次情報に当たるほうが確実です。
ZapierやMakeとの違い——課金単位・拡張性・運用負荷の3点で比べる

すでにZapierやMakeを使っている企業から「n8nに乗り換えるべきか」というご相談をいただくことがあります。この判断は、機能の多寡ではなく構造の違いで考えたほうが早いです。3つのツールを分けているのは、課金単位・拡張性・運用負荷の3点です。順に見ていきます。
課金単位の違い——実行単位・タスク単位・オペレーション単位
いちばん大きな違いがここです。3ツールはそもそも「何を数えて課金するか」が違います。2026年9月15日に各社の公式料金ページで確認した内容を並べます。
n8n | Zapier | Make | |
|---|---|---|---|
課金の単位 | 実行(execution)=ワークフロー1回の走行 | タスク=アクションが1つ成功するたび | オペレーション(クレジット)=モジュールの動作1回ごと |
ステップ数の影響 | 受けない(何ステップあっても1回) | 受ける(ステップが増えるほどタスクが増える) | 受ける(モジュールが増えるほど消費が増える) |
無料の範囲 | セルフホストは無料。クラウドは14日間のトライアル | 月100タスク、2ステップまで、ポーリング間隔15分 | 月1,000クレジット、稼働シナリオ2本まで、実行間隔15分 |
有料の入口(公式表示) | Starter 月20ユーロ(年払い)/ 月2,500回 | Professional 月19.99ドル〜(年払い) | Core 月9ドル〜 |
連携できるサービス数 | 公式の一覧ページに2,174件(トップページの表記は500超) | 9,000超 | 3,000超 |

この表から読み取っていただきたいのは、優劣ではなく得意な形が違うという点です。
n8nが有利になるのは、ステップ数の多いワークフローを比較的少ない回数まわす使い方です。たとえば、1件の問い合わせに対してデータを取得し、AIで分類し、条件で分岐し、3つのシステムに書き込む——という10ステップ超の処理を1日50回まわすなら、n8nでは月1,500回の実行です。Zapierのタスク単位では、同じ処理で月数万タスクに届きます。
逆に、2ステップ程度の単純な転記を1日数千回まわすような使い方では、実行単位の課金が必ずしも有利にはなりません。そして、連携できるサービスの数ではZapierが大きく上回ります。使いたいサービスの専用ノードがn8nに無い場合、HTTPリクエストノードで自分でAPIを叩くことになり、ここには技術的な手間が発生します。
「n8nのほうが安い」という説明をよく見かけますが、正確には「ワークフローの形によって安くなることがある」です。自社の実際のワークフローで、ステップ数と月間の起動回数を数えてから比べてください。ここを構造で考えずに乗り換えると、期待した削減が出ません。
拡張性の違い——コードを書ける逃げ道があるかどうか
2つめの違いは、標準の部品で表現できないことが出てきたときに逃げ道があるかどうかです。
n8nにはJavaScriptとPythonのコードノードがあり、処理の途中に任意のロジックを差し込めます。さらに、セルフホストであれば自作のノードを追加することもできます。「画面で組めるが、必要なら書ける」という設計です。
Zapierにもコード実行のステップはありますが、n8nほど自由度は高くありません。Makeは関数と反復処理が充実しており、中間的な位置づけです。
この差が効いてくるのは、ワークフローが複雑になってからです。ノーコードのツール全般に言えることですが、標準の部品で表現できない要件が出たときに、回避策を積み重ねて無理やり通すと、後から誰も読めないワークフローが残ります。コードを書ける逃げ道があることは、こうした事態を避ける保険として働きます。
ただし、逃げ道があることは、逃げ道を使うべきだという意味ではありません。コードノードを多用したワークフローは、結局のところプログラムです。それなら最初から開発したほうが保守しやすい、という分岐点があります。この線引きは、この記事の最後の章で扱います。
運用負荷の違い——誰がサーバーの面倒を見るか
3つめは、セルフホストという選択肢を持つn8nに固有の論点です。ZapierとMakeはクラウドサービスのみで、サーバーの心配はしなくて済みます。
n8nをセルフホストする場合、以下が自社の仕事になります。
- サーバーの用意と初期構築(Docker、Docker Compose、npm、クラウド事業者のイメージなどの選択肢がある)
- データベースの運用とバックアップ
- バージョン更新への追随
- 障害の検知と復旧
- 認証情報の暗号化キーの保管
セルフホストの魅力は、データが自社の管理下に残ることと、実行回数の制限がなくなることです。個人情報を扱う自動化を組みたい企業にとって、前者は決定的な理由になります。
一方で、この運用を担える人が社内にいるかどうかが分かれ目です。情報システム部門が2〜3名で基幹システムの保守に追われている、という状況で新しいサーバーを1台増やす判断は、慎重にすべきです。私の見てきた範囲では、まずクラウド版で業務が回ることを確認し、データの要件でどうしても外に出せないと分かった段階でセルフホストへ移る、という順序が無理がありません。
3つのツールに優劣はありません。ステップ数の多い処理を組みたいならn8n、つなぎたいサービスの幅を優先するならZapier、その中間を取るならMake。自社のワークフローの形で選んでください。
AIエージェント用途でのn8n——何ができて、何が向かないか

2025年以降、n8nの名前を「AIエージェントを作れるツール」として知った方が増えています。実際、公式サイトも「見て、制御できるAIエージェントとワークフロー」を作れることを前面に出しており、すべての判断を確認でき、人が途中に入れることを特徴として挙げています。ここでは、n8nでAIエージェントを組むとは具体的に何をすることなのか、そしてどこまでが現実的なのかを整理します。
AI Agentノード——モデルに「次に何をするか」を決めさせる
n8nには、LangChainの考え方を取り込んだAI向けのノード群があります。中心になるのがAI Agentノードです。
公式ドキュメントは、エージェントを「判断の仕方を知っているチェーン」と表現しています。通常のワークフローは、あらかじめ決めた順番どおりに処理が進みます。これに対してエージェントは、言語モデルに次にどの道具を使うかを決めさせ、必要なら道具を呼び、結果を見てまた次を決める、という繰り返しで動きます。
AI Agentノードには、次のものを接続します。
接続するもの | 役割 | 具体例 |
|---|---|---|
チャットモデル | 判断と文章生成を担う頭脳 | 各社のLLMに対応するノード |
ツール | エージェントが呼び出せる道具 | 検索、データベース照会、他のワークフローの呼び出し |
メモリ | 会話の流れを覚えておく仕組み | 直近のやり取りの保持 |
ベクトルストア | 文書を検索できる形で保持する場所 | 社内文書の検索(いわゆるRAG) |
つまり、AIエージェントを「作る」と言っても、ゼロからモデルを訓練するわけではありません。 既存のLLMに、社内のデータと道具へのアクセスを与え、どういう順番で使わせるかを画面上で組み立てる作業です。この理解があると、外部から来る提案の妥当性も判断しやすくなります。
業務でよく使われる形——問い合わせの一次対応、社内文書の検索、定型レポート
実務で採用されやすいのは、次の3つの型です。
1. 問い合わせの一次対応。 チャットやフォームから届いた内容を分類し、定型の質問には回答を返し、それ以外は担当者に振り分けます。人の判断が要る部分を残す形なら、誤答のリスクを抑えられます。
2. 社内文書の検索。 規程・マニュアル・過去の議事録をベクトルストアに入れておき、質問に対して該当箇所を引いて答えさせます。回答に出典を添える形にしておくと、利用者が自分で確認できます。
3. 定型レポートの作成。 複数のシステムから数値を集め、決まった観点で要約して配信します。数値そのものはワークフロー側で正確に取得し、LLMには文章化だけを任せる分担にすると事故が減ります。
この3つに共通するのは、間違いが起きても人が気づける形になっているという点です。当社でもLLMを組み込んだチャットボットを開発していますが、設計で最も時間をかけるのは、AIに任せる範囲と人が確認する範囲の線引きです。
向かないのは、間違いが許されない処理と、説明責任が要る判断
一方で、向かない使い方もはっきりしています。
- 金銭の計算や送金の実行。 言語モデルは同じ入力でも毎回同じ出力を返すとは限りません。金額を扱う処理は、ワークフロー側の確定的な処理で行ってください
- 法令や契約に関わる最終判断。 下書きを作らせるのは有効ですが、そのまま出す形にすると説明責任を果たせません
- 監査や規制対応で、判断の根拠を後から完全に再現する必要がある処理。 エージェントの判断過程は記録できますが、同一の再現は保証されません
- 応答時間が厳密に決まっている処理。 外部のLLMを呼ぶ以上、応答時間は変動します
それから、PoC(試作)と本番運用のあいだには段差があります。担当者が1人で組んだワークフローが社内で評判になり、いつの間にか1,000人が使う状態になっている——この形は要注意です。誰が保守するのか、止まったときに誰が気づくのか、認証情報は誰が管理しているのか。次の章で扱う3点は、まさにこの段差を埋めるためのものです。
なお、AIエージェントの開発をどこに頼むか、どんな会社があるのかという話は、当ブログの『AIエージェント開発会社』の記事で扱っています。本記事はn8nというツールの説明に集中するため、そちらに譲ります。
社内で運用するときに先に決める3つ——認証情報・実行ログ・可用性

ここまでは「n8nとは何か」の話でした。ここからは、実際に社内で動かし始めたあとに効いてくる話をします。導入の可否より、導入した後の設計のほうが、後々の負担を大きく左右します。先に決めておくべきことは3つです。認証情報の管理、実行ログの扱い、そして可用性です。いずれも動き始めてから変えようとすると、費用も手間も跳ね上がります。
認証情報——暗号化キーを失うと、つないだサービスすべてを登録し直すことになる
n8nは、つなぐ先のサービスごとに認証情報(credential)を保存します。公式ドキュメントの用語集は、認証情報を「特定のアプリやサービスに接続するための認証情報を保存するもの」と定義しています。APIキー、OAuthのトークン、ID・パスワード。つまり、n8nのデータベースには社内の主要なSaaSへの鍵が集まることになります。
これらはデータベース内で暗号化されて保存され、その暗号化に使われるのが N8N_ENCRYPTION_KEY という環境変数です。公式ドキュメントは、この変数を「n8nのデータベース内の認証情報を暗号化するために使うカスタムキーを指定する」ものと説明しており、指定しない場合は初回起動時にランダムなキーが生成されるとしています。
ここに落とし穴があります。自動生成されたキーは、コンテナを作り直したり、データを別環境に移したりすると失われることがあります。キーを失うと、暗号化された認証情報は復号できません。つないでいたサービスすべてを、手作業で登録し直すことになります。
ですから、セルフホストで運用するなら次の3点を最初に決めてください。
N8N_ENCRYPTION_KEYを自分たちで生成し、明示的に指定する- そのキーを、n8nのサーバーとは別の場所(パスワード管理ツールや鍵管理サービス)に保管する
- キーを知っている人を社内で2名以上にしておく(担当者1名だけにしない)
公式ドキュメントには、暗号化キーを定期的に入れ替えるローテーションの機能についての記述もあります。あわせて、ワークフローのノードが接続できるホストやIP範囲を制限するSSRF対策、利用者に使わせたくないノードをブロックする設定、SSOや二要素認証の導入なども、セキュリティの項目として案内されています。全部を最初からやる必要はありませんが、どれを採用するかを情報システム部門と一度話しておくことをおすすめします。
実行ログ——どこまで残すか、誰が見られるか
n8nは、ワークフローが動いた記録を実行(execution)として保存します。この記録には、各ノードが受け取ったデータと返したデータが含まれます。便利な反面、業務データがそのままログに残るということでもあります。
問い合わせフォームの内容、顧客のメールアドレス、請求金額。自動化の対象が業務そのものである以上、実行データには個人情報や機密情報が入り得ます。ここで決めておくことは3つです。
決めること | 具体的に | 理由 |
|---|---|---|
保持期間 | 実行データを何日残すか | 無期限に貯めるとデータベースが膨らみ、漏えい時の影響も広がる |
秘匿の範囲 | どのワークフローの入出力を隠すか | 公式には、実行のステータスや所要時間といったメタデータは残しつつ、入出力データを隠す仕組みが用意されている |
閲覧できる人 | 誰が実行履歴を見られるか | 認証情報と同様、実行データにも業務情報が含まれる |
監査部門から「誰がいつ何を実行したか」を問われる可能性がある業務では、逆にログを消しすぎないことも必要になります。残す・隠す・消すの方針は、対象業務ごとに変わります。ひとつのルールで通そうとせず、業務単位で決めてください。
可用性——1台構成のままでは、止まったときに気づけない
3つめが可用性です。最初は1台のサーバーで十分に動きます。問題は、そのワークフローが業務に組み込まれた後です。
n8nには、処理を分散させる queue モード(キュー モード)があります。公式ドキュメントによれば、この構成には次の4つが必要です。
- メインのn8nインスタンス(タイマー、Webhook、トリガーを担当する)
- ワーカーのインスタンス(実際の処理を実行する)
- Redis(実行の待ち行列を保持するメッセージブローカー)
- PostgreSQL(ワークフローと実行結果を保存するデータベース)
また公式ドキュメントは、キュー モードをSQLiteのデータベースで動かすことは推奨されず、分散構成としてはサポートされないとしています。試用のときにSQLiteのまま始めて、後から分散構成にしようとすると、データベースの移行が必要になります。本番で使う可能性があるなら、最初からPostgreSQLで構築しておくほうが後が楽です。
なお、メインのインスタンスを複数立てるマルチメイン構成は、前述のとおりCommunity版には含まれません。冗長化を本気で考えるなら、有償プランが前提になります。
そしてもうひとつ、技術の話ではない論点があります。止まったことに誰が気づくのかです。毎朝9時のレポートが届かない日に、誰かが「今日は来ていない」と声を上げる仕組みがあるか。エラー時に通知を飛ばすワークフローを別に用意しているか。当社が開発案件で品質を仕組みで担保するのと同じ考え方で、自動化も人の注意力ではなく仕組みで守る必要があります。
導入前に決める3つを、もう一度並べておきます。暗号化キーの生成と保管場所、実行データの保持期間と秘匿範囲、そして障害に気づく手段。 この3つが決まっていれば、n8nは安心して社内に置けます。
n8nで足りる範囲と、開発が必要になる境界——当社の位置づけ

最後に、開発会社の立場から境界の話をします。先に結論を書きます。n8nのような自動化ツールで足りるなら、開発する必要はありません。 当社にご相談いただいた案件でも、内容を伺って「それはツールで足ります」とお伝えして終わることがあります。ツールで済む業務まで開発すると、初期費用も保守費も無駄になるというのが実情です。問題は、足りるかどうかをどう見分けるかです。
5つの問いで、ツールで足りるかを確かめる
次の5つに答えてみてください。
# | 問い | ツールで足りる | 開発を検討する |
|---|---|---|---|
1 | 誰が使いますか | 社内の担当者だけ | 顧客や取引先が直接触る |
2 | 画面は要りますか | 既存サービスの画面で足りる | 自社専用の画面が必要 |
3 | データはどこに置きますか | 既存のSaaSやスプレッドシートのまま | 自社でデータモデルを設計して持つ |
4 | 途中で失敗したらどうなりますか | 手作業でやり直せる | 途中で落ちたら全部戻す必要がある |
5 | 止まったら何分以内に直しますか | 翌営業日でよい | 数分以内、または24時間365日 |

右側が3つ以上当てはまったら、開発を検討する段階です。 2つ以下なら、まだツールで進めたほうが早く、安く済みます。
この表で伝えたいのは、境界がツールの性能ではなく責任の重さで決まるということです。n8nの性能が足りなくなるより先に、「これは誰かが責任を持って保守しないといけないものになった」という段階が来ます。担当者が1人で組んだワークフローに、1,000人の業務が乗っている。この状態は、ツールの限界ではなく体制の問題です。
開発が必要になったときの受け皿——ラボ型とAI活用開発体制
当社(TALENTBASE VIETNAM)が提供しているのは、ベトナム・ホーチミンを拠点とするラボ型開発です。準委任契約で専属チームを組み、月額で継続的に開発します。
自動化ツールから開発へ移る案件でよくあるのは、全部を作り直す必要がないという状況です。顧客が触る部分だけを開発し、社内向けの通知や集計はn8nのまま残す。この形なら、月額で無理なく進められます。仕様が動く前提の案件は、総額の請負より月額で考えたほうが実態に合う、というのが私の持論です。
体制と費用の目安は次の通りです。最小構成は日本人PMがフロントに立ち、エンジニア2〜3人月で月額約80万円からです。公開している単価は、実務3年目安で1,500USD(約22.5万円/1USD=150円換算目安)、5年で2,000USD、10年クラスとブリッジSEで3,000USDです。1名から始められ、最短2週間で開始、増員は約1週間が目安です。
AIを組み込む案件については、当社はAI活用開発体制を持っており、LLMを組み込んだ24時間対応のチャットボットや、決済アプリ(Stripe連携・二要素認証・ウォレット・PDF出力)の新規開発から週次保守までを手がけてきました。介護記録SaaSのCareViewerでは、日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で継続開発を担当し、週次で優先順位を判断しながら進めています。
品質は人ではなく仕組みで担保します。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点です。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。
なお、AI開発そのものを外注する際の進め方や受入基準については、当ブログの『AI開発 外注』の記事で扱っています。
当社が向かないと判断する案件
正直に書いておきます。次のご相談は、当社ではお引き受けしていません。
- n8nの設定代行だけをお願いしたい。 ワークフローを組むこと自体は代行できますが、それだけでは当社の体制を使う意味がありません。ツールに詳しい国内のフリーランスや導入支援会社のほうが、費用も速度も合います
- 1回作って終わりの単発開発で、その後の保守を想定していない。 ラボ型は継続的に手を入れる前提の契約形態です。仕様が固まった単発案件は、請負契約を扱う会社のほうが適しています
- 要件も目的もまだ何も決まっていない段階で、まず作りはじめたい。 何を解決したいのかが定まっていない状態で人を並べても、費用が出ていくだけです。この場合はまず、自動化ツールで小さく試すことをおすすめしています
ツールで足りるなら、ツールで済ませてください。それでも足りなくなったときに、選択肢のひとつとして当社を思い出していただければ十分です。
n8nに関するよくある質問

記事の内容を踏まえて、実際にご相談のなかで繰り返し出てくる質問をまとめました。料金とライセンスに関する記述は、いずれも2026年9月15日にn8n公式サイト・公式ドキュメント・公式リポジトリのライセンス表記で確認した内容です。導入前には必ず公式で最新の情報をご確認ください。
Q1. n8nの読み方は何ですか
日本語の記事や解説では「エヌエイトエヌ」と表記されるのが一般的で、社内の会議で口頭で説明する場面ではこの読み方で通じます。ただし、公式ドキュメントに名前の由来や読み方の説明は見当たりませんでした。由来については諸説あるため、本記事では断定しません。
Q2. 本当に無料で使えますか
自社のサーバーで動かすセルフホストのCommunity版は、ソフトウェアの利用料が無料です。ただし、無料なのはソフトウェアのライセンスであって、サーバー代、データベースの運用、バージョン更新、障害対応は自社の負担として残ります。また、SSO、プロジェクト、ワークフローと認証情報の共有、Gitによるバージョン管理などはCommunity版に含まれず、有償プランの対象です。クラウド版には14日間の無料トライアルがあります。
Q3. 商用利用はできますか
自社の社内業務を自動化する目的であれば、Sustainable Use License, Version 1.0 の「自分自身の内部業務目的」に当たり、営利企業が使うことも認められています。一方、n8nを自社サービスの一部として第三者に提供する、n8nをホスティングして顧客に使わせる、といった形は同ライセンスの無償の範囲を外れ、n8n社との商用契約が必要になります。「オープンソースだから自由に使える」という理解のまま進めるのは要注意です。
Q4. 日本語の情報は十分にありますか
公式ドキュメントは英語が基本で、日本語の解説は有志の記事やブログが中心です。そのため、料金・ライセンス・機能については、翻訳や要約を経由せず公式の一次情報に当たることをおすすめします。本記事も、他の解説記事ではなく公式サイトと公式ドキュメント、公式リポジトリのライセンス表記を直接確認して書いています。
Q5. n8nで組んだ自動化を、開発に置き換えるべきかどうか相談できますか
はい。現在のワークフローの内容と、利用者・画面・データ・障害時の要求水準をお聞かせいただければ、ツールのまま残す範囲と開発に移す範囲を分けてご提案します。当社の最小構成は日本人PMフロント+2〜3人月で月額約80万円から、1名・最短2週間での開始が可能です。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要。ツールで足りるご相談の場合は、その旨も率直にお伝えします。
まとめ: n8nは仕組みとライセンスを押さえてから入れる。ツールで足りるなら作らないほうがよい
n8nとは、外部のサービスやAIをノードとしてつなぎ、決めた条件で自動的に走らせるワークフロー自動化ツールです。仕組みはノード・トリガー・実行の3語で理解できます。なかでも実行の数え方——ワークフロー1回の走行を1回と数え、ステップ数もデータ量も関係ない——は、料金の考え方と他ツールとの違いに直結するので、先に押さえてください。ZapierはタスクごとにMakeはオペレーションごとに数えるため、同じ業務を組んでも費用の出方が変わります。ステップ数の多い処理を少数回まわすならn8n、つなぎたいサービスの幅を優先するならZapier。優劣ではなく、自社のワークフローの形で選ぶ話です。
ライセンスは、この記事でいちばん丁寧に書いた部分です。n8nはソースコードが公開されていますが、適用されているのは Sustainable Use License, Version 1.0 であり、一般的なオープンソースライセンスではありません。自社の社内業務で使うことは認められる一方、n8nをホスティングして第三者に提供する形は認められていません。n8n自身が使う fair-code という語は、faircode.io の記述によればソフトウェアライセンスの名前ではなく提供モデルの呼び名です。社内で説明するときは Sustainable Use License という名前を使ってください。そして、セルフホストで無料なのはソフトウェアのライセンスだけです。サーバー、バックアップ、更新、障害対応は自社の仕事として残ります。運用を始めるなら、暗号化キーの生成と保管場所、実行データの保持期間と秘匿範囲、止まったときに気づく手段の3つを先に決めてください。
そのうえで、開発会社としての立場をもう一度書きます。自動化ツールで足りるなら、作らないほうがよいです。使うのが社内の担当者だけで、既存サービスの画面で足り、データもSaaSのままでよく、失敗しても手作業でやり直せて、翌営業日に直せばよい業務。これはツールの領域です。顧客が直接触る、自社専用の画面が要る、データモデルを自社で設計する、途中で落ちたら全部戻す必要がある、数分以内に復旧しなければならない。このうち3つ以上が当てはまったときに、初めて開発を検討すれば十分です。そのときも全部を作り直す必要はありません。顧客が触る部分だけを開発し、社内の通知や集計はツールに残す形が現実的です。ノーコードという手段そのものを整理したい方はノーコードとはを、AIエージェントの開発をどこに頼むか比べたい方はAIエージェント開発会社の選び方もあわせてご覧ください。当社が提供しているのはラボ型開発(準委任)で、最小構成は日本人PMフロント+2〜3人月の月額約80万円から、1名・最短2週間で開始できます。現在の体制と要件をお聞かせいただければ、ツールのまま残す範囲と開発に移す範囲の切り分けを含めて、概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。