n8nを起動したときに「Please set N8N_RUNNERS_ENABLED=true」のような警告が出て、n8n_runners_enabledとは何なのか、すぐ有効化してよいのか迷っている人は多いはずです。この記事では、2026/05/19時点で確認できる公式ドキュメント、n8n Community、GitHub Issueの情報をもとに、N8N_RUNNERS_ENABLEDの意味、trueとfalseの違い、Dockerでの考え方、エラーが出たときの見方を整理します。

結論からいうと、N8N_RUNNERS_ENABLEDはCodeノードでJavaScriptやPythonを実行するための「タスクランナー」を有効化する環境変数です。ただし、単に警告が出たからといって何も考えずにtrueへ変えると、環境やワークフローの内容によってはメモリ不足、Runner timeout、依存モジュール不足などの別問題が表面化することがあります。まずは「なぜ警告が出るのか」「自分の構成で有効化すべきか」を切り分けるのが安全です。

この記事のポイント
✅ n8n_runners_enabledの正体と、警告文の意味がわかる
✅ N8N_RUNNERS_ENABLED=true / false / Docker設定の判断軸がわかる
✅ タスクランナー有効化後に起きやすいエラーと対処方針がわかる
✅ n8n 2.0以降を見据えた移行準備の考え方がわかる
今日のセールをまとめてチェック！
本日のセール・タイムセールをまとめてチェックできます。
Amazon
楽天市場
Yahooショッピング
メルカリ

n8n_runners_enabledの基本と設定判断

n8n_runners_enabledの基本と設定判断
  1. n8n_runners_enabledへの答えはCodeノード用タスクランナーの有効化設定である
  2. please set n8n_runners_enabled trueは今後の標準化に備える警告である
  3. n8n_runners_enabled trueはCodeノード実行をランナー側に寄せる設定である
  4. n8n_runners_enabled=falseは警告を残しつつ従来寄りに動かす選択である
  5. n8n_runners enabled=true dockerではcomposeの環境変数として渡すのが基本である
  6. n8n_runners_enabled deprecatedは無効状態が将来非推奨になるという意味である

n8n_runners_enabledへの答えはCodeノード用タスクランナーの有効化設定である

【AI】【業務効率化】【職場】n8n_runners_enabledへの答えはCodeノード用タスクランナーの有効化設定である

n8n_runners_enabledで検索している人がまず知るべき答えは、これはn8nの「タスクランナー」を有効にするための環境変数だということです。公式ドキュメントでは、変数名は大文字でN8N_RUNNERS_ENABLEDと書かれており、初期値はfalse、説明は「タスクランナーを有効にするかどうか」という内容です。

タスクランナーは、n8nの中でも特にCodeノードに関係します。Codeノードとは、ワークフロー内でJavaScriptやPythonのコードを実行できるノードです。つまり、ただのHTTP RequestノードやIFノードだけを使っている場合より、ユーザーが書いたコードを実行するワークフローで重要になりやすい設定です。

公式ドキュメントでは、タスクランナーについて「Code nodeで定義されたコードを実行する」と説明されています。つまり、N8N_RUNNERS_ENABLED=trueは、n8n本体の設定というより、コード実行の仕組みをどう扱うかに関わる設定だと考えるとわかりやすいです。

参考：Task runner environment variables
https://docs.n8n.io/hosting/configuration/environment-variables/task-runners/

🧩 N8N_RUNNERS_ENABLEDの基本整理

項目 内容
環境変数名 N8N_RUNNERS_ENABLED
検索されがちな表記 n8n_runners_enabled
種類 Boolean
デフォルト false
主な役割 タスクランナーを有効化する
関係が深い機能 CodeノードのJavaScript / Python実行

ここで注意したいのは、検索キーワードでは小文字のn8n_runners_enabledが使われがちですが、実際の環境変数として設定する場合は大文字のN8N_RUNNERS_ENABLEDを使うのが基本だという点です。Docker Composeや.env、Linuxの環境変数、Windowsの環境変数でも、この大文字表記で扱うのが自然です。

もう1つ重要なのは、N8N_RUNNERS_ENABLEDだけで全てが決まるわけではないことです。公式ドキュメントには、N8N_RUNNERS_MODE、N8N_RUNNERS_AUTH_TOKEN、N8N_RUNNERS_MAX_CONCURRENCY、N8N_RUNNERS_TASK_TIMEOUTなど、関連する設定が複数あります。軽い環境ならまずtrueだけで試せる場合もありますが、本番運用や重いワークフローでは周辺設定も見たほうがよいです。

🧭 まず見るべき関連変数

変数 ざっくりした意味 初期値・特徴
N8N_RUNNERS_ENABLED タスクランナーを使うか 初期値はfalse
N8N_RUNNERS_MODE internal / externalのどちらで動かすか 初期値はinternal
N8N_RUNNERS_MAX_CONCURRENCY ランナーが同時に処理するタスク数 初期値は5
N8N_RUNNERS_TASK_TIMEOUT タスクの最大実行秒数 初期値は300秒
N8N_RUNNERS_MAX_OLD_SPACE_SIZE ランナーのNode.jsメモリ上限調整 必要に応じて設定

要するに、n8n_runners_enabledで調べている人が最初に押さえるべきポイントは、「警告を消すための謎設定」ではなく、n8nのコード実行方式に関わる設定だということです。ここを理解しておくと、後で出てくるDocker、メモリエラー、Runner timeout、2.0移行の話もつながりやすくなります。

please set n8n_runners_enabled trueは今後の標準化に備える警告である

【AI】【業務効率化】【職場】please set n8n_runners_enabled trueは今後の標準化に備える警告である

n8nを起動したときに、次のような警告を見た人は多いはずです。

N8N_RUNNERS_ENABLED → Running n8n without task runners is deprecated. Task runners will be turned on by default in a future version. Please set N8N_RUNNERS_ENABLED=true to enable task runners now and avoid potential issues in the future.
引用元：https://community.n8n.io/t/n8n-runners-enabled/93629

この警告の意味は、かなりざっくり言うと、「今はタスクランナーなしでも動くが、将来的にはタスクランナーありが標準になる予定なので、早めに有効化しておいてください」という案内です。エラーで即停止しているわけではなく、移行を促すための警告と捉えるのが近いです。

ただし、ここで焦ってN8N_RUNNERS_ENABLED=trueにする前に、自分のn8nがどのように動いているかを見たほうがよいです。単体のn8nなのか、Dockerなのか、queue modeなのか、workerを使っているのか、Codeノードで大きなデータを処理しているのかによって、確認ポイントが変わります。

🚦 警告文を見たときの判断

状況 すぐやること 補足
ローカル検証環境 trueで試して挙動確認 失敗しても戻しやすい
小規模な本番環境 バックアップ後に検証 Codeノードがある場合は特に注意
大量データ処理あり 先にメモリ・タイムアウト確認 GitHub Issueで類似報告あり
queue mode / worker構成 mainとworkerの役割を確認 worker側ランナー構成を整理
既にエラーが出ている ログを確認してから変更 警告と別問題の可能性あり

n8n Communityでは、コマンドラインでn8n startを実行したユーザーがこの警告に戸惑い、「どう設定すればよいか」と質問しています。回答では、環境変数なのでOSごとの方法で設定するものだと説明されています。また、Docker利用をすすめるコメントもありました。

つまり、please set n8n_runners_enabled trueで検索している人の多くは、「これは必須なのか」「どこに書けばいいのか」「今すぐ変えないと壊れるのか」を知りたい状態です。結論としては、今すぐ全員が同じ手順で変更すればよい、というより、環境に合わせて段階的に確認するのが現実的です。

📝 警告の読み解き方

表現 意味
deprecated 将来的に非推奨になる方向
turned on by default in a future version 将来バージョンでは標準で有効化される予定
Please set ... true 早めに有効化して検証してほしいという案内
avoid potential issues 将来の移行時トラブルを減らす目的

ここで大事なのは、警告は「今すぐ壊れる」という意味ではない一方で、無視し続けると将来のアップデートで慌てる可能性があるということです。特に2025年から2026年にかけて、n8n 2.0でタスクランナーがデフォルト有効化されることを気にする投稿も出ています。今のうちに検証環境で試しておく価値はあります。

n8n_runners_enabled trueはCodeノード実行をランナー側に寄せる設定である

【AI】【業務効率化】【職場】n8n_runners_enabled trueはCodeノード実行をランナー側に寄せる設定である

N8N_RUNNERS_ENABLED=trueにすると、n8nはタスクランナーを使ってCodeノードの処理を実行する方向になります。公式ドキュメントでは、N8N_RUNNERS_MODEの初期値はinternalで、internalはn8nがタスクランナーを子プロセスとして起動する方式だと説明されています。

つまり、単にtrueにした場合、多くの環境ではn8n本体の中から内部タスクランナーが立ち上がると考えるとわかりやすいです。外部ランナーを別コンテナや別プロセスで動かす場合は、externalモードや認証トークンなどの追加設定が関係します。

trueにするメリットとしては、今後のn8nの標準構成に近づけられること、Codeノードの実行をタスクランナーの仕組みに乗せられることが挙げられます。一方で、ワークフローの内容によっては、これまで見えていなかったメモリや依存関係の問題が出る場合もあります。

⚙️ trueにしたときの変化

観点 内容
Codeノード タスクランナー経由の実行になる
起動ログ Runner登録ログが出ることがある
メモリ ランナー側のメモリ設定が重要になる場合あり
エラー Runner timeoutやdisconnect系が出る場合あり
将来対応 n8nの今後の標準構成に近づく

GitHub Issue #13740では、N8N_RUNNERS_ENABLED=trueにした後、メモリを多く使う処理でJavaScript heap out of memoryが起きたという報告があります。投稿者はCSV解析など大量データ処理を例に挙げており、「メモリが高いまま残る」ように見えると説明しています。

参考：N8N_RUNNERS_ENABLED=true crashes with JavaScript heap out of memory after some hours
https://github.com/n8n-io/n8n/issues/13740

もちろん、これは特定バージョン・特定構成の報告であり、すべての環境で同じことが起きるとは言えません。ただ、trueにした直後から重いCodeノードで不安定になる場合、N8N_RUNNERS_MAX_OLD_SPACE_SIZEやN8N_RUNNERS_MAX_CONCURRENCY、データの分割処理を検討する価値があります。

🧪 true化前に見たい項目

確認項目 理由
Codeノードの有無 タスクランナーの影響を受けやすい
1回の処理データ量 大量データはメモリ問題につながりやすい
n8nバージョン 報告されている挙動がバージョン依存の可能性あり
Docker / npm / Cloudron 設定場所や依存関係が変わる
queue modeの有無 main / worker / runnerの役割整理が必要

N8N_RUNNERS_ENABLED=trueは、警告を消すためだけの設定ではありません。Codeノードの実行基盤を変える設定です。そのため、本番で重い処理を動かしている場合は、いきなり本番反映するより、検証環境や低負荷時間帯でログを見ながら進めるほうが無難です。

n8n_runners_enabled=falseは警告を残しつつ従来寄りに動かす選択である

【AI】【業務効率化】【職場】n8n_runners_enabled=falseは警告を残しつつ従来寄りに動かす選択である

N8N_RUNNERS_ENABLED=falseは、タスクランナーを有効化しない設定です。公式ドキュメント上でも初期値はfalseとされています。ただし、起動時に「タスクランナーなしは非推奨になる」という警告が表示される可能性があります。

つまり、falseを選ぶこと自体が即座に間違いというわけではありません。特に、trueにしたことでワークフローが不安定になった、またはRunner関連のエラーが出た場合、一時的にfalseへ戻す判断は現実的です。n8n Communityにも、N8N_RUNNERS_ENABLEDを有効にしたら重いワークフローがランダムにクラッシュし、無効化したら動作が戻ったという投稿があります。

参考：N8N_RUNNERS_ENABLED crash my WF
https://community.n8n.io/t/n8n-runners-enabled-crash-my-wf/83440

この投稿では、Offer expired and no open task slots、Runner timed out、ERR_STRING_TOO_LONGなどのログが報告されています。かなり重いワークフローで、具体的な内容は共有されていませんが、タスクランナー有効化により別の制約に当たった可能性が示されています。

🧯 falseを選ぶのが現実的な場面

場面 判断
true化後に本番ワークフローが落ちる 一時的にfalseへ戻す価値あり
重いCodeノードの原因調査中 先に処理分割やメモリ設定を確認
バージョンアップ直後で不安定 ログを保存して切り戻しも検討
検証環境がない いきなり本番反映は慎重に
警告だけで実害なし 期限を決めて検証計画を作る

ただし、falseのままにする場合でも、将来のn8nではタスクランナーがデフォルト有効になる可能性があるため、永続的な回避策として考えるのは少し危ういかもしれません。特にn8n 2.0関連の投稿では、タスクランナーが標準化される流れを前提にした相談が出ています。

また、GitHub Issue #25255では、N8N_RUNNERS_ENABLED=falseかつN8N_RUNNERS_MODE=offを設定しているにもかかわらず、タスクランナーが起動するという報告もあります。対象バージョンは2.4.6、2.4.8、2.6.3とのことで、IssueはClosedになっていますが、少なくとも「falseにすれば常にランナーが完全に出ない」とは言い切れない時期・構成があったようです。

参考：Task Runner starts despite N8N_RUNNERS_ENABLED=false
https://github.com/n8n-io/n8n/issues/25255

🧾 false運用時の注意点

注意点 内容
警告は残る 将来の変更に備える案内が出る
将来の標準とズレる アップデート時に再検証が必要
完全停止できない報告もある バージョン依存の可能性あり
問題の先送りになりやすい 原因調査の期限を決めるべき
本番安定性とのバランス 直近の安定を優先する判断もあり

N8N_RUNNERS_ENABLED=falseは、今すぐの安定運用を優先するための選択肢になり得ます。ただし、将来の移行を考えると、ログを見て原因を切り分け、段階的にtrueへ移行できる状態を作るのが望ましいです。

n8n_runners enabled=true dockerではcomposeの環境変数として渡すのが基本である

【AI】【業務効率化】【職場】n8n_runners enabled=true dockerではcomposeの環境変数として渡すのが基本である

Dockerでn8nを動かしている場合、n8n_runners enabled=true dockerやN8N_RUNNERS_ENABLED=true dockerのように検索する人が多いはずです。基本的には、docker-compose.ymlのenvironmentにN8N_RUNNERS_ENABLED=trueを追加します。

GitHub Issue #13740の投稿でも、Docker Compose内のenvironmentにN8N_RUNNERS_ENABLED=trueを入れている例が示されています。そこではPostgreSQL、Redis queue、S3 binary dataなどを使った比較的本格的な構成の中で、ランナーを有効化していました。

Dockerで注意したいのは、n8n本体だけでなく、worker、sidecar runner、外部タスクランナーなどの構成によって、どのコンテナにどの環境変数を渡すべきかが変わることです。単体構成ならn8nコンテナだけで済むかもしれませんが、queue modeではmainとworkerの役割が分かれます。

🐳 Docker Composeでの基本イメージ

構成 設定先の考え方
単体n8n n8nサービスのenvironmentに追加
queue mode worker側のCode実行も確認
external runner runnerコンテナ側にも関連変数が必要
Cloudronなど 専用の環境読み込み手順がある場合あり
本番 変更前にバックアップと切り戻し手順を確認

たとえば単体のDocker Composeなら、イメージとしては次のような形です。

environment:
  - N8N_RUNNERS_ENABLED=true

ただし、外部ランナーを使う場合はこれだけでは足りません。公式ドキュメントでは、N8N_RUNNERS_MODE=external、N8N_RUNNERS_AUTH_TOKEN、N8N_RUNNERS_TASK_BROKER_URIなどの変数が関係します。特にexternal modeでは、n8n本体とランナーの間で認証するための共有シークレットが必要になります。

🔐 external modeで関係しやすい変数

変数 使いどころ
N8N_RUNNERS_MODE=external 外部ランナー方式にする
N8N_RUNNERS_AUTH_TOKEN n8nとランナー間の共有シークレット
N8N_RUNNERS_TASK_BROKER_URI ランナーが接続するブローカーURI
N8N_RUNNERS_BROKER_PORT ブローカーのポート
N8N_RUNNERS_BROKER_LISTEN_ADDRESS ブローカーの待受アドレス

n8n 2.0関連のCommunity投稿では、queue modeでworker側にタスクランナーsidecarを持たせ、main側はN8N_RUNNERS_ENABLED=falseにしている構成について相談されています。将来的にタスクランナーがデフォルト有効化されるならmain側にもrunnerが必要なのか、という疑問です。

参考：N8N 2.0 Breaking Change – Enable Task Runners by Default
https://community.n8n.io/t/n8n-2-0-breaking-change-enable-task-runners-by-default/231564

この相談に対して、CommunityではOFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=trueを使っているなら、main側でN8N_RUNNERS_ENABLED=trueにして警告を満たしても、mainのrunnerは実質あまり使わないのではないか、という趣旨のコメントがありました。ただし、これはCommunity上のやり取りであり、公式の確定仕様として読むより、構成判断の参考として扱うのがよいです。

n8n_runners_enabled deprecatedは無効状態が将来非推奨になるという意味である

【AI】【業務効率化】【職場】n8n_runners_enabled deprecatedは無効状態が将来非推奨になるという意味である

n8n_runners_enabled deprecatedで検索している人は、警告文のdeprecatedが何を意味するのか不安になっているはずです。ここでのポイントは、N8N_RUNNERS_ENABLEDという変数そのものが非推奨という意味ではなく、タスクランナーなしでn8nを動かす状態が非推奨に向かっていると読むのが自然だということです。

実際の警告文では、「Running n8n without task runners is deprecated」と表現されています。つまり、非推奨の対象は「task runnersなしで動かすこと」です。その後に「future versionでtask runnersがデフォルト有効になる」と続いています。

この手の警告は、今すぐエラーで止めるというより、将来の破壊的変更に備えてユーザーに設定変更を促すために出されることが多いです。n8n側としては、Codeノードの安全性や実行分離、性能管理をタスクランナー中心に寄せていきたいのかもしれません。ただし、その背景までは提供情報だけでは断定できないため、ここは推測の域を出ません。

📌 deprecatedの読み方

表現 読み方
変数がdeprecated その変数自体が今後使われない可能性
今回の警告 タスクランナーなし運用が非推奨という意味
future version 将来バージョンで挙動が変わる可能性
turned on by default デフォルト有効化の予定
すぐ停止するか 警告だけなら即停止とは限らない

n8n 2.0に関するCommunity投稿では、タスクランナーがデフォルト有効になることを前提に、main instanceにもrunnerが必要になるのかという議論が出ています。これは、運用者にとってかなり重要な論点です。特にqueue modeでmainとworkerを分けている場合、main側にも余分なrunnerが起動するなら、リソース設計が変わる可能性があります。

⚖️ deprecated警告への向き合い方

対応 向いているケース
すぐtrue化 検証環境・小規模環境
期限を決めて検証 本番影響が大きい環境
一時的にfalse維持 既にtrueで障害が出た環境
external mode検討 runnerを別管理したい環境
バージョンアップ計画に組み込む 長期運用中の本番n8n

ここでやってはいけないのは、警告を単なるノイズとして無期限に放置することです。今動いていても、将来のn8nアップデートで標準挙動が変わる可能性があります。少なくとも、どのワークフローにCodeノードがあるか、どれが大量データを扱っているか、どの環境変数をどこで管理しているかは整理しておいたほうがよいです。

一方で、警告を見た瞬間に全本番環境へtrueを入れるのも、少し雑な対応になりがちです。GitHub IssueやCommunityには、実際にtrue化後のクラッシュ、タイムアウト、モジュール不足の報告があります。警告は移行準備の合図であって、無検証の即時変更命令ではないと捉えるのが実務的です。

【AI】【業務効率化】【職場】n8n_runners_enabled deprecatedは無効状態が将来非推奨になるという意味である
忘れる前に！【ふるさと納税】今年もお得に！
ふるさと納税のポイント付与は2025年10月に廃止になりました。
Amazon
楽天市場
Yahooショッピング
メルカリ

n8n_runners_enabled運用時のエラー対策と移行準備

【AI】【業務効率化】【職場】n8n_runners_enabled deprecatedは無効状態が将来非推奨になるという意味である
  1. set n8n_runners_enabled trueの前にCodeノードと処理量を確認するべきである
  2. n8n_runners_enabled=trueで落ちる場合はメモリ・タイムアウト・ペイロードを疑うべきである
  3. Offer expired and no open task slotsはランナー枯渇や重い処理のサインである
  4. Cannot find module系エラーは依存モジュールと実行環境のズレを確認するべきである
  5. queue modeではmain・worker・runnerの役割を分けて考えるべきである
  6. Pythonランナーでは標準ライブラリ・外部モジュール・環境変数アクセス制限を確認するべきである
  7. 総括：n8n_runners_enabledのまとめ

set n8n_runners_enabled trueの前にCodeノードと処理量を確認するべきである

【AI】【業務効率化】【職場】set n8n_runners_enabled trueの前にCodeノードと処理量を確認するべきである

set n8n_runners_enabled trueと検索している人は、設定方法だけを知りたいかもしれません。しかし実務的には、設定前にCodeノードの使い方と処理データ量を確認することがかなり重要です。なぜなら、タスクランナーは主にCodeノードの実行に関係するためです。

Codeノードをほとんど使っていない環境なら、N8N_RUNNERS_ENABLED=trueにしても影響は限定的かもしれません。一方で、大量のCSV、巨大なJSON、長時間回るJavaScript、外部モジュールを使うコードがある場合は、タスクランナー有効化によってメモリ制限やタイムアウトが目立つようになる可能性があります。

公式ドキュメントによると、N8N_RUNNERS_TASK_TIMEOUTの初期値は300秒です。つまり、タスクが最大5分で止められる設定が標準です。これまで長時間のCodeノードがなんとなく動いていた環境では、この制限が意識される場面が出るかもしれません。

✅ true化前のチェックリスト

チェック項目 見る理由
Codeノードの数 影響範囲を把握するため
1回あたりの処理件数 メモリ使用量に関わるため
長時間処理の有無 TASK_TIMEOUTに関わるため
外部モジュール利用 runner側で許可・存在確認が必要なため
失敗時の切り戻し方法 本番停止を避けるため

n8n Communityのクラッシュ報告では、重いワークフローが「以前は動いていたが、runner有効化後にランダムに落ちる」と説明されています。もちろん詳細なワークフローは共有されていないため一般化はできませんが、少なくとも重いCodeノードを持つ環境では事前確認が必要という示唆になります。

参考：N8N_RUNNERS_ENABLED crash my WF
https://community.n8n.io/t/n8n-runners-enabled-crash-my-wf/83440

また、設定前にはバージョンも確認したほうがよいです。GitHub Issueでは、n8n 1.80.5、1.81.4、1.94.0、2.6.3など、複数バージョンでrunner関連の話題が出ています。すべてが同じ原因ではありませんが、runnerまわりはバージョンによる挙動差があり得る領域と見ておくのが自然です。

🧰 変更前に控えておきたい情報

情報 使い道
n8n version 類似Issueの確認
Node.js version heap / module関連の参考
Database SQLite / PostgreSQLで構成が変わる
Execution mode main / queueの判断
Hosting Docker / npm / Cloudronなどの差分確認

「警告を消したい」だけであれば、N8N_RUNNERS_ENABLED=trueを入れれば済むように見えます。しかし、本番運用では警告を消すことより、変更後にワークフローが安定して動くことのほうが大切です。まずはCodeノードと処理量を棚卸しし、問題が起きたときに戻せる状態で試すのがよいです。

n8n_runners_enabled=trueで落ちる場合はメモリ・タイムアウト・ペイロードを疑うべきである

【AI】【業務効率化】【職場】n8n_runners_enabled=trueで落ちる場合はメモリ・タイムアウト・ペイロードを疑うべきである

N8N_RUNNERS_ENABLED=trueにした後にワークフローが落ちる場合、まず疑いたいのはメモリ、タイムアウト、ペイロードサイズ、同時実行数です。公式ドキュメントには、これらに関係する環境変数が複数用意されています。

代表的なのはN8N_RUNNERS_MAX_OLD_SPACE_SIZEです。これはタスクランナーのNode.jsに渡す--max-old-space-size相当の設定で、メモリ不足時の調整候補になります。また、N8N_RUNNERS_TASK_TIMEOUTはタスクの最大実行時間、N8N_RUNNERS_MAX_CONCURRENCYはランナーが同時に実行できるタスク数です。

GitHub Issue #13740では、N8N_RUNNERS_ENABLED=trueにした環境で、数時間後にJavaScript heap out of memoryが発生したと報告されています。ログには「FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed – JavaScript heap out of memory」とあり、大量データ処理が関係している可能性が示されています。

参考：N8N_RUNNERS_ENABLED=true crashes with JavaScript heap out of memory after some hours
https://github.com/n8n-io/n8n/issues/13740

🧠 メモリ・タイムアウト系で見る変数

変数 初期値・説明 見直す場面
N8N_RUNNERS_MAX_OLD_SPACE_SIZE Node.jsのメモリ上限調整 heap out of memory
N8N_RUNNERS_TASK_TIMEOUT 初期値300秒 長時間Codeノード
N8N_RUNNERS_MAX_CONCURRENCY 初期値5 同時実行が多い
N8N_RUNNERS_MAX_PAYLOAD 最大ペイロードサイズ 大きなデータ転送
N8N_RUNNERS_TASK_REQUEST_TIMEOUT 初期値20秒 runner待ちタイムアウト

ただし、これらを単純に大きくすればよいとは限りません。たとえばメモリ上限を上げれば一時的に落ちにくくなる可能性はありますが、根本的に1回のCodeノードで巨大データを抱え込んでいるなら、処理を分割したほうが安定することもあります。

n8n Communityのエラー文にも、「処理するitems数を減らし、loop nodeでbatchingする」「N8N_RUNNERS_MAX_OLD_SPACE_SIZEでメモリを増やす」といった趣旨の案内が含まれています。これは、n8n側としても巨大処理を一括で抱え込むより、分割処理やメモリ調整を選択肢として見ていることを示します。

🧩 対策の優先度

優先度 対策 理由
高 Codeノードの処理件数を減らす 根本的な負荷を下げられる
高 ログのエラー種別を確認 timeoutとheapでは対策が違う
中 MAX_OLD_SPACE_SIZE調整 メモリ不足時の候補
中 MAX_CONCURRENCY調整 同時実行過多を抑える
低〜中 MAX_PAYLOAD調整 巨大データ転送時に検討

N8N_RUNNERS_ENABLED=trueで落ちる場合、最初にやるべきことは「runnerを悪者にする」ことではありません。有効化によって、もともと重かった処理の制約が見えるようになった可能性もあります。ログの文言、落ちるタイミング、処理件数、Codeノードの内容をセットで確認すると、対策が立てやすくなります。

Offer expired and no open task slotsはランナー枯渇や重い処理のサインである

【AI】【業務効率化】【職場】Offer expired and no open task slotsはランナー枯渇や重い処理のサインである

タスクランナー有効化後に見かけることがあるログとして、Offer expired and no open task slotsがあります。n8n Communityの投稿では、このログが大量に出た後、Runner timed outやERR_STRING_TOO_LONGにつながった様子が共有されています。

この文言をそのまま読むと、タスクを処理するrunner側に空きスロットがないまま、割り当ての提案が期限切れになった、という意味に見えます。提供情報だけでは内部実装まで断定できませんが、一般的にはrunnerが忙しすぎる、同時実行数が足りない、1つの処理が重すぎるといった状況を疑うのが自然です。

公式ドキュメントでは、N8N_RUNNERS_MAX_CONCURRENCYの初期値は5です。これは、1つのタスクランナーが同時に実行できるタスク数に関係します。また、N8N_RUNNERS_TASK_REQUEST_TIMEOUTは、runnerが利用可能になるまでタスク要求が待てる秒数で、初期値は20秒です。

🚦 Offer expired系ログで見るポイント

見る項目 理由
同時実行数 runnerの空きスロットに関係
長時間Codeノード スロットを占有し続ける可能性
queue modeのworker数 処理能力に関係
MAX_CONCURRENCY 同時処理数の調整候補
TASK_REQUEST_TIMEOUT runner待ち時間の調整候補

ただし、MAX_CONCURRENCYを上げれば必ず解決するとは限りません。同時処理数を増やすと、CPUやメモリの消費も増えるため、むしろ不安定になる場合もあります。大量データを処理するCodeノードが複数並列で走る環境では、同時実行数を下げたほうが安定する可能性もあります。

🧮 対応パターンの比較

対応 メリット 注意点
MAX_CONCURRENCYを上げる 待ちを減らせる可能性 メモリ消費が増える
MAX_CONCURRENCYを下げる 1台あたりの負荷を抑えられる 待ち時間が増える
workerを増やす 処理能力を増やせる 構成が複雑になる
Codeノードを分割 根本負荷を下げやすい ワークフロー修正が必要
timeoutを延ばす 長い処理に対応しやすい 問題の発見が遅れる場合あり

Offer expired and no open task slotsが出ている場合、まずはどのワークフロー実行中に出るのかを見ます。特定のCodeノードや大量データ処理と連動しているなら、runner設定より先にワークフロー側の分割を考えたほうがよいこともあります。

Community投稿では、最終的にERR_STRING_TOO_LONGも出ています。これはNode.jsの文字列サイズ制限に関係するエラーとしてコメントされています。つまり、単なる同時実行数の問題だけでなく、巨大データを文字列として扱っている可能性も示唆されます。ここまで来ると、環境変数だけで解決するより、データ処理の設計見直しも必要になりそうです。

Cannot find module系エラーは依存モジュールと実行環境のズレを確認するべきである

【AI】【業務効率化】【職場】Cannot find module系エラーは依存モジュールと実行環境のズレを確認するべきである

N8N_RUNNERS_ENABLED=trueにしたら、Cannot find module 'moment-with-locales'のようなエラーが出たというGitHub Issueもあります。Issue #15876では、runnerを有効化したときだけTask runner failed to startが出て、無効化すると出なくなると報告されています。

参考：N8N_RUNNERS_ENABLED=true
https://github.com/n8n-io/n8n/issues/15876

この報告では、n8n v1.94.0、Node.js v10.19.0、SQLite、main execution modeという情報が記載されています。ただし、n8n v1.94.0に対してNode.js v10.19.0という組み合わせはやや気になります。提供情報だけでは原因を断定できませんが、実行環境や依存モジュールのズレが関係している可能性はありそうです。

タスクランナーでは、Codeノードで使える外部モジュールが制限されます。公式ドキュメントには、JavaScript向けにNODE_FUNCTION_ALLOW_BUILTINやNODE_FUNCTION_ALLOW_EXTERNALがあり、n8nはデフォルトでモジュールのimportを無効化すると説明されています。

📦 JavaScript Codeノード周辺の許可設定

変数 役割
NODE_FUNCTION_ALLOW_BUILTIN Node.js組み込みモジュールの許可
NODE_FUNCTION_ALLOW_EXTERNAL 外部モジュールの許可
N8N_RUNNERS_ALLOW_PROTOTYPE_MUTATION prototype mutationを許可
GENERIC_TIMEZONE runner側のタイムゾーン
NODE_OPTIONS Node.jsオプション

ここで重要なのは、N8N_RUNNERS_ENABLED=trueによって、これまで曖昧に動いていたコードや依存モジュールの扱いが変わる可能性があることです。特定のモジュールをCodeノードで使っている場合、そのモジュールがn8n環境内に存在するか、runner側から利用できるか、許可設定が必要かを確認します。

🛠️ Cannot find moduleで確認する順番

順番 確認内容
1 エラーに出ているモジュール名
2 n8nの実行方式 Docker / npm / Cloudron
3 n8nとNode.jsのバージョン
4 Codeノードで外部モジュールを使っているか
5 NODE_FUNCTION_ALLOW_EXTERNALの設定
6 runner側イメージにモジュールが含まれているか

ただし、セキュリティ面も忘れてはいけません。外部モジュールや組み込みモジュールを広く許可すると便利ですが、Codeノードで実行できることも増えます。チームでn8nを使っている場合や、複数ユーザーがCodeノードを書ける環境では、*で全許可する前にリスクを検討したほうがよいです。

Cannot find module系は、runnerの不具合に見えることもありますが、実際には「runner側でそのモジュールを使える状態になっていない」だけの場合もあります。ログのモジュール名、n8nバージョン、Node.jsバージョン、インストール方法をそろえて確認するのが近道です。

queue modeではmain・worker・runnerの役割を分けて考えるべきである

【AI】【業務効率化】【職場】queue modeではmain・worker・runnerの役割を分けて考えるべきである

n8nをqueue modeで運用している場合、N8N_RUNNERS_ENABLEDの判断は少し複雑になります。単体構成ならn8n本体に設定すれば済む話でも、queue modeではmain instance、worker、task runnerの役割が分かれるためです。

n8n Communityの2.0関連投稿では、main instanceにはN8N_RUNNERS_ENABLED=FALSE、workerにはsidecar containerとしてtask runnersを持たせている構成が紹介されています。さらにOFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=trueを使っているため、main側ではrunnerを使わないつもりだという相談でした。

参考：N8N 2.0 Breaking Change – Enable Task Runners by Default
https://community.n8n.io/t/n8n-2-0-breaking-change-enable-task-runners-by-default/231564

この構成で悩ましいのは、n8n 2.0以降でタスクランナーがデフォルト有効になる場合、main側にもrunnerを用意する必要があるのかという点です。Community上では、main側にもN8N_RUNNERS_ENABLED=trueを設定して警告を満たす案が出ていますが、リソースを無駄にしないかという懸念も示されています。

🧭 queue modeの役割整理

役割 主な仕事 runnerとの関係
main instance UI、Webhook、管理系 manual実行の扱いに注意
worker queueのジョブ実行 Codeノード実行でrunnerが重要
task runner CodeノードのJS/Python実行 worker側に配置されることが多い
Redis queue管理 runnerそのものではない
DB 実行履歴や設定保存 runnerとは別の基盤

queue modeでは、どこでCodeノードが実行されるのかを正確に理解する必要があります。OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=trueを使っているなら、手動実行もworkerへ寄せる構成になりますが、細かな挙動はバージョンや設定に依存する可能性があります。

⚙️ queue modeで確認する設定

設定 確認理由
EXECUTIONS_MODE=queue queue modeかどうか
workerのN8N_RUNNERS_ENABLED workerでCodeを処理するため
mainのN8N_RUNNERS_ENABLED 警告・manual実行の扱い
OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS 手動実行をworkerへ寄せるか
runner sidecarの有無 external構成か確認
brokerのポート・URI runner接続に必要

ここでありがちな失敗は、main側の警告だけを見て、worker側のrunner設定を確認しないことです。実際にワークフローを実行しているのがworkerなら、worker側のランナーが登録されているか、ログにRegistered runnerが出ているかを見るべきです。

反対に、main側にもrunnerが勝手に立ち上がるとリソースを使う可能性があります。GitHub Issue #25255のように、false設定でもrunnerが起動するという報告もあるため、バージョンによってはプロセス確認も必要です。queue modeでは、環境変数の文字だけでなく、実際のログとプロセスを確認するのが安全です。

Pythonランナーでは標準ライブラリ・外部モジュール・環境変数アクセス制限を確認するべきである

【AI】【業務効率化】【職場】Pythonランナーでは標準ライブラリ・外部モジュール・環境変数アクセス制限を確認するべきである

n8nのタスクランナーはJavaScriptだけでなくPythonにも関係します。公式ドキュメントには、Python向けの環境変数としてN8N_RUNNERS_STDLIB_ALLOW、N8N_RUNNERS_EXTERNAL_ALLOW、N8N_RUNNERS_BUILTINS_DENY、N8N_BLOCK_RUNNER_ENV_ACCESSが掲載されています。

特に重要なのは、Pythonの標準ライブラリや外部モジュールがデフォルトで広く使えるわけではない点です。公式ドキュメントでは、Python標準ライブラリのimportはデフォルトで無効、外部モジュールもデフォルトで無効と説明されています。利用したい場合は、許可リストに入れる必要があります。

また、N8N_BLOCK_RUNNER_ENV_ACCESSは初期値がtrueで、Python code task内からrunnerの環境変数へアクセスすることをブロックします。セキュリティ上は妥当な制限ですが、Pythonコード内でos.environを読む前提の処理がある場合は、ここで詰まる可能性があります。

🐍 Pythonランナー関連の主な変数

変数 内容
N8N_RUNNERS_STDLIB_ALLOW 使用を許可するPython標準ライブラリ
N8N_RUNNERS_EXTERNAL_ALLOW 使用を許可する外部Pythonモジュール
N8N_RUNNERS_BUILTINS_DENY 使用できない組み込み関数
N8N_BLOCK_RUNNER_ENV_ACCESS 環境変数アクセスをブロックするか
N8N_RUNNERS_MAX_CONCURRENCY runnerの同時処理数

Pythonランナーでは、セキュリティと利便性のバランスが特に重要です。たとえばN8N_RUNNERS_STDLIB_ALLOW=*のように広く許可すれば便利になりますが、Codeノードでできることも増えます。外部モジュールについても、runnerイメージに含まれていないものは許可しても使えない可能性があります。

🔒 Python利用時の注意点

やりたいこと 必要になりやすい確認
標準ライブラリをimportしたい N8N_RUNNERS_STDLIB_ALLOW
pandasなどを使いたい runnerイメージに含まれるか
外部モジュールを許可したい N8N_RUNNERS_EXTERNAL_ALLOW
環境変数を読みたい N8N_BLOCK_RUNNER_ENV_ACCESS=false
危険な組み込みを使いたい N8N_RUNNERS_BUILTINS_DENY

ただし、環境変数アクセスを許可する場合は注意が必要です。APIキーやDBパスワードなどが環境変数に入っている環境では、Codeノードを書けるユーザーがそれらを読めるようになる可能性があります。業務利用や複数ユーザー利用では、安易にfalseへ変える前に権限設計を確認したほうがよいです。

JavaScriptランナーと同じく、Pythonランナーでも「動かないから全部許可する」は短期的には楽ですが、長期的にはリスクになります。必要なモジュールだけを許可し、なぜ許可したのかをcomposeや運用メモに残しておくと、後から原因を追いやすくなります。

総括：n8n_runners_enabledのまとめ

【AI】【業務効率化】【職場】総括：n8n_runners_enabledのまとめ

最後に記事のポイントをまとめます。

  1. n8n_runners_enabledは正式にはN8N_RUNNERS_ENABLEDである。
  2. N8N_RUNNERS_ENABLEDはタスクランナーを有効化する環境変数である。
  3. タスクランナーは主にCodeノードのJavaScriptやPython実行に関係する仕組みである。
  4. 公式ドキュメント上の初期値はfalseである。
  5. 起動時の警告は、タスクランナーなし運用が将来非推奨になるという案内である。
  6. please set N8N_RUNNERS_ENABLED=trueは即時障害ではなく移行準備の警告である。
  7. trueにするとCodeノード実行がrunner経由になり、ログやメモリ挙動が変わる場合がある。
  8. 重いCodeノードではheap out of memory、Runner timeout、task slots不足を確認すべきである。
  9. Dockerではdocker-compose.ymlのenvironmentに設定するのが基本である。
  10. queue modeではmain、worker、runnerの役割を分けて考えるべきである。
  11. external modeではN8N_RUNNERS_AUTH_TOKENやbroker URIなどの追加設定が重要である。
  12. false維持は一時的な安定策になり得るが、将来移行の検証は必要である。
  13. Cannot find module系エラーでは依存モジュール、許可設定、実行環境を確認すべきである。
  14. Pythonランナーでは標準ライブラリ、外部モジュール、環境変数アクセス制限を確認すべきである。
  15. 本番では警告を消すことより、変更後にワークフローが安定することを優先すべきである。

関連記事

✓n8n 略の意味が一発でわかる！読み方・由来・使い道までまるっと整理
✓zapier bootcampはどれを選ぶ？迷う前に読める講座比較と失敗しない選び方
✓aiエージェントなんj民がザワつく理由とは？本命・できること・転職価値まで冷静に整理
✓電気主任技術者は「やめとけ！」そう言われる6つの理由を解説します。
✓manusのメールアドレス変更はできない？知らないと損する引っ越し手順まとめ
✓blinded manuscriptの意味が一発でわかる！投稿前にやらかしやすい盲点まで丸ごと整理
✓不動産仲介は「底辺」なのか？そう言われる6つの理由を解説します。
✓【目を合わせてくれない。なぜ私だけ…】職場での対処法５選！会社員を生き抜く術
✓genspark helpで迷った人へ｜ログイン・料金・使い方まで一気に解決
✓水色の保険証が恥ずかしい理由を言います。
記事作成にあたり参考にさせて頂いたサイト

各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
引用や参照の方法に不備、あるいはご不快に感じられる点がございましたら、お問い合わせフォームよりご連絡ください。
今後とも、どうぞよろしくお願いいたします。

AI 業務効率化 職場
ABOUT ME
カシワギ
『エグゼクティブワーク』編集長のカシワギです。 普段はITベンチャーで執行役員の40代男です。 元コンサルタントですが、今はテクノロジー企業で日々奮闘中。 仕事では厳しい顔をしていますが、家では小学生の子供2人のやんちゃなパパ。 休日はゴルフに行ったり、妻とワインを楽しんだり。
BLOG：https://min-biz.net/
当サイトについて
当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。 情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。 迅速に対応をさせていただきます。 その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応 することができますのでそちらもご協力いただけますと大変幸いでございます。 今後とも当サイトをよろしくお願いいたします。