1件に複数行ある注文や添付を処理するとき:ループと件数暴走の防ぎ方

処理単位の決め方メモ

先に「1通のメールに明細が3行ある」ことを前提に、出力が何件になるべきかを決めます。

• 明細を1行1レコードでシートやDBに入れる、処理単位：1行=1回、注意点：行を一意に識別するキー(注文番号+行番号)を作る
• 注文ごとに合計金額を1通だけ通知する、処理単位：1通=1回、注意点：行は繰り返さず、合計は集計してから使う
• 添付ファイルを1つずつ保存する、処理単位：添付=1回、注意点：ファイル数の上限と、拡張子・サイズの条件を先に決める
• 行ごとにメール送信や請求作成など外部に影響する処理をする、処理単位：1行=1回、注意点：上限を特に低くし、超過時は自動実行せず承認を挟む
• 行の処理は行い、完了通知は1通にまとめたい、処理単位：行は繰り返し、通知は最後の1回、注意点：通知をループ内に置くと行数ぶん届く

迷ったら、ループの中に「外部へ送る・作る・消す」処理があるかを見ます。あるなら、行数の想定外な増加がそのまま被害になるので、上限と停止条件が必須です。

仕様メモの書き方(コピー用)

処理単位: 1行=1回 / 1通=1回 / 添付1つ=1回(いずれか)
想定する通常の件数: 最大__行、__添付
上限(これを超えたら止める): __件
超過時の動作: ループに入らず担当者へ通知、処理は保留
ループ内の外部作用: あり(内容:__) / なし
最後に1回だけやること: 完了通知、集計 など
テストに使う件数: 0件、1件、上限ちょうど、上限+1

ツールごとの「繰り返し」と「数え方」

仕様は変わり得るので、以下は2026年10月29日に公式ページで確認できた範囲です。

n8n:ノードは基本的に入力された複数のアイテムをまとめて処理する作りで、多くのワークフローでは Loop Over Items は不要とされています。1件ずつしか扱えないノードやページ送りAPIなど、手動で制御したいときに使います。バッチサイズで1回あたりの件数を決められます。特にResetを使ったページ送りなどでは、無限ループを防ぐ終了条件が必要です。完了判定には {{$("Loop Over Items").context["noItemsLeft"]}} が使えると説明されています。

Zapier:Looping by Zapierの仕様では、確認した時点ではオープンベータで、Professional・Team・Enterpriseプランが対象と記載されています。区切り文字、明細(line item)、数値範囲の3種類があり、最大500回まで設定できます。ループ後のアクションはイテレーションごとに実行されます。設定手順では、1回だけ動かすために loop_iteration_is_last が真になる条件のフィルターを使います。ただし、各イテレーションは並列に動くため、最後の番号だけを通しても全件の完了を待つことにはなりません。完了通知には、全件の成功を確認する別の仕組みが必要です。注意点が二つあります。テスト時は最初の1回分しか表示されず、本番では全件が動きます。また、preview_loop_values は本番では使えないので後続に割り当てないよう書かれています。「テストでは1回で終わったから安全」とは言えません。

費用面では、タスクの数え方のページに、成功したアクションが1タスクで、トリガー・フィルター・パス・ループは対象外と書かれています。また、前述のLoopingの仕様には、ループ後のアクションは実行されたループごとにタスクを使うと明記されています。たとえば各行でシートに1レコード追加するアクションが成功すれば、行数ぶんのタスクになります。

Make:オペレーションの数え方では、モジュールが1つのバンドルを処理するたびに1オペレーションです。トリガーは何件返しても1回です。一方、後続モジュールはバンドルの数だけ動くので、1通に50行あれば、イテレーターで分けた後のモジュールは50回ずつ動きます。さらにシナリオ設定には、1回の実行で処理するサイクル数の上限(Cycles per run)、連続エラーで無効化する回数、順番どおりに処理する設定があります。なお「Run once」での手動実行はサイクル数の設定を無視し、1サイクルだけ実行します。ただし、サイクル数は明細件数の上限ではなく、1サイクル内でも複数のバンドルが処理されます。

件数上限と停止条件の設計例

どのツールでも骨格は同じです。

1. 入口で数える:明細(添付)の件数を、ループの手前で取り出す。
2. 上限判定:件数が0、または上限超なら分岐する。
3. 超過時は保留と通知:ループに入れず、注文番号と件数を担当者に送る。
4. ループ内は短く:外部作用は最小に。通知は最後の1回にまとめる。
5. 全体の安全弁:ツール側の実行回数・エラー設定も併用する。

説明用の数値例

通常は最大8行の注文メールを扱う想定で、上限を20行、添付は10件とします。この設定なら20行までは通し、21行以上は保留にします。上限は通常件数だけでなく、誤送信や誤作成が起きた場合の影響も踏まえて決めます。この数値は説明用で、自社の通常件数の履歴から決めてください。

n8nの例

ループの手前にCodeノードを置き、件数超過なら実行をエラーで止めます。以下は、1注文の明細を1行=1アイテムに分割済みの入力用です。明細配列を内包する1アイテムをそのまま渡すと、明細が何行あっても1件と数えてしまいます。0件の判定と通知への分岐は、明細を分割する前に行います。エラー時に通知するエラー用ワークフローを設定する前提ですが、Error Triggerは手動実行では動かないため、通知はテスト用入力による自動実行で確認します。以下は説明用で、実行して確認したものではありません。

// Code ノード: Run Once for All Items
const MAX_ROWS = 20;
const items = $input.all();

if (items.length > MAX_ROWS) {
  throw new Error(`明細が${items.length}件で上限${MAX_ROWS}件を超えました`);
}
return items;

エラーにせず分岐したいなら、明細を分割する前に配列の件数をIFノードで判定し、0件・超過側に通知だけをつなぎます。Loop Over Itemsを使うなら、バッチサイズは小さくし、完了通知はdone出力につなぎます。バッチサイズを小さくしても、総処理件数は減りません。

Zapierの例

この例では、入力元から分割対象と一致する明細件数を取得できる前提です。ループの前に件数を取り出し、その直後にフィルターで「件数が1以上、かつ20以下」のときだけ進める設定にします。件数を取得できない場合は、ループ前に数える処理を用意してから使ってください。フィルターはタスクを消費しないと明記されています。同じ入力を受ける通知用の別Zapでは、件数が0または20超のときだけ担当者へ通知します。停止したフィルターの後ろに通知を置いても動きません。ループ内の通知を loop_iteration_is_last で1回に絞る場合も、全件完了を知らせる通知には使わないでください。

Makeの例

イテレーターの手前にRouterを置き、配列関数の length(array)で明細件数を数えます。処理ルートは「1以上、かつ20以下」のフィルターを通してイテレーターへつなぎ、通知ルートは「0または20超」のときだけ通します。加えて、シナリオ設定の「Process data in order」で実行の重なりを抑えられますが、件数上限の代わりにはなりません。連続エラーによる無効化も補助として使えます。ただし、即時トリガーではその回数設定は無視され、最初のエラーで無効化されます。

AIに設計レビューを頼む依頼文

設計をAIに見てもらうときは、本物の注文データや顧客情報を貼らず、構造だけを置き換えて渡します。次の文をそのまま使えます。

あなたは業務自動化の設計レビュー担当です。
次の設計について、明細や添付が想定より多い場合の問題点を指摘してください。

【ツール】Make(または n8n / Zapier)
【入力の例】メール1通。件名「注文 A-0001」。本文に明細が3行(商品コード/数量)。
          添付はPDFが最大2つ。※すべて架空データ
【現在の流れ】
1. メール受信 → 2. 明細を分割 → 3. 行ごとにシートへ追加
→ 4. 行ごとに担当者へメール送信
【通常の件数】明細は最大8行
【知りたいこと】
- 処理単位は適切か
- 上限を置く位置と数値案
- 超過時の停止方法と通知文面
- 0件、1件、上限ちょうど、上限+1のテストケース

ツールの正確な設定名が不確かな場合は、推測と明示してください。

AIには、抜けている条件の洗い出しや通知文面の下書きを任せます。人が確認するのは、設定名が実際の画面にあるか、上限値が通常件数に合っているか、ループ内の外部作用が意図どおりかです。

公開前のテスト手順

1. 0件・1件・上限ちょうど・上限+1件の4種類のテストデータを、架空の注文で用意する。
2. 外部作用(メール送信・請求作成)は、テスト用の宛先や環境に向ける。
3. Zapierはテスト表示が最初の1回だけである点を踏まえ、本番相当の複数件で動作を確認する。
4. Makeは「Run once」が1サイクルだけ実行する点と、その中でも複数件を処理する点を踏まえ、入口の件数判定が働くことを確認する。
5. 上限+1件のとき、ループが一度も動かず通知だけが出ることを実行履歴で確認する。
6. 最初の1週間は、実行履歴と使用量(タスク・オペレーション)を毎日見て、上限が実態に合っているか見直す。