Power Automateの無限再実行を防ぐ

SharePointの「アイテムが作成または変更されたとき」は、作成だけでなく変更でも動きます。Flow自身が同じアイテムを更新して、更新後も起動条件を満たしていれば、再び実行される可能性があります。トリガー条件で不要な起動を抑えるのが基本です。ただし全ての更新Flowが無限ループするわけではありません。

まず「なぜ再実行されるか」を確認する

例えば「SharePoint Listのステータスが申請中なら処理するFlow」を作り、最後に同じアイテムのメモ欄を更新したとします。トリガーがWhen an item is created or modifiedなら、Flow自身が行った更新も新たな変更イベントの候補になります。

さらに、更新後もステータスが「申請中」のままなら、Flowは再び同じ処理を開始しかねません。

更新トリガーであること自体が不具合ではありません。 問題は、Triggerが監視する変更をFlow自身が生み、しかも再実行を遮る条件がないことです。

Microsoftも無限トリガーループのアンチパターンを明示し、Trigger Conditionsなどによる対策を案内しています。

公式：Avoid anti-patterns / SharePoint connector

1. 実行履歴から繰り返しの原因を切り分ける

最初に、Flowの実行履歴で同じSharePointアイテムのIdが短い間隔で繰り返し処理されていないか確認します。各実行で、Triggerの入力、Update itemの対象Id、更新した列と値を見比べます。

• Flowが同じList・同じItem Idを更新しているか
• その更新がTriggerの対象であるか
• 更新後も実行条件が真のままか
• 利用者による通常の更新と、Flow自身による更新のどちらか
• 更新を複数Flowが連鎖させていないか

最優先は、疑わしいFlowを一時停止するなどして不要な書き込みの拡大を防ぐことです。停止方法や影響は権限・運用環境によるため、本番で操作する前に関係者へ確認します。大量の同時実行が続く状態で条件式だけを少しずつ書き換えるのは避けましょう。

2. Trigger ConditionsとCondition actionの違い

Power Automateで条件を書く場所は同じではありません。

Microsoft LearnはTrigger Conditionsを使えば条件不一致のFlowを起動せず、不要なPower Platform requestsを減らせることを説明しています。Condition actionを1つ追加すれば起動回数まで減るという説明は不正確です。

なお、Trigger Conditionsでスキップした場合、対象のRun historyは作成されません。「実行履歴がないからSharePointの変更イベントが来なかった」と断定せず、条件の真偽や設定も点検します。

公式：Customize your triggers with conditions

3. まず業務状態を「未処理→処理済み」に変える

設定式より先に、起動対象を定義します。例えば架空の備品申請リストなら次のようにします。

1. 申請直後のStatusを「Pending」にする。
2. Trigger ConditionsでStatusがPendingのアイテムだけ起動する。
3. Flowが処理を完了できたらStatusを「Processed」に更新する。
4. 次回の変更イベントではStatusがProcessedのため、条件不一致で起動を抑える。

これは編集部の例示であり、Microsoftが定めた列名・値ではありません。実際のChoice列の内部名や値はテナントごとに異なります。

また、処理が長時間かかる場合や同時更新があり得る場合は、Pending→Processing→Processedのような中間状態、二重処理の検知、失敗時の再試行規則も設計します。状態更新を最後に行うだけでは、同時に複数の実行が始まる競合を完全には防げません。Trigger Conditionsだけで厳密な一度きりの処理（exactly-once）が保証されるわけではない点は押さえてください。

4. Trigger Conditionsの設定手順

Microsoft Learnは新しいデザイナー・クラシックデザイナーの両方を案内しています。現行の画面では次の順に確認できます。

1. 対象Flowを開き、Editを選ぶ。
2. SharePointのTriggerを選ぶ。
3. TriggerのSettingsを開く。クラシックデザイナーではメニュー（…）からSettingsを開く場合があります。
4. Trigger conditionsから条件を追加する。
5. 式を設定・保存し、架空のテストアイテムで期待した起動と非起動を確認する。

式は@から始める必要があります。 複数行で追加したTrigger Conditionsは原則ANDで評価され、どれか一つが偽なら実行されません。ORでまとめたい場合はor関数などを使用します。

条件式の例：StatusがPendingのときだけ

式をコピーする前に、必ず実際のTrigger出力（payload）を確認してください。 SharePoint列の内部名・大文字小文字・値の型は環境ごとに異なります。下記の['Status']?['Value']は、内部名がStatusで、単一Choice列がValueを含むオブジェクトとしてTrigger payloadに表れる場合だけの例です。実際の出力が文字列だったり、内部名や値が異なれば式を修正する必要があります。出力を確認しないまま貼り付けないでください。

@equals(triggerBody()?['Status']?['Value'], 'Pending')

環境によってStatusが単純文字列として返る場合や、内部列名が異なる場合があります。この式を全テナント共通の正解として貼り付けないでください。 Triggerの生出力で該当列の形を調べ、正しい内部名・値・型で式を作ります。Condition actionやほかの動的コンテンツの表示名をそのまま流用しないことも大切です。

Microsoft公式：Customize your triggers

5. 条件式を入れた後の安全な確認手順

テスト用のSharePoint Listまたは架空アイテムで、次の3場面を順に確かめます。

これは実施手順の提案です。FineInTheoryが顧客テナントでテストした結果ではありません。実行履歴がない場面はトリガー条件による非起動の可能性もあるため、設定と状態値を照合してください。

運用で一度きりの処理が不可欠なら、同時更新や接続エラー時の再試行も検討が必要です。状態を変えるだけで競合が解消するとは限りません。

6. 再実行が止まらないときのチェック

作成時だけの申請処理なら、そもそも作成＋変更Triggerが適切か検討してください。既存のMicrosoft Lists承認フローの作り方では、作成時Triggerを使う構成を解説しています。

7. 何を節約でき、何を保証しないか

Trigger Conditionsで不要なFlowの起動を抑えれば、Microsoftが説明するPower Platform requestsの消費抑制につながります。ただし、月額いくら節約できるかは契約形態や利用状況に依存し、一律の金額では示せません。

さらに、自己起動ループ以外にも同時実行、外部システムへの書き込み失敗、再試行、他Flowとの連鎖があるため、Trigger Conditionsだけで業務全体の重複処理防止を保証するものではありません。

まだ調べますか？

• 申請・承認業務を具体的に作りたい：Microsoft Lists承認フローの作り方で、新規作成Trigger・承認結果・リスト更新の流れを確認する。
• 接続・ライセンス・運用範囲を整理したい：Power Automateの概要で、導入条件と運用上の責任を確認する。

再実行を抑えたら、今度は処理が失敗したときに誰が気づいて復旧するかを決めておくことが重要です。

公式資料

• Microsoft Learn：Customize your triggers with conditions
• Microsoft Learn：Avoid anti-patterns
• Microsoft Learn：SharePoint connector triggers