結論から言うと、2026年4月20日のMicrosoft Security Blogで注目すべき点は、Power Platform Managed Identityの単発ニュースではありません。見るべきなのは、Power Platform上の業務自動化を、パスワード・クライアントシークレット・APIキーに依存しない「シークレットレス運用」へ移す流れが明確になったことです。Microsoftは、Power Platform Managed Identity、Microsoft Entra ID、Workload Identity Federation、Entra Agent IDを組み合わせ、Dataverseプラグイン、Power Automate、AIエージェント、管理自動化までを「管理された非人間ID」で統制する方向を示しています。(Microsoft)
Product owner、IT decision-maker、technical strategistが今やるべきことは、すべてのPower Platform資産を一気に移行することではありません。まずは、重要データに接続するDataverseプラグイン、期限切れシークレットで停止し得る連携、作成者個人の資格情報に依存する自動化を棚卸しし、対応済みの領域からPower Platform Managed Identityへ置き換えることです。
Power Platform Managed Identity / Microsoft Entra IDの最新動向をどう読むべきか
2026年4月20日のMicrosoft Security Blogでは、Microsoft Dynamics 365とPower PlatformのDeputy CISOが、機会便乗型のサイバー攻撃を難しくする設計として「credential elimination」「managed identities」「endpoint reduction」「platform engineering」を取り上げています。特に重要なのは、「ワークロードがシークレットなしで認証できるなら、そうすべき」という考え方です。Microsoftは、マネージドIDやフェデレーションIDによって、保存・ローテーション・漏えい・期限切れの対象になる資格情報を減らす方針を説明しています。(Microsoft)
Power Platform Managed Identityについては、Power Platformのコンポーネントにテナント所有のIDを持たせ、埋め込みパスワードやクライアントシークレットではなく、フェデレーション資格情報でAzureリソースへ認証する仕組みとして紹介されています。さらにMicrosoftは、今後の方向性として、サービスごとに自動作成され、セル単位で分割され、最小権限にスコープされた「platform provisioned identities」へ進むと述べています。これは、各チームが個別にIDやシークレットを作る運用から、プラットフォーム側が安全なIDパターンを標準提供する運用への移行と読めます。(Microsoft)
| 読み取るべき変化 | これまでの典型 | 今後の運用方針 |
|---|---|---|
| 認証 | アプリ登録のシークレット、APIキー、個人接続に頼りがち | 可能な範囲でマネージドID、フェデレーションID、サービスプリンシパルへ寄せる |
| 所有者管理 | 作成者や担当者の退職で接続の責任者が不明になる | ワークロードIDごとに技術所有者と業務責任者を持たせる |
| 権限設計 | 「動くこと」を優先して広い権限を付ける | 環境・用途・接続先ごとに最小権限化する |
| 監査 | 誰の資格情報で実行されたか分かりにくい | プラグイン、サービスプリンシパル、エージェント単位で追跡する |
| ロードマップ | 機能ごとの個別対応 | Power PlatformとMicrosoft Entra IDをまたいだ非人間ID統制へ拡張 |
ここで重要なのは、「Managed Identityを使えば安全」という短絡的な理解ではありません。シークレットをなくしても、権限が広すぎれば侵害時の被害範囲は大きくなります。Power Platform Managed Identityは、認証方式を安全にする機能であり、権限設計・監査・ライフサイクル管理まで含めて初めて効果を発揮します。
Power Platform Managed Identityの現在地
Power Platform Managed Identityは、DataverseプラグインからAzureマネージドID対応リソースへ、資格情報を管理せずに接続するための仕組みです。Microsoft Learnでは、Power Platform Managed IdentityがフェデレーションID資格情報に基づくワークロードIDに依存し、Microsoft Entra IDテナント内のユーザー割り当てマネージドIDまたはアプリケーション登録と連携すると説明されています。公開ドキュメント上のサポート対象は、Dataverseプラグインと依存アセンブリプラグインがGAとして掲載されています。(Microsoft Learn)
Microsoftのリリースプランでは、DataverseプラグインでマネージドIDを使う機能はPublic previewが2024年8月6日、General availabilityが2025年8月31日と示されています。DataverseプラグインからAzure Key Vaultへ接続し、外部Webサービスに使うシークレットを安全に取得する例も挙げられています。(Microsoft Learn)
つまり、現時点の実務上の出発点は「Power Platform全体を一括でManaged Identity化する」ことではありません。まずは、DataverseプラグインからAzure Key Vault、Azure Storage、Azure Functions、SharePointなどへ接続している領域を優先するのが現実的です。
| 導入対象 | 向いているケース | 注意点 |
|---|---|---|
| DataverseプラグインからAzure Key Vaultへ接続 | 外部APIの秘密情報をKey Vaultから取得したい | Key Vault側のRBACを最小権限にする |
| DataverseプラグインからAzureリソースへ接続 | Storage、Functions、Service BusなどでIDベース認証を使いたい | アプリ登録またはUAMIの所有者管理が必要 |
| SharePointドキュメント連携 | Dynamics 365環境でSharePoint Documentsテーブルを使う | SharePoint権限は広くなりやすいため、Sites.Selectedなど細かいスコープを検討する |
| 個人接続で動く自動化 | 作成者退職やパスワード変更で停止するリスクがある | すべてのコネクタがManaged Identity対応とは限らないため、対応状況を確認して段階移行する |
Power Platform Managed Identityの設定は、単に管理画面でスイッチを入れる作業ではありません。公式手順では、アプリ登録またはユーザー割り当てマネージドIDの作成、フェデレーションID資格情報の構成、Dataverseプラグインまたはプラグインパッケージの登録、Dataverse上のマネージドIDレコード作成、Azureリソースへのアクセス許可付与、統合検証という流れになります。(Microsoft Learn)
SharePoint連携については、Dynamics 365環境でSharePoint Documentsテーブルをモデル駆動型アプリのドキュメントグリッド外から使う場合、Azureアプリケーション、DataverseのマネージドID、フェデレーション資格情報を構成する手順が示されています。ドキュメントでは、SharePointドキュメント統合におけるPower Platform Managed IdentityのフェデレーションID資格情報は一般提供で完全サポートと説明されています。(Microsoft Learn)
Microsoft Entra IDのロードマップとつながる3つの軸
Power Platform Managed Identityは、Power Platformだけの個別機能ではなく、Microsoft Entra IDを中心にした非人間ID管理の一部として見るべきです。Microsoft Entraでは、ワークロードIDをアプリケーション、サービスプリンシパル、マネージドIDとして扱い、Azure上のワークロードはマネージドIDで、GitHub ActionsやKubernetes、Azure外のコンピュート環境などはWorkload Identity Federationで、シークレットを管理せずにMicrosoft Entra保護リソースへアクセスする考え方を示しています。(Microsoft Learn)
シークレットレス化: Workload Identity Federation
Workload Identity Federationは、外部IDプロバイダーのトークンをMicrosoft identity platformのアクセストークンと交換する仕組みです。これにより、CI/CD、Kubernetes、外部実行基盤などで、クライアントシークレットや証明書を保存・ローテーションする負担を減らせます。
Power Platform Managed Identityも、この流れの中にあります。技術的には、Power Platform上の特定コンポーネントがEntra ID上のIDとフェデレーション資格情報を使ってAzureリソースにアクセスする設計です。したがって、IT部門はPower Platformだけを例外扱いせず、Azure、GitHub、Kubernetes、Power Platform、Copilot Studioを横断して、同じ非人間ID管理のルールを適用する必要があります。
ワークロードへの条件付きアクセスとリスク管理
Microsoft Entra Conditional Access for workload identitiesは、組織が所有する単一テナントのサービスプリンシパルに対して条件付きアクセスポリシーを適用する機能です。ただし、Microsoft Learnでは、マネージドIDはこのポリシーの対象外であり、アクセスレビューに含める選択肢が示されています。つまり「Entra ID配下だから同じ制御ができる」と考えるのではなく、サービスプリンシパル、マネージドID、アプリ登録、エージェントIDごとに使える統制を分けて設計する必要があります。(Microsoft Learn)
AIエージェントのID化: Microsoft Entra Agent ID
Microsoft Entra Agent IDは、AIエージェントをエンタープライズ内で識別・認証・統制するためのID基盤です。Microsoft Learnでは、Copilot Studioで作成されたエージェントを自動的にエージェントIDへ割り当てられる構成が説明されており、Agent IDはMicrosoft Agent 365の一部として、ID、ライフサイクル、アクセス管理に使われるとされています。(Microsoft Learn)
ここで重要なのは、AIエージェントにも「誰が業務上責任を持つのか」を割り当てる考え方です。Microsoft Entra Agent IDのベストプラクティスでは、エージェントIDやブループリント作成時にスポンサーと所有者を割り当てること、スポンサーはエージェントの目的に責任を持つ人物またはグループであることが示されています。(Microsoft Learn)
ロードマップは「非人間IDの標準化」として読む
今回の更新を単発ニュースとして読むと、「Power Platform Managed Identityが便利になりそう」で終わってしまいます。しかし、中期的な製品方向性として見ると、Microsoftが進めているのは次の3段階です。
| 段階 | 製品・機能の例 | 運用上の意味 |
|---|---|---|
| 資格情報を減らす | Power Platform Managed Identity、Workload Identity Federation | シークレット管理、ローテーション、期限切れ対応を減らす |
| 非人間IDを見える化する | Entra Workload ID、Entra Agent ID | アプリ、サービス、エージェント単位で所有者と権限を管理する |
| プラットフォームで標準化する | Power Platform RBAC、platform provisioned identities | 個別チームの手作業ではなく、共通の安全な経路を用意する |
Power Platform管理に関しても、Power Platform admin centerのRBACはプレビュー機能として、ユーザー、グループ、サービスプリンシパル、マネージドIDをセキュリティプリンシパルとして扱い、テナント、環境グループ、環境といったスコープで権限を割り当てる方向を示しています。ただし、Power Platform admin center UIでのテナント未満スコープの読み取り・読み書き権限は、ドキュメント上「ロードマップ上だが未完了」とされています。(Microsoft Learn)
このため、意思決定では「今すぐ本番全面導入できるか」だけで判断しない方がよいです。GAになっている領域は標準化し、プレビューの領域は非本番で検証し、未対応の領域は例外運用として期限付きで管理する。これが現実的なロードマップです。
どの組織が今すぐ取り組むべきか
Power Platform Managed IdentityとMicrosoft Entra IDの運用見直しは、特に次のような組織で優先度が高くなります。
- DataverseプラグインからAzure Key Vault、Storage、SharePoint、外部APIへ接続している
- アプリ登録のクライアントシークレット期限切れで障害を起こしたことがある
- Power AutomateやPower Appsの個人接続が多く、退職・異動時の影響が読みにくい
- Copilot StudioやAIエージェントの利用が増え、業務責任者やアクセス権限の整理が追いついていない
- グローバルに複数環境を運用しており、環境ごとの例外設定が増えている
- 監査、内部統制、規制対応で非人間IDの棚卸しを求められている
逆に、DataverseプラグインやAzure連携が少なく、部門内の小規模フローが中心の組織では、大規模な移行プロジェクトを急ぐ必要はありません。ただし、新規開発ルールだけは先に変えるべきです。新しいプラグインや管理自動化でクライアントシークレットを安易に作らないようにすれば、将来の移行負債を増やさずに済みます。
Product ownerが決めるべきこと
Product ownerは、設定手順よりも「どの業務自動化を優先してシークレットレス化するか」を決める役割です。判断軸は、止まったときの業務影響と、漏えいしたときの被害範囲です。
| 優先度 | 対象 | 判断基準 |
|---|---|---|
| 高 | 顧客データ、財務データ、個人情報にアクセスするプラグイン | 権限が広く、停止時の業務影響も大きい |
| 高 | Key VaultやSharePointへ接続するDataverse連携 | Managed Identity化の効果が分かりやすい |
| 中 | 部門内のPower Automateフロー | 公式対応状況を確認しながら、個人接続の依存を減らす |
| 中 | Copilot Studioエージェント | スポンサー、用途、接続先データを整理する |
| 低 | 一時的な検証用フロー | 削除期限と所有者を明確にする |
Product ownerが避けたい失敗は、「セキュリティ対策だからIT部門に任せる」と考えることです。Managed Identityに移行しても、その自動化が業務上必要か、どのデータまでアクセスしてよいか、誰が廃止判断をするかは業務側でなければ決められません。
IT decision-makerが整備すべきガードレール
IT decision-makerは、Power Platform Managed Identityを個別案件の便利機能ではなく、組織標準として扱う必要があります。特に重要なのは、例外の扱いです。
新規のDataverseプラグインがAzureリソースへ接続する場合、原則としてPower Platform Managed Identityを使う。どうしてもクライアントシークレットを使う場合は、業務責任者、技術所有者、有効期限、ローテーション方法、保管場所、廃止予定日を記録する。このようなルールを先に作ると、例外が増えても管理できます。
Power PlatformはMicrosoft Entra IDをIDとアクセス管理に使い、Conditional Accessや継続的アクセス評価などのEntra IDのセキュリティ機能を活用できます。ただし、Power Platform側のデータ権限、Dataverseのセキュリティロール、コネクタ接続、Entra ID側のアプリ権限は別レイヤーです。Power PlatformのWell-Architectedガイダンスでも、IDは主要な境界であり、人間だけでなく、ワークロードID、マネージドID、APIキー、サービスプリンシパルなどのシステムIDも含めて考える必要があると説明されています。(Microsoft Learn)
Technical strategistが描くべき参照アーキテクチャ
Technical strategistは、Power Platform、Azure、Microsoft Entra IDを別々に設計するのではなく、非人間IDの参照アーキテクチャを作るべきです。最低限、次の構成を標準にします。
| 項目 | 推奨方針 |
|---|---|
| IDの命名 | 環境、用途、接続先、所有チームが分かる名前にする |
| スコープ | 本番・検証・開発でIDを分ける |
| 権限 | Key Vaultなら必要なSecret取得権限だけにするなど、リソース側RBACを最小化する |
| 所有者 | 技術所有者と業務責任者を分けて記録する |
| 監査 | Entraサインインログ、Dataverse監査、Power Platform管理ログを確認できるようにする |
| 例外 | シークレット利用は期限付きにし、定期レビュー対象にする |
| エージェント | Copilot Studioなどのエージェントはスポンサーと利用目的を必須にする |
この設計で重要なのは、1つのユーザー割り当てマネージドIDを便利だからといって複数システムで使い回さないことです。共通IDは管理が楽に見えますが、侵害時の影響範囲が広くなります。用途ごと、環境ごと、接続先ごとに分けることで、監査や停止判断もしやすくなります。
90日で進める導入計画
Power Platform Managed Identityの導入は、短期間で「完全移行」を目指すより、90日程度で標準化の土台を作る方が成功しやすいです。
| 期間 | 取り組み | 成果物 |
|---|---|---|
| 0〜30日 | Power Platform資産の棚卸し | 個人接続、アプリ登録、シークレット、Dataverseプラグイン、AIエージェントの一覧 |
| 31〜60日 | 高リスク連携のPoC | DataverseプラグインからKey VaultまたはSharePointへManaged Identityで接続する検証 |
| 61〜90日 | 標準化と例外管理 | 命名規則、権限付与ルール、例外申請、レビュー周期、移行ロードマップ |
最初のPoCは、ビジネス影響が大きすぎる本番中核システムではなく、構成が単純で効果が見えやすいDataverseプラグインから始めるのが現実的です。たとえば「プラグインがKey Vaultから外部API用のシークレットを取得している」ようなケースは、Power Platform Managed Identityの価値を説明しやすく、運用設計のひな型にもなります。
失敗しやすいポイントと対策
| 失敗しやすいポイント | なぜ問題か | 対策 |
|---|---|---|
| Managed Identity化だけで満足する | 権限が広いままだと侵害時の被害範囲が大きい | Azure RBAC、Dataverseロール、SharePoint権限を個別に見直す |
| Power Automate全体にすぐ適用できると考える | 機能ごとに対応状況が異なる | 公式ドキュメントのSupported servicesと個別サービスの手順を確認する |
| 1つのIDを複数環境で使い回す | 障害・侵害時の切り分けが難しい | 本番、検証、開発でIDを分離する |
| 個人接続を「一時的に」残し続ける | 退職、MFA変更、パスワード変更で停止する | 例外期限を設定し、月次でレビューする |
| エージェントの業務責任者を決めない | AIエージェントが孤児化しやすい | スポンサー、所有者、用途、接続先データを登録する |
| プレビュー機能を本番前提で計画する | 仕様変更や制限の影響を受ける | 非本番検証に限定し、GA領域とは別管理にする |
Microsoftのリリースプランやプレビュー機能は、提供時期や仕様が変わる可能性があります。グローバル環境で展開する場合は、機能の一般提供日だけでなく、地理的な提供状況、言語、テナント設定、ライセンス条件も確認してから本番計画に入るべきです。リリースプラン自体も、地理的提供状況や言語提供状況の確認を案内しています。(Microsoft Learn)
社内ポリシーに落とし込む例
Power Platform Managed IdentityとMicrosoft Entra IDの方向性を、実際の運用ルールに落とすなら、次のような方針文から始めると実装しやすくなります。
新規に作成するDataverseプラグインがAzureリソースまたはMicrosoft 365リソースへ接続する場合、原則としてPower Platform Managed IdentityまたはMicrosoft Entra IDのシークレットレス認証を使用する。クライアントシークレット、APIキー、個人資格情報を使用する場合は、業務責任者、技術所有者、有効期限、ローテーション方法、廃止予定日を記録し、定期レビューの対象とする。
この方針のポイントは、「禁止」だけで終わらせないことです。例外を認める場合でも、期限と所有者を必ず持たせれば、シークレットが放置されるリスクを下げられます。
次に取るべき行動
Power Platform Managed Identity / Microsoft Entra IDの最新動向は、「Power Platformが便利になる」という話ではなく、「業務自動化のID管理を人間中心からワークロード中心へ移す」という話です。今後は、アプリ、プラグイン、フロー、AIエージェントがそれぞれ明確なIDを持ち、最小権限で実行され、監査できることが前提になっていきます。
まず着手すべきことは3つです。
- Dataverseプラグイン、Power Automate、アプリ登録、AIエージェント、個人接続を棚卸しする
- Azure Key VaultやSharePointに接続する高リスクなDataverse連携を1つ選び、Power Platform Managed IdentityでPoCする
- 新規開発では、クライアントシークレットや個人資格情報を原則使わないルールを先に決める
中期的には、Power Platform Managed Identity、Power Platform RBAC、Microsoft Entra Workload ID、Microsoft Entra Agent IDを別々の機能として扱うのではなく、非人間IDの共通運用基盤として設計することが重要です。シークレットをなくすことはゴールではありません。誰が、どのワークロードに、どの権限を、どの期間だけ与えるのかを説明できる状態にすることが、これからのPower Platform運用方針の中心になります。
コメント