Microsoft Entra ID Governance licensing fundamentalsの要点は、機能を有効化する前に「前提ライセンス」「対象ユーザー数」「ゲスト課金」「PIMの期限切れ時の挙動」を確認することです。特に2026年5月時点の公式情報では、Microsoft Agent 365やエージェントIDのガバナンスに関する記載が増えており、従来の従業員向けIDガバナンスだけを前提に見積もると、必要なライセンスや展開範囲を誤る可能性があります。Microsoft Learnの日本語ページは2026年5月1日更新表記ですが、公開リポジトリでは5月11〜13日にAgent 365関連の差分が確認できるため、本記事では2026年5月14日時点で確認すべき変更点として整理します。(Microsoft Learn)
Microsoft Entra ID Governance licensing fundamentalsとは
Microsoft Entra ID Governance licensing fundamentalsは、Microsoft Entra ID Governanceを利用する際のライセンス要件を整理した公式ドキュメントです。対象読者は、IT意思決定者、IT管理者、ID管理・セキュリティ担当者です。主に従業員、つまりメンバーユーザー向けのライセンス要件を扱い、ゲストユーザーやエージェントIDについては別のライセンス考慮が必要であることも示しています。(Microsoft Learn)
ここで重要なのは、Microsoft Entra ID Governanceが単体で完結するライセンスではなく、Microsoft Entra ID P1またはP2などの前提サービスプランの上に成り立つ高度なIDガバナンス機能として位置付けられている点です。
つまり、管理者が最初に確認すべきことは「Microsoft Entra ID Governanceを購入しているか」だけではありません。次の3点を合わせて確認する必要があります。
- テナントに前提となるMicrosoft Entra ID P1またはP2相当のサービスプランがあるか
- 利用する機能がP2で足りるのか、ID GovernanceまたはMicrosoft Entra Suiteが必要なのか
- 対象ユーザー、レビュー担当者、承認者、管理者、ゲスト、エージェントIDまで含めたライセンス範囲を把握できているか
2026年5月時点の主な変更点
今回のMicrosoft Entra ID Governance licensing fundamentalsで注目すべき変更は、単なる料金表の更新ではありません。運用設計に影響しやすいのは、Microsoft Agent 365とエージェントIDのガバナンスが、ライセンス説明の中で明確に扱われるようになったことです。
| 確認項目 | 変更・整理された内容 | 管理者への影響 |
|---|---|---|
| Microsoft Agent 365の記載 | ライセンス種別としてMicrosoft Agent 365が説明され、エージェントIDやサービスプリンシパルのアクセスガバナンスに触れられている | 人間の従業員だけでなく、AIエージェントやサービスプリンシパルの権限管理も設計対象になる |
| 前提ライセンス | Microsoft Agent 365には、AAD_PREMIUMサービスプランを含むアクティブなサブスクリプションが必要とされている | Entra ID P1やMicrosoft 365 E3相当の前提があるか確認が必要 |
| Agent Sponsorship tasks | Lifecycle WorkflowsのAgent Sponsorship tasksは、Microsoft Agent 365側の機能として整理されている | P1/P2だけで利用できると誤解しないよう注意が必要 |
| Account Discoveryの記載 | 対象アプリ内の既存アカウントを検出し、Entraアカウントとの一致や孤立アカウントを識別する機能として説明されている | 退職者・未管理アカウント・孤立アカウントの棚卸しに使えるが、GovernanceアドオンまたはEntra Suiteが必要 |
Microsoftの公開リポジトリ履歴では、2026年5月11日にAgent 365のライセンス種別追加、前提条件追加、Lifecycle WorkflowsのAgent Sponsorship tasksの表記修正が行われ、5月13日にはAccount Discovery説明文の修正が入っています。運用上の大きな影響は、誤字修正ではなく、Agent 365関連の前提条件と機能範囲を誤認しないことです。(GitHub)
まず押さえるべきライセンスの全体像
Microsoft Entra ID Governanceのライセンスを理解するには、Free、P1、P2、ID Governance、Microsoft Entra Suite、Microsoft Agent 365を分けて考える必要があります。
| ライセンス・製品 | 主な位置付け | 実務での判断ポイント |
|---|---|---|
| Microsoft Entra ID Free | Microsoft AzureやMicrosoft 365などに含まれる基本的なID機能 | IDガバナンスの高度な運用には不足することが多い |
| Microsoft Entra ID P1 | 条件付きアクセスや基本的なID管理の土台 | Governance製品の前提ライセンスになり得る |
| Microsoft Entra ID P2 | PIMや一部のアクセスレビューなどを含む上位ライセンス | 既存のGA機能は残るが、新しいIGA機能はP2 SKUに追加されないと説明されている |
| Microsoft Entra ID Governance | エンタイトルメント管理、アクセスレビュー、ライフサイクルワークフローなどの高度なIDガバナンス | 対象ユーザー数と機能範囲に応じた見積もりが必要 |
| Microsoft Entra Suite | ID Governanceを含むEntra製品群のスイート | 複数のEntra製品をまとめて導入する場合に検討しやすい |
| Microsoft Agent 365 | エージェントIDやサービスプリンシパルのガバナンスに関係する製品 | AIエージェントや自動化主体のアクセス管理を行う場合に確認が必要 |
Microsoft Entra SuiteにはMicrosoft Entra ID Governanceのすべての機能が含まれる一方、Microsoft Entra ID Governanceの単体製品とは前提条件が異なります。すでにMicrosoft 365 E5やEntra ID P2を持っている組織でも、「P2があるからGovernanceの新機能も使える」とは考えない方が安全です。(Microsoft Learn)
管理者が最初に確認すべき前提ライセンス
Microsoft Entra ID Governanceを展開する前に、テナント内のライセンス状態を確認します。公式ドキュメントでは、Microsoft Entra管理センターまたはMicrosoft 365管理センターで、現在の製品とライセンス機能を確認できると説明されています。(Microsoft Learn)
確認手順
| 手順 | 操作 | 確認するポイント |
|---|---|---|
| 1 | Microsoft Entra管理センターにLicense Administratorとしてサインイン | ライセンス確認に必要な権限があるか |
| 2 | 請求 → ライセンス を開く | テナント内のライセンス管理画面へ進む |
| 3 | ライセンスされた機能 を確認 | 現在のMicrosoft Entra IDライセンスプランを把握する |
| 4 | すべての製品 を確認 | P1、P2、E3、E5、Governance、Suiteなどの有無を確認する |
| 5 | 対象機能とユーザー範囲を照合 | 機能のスコープに含まれる人数分のライセンスを見積もる |
特に注意したいのは、前提サブスクリプションがテナントでアクティブである必要がある点です。前提条件がない、またはサブスクリプションが期限切れになると、Microsoft Entra ID Governanceのシナリオが想定どおりに機能しない可能性があります。(Microsoft Learn)
機能別に見る影響範囲
Microsoft Entra ID Governanceでは、機能ごとに必要なライセンスや対象ユーザーの考え方が異なります。導入前に、どの機能を使うのかを棚卸ししてください。
エンタイトルメント管理
エンタイトルメント管理は、アクセスパッケージを使って、グループ、Teams、アプリケーション、SharePointサイトなどへのアクセスを申請・承認・期限付きで管理する機能です。
実務では、次のような場面で使われます。
- 新入社員が部門別の標準アクセスを申請する
- 外部委託先に期間限定でSharePointサイトを公開する
- 特定プロジェクトのTeams、アプリ、グループをまとめてアクセスパッケージ化する
- 承認者を上長、スポンサー、特定担当者に分ける
注意点は、実際に申請した人数だけでなく、アクセスパッケージを要求できる対象ユーザー数がライセンス見積もりに影響する場合があることです。たとえば「全従業員2,000人がアクセスパッケージを要求できる」ポリシーを作ると、実際の申請者が150人でも、要求可能な2,000人を前提に考える必要があります。(Microsoft Learn)
アクセスレビュー
アクセスレビューは、グループ、アプリ、特権ロールなどへのアクセスが現在も妥当かを定期的に確認する機能です。
ライセンス見積もりで見落としやすいのは、レビュー対象者だけでなく、レビューを実施する担当者も含めて考える必要がある点です。公式例では、75人のメンバーを持つグループを1人のグループ所有者がレビューする場合、75人分に加えてレビュー担当者1人分、合計76ライセンスが必要とされています。(Microsoft Learn)
アクセスレビューを設計するときは、次のように分けて考えると失敗しにくくなります。
| レビュー対象 | おすすめの設計 | 注意点 |
|---|---|---|
| 管理者ロール | 月次または四半期ごとにレビュー | PIMとの組み合わせを前提にする |
| 部門グループ | 所有者または上長レビュー | グループ所有者が実在し、責任を持てるか確認する |
| 外部ユーザー | スポンサーまたは業務担当者レビュー | ゲスト課金とuserTypeの確認が必要 |
| 自己レビュー | 小規模・明確な権限に限定 | 自己承認に近い運用になるため、監査要件に合うか確認する |
ライフサイクルワークフロー
ライフサイクルワークフローは、入社、異動、退職などのタイミングで、ユーザーのアクセスを自動的に付与・変更・削除するための機能です。Microsoft Entra ID Governanceライセンスでは、合計50個までのワークフロー作成・管理・削除、オンデマンド実行やスケジュール実行、最大100個のカスタムタスク拡張機能作成が説明されています。(Microsoft Learn)
実務で効果が出やすいのは、次のような処理です。
- 入社日に部門グループへ自動追加する
- 異動時に旧部門のアクセスを削除し、新部門のアクセスを付与する
- 退職予定者を事前オフボードし、最終日前に権限を段階的に削除する
- Logic Appsなどのカスタム拡張と連携し、チケット作成や通知を自動化する
ただし、ワークフローを実行する管理者だけをライセンス対象と考えるのは危険です。ワークフローの対象になるユーザー数も見積もる必要があります。たとえば新入社員400人にワークフローでグループ付与する場合、管理者1人と対象ユーザー400人で、合計401ライセンスという考え方が示されています。(Microsoft Learn)
Privileged Identity Management
Privileged Identity Management、つまりPIMは、管理者ロールやAzureロールを常時付与せず、必要なときだけ有効化するための重要な機能です。PIMとその設定を使うには、Microsoft Entra ID GovernanceまたはMicrosoft Entra ID P2のライセンスが必要です。(Microsoft Learn)
PIMでライセンス対象として考えるべきユーザーは、主に次のカテゴリです。
- PIMで管理されるMicrosoft Entra IDロールまたはAzureロールに有資格割り当てがあるユーザー
- PIM for Groupsのメンバーまたは所有者として割り当てられるユーザー
- PIMのアクティブ化要求を承認または却下できるユーザー
- アクセスレビューに割り当てられるユーザー
- アクセスレビューを実行するユーザー
PIMはセキュリティ上の重要度が高いため、試用版や期限付きライセンスで検証する場合も、期限切れ時の挙動を必ず確認してください。
PIMのライセンス期限切れは特に注意
Microsoft Entra ID P2、Microsoft Entra ID Governance、または試用版ライセンスが期限切れになると、PIM機能はディレクトリで利用できなくなります。永続的なロール割り当ては影響を受けない一方で、有資格ロールの割り当ては削除され、ユーザーは特権ロールをアクティブ化できなくなります。さらに、PIMの管理画面、API、PowerShellインターフェイスも利用できなくなり、進行中のアクセスレビューは終了します。(Microsoft Learn)
これは検証環境だけの問題ではありません。本番環境でライセンス更新や契約変更のタイミングを誤ると、次のような運用障害につながります。
| 起こり得る問題 | 影響 | 事前対策 |
|---|---|---|
| 有資格ロールが削除される | 管理者が必要なロールを有効化できない | 更新前にPIM対象ロール一覧をエクスポートする |
| 進行中のアクセスレビューが終了する | 監査証跡やレビュー計画に穴が空く | 期限前にレビューを完了する |
| APIやPowerShellでPIM操作できない | 自動化スクリプトが失敗する | ライセンス期限を監視し、運用カレンダーに入れる |
| PIM通知が送信されない | 管理者や承認者が変更に気付かない | 代替通知や監査ログ確認を用意する |
ライセンス変更を伴う移行では、「PIM設定は後で見ればよい」と考えず、移行前の棚卸し項目に含めてください。
ゲストユーザーは従業員ライセンスとは別に考える
Microsoft Entra ID Governanceのライセンス設計では、従業員とゲストユーザーを同じ考え方で扱わないことが重要です。ゲストユーザーのガバナンスでは、Azureサブスクリプションを選択したゲスト課金が必要です。ゲスト課金モデルでは、ユーザーがどこで認証するかではなく、userTypeがGuestかどうかで識別され、その月に1つ以上のガバナンスアクションがあったゲストユーザーが請求対象として扱われます。(Microsoft Learn)
実務では、次のような確認が必要です。
- 外部ユーザーが
MemberではなくGuestとして登録されているか - B2B招待ユーザーの棚卸しができているか
- アクセスレビュー、アクセスパッケージ、外部ユーザーライフサイクル管理の対象範囲を定義しているか
- Azureサブスクリプションの課金設定を誰が管理するか決めているか
特に外部委託先、販売代理店、共同研究先などを大量に招待している組織では、ゲストのガバナンスアクションが増えると月次請求に影響します。アクセスパッケージの設計段階で、ゲストユーザーの数と利用頻度を見積もっておきましょう。
API-driven provisioningとAccount Discoveryの確認ポイント
開発者やID連携担当者が確認すべきポイントは、API-driven provisioningとAccount Discoveryです。
API-driven provisioningは、/bulkUpload APIを使って取得されたIDを、オンプレミスActive DirectoryまたはMicrosoft Entra IDへプロビジョニングする機能です。この機能では、ソースとして取り込まれプロビジョニングされるすべてのIDに対して十分なライセンス数が必要です。(Microsoft Learn)
また、使用量制限も見逃せません。
| ライセンス構成 | 24時間あたりのユーザーレコード上限 | API-driven provisioningジョブ上限 |
|---|---|---|
| Microsoft Entra ID P1またはP2 | 100,000ユーザーレコード | 各フロー最大2ジョブ |
| Microsoft Entra ID Governance + P1またはP2 | 300,000ユーザーレコード | 各フロー最大20ジョブ |
大規模な人事システム連携や複数アプリへのプロビジョニングを行う場合、P1/P2だけではジョブ数やレコード数が足りない可能性があります。PoCでは動いても、本番展開で対象アプリや対象部門が増えた時に制限へ当たることがあります。
Account Discoveryは、ターゲットアプリケーション内の既存ユーザーアカウントを検出し、Entraアカウントと一致するユーザーや孤立アカウントを識別する機能です。この機能にはMicrosoft Entra ID GovernanceアドオンまたはMicrosoft Entra Suiteが必要です。(Microsoft Learn)
退職者アカウント、共有アカウント、アプリ側にだけ残った孤立アカウントを洗い出す用途では有効ですが、検出後の削除・無効化フローまで設計しないと、棚卸しだけで終わってしまいます。
管理者が展開前にやるべきチェックリスト
Microsoft Entra ID Governanceを導入または見直す場合は、次の順番で確認すると手戻りを減らせます。
| チェック項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| 前提ライセンス | P1、P2、E3、E5、Governance、Suiteの有無 | Governanceだけを見て、前提サービスプランの期限を見落とす |
| 対象機能 | EM、AR、LCW、PIM、API-driven provisioning、Account Discovery、Agent 365を分類 | P2で足りる機能とGovernanceが必要な機能を混同する |
| 対象ユーザー数 | 申請者、レビュー対象者、承認者、管理者、ワークフロー対象者を集計 | 実際の利用者だけを数え、スコープ内ユーザーを見落とす |
| ゲスト課金 | Azureサブスクリプション、userType、月間アクションを確認 | ゲストを従業員ライセンスと同じ見積もりにする |
| PIM期限切れ | 試用版・契約更新日・PIM設定のバックアップを確認 | 試用終了後に有資格割り当てが消える |
| Agent 365 | エージェントID、サービスプリンシパル、スポンサータスクの利用有無を確認 | 人間のユーザーだけで権限設計を完了してしまう |
| API制限 | /bulkUploadのレコード数、ジョブ数、対象アプリ数を確認 | PoC規模では問題なく、本番規模で上限に当たる |
移行・展開時の実務ポイント
まず小さなスコープで検証する
最初から「全従業員」を対象にアクセスパッケージやアクセスレビューを作ると、ライセンス見積もりも運用負荷も一気に増えます。最初は、特権管理者、情報システム部門、特定プロジェクト、外部委託先など、目的が明確な範囲から始めるのが現実的です。
アクセスパッケージは「便利な申請フォーム」ではなく「権限境界」として設計する
エンタイトルメント管理を単なる申請フォームとして使うと、承認者が形だけになり、アクセス権の棚卸しも曖昧になります。アクセスパッケージは、業務ロール、利用期限、承認者、レビュー頻度、削除条件をセットで設計してください。
PIMはライセンス更新とセットで管理する
PIMは管理者権限を守る中核機能です。ライセンス更新、契約変更、試用版終了の影響を受けるため、契約管理部門とID管理部門の連携が必要です。PIM対象ロール、承認者、レビュー設定は、定期的にエクスポートしておくと復旧時に役立ちます。
プレビュー機能は本番の統制要件に直結させすぎない
公式ドキュメントでは、一部の機能にプレビュー表記があります。プレビュー機能は仕様や提供条件が変わる可能性があるため、監査・法令対応・本番統制の必須プロセスに組み込む場合は、代替手順や変更時の見直し計画を用意しておくべきです。
日本語ドキュメントだけでなく英語版・製品条項も確認する
Microsoft Learnの日本語ページは便利ですが、表の翻訳や数値表記が読み取りにくい場合があります。ライセンス見積もりや契約判断を行う場合は、日本語ページだけで確定せず、英語版、製品条項、管理センター上の実際の表示も確認してください。
開発者が確認すべき点
開発者や自動化担当者は、ライセンスを管理者任せにせず、実装前に次の点を確認してください。
- API-driven provisioningの対象ID数が、P1/P2の上限で足りるか
/bulkUploadの呼び出し設計が、24時間あたりのレコード制限を超えないか- Logic Appsなどのカスタム拡張を使う場合、追加のライセンスや課金が発生しないか
- PIM、アクセスレビュー、エンタイトルメント管理をGraph APIやPowerShellで操作する場合、ライセンス期限切れ時の失敗パターンを想定しているか
- サービスプリンシパルやエージェントIDをアクセスパッケージに含める場合、Microsoft Agent 365側の要件を確認しているか
特に、入退社処理を自動化するワークフローでは、ライセンス不足が単なるエラーではなく、権限付与漏れや退職者権限の残存につながります。実装時には、エラー検知、再実行、監査ログ、通知まで含めて設計しましょう。
この記事のまとめ
Microsoft Entra ID Governance licensing fundamentalsで最も重要なのは、製品名ではなくどの機能を、誰に、どの範囲で使うかです。
今回の公式情報では、Microsoft Agent 365やエージェントIDのガバナンスがより明確に扱われ、従業員、ゲスト、エージェント、サービスプリンシパルを分けてライセンスと運用を考える必要性が高まっています。
管理者が次に取るべき行動は、次の3つです。
- Microsoft Entra管理センターで現在のライセンスと前提サービスプランを確認する
- 使う予定の機能を、エンタイトルメント管理、アクセスレビュー、ライフサイクルワークフロー、PIM、API-driven provisioning、Account Discovery、Agent 365に分けて棚卸しする
- 対象ユーザー、レビュー担当者、承認者、ゲスト、エージェントIDまで含めて、ライセンス数と展開範囲を見直す
Microsoft Entra ID Governanceは、うまく設計すれば入退社、外部ユーザー管理、特権管理、アクセスレビューを大きく効率化できます。一方で、ライセンス前提や対象範囲を誤ると、想定外のコストやPIM停止、レビュー中断といった運用リスクにつながります。導入前に小さく検証し、対象範囲を明確にしてから本番展開することが、最も安全な進め方です。
コメント