n8nのメモリ不足エラー対処法アイキャッチ

ワークフローを実行したら突然「Execution stopped at this node（n8n may have run out of memory）」と表示され、困惑していませんか。

そこで今回は、n8nをセルフホストおよびCloudで大規模運用してきた経験をもとに、メモリ不足エラーの原因と具体的な解決方法を解説します！設定の見直しだけで直る場合も多いので、ぜひ最後まで読んで試してみてください！

この記事で分かること

  • n8nでメモリ不足エラーが発生する仕組みと主な原因
  • n8n Cloudとセルフホストでの原因切り分け方法
  • プラン変更・設計見直し・環境変数設定による4つの解決策

n8nでメモリ不足が起きる仕組み

n8nは、ノードごとに処理できるデータ量を制限していません。この仕様が「n8n メモリ不足」を招く根本原因です。

自由度が高い反面、大量データを扱うワークフローでは利用可能なメモリを超えることがあります。その結果、「n8n Execution stopped」というエラーが表示されます。

メモリを消費しやすい要因

  • 処理するJSONデータの量が多い（数千件以上のアイテムなど）
  • 画像やPDFなどのバイナリデータをそのまま扱っている（デフォルトではメモリ上に保持される仕様）
  • Code／Functionノードでの重い処理（配列のコピーやループ処理でメモリを多く消費）
  • 手動実行（フロントエンド表示用にデータを二重に保持するため）

特にCode／Functionノードは、標準ノードより柔軟な分メモリ消費が大きくなりがちです。また手動実行は自動実行より負荷が高い点も見落とされがちです。

原因を切り分ける2つのケース

メモリ不足エラーが出た場合、まず「Cloud」か「セルフホスト」かで対処法が異なります。以下のように切り分けて考えましょう。

項目n8n Cloudセルフホスト
メモリ上限プランごとに固定サーバー・コンテナの割り当てに依存
対処の起点プランのアップグレードインスタンスのリソース増強
設定変更不可（運営側の管理）NODE_OPTIONSで調整可能

n8n Cloudでプラン上限に達しているケース

n8n Cloudでは、契約プランごとにインスタンスへ割り当てられるRAM容量が固定されています。具体的には、TrialとStarterプランは320MiB、Pro-1（月1万実行まで）は640MiB、Pro-2（月5万実行まで）は1280MiB、Enterpriseは4096MiBが上限です。

320MiBや640MiBのプランでは、AIエージェントの応答や画像処理などメモリを多く使う処理を1つ実行するだけで上限に達することがあります。管理画面の「Usage」ページから、直近の実行でどれだけメモリを使用したかを確認できます。

使用率が慢性的に80%を超えている場合はアップグレードのサインですが、まずは後述する「Split In Batches」や「バイナリデータの外部化」で消費量そのものを減らせないか確認してから判断すると、無駄なコストを抑えられます。

セルフホストでインスタンスのメモリ割り当てが不足しているケース

セルフホストの場合、DockerコンテナやVPSに割り当てたメモリ量そのものが不足していることが多いです。特に1〜2GBメモリのVPSでは、Code ノードや画像処理を含むワークフローで容易に上限へ達します。

この場合、サーバーログに「Allocation failed - JavaScript heap out of memory」というエラーが出ることがあります。これは、n8nの内部で動くNode.jsのV8エンジンが確保できるヒープメモリ（デフォルトでは搭載RAMの一部のみ）の上限に達したサインです。

確認方法として、Dockerであれば以下のコマンドでコンテナのメモリ使用量をリアルタイム監視できます。

# ファイル名: check_memory.sh
docker stats n8n --no-stream

この数値が搭載RAMの上限付近に張り付いている場合、次章の設定変更で解消できる可能性が高いです。

解決する4つの方法

n8n Cloudのプランをアップグレードする判断基準

Usage画面でメモリ使用率が常時80％を超えている場合は、プランアップグレードを検討すべきサインです。実行頻度や同時実行数が増えている場合も同様です。

目安として、320MiB（Starter）から640MiB（Pro-1）へ上げると、単純計算でメモリ許容量が2倍になります。AIエージェントやHTTP Requestで大きなレスポンスを扱う場合は、1280MiB以上のPro-2プランが安全です。

ただしアップグレードだけで解決しないケースもあるため、次項以降の設計変更（バッチ分割・標準ノード化）を先に試し、それでも不足する場合にプラン変更を行うのが費用対効果の高い順序です。

大量データを小さいチャンクに分割して処理する設計

効果が高いのが、Loop Over Items（旧Split In Batches）ノードを使ったチャンク分割処理です。1万件のデータを一度に処理せず、100〜200件ずつのバッチに分けて処理することで、各実行時のメモリ使用量を大幅に抑えられます。

具体的な設計手順は次の通りです。

  • Loop Over Itemsノードを配置し、Batch Sizeを100〜200に設定する
  • バッチ内の処理が終わるたびに、後続ノードで不要になったデータをSetノードで削除する
  • 重い処理（AI呼び出し、画像処理など）はExecute Workflowノードでサブワークフロー化し、親ワークフローには結果のみを戻す

サブワークフロー化すると、親ワークフローは処理途中の大量データを保持し続ける必要がなくなるため、メモリ使用量のピークを大きく下げられます。

Code／FunctionノードをFilter・Aggregate等の標準ノードに置き換える方法

Code ノードとFunctionノードは、配列全体をコピーしたりループ処理を行ったりする関係で、n8nの中でも特にメモリ消費が大きいノードです。

例えば、以下のようなCode ノードの処理は、標準ノードに置き換えることでメモリ消費を抑えられます。

// 置き換え前：Code ノードでの絞り込み処理
return items.filter(item => item.json.status === 'active');

この処理はFilterノードの条件式「{{ $json.status }} = active」で完全に代替できます。同様に、合計・平均・件数集計はAggregateノード、条件分岐はIFノードやSwitchノードに置き換え可能です。標準ノードは内部処理が最適化されているため、同じ結果でもメモリ消費を抑えられます。

どうしてもCode ノードが必要な場合は、Loop Over Itemsで事前にデータ量を絞ってから渡すことで負荷を軽減できます。

セルフホストでNODE_OPTIONSの--max-old-space-sizeを設定する手順

セルフホストでJavaScriptヒープ不足が疑われる場合、NODE_OPTIONS環境変数でV8エンジンのヒープサイズを拡張します。手順は以下の通りです。

手順1：現在のサーバー搭載メモリを確認する

# ファイル名: check_ram.sh
free -h

手順2：搭載RAMの70〜80%程度をヒープサイズとして.envに設定する（例：8GB搭載サーバーの場合）

# ファイル名: .env
NODE_OPTIONS=--max-old-space-size=6144

手順3：Docker運用の場合はdocker-compose.ymlに直接指定する

# ファイル名: docker-compose.yml
services:
  n8n:
    environment:
      - NODE_OPTIONS=--max-old-space-size=6144
    deploy:
      resources:
        limits:
          memory: 8g

手順4：バイナリデータをメモリではなくディスクに保存する設定も併用する

# ファイル名: .env
N8N_DEFAULT_BINARY_DATA_MODE=filesystem

この設定により、画像やPDFなどのバイナリデータがメモリではなくディスク（デフォルトでは/home/node/.n8n/binaryData）に保存されるようになり、メモリ消費を大幅に削減できます。設定後はコンテナやプロセスの再起動が必要です。

メモリ不足を未然に防ぐワークフロー設計

エラーが出てから対処するより、設計段階でメモリ消費を意識することが最も効果的です。不要なフィールドは早い段階でSetノードなどにより削除し、後続ノードへ渡すデータ量を最小限に保ちましょう。

具体的には、以下の3点をチェックリストとして運用に組み込むことをおすすめします。

  • バイナリデータを扱うワークフローでは、必ずN8N_DEFAULT_BINARY_DATA_MODE=filesystemを設定する
  • 1,000件を超えるデータ処理には、必ずLoop Over Itemsでバッチ分割を組み込む
  • 手動実行はテスト時のみにとどめ、本番運用はWebhookやスケジュールトリガーによる自動実行に統一する

この3点を徹底するだけで、多くの「n8n Execution stopped」エラーは未然に防げます。

よくある質問

Q1. n8n メモリ不足エラーは自動で復旧しますか？

Docker版やn8n Cloudでは、メモリ不足を検知すると自動的にインスタンスが再起動します。npmで直接起動している場合は、手動でのプロセス再起動（n8n start）が必要になることがあります。

Q2. n8n Execution stoppedが出てもワークフローの一部は保存されますか？

エラー発生前までの実行結果は、実行履歴（Executions）に部分的に残ることがあります。ただし、必ずしも全データが保存されるとは限らないため、重要な処理はサブワークフロー化して結果を都度別途保存する設計が安全です。

Q3. n8n Code ノードが重い場合、代替手段はありますか？

単純なフィルタリングや集計であれば、Filter・Aggregate・IFなどの標準ノードで代替可能です。どうしてもコードが必要な場合は、Loop Over Itemsで処理対象を事前に絞り込むことで負荷を軽減できます。

Q4. セルフホストでどのくらいのメモリを割り当てるべきですか？

目安として、軽量なワークフローなら2GB、Code ノードやAIエージェントを多用する場合は8GB以上を推奨します。NODE_OPTIONSのヒープサイズは搭載RAMの70〜80%程度に設定するとバランスが取れます。

まとめ：n8nのメモリ不足エラーを解消する

今回は、n8nの「Execution stopped（out of memory）」エラーの原因究明と解決策の整理に取り組みました。

エラーメッセージを見ただけで慌てず、Cloudかセルフホストかを切り分け、バッチ分割・標準ノード化・環境変数の調整を組み合わせることで、多くのケースは解消できます。

まずは小さなワークフローから、バッチ分割やNODE_OPTIONSの設定を試してみてください！

参考リンク