Power Platform Managed Identityの価値は、DataverseプラグインやPower Automate連携に埋め込まれがちなクライアントシークレット、APIキー、共有パスワードを「安全に保管する」のではなく、そもそも持たない設計へ移せる点にあります。
2026年4月20日のMicrosoft Security Blogでは、Microsoftが「認証情報の排除」を重要なセキュリティ設計として取り上げ、Power Platform Managed IdentityがDataverse pluginsやPower AutomateなどのPower Platformコンポーネントにテナント所有のIDを与え、埋め込みパスワードやクライアントシークレットではなくフェデレーション資格情報でAzureリソースへ認証できると説明しています。これにより、シークレット期限切れによる停止、過剰なアプリ登録申請、監査しにくい共有資格情報といった現場の摩擦を減らせます。(Microsoft)
ただし、導入時に最初から全フローを置き換えようとするのは危険です。現時点で実装パスが明確なのはDataverseプラグインで、Microsoft LearnではDataverse plug-insとdependent assembly plug-insがPower Platform Managed Identityのサポート対象としてGAと記載されています。一方、Power AutomateではカスタムコネクタのManaged identity authenticationがプレビューとして展開中であり、テナントやUXによって見え方が異なる可能性があります。まずはDataverseプラグインや重要なカスタムコネクタから段階的にシークレットレス化するのが現実的です。(Microsoft Learn)
Power Platform Managed Identityは「シークレットを隠す仕組み」ではなく「シークレットをなくす仕組み」
従来のPower Platform連携では、外部APIやAzureリソースへ接続するために、次のような資格情報をどこかに持たせることが一般的でした。
- DataverseプラグインのSecure Configurationにクライアントシークレットを保存する
- Power AutomateのHTTPアクションやカスタムコネクタにAPIキーを設定する
- 環境変数やKey Vault参照でシークレットを管理する
- サービスアカウントのパスワードを接続に使う
- Azure AD、現在のMicrosoft Entra IDのアプリ登録に長期のシークレットを作成する
これらは一見すると管理できているように見えますが、実務では「誰が更新するのか」「期限切れ前に検知できるのか」「漏えい時にどのフローが影響を受けるのか」が問題になります。MicrosoftのPower Platform Well-Architected Securityガイダンスでも、クラウドフロー、キャンバスアプリ、構成ファイル、デプロイパイプラインにシークレットをハードコードしないことが推奨されています。(Microsoft Learn)
Power Platform Managed Identityは、この問題を保存場所の工夫ではなくID設計で解決します。ワークロード自身にMicrosoft Entra ID上のIDを持たせ、必要なときにトークンを取得して、許可されたAzureリソースやAPIへアクセスします。Microsoft EntraのマネージドIDは、アプリケーションが資格情報を管理せずにMicrosoft Entraトークンを取得できる仕組みで、アクセスキー、パスワード、証明書などの代替として使えます。(Microsoft Learn)
従来のクライアントシークレット方式との違い
| 観点 | 従来のクライアントシークレット方式 | Power Platform Managed Identityを使う方式 |
|---|---|---|
| 認証情報の扱い | シークレット、APIキー、証明書を保存・配布・更新する | Power Platform側のワークロードIDでトークンを取得する |
| 期限切れリスク | シークレット期限切れでフローやプラグインが停止しやすい | クライアントシークレットのローテーション負荷を減らせる |
| 監査 | 誰の接続か、どの処理が使ったか分かりにくい場合がある | Microsoft Entra ID上のワークロードIDとして追跡しやすい |
| 権限設計 | 共有シークレットに広い権限を付けがち | 環境・用途ごとに最小権限を割り当てやすい |
| ガバナンス | 作成者がアプリ登録やシークレット発行を都度依頼しがち | 管理者が標準ID、フェデレーション資格情報、RBACをテンプレート化しやすい |
| インシデント対応 | 漏えい時にシークレット再発行と接続更新が必要 | 対象IDの権限停止・削除で封じ込めやすい |
重要なのは、Managed Identityにするとセキュリティ対策が不要になるわけではない点です。シークレット管理の負担は減りますが、代わりに「どのIDに、どのスコープで、どのリソースへの権限を与えるか」が設計の中心になります。
Dataverseプラグインでは何ができるのか
Dataverseプラグインでは、Power Platform Managed Identityを使って、資格情報を管理せずにAzure Key Vault、Azure Storage、独自APIなどのMicrosoft Entra認証対応リソースへ接続できます。Microsoft Learnでは、Power Platform Managed IdentityがDataverse plug-insからAzure Managed IdentityをサポートするAzureリソースへ安全に接続できる仕組みであり、ユーザー割り当てマネージドIDまたはアプリ登録にフェデレーションID資格情報を構成すると説明されています。(Microsoft Learn)
たとえば、受注レコードの作成時にDataverseプラグインが動き、Azure Storageへ監査ログを書き込むケースを考えます。従来はプラグイン内に接続文字列やKey Vaultへアクセスするためのシークレットを持たせることがありました。Managed Identityを使うと、プラグインは自身のIDでトークンを取得し、Azure Storage側ではそのIDに必要最小限のロールだけを付与できます。
Microsoftのセットアップ手順では、DataverseプラグインまたはプラグインパッケージでManaged Identityを使うために、アプリ登録またはユーザー割り当てマネージドIDの作成、フェデレーションID資格情報の構成、プラグイン登録、Dataverseのmanaged identityレコード作成、Azureリソースへの権限付与、統合検証を行う流れが示されています。(Microsoft Learn)
Dataverseプラグインでの基本構成
| 構成要素 | 役割 | 実務上の判断基準 |
|---|---|---|
| Microsoft Entra IDのアプリ登録またはUAMI | プラグインが使うワークロードID | 環境別、用途別に分ける。複数業務で使い回しすぎない |
| フェデレーションID資格情報 | Dataverseプラグインからのトークン要求を信頼する設定 | issuer、subject、audienceを正確に合わせる |
| 署名済みプラグインアセンブリ | プラグイン自体の識別に使われる | 本番では自己署名証明書を避け、信頼された発行元を使う |
| Dataverse managed identityレコード | Dataverse側でIDをプラグインに関連付ける | ALM時に環境ごとの差し替えを設計する |
| Azure RBACまたはAPI権限 | 対象リソースへの実アクセス制御 | Key Vaultなら必要なシークレットだけ、Storageなら必要なコンテナーだけに絞る |
プラグイン側では、IManagedIdentityServiceのAcquireToken(IEnumerable<string> scopes)を使ってスコープに対するトークンを取得する形が示されています。これは「プラグインに秘密情報を読ませる」のではなく、「プラグインが許可されたIDとしてトークンを取得する」考え方です。(Microsoft Learn)
var managedIdentityService = (IManagedIdentityService)serviceProvider.GetService(typeof(IManagedIdentityService));
var token = managedIdentityService.AcquireToken(
new[] { "https://vault.azure.net/.default" }
);
// 取得したBearerトークンを使って、許可されたAzureリソースへアクセスするこのコード例は考え方を示すものです。実装時は対象リソースのSDK、例外処理、タイムアウト、監査ログ、再試行方針を必ず組み込みます。
Power Automateではどう使うべきか
Power Automateでのポイントは、「すべてのフローがすぐManaged Identityだけで直接外部APIへ接続できる」と考えないことです。現実的には、次の3つのパターンに分けて設計します。
| 利用シーン | 推奨パターン | 向いている理由 |
|---|---|---|
| Dataverseのイベントを起点にAzureリソースへ接続する | Power AutomateではなくDataverseプラグイン側に処理を寄せ、Power Platform Managed Identityを使う | GAの実装パスが明確で、サーバー側処理として統制しやすい |
| Power Automateから独自APIを呼ぶ | カスタムコネクタのManaged identity authenticationを検証する | シークレットをコネクタに保存せずに済む可能性がある |
| フローから複数の外部サービスを横断する | Azure API Management、Azure Functions、Dataverse Custom APIなどを中継し、その裏側でManaged Identityを使う | フローに資格情報や複雑な認可ロジックを持たせず、API側で統制できる |
Microsoft Learnでは、Power AutomateのカスタムコネクタでMicrosoft Entra ID認証を使う手順の中に、Managed identity authenticationがプレビューとして記載されています。説明では、クライアントシークレットの代わりにManaged Identityを使えるため、シークレット期限が近づくたびにローテーションする負担を避けられる一方、プレビューで段階的に展開中であり、UX上まだ選択肢が見えない場合があるとされています。また、クライアントアプリケーションはシングルテナントである必要があり、Tenant IDにはcommonではなく実際のテナントGUIDを使う必要があります。(Microsoft Learn)
Power Automate管理者が最初に見るべきなのは、「どのフローにシークレットがあるか」ではなく、「そのシークレットを本当にフローが持つ必要があるか」です。業務フローの中にHTTPアクション、カスタムコネクタ、接続参照、環境変数、Key Vault参照が散在している場合、すべてを個別に修正するより、重要なAPIアクセスをDataverseプラグインや中継APIへ集約した方がガバナンスは楽になります。
ガバナンス摩擦を減らす理由
Power Platform Managed Identityが注目される理由は、単にセキュリティが強くなるからではありません。Power Platform admins、enterprise architects、security engineersの間に起きやすい摩擦を減らせるからです。
よくある摩擦は次のようなものです。
| 現場で起きる摩擦 | Managed Identityで変わること |
|---|---|
| 作成者が「APIを呼びたいのでクライアントシークレットをください」と依頼する | 管理者が用途別のワークロードIDと権限を払い出せる |
| セキュリティ担当が「そのシークレットは誰が保管するのか」と差し戻す | シークレットを配布しない設計にできる |
| シークレット更新のたびにフロー、環境変数、コネクタを修正する | 認証情報のローテーション作業を大幅に減らせる |
| 本番障害の原因が「期限切れのシークレット」だった | 期限切れシークレット由来の停止リスクを下げられる |
| どの自動化がどの権限で動いているか不明 | Microsoft Entra IDのワークロードID単位で管理しやすい |
Microsoft Security Blogでも、埋め込みパスワードやクライアントシークレットではなくフェデレーション資格情報を使うことで、期限切れシークレットによる停止を減らし、アプリ登録を作成する権限がない作成者のブロックを解消しやすくなると説明されています。(Microsoft)
ただし、Managed Identityを「作成者が自由に強い権限を持てる仕組み」として使うと逆効果です。管理者側が標準パターンを先に用意し、作成者はその範囲で利用する形にする必要があります。
導入に向いているケース、まだ慎重に見るべきケース
| 判断項目 | 導入に向いている | 慎重に検討すべき |
|---|---|---|
| 対象処理 | DataverseプラグインからAzureリソースを呼ぶ | すべてのPower Automateフローを一括移行する |
| 認証方式 | Microsoft Entra ID認証に対応しているAPI | APIキーしか対応していない外部SaaS |
| 権限管理 | Azure RBACやアプリロールで最小権限を設定できる | 共有管理者権限でしか動かない |
| 運用課題 | シークレット期限切れ、漏えいリスク、監査不備が課題 | 現在の接続が小規模で、変更リスクの方が大きい |
| 組織体制 | Entra ID、Power Platform、Azure管理者が連携できる | アプリ登録やRBACの責任者が不明 |
最初のパイロットには、次のような処理が向いています。
- DataverseプラグインからAzure Key Vault、Storage、Service Bus、独自APIへ接続している
- クライアントシークレットの期限切れで過去に障害が起きた
- 本番環境のフローにHTTPアクションやカスタムコネクタが多い
- ISVまたは内製ソリューションを複数環境へ展開している
- セキュリティレビューで「シークレットの保管場所」が毎回論点になる
逆に、外部SaaSがAPIキーしか対応していない場合は、Power Platform Managed Identityだけで完全なシークレットレス化はできません。その場合は、API ManagementやAzure Functionsを中継し、Power Platform側にはシークレットを持たせない構成を検討します。
実務での導入手順
シークレット棚卸しから始める
最初にやるべきことは、機能追加ではなく棚卸しです。対象はDataverseプラグインだけではありません。Power Automateのクラウドフロー、カスタムコネクタ、環境変数、接続参照、デプロイパイプライン、プラグイン構成をまとめて確認します。
| 棚卸し項目 | 確認内容 |
|---|---|
| 保存場所 | フロー、カスタムコネクタ、環境変数、プラグインSecure Configuration、Key Vault、パイプライン |
| 種類 | クライアントシークレット、APIキー、接続文字列、証明書、ユーザー名・パスワード |
| 期限 | 有効期限、更新担当者、期限切れ通知の有無 |
| 利用範囲 | どのフロー、プラグイン、環境、ソリューションが使っているか |
| 代替可能性 | Microsoft Entra ID認証、Managed Identity、RBAC、アプリロールに置き換えられるか |
この段階で、URLや環境名などの非機密情報まで「シークレット」として扱っている場合は整理します。Microsoftのガイダンスでも、API URLなどの非シークレット設定はアプリケーションコードやシークレットとは分け、環境変数やDataverseテーブルなどで管理する選択肢が示されています。(Microsoft Learn)
パイロット対象を選ぶ
最初の対象は、影響範囲が狭く、効果が分かりやすいものを選びます。おすすめは、DataverseプラグインからAzure Key VaultやStorageへアクセスしている処理です。理由は、Power Platform Managed Identityの公式手順が明確で、対象リソース側の権限もAzure RBACで管理しやすいからです。
選定時は次の条件を満たすものを優先します。
| 条件 | 理由 |
|---|---|
| 本番影響が限定的 | ロールバックしやすい |
| 現在シークレットを使っている | 効果を測定しやすい |
| 接続先がMicrosoft Entra ID認証に対応している | Managed Identityの強みを活かせる |
| 所有者が明確 | 権限設計とテストが進めやすい |
| ALM対象になっている | 開発、検証、本番の差分管理を確認できる |
ID設計を決める
Managed Identity導入で最も重要なのは、IDの粒度です。便利だからといって、1つのIDをすべてのプラグインやフローに使い回すと、監査性と最小権限が失われます。
おすすめは「環境 × 用途」で分ける設計です。
| ID設計 | 例 | 評価 |
|---|---|---|
| 全社で1つのID | pp-global-mi | 避けたい。権限が肥大化し、監査しにくい |
| 環境ごとに1つのID | pp-prod-mi | 小規模なら可。ただし用途が増えると権限が広がる |
| 環境 × 業務機能ごと | pp-prod-order-keyvault-mi | 実務で扱いやすい |
| プラグインごとに完全分離 | pp-prod-order-plugin-mi | 高機密処理では有効。ただし管理対象が増える |
セキュリティ重視の本番環境では、少なくとも開発・検証・本番でIDを分けます。検証環境のIDが本番Key Vaultを読める、といった構成は避けるべきです。
フェデレーションID資格情報を構成する
Power Platform Managed Identityは、Microsoft Entra IDのワークロードIDフェデレーションと密接に関係します。ワークロードIDフェデレーションでは、外部ワークロードからのトークンをMicrosoft Entra IDが信頼し、アプリ登録またはユーザー割り当てマネージドIDに対するアクセストークンへ交換します。これにより、シークレットや証明書を手動で管理する負担と、期限切れや漏えいのリスクを減らせます。(Microsoft Learn)
Dataverseプラグインの場合、フェデレーションID資格情報ではissuer、subject、audienceの整合性が重要です。Microsoft Learnでは、パブリッククラウドやGCCなどの既定値に加え、GCC High & DoD、中国クラウド、US National、US Secureなど特殊なAzureクラウド環境ではAudience、Issuer URL、Subject prefixを明示的に設定する必要があると説明されています。グローバル展開している企業では、この差異をALMテンプレートに入れておかないと、特定リージョンだけ認証できない問題が起きます。(Microsoft Learn)
プラグインまたはカスタムコネクタに関連付ける
Dataverseプラグインでは、プラグインアセンブリまたはプラグインパッケージを登録した後、Dataverseのmanagedidentitiesレコードを作成し、pluginassembliesまたはpluginpackagesへ関連付けます。Microsoft Learnでは、Dataverse Web APIにPOSTしてmanaged identityレコードを作成し、そのGUIDをプラグインアセンブリまたはプラグインパッケージへPATCHで紐づける例が示されています。(Microsoft Learn)
Power Automateのカスタムコネクタでは、プレビュー機能としてSecurityタブでOAuth 2.0、Azure Active Directory、Managed identityの選択肢を使う流れが示されています。保存後に表示されるissuerとsubject identifierを、対象のMicrosoft EntraアプリのFederated Credentialsへ追加します。環境へエクスポート・インポートすると新しいManaged Identityが生成され、移行先のEntraアプリにも対応する資格情報を追加する必要がある点に注意が必要です。(Microsoft Learn)
対象リソースに最小権限を付与する
IDを作っただけではアクセスできません。Azure Key Vault、Storage、独自APIなど、接続先リソース側でそのIDに権限を付与します。
| 接続先 | 権限設計の例 | 注意点 |
|---|---|---|
| Azure Key Vault | 必要なシークレットだけを読める権限 | Key Vault全体の管理権限を与えない |
| Azure Storage | 対象コンテナーへのデータ読み書き権限 | ストレージアカウント全体のOwnerは避ける |
| Azure Service Bus | 必要なキューやトピックの送受信権限 | 送信だけでよい処理に受信権限を付けない |
| 独自API | アプリロールやスコープで業務操作を制限 | API側でトークン検証と認可を実装する |
| Microsoft Graph | 必要なアプリケーション権限だけ | 高権限のGraph権限は承認プロセスを分ける |
ここでの原則は「接続できること」ではなく「必要な操作だけできること」です。認証が成功しても、認可が広すぎればセキュリティ上の負債になります。
失敗しやすいポイントと対策
| 失敗しやすいポイント | 症状 | 対策 |
|---|---|---|
| issuer、subject、audienceの不一致 | AADSTS700213: No matching federated identity record foundが出る | エラーに表示される期待値とFederated Credentialの値を照合する |
| 大文字小文字の違い | 設定が正しそうに見えるのに認証できない | audienceなどはケースセンシティブとして扱う |
| 自己署名証明書を本番利用する | セキュリティレビューで差し戻される | 自己署名は開発・検証用に限定し、本番は信頼された発行元を使う |
| Power AutomateでManaged Identity項目が見えない | カスタムコネクタのUXに選択肢がない | プレビュー展開状況、環境、テナント条件を確認する |
commonテナントを使う | カスタムコネクタの接続作成に失敗する | 実際のテナントGUIDを指定する |
| トークンは取れるが403になる | 認証は成功しているがリソース操作に失敗する | Azure RBAC、Key Vault権限、API側のアプリロールを確認する |
| IDを使い回しすぎる | どの処理が何をしたか追跡しにくい | 環境別・用途別にIDを分ける |
| Key Vaultに置いたので安全だと思い込む | Key Vaultへアクセスするための資格情報が残る | 可能な箇所はManaged IdentityでKey Vault自体へのアクセスもシークレットレス化する |
Microsoft LearnのFAQでも、AADSTS700213が出た場合はFICが正しく保存されているか、issuerとsubjectが指定フォーマットに一致しているかを確認するよう案内されています。また、Power Platformへ到達できないエラーではPower PlatformのURLとIPアドレス範囲の許可設定を確認する必要があります。(Microsoft Learn)
管理者が用意すべき標準ルール
Power Platform Managed Identityは、個別案件ごとに手作業で設定すると管理が複雑になります。管理者は最初に標準ルールを決めるべきです。
命名規則
ID名には、環境、用途、接続先を含めます。
| 悪い例 | 良い例 |
|---|---|
managed-id-01 | pp-prod-order-kv-mi |
powerplatform-app | pp-dev-invoice-storage-app |
test-mi | pp-test-customer-api-mi |
命名規則が曖昧だと、半年後に「このIDを消してよいか」が誰にも分からなくなります。
権限申請テンプレート
申請時には、少なくとも次の情報を必須にします。
| 項目 | 記入例 |
|---|---|
| 対象環境 | Production |
| 対象コンポーネント | Dataverse plug-in: OrderValidationPlugin |
| 接続先 | Azure Key Vault: kv-prod-order |
| 必要操作 | Secretの読み取りのみ |
| 所有者 | 業務アプリチーム、セキュリティ承認者 |
| ログ確認方法 | Entra sign-in logs、Azure Activity logs、アプリログ |
| ロールバック方法 | 旧シークレット接続を一時的に戻す、または旧バージョンのプラグインへ戻す |
環境分離
開発、検証、本番で同じIDを使わないことは基本です。特にDataverse環境をまたぐ場合、subject identifierには環境IDが関係するため、ALM時に環境ごとのフェデレーション資格情報を用意する必要があります。
DLPとの併用
Managed Identityは認証情報の安全性を高める仕組みであり、データ損失防止ポリシーの代替ではありません。Power AutomateでManaged Identityを使っても、業務データをどのコネクタへ渡してよいかはDLPで制御する必要があります。
既存フローやプラグインを移行する進め方
既存資産を移行するときは、いきなりシークレットを削除しないでください。次の順序で進めると失敗しにくくなります。
| ステップ | 作業内容 | 完了条件 |
|---|---|---|
| 1 | シークレット利用箇所を棚卸しする | 利用箇所、所有者、期限、接続先が一覧化されている |
| 2 | パイロット対象を選ぶ | 影響範囲が小さく、接続先がEntra認証に対応している |
| 3 | IDを作成する | アプリ登録またはUAMIが環境別に作成されている |
| 4 | フェデレーション資格情報を設定する | issuer、subject、audienceが環境に合わせて設定されている |
| 5 | プラグインまたはコネクタへ関連付ける | テスト環境でトークン取得に成功している |
| 6 | 接続先リソースに権限を付与する | 必要最小限の操作だけが許可されている |
| 7 | ログと監査を確認する | Entra ID、Azure、アプリ側のログで追跡できる |
| 8 | 旧シークレットを段階的に無効化する | 影響がないことを確認してから削除する |
移行時のコツは、古いシークレット方式とManaged Identity方式を短期間だけ並行させることです。ログで新方式の利用を確認し、業務処理が安定してから旧シークレットを無効化します。
セキュリティエンジニアが確認すべき観点
Power Platform Managed Identityを承認する側は、次の観点でレビューすると判断しやすくなります。
| 確認観点 | 見るべき内容 |
|---|---|
| IDの所有者 | 退職者や個人アカウントに依存していないか |
| 権限の範囲 | 接続先リソースに対して最小権限か |
| 環境分離 | 開発IDが本番リソースへアクセスできないか |
| 監査ログ | 誰が設定変更し、どのIDがアクセスしたか追えるか |
| ALM | ソリューション移行時にIDとFICが正しく差し替わるか |
| 例外管理 | APIキーしか使えない外部SaaSをどう扱うか |
| 緊急停止 | 対象IDの権限削除でアクセスを止められるか |
レビューでは「Managed Identityだから安全」と承認するのではなく、「このIDが侵害または誤用された場合の影響範囲はどこまでか」を確認します。
Enterprise Architectが考えるべきアーキテクチャ
大規模環境では、Power Platform Managed Identityを個別機能として扱うより、エンタープライズ統合基盤の一部として設計する方が効果的です。
おすすめの構成は、Power Platform、Dataverse、Azure API Management、Azure Functions、Azure Key Vault、Microsoft Entra IDを役割分担させる形です。
| レイヤー | 役割 |
|---|---|
| Power Automate | 業務プロセス、承認、通知、スケジュール実行 |
| Dataverse | 業務データ、イベント、Custom API、プラグイン実行 |
| Dataverseプラグイン | 機密性の高いサーバー側処理、Managed IdentityによるAzure接続 |
| Azure API Management | 外部APIの集約、認証・認可、レート制御、監査 |
| Azure Functions | 複雑な処理、外部サービス連携、Managed Identityによる下流アクセス |
| Microsoft Entra ID | ワークロードID、フェデレーション資格情報、条件付き統制 |
| Azure Key Vault | どうしても残るシークレットの保護 |
この構成にすると、Power Automateに業務ロジックを置きすぎず、認証・認可・監査を管理しやすい場所へ寄せられます。特にグローバル組織では、各国・各部門が独自にHTTPアクションでAPIキーを扱う状態を避け、標準APIと標準IDで統制することが重要です。
すぐに取るべき次のアクション
最初にやるべきことは、Power Platform環境内のシークレット棚卸しです。特に、期限が近いクライアントシークレット、本番フロー内のHTTPアクション、DataverseプラグインのSecure Configuration、カスタムコネクタの認証設定を優先して確認します。
そのうえで、DataverseプラグインからAzureリソースへ接続している処理を1つ選び、Power Platform Managed Identityのパイロットにします。Power Automateについては、カスタムコネクタのManaged identity authenticationが利用できる環境かを確認しつつ、必要に応じてDataverseプラグインやAPI Managementを中継する設計を検討します。
Power Platform Managed Identityの導入目的は、単なる新機能の利用ではありません。シークレットを配らない、期限切れで止めない、誰が何にアクセスできるかを追える状態にすることです。これを標準パターン化できれば、Power Platform admins、enterprise architects、security engineersの間で起きがちな承認待ちや差し戻しを減らし、安全な自動化をより速く展開できます。
コメント