セルフホストしたn8nを使って、顧客のために自動化を組み、その構築と保守の料金を請求してよいのか。結論から書くと、公式のライセンスFAQはそれを明示的に認めています。認めていないのは、顧客や外部の利用者が自分でワークフローを作成・編集できる形で渡すことです。分かれ目は、お金を取るかどうかではありません。作る権限が誰の手にあるかです。
ここを取り違えやすいのは、n8nのコードがGitHubで公開されているためです。ただしリポジトリの LICENSE.md が適用しているのはSustainable Use License（以下SUL）で、使い道に条件が付いています。条文は、他者へ渡すことを「非商用の目的で、無償のときだけ」に限っています。再配布と販売を制限している以上、一般にオープンソースと呼ばれるライセンスとは条件が違います。「公開されているから自由に使える」という読み方は、この条文では通りません。
この記事では、リポジトリの条文と公式ドキュメントに書かれている範囲だけを使って、4つを順に見ます。リポジトリのどの部分にどのライセンスが当たるのか。条文が許している使い方は何か。受託や自社プロダクトへの組み込みはどちらに入るのか。そして、自分で建てても無料にならない機能はどれか。金額は公式ページの表記どおりユーロで書き、日本円へは換算していません。確認日は2026年10月7日です。
なお、この記事は条文の記載を整理したもので、個別の契約が有効かどうかという法的な判断はしていません。自社の案件がどちらに入るかを決めるときは、後述の公式の問い合わせ先か、社内の法務の確認を通す範囲になります。
GitHubに置かれていても、全部が同じ条件ではない
まず読む場所を間違えないようにします。LICENSE.md は、冒頭でリポジトリの中身を4つに分け、それぞれ別の扱いにしています。
1つ目は、master以外のブランチの内容です。条文は、これを「ライセンスされない」と書いています。開発中のブランチからコードを持ち出して使う行為は、許諾の対象にそもそも入っていません。
2つ目は、ファイル名に .ee. を含むファイル、またはディレクトリ名に .ee を含むファイルです。これらはSULの対象外で、使うにはそのファイルへのアクセスを認めるn8n Enterprise Licenseを持っている必要がある、と明記されています。有償で提供されている機能の実装が、ソースツリーの中で名前によって切り分けられている形です。
3つ目は、n8nに組み込まれた第三者のコンポーネントで、これは元の権利者が付けたライセンスに従います。そして4つ目、上の3つ以外がSULの対象です。公式ドキュメントはこのSULを「Community license」と呼び、無料であること、そしてセルフホスト版にのみ適用されることを書いています。クラウド版を契約した場合に適用されるのは、SULではなく有償プランの条件になります。
条文が許しているのは、内部業務と非商用の利用
SULの中心は「Limitations」の節です。短い条文なので、原文の文言と、そこに書かれていることを並べて見ておきます。
| 条文の文言（原文） | 書かれていること |
|---|---|
| use or modify the software only for your own internal business purposes | 自社の内部業務のためであれば、使うことも改変することもできる |
| or for non-commercial or personal use | 非商用の利用と、個人としての利用も認められる |
| distribute the software or provide it to others only if you do so free of charge for non-commercial purposes | 他者へ渡せるのは、非商用の目的で、しかも無償のときだけ |
| non-sublicensable, non-transferable（Copyright License の節） | 受け取った許諾を、他者へ再許諾したり譲り渡したりできない |
| may not alter, remove, or obscure any licensing, copyright, or other notices | ライセンス表記や著作権表記を、変える・消す・見えなくすることができない |
| Any use of the licensor’s trademarks is subject to applicable law | 商標の利用については、適用される法律に従う |
出典：n8n リポジトリの LICENSE.md（確認日 2026-10-07）
注目したいのは2点です。1つは、改変が内部業務の範囲で許されていることです。自社の都合に合わせてコードへ手を入れること自体は条文の中にあります。ただし表記の削除は禁じられ、改変したコピーを配る場合は改変した旨の目立つ通知を入れる義務（Notices の節）が付きます。
もう1つは、許諾が再許諾できず、譲渡もできないことです。つまり、自分が受け取った権利を顧客へ渡す形の契約は作れません。顧客の環境へn8nを入れる案件では、誰が許諾を受けている当事者なのかが問題になります。許諾を受けるのは、そのソフトウェアを使う側です。この構造が、次の節の線引きにそのままつながります。
線を引いているのは「顧客が作れるかどうか」
条文の「internal business purposes」という言葉だけでは、受託の仕事が入るのか判断できません。公式のライセンスFAQは、この語を自社の組織やプロダクトの中での利用で、業務の外にいる人がワークフローの産物を受け取ったり見たりする場合を含むものとして説明しています。成果物が外へ出ること自体は、範囲を外れる理由になっていません。
そのうえでFAQは、できることとできないことを例で列挙しています。
できる側には、自社の業務を回すために使うこと、個人の学習や研究に使うこと、顧客のための自動化を自分のインスタンスで作ること、構築・設定・保守の料金を顧客へ請求すること、研修とコンサルティングの料金を請求すること、自社プロダクトの裏側でn8nを使うこと、複数のインスタンスを動かすことが並んでいます。受託の仕事が丸ごと禁止されているわけではない、というのがここの要点です。
できない側に並んでいるのは、n8nをサービスとしてホスティングして顧客にワークフローを作らせること、外部の利用者に自分のワークフローを作成・設定させること、コードをフォークして自社の自動化製品を立ち上げること、ブランド表記を外してそのまま提供すること、そしてライセンスキーを求める機能をEnterpriseライセンスなしで使うことです。
受託で使うときの条件は、FAQの文言の中に書かれています。顧客のための自動化を自分のインスタンスで作ることが許されるのは、顧客がそれを作成・編集できる状態になっていない場合です。顧客に渡すのは結果であって、編集画面ではない、という形になります。顧客側の担当者にも自分で直せるようにしたい、という要望は現場でよく出ますが、それはこの線を越える変更にあたります。
作らせる経路を変えても、扱いは同じ
もう1つ、2026年の実務で効いてくる記載があります。FAQは、できない側の例として自社プロダクトのUI、API、MCP、あるいは利用者の代わりに動くAIエージェントを通じて外部の利用者にワークフローを作成・設定させる形を、まとめて挙げています。経路を差し替えても扱いは変わらない、という書き方です。
AIエージェントに「必要なワークフローを組ませる」機能を自社サービスへ載せる設計は、n8nを裏で動かす前提だと、この例に正面から当たる可能性があります。画面を見せていないから大丈夫、という読み方は通りません。
反対に、FAQが許している組み込みの形も具体的です。自社プロダクトの裏側でn8nを使い、利用者が自分で組んだのではない自動化を実行・起動し、自分のアカウントを接続することまでは、できる側に挙げられています。つまり、設計の自由度は残っています。固定された自動化を提供して利用者に走らせるのか、利用者に組ませるのか。この一点で扱いが変わります。
違反に気づいたときの30日
条文にはTerminationの節があり、違反したときに何が起きるかが書かれています。ここは、提供の形を変えるときに知っておく価値があります。
条文の構造はこうです。条文に反する使い方は、そもそも許諾されていない。そしてライセンスは自動的に終了します。licensorから違反の通知を受け取った場合は、その通知を受け取ってから30日以内にすべての違反をやめれば、ライセンスは遡って復活すると書かれています。ただし、復活したあとに再び違反すると、追加の違反によってライセンスは自動的かつ恒久的に終了します。
30日の起点は、通知を受け取った日です。社内で気づいた日ではありません。特許についても1行あり、ソフトウェアが特許を侵害していると書面で主張した場合、その時点で特許ライセンスが終了すると定められています。No Liability の節では、ソフトウェアは現状のまま提供され、保証も条件も付かないとされています。無償で動かす選択は、この保証なしを引き受ける選択でもあります。
自分で建てても、全機能が無料になるわけではない
セルフホストを「同じものを無料で手に入れる方法」と考えると、機能の側で差が出ます。公式ドキュメントはCommunity editionを「n8nのほぼ全機能」と説明したうえで、含まれないものを列挙しています。
| 区分 | 使える機能の範囲 |
|---|---|
| Community edition（無料・ライセンスキー不要） | 「ほぼ全機能」と記載。下の2区分に挙げた機能は含まれない |
| 無料のライセンスキーを登録すると使える | フォルダ、エディタ内でのデバッグ、カスタム実行データ |
| Business・Enterprise（有償のライセンスキーが必要） | カスタム変数、環境（Environments）、外部シークレット、バイナリデータの外部保存、ログストリーミング、マルチメイン構成、プロジェクト、SSO（SAML・LDAP）、ワークフローと認証情報の共有、Gitによるバージョン管理 |
出典：n8n Docs「Community edition features」（確認日 2026-10-07）
真ん中の区分が分かりにくいところです。メールアドレスを登録して無料のライセンスキーを受け取ると、3つの機能が開くという仕組みで、公式ドキュメントはこれを登録済みのCommunity editionとして別に扱っています。費用はかからない代わりに、キーの発行を受けるという手順が入ります。
下の区分は、複数人の運用に関わるものが並んでいます。SSO、プロジェクト、環境の切り替え、Gitによるバージョン管理、ワークフローと認証情報の共有です。1人で運用する間は困らないのに、チームへ広げると有償側へ移る構成になっていると読めます。なお公式ドキュメントは、プランと版ごとの正確な機能は変わりうるとして、料金ページを見るよう書いています。導入の判断に使うなら、この表ではなく当日の公式ページを見てください。
クラウド版の料金は、ステップ数ではなく実行回数で決まる
有償側の金額も見ておきます。料金ページは年払いでの月額を既定で表示しており、実行回数で段が分かれています。
| プラン | 月額（年払いでの表示） | 含まれるワークフロー実行回数 | ホスティング |
|---|---|---|---|
| Starter | 20€/mo | 2.5K | n8n Cloud |
| Pro | 50€/mo | 10K | n8n Cloud |
| Business | 667€/mo | 40K | セルフホストのみと表示 |
| Enterprise | Contact Sales | 個別に設定 | n8n Cloud またはセルフホスト |
出典：n8n「Plans and Pricing」（確認日 2026-10-07）。Kは千を表す公式ページ側の表記です
数え方が、この料金の読み方を決めます。公式のFAQは「1回の実行とは、ワークフロー全体を1回走らせることである。ワークフローに含まれるステップの数や、処理するデータの量は関係しない」と書いています。どの段でもステップ数は無制限とされているため、1本のワークフローを細かく分けて作っても、消費する回数は変わりません。処理1件ごとに課金される形式のツールと比べると、設計の自由度が違ってきます。
一方で、この数え方はこまめに起動する設計に弱いという面も持ちます。5分ごとに様子を見るだけのワークフローでも、1日あたりの起動回数は三桁になります。重い処理を1本にまとめた設計と、軽い確認を頻繁に走らせる設計では、同じ段でも足りるかどうかが変わります。月払いでの金額と、超過したときの扱いは、この記事では参照していません。
ホスティングの欄も見落としやすいところです。参照した時点の表示では、Businessの段はセルフホストのみとなっており、クラウドで使える段はStarterとPro、それにEnterpriseです。セルフホストが前提の段があるため、「有償プランならクラウドで動く」とは限りません。
契約の相手はベルリンのn8n GmbH
最後に、確認の宛先を押さえておきます。公式の事業者表記によれば、運営しているのはn8n GmbHで、所在地はNovalisstr. 10, 10115, Berlin, Germany、代表はJan Oberhauser、商業登記はシャルロッテンブルク区裁判所のHRB 212509 Bです。条文の相手方はドイツの会社で、日本法人ではありません。
問い合わせ先は2つ用意されています。ライセンスについての質問は license@n8n.io、Community licenseの範囲を超える使い方について商用ライセンスを相談する場合は sales@n8n.io です。自社の案件がどちらに入るか微妙なときは、設計を固める前に聞いた方が安いという作りになっています。提供の形を変えるのは、顧客へ引き渡したあとでは難しい部分です。
参照した範囲で確認できなかったことも残します。条文の日本語版は見つかりませんでした。準拠法と裁判管轄についても、今回参照した条文とドキュメントには記載がありません。セルフホストでの利用に対するサポートの範囲、過去バージョンの条文との差分も、この記事では扱っていません。記載がないというのは、定めが存在しないという意味ではなく、参照したページに書かれていなかったという意味です。
公開されたコードで売上を守るライセンス設計そのものは、海外のソフトウェア企業が揃って作り直してきた領域です。設計する側の視点は非競合ライセンスの設計に、AGPLv3で公開しているサービスを使う側から見た例はPlausible Analyticsの料金と自前運用にまとめています。ツール選びの前段にある業務の切り分けはAIによる業務自動化、海外のサービスと事業の動きは海外ビジネスにあります。
どこで線を引くかを、作り始める前に決める
n8nのライセンスを読むときに決める必要があるのは、次の3つです。
1つ目、外部の利用者に作成・編集をさせるか。させないなら、受託でも自社プロダクトへの組み込みでもSULの範囲に入り、構築と保守の料金を請求できます。させるなら、UIでもAPIでもMCPでもAIエージェント経由でも同じ扱いで、商用ライセンスの相談になります。
2つ目、有償のライセンスキーを求める機能を使うか。SSO、プロジェクト、環境、Gitによるバージョン管理などは、自分のサーバーで動かしていても無料では使えません。チームの人数が増えてから気づくと、移行の手間が乗ります。
3つ目、クラウドで動かすか自分で建てるか。自分で建てる側を選ぶなら、適用されるのはSULで、保証もサポートも条文の上では付きません。クラウドを選ぶなら適用されるのは有償プランの条件で、料金は実行回数で決まります。
この3つは、どれも作り始めたあとでは変えにくい部分です。無料という言葉だけで決めると、提供の形を変える段で詰まります。先に条文を読んで線を引いておけば、あとは設計の話になります。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。
あわせて読みたい
ソースコードを公開したまま収益を守る｜非競合ライセンスの設計 ソースコードを公開したまま売上を守るために、海外のソフトウェア企業がライセンスを設計し直しています。HashiCorp・Elastic・Redis・Sentryの公式発表と実際の条文から、非競合条項と期限つき公開の仕組みを整理します。
Plausible Analyticsとは｜料金と自前運用の条件を公式情報で整理 EU拠点の独立系アクセス解析Plausible Analyticsを公式サイトの記載だけで整理します。月間ページビューで決まる料金、取得する項目と取得しない項目、自分のサーバーで動かすときに外れる機能、日本から使う前に自社で確かめる点まで。
Cloudflare Turnstileとは｜無料プランの上限と導入に要るもの 問い合わせフォームのbot対策に使えるCloudflare Turnstileを、公式ドキュメントの記載だけで整理します。無料プランの上限、必ず要るサーバー側の検証、トークンの有効期間、3つの表示モード、日本の会社が導入前に決める項目まで。