目次
まず決めるのは「配列の1項目を別runにするか」
トリガーが複数レコードを含む配列を返したとき、Power Automateでは大きく二つの処理方法があります。トリガーのSplitOnは、対応するトリガー出力の配列を分割し、項目ごとに別のフローrunを起動する方式です。Apply to eachは、配列全体を受け取った一つのrunの中で、各項目に同じアクションを実行するループです。
選択基準は「速そうだからSplitOn」ではありません。項目を独立した実行・監視・失敗単位にしたいか、配列全体や親リクエストの情報を一緒に扱いたいかで決めます。入力を一件ずつ処理しても業務上の関連がなく、項目別のrun履歴が必要ならSplitOnを検討します。一括依頼として全項目を検証し、集計や全体結果を返すならApply to eachが扱いやすい選択です。
先に入力ペイロードを確かめる
設計前に、実際のトリガー履歴から成功例だけでなく、空配列・単一要素・複数要素・欠損フィールドのbodyを保存します。トリガーが配列を返すことと、SplitOnを利用できることは同じではありません。MicrosoftのLogic Apps定義資料では、配列を受け取り返すことができ、SplitOnをサポートするトリガーが対象とされています。Power Automateでは、利用中のトリガー設定画面にSplit onがあるか、現在の製品ドキュメントと実フローのデザイナーで確認してください。別製品のAzure Logic Appsの仕様をPower Automate全体へそのまま当てはめないことが重要です。
配列の場所も確認します。bodyそのものが配列とは限らず、例えばbody.recordsのような入れ子の配列かもしれません。SplitOnはどの配列をrun単位にするかを式で指定します。分割後のrunでは、各項目が新しいrunのtrigger bodyとして見えるため、元の配列の外側にあったrequest ID、合計件数、親レコードなどを同じように参照できるとは限りません。必要な親情報は配列項目へ含めるか、分割前に別の永続領域へ保存する設計を検討します。
判断表
表は横にスクロールできます
| 判断条件 | SplitOnを検討 | Apply to eachを検討 |
|---|---|---|
| 業務上の単位 | 各レコードが独立した処理・監査単位 | 一つの依頼に含まれる項目群 |
| 親情報 | 各項目に必要情報を含められる | 配列外の親情報を後続処理でも使う |
| 失敗時 | 失敗項目を個別runとして追跡したい | 全体を検証し、行別結果をまとめたい |
| 完了通知 | 項目単位で完了を通知できる | 全項目の結果をまとめて通知する |
| 入力件数 | SplitOn上限を満たすことを確認済み | Apply to eachの件数上限・処理時間に収まる |
| 二重実行対策 | 項目の一意IDで冪等化できる | 親依頼IDと項目IDで再実行を照合できる |
これは製品の絶対的な優劣表ではありません。同じフローでも、業務要件・契約プラン・トリガー・接続先の制限で適切な選択が変わります。
SplitOnにした場合の制約
SplitOnを有効にすると、親配列ではなく分割後の項目を中心にフローが実行されます。そのため、親オブジェクトの他のプロパティを前提とした式が壊れないか確認します。Logic Appsの公式定義資料も、SplitOn後に配列外のプロパティを直接参照できない状況を説明しており、必要な参照には安全なnull条件演算子などを使う例を示しています。ただし式の構文やデザイナー表示は製品・トリガーに合わせてテストしてください。
SplitOnはrun数を増やします。各項目の処理を並列化できる一方で、接続先APIのthrottling、同一レコード競合、通知量、実行履歴の保管・閲覧負荷が増えることがあります。トリガーConcurrency Controlも使う場合はSplitOnの処理可能件数が制限されます。MicrosoftのPower Automate limits資料ではConcurrency Control有効時のSplit on上限は100 itemsと案内されています。ライセンス・フロー種別によりその他の上限は変わるため、公開値を固定値として記事や設計へコピーせず、対象環境でLimits and configを確認してください。
特に重要なのは、Power AutomateのトリガーConcurrency Controlは一度有効化すると無効へ戻せず、元に戻すにはトリガーを削除して再作成する必要があるという公式注意です。これは取り消しに手間がかかる設定なので、本番フローで試しに切り替えるのではなく、テストフローで挙動・必要数・復旧方法を確認してから設定してください。
Apply to eachにした場合の制約
Apply to eachでは配列全体を一つのrunで扱えるため、親依頼の共通情報を参照しながら各要素を処理できます。各項目の結果を配列や変数へ集め、最後に成功・失敗件数をまとめて返す構成にも向きます。ただし、逐次処理が必要なのか並列処理が許されるのかを明示します。MicrosoftのPower Automate上限資料ではApply to eachの反復件数はプラン区分によって5,000または100,000、同時実行数は既定1で変更範囲は1〜50とされています。実環境の契約、フロー種別、アクション・コネクタの個別制限を併せて調べてください。
順序依存の更新、共有変数への追記、同じ顧客・ファイルへの書き込みがある場合、並列度を上げると競合や順序の変化が起こり得ます。逆に既定の逐次実行が遅いからといって無条件に並列化すると、API上限や下流サービスのcapacityを超えることがあります。処理時間だけでなく、下流の許容量、再試行時の重複、レコードロック、順序保証を確認します。
共有変数の混在はitem IDと読み書きの順で追う
Apply to each内の変数を「各item専用の箱」と考えないでください。Power Automateの変数は、そのcloud flow内で共有され、反復をまたいで残ります。Microsoftは、ループ変数の予測可能な結果が必要な場合、各反復を逐次実行するよう注意しています。Microsoft：Store and manage values in variables（新しいタブで開く）
例えば各itemの顧客IDを共有変数currentCustomerへ入れ、その変数を後の書込み先判定に使うとします。次は起こり得る読み書きの交差を説明する架空例で、実フローの実行ログではありません。
表は横にスクロールできます
| 順番 | item | 操作 | 共有変数の状態／読んだ値 |
|---|---|---|---|
| 1 | A | currentCustomerへC01を設定 | C01 |
| 2 | B | currentCustomerへC02を設定 | C02 |
| 3 | A | 書込み先として変数を読む | C02を読んでしまう可能性 |
この例では、値を設定するaction単体が成功しても、後の参照が同じitemの値とは限りません。診断ではitem ID、変数を書いたaction、読んだaction、出力先IDを対応させます。個人情報の実値をログへ増やさず、許可された非機密のテストIDを使ってください。
共有状態が必要なら、検証環境で反復を逐次にした場合と比較します。各itemだけで完結する値なら、共有変数へ移す必要があるか、現在のitemやその処理に対応する出力を参照できるかを見直します。並列処理は、互いに依存しない作業かを先に確認する設計です。Microsoft：Optimize flows with parallel execution and concurrency（新しいタブで開く）
ただし逐次化で、外部サービス側の再試行、別runとの同時書込み、同じitemの二重到着まで解消するわけではありません。入力item IDと更新先ID、件数、失敗・重複を照合し、速度の変化とデータの正しさを別に確認してください。ここではPower Automateを実行しておらず、並列度変更の効果を測定していません。
どちらを選ぶかを試す最小テスト
本番データではなく、同じ形のテストペイロードを用意します。次のケースを実行履歴に残し、run数・入力の見え方・親情報・失敗範囲を比較してください。
表は横にスクロールできます
| ケース | 入力 | 確認すること |
|---|---|---|
| 空 | 配列が空 | runが起動するか、スキップになるか、空結果をどう記録するか |
| 単一 | 1項目 | body shapeとIDが想定通りか |
| 複数 | 3項目、うち1件は検証失敗 | run数、他項目への影響、失敗項目を再処理できるか |
| 欠損 | 1項目で必須キーなし | null参照で停止せず、その項目を隔離できるか |
| 重複 | 同じ業務IDを含む | 2回届いた場合に二重更新されないか |
| バースト | 想定ピークの配列数 | 処理時間、throttling、待機・再試行の挙動 |
SplitOnで3項目を処理したときは、項目ごとに別のrunができるか、各runにどの親情報が残るか、1項目の失敗が他runを止めないかを確認します。Apply to eachでは一つのrun内に各反復が表示されること、失敗した反復の再実行単位、最終集計が正しいことを確認します。デザイナー上の表示だけでなく、run historyから入力、出力、失敗アクションを読み戻してください。
迷ったときの設計ワークシート
次の項目を埋めると、方式の選択理由を実装担当者へ引き継げます。
表は横にスクロールできます
| 記入項目 | SplitOn案 | Apply to each案 |
|---|---|---|
| 1回の入力で受け取る最大件数 | 予想する項目run数とtrigger上限を記録 | 1runのloop件数と総実行時間を記録 |
| 親レコードの識別子 | 各項目へ引き継ぐ方法を明記 | trigger bodyから参照する式を記録 |
| 失敗時に再実行する単位 | 失敗した項目runをどう見つけるか | 失敗反復と残り項目をどう再開するか |
| 下流サービスの許容量 | 同時runとconnector throttleを照合 | loop parallelismとAPI quotaを照合 |
| 完了通知 | 項目ごとか、親依頼の全件終了後か | 全反復の結果をどう集約するか |
例えば受注イベント配列で、各注文を独立して配送先へ送信し、注文IDごとに失敗を再処理するなら、SplitOn候補を小規模なテストflowで確かめます。一方、ひとつの月次精算依頼に含まれる複数明細を合算し、全体合計が一致した場合だけ確定するなら、Apply to eachで処理してから合計と明細数を照合する方が業務単位を保ちやすいでしょう。これは方式の例であり、特定connectorの保証や実測結果ではありません。
設計記録には選択理由だけでなく、採用しなかった方式が不適切な条件も残します。「項目ごとに独立runが必要」「親contextを使った全体検証が必要」「接続先の上限が先に支配する」といった条件を運用変更時に再点検できるようにしてください。
選定後に残す運用ルール
SplitOnを選ぶなら、項目ごとの一意キー、親依頼との対応、重複排除、失敗runの再処理方法を決めます。親payloadのメタデータが必要なら、分割後にも保存・検索できる方法を用意します。Apply to eachを選ぶなら、配列全体の入力件数、成功・失敗item数、途中失敗時の再開位置、並列度と接続先上限を記録します。
いずれの方式でも、フローrunがSucceededになったことと、業務上の全レコードが処理済みであることは別の条件です。runの最終状態だけで完了と判定せず、入力item IDと出力・更新済みIDの集合を比較し、欠落・重複・失敗を検出します。再試行は冪等キーと更新前readbackを使い、同じ依頼を二重登録しないようにします。
結論：一件ごとのrunか、一括依頼のrunか
まず「入力配列の各項目は独立した業務イベントか」を決めてください。独立イベントで、項目別の履歴・再処理・通知が必要ならSplitOnを試し、対応トリガーと件数上限、親情報の扱いを検証します。一件の依頼の中で全行を比較・集約し、親情報や一括結果を使うならApply to eachを基本候補にします。
ただし両方の方式で、空配列・部分失敗・重複・想定ピークをテストするまでは本番切り替えを完了扱いにしません。トリガーのConcurrency Controlは、有効化後に解除するにはトリガーの削除・再追加が必要になるため、Apply to eachの並列度とは分けて変更の影響を確認してください。
公式情報と確認範囲
2026-10-15にMicrosoft LearnのPower Automate limitsとLogic Apps trigger/action schema資料を確認しました。上限値はフロー種別・プラン・機能設定により適用範囲が異なります。Logic AppsのSplitOn記述は挙動理解の補助として参照し、Power Automateのトリガー対応可否は対象フローのデザイナーとPower Automate公式情報で確認してください。
-
https://learn.microsoft.com/power-automate/limits-and-config（新しいタブで開く）
-
https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-workflow-actions-triggers（新しいタブで開く）
出典・適用範囲
対象はPower Automate cloud flowのトリガー配列処理とApply to eachです。Azure Logic AppsはSplitOnの概念や配列外参照の制約を理解する比較資料として扱い、製品間の全仕様・上限が同一とはしていません。利用中のtrigger、license、connector、tenant環境に対する動作は未実行です。