業務自動化の受託をしているエンジニアとして、n8n 公式ドキュメントのセキュリティ関連ページを確認し、一部をセルフホスト版（2.43.7。2026-10-16 時点の最新の安定版）で実際に確かめてまとめました。最初の検証は 1.121.0 で行い、2.43.7 でも同じ結果でした。公式ドキュメントで確認できなかったことは、確認できなかったと書いています。
情報システムの担当の方や、導入を決める立場の方から「n8n は安全か」と聞かれたときに、確認する項目の一覧として使えるようにしています。
結論：トークンは Credentials に、Webhook には認証を
最初に押さえたい点は3つです。
- API トークンは Credentials（認証情報の保管機能）に置きます。 ワークフローの JSON に直接書きません
- 外から呼ばれる Webhook には、認証か IP の制限をかけます。 URL を知っていれば誰でも呼べる状態にしません
- 実行履歴には、処理したデータが残ります。 個人情報を扱うなら、保存の設定と保存期間を決めます
| # | 確認項目 | Cloud | セルフホスト |
|---|---|---|---|
| 1 | 認証情報の置き場所 | 利用者が対応 | 利用者が対応 |
| 2 | Webhook の URL と認証 | 利用者が対応 | 利用者が対応 |
| 3 | 公開範囲（HTTPS・管理画面） | n8n 側 | 利用者が対応 |
| 4 | 環境変数へのアクセス | ― | 利用者が対応 |
| 5 | 実行履歴の個人情報 | 利用者が対応 | 利用者が対応 |
| 6 | 権限・アカウント | 利用者が対応 | 利用者が対応 |
| 7 | 更新 | 利用者が管理画面から更新（サーバーは n8n 側） | 利用者が対応 |
1. 認証情報は Credentials に置く
n8n には、API トークンやパスワードを保管する Credentials という機能があります。セルフホスト版では、認証情報を暗号化キーで暗号化してからデータベースに保存します（出典: n8n Docs「Set a custom encryption key」、2026-10-16 確認）。
ワークフローの中にトークンを直接書くと、書き出した JSON にそのまま残ります。
- 書き出した JSON には、認証情報の名前と ID が含まれます（出典: n8n Docs「Export and import workflows」）
- cURL のコマンドを取り込んで作った HTTP Request ノードは、認証ヘッダーがそのまま残ることがあります（同）
確認すること
- HTTP Request ノードのヘッダー欄に、トークンが直接書かれていないか
- JSON を社外に共有する前に、認証情報の名前と ID を消したか
- セルフホストなら、暗号化キーをデータベースと一緒に保管しているか
暗号化キーは、初回起動時に自動で作られ ~/.n8n に保存されます。N8N_ENCRYPTION_KEY で自分で指定することもできます（出典: 同上）。
2. Webhook の URL を「秘密の鍵」扱いにしない
Webhook は、外部から n8n のワークフローを呼び出す受け口です。問い合わせフォームや kintone の通知を受けるときに使います。
わたしたちの検証では、セルフホスト版の Webhook に curl でデータを送ると、n8n はすぐに「Workflow was started」と返しました。認証を設定していなければ、URL を知っている人は誰でもワークフローを動かせます。
Webhook ノードには、次の認証方式が用意されています（出典: n8n Docs「Webhook node」、2026-10-16 確認）。
| 方式 | 内容 |
|---|---|
| Basic auth | ユーザー名とパスワード |
| Header auth | 決めたヘッダーと値 |
| JWT auth | JWT（署名つきのトークン） |
| None | 認証なし |
また、IP(s) Allowlist というオプションで、呼び出せる IP アドレスを絞れます。リストにない IP からの呼び出しは 403 エラーになります。空欄なら、すべての IP から呼べます（出典: 同上）。
テスト用と本番用で URL が違う
- テスト用：エディタでテストの実行を始めたときに受け付ける（公式ドキュメントによる）
- 本番用：ワークフローを公開（publish）したときに受け付ける。n8n 2.0 以降は、有効化を「公開」と呼びます（出典: n8n Docs「2.0 breaking changes」）
わたしたちの検証では、エディタで実行していない状態でテスト用 URL を呼ぶと 404 が返りました。GET で呼んだ場合も 404 でした（2.43.7・1.121.0）。本番用の URL で受けたデータは、ワークフローの画面ではなく「Executions」タブで確認します。
確認すること
- 外から呼ばれる Webhook に、認証か IP の制限をかけたか
- 送信元（フォームのサービスなど）が、その認証方式に対応しているか。たとえば kintone の Webhook は、送信先 URL のほかに認証ヘッダーを設定できるかを公式ヘルプで確認できませんでした。対応していない送信元は、推測されにくい Path と、受け取った値の確認（アプリ ID など）で守ります
- 使わなくなった Webhook のワークフローを止めたか
3. セルフホストの公開範囲
セルフホスト版では、サーバーをどこまで外に見せるかを自分で決めます。公式ドキュメントのセキュリティの項目には、次のページがあります（出典: n8n Docs「Securing n8n」、2026-10-16 確認）。
- SSL（HTTPS）の設定
- 公開 API（REST API）の無効化
- 特定のノードの利用禁止
- SSRF 対策（ノードがアクセスできるホストの制限）
- セキュリティ監査（security audit）の実行
確認すること
- 外部に出すなら、HTTPS で接続させているか
- 外部から受ける必要があるのは Webhook だけか。管理画面まで公開する必要があるか
- 公開 API を使わないなら、無効にしたか
- セキュリティ監査を実行し、指摘を確認したか
なお、Cookie を HTTPS でだけ送る設定（N8N_SECURE_COOKIE）は、既定で true です（出典: n8n Docs「Security environment variables」）。
4. 環境変数（$env）へのアクセスを制限する
n8n の式やコードノードからは、サーバーの環境変数を読めることがあります。環境変数にデータベースのパスワードなどを置いている場合、ワークフローを作れる人なら誰でも読める状態になりかねません。
これを止めるのが N8N_BLOCK_ENV_ACCESS_IN_NODE です。true にすると、式やコードノードから環境変数を読めなくなります（出典: n8n Docs「Security environment variables」）。
わたしたちの検証で確かめたこと
セルフホスト版（2.43.7 と 1.121.0）で、式の中で $env を使ったワークフローを動かしました。N8N_BLOCK_ENV_ACCESS_IN_NODE を指定しないと、ExpressionError: access to env vars denied で止まりました。false を起動時に指定して初めて読めました。2つの版で同じ結果です。
公式ドキュメントの記載が揃っていない点
- 環境変数の一覧ページ：既定値
false（読める） - 2.0 の変更点のページ：2.0 から、Code ノードからの環境変数の読み取りを既定で遮断（既定値
true）に変えた
わたしたちの検証では、1.121.0 でも 2.43.7 でも「既定では読めない」でした。どちらにしても、true（遮断）を明示的に設定しておくのが確実です。値を渡したいときは、環境変数ではなく Credentials を使います。
あわせて確認したい設定（2.0 以降の既定）
2.0 の変更点のページには、次の変更も書かれています（出典: n8n Docs「2.0 breaking changes」、2026-10-16 確認）。
- コマンドを実行するノード（Execute Command）とローカルファイルの監視ノードは、既定で使えなくなった
- ファイルを読み書きするノードは、既定で
~/.n8n-filesの中だけに限られる
古いバージョンから更新した環境では、これらの設定を意図して変えていないか確認しましょう。
5. 実行履歴に個人情報が残る
n8n は、ワークフローを動かした記録（実行履歴）を保存します。実行履歴には、ノードが受け取ったデータや出力が含まれます（出典: n8n Docs「Manage your data」）。問い合わせフォームを処理すれば、氏名や連絡先が残ります。
わたしたちの検証では、kintone のトークンを間違えて実行すると、n8n は 401 - "{\"code\":\"CB_WA01\"}" というエラーで止まりました（2.43.7 では「Authorization failed - please check your credentials」という表示も出ました）。エラーの表示には、相手のサービスが返した内容がそのまま出ます。相手の返す内容によっては、エラーにも業務データが含まれうると考えておきましょう（履歴の画面での表示はコマンド実行のため未確認です）。
セルフホストで使える設定
次の環境変数で保存の範囲と期間を決められます（出典: n8n Docs「Execution data」、2026-10-16 確認）。
| 環境変数 | 内容 | 既定値 |
|---|---|---|
EXECUTIONS_DATA_SAVE_ON_SUCCESS |
成功した実行を保存するか | ページに記載なし |
EXECUTIONS_DATA_SAVE_ON_ERROR |
失敗した実行を保存するか | ページに記載なし |
EXECUTIONS_DATA_PRUNE |
古い実行を自動で消すか | 有効 |
EXECUTIONS_DATA_MAX_AGE |
何時間たったら消す対象にするか | 336時間（14日） |
EXECUTIONS_DATA_PRUNE_MAX_COUNT |
残す件数の上限 | 10,000件 |
保存するかどうかは、ワークフローごとの設定でも変えられます（出典: 同上）。
Cloud の場合
Cloud では、管理画面の「Manage」や、ワークフローの設定で、成功した実行を保存しないようにできます。保存期間はプランで決まり、Starter は最大2,500件・7日、Pro は最大25,000件・30日です（出典: n8n Docs「Manage your data」）。
画面に見せない設定（Enterprise）
実行データを画面上で見えなくする「Redact execution data」という機能もあります。ただし Enterprise プランが必要です（出典: n8n Docs「Redact execution data」）。
確認すること
- 個人情報を扱うワークフローで、成功時の実行を保存する必要があるか
- 保存期間を、社内の規程に合わせたか
- 実行履歴を見られる人を限定しているか
6. 権限とアカウント
無料のセルフホスト版（Community Edition）には、次の機能がありません（出典: n8n Docs「Community Edition features」）。
- ワークフローと認証情報の共有
- Projects（チームごとの区分け）
- SSO（SAML・LDAP）
公式ドキュメントでは、Community Edition でワークフローや認証情報にアクセスできるのは、インスタンスの所有者と作成者だけとされています。部署ごとに権限を分けたい、社内の ID で一元管理したい場合は、有料プランの機能を確認してください。
二段階認証（2FA）は、各自が「Settings」→「Personal」で設定できる手順が公式にあります。全員に強制する設定（N8N_MFA_ENFORCED_ENABLED）も環境変数の一覧に載っています（出典: n8n Docs「Security environment variables」）。どのプランで使えるかは、公式ページで確認できませんでした。
確認すること
- 管理者（所有者）のアカウントを、個人ではなく管理用として持っているか
- 退職・異動のときに、アカウントと認証情報を引き継ぐ手順があるか
- 2FA を設定したか
7. 更新
セルフホスト版は、更新を自分で行います。docker run で動かしている場合は、新しいイメージを取得し、コンテナを入れ替えます（出典: n8n Docs「Docker」）。
わたしたちの検証は、2026-10-16 時点の最新の安定版 2.43.7 で行いました。セキュリティの既定値は 2.0 で変わっています。公式ドキュメントには 3.0 の変更点のページもあり、未検証のコミュニティノードを既定で無効にするなどの変更が予告されています。古い版を使い続けず、更新の担当と頻度を決めておきましょう。
Cloud では、サーバーの保守は n8n 側が行い、バージョンの更新は利用者が管理画面から行います（出典: n8n Docs「Cloud admin dashboard」）。サーバーの公開範囲を自分で持ちたくない場合は、Cloud を選ぶと確認項目が減ります。n8n の料金とプランは公式の料金ページ（https://n8n.io/pricing/）で確認できます。
受託の現場で、ツールの設定とあわせて決めていること
n8n に限らず、業務の自動化や AI 化を受託するときは、ツールの設定のほかに次の点を顧客と決めています。
- 自動で外に出さない線を引く。 開発に加わっている、受信メールを起点に処理する仕組みでは、処理の結果を一度利用者に返し、外部への転送は人が手で行う形にしています
- 顧客の社内ルールに合わせて、使うサービスを選ぶ。 ある顧客では、社内のポリシーで特定の AI モデルの利用が禁止されていたため、別のモデルで構築しました
- 何がどれだけ動いたかを記録する。 AI を呼ぶ仕組みでは、1回の呼び出しごとにモデル名・使用量・所要時間・成否を記録しています。あとから「何が起きたか」を確かめられるようにするためです
- 見られる人を絞る。 成果を報告する画面も、閲覧できるドメインを関係者に限っています
n8n の設定だけで安全が決まるわけではありません。どのデータを流し、どこで人が確認し、誰が見られるかを先に決めておくと、上の7項目の設定値も決めやすくなります。
導入前チェックリスト
- トークンは Credentials に置き、ノードに直接書いていない
- 外から呼ばれる Webhook に認証か IP 制限をかけた
- （セルフホスト）HTTPS で公開し、不要な公開 API を止めた
- （セルフホスト）
N8N_BLOCK_ENV_ACCESS_IN_NODE=trueを明示した - 実行履歴の保存範囲と保存期間を決めた
- アカウントと認証情報の引き継ぎ手順を決めた
- 更新の担当と頻度を決めた
n8n Cloud を試すなら、n8n Cloud の14日間の無料試用から始められます。
参考にした公式情報
- n8n Docs: n8n Cloud の無料試用（14日間）: https://docs.n8n.io/manage-cloud/cloud-free-trial/ （2026-10-16 確認）
- n8n Docs: ワークフローのエクスポート・インポート: https://docs.n8n.io/workflows/export-import/ （2026-10-16 確認）
- n8n Docs: Community Edition の機能: https://docs.n8n.io/hosting/community-edition-features/ （2026-10-16 確認）
- n8n Docs: Securing n8n: https://docs.n8n.io/hosting/securing/overview/ （2026-10-16 確認）
- n8n Docs: Security environment variables: https://docs.n8n.io/hosting/configuration/environment-variables/security/ （2026-10-16 確認）
- n8n Docs: Execution data: https://docs.n8n.io/hosting/scaling/execution-data/ （2026-10-16 確認）
- n8n Docs: Cloud のデータ管理: https://docs.n8n.io/deploy/use-n8n-cloud/configure-cloud/manage-your-data （2026-10-16 確認）
- n8n Docs: Redact execution data: https://docs.n8n.io/deploy/host-n8n/configure-n8n/security/redact-execution-data （2026-10-16 確認）
- n8n Docs: Webhook node: https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/ （2026-10-16 確認）
- n8n Docs: 暗号化キーの設定: https://docs.n8n.io/hosting/configuration/configuration-examples/encryption-key/ （2026-10-16 確認）
- n8n Docs: 2.0 の破壊的変更: https://docs.n8n.io/changelog/v20-breaking-changes （2026-10-16 確認）
- n8n Docs: 3.0 の破壊的変更: https://docs.n8n.io/changelog/v30-breaking-changes （2026-10-16 確認）
- n8n Docs: 2FA: https://docs.n8n.io/administer/manage-users-and-access/verify-user-identity/require-two-factor-auth （2026-10-16 確認）
- n8n Docs: Docker でのインストール: https://docs.n8n.io/hosting/installation/docker/ （2026-10-16 確認）
- n8n Docs: Cloud の管理画面: https://docs.n8n.io/manage-cloud/cloud-admin-dashboard/ （2026-10-16 確認）
- n8n のリリース一覧: https://github.com/n8n-io/n8n/releases （2026-10-16 確認）
- n8n Docs: リリースノート: https://docs.n8n.io/changelog/release-notes （2026-10-16 確認）
- kintone Webhook の設定: https://jp.kintone.help/k/ja/app/set_webhook/webhook （2026-10-16 確認）
導入時の設定のご相談
n8n を社内に入れたいが、情報システムの担当者に説明できる形で設定をそろえたい、という段階からお手伝いします。合同会社frectas では、流すデータと人が確認する箇所を業務の側から決めたうえで、認証情報・Webhook・実行履歴・権限の設定と、運用の引き継ぎまで担当します。お問い合わせからご相談ください。
