n8nはどんなテレメトリやデータを外部に送るか、セルフホストでどう無効化するか?

・ ・ 朝倉 凛

この話題の全体像は n8nで業務自動化とAIをつなぐ使い方の総まとめ にまとめている。

前提の確認

n8nの「外部に送るデータ」を議論するとき、プロダクト自身のテレメトリと、各ノードが業務上の目的で外部APIに送るデータは区別する必要がある。 本稿は前者、すなわち本体の診断送信や更新確認、クラッシュ報告、AI機能に付随するプロファイリングを対象にし、ワークフロー設計として意図的に行うAPI送信は論点から外す。 ここを混ぜると無効化の設計が誤るので、意図的なAPI呼び出しとテレメトリを混同しないことを先に置く。

n8nはクラウド提供とセルフホストの両方に対応している。 運用形態が変わると、送信主体や責任分界が変わるため、送信の抑止方法も変わる。

ここでいう「無効化」は二層ある。 アプリの設定や環境変数で送信機能を止める層と、ネットワークで外向き通信そのものを制限する層である。 後者は確実だが副作用が大きいので、両者を組み合わせて運用可能性を確保する。

一次資料の突き合わせ

n8nのプライバシーポリシーは、会社情報、適用範囲、更新、個人データの類型、Cookie の利用、プロファイリングやAIの利用、保持期間、権利行使の窓口などを項目として掲げていると記されている。 資料は「すべてのユーザー」に適用されるとし、ウェブサイトやサービス経由のデータ処理、問い合わせ窓口の所在を明示している。 ただし、セルフホスト実行時の本体テレメトリの具体的な項目やオプトアウトの手順を、この抜粋だけで特定することはできない。

一方で、公式リポジトリは自己紹介として、セルフホストまたはクラウドで動くプラットフォームであること、監査証跡や可観測性を備えること、AIワークフローを構築できることを述べている。 ここにはインストールの導線や機能概要が載るが、テレメトリの詳細や無効化スイッチの有無を説明する文言は見当たらない。 機能説明と法務文書は役割が異なるので、この差分は不自然ではない。

したがって、提供された一次資料の範囲では、「どのデータが外部に送られるか」「セルフホストでどう止めるか」という点の決定的な根拠は観測できない。 裏返すと、仕様の有無を断定できる段階ではなく、設計上の前提を置いて検証と抑止策を準備するのが現実的になる。

食い違いが生む実務上の影響

ポリシーが一般的説明に留まるとき、セルフホスト運用者は「本体からの送信は無いはずだ」と想定しがちだが、更新確認や診断送信はプロダクト改善のために実装されやすい。 この種の送信はプロセスが自発的に周期的なHTTPリクエストを行う形で現れるため、知らぬ間に出口監査にひっかかる。 結果として、個人情報や識別子の取り扱い、データ所在、ベンダー越境移転の審査が後追いになる。

そこで、送信の有無が不明な段階でも成立する抑止策を層別に準備する。 まず仕様の未確定を前提に、観測と制御を同時に設計する。 これにより、仮に送信が存在しても内容と頻度を把握し、止める経路を確保できる。

Docker によるセルフホストでは、全外向き通信をプロキシに強制し、プロキシ側で宛先とメソッドを記録するのが扱いやすい。 そのうえで許可リストを段階的に狭め、機能退行がないかをUIとログで同時に観察する。 送信を遮断しても業務に必要な外部API呼び出しが止まらない構成に分離しておくと復旧が速い。

留保付きの見立て

現時点の抜粋資料は、テレメトリの項目列挙やオプトアウト手順を直接は示していない。 したがって、実装の有無は観測で補い、抑止はアプリ設定とネットワーク制御を併置して担保するのが実務的である。 特にAI関連機能はプロファイリングやモデル提供者とのデータ共有が絡みやすいので、利用時は個別に設計審査を行う。

最後に、ベンダーに確認すると話が早い要点をまとめる。 テレメトリの項目、識別子の種類と生成方法、送信の頻度とトリガー、送信先の名称、保持期間、オプトアウトの手順の有無である。 問い合わせ窓口はプライバシーポリシーに記されているので、記録を残す形で照会する。 確認が取れるまでは、無効化できると断定しない運用設計を続ける。

出典

  1. Privacy Policy — n8n — n8n (一次情報)
  2. n8n — Workflow Automation Tool (repository) — n8n-io / GitHub (一次情報)