【Power Automate】Apply to eachが急に動かない時の実行履歴から原因を読む方法

Power Automateでフローを運用していると、突然「Apply to each」のアクションが動作しなくなる場面に遭遇することがあります。これまで問題なく動いていたのに、ある日を境にエラーが発生したり、処理が途中で止まったりするケースは珍しくありません。原因はデータ構造の変化、同時実行数の制限、変数の型不一致など多岐にわたります。本記事では、実行履歴を手がかりに原因を特定し、再発を防ぐための具体的な方法を解説します。

実行履歴の基本と「Apply to each」の挙動

Power Automateのフローは、各アクションが順番に実行され、その結果が実行履歴に記録されます。「Apply to each」は配列やコレクションの各要素に対してループ処理を行うアクションです。実行履歴を確認することで、どのループの何番目の要素でエラーが発生したのか、入力データがどのような状態だったのかを把握できます。以下に基本的な確認手順を示します。

1. Power Automateポータル(make.powerautomate.com)にサインインします。
2. 左メニューから「マイフロー」を選択し、該当フローの行にある「実行履歴」アイコンをクリックします。
3. リストから「失敗」または「中断」の実行を選択し、詳細画面を開きます。
4. アクションの一覧で「Apply to each」を見つけ、そのアクションをクリックして展開します。
5. 「入力」タブでループの元になった配列の内容、「出力」タブで各ループの結果、「エラー」タブでエラーの詳細を確認します。特に「エラー」タブに表示されるメッセージとコードが重要です。

代表的なエラーパターンとその読み解き方

実行履歴に表示されるエラーにはいくつかの典型的なパターンがあります。それぞれの原因と対処法をまとめました。

パターン1: 「BadRequest」エラー

「Apply to each」内で使用しているアクション(SharePointの「アイテムの作成」など)が、必須項目の欠落や不正なデータ型により BadRequest を返すケースです。実行履歴では、該当のループ番号とエラーメッセージが表示されます。

この場合、ループ内で渡しているプロパティの値が null や空文字でないか確認します。また、参照元のデータソース(Excelテーブル、SharePointリストなど)の列名やデータ型が変更されていないか調査します。特に、数値項目に文字列が混ざっているとエラーになります。

パターン2: 「GatewayTimeout」または「ServiceUnavailable」

「Apply to each」のループ回数が非常に多い場合(例:数千件)、ループ内の各アクションの応答が遅延し、タイムアウトが発生することがあります。実行履歴では「GatewayTimeout」などのエラーが記録されます。

この問題は、同時実行数の制限(並列度)やAPI呼び出しの頻度制限が原因となることが多いです。対策として「Apply to each」の「同時実行数」を調整するか、ループ内で「遅延」アクションを挿入してレート制限を回避します。管理者に連絡し、該当コネクタのAPI制限値を確認してもらう必要があるかもしれません。

パターン3: 「ExpressionEvaluationFailed」

ループ内で使用している式や関数(items() や variables() など)が正しく評価されない場合に発生します。実行履歴のエラーメッセージには、評価に失敗した式の詳細が含まれます。

よくある原因は、ループ外で定義した変数のスコープの問題です。また、配列の要素にアクセスする際に、想定外のnullが含まれているとこのエラーが出ます。そのため、ループの前に「フィルター」アクションで不要な要素を除去するなどの事前処理が有効です。

比較表:エラー種類と対処方針

エラーパターン	典型的なメッセージ	主な原因	推奨対処
BadRequest	Bad Request. The property ‘xxx’ is required.	必須項目の欠落、データ型不一致	入力データを検証し、データソースの列定義を確認
GatewayTimeout	The gateway timed out.	ループ処理時間が長すぎる、API制限	並列度の調整、遅延挿入、管理者への制限確認依頼
ExpressionEvaluationFailed	The expression ‘…’ could not be evaluated.	式の中の値がnull、スコープ外変数	式を見直し、事前にnullチェックを追加

失敗パターン:よくある誤った対処法

「Apply to each」が動かないとき、以下のような対応は逆効果になることがあります。

• ループの同時実行数をむやみに増やす:並列度を上げすぎるとAPI制限エラーが頻発したり、データベースロックが発生したりします。同時実行数はデフォルトの20程度から少しずつ調整するのが安全です。
• エラーを無視して再実行する:原因を特定せずにフローを再実行しても、同じエラーが繰り返されます。必ず実行履歴を確認してから対処しましょう。
• SharePointリストの列を直接編集する:フローが参照している列の名前やデータ型を変更すると、エラーの原因になります。変更する場合はフロー側の設定も同時に更新してください。

管理者へ確認すべき情報

問題が解決しない場合、Power Platform管理者(またはIT部門)に以下の情報を伝えると迅速な対応が期待できます。

• 実行履歴の「エラー」タブに表示される完全なエラーメッセージとエラーコード
• 「Apply to each」の入力値として渡しているデータのサンプル(件数、データ型など)
• フロー内で使用しているコネクタ(SharePoint、Outlook、SQL Serverなど)の一覧
• エラーが発生し始めたタイミング(日時)と、その前後でデータソースや環境に変更があったかどうか

よくある質問

Q1. 「Apply to each」のループ内でエラーが発生した場合、その後のループはどうなりますか?

デフォルトでは、エラーが発生した時点でフロー全体が失敗となります。ただし、並列実行設定や「エラー時の処理」を構成することで、エラーをスキップして後続のループを継続させることも可能です。

Q2. 実行履歴に「中断」と表示されるのはなぜですか?

フローが手動で停止されたか、タイムアウト(30日間)に達した可能性があります。また、ライセンスの制限や同時実行数の上限に達した場合も中断されることがあります。

Q3. ループ内で大量のデータを処理する際のベストプラクティスはありますか?

可能であれば、一度のAPI呼び出しでバッチ処理できるコネクタ(例えばSQL Serverのストアドプロシージャ)を利用することを検討してください。どうしてもループが必要な場合は、処理対象のデータを適切なチャンクに分割し、それぞれに別の「Apply to each」を使用する方法もあります。

まとめ

「Apply to each」が急に動かなくなったときは、実行履歴を詳細に確認することで原因のほとんどを特定できます。特にエラーメッセージの種類と、ループの入力データの状態に注目してください。原因がデータ構造の変化やAPI制限にある場合は、自分で修正可能な範囲を判断し、難しい場合は管理者へ正確な情報を伝えて対応を仰ぎましょう。日頃から実行履歴を定期的に確認する習慣をつけておくことで、問題の早期発見につながります。