【Power Automate】JSON解析が想定外に繰り返される時の会社環境での安全な再設定

Power AutomateでJSON解析を利用する際、フローが想定外に繰り返される問題に遭遇することがあります。ループが止まらず、大量の実行が発生して課金やパフォーマンスに影響を与えるケースです。会社の環境では、この問題を安全に解決するために原因を正しく切り分けることが重要です。ここでは、JSON解析が繰り返される原因を分解し、適切な再設定方法を解説します。

想定外にJSON解析が繰り返される原因

JSON解析が想定外に繰り返される主な原因は、フローのトリガーが発火した後にJSON解析結果を用いて何らかのアクションを起こし、そのアクションが再度同じトリガーを呼び出すループ構造にあることです。例えば、 SharePoint に新しいファイルが追加されたときにJSONを解析し、解析結果を別のファイルに書き込むと、その書き込みが新しいファイルの追加としてトリガーされるケースです。また、HTTP要求の応答JSONを解析してデータベースを更新し、その更新がトリガーになる場合も同様です。

会社環境では、複数のユーザーが同じフローを共有している場合や、コネクタの権限が広範に設定されている場合に問題が顕在化しやすいです。具体的には、トリガー条件が不十分で「すべての変更」をキャッチしている、JSON解析後のアクションで使用するコネクタが書き込み権限を持っているため、書き込みが新たなイベントを生成する、といったパターンです。

トリガー条件の設定ミス

トリガー条件が緩いと、わずかな変更でもフローが起動します。例えば、SharePointの「ファイルが作成または変更されたとき」トリガーで、特定のライブラリを指定していても、条件フィルターを追加していなければ、同じライブラリ内のあらゆるファイル変更に反応してしまいます。JSON解析が繰り返される場合、このトリガーが発火→JSON解析→別のファイルを作成→再トリガーという悪循環が発生します。

JSON解析後のアクションが再トリガーを引き起こす

JSON解析の結果をもとに別のシステムに書き込みを行うと、その書き込みがトリガー条件に合致してしまう場合があります。代表例は、Microsoft Teamsにメッセージを投稿するアクションです。Teamsのメッセージが作成されたことをトリガーにしているフローだと、自分が投稿したメッセージにも反応して無限ループに陥ることがあります。

並列処理の制御不足

Power Automateのフローはデフォルトで並列実行が有効になっている場合があります。JSON解析の処理が完了する前に次のトリガーが発火し、重複した実行が連鎖して繰り返される現象です。通常は同時実行数の制限(コンカレンシー制御)を設定することで回避できますが、設定を忘れていると想定外の繰り返しが発生します。

原因を切り分けるための確認手順

問題の原因を特定するには、まずフローの実行履歴を確認します。Power Automateポータルの「実行」タブから、繰り返し発生しているフロー実行を開き、各アクションの入出力を調べます。特に、JSON解析アクションの出力が後続のアクションでどのように使われているかを追跡してください。

1. フローの実行履歴を開く: Power Automateポータルにサインインし、該当フローの「実行」タブをクリックします。過去の実行一覧が表示されます。
2. 繰り返し実行を特定する: 同じトリガーが短時間に複数回実行されているものを選びます。例えば、1分間に10回以上実行されている場合、問題の可能性が高いです。
3. アクションの入出力を確認する: 実行を開き、JSON解析アクションの「入力」と「出力」を確認します。JSONの構造が想定通りか、後続アクションで更新が発生しているかを見ます。
4. トリガー条件をチェックする: フローの編集画面でトリガーの設定を開き、「トリガー条件」が適切に設定されているか確認します。特に、フィルタークエリや条件式がある場合は、それがループを防げているか検証します。
5. コンカレンシー設定を確認する: フロー設定の「同時実行数の制限」を確認します。デフォルトは「無制限」になっている可能性があり、ここを「1」に設定すると直列実行になるため、ループの連鎖を抑制できます。
6. テスト環境で再現する: 修正前に、フローのコピーを作成し、テスト用のトリガー条件で同じ現象が発生するか試します。会社環境では、本番フローを直接編集せず、必ずテストを行ってください。

実行履歴で見るべきポイント

実行履歴の詳細画面では、各アクションの「ステータス」と「出力」が重要です。JSON解析アクションが成功していても、後続のアクションが期待通りの変更をシステムに与えているか確認します。もし後続アクションがシステムに変更を加えた結果、その変更がトリガー条件を満たしているなら、それがループの原因です。

安全な再設定の具体的な手順

原因が特定できたら、安全に再設定を行います。以下の手順は会社環境でも適用できる安全な変更方法です。フローをオフにしてから編集し、テストを経てから再度有効化することを推奨します。

1. フローを無効化する: Power Automateポータルで該当フローを開き、画面上部の「無効化」をクリックします。これで新しいトリガーは発生しなくなります。
2. トリガー条件を強化する: トリガーの設定で「高度なモード」を有効にし、条件式を追加します。例えば、SharePointリストを使う場合、「@triggerOutputs()?[‘body/Modified’]」をチェックして、自分自身の変更を除外する条件を加えます。
3. JSON解析の出力をキューに入れる: Visual Studioの開発者であれば、JSON解析結果を変数に格納し、その変数を使ってループ検出ロジックを組み込むことができます。例えば、変数に解析結果のハッシュを保存し、同じ値が連続したらフローを中断する条件分岐を追加します。
4. コンカレンシー制限を設定する: フロー設定の「同時実行数の制限」を「1」に変更します。これにより、フローが直列実行され、前の実行が完了するまで次の実行が開始されなくなります。
5. テストフローで動作確認: フローのコピーを作成し、テスト環境で同じトリガーを発生させます。JSON解析が繰り返されないことを確認したら、本番フローに反映します。
6. 段階的に有効化する: 本番フローを再度有効化する前に、監視ログを有効にし、最初の数時間は実行状況を逐一確認します。異常があればすぐに無効化できるように準備します。

フローの無効化とコピー作成の注意

会社環境では、フローを無効化する権限がない場合があります。その場合は、管理者に連絡して一時的に無効化してもらうか、影響を最小限に抑えるためにトリガー条件を一時的に空にしてフローを実質停止させる方法もあります。ただし、トリガー条件を空にするとフローが停止するわけではなく、すべてのイベントで起動するようになるため注意が必要です。正しくは、トリガー条件に常にfalseになる式(例えば「1==0」)を設定します。

各トリガー別の注意点と比較

トリガーの種類によって、JSON解析が繰り返される原因と対策は異なります。以下の表で主なトリガーと推奨対策をまとめました。

トリガーの種類	繰り返しが発生しやすいシナリオ	推奨対策
SharePoint – ファイルが作成または変更されたとき	JSON解析結果を同じライブラリに書き込むと無限ループ	トリガー条件でファイル名パターンを絞る、書き込み先を別の場所にする
Outlook – 新しいメールが届いたとき	JSON解析後にメールを送信すると、その送信が再トリガーになる	トリガー条件に「自分が送信者でない」フィルターを追加、コンカレンシー制限を1にする
HTTP要求 – 要求が受信されたとき	JSON解析結果を元にHTTP応答を返すと、呼び出し元が再送信する可能性	一意の識別子を要求に含めて重複を検出、またはステートレスな処理にする
スケジュール – 指定した時刻	JSON解析結果の処理時間が長く、次のスケジュールと重複する	スケジュール間隔を長くする、同時実行数の制限を設定する

よくある失敗パターンと回避策

実際の現場でよくある失敗パターンをいくつか紹介します。これらを事前に知っておくことで、同様の問題に迅速に対処できます。

JSON解析の結果を直接トリガー条件に使おうとする失敗

トリガー条件はJSON解析よりも前に評価されるため、解析結果を条件に使うことはできません。そのため、JSON解析後のアクションでトリガー条件を動的に変えようとする試みは無効です。回避策として、フローを二段階に分け、最初のフローではトリガー条件をシンプルにし、解析結果をキューや一時ファイルに保存して、別のフローでその内容を処理する方法があります。

オブジェクトの比較で予期せぬループ

JSON解析で取得したプロパティを後続の条件分岐で使う場合、期待する値と実際の値が微妙に異なり(改行やスペースの違いなど)、条件が成立せずに次のアクションが実行されないと思いきや、逆に条件が常に真になってループするケースがあります。これを防ぐには、JSON解析の出力を正規化(例:trimやreplace)してから比較するアクションを追加します。

テスト環境を本番と同じにできない失敗

会社環境では、テスト環境と本番環境でコネクタの権限やデータ量が異なるため、テストで問題が再現しないことがあります。その場合は、本番フローの実行履歴を詳細に分析し、トリガー条件をさらに厳しくするしかありません。また、本番フローに「実行回数制限」や「条件付きトリガー」を追加して、明らかに異常な実行を自動停止する仕組みを組み込むことも有効です。

管理者へ確認すべき設定

会社のPower Automate環境では、管理者が設定するデータ損失防止ポリシー(DLP)やコネクタの使用制限が、JSON解析の動作に影響を与える場合があります。以下の項目を管理者に確認してください。

• コネクタの許可リスト: 使用しているコネクタ(例えば、SharePointやSQL Server)がDLPポリシーで許可されているか。許可されていないとフローが正常に動作しないか、実行がブロックされてループに見えることがあります。
• 同時実行数の制限に関するテナント設定: テナント全体でフローの同時実行数に上限が設定されている場合があります。その上限を超えるとフローがキューイングされ、あたかも繰り返しているように見えることがあります。
• フロー共有の権限: 他のユーザーが誤ってフローを編集したり有効化したりしないよう、編集権限を制限する必要があります。管理者に依頼して、フローの所有者を最小限にしてください。
• 監査ログの有効化: 何がトリガーになったのかを追跡するために、監査ログが有効になっているか確認します。監査ログがあれば、誰がいつどんな変更をしたかが分かり、問題の特定が容易になります。

よくある質問

• Q: JSON解析が繰り返されるのを防ぐために、フローにループカウンターを追加できますか?
  A: 可能です。変数にカウンターを持たせ、一定回数を超えたらフローを終了する条件分岐を追加します。ただし、Power Automateの無料枠では変数の使用に制限があるため、会社のライセンスを確認してください。
• Q: フローを無効化しても実行履歴が残るのはなぜですか?
  A: フローを無効化しても、既にトリガーされた実行は完了するまで続きます。完全に停止するには、全ての実行が終了するのを待つか、アクティブな実行をすべてキャンセルする必要があります。
• Q: JSON解析のエラーが原因でループが発生することはありますか?
  A: まれに、JSON解析がエラーになった場合に後続アクションがスキップされ、エラーハンドリングが原因でループすることがあります。エラー時の処理に「再試行」を設定していると、その再試行が連続して発生し、ループのように見えることがあります。

まとめ

Power AutomateでJSON解析が想定外に繰り返される問題は、トリガー条件の設定ミスや後続アクションによる再トリガー、並列実行の制御不足が主な原因です。原因を切り分けるには、実行履歴の詳細確認から始め、トリガー条件とコンカレンシー設定を重点的にチェックします。安全な再設定のためには、フローを無効化してから編集し、テスト環境で検証してから本番に反映する手順が確実です。会社環境では管理者との連携が不可欠な場合もあるため、必要な情報を事前に共有しておくことで、迅速な解決につながります。