n8n 入門と実践

n8n（エヌエイトエヌ）は、ワークフロー自動化のツールです。「Webhook を受けたら」「毎朝9時に」といったきっかけ（トリガー）から始めて、API を呼ぶ、データを変換する、条件で分ける、チャットに送る、といった部品（ノード）を画面上で線でつなぎ、一連の処理を自動で動かします。

名前は「nodemation」（node ＋ automation）を縮めたもので、n と n のあいだに8文字あることから n8n。同じ種類のツールには Zapier や Make がありますが、n8n には次のような特徴があります。

• 自分のサーバーで動かせる（セルフホスト） ── Docker で起動でき、データを社外に出さずに済む。クラウド版もある
• コードも書ける ── 画面でつなぐだけでなく、JavaScript や Python のコードを1ノードとして混ぜられる。開発者が使いやすい
• 連携先が多い ── Slack、GitHub、GitLab、Jira、Google Sheets、PostgreSQL などのノードが標準で入っている。公式サイトの連携先一覧は2,000件を超える
• AI を組み込みやすい ── LLM を使う AI Agent ノードや、MCP（AI と外部ツールをつなぐ仕組み）にも対応

n8n は、ベルリンの開発者ヤン・オーバーハウザー（Jan Oberhauser）が2019年に始めたプロジェクトです。個人の道具から、AI 時代の自動化基盤へと大きく育ちました。

2.0 では、安全側に倒す変更が多く入りました。Code ノードの実行を別のプロセス（タスクランナー）に分ける、サーバーのコマンドを実行する Execute Command ノードを既定で無効にする、などです。また、ワークフローを保存しただけでは本番に反映されず、「Publish」して初めて切り替わるようになりました。直しかけの状態が本番で動いてしまう事故を防ぐためです。

n8n のワークフローは、トリガー1つと、それにつながるノードでできています。ノードの間を流れるのは、JSON のアイテムの配列です。

処理の途中で失敗したときは、ノードごとに「止める」「エラーを次のノードに流して続ける」を選べます。ワークフロー全体の失敗は、別に用意したエラー用のワークフロー（Error Trigger）で拾って通知できます。

クラウドか、セルフホストか

手元で試すだけなら、Docker で次のように起動し、ブラウザで http://localhost:5678 を開きます（公式の手順）。最初に管理者のアカウントを作れば使い始められます。

# データ（ワークフローや暗号化キー）を残すボリュームを作って起動
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:2.42.6

本番で使うなら、保存先を SQLite（標準）から PostgreSQL に変え、版を固定し（latest ではなく 2.42.6 のように）、暗号化キー（N8N_ENCRYPTION_KEY）をバックアップしておきましょう。Docker の使い方は開発ガイド No.5で紹介しています。

セルフホスト版のエディション

ライセンス（Sustainable Use License）で注意すること

n8n は「ソースは公開されているが、いわゆるオープンソースとは違う」ライセンスです。公式の FAQ の要点は次のとおりです。受託開発の会社は特に、顧客に渡すときの形を先に確認しておきましょう。

判断の軸は「だれがワークフローの中身を決められるか」です。迷うケースは n8n 社（[email protected]）に確認するよう公式も案内しています。この記事は法的な助言ではありません。

• 向いている ── API や DB で届く処理、イベントで動く処理、手順がはっきりした繰り返しの作業、エンジニアが近くにいるチーム
• 向いていない ── 画面しかないシステムの操作（RPA の領分）、ミリ秒単位の速さが要る処理や大量データの一括処理（専用のバッチやストリーム処理のほうがよい）、厳密なトランザクションが要る業務ロジックそのもの（アプリ側に書く）

ここからは、Web システム開発の現場の例を一つ、実際に作って動かします。題材は開発ガイド No.5で使った顧客管理システム（Spring Boot ＋ Vue ＋ PostgreSQL）です。

よくある悩み

検証環境に新しい版をデプロイするたびに、担当者が確認表（Excel）を見ながら画面と API を手で確かめ、スクリーンショットを貼り、結果をチャットに書き、問題があれば課題を起票する ── という作業をしていないでしょうか。1回は短くても、デプロイのたびに発生し、見落としや記録漏れも起きます。

n8n で作る流れ

1. CI（GitLab CI や GitHub Actions）が、検証環境へのデプロイのあとに n8n の Webhook を呼ぶ
2. n8n がテストケース（URL・期待するステータス・含まれるべき文字列）を読み、画面と API を順に呼んで判定する
3. DB にも読み取り専用のユーザーでつなぎ、マイグレーションの失敗がないか、マスタにデータがあるかを確かめる
4. 結果をまとめてチャットに流し、不合格なら課題を自動で起票する
5. CI には合否を HTTP のステータス（200／422）で返し、不合格ならパイプラインを止める

① テストケースをデータテーブルに置く

② CI から Webhook を呼ぶ

Webhook ノードは、ヘッダーのトークンで認証する設定にし、「応答は Respond to Webhook ノードで返す」を選びます。CI 側は、たとえば GitLab CI ならこう書けます（例）。

# .gitlab-ci.yml（抜粋）
acceptance:
  stage: verify
  needs: [deploy_staging]
  script:
    - >
      curl --fail-with-body -sS -X POST "$N8N_URL/webhook/acceptance"
      -H "X-Api-Key: $N8N_TOKEN" -H "Content-Type: application/json"
      -d "{\"env\":\"staging\",\"version\":\"$CI_COMMIT_TAG\",
           \"commit\":\"$CI_COMMIT_SHORT_SHA\",\"pipeline\":\"$CI_PIPELINE_URL\"}"

③ HTTP Request ノードで呼ぶ

• Method は {{ $json.method }}、URL は {{ $json.url }} と、テストケースの値を式で入れる。4件のアイテムが入るので、4回呼ばれる
• Options の Include Response Headers and Status と Never Error をオンにする。404 や 500 でも止まらず、ステータスを次のノードで判定できる
• Settings の On Error を「続ける」にしておくと、接続できないときも判定に回せる

④ Code ノードで判定する

// テストケースと HTTP の結果を 1 件ずつ突き合わせる（抜粋）
const cases = $('受入テストケースを読む').all();
return $input.all().map((res, i) => {
  const c = cases[i].json;
  const status = res.json.statusCode;
  const body = String(res.json.data ?? '');
  const okStatus = status === c.expect_status;
  const okText = !c.expect_text || body.includes(c.expect_text);
  let detail = 'OK';
  if (status === undefined) detail = '接続できない';
  else if (!okStatus) detail = `ステータス ${status}（期待値 ${c.expect_status}）`;
  else if (!okText) detail = `期待した文字列がない：${c.expect_text}`;
  return { json: { case_no: c.case_no, title: c.title, ok: okStatus && okText, status, detail } };
});

⑤ DB を確かめる

Postgres ノードで、SELECT しかできないユーザーを使って問い合わせます。マイグレーション（Flyway）の履歴と、マスタの件数を見ます。

SELECT
  (SELECT count(*) FROM flyway_schema_history WHERE NOT success) AS failed_migrations,
  (SELECT max(version) FROM flyway_schema_history WHERE success) AS schema_version,
  (SELECT count(*) FROM customer) AS customers;

⑥ まとめて、分けて、返す

もう一つの Code ノードで API と DB の結果を合わせ、通知の文面と課題の本文を作ります。IF ノードで「すべて合格」かを見て、合格ならチャットへ通知して CI に 200 を、不合格なら課題を起票し、チャットへ通知して CI に 422 を返します。課題の起票は GitLab・GitHub・Jira などのノードか、HTTP Request で各サービスの API を呼びます。

2.x では、ワークフローを直したら必ず Publish しましょう。保存しただけだと、Webhook は前に Publish した版のまま動きます（筆者も一度、直したつもりで古い版を動かしていました）。

検証環境に版 1.0.1 を置いて呼ぶと、6項目すべて合格。次に、設定の誤りで API のパスがずれた版 1.0.2（確かめるために、わざと誤りを入れたもの）を置いて呼ぶと、3項目が不合格になり、課題が起票され、CI には 422 が返りました。

# CI から呼んだときの応答（1.0.2）
{"result":"failed","passed":3,"total":6,"issue":"https://gitlab.example.com/crm/-/issues/102"}
HTTP 422

# チャットに届いた文面
【受入チェック NG】staging v1.0.2（9d81e0c）3/6 件 合格
[OK] AC-01 画面のトップが表示される：OK
[NG] AC-02 アプリが起動している（ヘルスチェック）：ステータス 404（期待値 200）
[NG] AC-03 顧客一覧を取得できる：ステータス 404（期待値 200）
[NG] AC-04 顧客を登録できる：ステータス 404（期待値 200）
[OK] DB-01 マイグレーションの失敗がない：失敗 0 件（適用済み V1）
[OK] DB-02 顧客マスタにデータがある：3 件
課題：https://gitlab.example.com/crm/-/issues/102

チャットと課題管理は、検証のために用意した受け口（モック）で受け取った内容です。実際の運用では Slack・Teams・GitLab などのノードや API に置き換えます。

何が変わるか

気をつけること

• テストデータが増える ── 登録のテストは毎回データを作る。テスト用とわかる名前にして、定期的に消すワークフローを用意する
• 権限は最小に ── DB は読み取り専用のユーザー、Webhook はトークン必須。検証環境だけを対象にし、本番には向けない
• テストの代わりではない ── 単体テストや E2E テストの代わりではなく、「デプロイが正しく済んだか」の確認。細かい仕様の検証はアプリのテストで
• n8n 自体も運用する ── 版の固定と更新、バックアップ、暗号化キーの保管。ほぼ毎週新しい版が出るので、更新の手順を決めておく
• チームで使うなら ── 無料の Community 版は、ワークフローやクレデンシャルを他のメンバーと共有できない。複数人で保守するなら有料版も検討する

RPA（Robotic Process Automation）は、ソフトウェアのロボットが、人と同じように画面を操作して業務をこなす仕組みです。画面の項目を読み取り、クリックし、入力し、別のアプリに貼り付ける。相手のシステムに API がなくても、人が操作できる画面があれば自動化できるのが最大の特徴です。

ただ、「業務の自動化」の道具は RPA だけではありません。大まかに分けると次のようになります。

UiPath とはどんな製品か

UiPath は、2005年にルーマニアのブカレストで DeskOver として創業し、2015年に UiPath に改名、2021年にニューヨーク証券取引所に上場した RPA の代表的な会社です。Gartner の RPA 部門の評価（Magic Quadrant）では、2025年まで7年続けて「リーダー」に選ばれています。いまは RPA だけでなく、AI エージェントまで含めた「エージェント型自動化のプラットフォーム」を掲げています。

料金は、個人や条件を満たす組織向けの無料の Community、月25ドルからの Basic（ロボット2台まで、データは欧州のリージョンのみ）、見積もりの Standard と Enterprise があり、ユーザーやロボットの数で費用が積み上がる形です（2026年10月時点の公式サイト）。

結論から言うと、相手に API か DB の接続口があり、作り手が開発者（または開発者が支えるチーム）なら、n8n で置き換えられる場面は多くあります。

一方で、次のような場面では、UiPath（またはエンタープライズ向けの RPA 製品）を n8n で置き換えるのは難しいか、割に合いません。

逆に言えば、「画面しかない」「人の PC の上で」「全社で数百のロボットを統制」のどれにも当てはまらないなら、n8n を有力な候補にしてよいと考えます。

二者択一にする必要はありません。API で届くところは n8n、画面しかないところは RPAと分け、つなぎ目を API にするのが現実的です。

選ぶときに確かめること

すでに UiPath を使っている会社なら、まず既存のロボットを棚卸しし、「API で済むもの」を n8n に移すところから始めると効果が見えやすいでしょう。これから自動化を始める開発チームなら、n8n で開発・運用の自動化から小さく始め、画面しかないシステムが出てきたときに RPA を検討する順番がおすすめです。