n8n（エヌエイトエヌ）は、複数のSaaSやAPIをつないで業務を自動化する「ワークフロー自動化」プラットフォームです。ノーコード寄りで始められる一方、HTTPリクエストやコード実行もできるため、運用に耐える自動化基盤としても使われます。この記事では、n8nで何ができるのか、導入手段（Cloud/セルフホスト）、よくあるつまずき（Webhook URL・永続化・セキュリティ）を結論ファーストで整理します。 n8nは、トリガー（開始条件）→処理（変換・分岐・API呼び出し）→アクション（通知・登録・更新）という流れを、ノードを線でつないで構築するタイプの自動化ツールです。Webhookで外部イベントを受けたり、HTTP Requestで任意のAPIを叩いたりできるため、「SaaS連携だけ」より自由度が高いのが特徴です。 押さえておきたいポイント n8nのWebhookノードは「トリガーノード」で、外部からHTTPリクエストが届いたタイミングでワークフローを開始できます。公式ドキュメントでも、Webhookノードはワークフローを開始でき、標準のHTTPメソッドに対応する旨が説明されています。 Webhookノードはトリガーとして動作し、Webhook URLが呼ばれるとデータをワークフロー内で扱えるようになります（HTTPメソッドにも対応）。
n8nの概要
n8nは「業務自動化ツール」であると同時に、HTTP・Webhook・認証情報を扱う“軽量な統合基盤”でもあります。便利な反面、公開運用ではセキュリティ設計が必須です。できること
代表的なユースケース
Webhookで外部から起動
HTTP Requestノードを使えば、任意のREST APIを呼び出してデータ取得・登録・更新が可能です。SaaSの「公式連携ノード」がなくても、APIがあれば統合できるのが強みです。 注意 セルフホストはDockerが手早く、公式ドキュメントでも「多くのセルフホスト用途でDockerを推奨」し、データ永続化のために
HTTPで任意APIを連携
Cloudと自前の違い
観点
n8n Cloud
セルフホスト
初期構築
早い（アカウント作成で利用開始）
Docker/DB/SSLなどが必要
運用
運用負荷が低い
アップデート・監視・バックアップが必要
セキュリティ/統制
ベンダー側の管理に依存
ネットワーク制御や認証を自社で設計できる
コストの考え方
実行回数などの枠に依存
サーバー費＋運用工数（自動化規模で最適解が変わる）
「Cloudの料金」や「実行回数の上限」はプラン変更で変わる可能性があります。導入判断の際は、必ずn8n公式サイトの最新情報も確認してください。最短の始め方
Dockerで起動
n8n_dataを/home/node/.n8nへマウントする構成が示されています。
docker run -it --rm \
--name n8n \
-p 5678:5678 \
-v n8n_data:/home/node/.n8n \
docker.n8n.io/n8nio/n8n
永続化は最優先
まずボリューム（またはホストディレクトリ）をマウントし、/home/node/.n8n配下（DB/暗号化鍵など）を確実に保持してください。テスト起動のつもりが、そのまま本番運用に移行して「データが消えた」事故が起きやすいポイントです。
公開WebhookのURL設定
リバースプロキシ配下で運用する場合、外部から到達するWebhookのURLを正しく生成させる必要があります。公式ドキュメントでは、WEBHOOK_URLは「リバースプロキシ配下で動かすときにWebhook URLを手動指定するための変数」とされています。
# docker-composeの例（抜粋）
services:
n8n:
image: docker.n8n.io/n8nio/n8n
ports:
- "5678:5678"
environment:
- N8N_PROTOCOL=https
- N8N_HOST=example.com
- WEBHOOK_URL=https://example.com/
volumes:
- n8n_data:/home/node/.n8n
volumes:
n8n_data:運用の注意点
Webhookの衝突
Webhookは「同じパス×同じHTTPメソッド」が重複すると登録できません。公式のトラブルシュートでも、パスとメソッドの組み合わせは1つに限られる点が明記されています。
最低限のセキュリティ
セルフホストでWebhookをインターネット公開するなら、次の3点は最低限押さえてください。
- 管理画面へのアクセス制限（VPN/社内IP/認証）
- Webhookに認証を付ける（ヘッダ認証、署名検証など）
- 定期アップデート（既知脆弱性への追随）
n8n公式ドキュメントにも「Securing n8n」として、2FAの利用やデータ収集設定など、運用上のセキュリティ観点が整理されています。
警告
Webhookは便利ですが、設計次第で攻撃面にもなります。公開する場合は「到達制御（WAF/リバースプロキシ）」「認証」「ログ監視」をセットで考えてください。
Webhook認証の選択肢
Webhookの認証は用途により最適解が変わります。例えば、単純な連携なら固定ヘッダ（シークレット）で十分なこともあります。一方で、外部SaaSが署名検証（HMACなど）を提供しているなら、署名検証を優先した方が安全です。n8nの認証情報（Credentials）としてWebhook向けの認証方式もドキュメント化されています。
よくある質問
無料で使えますか
セルフホストなら、インフラ費用は別としてソフトウェア自体は利用できます。n8n Cloudはマネージド運用の代わりに月額プランが必要です。
スクレイピングにも使えますか
n8n自体は自動化基盤なので、HTTPでページ取得→抽出→保存といった処理は構成できます。ただし、対象サイトの規約、アクセス制限、ボット対策、法的リスクを踏まえた設計が必要です（高頻度アクセスや認証回避は特に注意）。
どこから始めるべきですか
まずは「Webhookで受ける」か「スケジュールで回す」か、トリガーを1つ決めて小さく作るのが近道です。次に、失敗時のリトライや通知、ログの残し方を決めると運用品質が上がります。
まとめ
- n8nはSaaS連携とHTTP/APIを組み合わせて業務を自動化できる
- セルフホストはDocker＋永続化が基本、Webhook URLは環境変数で設計する
- Webhook公開は「認証・到達制御・更新」を前提に運用する
参考資料
