Power Platform Managed Identity / Microsoft Entra ID の rollout で現場がまず変わるのは、「フローやプラグインの中にシークレットを持たせる」運用から、「ワークロードそのものに ID を与え、必要な Azure リソースだけに権限を付ける」運用へ移る点です。つまり、Power Automate、Dataverse プラグイン、Copilot Studio エージェントを使う現場では、認証情報の受け渡し・更新・期限切れ対応が減り、管理者は Microsoft Entra ID を中心にアクセス制御と監査を設計する流れになります。
2026年4月20日の Microsoft Security Blog では、攻撃者が「侵入する」のではなく「盗まれた資格情報でログインする」リスクに触れ、資格情報をなくす設計、マネージド ID、Federated Identity Credentials、Power Platform Managed Identity を取り上げています。特に PPMI は、Dataverse プラグインや Power Automate などの Power Platform コンポーネントにテナント所有の ID を与え、埋め込みパスワードやクライアントシークレットではなくフェデレーション資格情報で Azure リソースへ認証する方向性として説明されています。(Microsoft)
Power Platform Managed Identity / Microsoft Entra ID の最新動向
今回のポイントは、単なる新機能の追加ではありません。Power Platform の自動化を、個人アカウント・共有アカウント・期限付きシークレットに依存した仕組みから、Microsoft Entra ID 上で管理できる「ワークロード ID」中心の仕組みに寄せる動きです。
Microsoft Learn の Power Platform Managed Identity 概要では、Dataverse プラグインから Azure マネージド ID をサポートする Azure リソースへ、資格情報を管理せずに接続できると説明されています。公式ドキュメント上のサポート対象は、Dataverse プラグインおよび依存アセンブリ プラグインが GA とされています。(Microsoft Learn)
一方で、Power Automate まわりはすべての標準コネクタが即座にマネージド ID 化される、という意味ではありません。たとえば Microsoft Entra ID で保護された API を呼び出すカスタム コネクタでは、クライアントシークレットの代わりにマネージド ID を使う認証がプレビューとして説明されており、まだロールアウト中で UI に表示されない場合があるとされています。(Microsoft Learn)
現場で変わるのは「認証情報の管理」ではなく「IDの設計」
従来の Power Platform 自動化では、次のような運用が起こりがちでした。
| 従来の運用 | 起こりやすい問題 | Managed Identity 後の考え方 |
|---|---|---|
| クライアントシークレットを環境変数や設定値に保存する | 期限切れ、漏えい、更新漏れが起こる | シークレットではなく、ワークロード ID に権限を付与する |
| サービスアカウントでフローを実行する | 所有者変更、退職、MFA、監査が複雑になる | 実行主体を ID として分離し、Entra ID で監査する |
| 開発・検証・本番で同じシークレットを使い回す | 本番影響範囲が広がる | 環境ごとに ID と RBAC を分ける |
| 管理者が個別にアプリ登録や秘密値を払い出す | 依頼、保管、更新の属人化が進む | 事前に標準パターンを作り、必要最小権限で割り当てる |
Azure のマネージド ID は、アプリケーションが Microsoft Entra トークンを取得するために、開発者が資格情報を管理しなくてよい仕組みです。Microsoft Learn でも、マネージド ID はアクセスキーやパスワードなどのシークレットを置き換えられると説明されています。(Microsoft Learn)
Power Platform Managed Identity の rollout によって、現場の会話は「このシークレットをどこに保存するか」から、「この自動化にはどの ID が必要で、どのリソースに、どの範囲で、いつまでアクセスできるべきか」に変わります。これは Power users にとっては作業の簡略化、admins にとっては統制強化、solution owners にとっては運用品質の向上につながります。
利用シナリオ: Dataverse プラグインから Azure Key Vault にアクセスする
最も分かりやすい活用例は、Dataverse プラグインが Azure Key Vault、Azure Storage、Azure SQL などの Azure リソースへアクセスするケースです。
たとえば、見積承認アプリで Dataverse のレコード作成時にプラグインを実行し、外部 API の接続情報を Azure Key Vault から取得する構成を考えます。従来は、プラグインの安全な構成、環境変数、独自テーブルなどにクライアント ID やシークレットを持たせる設計になりがちでした。これでは、シークレット期限切れのたびに本番処理が止まるリスクがあります。
Power Platform Managed Identity を使う場合は、概念的には次の流れになります。
| 手順 | 担当 | やること |
|---|---|---|
| ID を用意する | Azure / Entra 管理者 | アプリ登録またはユーザー割り当てマネージド ID を作成する |
| フェデレーション資格情報を設定する | Azure / Entra 管理者 | Power Platform 側の主体を信頼する設定を Entra ID に追加する |
| プラグインを作成・署名する | 開発者 | Dataverse プラグインをビルドし、証明書で署名する |
| Dataverse に Managed Identity レコードを作る | Power Platform 管理者 / 開発者 | プラグイン アセンブリまたはパッケージに ID を関連付ける |
| Azure リソースに権限を付ける | Azure 管理者 | Key Vault などに最小権限の RBAC を割り当てる |
| 本番検証する | solution owner | プラグインがトークンを取得し、対象リソースへアクセスできるか確認する |
Microsoft Learn の設定手順でも、アプリ登録またはユーザー割り当てマネージド ID の作成、フェデレーション資格情報の構成、Dataverse プラグインの登録、Dataverse の managed identity レコード作成、Azure リソースへのアクセス許可付与、統合の検証という流れが示されています。(Microsoft Learn)
このシナリオでの実務上の効果は大きく、solution owner は「秘密値を更新したか」ではなく「このプラグイン ID に Key Vault のどの権限が必要か」を確認すればよくなります。障害調査でも、期限切れシークレットを探すより、Entra ID のサインインログや Azure 側の RBAC、Key Vault のアクセスログを確認する流れに寄せられます。
利用シナリオ: Power Automate から Entra ID で保護された API を呼び出す
Power Automate では、業務アプリの承認、Teams 通知、SharePoint 更新、Dataverse 登録などを組み合わせたフローがよく使われます。問題は、社内 API や Azure API を呼び出すときに、HTTP アクションやカスタム コネクタへクライアントシークレットを持たせる設計になりやすい点です。
Microsoft Learn のカスタム コネクタの説明では、Microsoft Entra ID で認証された任意の RESTful API へアクセスする手順が紹介されており、マネージド ID 認証ではクライアントシークレットの更新に悩まされにくくなると説明されています。ただし、この機能はプレビューであり、単一テナント アプリケーションが必要で、UI への表示もロールアウト状況に左右される点に注意が必要です。(Microsoft Learn)
現場での使いどころは、次のようなフローです。
| 業務フロー | 従来の課題 | Managed Identity 利用時の狙い |
|---|---|---|
| Power Automate から社内申請 API を呼ぶ | カスタム コネクタにシークレットを保存する | コネクタの ID を Entra ID 側で信頼し、秘密値を持たせない |
| 契約更新フローから Azure API を呼ぶ | シークレット期限切れで処理が止まる | フェデレーション資格情報でトークンを取得する |
| 複数環境に同じコネクタを展開する | dev/test/prod の秘密値管理が煩雑 | 環境ごとに ID とフェデレーション設定を分ける |
| グローバル拠点で共通フローを使う | どの国・環境で誰の資格情報を使っているか不明確 | Entra ID を軸に監査・棚卸ししやすくする |
重要なのは、「Power Automate のすべての接続がマネージド ID で動く」と誤解しないことです。標準コネクタ、ユーザー委任の接続、外部 SaaS の API キー認証などは、それぞれ認証方式が異なります。まずは、Microsoft Entra ID で保護された API、カスタム コネクタ、Azure リソース連携のように、ID ベース認証へ移しやすい箇所から棚卸しするのが現実的です。
利用シナリオ: Copilot Studio エージェントの「所有者不明」を防ぐ
Power Platform の今後を考えるうえで、Microsoft Entra Agent ID も無視できません。Copilot Studio で作成される AI エージェントは、業務データにアクセスし、ユーザーの代わりに処理を実行し、場合によっては外部システムを呼び出します。ここで必要になるのは、「誰が作ったか」だけではなく、「どのエージェントが、どの権限で、何をしたか」を確認できる ID 管理です。
Microsoft Entra Agent ID は、AI エージェントに固有の識別と認証を与える Microsoft Entra ID 内の ID アカウントとして説明されています。Copilot Studio で作成されたエージェントには agent identity が付与され、作成者が sponsor として記録され、認証活動は Microsoft Entra ID 上で AI エージェントとしてログに残るとされています。なお、Microsoft Entra Agent ID はプレビュー段階の情報として扱う必要があります。(Microsoft Learn)
実務では、次のような変化が起こります。
| これまでの課題 | Entra Agent ID で期待される変化 |
|---|---|
| エージェントが誰の責任で運用されているか分かりにくい | sponsor や owner を割り当て、責任者を明確にする |
| 退職者が作ったエージェントが残り続ける | ライフサイクル管理やスポンサー移管を検討しやすくなる |
| エージェントの権限が過剰か判断しにくい | agent identity 単位でアクセス権を確認する |
| 監査時に人間・アプリ・AI の操作が混ざる | AI エージェントとしての操作記録を分けて見やすくなる |
Microsoft Entra ID Governance の Agent Identities 概要では、agent identity のスポンサーはライフサイクルとアクセスに責任を持つ人間ユーザーであり、スポンサーが組織を離れる場合はマネージャーへ移管される仕組みに触れています。(Microsoft Learn)
power users、admins、solution owners の仕事はどう変わるか
Power Platform Managed Identity / Microsoft Entra ID の rollout は、役割ごとの作業を次のように変えます。
| 役割 | これまで多かった作業 | これから重視すべき作業 |
|---|---|---|
| Power users | 管理者にアプリ登録や秘密値を依頼する。期限切れ時にフローを直す | 承認済みのコネクタや環境で、ID ベースの標準パターンを使う |
| Admins | シークレットを発行、保管、更新、削除する | Entra ID、RBAC、条件付きアクセス、監査ログで統制する |
| Solution owners | フロー所有者や接続所有者の変更に追われる | 業務プロセス単位で ID、権限、責任者、環境分離を設計する |
| Developers | プラグインに秘密値を渡す実装を作る | トークン取得、署名、フェデレーション設定、最小権限を前提に実装する |
| Security teams | どこに秘密値があるかを探す | ワークロード ID と権限の棚卸し、過剰権限の検出に集中する |
Microsoft の Power Platform 向け ID とアクセス管理ガイダンスでは、Power Platform は Microsoft Entra ID と統合され、条件付きアクセスや多要素認証などを使ってユーザーとリソースへのアクセスを管理できると説明されています。また、権限は ID の責任に応じて割り当て、必要以上の操作ができないようにすることが推奨されています。(Microsoft Learn)
導入判断: 今すぐ進めるべきケースと様子を見るケース
Power Platform Managed Identity は有用ですが、どの現場でも一斉導入すべきとは限りません。まずは、シークレット管理の痛みが大きい領域から始めるのが効果的です。
| 判断軸 | 今すぐ検討したいケース | まだ調査・PoC から始めたいケース |
|---|---|---|
| 対象コンポーネント | Dataverse プラグインから Azure リソースへアクセスしている | 標準コネクタ中心で、独自 API 呼び出しが少ない |
| 認証方式 | クライアントシークレット、証明書、API キーの期限管理が負担 | 外部 SaaS が API キー認証しか提供していない |
| 障害リスク | 秘密値の期限切れで本番フローが止まったことがある | 期限管理の運用がすでに安定している |
| ガバナンス | 誰の資格情報で動いているか分からない自動化が多い | 環境・接続・所有者が整理されている |
| 組織体制 | Entra ID 管理者、Azure 管理者、Power Platform 管理者が連携できる | 管理境界が分断され、RBAC 設計の合意がまだない |
特に、Dataverse プラグインで Azure Key Vault、Storage、Service Bus、Azure Functions などを呼び出している場合は、移行候補として優先度が高いです。逆に、Power Automate の単純な通知フローや、ユーザーの Outlook・Teams 接続だけで完結するフローは、Managed Identity よりも DLP、接続参照、所有者管理、環境分離を先に整えるほうが効果的な場合があります。
導入前に決めるべき設計ポイント
ID は「共有」ではなく「業務単位」で切る
Managed Identity は、共有アカウントの安全版ではありません。1つの ID に多くのフローやプラグインをぶら下げすぎると、結局「この ID が何のために使われているのか」が分からなくなります。
おすすめは、次の単位で ID を分けることです。
| 分け方 | 向いているケース | 注意点 |
|---|---|---|
| 業務プロセス単位 | 契約管理、請求処理、顧客登録など | プロセス変更時に権限見直しが必要 |
| 環境単位 | dev/test/prod を厳密に分けたい | 本番 ID を検証環境へ流用しない |
| Azure リソース単位 | Key Vault、Storage、API ごとに権限を絞りたい | ID が増えるため命名規則が必要 |
| ソリューション単位 | ISV パッケージや共通部品を管理したい | 依存関係が複雑な場合は棚卸しが必要 |
Microsoft のガイダンスでも、最小特権の考え方に基づき、ID が必要な作業だけを実行できるようにロールを割り当てることが推奨されています。(Microsoft Learn)
アプリ登録と UAMI の使い分けを決める
Power Platform Managed Identity の設定では、Microsoft Entra ID のアプリ登録またはユーザー割り当てマネージド ID を選べます。Microsoft Learn では、Azure Key Vault などへ接続するプラグインに関連付けられたアプリ ID が必要で、Azure ポリシーを適用したい場合はアプリ登録を使い、サービス プリンシパルとして Azure リソースへアクセスしたい場合はユーザー割り当てマネージド ID をプロビジョニングできると説明されています。(Microsoft Learn)
実務では、どちらを選ぶかを開発者だけで決めないことが重要です。Entra ID 管理者、Azure 管理者、Power Platform 管理者で、命名規則、所有者、RBAC、ログ確認方法、削除時の手順まで合意しておく必要があります。
本番では証明書とフェデレーション設定を軽視しない
Dataverse プラグインの設定では、プラグイン アセンブリの署名やフェデレーション資格情報の subject が重要になります。Microsoft Learn では、自己署名証明書は開発またはテスト用途に限り、本番環境では使用しないよう注意されています。また、フェデレーション資格情報が一致しない場合、AADSTS700213: No matching federated identity record found のようなエラーが発生し、issuer や subject の一致確認が必要とされています。(Microsoft Learn)
この種のエラーは、設定値を見れば分かるようでいて、実際には環境 ID、テナント ID、証明書、subject の生成ルールが絡むため、切り分けに時間がかかります。本番導入前に、検証環境で「意図的に失敗させるテスト」を行い、どのログに何が出るかを確認しておくと運用が安定します。
グローバル環境や政府クラウドでは issuer と audience を確認する
グローバル組織では、商用クラウドだけでなく GCC High、DoD、中国クラウドなどを使うケースがあります。Microsoft Learn の設定手順では、特定のクラウド環境では audience、issuer URL、subject prefix を明示的に設定する必要があり、public cloud や GCC では既定値が異なることが説明されています。(Microsoft Learn)
海外拠点を含む rollout では、「日本の検証環境で動いた設定をそのまま全リージョンに展開する」のは危険です。国・リージョン・クラウド種別ごとに、Entra ID、Power Platform 環境、Azure リソースの対応関係を確認してから展開します。
移行を進める実務ステップ
最初から全フローを移行しようとすると失敗します。Power Platform Managed Identity は、次の順番で進めると現場に定着しやすくなります。
| ステップ | 作業内容 | 成果物 |
|---|---|---|
| 棚卸し | 環境変数、カスタム コネクタ、プラグイン構成、サービスアカウント、期限付きシークレットを洗い出す | シークレット利用一覧 |
| 優先順位付け | 本番影響、期限切れ頻度、権限の強さ、所有者不明の有無で分類する | 移行候補リスト |
| 標準パターン作成 | Dataverse プラグイン、カスタム コネクタ、Azure リソース別に設計テンプレートを作る | ID 設計テンプレート |
| PoC | 1つの業務フローで ID 作成、FIC、RBAC、ログ確認まで実施する | 検証結果と手順書 |
| 本番展開 | dev/test/prod の ID を分けて段階的に展開する | 本番移行計画 |
| 廃止 | 旧シークレット、旧サービスアカウント、不要なアプリ登録を削除する | 廃止証跡 |
| 監査 | Entra ID、Azure、Power Platform のログを定期確認する | 権限レビュー記録 |
Microsoft の Power Platform Well-Architected ガイダンスでは、クラウド フローやキャンバス アプリ、構成ファイル、デプロイ パイプラインなどにシークレットをハードコードしないこと、またシークレットが見つかった場合は漏えいしたものとして扱い取り消すことが推奨されています。(Microsoft Learn)
よくある失敗と回避策
| 失敗しやすいポイント | 何が起きるか | 回避策 |
|---|---|---|
| 「Managed Identity なら安全」と考えて広い権限を付ける | 侵害時の影響範囲が広がる | Key Vault、Storage、API ごとに最小権限を付ける |
| dev/test/prod で同じ ID を使う | 検証作業が本番リソースへ影響する | 環境ごとに ID、RBAC、フェデレーション設定を分ける |
| Power Automate の全接続で使えると誤解する | 移行計画が途中で止まる | Dataverse プラグイン、カスタム コネクタ、Entra ID 保護 API から始める |
| 旧シークレットを残したままにする | 使われていない秘密値が攻撃面になる | 移行後に旧資格情報を削除し、アクセスログで未使用を確認する |
| カスタム コネクタを別環境へインポートした後に再設定しない | 接続作成や API 呼び出しが失敗する | 環境ごとの issuer / subject を確認し、Entra ID 側に設定する |
| 条件付きアクセスの対象を誤る | Power Automate の埋め込みフローで認証エラーが出る | Microsoft Flow Service を含めるか、対象クラウドアプリを見直す |
Power Platform の条件付きアクセスに関する公式ガイダンスでは、Office 365 アプリスイートのみを対象に MFA を要求すると、SharePoint、Teams、Excel から Power Automate フローへアクセスする際に認証エラーが発生する可能性があり、Microsoft Flow Service を明示的に追加するか、All cloud apps を対象にすることが示されています。(Microsoft Learn)
導入後に見るべき運用指標
Power Platform Managed Identity / Microsoft Entra ID の導入効果は、「設定できたか」ではなく「運用リスクが減ったか」で測ります。
| 指標 | 見る理由 |
|---|---|
| 期限付きクライアントシークレットの数 | 更新漏れリスクが減っているか確認する |
| 本番フロー・プラグインの所有者不明件数 | 退職者や異動者に依存していないか確認する |
| 共有サービスアカウントの利用数 | 人間の資格情報に依存した自動化を減らす |
| 過剰 RBAC の件数 | Managed Identity に不要な権限が付いていないか確認する |
| 旧シークレットの最終利用日時 | 移行後に安全に削除できるか判断する |
| フェデレーション資格情報の設定ミス件数 | 展開手順の品質を測る |
| AI エージェントの sponsor 未設定件数 | Copilot Studio エージェントの責任者不明を防ぐ |
この指標を月次レビューに入れると、Managed Identity は単なる技術機能ではなく、Power Platform ガバナンスの一部として定着します。
まず着手すべき次のアクション
Power Platform Managed Identity の rollout を受けて、最初にやるべきことは新機能の有効化ではなく、既存の自動化資産の棚卸しです。
特に次の3つを優先してください。
- Dataverse プラグインが Azure リソースへ接続している箇所を洗い出す
- Power Automate のカスタム コネクタや HTTP アクションで、クライアントシークレットを使っている箇所を洗い出す
- Copilot Studio エージェントや重要フローについて、所有者、スポンサー、実行主体、権限範囲を確認する
そのうえで、1つの本番影響が小さい業務フローを選び、Managed Identity、Federated Identity Credentials、Azure RBAC、Entra ID ログ確認までを一通り検証します。成功したら、その手順をテンプレート化し、dev/test/prod に展開できる形へ整えます。
Power Platform Managed Identity / Microsoft Entra ID の本質は、シークレットを別の場所へ移すことではありません。シークレットに依存した自動化を、ID、最小権限、監査、ライフサイクル管理に基づく自動化へ作り替えることです。Power users は安全な標準パターンを使い、admins は Entra ID を軸に統制し、solution owners は業務プロセス単位で責任と権限を設計する。この役割分担ができるほど、Power Platform の自動化は止まりにくく、監査しやすく、グローバルにも展開しやすいワークフローになります。
コメント