n8nを商用・業務利用するときに確認したい条件

n8nは会社の業務自動化や受託開発でも使えます。

ただし、Self-hosted Community Editionを使えば「どんな商用サービスにも自由に組み込める」という意味ではありません。

2026年10月7日に確認したn8nのCommunity editionはSustainable Use License（SUL）で提供されており、社内利用、consulting、client支援、hosting、white-label提供では必要なlicenseが変わります。

自社の内部業務なら使いやすい

Sustainable Use Licenseは、n8nを自社のinternal business purposesで利用することを主な許可範囲としています。

たとえば、

社内の問い合わせ処理

営業dataの同期

請求・通知automation

marketing workflow

AI agentの社内運用

のように、自社業務を効率化する目的でSelf-hosted n8nを使うケースは基本的な利用形態です。

client向けworkflowを作るconsultingは可能

n8nは、client自身のinstanceに対してworkflow構築やsupportを提供するconsultingについて、別のcommercial licenseを必須とはしていません。

つまり、clientが自分のn8n環境を持ち、そこへworkflowを実装する受託支援は可能です。

料金を受け取ってworkflowを設計・構築すること自体が禁止されているわけではありません。

自社instanceでclientのworkflowをhostする場合は別

注意したいのは、clientごとのworkflowやcredentialsを自社のn8n instanceでhost・管理する場合です。

n8n公式FAQは、顧客がworkflow editorやlogicへアクセスせず、結果を受け取る構成と、顧客が外部からworkflowを作成・設定できる構成を分けています。前者はCommunity editionのSULで許容される場合がありますが、後者やn8nをserviceとしてhostingする形はcommercial licenseを確認します。

「clientのためにworkflowを作る」と「clientのworkflow実行基盤そのものを自社で提供する」はlicense上別の扱いです。

n8nをproductへ組み込む場合

SaaSや自社productの中へn8nをembedし、end userがそのautomation機能を利用できるようにする場合は、通常のCommunity利用とは別に考える必要があります。

顧客が独自interface、API、MCP、AI agent等を通じてworkflowを作成・設定できる形はcommercial licenseの確認対象です。名称や条件は契約で変わり得るため、実装内容を説明してn8nへ確認します。

automation SaaSを作る場合は、開発前にlicense確認を入れた方が安全です。

Cloudも「第三者へ再販売する権利」ではない

n8n CloudのSelf-Serve Termsでは、Cloud Servicesはinternal business purposes向けで、第三者へtransfer、sell、distribute、lease、licenseすることを制限しています。

有料planを契約しているから、そのままn8n accessをclientへ再販売できるわけではありません。

service提供形態まで含めてlicenseを確認する必要があります。

workflow内で使う第三者serviceにも別条件がある

n8nは多くのAPIやSaaSを接続できます。

ただしOpenAI、Google、Slack、Stripeなど接続先serviceには、それぞれ利用規約、rate limit、data policyがあります。

n8nの利用条件を満たしていても、接続先APIのcommercial useやdata handling条件を満たしているとは限りません。

AI機能ではAUPも確認する

2026年のn8n Customer Acceptable Use PolicyはCloudとSelf-hosted双方へ適用される項目があります。

security abuse、credential exfiltration、unauthorized accessなどは禁止されています。

またn8n CloudのAI機能ではAI subprocessorsのpolicyも関係し、生成outputをproductionで使う前にreviewする責任が利用者側にあります。

client workでは契約条件も確認する

受託案件ではn8n側のlicenseだけでなく、

client dataを外部serviceへ送ってよいか

API credentialを誰が管理するか

workflowのownerは誰か

障害時の責任範囲

AI利用制限

個人情報・機密情報

も確認する必要があります。

特に自社n8nへ複数clientのcredentialを集約する設計は、licenseとsecurityの両面で慎重に判断すべきです。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  n8n

  公式サイトを見るTool詳細を見る

事業形態を先に分ける判断表

「商用かどうか」だけではlicense判断はできません。n8n instanceを誰が運営し、workflowの作成・編集権を誰が持ち、顧客へ何を提供するかが確認の起点です。現行n8n Help Centerは、Community editionのSustainable Use Licenseについて、組織内でworkflowを作成・編集する利用と、顧客向けに構築して自社instance上で実行するconsultingを区別しています。顧客がeditorやworkflow logicへアクセスする形、hostingやwhite-label提供、顧客自身がautomationを構成できる製品は、commercial licenseの確認が必要になる場合があります。個別契約の判断は記事だけで確定できません。

表は横にスクロールできます

ケース	誰が編集するか	instanceの運営者	次の確認
社内の申請処理	自社チーム	自社	internal business useとedition条件
顧客業務の受託構築	自社担当	自社または顧客	顧客がeditorを使うか、credentialを誰が管理するか
顧客serverへの導入支援	顧客	顧客	顧客が契約主体となるplan・license
顧客へworkflow editorを提供	顧客も編集	自社service	commercial / enterprise窓口へ確認
n8nをwhite-label化	提供者側	自社service	提供前にlicense範囲を書面で確認

「顧客に結果だけ渡す」形と「顧客が設定を変えられる」形では、同じworkflowでも提供内容が違います。顧客が自分のaccountを接続する場合も、n8nへloginするのか、外部formを通じてcredentialを預けるのかで、権限と責任が変わります。

相談前に一枚で説明する

license窓口へ「受託で使えますか」とだけ質問すると、回答が一般論になりやすくなります。次の項目を具体化します。

1. n8n CloudかSelf-hosted Communityか、有料Self-hosted planか。

2. 契約者、instance owner、server operatorは誰か。

3. workflowを作成・編集する人と、実行結果だけを受け取る人は誰か。

4. 顧客がeditor、API、MCP、独自interfaceからlogicを変更できるか。

5. 顧客のOAuth tokenやAPI credentialをどこへ保存し、誰が閲覧できるか。

6. n8nを再販、white-label、host提供するか。

7. 顧客ごとのinstance分離、data削除、契約終了時の引継ぎをどうするか。

実際の画面案やdata flowを添え、未確定点は未決と明記します。境界に近い形なら、実装前にn8nへ書面確認し、その回答を契約と社内判断に保管します。個別回答がない状態で「一般に許可」と販売資料へ書かないでください。

顧客dataとlicenseを分けて確認する

license条件を満たしても、顧客情報の保護や委託契約は別に確認します。接続serviceの権限を最小化し、credentialを顧客間で使い回さないこと、execution logに本文やsecretを残す範囲、異動時のaccess取消し、契約終了後のcredential削除を決めます。CloudとSelf-hostedの責任者の違いも別表にします。

受注前のstop gate

提案書を出す前に、(a) workflow編集主体、(b) instance運営主体、(c) 顧客へ渡す機能、(d) credential保管先、(e) license回答の有無を記録します。顧客がautomationを作る製品、API等でworkflowを設定させる機能、複数顧客環境を自社運用するserviceは、見た目だけでは可否が決まりません。構成図と利用規約案を添え、確認が取れるまで提供範囲を確約しないのが安全です。

AIものさしの判断

自社業務automationや、client自身のinstanceへworkflowを構築するconsultingならn8nは使いやすい選択肢です。

一方、

client workflowを自社instanceでhostする

n8nをSaaSへ組み込む

n8n自体へのaccessを有料提供する

場合は、通常のCommunity / Self-Serve利用と同じ扱いではありません。

商用利用では「仕事で使うか」より、「誰のinstanceで、誰のworkflowとcredentialsを管理し、誰に機能を提供するか」でlicenseを判断するのが重要です。