Power Automateのフローが403やSuspendedになったとき、接続を作り直したり別のコネクタへ置き換えたりする前に、接続先の権限不足と組織のデータ損失防止（DLP）ポリシーを切り分けてください。Microsoftの公式資料では、DLPポリシーがコネクタの利用や組み合わせを制限し、フローの設計時だけでなく実行時にも影響する場合が説明されています。対象resourceにアクセスする権限がないケースと、ポリシー上そのデータ経路が許されないケースは、同じ403に見えても対応が違います。makerがポリシーを回避するconnectorへ置き換えるのではなく、run historyと環境管理者のpolicy確認から始めます。
目次
【最初に記録する情報】
対象環境、flow名、失敗時刻、run ID、Trigger、失敗したAction、エラー全文のうち機密を除いた部分、直近の変更、他のフローにも同時に影響があるかを記録します。スクリーンショットやrun historyを共有するときは、個人情報・token・接続名に含まれる機密識別子をマスキングします。エラー表示だけで原因を確定せず、発生時刻と対象environmentが分かる状態にします。
【403の切り分け】
Microsoft Learnのクラウドフローエラー参照では、403の原因例として、DLPがconnectorまたはactionをブロックしていること、ユーザーがtarget resourceの権限を持たないこと、テナント設定による制限、premium licenseの条件などが挙げられています。このため「403＝SharePoint権限不足」と決めつけられません。次の順に、同じ実行の失敗Actionを調べます。
- Run historyで最初に失敗した処理を特定する
最終Actionの赤い表示だけでなく、最初の失敗位置と直前の出力を確認します。共通のwrapper errorではなく、Actionのoutputにある実際のstatus、message、request IDなど、管理者へ必要な診断情報を取得します。値や本文に顧客情報が含まれる場合は共有前に伏せます。
- Connectionの健全性を確認する
接続が無効、認証期限切れ、再認証要求中でないかを確認します。接続エラーならconnection ownerまたは管理者が認証状態を直す経路へ進みます。ただし、connectionが正常と表示されても、DLP制限や接続先のresource権限が十分とは限りません。
- 実行主体とtarget resourceを確認する
そのActionがどのconnectionで動くかを調べ、対象ユーザーまたはconnection ownerのどちらの権限でresourceへアクセスするのかを明確にします。SharePointのサイト・リスト、Dataverseのテーブル、ファイルなど、対象と操作（read/create/update/delete）を列挙します。接続主体が直接resourceを開けるかを、フロー外でも安全なテストデータで確認します。
- DLP policyの適用を管理者へ照会する
環境管理者に対象environmentとflow、connector/action、発生時刻を伝え、tenant-levelまたはenvironment-levelのdata policyが対象をblockしているか、connector groupingの組み合わせに抵触していないか確認を依頼します。maker権限だけではpolicyの全体像を見られない場合があるため、管理者の確認なしにpolicy変更を試みません。
- 契約・ライセンス条件を別に確認する
エラーが示す場合や対象connectorがpremium条件を含む場合、現在の利用者・flow・接続方式の契約をライセンス担当者へ確認します。DLP policy、認証、target permission、licenseを一つの「権限問題」にまとめず、それぞれの判断主体へ渡します。
【診断表】
症状 | 次に見る証拠 | 管理者へ渡す質問
保存時にflowがSuspended | designerのpolicy conflict、environment、connector組み合わせ | どのdata policyが適用され、どの接続の組み合わせが違反か
実行時に開始できない | run history、失敗Action、policy error、変更時刻 | 既存flowへ変更されたpolicyがruntime enforcementされたか
特定のActionだけ403 | target resource、接続主体、resource permission | 接続主体はその操作をresourceで許可されているか
同じ環境で複数flowが停止 | 複数run ID、共通connector、policy変更時刻 | 共通のenvironment/tenant policy変更があったか
connection認証エラー | connection状態、再認証表示、認証ログ | 接続資格情報やOAuth認可が失効していないか
この表は調査の分岐であって、症状だけから特定のpolicyを断定するものではありません。
【DLPによる制限が疑われるとき】
まずpolicyのscopeを確認します。DLPが環境単位かテナント単位か、対象のenvironmentがどれか、該当するconnectorがどのdata groupに分類されているかを管理者に確認します。複数のconnectorを組み合わせたflowでは、一つのconnectorがBlockedか、Business / Non-businessなどの分類が衝突しているか、Action単位の制御があるかを調べます。policyの変更は同じenvironmentの他flowやappに影響し得るため、今回止まったflowだけを見て即時に例外を追加するのではなく、影響対象とデータの流れを管理者が評価します。
Microsoftは、data policyに反するflowが保存時にSuspendedとなったり、後のpolicy変更が既存のflowに影響したりするケースを説明しています。またSuspendedへの反映はpollingで処理され、変更が即時に見えない場合があります。したがって「policy変更直後に動いた／動かなかった」だけで適合性を決めず、管理者が適用policyの状態とflowの最新評価を確認します。反映待ちの時間は環境・処理状況に依存するため、固定の待ち時間を前提にしません。
【権限不足なら最小範囲を確認】
DLPに違反せずconnectionも有効で、target resourceの権限が原因と確認できた場合は、その接続主体に必要な最小の権限だけを検討します。SharePointサイト全体への広い権限ではなく、必要なリストや操作に限定できるかを管理者と確認します。フローの所有者を増やしても、resource権限が自動で付与されるとは限りません。逆に、所有者の広い接続を共有する方式では、実行者が直接アクセスできないデータをflowが扱うこともあるため、業務上許可されたデータ範囲・監査責任・承認者を確認します。
【回避せずに復帰する手順】
・flowの実行を止めたまま、失敗runとpolicy/permission evidenceを保全する。
・makerはflow全体を書き換えず、管理者へ対象environment、connector/action、run ID、直近変更を共有する。
・環境管理者はpolicy scope、connector分類、適用時刻、他flowへの影響を確認する。
・resource管理者は接続主体と対象resourceの必要権限を別に確認する。
・原因がDLPなら、承認済みpolicy変更または適合するflow設計を、権限者が決定する。
・原因が認証なら対象connectionの安全な再認証を担当者が行う。
・原因がresource権限なら最小範囲の付与を検討し、記録する。
・テストenvironmentまたは機密を含まないtest dataで、flow・data boundary・run historyを再検証する。
・管理者がpolicy適合と実行結果を確認してから運用再開する。
DLP制限を避けるために、別のpersonal connector、HTTP、任意の外部endpointへ置き換えるのは解決ではありません。データ経路や監査可能性を変え、policyの意図を損なう可能性があります。コネクタの変更が必要なら、業務目的、データ分類、送信先、認証主体、ログ、保管先を管理者とsecurity担当がレビューしてから実施します。
【管理者へ渡す記録】
Environment：＿＿ Flow ID / name：＿＿
発生日時・policy変更の心当たり：＿＿
Run ID：＿＿ Trigger：＿＿ 最初の失敗Action：＿＿
エラー種別（秘密を含めない）：＿＿
Connection名・主体・状態：＿＿
接続先resourceと必要操作：＿＿
同一環境の他flowへの影響：＿＿
DLP確認者／適用policy scope／該当connector：＿＿
resource権限確認者／結果：＿＿
次の安全なテスト条件・承認者：＿＿
この記録には、connection secret、個人データを含むrun input、顧客レコードを貼りません。管理者が必要とするIDと時刻を伝え、詳細はアクセス制御された管理画面で確認してもらいます。
【次の行動】
問題が起きた実行のrun IDを一つ選び、最初に失敗したAction、connection主体、target resourceを記録します。そのうえで、environment管理者へdata policyのscopeと該当connector/actionを確認してもらい、resource管理者には接続主体のアクセスを別に見てもらいます。原因が一つに確定してから、権限ある担当が修正案を選びます。flowを迂回connectorへ差し替える前に、変更の影響範囲とデータ境界が保たれることを確認してください。
Sources（確認日：2026-10-15）
・Microsoft Learn, Impact of data policies on apps and flows: https://learn.microsoft.com/en-us/power-platform/admin/dlp-impact-policies-apps-flows（新しいタブで開く）
・Microsoft Learn, Cloud flow error code reference: https://learn.microsoft.com/en-us/power-automate/error-reference（新しいタブで開く）
・Microsoft Learn, Fix connection failures in cloud flows: https://learn.microsoft.com/en-us/power-automate/fix-connection-failures（新しいタブで開く）
・Editorial Note: Microsoft Learnのdata policy impact / error referenceを確認。HTTP 403はDLPだけでなくresource permissions、tenant restrictions、license等も原因候補。実テナントでの診断・実行テストは行っていない。