公開2025.05.28更新2026.10.12 自動化

n8nとは？読み方・料金・セルフホストの始め方とWebhook実装を解説【2026年10月版】

n8n（エヌエイトエヌ）は、アプリやAPIをノーコード／ローコードでつないで業務を自動化できる、fair-code（ソース公開型）のワークフロー自動化ツールです。公式サイトは n8n.io で、ZapierやMakeと同じく複数サービスを連携できます。最大の違いは自分のサーバーで無料・実行回数の上限なしに動かせる点にあります。この記事では、n8nの読み方や名前の由来、できること、料金とライセンス（商用利用の可否）、npxとDocker Composeでの始め方、Webhookを外部から呼び出す実装例、他ツールとの違いまでを、2026年10月時点の公式情報で整理しました。

まとめ：n8nは自社サーバーで動かせるfair-codeのワークフロー自動化ツール

結論を先にお伝えすると、n8nは「自社の環境で動かせる自動化ツール」です。判断に必要な要点を並べます。

料金：セルフホスト版（Community Edition）は無料。公式クラウドのn8n Cloudは年払い換算で月20ユーロのStarterからで、実行数ベースの課金になる（2026年10月時点）。
商用利用：自社の業務を自動化する用途なら可能。n8nそのものを顧客向けサービスとして有償提供する用途はライセンス上認められない。
連携と拡張：400以上の連携ノードに加え、JavaScript／Pythonを書けるCodeノード、LLMを呼び出すAI Agentノードを標準で備える。
始め方：お試しは npx n8n、継続運用は公式が推奨するDocker Compose。版は2.42系が安定版（2026年10月時点）。
向く組織：データを外部に預けたくない、タスク課金のコストが読みにくい、コードやAIで作り込みたい。運用担当を置けない場合はCloudから始める。

まずは手元で小さく試し、Webhookやスケジュールで1本動かしてから運用形態を決める流れが安全です。以下で、読み方から実装、運用で詰まる点までを順に解説します。

n8nとは｜読み方・名前の由来・開発元とn8n.io公式サイトの見方

n8nは「nodemation（node＝ノード＋ automation＝自動化）」を語源とし、読み方は「n-eight-n（エヌエイトエヌ）」です。先頭の n と末尾の n の間に8文字あることが名前の由来とされています。処理の最小単位である「ノード」を線でつないでワークフローを組み立てることから、この名前が付けられました。

仕組みはシンプルで、「トリガー（きっかけ）、各種ノード（処理）、アクション（結果）」という流れをGUI上で組み立てます。たとえば「フォーム送信を受け取る、内容を整形する、Slackに通知する」といった一連の処理を、コードをほとんど書かずに視覚的に作成できます。

開発元はドイツ・ベルリンに拠点を置くn8n GmbHで、創業者Jan Oberhauser氏が2019年に公開しました。ソースコードはGitHubのn8n-io/n8nリポジトリで公開され、リリースもここで追えます。2026年10月9日時点の安定版は[email protected]、ベータ版は[email protected]でした。更新の頻度は高く、数日おきにパッチ版が出ます。

「n8n.io」で検索した人が迷いやすいのが、公式サイト上の入口の違いです。n8n.io は製品サイトで、料金ページ・テンプレート・ドキュメント（docs.n8n.io）への入口がまとまっています。「Get started」から進むとn8n Cloud（公式がホストする有料版）の登録になり、自社サーバーで動かすセルフホスト版はドキュメントのインストール手順から入ります。同じn8nでも、どちらの入口から入ったかで課金と運用責任の持ち方が異なる仕組みです。

n8nでできること｜400超の連携ノード・Codeノード・AI Agentの3本柱

n8nの中心は、複数サービスをまたいだ業務の自動化です。公式で400種類以上のアプリ連携（ノード）が用意され、Slack・Gmail・Googleスプレッドシート・各種データベース・Webhook・HTTPリクエストなどを組み合わせて定型作業を回します。トリガーにはWebhook（外部からの通知）やスケジュール（定期実行）があり、人手を介さずに処理を開始できます。

標準ノードで足りない処理は、CodeノードにJavaScriptかPythonを書いて拡張します。公式ドキュメントによれば、2.0系でPyodide版のPythonは廃止され、ネイティブPythonが安定版になりました。実行モードは「全アイテムで1回」と「アイテムごと」の2種類で、ノーコードで始めて必要な箇所だけコードで作り込む使い分けができます。エンジニアに支持される理由はここにあります。

もう1つの柱がAI連携です。n8nはAI AgentノードをはじめとするLangChain系ノードを標準搭載しており、ChatGPT・Claude・Geminiなどの大規模言語モデル（LLM）にメモリ・ツール・ベクトル検索を組み合わせたワークフローを画面上で構築できます。問い合わせの自動要約、社内ナレッジを参照するチャットボット（RAG）、調査や下書き生成を任せるエージェントが代表的な用途です。AIエージェントの考え方そのものはAIエージェントとは何かを生成AIとの違いから整理した記事で、n8n上で複数モデルを切り替えて使う機能はn8n Chat Hubの使い方を解説した記事で掘り下げています。

n8nの基本構造｜トリガー・ノード・アクションでワークフローを組む

n8nのワークフローは、大きく3つの要素で組み立てます。仕組みを押さえると、自分の業務にどう当てはめるかがイメージしやすくなります。

トリガー：ワークフローの起点。Webフォーム送信、スケジュール（定期実行）、Webhook（外部からの通知）、ファイル追加などをきっかけに処理を開始します。
ノード：処理の最小単位。各サービスの操作（データ取得・更新・送信）に加え、条件分岐・ループ・データ整形、コード実行、AI呼び出しなどを担います。
アクション：ノードが実行する具体的な操作。Slackへの投稿、スプレッドシートへの書き込み、メール送信などが該当します。各サービスの認証情報は一度登録すれば使い回せます。

これらをキャンバス上にドラッグ＆ドロップし、線でつないでデータの流れを定義します。ノード間を流れるデータは「アイテム」の配列で、各アイテムは json というキーの下に値を持ちます。この形を知っておくと、後述するCodeノードの書き方で迷いません。各ノードの実行結果は個別に確認できるため、どこで止まったか・どんなデータが流れたかを見ながらデバッグできます。

n8nの主なユースケース｜通知・データ連携・問い合わせ一次対応・RAG

抽象的な説明よりも、具体的な使いどころを見るとイメージしやすくなります。n8nは「定期実行」と「イベント起点」の両方に対応するため、次のような自動化を1つのツールで完結できます。

通知の自動化：フォーム送信やシステムのエラー検知をトリガーに、内容を整形してSlackやメールへ即時通知する。
データ連携・レポート作成：複数サービスのデータを定期取得し、Googleスプレッドシートやデータベースへ集約。週次レポートの自動生成まで一気通貫で行う。
問い合わせの一次対応：受信メールやフォームの内容をAIノードで分類・要約し、担当チャンネルへ自動で振り分ける。
社内ナレッジ検索（RAG）：社内ドキュメントをベクトル化して取り込み、AI Agentが出典付きで回答する社内チャットボットを構築する。
定期バッチ処理：スケジュールトリガーで、在庫同期・データバックアップ・外部APIとの同期などを無人で実行する。

いずれも、複数のサービスを横断する「つなぎ込み」を人手でやっていた部分を置き換えるイメージです。この領域はiPaaS（クラウド型の連携基盤）と重なっており、RPAとの違いや料金の数え方はiPaaSの仕組みとRPAとの違いを解説した記事で比較しています。まずは効果が見えやすい通知やデータ転記から始め、慣れてきたらAI連携や複雑な分岐へ広げると無理なく定着します。

n8nの料金とライセンス｜Cloud4プランと商用利用できる範囲の線引き

料金は大きく2系統です。セルフホスト版（Community Edition）は無料で、実行回数の上限がなく、連携ノードも使えます。一方のn8n Cloudはサーバー管理が不要な代わりに利用料がかかります。公式料金ページで2026年10月時点に確認できたプランは次のとおりです（年払い時の月額表示）。

プラン	月額目安（年払い）	月間実行数	提供形態
Starter	20ユーロ	2,500回	Cloud
Pro	50ユーロ	10,000回	Cloud
Business	667ユーロ	40,000回	セルフホストのみ
Enterprise	要問い合わせ	個別設定	Cloud／セルフホスト

Cloudの料金は「実行数ベース」です。たとえば15ステップのワークフローでも1回の実行として数えられ、ステップ数では課金されません。ZapierやMakeの「タスク／オペレーション課金」と比べてコストが読みやすいのが特徴です。Zapier側のタスクの数え方はZapierの料金とタスク課金の仕組みを整理した記事で確認できます。金額やプラン構成は改定されることがあるため、契約前には料金ページで最新の表示を確かめてください。

ライセンスは、よく誤解されますがOSI準拠のオープンソースではなく、fair-codeの「Sustainable Use License」です（2022年3月にApache 2.0＋Commons Clauseから移行）。リポジトリのLICENSE.mdは、利用と改変を「自社の内部業務目的、または非商用・個人利用」に限り、第三者への配布や提供は「非商用目的で無償の場合」に限ると定めています。また、ファイル名やディレクトリ名に「.ee」を含むソースはこのライセンスの対象外で、有効なEnterprise Licenseが必要です。

「商用利用できるか」への答えは、社内の業務効率化が目的なら可能です。自社の業務をn8nで自動化して大きな利益を上げても問題ありません。一方で、n8nを顧客向けのサービス（SaaS）として再販・提供する用途は許可されていません。顧客ごとにn8nを立てて操作画面を渡す形や、n8nを組み込んだ有償サービスは、Enterprise契約か個別の確認が前提になります。

無料版でも使えない機能がある点も押さえておきます。公式のエディション比較によると、Community Editionではプロジェクト、ワークフローと認証情報の共有、SSO（SAML・LDAP）、Gitによるバージョン管理、外部シークレット、ログストリーミング、環境（Environments）が対象外です。メール登録だけで使える「Registered Community」にすると、フォルダ・エディタ内デバッグ・カスタム実行データが追加されます。複数部署で権限を分けて使うなら、Business以上を前提に予算を組むのが現実的な線です。

n8nの始め方｜npxで試してDocker Composeでセルフホストする手順

ここからは実際に動かす手順です。目的に応じて3つの入り方があります。

npxで最短起動する手順と対応するNode.jsのバージョン範囲

試すだけなら、Node.js環境があれば npx で即起動できます。npmでの導入手順によると、対応するNode.jsは20.19以上24.x以下です（2026年10月時点）。範囲外の版では起動時にエラーになるため、先に node -v で確かめておきます。

node -v
npx n8n

起動後はブラウザで http://localhost:5678 を開くと、オーナーアカウントの作成画面に入れます。なお、同ページにはnpmでの導入が3.0系で非推奨になる旨の注記があるため、継続して使う環境はDockerで組むほうが無難です。

Docker単体でn8nを起動しデータをボリュームに永続化する手順

設定やワークフローを残しながら使うならDockerが定番です。データ用のボリュームを作ってから公式イメージを起動します。タイムゾーンを指定しないとスケジュールトリガーが想定と9時間ずれるので、日本で使う場合は Asia/Tokyo を入れておきます。

docker volume create n8n_data

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -e GENERIC_TIMEZONE="Asia/Tokyo" \
  -e TZ="Asia/Tokyo" \
  -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
  -v n8n_data:/home/node/.n8n \
  n8nio/n8n

GENERIC_TIMEZONE はスケジュール系ノードの基準時刻、TZ はコンテナ自体の時刻に効きます。両方そろえておくと、ログと実行時刻の食い違いを防げます。

Docker Composeで本番寄りに構成するときの設定ファイル例

公式が推奨するのはDocker Composeによる導入です。2026年10月時点の公式構成は、n8n Assistant向けのサンドボックスや検索用コンテナまで含む大きめのものになっています。まず業務フローだけ動かしたい場合は、n8n本体とPostgreSQLの2サービスから始め、必要に応じて公式構成へ寄せると理解しやすくなります。次は、公式ドキュメントに載っている環境変数名を使った最小構成の例です。

services:
  postgres:
    image: postgres:18
    restart: always
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: n8n
    volumes:
      - db-storage:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n -d n8n"]
      interval: 5s
      retries: 10

  n8n:
    image: n8nio/n8n
    restart: always
    ports:
      - "5678:5678"
    environment:
      GENERIC_TIMEZONE: Asia/Tokyo
      TZ: Asia/Tokyo
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: "5432"
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change-me
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  db-storage:
  n8n_data:

保存したら docker compose up -d で起動し、docker compose ps で両方のコンテナが動いているかを確かめます。パスワードは例のままにせず、本番では .env に逃がしてください。用途別の構成例は公式のn8n-hostingリポジトリにもまとまっています。

サーバーの構築・保守を避けたい場合は、申し込めばすぐ使えるn8n Cloudが手軽です。ローカルやCloudで小さく試し、本格運用の段階でセルフホストへ移る、という進め方が現実的です。

Webhookで外部からワークフローを起動する実装例とテストURLの違い

n8nを業務システムとつなぐとき、最初に使うことが多いのがWebhookノードです。フォームや社内システムからHTTPリクエストを受け取り、ワークフローを起動します。Webhookの仕組み自体はWebhookの仕組みとAPIとの違いを実際のリクエストで解説した記事にまとめているので、ここではn8n側の設定に絞ります。

Webhookノードを設定してcurlでPOSTを送り動作を確かめる

Webhookノードの公式ドキュメントによると、URLにはテスト用と本番用の2種類があります。テスト用URLはエディタで「Listen for Test Event」を押している間だけ受け付け、受け取ったデータが画面に表示されます。本番用URLはワークフローを公開（Publish）した時点で登録され、結果はExecutionsタブで確認する仕組みです。パスの既定値は、環境変数の一覧でテスト用が webhook-test、本番用が webhook と定められています。

WebhookノードのHTTP MethodをPOST、Pathを contact にしてテスト待ち受けを開始し、別のターミナルから次を送ります。

curl -X POST "http://localhost:5678/webhook-test/contact" \
  -H "Content-Type: application/json" \
  -d '{"name":" 山田 太郎 ","email":"[email protected]"}'

エディタ側に受信データが出れば成功です。本番に切り替えるときは、URLの webhook-test を webhook に変え、ワークフローを公開します。受け付けるメソッドはGET・POST・PUT・PATCH・DELETE・HEADの6種類で、認証はBasic・Header・JWTから選べます。外部に公開するURLには、少なくともHeader認証を付けておくと安心です。ペイロードの上限は既定で16MiBで、セルフホストなら N8N_PAYLOAD_SIZE_MAX で引き上げられます。

Codeノードで受け取ったJSONを整形して後続のノードへ渡す

Webhookノードの出力では、リクエスト本文が json.body の下に入ります。Codeノードを「Run Once for All Items」で置き、次のJavaScriptで前後の空白除去やメールアドレスの小文字化をしておくと、後続のSlack通知やスプレッドシート書き込みが安定します。

const results = [];

for (const item of $input.all()) {
  const body = item.json.body || {};
  results.push({
    json: {
      name: String(body.name || '').trim(),
      email: String(body.email || '').trim().toLowerCase(),
      receivedAt: new Date().toISOString(),
    },
  });
}

return results;

戻り値は「json キーを持つオブジェクトの配列」にするのが決まりで、この形を崩すと次のノードでデータが空になります。署名検証や再送への備えまで含めた受信側の設計は、受信側の署名検証と冪等性をNode.jsで実装した記事が参考になります。

Zapier・Make・Power Automateとの違い｜課金単位と提供形態で比べる

同種のノーコード自動化ツールとの違いを、ホスティング形態・料金の考え方・拡張性の観点で整理すると次のようになります（連携数は各社公式の表記・時期により変動します）。

ツール	提供形態	料金の考え方	連携数	向くケース
n8n	セルフホスト＋Cloud	セルフホスト無料／Cloudは実行数	400以上	自社管理・拡張・AI
Zapier	SaaS	タスク数で課金	数千以上	手軽に始めたい
Make	SaaS	オペレーション数で課金	1,000以上	視覚的な複雑フロー
Power Automate	SaaS	ユーザー／フロー単位	1,000以上	Microsoft 365中心

大づかみには、手軽さならZapier、Microsoft環境ならPower Automate、自社でデータを持ちコードやAIで作り込むならn8n、と整理できます。ZapierとMakeの課金単位の差はZapierとMakeの違いを課金単位から比べた記事、Power Automateの基本と料金はPower Automateの概要と導入判断の記事で詳しく扱っています。

コストの差が出やすいのは、1回の処理で多くのステップを通る場合です。たとえば10ステップのフローを月3,000回回すと、アクションごとに数える課金体系では2万〜3万単位近くを消費しますが、n8n Cloudでは3,000回の実行として数えます。逆に、数ステップの単純な転記を少量回すだけなら、管理の手間がないSaaSのほうが総額で安く収まることもあります。

n8nのメリット・デメリットと採用を見送るべきケースの判断基準

導入を検討する際の判断材料として、長所と短所を整理します。

主なメリット

セルフホスト版は無料で実行回数の上限がなく、利用規模が大きくなっても費用が膨らみにくい。
データを自社環境で管理できるため、プライバシー要件や社内規程に合わせやすい。
ノーコードで始めつつ、CodeノードやAI Agentノードでコード・AIまで拡張できる。

主なデメリット・注意点

セルフホストはサーバー構築・定期アップデート・バックアップ・HTTPS化など運用の手間が発生する。
純粋なOSSではなくfair-codeのため、再販（SaaS提供）など一部の用途はライセンス上認められない。
無料版では共有・SSO・Git連携が使えず、複数部署での権限分離には有償プランが要る。
最新の機能情報や高度な設定は、英語の公式ドキュメントが中心になる。

判断の目安は次のとおりです。データを社外に出せない、またはステップ数の多いフローを大量に回すなら、セルフホストのn8nを第一候補にしてよいでしょう。運用担当を置けず、連携先が一般的なSaaSだけなら、n8n CloudかZapierで十分に対応可能です。自動化を顧客向けサービスとして売りたい場合は、ライセンス上そのままでは採用できないので見送るか、Enterprise契約を前提に検討します。Difyなど別系統のツールと迷う場合は、Difyワークフローの作り方を実装手順で解説した記事と見比べると、業務連携とAIアプリ開発のどちらが主目的かを切り分けられます。

セルフホスト運用で詰まりやすい点｜更新・バックアップ・HTTPSと権限

セルフホストで止まりやすいのは、構築よりも運用の段階です。事前に決めておきたい項目を挙げます。

更新の頻度：リリースは数日おきに出る。安定版のタグを追い、検証環境で動作を確かめてから本番を上げる手順を決めておく。
バックアップ：ワークフローと認証情報はデータベースと .n8n ディレクトリに入る。ボリュームとDBの両方を定期的に退避する。
HTTPSと外部公開URL：リバースプロキシの裏に置く場合は N8N_WEBHOOK_URL を設定しないと、画面に表示されるWebhook URLが内部アドレスのままになる。旧名の WEBHOOK_URL は2.35.0から非推奨扱いとされている。
認証情報の管理：Community Editionでは外部シークレット連携が使えない。APIキーを扱うフローが増えたら、管理方法を早めに決める。

社内に運用を担う人がいない場合や、既存システムとのAPI連携の設計から相談したい場合は、外部の支援を使う選択肢もあります。一創では、n8nを含む連携ツールの選定から設計・構築までをiPaaS導入支援サービスとして提供しています。