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

n8n v2.0 の重要な変更 | n8n ドキュメント

n8n v2.0 がまもなくリリースされます。このドキュメントでは、重要な破壊的変更と、移行に向けて実施すべき準備について説明します。これらの更新により、セキュリティが強化され、設定が簡素化され、レガシー機能が削除されます。

n8n 2.0 のリリースは、安全で信頼性が高く、本番運用に対応した自動化プラットフォームを提供するという n8n の取り組みを継続するものです。このメジャーバージョンには、重要なセキュリティ強化と、廃止予定機能の整理が含まれています。

動作変更​

サブワークフローが待機状態から再開した際に想定どおりのデータを返す​

これまでは、親実行（Parent）が、待機状態に入るノードを含むサブワークフロー実行（Child execution）を呼び出し、かつ親実行がサブワークフロー実行の完了を待つ設定になっている場合、親実行は正しくない結果を受け取っていました。

たとえば、サブワークフロー実行にタイムアウトが 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 ツールは _query をサポートしており、これは AI エージェントがツールを呼び出す際に渡される入力文字列です。

移行手順： 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 コマンドを使用してください。これにより、ワークフローの公開状態をより明確に把握し、適切に制御できます。

外部フック（External Hooks）​

ワークフローフックの非推奨化​

フック関数 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 への更新時に問題が発生した場合やサポートが必要な場合は、コミュニティのフォーラムをご利用ください。