n8n 2.0移行で中小企業の自動化を止めないための注意点

2026年10月16日

毎日動いているはずのn8nの自動化フローが、ある日突然エラーで止まっていた——そんな経験はしたくないはずです。n8nは2025年12月15日、ワークフロー自動化ツールの大型リリース「n8n 2.0」を安定版として公開しました[1]。今回のテーマは「secure by default(既定で安全)」。セルフホスト環境のCode nodeでの環境変数アクセス制限や、タスクランナーの既定有効化など、既存ワークフローの動作に直接影響する破壊的変更が複数含まれています[1][2]。この記事では、何が変わったのか、アップグレード前に確認すべきことを整理します。

n8n 2.0で何が変わったのか

n8nの公式発表によれば、2.0のテーマは「secure by default」であり、従来の許容的な動作に依存しているワークフローがある場合、明示的な設定変更をしなければそのままでは動かなくなる可能性があります[1]。公式ブログでは次のように説明されています。

“The theme is ‘secure by default.’ If your workflows rely on any of the previous, more permissive behaviors, you can still enable them, but you’ll need to do so explicitly.”[1]

具体的な変更は主に3点です。まず、Code nodeから環境変数へのアクセスが既定でブロックされます[1][2]。次に、Code nodeの実行がタスクランナー(隔離された実行環境)上で動くことが既定になりました[1][2]。さらに、設定ファイルのパーミッションが0600(ファイル所有者のみ読み書き可)でなければエラーになる仕様に変わっています[2]。加えて、任意コマンドを実行できるExecuteCommandやLocalFileTriggerといったノードも既定で無効化され、データベースはMySQLサポートが廃止されPostgreSQLへの移行が必須になりました[2]。

旧バージョン(1.x)と2.0の違い

項目	n8n 1.x(旧)	n8n 2.0(新)
Code nodeの環境変数アクセス	既定で可能	既定でブロック(`N8N_BLOCK_ENV_ACCESS_IN_NODE=false`で解除可)[2]
Code nodeの実行環境	メインプロセス内で実行	タスクランナー(隔離環境)で実行が既定[1][2]
設定ファイルの権限	制約なし	`0600`必須(Windowsは対象外)[2]
ExecuteCommand等の危険ノード	既定で有効	既定で無効化[2]
データベース	MySQL対応	MySQLサポート廃止、PostgreSQL必須[2]

セルフホストで運用している場合、この表の変更点はいずれも「今まで動いていたワークフローが、何もしていないのに動かなくなる」典型パターンです。クラウド版(n8n Cloud)はn8n側で対応されるため、影響は主にセルフホスト環境に出ます[2]。

アップグレード前に確認すべきこと

本番環境にそのまま2.0を適用せず、次の手順で確認してから進めることをおすすめします。

現在のn8nバージョンと、セルフホストかクラウドかを確認する
Code nodeの中で環境変数($env等)を参照しているワークフローを洗い出す
ExecuteCommand・LocalFileTriggerノードを使っているワークフローがあるか確認する
データベースがMySQLの場合、PostgreSQLへの移行計画を立てる
Linux/Mac環境では設定ファイルの権限を確認する

# 設定ファイルの権限確認(Unix/Linux)
ls -l ~/.n8n/config
# 必要であれば権限を修正
chmod 600 ~/.n8n/config

ステージング環境を用意できる場合は、本番反映前に同じワークフローで動作確認する

⚠ 注意:Code nodeで環境変数を使っているワークフローがある場合、N8N_BLOCK_ENV_ACCESS_IN_NODE=falseで旧動作に戻すことは技術的に可能ですが、これはセキュリティを既定で強化した変更を元に戻す設定です。恒久的に使うのではなく、ワークフロー側を環境変数に依存しない形に書き換えることを優先してください。

ハマりどころ・落とし穴

実務でよく起きるのは次のようなケースです。

API連携が突然止まる:外部APIのキーをCode node内で環境変数から読んでいたワークフローが、アップグレード後にエラーで停止する
タスクランナーがインフラ要件を満たせない:タスクランナーの既定有効化により、これまでのコンテナのメモリ・CPU設定では起動に支障が出ることがある[1][2]
Windows環境との仕様差:設定ファイルのパーミッション要件はWindowsでは対象外とされていますが、Linux系サーバーで運用している場合は要確認[2]

💡 学び:「アップデート通知が来たらすぐ適用する」運用のままだと、こうした破壊的変更に気づかず本番で止まって初めて発覚することになります。メジャーバージョンアップの際はリリースノートを確認する工程を、担当者の作業フローに組み込んでおくと安心です。

対応した場合・しなかった場合

今回のアップデートで得られるのは、Code node実行の隔離やデフォルトでの安全設定強化といったセキュリティ面の向上です[1]。一方、何も確認せずにアップグレードした場合、環境変数に依存したワークフローやMySQLを使った構成は停止するリスクがあります[2]。公開直後のメジャーバージョンであり、中小企業における移行時間や影響範囲を数字で示せるデータはまだないため、「何時間の作業で済む」といった断定は避けます。ただ、事前に洗い出しをしておけば、本番で自動化が止まって慌てるリスクは明確に減らせます。

まとめ

n8n 2.0の「secure by default」は方向性としては歓迎すべき変更ですが、セルフホストで運用している中小企業にとっては、アップグレード前の確認作業が欠かせません。まずは自社のワークフローがCode nodeの環境変数・危険ノード・MySQLのいずれかに依存していないかを確認し、該当する場合は計画的に対応することをおすすめします。

「うちで動いているn8n、このままアップグレードして大丈夫か確認してほしい」と思った方は、お問い合わせからお気軽にご相談ください。初回ヒアリング(30分・無料)で、御社の運用環境を踏まえた移行計画をご提案します。

itdoor | AI/業務自動化の受託開発・コンサルティングを提供。

根拠: [1] n8n公式ブログ「Introducing n8n 2.0」(確認日2026-10-16)「The theme is ‘secure by default.’ If your workflows rely on any of the previous, more permissive behaviors, you can still enable them, but you’ll need to do so explicitly.」 https://blog.n8n.io/introducing-n8n-2-0/ [2] n8n公式ドキュメント「v2.0 breaking changes」(確認日2026-10-16)「To improve security, n8n will block access to environment variables from the Code node by default.」「configuration files must use 0600 permissions, which means only the file owner can read and write them.」 https://docs.n8n.io/changelog/v20-breaking-changes