n8n「実行データが大きすぎます」エラーの解決：セルフホスト環境の修正ガイド

n8nをセルフホストすると、ワークフローを回数制限なく実行でき、環境を完全に管理できます。ただし、大規模なデータセットを扱う複雑なワークフローでは、自分でサーバー設定を修正しなければならない厄介なエラーが発生することがあります。個別のノードをテストする際に「Please execute the whole workflow, rather than just the node. (Existing execution data is too large.)」と表示されたら、ペイロードサイズの上限に達しています。この記事では、原因を特定し、設定を修正・最適化して、本番運用に対応するn8n環境を整える方法を紹介します。

問題：ワークフローをテストできなくなる

n8nインスタンスを構築し、安定したWebhook機能を設定した後、ファイル、大きなAPIレスポンス、データセットを処理する高度なワークフローを作り始めると、この問題に遭遇することがあります。ワークフロー全体を実行すると正常に動くのに、1つのノードだけをテストしたり、部分実行を試みたりすると、n8nがエラーを表示します。

これは、n8nが部分的な実行データに対して16MBのデフォルト制限を持っているために発生します。この制限はシンプルなワークフローには十分ですが、実際のデータ量を処理し始めるとすぐにボトルネックになります。

このガイドで解決すること

このガイドに沿って設定すると、次の状態を実現できます。

✅ ペイロードサイズの上限を16MBから256MBまたは任意の値に引き上げ
✅ 大規模なデータセットを扱う複雑なワークフローの部分実行
✅ サーバーのRAM容量を考慮した適切なリソース割り当て
✅ メモリ使用量を継続的に追跡する監視環境
✅ ファイル処理ワークフローに対応した本番環境の設定
✅ 設定変更時のバックアップとロールバック手順

前提条件

正常に動作するn8n環境（できれば当社のHetzner構築ガイドに沿って構築したもの）
Dockerコンテナで実行中のn8n
サーバーへのSSHアクセス
Docker Composeの環境変数に関する基本的な知識
最低3GBの利用可能RAM（256MBペイロード制限に推奨）

根本原因の理解

セルフホスト型n8nにペイロード制限がある理由

部分実行（個別ノードのテスト）を行う際、n8nはワークフローの状態とデータをシリアライズしてバックエンドに送信する必要があります。これには以下が含まれます：

前のノードからのすべての入力データ
ワークフローロジックとノード設定
実行コンテキストと変数
バイナリデータとファイルの内容

初期設定のN8N_PAYLOAD_SIZE_MAX=16（16MiB、値の単位はMiB）は、一般的なAPIレスポンスや単純なデータ処理を想定しています。しかし、現在のワークフローでは、次のような処理を行うことも多くあります。

❌ 16MBを超えやすい処理：

ファイルのアップロードと処理（PDF、画像、スプレッドシート）
データソースからの大規模なAPIレスポンス
一括データ変換
処理を進めるうちにデータが蓄積する複数ステップのワークフロー

✅ 修正後に可能になること：

大規模なデータセットを使った部分実行
ファイル処理ワークフローのテスト
複雑なデータ変換のノード単位でのデバッグ

不足している設定

解決の鍵は、リクエストのペイロードサイズの上限をMiB単位で設定する環境変数N8N_PAYLOAD_SIZE_MAXです。部分実行のためにエディターが送信するデータも対象です。リクエストが上限を超えると、n8nはHTTP 413を返し、エディターにこのエラーが表示されます。n8n Cloudではn8nがこの設定を管理します。セルフホスト環境では控えめな初期値の16MiBが使われます。

ステップ1：現在のセットアップを診断

サーバーリソースの確認

ペイロードの上限を引き上げる前に、サーバーがより多くのメモリ割り当てに対応できることを確認します。

# Check available memory
free -h

# Check current Docker container memory usage
docker stats --no-stream | grep n8n

# Check total system resources
htop

メモリ要件：

64MBペイロード制限：最低1GBの利用可能RAM
128MBペイロード制限：最低2GBの利用可能RAM
256MBペイロード制限：最低3GBの利用可能RAM

現在の制限の確認

N8N_PAYLOAD_SIZE_MAXが設定されているか確認します：

# Navigate to your n8n directory (adjust path as needed)
cd /opt/n8n

# Check current environment variables
cat docker-compose.yml | grep -A 30 "environment:"

# Look for payload size configuration
grep "N8N_PAYLOAD_SIZE_MAX" docker-compose.yml || echo "Not configured - using 16MB default"

エラーの再現テスト

問題を再現するためのテストワークフローを作成します：

n8nインターフェースを開く
大規模なデータセットを使うワークフローを作成する（例：16MBを超えるレスポンスを返すAPIへのHTTP Request）
下流の1つのノードだけを実行してみる
「Existing execution data is too large」エラーが表示されることを確認する

ステップ2：主な問題を修正し、ペイロードの上限を引き上げる

単一のn8nインスタンスの場合

n8nを1つだけ運用している場合は、次の手順で設定します。

cd /opt/n8n

# Create backup first
cp docker-compose.yml docker-compose.yml.backup_$(date +%Y%m%d_%H%M)

# Edit the configuration
nano docker-compose.yml

既存の設定にN8N_PAYLOAD_SIZE_MAX環境変数を追加します：

version: '3'

services:
  n8n:
    image: n8nio/n8n:latest
    restart: always
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - NODE_ENV=production
      - N8N_PROTOCOL=https
      - N8N_PORT=5678
      - N8N_EDITOR_BASE_URL=https://n8n.yourdomain.com
      - N8N_EMAIL_MODE=smtp
      - N8N_SMTP_HOST=mailserver
      - N8N_SMTP_PORT=25
      - N8N_SMTP_SSL=false
      - N8N_SMTP_USER=
      - N8N_SMTP_PASS=
      - [email protected]
      - N8N_TRUST_PROXY_HEADER=true
      - N8N_RUNNERS_ENABLED=true
      - WEBHOOK_URL=https://n8n.yourdomain.com
      # ADD THIS LINE - Increases payload limit to 256MB (value in MiB)
      - N8N_PAYLOAD_SIZE_MAX=256
    volumes:
      - ./data:/home/node/.n8n
    networks:
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.n8n.rule=Host(`n8n.yourdomain.com`)"
      - "traefik.http.routers.n8n.entrypoints=https"
      - "traefik.http.routers.n8n.tls.certresolver=letsencrypt"
      - "traefik.http.services.n8n.loadbalancer.server.port=5678"

networks:
  proxy:
    external: true

複数のn8nインスタンスの場合

複数のn8nインスタンスを運用している場合は、それぞれの設定を更新します。

# First instance
cd /opt/n8n
cp docker-compose.yml docker-compose.yml.backup_$(date +%Y%m%d_%H%M)
sed -i '/N8N_RUNNERS_ENABLED=true/a\      - N8N_PAYLOAD_SIZE_MAX=256' docker-compose.yml

# Second instance (adjust path as needed)
cd /opt/n8n-team2
cp docker-compose.yml docker-compose.yml.backup_$(date +%Y%m%d_%H%M)
sed -i '/N8N_RUNNERS_ENABLED=true/a\      - N8N_PAYLOAD_SIZE_MAX=256' docker-compose.yml

コンテナの再起動

変更を適用します：

# For single instance
cd /opt/n8n
docker compose down && docker compose up -d

# For multiple instances
cd /opt/n8n
docker compose down && docker compose up -d
cd /opt/n8n-team2
docker compose down && docker compose up -d

# Verify containers are running
docker ps | grep n8n

ステップ3：修正の検証

コンテナログの確認

コンテナが正常に起動したことを確認します：

# Check main instance logs (adjust container name as needed)
docker logs n8n-n8n-1 --tail 20

# Check for any startup errors
docker logs n8n-n8n-1 | grep -i "error\|failed\|warning"

ペイロードの上限変更をテストする

エラーが出ていたテスト用ワークフローに戻ります。

大規模なデータセットを使うワークフローを開く
下流の単一ノードを実行してみる
「Existing execution data is too large」エラーが解消されたことを確認する
部分実行が正しく動作することを確認

メモリ使用量の監視

変更後はシステムリソースの使用状況を監視します。

# Monitor memory usage over time
watch -n 5 'free -h && echo "--- Docker Stats ---" && docker stats --no-stream | grep n8n'

ステップ4：サーバーに合わせた最適化

サーバーRAM別の推奨ペイロードサイズ

ハードウェアに適したペイロードサイズを選択します：

# For servers with 2GB RAM or less
- N8N_PAYLOAD_SIZE_MAX=64   # 64 MiB

# For servers with 4GB RAM  
- N8N_PAYLOAD_SIZE_MAX=128  # 128 MiB

# For servers with 8GB+ RAM
- N8N_PAYLOAD_SIZE_MAX=256  # 256 MiB

# For high-performance servers with 16GB+ RAM
- N8N_PAYLOAD_SIZE_MAX=512  # 512 MiB

メモリ使用量の計算

メモリ要件を見積もります：

# Calculate safe payload size (should be <20% of available RAM)
echo "Available RAM: $(free -h | awk 'NR==2{print $7}')"
echo "Current payload limit: $(docker exec n8n-n8n-1 env | grep N8N_PAYLOAD_SIZE_MAX || echo '16 (default, MiB)')"

# Monitor actual usage during large workflow executions
docker stats n8n-n8n-1 | grep -E "MEM|n8n"

よくある問題のトラブルシューティング

問題：設定変更後にコンテナが起動しない

症状：

起動直後にコンテナが終了
DockerでのOOMKilledステータス
サーバーが応答しなくなる

解決策：

# Check container exit reason
docker logs n8n-n8n-1

# Reduce payload size if out of memory
cd /opt/n8n
sed -i 's/N8N_PAYLOAD_SIZE_MAX=256/N8N_PAYLOAD_SIZE_MAX=64/' docker-compose.yml
docker compose up -d

問題：ペイロードサイズのエラーが続く

症状：

設定変更後もエラーが続く
環境変数が有効になっていないように見える

解決策：

# Verify environment variable is set correctly
docker exec n8n-n8n-1 env | grep N8N_PAYLOAD_SIZE_MAX

# If missing, recreate container with force
docker compose down
docker compose up -d --force-recreate

# Check if the value is being read
docker logs n8n-n8n-1 | grep -i payload

問題：サーバーの性能が低下する

症状：

応答時間が長くなる
メモリ使用量が多い
スワップファイルの使用量の増加

解決策：

# Monitor system performance
vmstat 1 5
iostat -x 1 5

# Check swap usage
swapon --show

# Reduce payload size if needed
# From 256MB to 128MB
sed -i 's/N8N_PAYLOAD_SIZE_MAX=256/N8N_PAYLOAD_SIZE_MAX=128/' docker-compose.yml
docker compose down && docker compose up -d

高度な設定

ペイロードの上限ごとにインスタンスを分ける

上限はワークフローごとではなく、n8nインスタンスごとに適用されます。高度な運用では、上限の異なる複数のインスタンスを使う構成を検討します。

# High-capacity instance for file processing
n8n-files:
  image: n8nio/n8n:latest
  environment:
    - N8N_PAYLOAD_SIZE_MAX=512  # 512 MiB
    - N8N_HOST=files.yourdomain.com

# Standard instance for regular workflows  
n8n-standard:
  image: n8nio/n8n:latest
  environment:
    - N8N_PAYLOAD_SIZE_MAX=64   # 64 MiB
    - N8N_HOST=workflows.yourdomain.com

コンテナリソース制限

システム過負荷を防ぐために明示的なメモリ制限を設定します：

services:
  n8n:
    image: n8nio/n8n:latest
    environment:
      - N8N_PAYLOAD_SIZE_MAX=256
    deploy:
      resources:
        limits:
          memory: 2G      # Maximum memory usage
        reservations:
          memory: 1G      # Soft reservation, not a hard guarantee
    # ... rest of configuration

ペイロード使用量の監視

n8nはペイロードサイズを直接報告しないため、代わりにコンテナのメモリ使用量に対してアラートを設定します。このスクリプトは、docker statsがメモリをMiB単位で報告することを前提としています。

#!/bin/bash
# Create monitoring script: /opt/monitor-payload.sh

CONTAINER_NAME="n8n-n8n-1"
MEMORY_LIMIT_MB=1500  # Alert if memory usage exceeds this

CURRENT_MEMORY=$(docker stats --no-stream --format "{{.MemUsage}}" $CONTAINER_NAME | cut -d'/' -f1 | sed 's/MiB//')

if (( $(echo "$CURRENT_MEMORY > $MEMORY_LIMIT_MB" | bc -l) )); then
    echo "WARNING: n8n memory usage high: ${CURRENT_MEMORY}MB" | logger
    # Add notification logic (email, Slack, etc.)
fi

セキュリティの考慮事項

リソース消費型DoSへの対策

ペイロードの上限を大きくすると、悪用される可能性があります。リバースプロキシでリクエストサイズを制限してください。ただし、その上限（バイト単位）はN8N_PAYLOAD_SIZE_MAXが定めるサイズ以上にします。そうしないと、大きなリクエストがプロキシによってHTTP 413で拒否されます。

# Add to Traefik labels for request size limiting
labels:
  - "traefik.http.middlewares.payload-limit.buffering.maxRequestBodyBytes=268435456"  # 256MB max request, matches N8N_PAYLOAD_SIZE_MAX
  - "traefik.http.routers.n8n.middlewares=payload-limit"

ワークフロー固有の制限

ワークフローベースの制限を検討します：

# Monitor workflows with large payloads
docker exec n8n-n8n-1 n8n execute --help

# Log large executions
(crontab -l 2>/dev/null; echo "*/10 * * * * docker logs n8n-n8n-1 | grep -i 'payload\|memory' >> /var/log/n8n-payload.log") | crontab -

パフォーマンス最適化

バイナリデータの処理

ファイル処理ワークフローでは、バイナリデータの保存方法を最適化します。なお、N8N_BINARY_DATA_TTLはn8n 1.9.0以降は効果がありません。n8nは実行データを整理・削除する際にバイナリデータも削除します。

environment:
  - N8N_PAYLOAD_SIZE_MAX=256
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem  # Store files on disk, not in memory
  - N8N_BINARY_DATA_TTL=1440                 # Clean up files after 24 hours

データベース最適化

大きなペイロードはデータベースのパフォーマンスに影響を与える可能性があります：

# Monitor database size growth
du -sh /opt/n8n/data/

# Clean up old executions more aggressively
# Add to docker-compose.yml environment:
# - EXECUTIONS_DATA_MAX_AGE=168  # 7 days instead of default 14
# - EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000

バックアップと復旧

設定のバックアップ方針

変更を行う前に必ずバックアップします：

#!/bin/bash
# Create backup script: /opt/backup-n8n-config.sh

BACKUP_DIR="/opt/backups/n8n-configs"
mkdir -p $BACKUP_DIR

# Backup all n8n docker-compose files
for instance in n8n n8n-team2; do
    if [ -d "/opt/$instance" ]; then
        cp "/opt/$instance/docker-compose.yml" "$BACKUP_DIR/${instance}-$(date +%Y%m%d_%H%M).yml"
    fi
done

# Delete backups older than 10 days
find $BACKUP_DIR -name "*.yml" -mtime +10 -delete

迅速なロールバック手順

変更を元に戻す必要がある場合：

# List available backups
ls -la /opt/n8n/docker-compose.yml.backup_*

# Restore specific backup
cd /opt/n8n
cp docker-compose.yml.backup_20241206_1430 docker-compose.yml
docker compose down && docker compose up -d

コストとパフォーマンスへの影響

メモリコスト分析

ペイロード制限の増加はサーバーコストに影響します：

Server RAM Requirements:
- 16MB limit (default): 1GB RAM sufficient
- 64MB limit: 2GB RAM recommended  
- 128MB limit: 4GB RAM recommended
- 256MB limit: 8GB RAM recommended
- 512MB limit: 16GB RAM recommended

Hetzner Cloud Costs (legacy plans, deprecated by Hetzner in June 2024; check current pricing):
- CX11 (2GB RAM): €4.51/month
- CX21 (4GB RAM): €8.46/month  
- CX31 (8GB RAM): €16.07/month

パフォーマンスのメリット

ペイロードの上限を引き上げると、次の処理が可能になります。

ファイル処理：ドキュメント、画像、動画の処理
データ統合：大規模なAPIレスポンスの処理
一括操作：データセットの効率的な変換
デバッグ：複雑なワークフローのノードごとのテスト

まとめ

N8N_PAYLOAD_SIZE_MAXを初期値の16MBからサーバーに適した値へ引き上げることで、これまで部分実行ではできなかった高度なワークフロー処理が可能になります。今回設定した256MBの上限は、サーバーの安定性を保ちつつ、実際の用途の大半に対応します。

この設定の主な利点

生産性：サイズ制限を大幅に減らして、複雑なワークフローをノードごとにデバッグ
処理能力：ファイルと大規模なデータセットを効率的に処理
費用対効果：4GB RAMのサーバーで128MBの上限を月額10ユーロ未満で運用（上記の旧Hetzner CX21プランの料金）
信頼性：適切なリソース管理を備え、本番環境で検証された設定
拡張性：ワークフローが複雑になるにつれて上限を容易に調整

この設定は、当社の最初のn8n構築ガイドとWebhookのトラブルシューティングガイドを基に、企業向けのデータ処理ワークフローに対応する、本番運用可能な自動化プラットフォームを構築するものです。

大量のデータや特殊なペイロード要件がある場合は、用途に合わせた最適化と適切なサーバーリソースの配分について、自動化の専門家への相談を検討してください。

tvaについて

tvaは、データベースシステム、クラウド環境、グローバルなサプライチェーンのインフラを総合的に管理します。体系的なアプローチで厳格なセキュリティ対策と性能最適化を組み合わせ、戦略的なアドバイザリーサービスを通じてデジタル機能と物理的資産を精密に調整します。すべての支援案件で、最高水準の業務品質とコンプライアンスを維持します。

当社のサービスや、その他の自動化チュートリアルの詳細は、tva.sgをご覧ください。

問題：ワークフローをテストできなくなる

このガイドで解決すること

前提条件

根本原因の理解

セルフホスト型n8nにペイロード制限がある理由

不足している設定

ステップ1：現在のセットアップを診断

サーバーリソースの確認

現在の制限の確認

エラーの再現テスト

ステップ2：主な問題を修正し、ペイロードの上限を引き上げる

単一のn8nインスタンスの場合

複数のn8nインスタンスの場合

コンテナの再起動

ステップ3：修正の検証

コンテナログの確認

ペイロードの上限変更をテストする

メモリ使用量の監視

ステップ4：サーバーに合わせた最適化

サーバーRAM別の推奨ペイロードサイズ

メモリ使用量の計算

よくある問題のトラブルシューティング

問題：設定変更後にコンテナが起動しない

問題：ペイロードサイズのエラーが続く

問題：サーバーの性能が低下する

高度な設定

ペイロードの上限ごとにインスタンスを分ける

コンテナリソース制限

ペイロード使用量の監視

セキュリティの考慮事項

リソース消費型DoSへの対策

ワークフロー固有の制限

パフォーマンス最適化

バイナリデータの処理

データベース最適化

バックアップと復旧

設定のバックアップ方針

迅速なロールバック手順

コストとパフォーマンスへの影響

メモリコスト分析

パフォーマンスのメリット

まとめ

この設定の主な利点

tvaについて

関連記事