セルフホスト型n8n 2.x：実行データの上限を診断し、ペイロードを安全に引き上げる

ベンダーの公式文書をもとに、運用管理、移行の判断、検証可能なリリース基準を具体化する、本番運用向けの最新の補足記事です。

2026年に変わったこと

運用上の境界条件が変化したため、このテーマを改めて検討します。長期的に有効な原則は残る一方、現行バージョンでは過去の簡便な方法の一部が不十分、あるいは危険になっています。本稿は2026年7月14日時点で入手できる公式文書を起点に、事実と自社環境での判断を分け、設定変更をすべて管理下で行う本番環境への介入として扱います。

この更新版の使い方

まず一次資料を確認し、実際に稼働しているバージョンを記録し、設定を変える前に観測可能な成果を定義します。実際の運用を代表する環境で、最小かつ元に戻せる変更を試します。コマンドが成功しただけでは受け入れ基準を満たしません。サービスの健全性、データの完全性、レイテンシー、セキュリティ境界、ロールバック時間まで確認します。旧稿の診断手順で現在も有効な部分は運用基盤として残しますが、バージョン依存の例は必ず現行文書と照合します。

リリース前に、設定差分、少なくとも1回は復元を確認したバックアップまたはスナップショット、変更を元に戻すためのコマンドを記録します。最初の本番運用期間を監視する担当者と、想定した指標が悪化した場合にエスカレーションを承認する担当者を別々に決めます。アラートは、発報した構成要素だけでなく、利用者にどのようなリスクがあるかを示す必要があります。確認期間には、エラー率、キューの深さ、リソースの飽和、処理のレイテンシー、データの完全性を、合意したベースラインと比較します。平均値だけでなく分布の裾も確認します。平均が安定していても、少数ながら重要な処理の失敗が隠れている場合があるためです。遅延したジョブ、再試行、定期実行タスク、下流へのエクスポートが完了してから変更を完了扱いにします。復旧中の手作業はすべて記録します。文書化されていない復旧操作が必要なら、運用手順書はまだ不完全だという証拠です。このリリース管理によって、次のアップグレードで再利用できる証跡が残り、同じ依存関係をチームが調べ直さずに済みます。

運用の基盤

n8nのセルフホスティングは無制限のワークフロー実行と完全な制御を提供しますが、大規模なデータセットを扱う複雑なワークフローは、自身のサーバー設定で対処する必要のある厄介なエラーを引き起こす可能性があります。個別のノードをテストしようとして「Please execute the whole workflow, rather than just the node. (Existing execution data is too large.)」が表示される場合、ペイロードサイズの制限に達しています。この制限を特定、修正、最適化して本番運用に対応できるn8n環境にする方法を紹介します。

問題：ワークフローのテストができなくなる場合

n8nインスタンスのセットアップに成功し、堅牢なWebhook機能を設定しましたが、ファイル、大規模なAPIレスポンス、またはデータセットを処理するより高度なワークフローを構築し始めました。完全なワークフローを実行すると問題なく動作しますが、単一のノードをテストしたり部分的な実行を行おうとした瞬間に、n8nがエラーメッセージを表示します。

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

このガイドで修正する内容

このガイドを終えると、以下を実現できます：

✅ ペイロードサイズ制限を16MBから256MBまたはカスタム値に増加

✅ 大規模なデータセットを持つ複雑なワークフローの部分実行が動作

✅ サーバーのRAM制限を考慮した適切なリソース割り当て

✅ メモリ使用量の推移を追跡する監視設定

✅ ファイル処理ワークフローに対応する本番運用向けの設定

✅ 設定変更のためのバックアップとロールバック手順

前提条件

稼働中のn8n環境（当社のHetzner構築ガイドに沿った環境を推奨）

Dockerコンテナで実行中のn8n

サーバーへのSSHアクセス

Docker Compose環境変数の基本的な理解

空きRAMが最低3GB（256MBペイロード制限に推奨）

根本原因の理解

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

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

前のノードからのすべての入力データ

ワークフローロジックとノード設定

実行コンテキストと変数

バイナリデータとファイルの内容

デフォルトのN8N_PAYLOAD_SIZE_MAX=16（16 MiB。値の単位はMiB）は、一般的なAPIレスポンスとシンプルなデータ処理向けに設計されています。しかし、現代のワークフローはしばしば以下を処理します：

❌ 16MBを超える一般的なシナリオ：

ファイルのアップロードと処理（PDF、画像、スプレッドシート）

データソースからの大規模なAPIレスポンス

一括データ変換

複数の段階でデータが蓄積するワークフロー

✅ 修正後にできること：

大規模なデータセットでの部分実行が動作

ファイル処理ワークフローがテスト可能に

複雑なデータ変換をノードごとにデバッグ可能

不足している設定

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

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

サーバーリソースの確認

ペイロード制限を増やす前に、サーバーがより大きなメモリ割り当てを処理できることを確認します：

メモリ要件：

64MBペイロード制限：空きRAMが最低1GB

128MBペイロード制限：空きRAMが最低2GB

256MBペイロード制限：空きRAMが最低3GB

現在の制限の確認

ComposeファイルでN8N_PAYLOAD_SIZE_MAXが設定されているか確認します。未設定の場合、n8nはデフォルト値の16 MiBを使用します。

エラー条件のテスト

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

n8nインターフェースを開く

大規模なデータセットを扱うワークフローを作成する（例：16MBを超えるデータを返すAPIへのHTTPリクエスト）

下流の1つのノードだけを実行してみる

「Existing execution data is too large」エラーが表示されることを確認

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

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

n8nを単一の環境にインストールしている場合は、まずdocker-compose.ymlをバックアップしてから編集します。

既存の設定にN8N_PAYLOAD_SIZE_MAX環境変数を追加します。値の単位はMiBなので、N8N_PAYLOAD_SIZE_MAX=256と設定すると上限は256 MiBになります。

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

複数のn8nインスタンスを実行している場合は、それぞれを更新します。上限はインスタンスごとに適用されます。

コンテナの再起動

docker compose downとdocker compose up -dでコンテナを再作成し、変更を適用します。docker compose restartでは変更した環境変数の値は反映されません。

ステップ3：修正の検証

コンテナログの確認

コンテナのログにエラーがないか調べ、コンテナが正常に起動したことを確認します。

ペイロードサイズ増加のテスト

失敗していたテストワークフローに戻ります：

大規模データセットを持つワークフローを開く

下流の単一ノードを実行してみる

「Existing execution data is too large」エラーが解消されたことを確認

部分実行が正しく動作することを確認

メモリ使用量の監視

変更後は、free -hやdocker statsなどでシステムリソースを監視します。

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

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

ハードウェアに適したペイロードサイズを選択します。初期設定の目安は、RAMが2GB以下のサーバーでは64 MiB、4GBでは128 MiB、8GBでは256 MiB、16GB以上では512 MiBです。

メモリ使用量の計算

メモリ要件を見積もります。ペイロード上限は利用可能なRAMの20%未満に抑え、大規模なワークフローの実行中に実際のメモリ使用量を確認します。

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

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

症状：

コンテナが起動直後に終了する

Dockerで「OOMKilled」状態になる

サーバーが応答しなくなる

対処方法：コンテナのログで終了理由を確認します。メモリ不足で終了した場合は、N8N_PAYLOAD_SIZE_MAXを引き下げ（例：256から64）、再度起動します。

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

症状：

設定変更後もエラーが解消しない

環境変数が反映されていないように見える

対処方法：docker execとenvでコンテナ内の値を確認します。設定がない場合は、docker compose up -d --force-recreateでコンテナを再作成します。

問題：サーバーの性能低下

症状：

応答時間が長くなる

メモリ使用量が多い

スワップファイルの使用量が増える

対処方法：メモリ、ディスクI/O、スワップの使用状況を確認します。必要に応じてN8N_PAYLOAD_SIZE_MAXを引き下げ（例：256から128）、コンテナを再作成します。

高度な設定

ペイロードサイズ別にインスタンスを分離

上限はワークフローごとではなく、n8nインスタンスごとに適用されます。高度な用途では、ファイル処理向けの大容量インスタンスと通常のワークフロー向けの標準インスタンスなど、上限の異なるインスタンスの分離を検討します。

コンテナのリソース制限

システムの過負荷を防ぐため、Composeのdeploy.resourcesセクションでメモリ上限を明示的に設定します。メモリ予約はソフトリミットであり、保証ではありません。

ペイロード使用状況の監視

n8nはペイロードサイズを直接報告しないため、代わりにコンテナのメモリ使用量に対してアラートを設定します。例えば、docker statsの出力を読み取るスクリプトを使用します。

セキュリティ上の考慮事項

リソース消費を狙うDoSへの対策

大きなペイロード上限は悪用される可能性があります。リバースプロキシでリクエストサイズを制限し、正当なリクエストがHTTP 413で拒否されないよう、その上限をN8N_PAYLOAD_SIZE_MAX以上に設定します。

ワークフローごとの制限

大きな実行データを生成するワークフローをログに記録するなど、ワークフロー単位の制限を検討します。

性能の最適化

バイナリデータの扱い

ファイル処理ワークフローでは、N8N_DEFAULT_BINARY_DATA_MODE=filesystemを設定し、バイナリデータをメモリではなくディスクに保存します。n8nはキューモードでfilesystemモードをサポートしていません。キューモードでは、ドキュメントでdatabaseモードが推奨されています。

データベースの最適化

大きなペイロードはデータベースの性能に影響することがあります。データベースの増大を監視し、EXECUTIONS_DATA_MAX_AGEとEXECUTIONS_DATA_PRUNE_MAX_COUNTで古い実行データをより積極的に削除します。

バックアップと復旧

設定のバックアップ方針

変更前には必ずdocker-compose.ymlをバックアップし、ファイル名にタイムスタンプを含めます。

迅速なロールバック手順

変更を取り消す必要がある場合は、特定のバックアップファイルを復元してから、docker compose downとdocker compose up -dを実行します。

費用と性能への影響

メモリコストの分析

ペイロード上限を引き上げると必要なRAMが増えるため、サーバー費用に影響します。

性能面の利点

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

ファイル処理：文書、画像、動画の処理

データ統合：大規模なAPIレスポンスの処理

一括操作：データセットの効率的な変換

デバッグ：複雑なワークフローのノードごとのテスト

まとめ

N8N_PAYLOAD_SIZE_MAXをデフォルトの16MBからサーバーに適した値に引き上げることで、部分実行では以前不可能だった強力なワークフロー機能が実現されます。設定した256MBの上限は、サーバーの安定性を維持しながら、実務でよくある状況の大部分に対応できます。

この設定の主な利点

生産性：サイズ制限を大幅に減らし、複雑なワークフローをノードごとにデバッグ

処理能力：ファイルと大規模データセットを効率的に処理

コスト効率：控えめな構成のセルフホスト型サーバーで、より大きなデータセットを処理

信頼性：適切なリソース管理を備えた、本番環境で検証済みの設定

拡張性：ワークフローが複雑になるにつれて上限を容易に調整

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

大量のデータや特殊なペイロード要件を扱う場合は、用途に合った最適化とサーバーリソースの適切な配分について、自動化の専門家にご相談ください。

設定作業から運用判断へ

実務上の問いは、プラットフォームを設定できるかどうかではありません。チームが責任の所在を説明し、構成のずれを検出し、場当たり的な対応なしに復旧し、狙った成果を変更によって改善できたと示せるかです。そのため、各変更に責任者、ベースライン、ロールバック手順、確認期間を組み合わせます。これにより、単発の修正が運用能力になります。本番環境での変更記録には、変更の理由、確認した証拠、正確な対象範囲、停止または取り消しを行う権限を持つ担当者を含めます。リリース後は、合意した指標をベースラインと比較し、結果を変更記録とともに保存します。期待した改善がなければ、ロールバックも妥当な結果であり、失敗ではありません。この運用管理は、個々の設定値よりも重要です。同じ記録が次の担当者に信頼できる出発点を与え、その後の最適化を、新たな推測ではなく測定に基づく判断に変えます。