MakeのIteratorとAggregator｜一件ずつ処理して結果をまとめる

Makeで複数の商品や回答を処理したいのに、一件だけ登録される。逆に、まとめて一回送るつもりの内容が何度も送られる。そんなときは、IteratorとAggregatorの役割を分けて考えると、どこで件数が変わるかを確認しやすくなります。

配列を一件ずつ扱う処理と、複数の結果をまとめる処理を分けましょう。この記事では三件の商品データを例に、設定、途中の件数、空の結果を確認する順番を紹介します。外部へ登録・送信する前に、確認用のデータで流れを点検します。

配列とバンドルを区別する

Make公式では、Iteratorは配列を複数のバンドルへ分け、配列の各要素を別々に出力するモジュールと説明されています。配列は複数の項目を一つの中へ入れたデータ、バンドルはモジュールを流れるデータのまとまりとして考えると整理できます。

見た目が一覧でも、実際のデータが配列とは限りません。改行した文字列やカンマ区切りの文章を、そのまま配列として指定する前に、前のモジュールの出力を確認します。AIにJSONを作らせる場合も、表示された文章と構造を持つデータを混同しないことが大切です。

既に一件ずつ出ているなら分け直さない

検索モジュールなどが最初から複数のバンドルを出している場合は、その結果の流れを先に確認します。複数件だから必ずIteratorを足すとは考えません。入力が一つの配列なのか、既に一件ずつ流れているのかで、必要な構成が変わります。

説明用に、三商品の一覧を一つの配列で受け取る場合と、検索結果で三商品が個別に出る場合を比較します。どちらも元の商品数は三ですが、モジュールの出力状態は違います。途中の出力を開き、対象項目と件数を見てから次の処理を選びましょう。

一件ずつ処理する最初の構成

1. 元データを受け取るモジュールで、出力の構造を確認します。
2. 複数項目が入った配列を、IteratorのArrayへ指定します。
3. 後続へ、一件の内容を確認できる処理を置きます。
4. 三件など少数の確認用データで実行します。
5. Iteratorの出力件数と、各件の識別子を確認します。
6. 後続処理が意図した各件の値を扱っているかを照合します。

商品ID、名称、確認状態を持つ説明用データなら、どのバンドルがどの商品かを追えます。名称が似ているだけでは、別商品を取り違えたことに気付きにくくなります。実際の業務へ広げる前に、元データへ戻れる識別子を持たせてください。

後続のマッピング候補が出ない場合は、入力の構造が把握されているかも見ます。公式にも、Iteratorが配列項目の構造を知らない場合の案内があります。無関係な項目を選んで先へ進めず、前段から対象のデータを確認しましょう。

まとめて出す場所を決める

Aggregatorは、受け取った複数のバンドルをまとめて出力するためのモジュールです。例えば商品ごとの処理結果を一つの一覧へまとめたい場合に考えられます。ただし、どこから集約を始めるかと、どの情報を集めるかを設定する必要があります。

公式はSource Moduleで集約の起点を選ぶと説明しています。商品ごとの処理をまとめたいのか、注文ごとのまとまりを保ちたいのかを先に決めます。灰色で示される区間だけを見て理解したつもりにならず、起点の出力とAggregatorの結果を照合してください。

フィルターがあるなら途中の件数を数える

三件をIteratorへ渡しても、途中の条件で二件だけが通るなら、最後にまとめる対象は変わります。元の三件と最終結果の二件が違うことだけで失敗とは判断せず、どの条件で一件が除かれたかを確認します。

説明用の点検では、入力三件、分割三件、確認済みだけ通過二件、集約後の配列二件という流れを考えられます。これは期待値の例であり、当サイトが実際にそのシナリオを実行した記録ではありません。実際の結果は各モジュールの出力へ戻って確認してください。

フィルターで除かれたものを、処理済みと混同しないようにします。未承認だから止めた、値が空だから対象外にした、という理由を記録すると、次にデータを修正した後の再実行範囲を判断できます。

後で必要な値を集約へ含める

公式は、Aggregatorより前の出力項目が後続へそのまま渡るわけではないと説明しています。集約後に商品IDや注文番号が必要なら、それを集める設定へ含めるかを確認します。前段に値があることだけでは、後段で使えることの確認になりません。

一覧へ表示する商品名だけを集めると、登録先の結果と照合するためのIDが失われるかもしれません。一方、不要な個人情報まで全部まとめる必要もありません。何を表示し、何で照合するかを決め、必要な項目を選びます。

グループ化と空の配列を確認する

Group byを使う場合は、条件ごとに出力が分かれることを考えます。すべての結果を一回の一覧にしたいのに、注文別などの条件を残していれば複数の出力になる場合があります。後続が何回動く予定かを、グループの数と一緒に確認します。

すべてのデータがフィルターで止まった場合も試します。公式には、空の集約後に処理を止める設定への案内があります。対象なしの通知を残したいのか、何も登録しないのかを決めてください。成功の表示だけで、空の登録が意図どおりだとは扱いません。

外部へ登録する前の検証

確認用の段階では、一件、一度に複数件、空、同じ識別子を含むデータを分けて試します。元データ、途中の件数、最終結果が説明できる状態を作ってから、本番の登録や送信へつなげます。送る回数と処理する件数が違うことを、設計の時点で明確にします。

途中で失敗した結果を再実行する場合は、既に登録された件数と識別子を確認します。Iteratorを使うだけで重複が防げるわけではありません。登録済みの判定や照合は、業務に合う方法で別に考えてください。

• 入力が配列か、既に複数のバンドルかを確認したか。
• 各件の識別子と、途中で除かれた理由を追えるか。
• 集約の起点、項目、グループ、空の扱いが合うか。
• 後続の実行回数と保存された結果を照合したか。

選び方はMakeとZapierの比較、運用方針はMakeとn8nの比較も参考にできます。

確認日：2026年10月12日。参考：Make公式Iterator、Aggregator。三件の例と点検順は当サイトの運用案です。本記事にはアフィリエイト広告が含まれます。