はじめに

n8nワークフローがアイテムのリストを受け取ったとき — 例えばスプレッドシートから500行、APIから1,000件の連絡先など — すべてのアイテムを次のノードにそのまま送ると、レートリミット、タイムアウト、メモリスパイク、データベーステーブルのロックといった問題が発生する可能性があります。SplitInBatchesノードは、リストを小さなグループに分割し、一度に1バッチずつ解放することでこの問題を解決します。これにより下流のノードがグループ間で休憩できます。

これは制御されたコンベアベルトのようなものと考えてください：一度に1,000個の箱を作業者に投げる代わりに、50個ずつ供給するのです。

SplitInBatchesの仕組み

SplitInBatchesはデータソースと各アイテムを処理するノードの間に配置されます。最初の実行では最初のチャンク（設定可能なサイズ、デフォルトは1アイテム）を出力し、一時停止し、その後の実行で次のチャンクをリストが尽きるまで出力します。各バッチは同じ下流ブランチを通るため、通常はSet、HTTP Request、データベースノードと組み合わせます。

ノードには2つの重要な出力が存在します：「Done」は最後のバッチが解放された後に一度だけ発火します — 最終サマリーやクリーンアップステップに便利です — そして「Loop」は次のバッチを処理ブランチにフィードバックします。

基本設定

ノードを開き、Batch Sizeを下流サービスが処理できる数に設定します。1分あたり100リクエストに制限しているほとんどのHTTP APIでは、Batch Sizeを10、間に6秒のWaitノードを置く構成が効果的です。

{
  "node": "SplitInBatches",
  "parameters": {
    "batchSize": 10,
    "options": {}
  },
  "type": "n8n-nodes-base.splitInBatches"
}

「Loop」出力を作業用ノードに接続し、そのノードからSplitInBatchesへ戻りの配線をすることで次のバッチが解放されるようにします。「Done」出力は必要なサマリーステップに接続します。

実践例：連絡先を外部APIに送信する

CRMから200件の連絡先を取得し、それぞれをWebhookにPOSTする必要があるとします。バッチ処理を行わなければ、200リクエストを即座に発射し、おそらく429 Too Many Requestsエラーが発生するでしょう。

ワークフローは次のようになります：Cronトリガーが毎日起動し、HTTP Requestノードが連絡先を取得し、SplitInBatchesが10件ずつグループ化し、各バッチがループに入りWebhookをアイテムごとに呼び出し、Waitノードが6秒間一時停止し、制御がSplitInBatchesに戻って次のバッチを処理します。すべてのバッチが処理されると、「Done」ブランチが「Synced 200 contacts」をSlackにログとして記録します。

よくある間違い

ループ配線を戻し忘れることが最も多いエラーです — この接続がないと、ワークフローは最初のバッチの後に停止します。もう一つのよくあるミスとして、Waitノードをループブランチ内ではなくSplitInBatchesの後に配置してしまうことがあります。これではバッチ間でスロットリングが行われず、意味がありません。最後に、SplitInBatchesは実行ごとに状態を保持するため、新しいトリガー実行は毎回バッチ1から開始されます — 別々の実行にまたがって半分完了したバッチループを再開することはできません。

まとめ

SplitInBatchesは、下流サービスがリスト全体を一度に処理できない場合に使用する定番ノードです。対象APIのレートリミットに基づいて適切なBatch Sizeを設定し、必ずループ出力を戻りの配線し、ループ内のWaitノードと組み合わせてスロットリングに優しいペーシングを行い、「Done」ブランチを実行終了時の後処理に活用しましょう。

数百件を超えるリストや並列処理については、LoopノードやExecute Workflowトリガーを使ったサブワークフローを検討してください — これらはいずれも後ほどのレッスンで扱います。