メインコンテンツまでスキップ

n8n v2.0 における重大な変更点

n8n v2.0 のリリースが間近に迫っています。このドキュメントでは、重要な破壊的変更と、スムーズな移行のために取るべき対応策を紹介します。これらのアップデートにより、セキュリティが強化され、設定が簡素化され、レガシー機能が削除されます。

n8n 2.0 のリリースは、安全で信頼性が高く、本番環境に対応可能な自動化プラットフォームを提供するという n8n のコミットメントを引き継いでいます。このメジャーバージョンには、重要なセキュリティ強化と非推奨機能のクリーンアップが含まれています。

挙動の変更​

サブワークフローが待機状態から再開された際に期待通りのデータを返すように​

以前は、親実行（Parent）がサブ実行（Child）を呼び出し、そのサブ実行内に待機状態になるノード（例：65秒を超える Wait ノード、Webhook 呼び出し、フォーム送信、Slack ノードなどの人手による承認ノード）が含まれており、かつ親実行がサブ実行の完了を待つように設定されていた場合、親実行は誤った結果を受け取っていました。

親ワークフロー:
親ワークフロー

サブワークフロー:
サブワークフロー

v1: 親実行はサブ実行の入力をそのまま出力として受け取る
v1: 親実行はサブ実行の結果を受け取らない

v2: 親実行はサブ実行の結果を受け取る
v2: 親実行はサブ実行の結果を受け取る

これにより、サブワークフロー内で人手による承認ノードを使用し、その結果（例：承認または拒否）を親ワークフローで利用できるようになります。

移行方法:
サブワークフローの入力データが親ワークフローに返されると想定しているすべてのワークフローを確認し、新しい挙動に合わせて更新してください。親ワークフローは、サブワークフローの入力ではなく、サブワークフローの最後の出力を受信するようになります。

Start ノードの削除​

Start ノードはサポートされなくなりました。このノードはワークフローを開始する元々の方法でしたが、現在はより目的に特化したトリガーノードに置き換えられています。

移行方法:
ワークフローの使用方法に応じて、Start ノードを以下のように置き換えてください：

  • 手動実行: Start ノードを Manual Trigger ノードに置き換えます。
  • サブワークフロー: 別のワークフローからこのワークフローがサブワークフローとして呼び出される場合は、Start ノードを Execute Workflow Trigger ノードに置き換え、ワークフローをアクティブにしてください。
  • 無効化された Start ノード: Start ノードがすでに無効化されている場合は、ワークフローから削除してください。

ワークフローの保存と公開​

新しいワークフロー公開システムが、従来の「アクティブ/非アクティブ」切り替えスイッチに代わって導入されました。「アクティブ/非アクティブ」のトグルは、新しい「公開/非公開」ボタンに置き換えられます。この変更により、ワークフローの変更をいつ本番環境に反映させるかをより細かく制御でき、まだ作業中の変更が本番環境に適用されてしまうリスクを軽減できます。詳細については、「ワークフローの保存と公開」をご参照ください。

廃止されたサービスのノードを削除​

以下のノードは、接続先の外部サービスがもはや利用できないため削除されました：

  • Spontit ノード
  • crowd.dev ノード
  • Kitemaker ノード
  • Automizy ノード

移行方法:
上記のいずれかのノードを使用しているワークフローがある場合は、エラーを回避するためにそれらのワークフローを更新または削除してください。

セキュリティ​

Code ノードによる環境変数へのアクセスをデフォルトでブロック​

セキュリティを強化するため、n8n は Code ノードによる環境変数へのアクセスをデフォルトでブロックします。N8N_BLOCK_ENV_ACCESS_IN_NODE のデフォルト値が true に設定されます。

移行方法:
Code ノード内で環境変数にアクセスする必要がある場合は、環境設定で N8N_BLOCK_ENV_ACCESS_IN_NODE=false を設定してください。機密データについては、環境変数ではなくクレデンシャルやその他の安全な方法を使用することを推奨します。

設定ファイルのパーミッションを厳格に強制​

セキュリティを向上させるため、n8n は設定ファイルに対して厳格なファイルパーミッションを要求します。デフォルトでは、設定ファイルは 0600 パーミッション（ファイル所有者のみが読み書き可能）である必要があります。これは SSH が秘密鍵を保護する方法と同様です。

移行方法:
v2.0 にアップグレードする前にこの挙動をテストするには、N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true を設定してください。Windows など、ファイルパーミッションをサポートしていない環境では、N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false を設定してこの要件を無効化できます。

ランナーをデフォルトで有効化​

セキュリティと分離性を向上させるため、n8n はランナーをデフォルトで有効にします。すべての Code ノードの実行は、ランナー上で実行されます。

移行方法:
v2.0 にアップグレードする前に、N8N_RUNNERS_ENABLED=true を設定してこの挙動をテストしてください。インフラストラクチャがランナーの実行要件を満たしていることを確認してください。さらにセキュリティを強化したい場合は、外部モードの使用を検討してください。

n8nio/n8n Docker イメージからランナーを削除​

v2.0 以降、メインの n8nio/n8n Docker イメージには、外部モード用のランナーが含まれなくなります。外部モードでランナーを実行するには、別途 n8nio/runners ランナー用 Docker イメージを使用する必要があります。

移行方法:
Docker の外部モードでランナーを実行している場合は、n8nio/n8n イメージの代わりに n8nio/runners イメージを使用するように設定を更新してください。

Pyodide ベースの Python Code ノードおよびツールを削除​

n8n は、Pyodide ベースの Python Code ノードおよびツールを削除し、ネイティブ Python を使用するランナーに基づく実装に置き換えます。これにより、セキュリティとパフォーマンスが向上します。v2.0 以降、Python Code ノードは外部モードのランナーとネイティブ Python ツールとの組み合わせでのみ使用できます。

ネイティブ Python Code ノードは、Pyodide 版で提供されていた _input などの組み込み変数やドットアクセス記法をサポートしません。詳細は Code ノードのドキュメント をご参照ください。

ネイティブ Python ツールは、AI エージェントがツールを呼び出す際に渡される入力文字列である _query をサポートしています。

移行方法:
Code ノードで引き続き Python を使用するには、外部モードでランナーを設定し、既存の Python Code ノードおよびツールが互換性を持っているか確認してください。

ExecuteCommand および LocalFileTrigger ノードをデフォルトで無効化​

セキュリティリスクがあるため、n8n は ExecuteCommand および LocalFileTrigger ノードをデフォルトで無効にします。これらのノードは、任意のコマンドの実行やファイルシステムへのアクセスを許可します。

移行方法:
これらのノードを使用する必要がある場合は、NODES_EXCLUDE 環境変数を更新して、n8n 設定内の無効化ノードリストからこれらを除外してください。例えば、NODES_EXCLUDE="[]" を設定するとすべてのノードが有効になり、特定のノードのみを有効にするには必要なノードだけを除外リストから削除します。

OAuth コールバック URL に認証をデフォルトで要求​

n8n は、OAuth コールバックエンドポイントに対してデフォルトで認証を要求するようになります。N8N_SKIP_AUTH_ON_OAUTH_CALLBACK のデフォルト値が true（認証不要）から false（認証必須）に変更されます。

移行方法:
v2.0 にアップグレードする前に、N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=false を設定し、認証が有効な状態で OAuth インテグレーションが正常に動作することをテストしてください。

N8N_RESTRICT_FILE_ACCESS_TO のデフォルト値を設定​

n8n は、ファイル操作がどこで実行できるかを制御するために N8N_RESTRICT_FILE_ACCESS_TO にデフォルト値を設定します。これは ReadWriteFile および ReadBinaryFiles ノードに影響します。デフォルトでは、これらのノードは ~/.n8n-files ディレクトリ内のファイルにのみアクセスできます。

移行方法:
ファイルノードを使用しているワークフローを確認し、許可されたディレクトリ内のファイルにのみアクセスしていることを保証してください。他のディレクトリへのアクセスを許可する必要がある場合は、N8N_RESTRICT_FILE_ACCESS_TO 環境変数を希望のパスに設定してください。

N8N_GIT_NODE_DISABLE_BARE_REPOS のデフォルト値を true に変更​

セキュリティ上の理由から、Git ノードはベアリポジトリをデフォルトでブロックするようになります。N8N_GIT_NODE_DISABLE_BARE_REPOS のデフォルト値が true に設定されるため、この設定を変更しない限りベアリポジトリは無効になります。

移行方法:
ワークフローでベアリポジトリを使用する必要がある場合は、環境設定で N8N_GIT_NODE_DISABLE_BARE_REPOS=false を設定して有効化してください。

データ​

MySQL/MariaDB のサポート終了​

n8n は、MySQL および MariaDB をストレージバックエンドとしてサポートしなくなります（このサポートは v1.0 で非推奨となっていました）。最適な互換性と長期的なサポートを得るには、PostgreSQL を使用してください。MySQL ノード自体は引き続きこれまで通りサポートされます。

移行方法:
v2.0 にアップグレードする前に、データベース移行ツールを使用して MySQL または MariaDB から PostgreSQL または SQLite へデータを移行してください。

SQLite レガシードライバーの削除​

信頼性の問題があるため、n8n はレガシーな SQLite ドライバーを削除します。接続プールドライバーが唯一の SQLite ドライバーとなります。接続プールドライバーは WAL モードを使用し、単一の書き込み接続と複数の読み取り接続プールを備えています。ベンチマークテストによると、最大で 10 倍高速になることがあります。

移行方法:
sqlite-pooled ドライバーが自動的にデフォルトドライバーになります。すぐに接続プールを有効化するには、DB_SQLITE_POOL_SIZE を 0 より大きい値に設定してください。デフォルトの接続プールサイズは 2 に設定されます。

メモリーベースのバイナリデータモードを削除​

n8n は、実行中にバイナリデータをメモリに保持する N8N_DEFAULT_BINARY_DATA_MODE の default モードを削除します。v2 以降、以下のオプションが利用可能となり、パフォーマンスと安定性が向上します：

  • filesystem: バイナリデータをファイルシステムに保存（通常モードのデフォルト）
  • database: バイナリデータをデータベースに保存（キューイングモードのデフォルト）
  • s3: バイナリデータを S3 互換ストレージに保存

また、N8N_AVAILABLE_BINARY_DATA_MODES 設定も削除されるため、モードは N8N_DEFAULT_BINARY_DATA_MODE のみで決定されます。

移行方法:
設定に応じて自動的にファイルシステムまたはデータベースモードが使用されます。n8n インスタンスにバイナリデータを保存する十分なディスク容量があることを確認してください。詳細は「バイナリデータの設定」をご参照ください。

設定と環境​

dotenv のアップグレード​

n8n は .env ファイルから環境設定を読み込むために dotenv ライブラリを使用しています。このライブラリがバージョン 8.6.0 から最新版にアップグレードされ、.env ファイルの解析方法が変更される可能性があります。主な破壊的変更は以下の通りです：

  • バッククォートのサポート (#615): 値にバッククォートが含まれる場合は、シングルクォートまたはダブルクォートで囲んでください。
  • 複数行のサポート: 複数行の値が使用可能になりました。
  • # によるコメント: # で始まる行はコメントとして扱われます。

移行方法:
dotenv のチェンジログを確認し、新しいバージョンとの互換性を確保するために .env ファイルを更新してください。

n8n --tunnel オプションの削除​

n8n --tunnel コマンドラインオプションは v2.0 で削除されます。

移行方法:
開発やテストで --tunnel オプションを使用している場合は、ngrok、localtunnel、Cloudflare Tunnel などの他のトンネリングソリューションに切り替えてください。ワークフローやドキュメントを更新し、この変更を反映させてください。

QUEUE_WORKER_MAX_STALLED_COUNT の削除​

QUEUE_WORKER_MAX_STALLED_COUNT 環境変数および Bull による停止したタスクの再試行メカニズムは、混乱を招きやすく信頼性が低いため削除されます。

移行方法:
この環境変数を設定から削除してください。アップグレード後、n8n は停止したタスクを自動的に再試行しなくなります。停止したタスクを処理する必要がある場合は、独自の再試行ロジックまたは監視を実装することを検討してください。

N8N_CONFIG_FILES の削除​

N8N_CONFIG_FILES 環境変数は削除されました。

移行方法:
この環境変数を設定から削除してください。設定を環境変数、.env ファイル、または _FILE ベースの設定に移行してください。

CLI とワークフロー​

CLI コマンド update:workflow の置き換え​

update:workflow CLI コマンドは非推奨となり、類似の機能とより明確な意味を持つ2つの新コマンドに置き換えられます：

  • publish:workflow — 引数は id および（オプションで）versionId
  • --all 引数は削除され、本番環境で意図せずワークフローが公開されるのを防止
  • unpublish:workflow — 引数は id および all

移行方法:
新しい publish:workflow コマンドを使用して、ID で個別にワークフローを公開し、必要に応じてバージョンを指定してください。公開を取り消すには、新しい unpublish:workflow コマンドを使用します。これにより、ワークフローの公開状態に対する明確性と制御が向上します。

外部フック​

フロントエンドワークフローフックの非推奨化​

フック workflow.activeChange および workflow.activeChangeCurrent は非推奨となり、新しいフック workflow.published に置き換えられます。新しいフックは、ワークフローの任意のバージョンが公開された際にトリガーされます。

移行方法:
workflow.activeChange および workflow.activeChangeCurrent の代わりに、新しい workflow.published フックを使用するようにコードを更新してください。このフックはより一貫性のある挙動を提供し、ワークフローバージョンが公開された際にトリガーされます。

リリースチャンネル​

n8n はリリースチャンネル名を latest および next からそれぞれ stable および beta に変更しました。

stable タグは最新の安定版を、beta タグは最新の実験版を指します。これらのタグは npm および Docker Hub の両方で利用可能です。現時点では、n8n は引き続きリリースバージョンに latest および next タグも付与しますが、これらのタグは今後のメジャーバージョンで削除される予定です。

推奨事項:
n8n のバージョンを 2.0.0 のような特定のバージョン番号に固定することを推奨します。

問題の報告​

n8n 2.0 へのアップデート中に問題が発生した場合は、コミュニティフォーラムでヘルプとサポートを受けてください。