【Power Automate】Apply to eachが想定どおり進まない時のDLPポリシーとライセンスの見直し

Power AutomateでApply to eachアクションを使用する際、ループが途中で止まったり、一部のアイテムしか処理されなかったりするトラブルは意外と多く発生します。フロー自体は正しく設計しているのに想定どおり進まない場合、原因は多くの場合、組織のDLPポリシー(データ損失防止ポリシー)やライセンスの制限にあります。これらの要因はフローの実行回数や使用できるコネクタ、ループの反復回数に直接影響を与えるため、事前に把握しておかないと時間を浪費することになります。本記事では、Apply to eachが期待通り動作しない原因をDLPポリシーとライセンスの観点から切り分け、具体的な確認手順や対処方法を解説します。

Apply to eachが想定どおり進まない原因の全体像

Apply to eachが期待通り動作しない原因は、大きく分けて以下の3つに分類できます。

• フロー設計の問題:ループ内のアクションが正しく構成されていない、変数の使い方が誤っている、条件分岐が原因で特定のアイテムだけスキップされるなど。
• DLPポリシーによる制限:組織のデータ損失防止ポリシーが特定のコネクタやアクションをブロックしているため、Apply to eachで使用するサービス(SharePoint、Outlook、SQL Serverなど)にアクセスできない。
• ライセンス不足による制限:Power Automateのプランによっては、Apply to eachの実行回数(API呼び出し回数)や並列処理に上限があり、その上限に達すると途中で停止する。

このうち、DLPポリシーとライセンスは組織の設定に依存するため、個人では解決できないケースがほとんどです。本記事では、この2つに焦点を当てて詳しく解説します。

DLPポリシーがApply to eachに与える影響

DLPポリシーとは

DLPポリシーは、組織内のデータが外部に漏洩するのを防ぐために、Microsoft 365管理センターで設定されるポリシーです。Power Automateにおいては、使用できるコネクタ(サービス)やアクションを制限する役割を持ちます。例えば、SharePointとOutlookのコネクタを同時に使うフローを禁止するポリシーが設定されていると、Apply to each内でSharePointからアイテムを取得してOutlookにメールを送信するようなフローはブロックされます。

DLPポリシーによる制限例

• コネクタの一部ブロック:特定のコネクタ(例:非Microsoft製コネクタ)が全フローで使えない。
• データグループの分離:「ビジネスデータ」と「非ビジネスデータ」を混在させるフローが禁止される。Apply to eachでSharePoint(ビジネス)とTwitter(非ビジネス)を組み合わせるとブロック。
• アクション単位の制限:Apply to each内で特定のアクション(例:HTTP要求)が許可されていない。

DLPポリシーが原因でApply to eachが止まる場合、フローを保存しようとした時点でエラーが発生するか、実行中に「アクションが許可されていません」といったエラーが表示されます。

ライセンス不足が引き起こす動作不良

Power Automateのライセンスと制限

Power Automateにはいくつかのプランがあり、無料のMicrosoft 365ライセンスに含まれる「Power Automate for Microsoft 365」と、有償の「Power Automate Premium」や「Power Automate Process Mining」などがあります。ライセンスによって、Apply to eachの実行に関する以下の制限が異なります。

項目	Power Automate for Microsoft 365	Power Automate Premium
1フローあたりのAPI呼び出し回数(日次)	5,000回	500,000回
Apply to eachの並列処理	非対応(逐次処理のみ)	対応(最大50並列)
1回のApply to eachで処理できる最大アイテム数	100,000件	制限なし(実質的にAPI呼び出し回数の範囲)
プレミアムコネクタの利用	不可	利用可能

例えば、Apply to eachで100,000件を超えるアイテムを処理しようとすると、無料版では上限に達してフローが停止します。また、API呼び出し回数の上限に達した場合も、その日はフローの実行が制限されます。

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

以下の手順で、DLPポリシーとライセンスのどちらが原因かを切り分けてください。

1. フローの実行履歴を確認する:Power Automateポータルで該当フローの「実行履歴」を開き、失敗した実行を選択します。エラーメッセージを確認します。「AccessDenied」「PolicyViolation」などが表示されていればDLPポリシーが原因です。「ApiRequestsExceeded」「QuotaExceeded」などはライセンスの制限を示します。
2. フローを編集して保存を試みる:フローエディターで何も変更せずに保存しようとして、エラーが出る場合はDLPポリシーがブロックしている可能性が高いです。エラーがなければ保存は問題なく、実行時のみエラーが出るならライセンスが原因です。
3. 使用しているコネクタの一覧を確認する:フローで使っているコネクタが、組織のDLPポリシーで許可されているか確認します。Power Automate管理センターの「データポリシー」で確認できますが、一般ユーザーは参照できない場合があります。その場合は管理者に確認を依頼してください。
4. API呼び出し回数をチェックする:フローの「プロパティ」から「API呼び出しの制限」を確認します。現在の使用量が上限に近い場合はライセンスのアップグレードを検討します。
5. ライセンスプランを確認する:自身のPower Automateライセンスが何かを確認します。Microsoft 365管理ポータル(テナント管理者のみ)またはPower Automateポータルの「プラン」から確認できます。
6. Apply to eachの設定を見直す:並列処理の有効化、バッチサイズの調整、フィルターの追加など、設計上の最適化も行います。例えば、一度に大量のアイテムを処理するのではなく、分割して実行することで制限を回避できる場合があります。

具体的な対応策と管理者への依頼

DLPポリシーが原因の場合

DLPポリシーは管理者しか変更できません。以下の情報を整理して管理者に依頼しましょう。

• ブロックされているコネクタまたはアクションの名称
• フローで実現したい処理内容
• ビジネス上の必要性(なぜそのコネクタが必要か)
• 代替案の有無(例:許可されている別のコネクタで代用可能か)

管理者はPower Automate管理センターで「データポリシー」を編集し、特定の環境やユーザーに対して例外ルールを追加することができます。

ライセンス不足が原因の場合

ライセンスのアップグレードも管理者の判断が必要です。以下の情報を準備して依頼します。

• 現在のAPI呼び出し使用量と上限
• フロー1回の実行で消費するAPI呼び出し数の見積もり
• 必要なApply to eachの並列処理や最大アイテム数
• 有償ライセンスの費用対効果の簡単な説明

よくある失敗パターンと対処例

• Apply to eachが最初の1件だけ処理して停止する:多くはAPI呼び出し回数の制限(ライセンス)が原因です。実行履歴で「QuotaExceeded」を確認し、管理者にライセンスアップグレードを依頼します。または、フローを複数のサブフローに分割して実行回数を減らします。
• 「アクション’Apply_to_each’は許可されていません」と表示される:DLPポリシーがApply to eachアクション自体をブロックしている可能性があります。これは非常に稀ですが、管理者にポリシーの確認を依頼します。
• フロー保存時に「ポリシー違反」のエラーが出る:DLPポリシーが原因です。使用しているコネクタの組み合わせが禁止されています。管理者にポリシー変更を依頼するか、コネクタを変更します。
• 処理が異常に遅い:ライセンスが無料版で並列処理ができないため、大量アイテムの逐次処理で時間がかかります。Premiumライセンスへのアップグレードを検討します。

よくある質問(Q&A)

Q: DLPポリシーとライセンス、どちらの影響が先に現れますか?

A: DLPポリシーはフローの保存時または実行開始直後にエラーとなります。ライセンス制限は実行中、特に多くのAPI呼び出しを行うApply to eachで顕著に現れます。

Q: 管理者に依頼するときのテンプレートはありますか?

A: 以下のような文面を参考にしてください。「[フロー名]のApply to eachでDLPポリシー違反(またはライセンス制限)が発生しています。具体的には[コネクタ名]がブロックされており、[理由]のため許可が必要です。代替案はありません。ポリシーの変更またはライセンスアップグレードをご検討ください。」

Q: ライセンスが原因の場合、フローの設計で回避できますか?

A: 部分的に回避可能です。例えば、Apply to eachのアイテム数をフィルターで減らす、複数のフローに分割して1日あたりのAPI呼び出しを分散する、またはフローをトリガーごとに分割するなどの方法があります。ただし、根本的な解決にはなりません。

まとめ:再発防止のために

Apply to eachが想定どおり進まない原因の多くは、DLPポリシーとライセンスの制限に集約されます。フローを設計する段階で、事前に組織のDLPポリシーと自身のライセンスプランを確認しておくことが最も効果的な対策です。また、大量のデータを処理する場合は、最初から有償ライセンスを申請するか、管理者と調整しておくと後悔しません。原因を切り分ける際は、エラーメッセージと実行履歴を丁寧に確認し、管理者に依頼する情報を整理してから連絡することで、解決までの時間を大幅に短縮できます。

🔐

会社アカウント・認証トラブル完全解決データベース 職場または学校アカウント、MFA、Authenticator、VPN、権限、会社ポリシーで止まる問題を横断的に確認できます。