Make.comのイテレーターは分解係　使いどころと落とし穴 2026

Makeのシナリオは、基本的に1件ずつ処理が流れます。メールが1通届いたら、1回の処理が走る。この形なら分かりやすい。

ところが、届いたデータの中に複数の項目が入っていることがあります。添付ファイルが3つあるメール、10行返ってくるスプレッドシート、5件の商品が入った注文データ。

ここで詰まります。「1件ずつ」を前提にしたモジュールに、まとまったデータを渡すとエラーになる。あるいは、1つのセルに全部が押し込まれた妙な結果になります。

この橋渡しをするのがイテレーターです。

イテレーターは何をするのか

配列を、個別のバンドルに分解します。

トランプの束を配るのに近い。1つの束のまま渡しても、誰も遊べません。1枚ずつ配って初めて、それぞれの手元で処理ができる。

そして、配ったあとに集めて1つの山に戻すのがアグリゲーターです。この2つはセットで覚えるのが正解で、白状すると私も最初はイテレーターだけ覚えて、後段で通知が連射されて慌てました。

そもそもバンドルとは

Makeの中を流れるデータの単位です。1行、1件、1通。これが1バンドル。

モジュールは、1バンドルを受け取るたびに1回動きます。だから10バンドル流れれば10回動く。この仕組みを理解しておくと、後のクレジットの話が腑に落ちます。

どんなときに必要になるか

典型的なのはこのあたりです。

• メールの添付ファイルを1つずつDriveに保存する
• APIが返したJSONの中の商品リストを1件ずつ処理する
• フォームの複数選択の回答を、選択肢ごとに分けて扱う
• カンマ区切りで届いたタグを、1つずつ登録する

共通点は、1つのバンドルの中に複数の項目が入っていることです。

逆に、スプレッドシートの「複数行を取得」のようなモジュールは、最初から行ごとにバンドルを分けて出力します。この場合はイテレーターは不要です。

ここを混同して、分ける必要のないものにイテレーターを挟んでしまうケースがあります。実行ログを見て、すでにバンドルが分かれているかどうかを確認してから判断してください。

設定のしかた

イテレーター

Flow Controlのカテゴリにあります。設定する項目は1つだけ。

• Array：分解したい配列をマッピングする

メールの添付なら`attachments[]`のような配列を指定します。ここに配列以外を入れると動きません。

配列がない場合は、split関数で自分で作ることもできます。

{{split(1.tags; “,”)}}

「A,B,C」という文字列を、3つの要素に分けてからイテレーターに渡す形です。

特化型イテレーター

アプリによっては、専用のイテレーターが用意されています。メールの添付を扱う専用モジュールなどがそれです。

使えるならこちらのほうが設定が楽なので、汎用のイテレーターを置く前に探してみてください。

アグリゲーター

ここが本題です。設定項目が2つあり、片方でほぼ全員がつまずきます。

• Source Module：どのモジュールから集約を始めるか
• Aggregated fields：何をまとめるか

問題は1つ目です。ここでイテレーターを指定すると、イテレーターが分解した分をまとめてくれます。ところが別のモジュールを指定すると、集約の範囲がずれる。

設定を保存すると、画面上で対象範囲がグレーの帯で囲まれます。分解したモジュールから集約するモジュールまでが正しく囲まれているか、必ず目で確認してください。この帯を見る癖をつけるだけで、事故がかなり減ります。

実際の流れ

「1通のメールの添付ファイルを全部Driveに保存して、完了通知を1回だけ送る」構成で説明します。

1. Gmailの監視モジュールを置く
2. イテレーターを置いて、添付の配列を指定する
3. Google Driveのアップロードモジュールをつなぐ（添付の数だけ動く）
4. Array aggregatorを置いて、Source Moduleにイテレーターを指定する
5. Slackの通知モジュールをつなぐ（1回だけ動く）

4番を入れないと、添付が3つあれば通知も3通飛びます。まとめてから通知する。これがアグリゲーターの一番分かりやすい使い道です。

アグリゲーターの種類

通知メッセージを作りたいならText aggregator、別のシステムに渡すならArray aggregator。用途で使い分けます。

クレジットの話

ここは無料プランで運用するなら必ず押さえてください。

イテレーターは、処理する件数分のクレジットを消費します。3件に分解すればイテレーター自体で3消費。さらに後続のモジュールも3回動くので、それぞれ3消費します。

Makeの無料プランは月1,000クレジット。10件のデータを1日1回処理するだけで、月に600以上消えます。これを1日3回にすると足りません。

私がこのブログの記事生成をMakeで回していた頃も、繰り返し処理が入るシナリオは特に消費が読めませんでした。動かしてみるまで実際の請求が分からないのは、正直やりにくいところです。

節約の要はフィルター

覚えておくと効くのがこれです。フィルター自体はクレジットを消費しません。

だから、イテレーターの直後にフィルターを置いて、条件に合わないものを止める。後続のモジュールが動かなくなるので、そのぶん消費が減ります。

10件のうち処理が必要なのが2件だけなら、フィルターを1つ置くだけで消費が大きく変わってきます。

つまずきやすいポイント

後続が1回しか動かない

イテレーターのArrayフィールドに、配列ではなく単一の値を指定しています。実行ログでイテレーターの出力を開き、バンドルが複数に分かれているか確認してください。

アグリゲーターが空を返す

Source Moduleの指定が間違っています。分解を始めたモジュールを指定し直してください。

集約結果が複数出てくる

Source Moduleに、複数回動くモジュールを指定しています。1回しか動かないモジュール（トリガーなど）を指定すると、1つにまとまります。

件数が多いと結果がおかしい

直近のコミュニティでも報告が上がっていた症状です。1〜2件では正常なのに、5件を超えると集約結果が不安定になるケースがあります。

原因は状況によりますが、後続でAPIを呼んでいる場合はタイムアウトやレート制限が絡んでいることが多い。件数を絞って実行し、どこから崩れるかを確認するのが切り分けの近道です。

入れ子が深くなる

イテレーターの中でさらにイテレーターを使う構成は、動きますが読めなくなります。配列の中に配列があるデータを扱うなら、先にflatten関数で平らにできないか検討してください。

気になるところ

Makeのこの仕組みについて、弱いと感じる点も書いておきます。

まず、どこまでが集約範囲なのかが直感的でないこと。グレーの帯で示されるようになったのは改善ですが、Source Moduleという概念自体が初見では分かりづらい。ここでつまずいて離脱する人は多いと思います。

もう1つ、クレジットの見積もりが事前に出せないこと。件数が変動するデータを扱うと、月の消費が読めません。処理件数の上限を自分で設けるくらいしか対策がないんですよね。

よくある質問

無料プランでもイテレーターは使えますか

使えます。機能の制限はありません。ただしクレジット消費が大きいので、処理件数と実行頻度の設計が重要になります。

処理する件数を制限できますか

イテレーターの前で配列を加工するか、フィルターで絞り込むかになります。データを取得するモジュール側にLimitの設定がある場合は、そこで制限するのが一番確実です。

順番は保証されますか

基本的には配列の順番どおりに処理されます。ただし後続で外部APIを呼ぶ場合、応答時間の差で完了の順序が前後することはあります。

途中でエラーが出たら全部止まりますか

初期設定では止まります。エラーハンドリングの設定を追加すれば、失敗した1件を飛ばして続行させることも可能です。件数の多い処理では入れておいたほうがいい。

アグリゲーターは必ず必要ですか

不要な場合もあります。分解して個別に処理して、そのまま終わる構成なら要りません。「まとめて何かをしたい」ときだけ置いてください。

まとめ

イテレーターでつまずく場所は3つです。配列ではないものを指定していること、アグリゲーターのSource Moduleを間違えること、そしてクレジット消費を見積もらずに件数の多いデータを流すこと。

特に3つ目は無料プランだと即座に効いてきます。分解する前にフィルターで絞る。この1手を入れるかどうかで、月末の残量がまるで変わります。

※本リンクはアフィリエイトリンクです。

無料プランでも繰り返し処理は組めます。まずは3件程度の小さい配列で試すところから → Make.com（※アフィリエイトリンクです）

使うかどうかの判断材料を1つ渡すとすれば、実行ログでバンドルがいくつ表示されているかです。1つのまま次に進んでいるのに中身が複数あるなら、そこがイテレーターの出番。答えは解説記事の中ではなく、あなたのシナリオの実行ログに並んでいる、あの数字の中にあります。