はじめに
こんにちは！データフローのオーケストレーター、シニアエンジニアです。

第3回までで、私たちはAPIを介して外部の世界と繋がり、貴重なデータをワークフローに引き込む術を学びました。しかし、ここで新たな、そして非常に現実的な課題が立ちはだかります。

「APIが、1個ではなく100個のデータを返してきた…！」

新着ニュース10件、今月の新規顧客リスト50人、ECサイトの注文履歴200件…。データは単体ではなく、大群（＝複数アイテム）で押し寄せてくるのが常です。このアイテムの洪水に、あなたはどう立ち向かいますか？

100個のアイテム、それぞれに同じ処理を適用したい

各アイテムから、本当に必要な情報だけを抜き出して整形したい

最終的に、100個のバラバラな情報を1つのレポートにまとめたい

今回のテーマは、この**「複数アイテムの処理（ループ）」と「高度なデータ加工」**です。n8nが裏側でどのようにループを処理しているのかを理解し、大量のデータを意のままに「さばき」「整形し」「集約する」ためのプロフェッショナルな技術を伝授します。

この記事を読破すれば、あなたはもうアイテムの数に怯えることはありません。どんなに大量のデータが来ても、それをエレガントな作品に仕上げる指揮者（マエストロ）へと進化しているでしょう。

n8nの暗黙的ループ：知らぬは損、知れば天国
伝統的なプログラミングで複数データを処理する場合、forやwhileといった構文でループ処理を明示的に書く必要があります。しかし、n8nでは多くの場合、その必要がありません。

なぜなら、n8nの各ノードは**「入力されたアイテムの数だけ、自動的に処理を繰り返す」**という、暗黙的なループ機構を持っているからです。

1-1. 工場の組立ラインをイメージしよう
この概念は、工場の組立ラインに例えると非常に分かりやすいです。

(画像はアイテムがノードを一つずつ流れていく組立ラインのイメージ)

つまり、あなたはループを「書く」必要はなく、「各アイテムに適用したい処理」をノードとして置くだけで良いのです。これがn8nの生産性を飛躍的に高めている秘密の一つです。

1-2. ループの証拠を確認する
この暗黙的ループは、ノードの実行ログを見れば一目瞭然です。
10個のアイテムを出力するノードの次に接続されたノードを実行すると、実行結果の右上に「10 items」と表示されます。そしてOutputタブを開くと、10個のアイテムがそれぞれ処理された結果がリストとして表示されているはずです。これが、ノードが10回実行された何よりの証拠です。

この**「n8nはアイテムごとに自動でループしてくれる」**という大原則を理解することが、大量データ処理の第一歩です。

アイテムの整形外科医：データ加工ノードを使い分ける
APIから取得した生のデータは、多くの場合、私たちの目的にとって不要な情報を含んでいたり、項目名が使いにくかったりします。ループ処理の中で、各アイテムを必要な形に磨き上げていきましょう。ここでは、そのための2人の名医（ノード）を紹介します。

① Set ノード (創造主)
すでにお馴染みのSetノードは、全く新しいデータ構造を作り出すのに適しています。既存のデータを参照しつつも、最終的には定義したフィールドだけの、クリーンな新アイテムを出力します。ループの中で、各アイテムをシンプルな文字列や特定のJSON構造に変換したい場合に最適です。

② Edit Fields ノード (専門医)
Setが創造主なら、Edit Fieldsはより専門的な整形外科医です。既存のアイテム構造を活かしつつ、的を絞った操作を加えるのに非常に優れています。

Keep / Remove Fields (フィールドの保持/削除): APIが返す30個のフィールドの中から、nameとemailだけを残したい、といった場合にKeepを使います。逆に、パスワードのような機密情報を下流に渡したくない場合にRemoveを使います。

Rename Fields (フィールド名の変更): user_nameというフィールド名を、次のSlackノードで使うusernameに変更する、といった場合に活躍します。

Change Field Values (フィールド値の変更): フィールドの値に特定の計算式を適用したり、文字列を加工したりできます。

【使い分けの指針】

ゼロから新しい構造を作りたい → Set

既存のアイテムを部分的に修正・整理したい → Edit Fields

特に、不要なフィールドを削ぎ落とすKeep/Removeは、後の処理をシンプルにし、ワークフロー全体のメモリ使用量を抑える効果もあるため、積極的に活用しましょう。

大量のデータを賢く分割：Split In Batches ノード
もし、処理すべきアイテムが1000個、1万個とあったらどうなるでしょう？

APIレートリミット: 短時間に1000回もAPIリクエストを送ると、相手のサーバーから「アクセス過多」として一時的にブロックされてしまう可能性があります。

メモリの問題: 大量のデータを一度に処理しようとすると、n8nが稼働しているサーバーのメモリを圧迫し、パフォーマンスが低下したり、最悪の場合ワークフローが停止したりする恐れがあります。

この問題をエレガントに解決するのがSplit In Batches（バッチで分割）ノードです。

これは、アイテムの洪水に対する**「交通整理員」**の役割を果たします。1000人の行列を、10人ずつのグループに分割してくれるイメージです。

Batch Size (バッチサイズ): この設定で、1グループあたりの人数（アイテム数）を決めます。例えば10と設定すれば、1000個のアイテムは「10個のアイテムを含むリスト」が100個、という形に変換されて出力されます。

後続処理: Split In Batchesの後、Waitノードを挟んで「1バッチ処理するごとに1秒待つ」といった制御を入れることで、APIレートリミットを優雅に回避できます。

大量データを扱う本番環境のワークフローでは、このSplit In Batchesが命綱となります。

実践！大量の記事を整形し、1つのサマリーに集約する
それでは、今回学んだ技術を結集し、複数の記事情報を取得・整形し、最終的に1つのSlackメッセージにまとめて投稿するワークフローを構築します。

シナリオ
[RSS Read]: 複数の記事（例: 10件）を取得する。

[Set]: 各記事を「- 見出し」というMarkdown形式の1行の文字列に変換する。

ワークフロー構築手順
Step 1: [RSS Read] ノード

適当なRSSフィード（例えばhttps://b.hatena.ne.jp/hotentry/it.rss）を指定し、複数のアイテムが取得できることを確認します。

Step 2: Edit Fields ノード (アイテムの整形)

RSS Readノードの次に接続します。

ModeをKeep Fieldsに設定し、Fields to Keepにtitleとlinkを追加します。

Add OperationからRename Fieldsを追加します。Field to Renameにtitle、New Nameに見出しと入力します。

これで、各アイテムは{ "見出し": "...", "link": "..." }というシンプルな構造になりました。

Step 3: [Set] ノード (Markdown形式への変換)

Edit Fieldsノードの次に接続します。

Add Valueで、Nameにmarkdown_lineと入力。

Valueに、 - [{{ $json['見出し'] }}]({{ $json.link }})と式を入力します。

OptionsからKeep Only SetをONにして、出力が{ "markdown_line": "- 記事タイトル" }という形になるようにします。

Step 4: Items Lists ノード (アイテムの集約)

ここが今回のハイライトです。Setノードの次にItems Listsノードを接続します。

OperationをConcatenate Items (アイテムを連結) に設定します。

Field to Concatenateに、連結したいデータが格納されているmarkdown_lineを指定します。

Separator (区切り文字) に、\n（改行を意味する特殊文字）を入力します。

これを実行すると、それまで10個あったアイテムが、全アイテムのmarkdown_lineを改行で繋げた、たった1つのアイテムに集約されます。

Step 5: Slack ノード (最終投稿)

Items Listsノードの次に接続します。このノードは1回しか実行されません。

Textに、以下のように入力します。

今日のITホットエントリー
{{ $json.data }}
{{ $json.data }}の部分に、Items Listsノードが集約してくれたテキストブロックがまるごと挿入されます。

これで、複数のアイテムをループ処理で個別に加工し、最後に一つの情報にまとめて出力する、という非常に実用的なパターンが完成しました！

まとめ：群れを統べるデータ使いへ
今回は、n8nにおける複数アイテムの処理、すなわち「ループ」「データ加工」「集約」そして「スケーリング」の技術を学びました。

n8nのループは暗黙的。ノードはアイテムの数だけ自動で実行される。

アイテムの整形にはEdit FieldsとSetを使い分ける。不要なデータを削ぎ落とし、必要な形に磨き上げる。

大量データにはSplit In Batchesで立ち向かう。 API制限やメモリ問題を回避するプロの技。

バラバラのアイテムはItems Listsで集約する。複数の結果を一つにまとめて最終報告。

これらの技術を身につけたあなたは、もはやアイテムの数に振り回されることはありません。1個であろうと1万個であろうと、その群れを冷静に分析し、統率し、望むべき成果へと導くことができるはずです。

さて、ワークフローはますます実用的で、強力なものになってきました。しかし、強力なツールには相応の責任が伴います。もし、途中でエラーが起きたら？同じような処理を何度も作るのは面倒ではないか？

次回、いよいよ最終回となる第5回では、**「本番運用に耐えるための、堅牢なワークフロー構築術」**として、エラーハンドリング、ワークフローの再利用、そしてプロが実践する運用上のベストプラクティスについて解説します。

それでは、良き自動化ライフを！