Microsoft Entra PIM ロール有効化の2026年4月更新でまず押さえるべき結論は、「操作方法が大きく変わった」というより、PIMで特権ロールを必要なときだけ有効化する運用を、最新の公式手順に合わせて再点検すべきタイミングになったという点です。対象のMicrosoft Learnページは2026年4月24日に更新されており、公開リポジトリ上の差分では、手順本文の大幅な変更ではなく、日付更新と顧客意図メタデータの整理が確認できます。(Microsoft Learn)
ただし、security admins、identity teams、compliance teamsにとって重要なのは「更新内容そのもの」だけではありません。Microsoft Entra Privileged Identity Management（PIM）では、対象ユーザーがeligibleな管理者ロールを必要時にactivateし、一定時間だけ管理権限を持つ形になります。常時Global Administratorを付与しない設計、MFA・承認・理由入力・監査ログの運用が、今回の確認ポイントです。(Microsoft Learn)
Microsoft Entraの最新動向: Activate Microsoft Entra roles in PIM – Microsoft Entra ID Governanceで何が変わったか
今回取り上げる公式ページは、Microsoft Entra ID Governance内の「Activate a Microsoft Entra role in PIM」です。ページ上では、PIMがMicrosoft Entra ID、Microsoft 365、Microsoft Intuneなどに関わる特権アクセス管理を簡素化する仕組みとして説明されています。(Microsoft Learn)
2026年4月更新の読み方としては、次のように整理できます。
| 確認項目 | 2026年4月時点のポイント | 実務での見方 |
|---|---|---|
| 公式ページの更新日 | Microsoft Learn上では2026年4月24日更新 | 既存のPIM運用手順を最新Docsに照らして確認する |
| GitHub上の公開差分 | ms.dateの更新とCustomer intentメタデータ整理が確認できる | 新機能発表ではなく、ドキュメントの現行化として扱う |
| 中心となる手順 | My rolesからMicrosoft Entra roleをactivateする流れ | 管理者向け手順書・教育資料を見直す |
| 重要な注意点 | ロール割り当ての反映とアプリ側のキャッシュは別問題 | 「有効化したのに使えない」「無効化したのに残る」を想定する |
| API対応 | Microsoft Graph APIでeligible roleの確認やselfActivateが可能 | 自動化・監査・運用ポータル連携で活用する |
| モバイル対応 | Azure mobile appからPIMロール操作が可能 | インシデント対応やオンコール運用で検討する |
公開差分だけを見ると、2026年4月24日の変更はms.dateを2025年1月6日から2026年4月23日に更新する内容が中心です。また、同日にCustomer intentをメタデータ側へ整理する変更も確認できます。したがって、「PIMのロール有効化UIが全面的に変わった」「承認仕様が大きく変わった」といった断定は避けるべきです。(GitHub)
一方で、公式ページにはPIMロール有効化時の重要な運用上の注意点がまとまっています。特に、ロールがactivateされるとMicrosoft Entra PIMが一時的なactive assignmentを作成し、deactivation時にはそれを削除します。ただし、アプリケーション側がロール状態をキャッシュしている場合、アクセス許可の反映や解除がすぐに見えないことがあります。(Microsoft Learn)
Microsoft Entra PIMのロール有効化とは
Microsoft Entra PIMのロール有効化とは、普段は管理者権限を持たない、または有効化されていないユーザーが、必要な作業のために一時的に管理者ロールを有効化する仕組みです。
たとえば、Microsoft 365の設定をたまに変更する担当者に、常時Global Administratorを付与するのはリスクが高くなります。その代わりに、Exchange Administratorなど必要なMicrosoft Entra roleをeligible assignmentとして付与し、作業時だけactivateする設計にします。公式ページでも、eligibleな管理者ロールを持つユーザーが、特権操作を行う必要があるときにロール割り当てをactivateする流れとして説明されています。(Microsoft Learn)
PIM運用では、次の3つの状態を区別することが重要です。
| 状態 | 意味 | 実務での使いどころ |
|---|---|---|
| Eligible assignment | ユーザーはロール候補者だが、普段は権限が有効ではない | 通常の管理者運用に推奨される基本形 |
| Active assignment | 一定時間だけロールが有効になっている状態 | 変更作業、障害対応、監査対応など |
| Permanent active assignment | 常時ロールが有効な状態 | 例外的な運用。最小限に抑えるべき |
security adminsが最初に確認すべきなのは、「誰にどのロールを常時付与しているか」ではなく、「誰がどのロールをeligibleとして持ち、どの条件でactivateできるか」です。PIMの価値は、単にロールを付け替えることではなく、特権アクセスを必要最小限の時間・範囲・理由に絞る点にあります。
2026年4月更新で特に確認したいポイント
大幅な機能変更ではなく、運用ルールの再確認として読む
今回の更新は、少なくとも公開されているGitHub差分上では、手順そのものを大きく書き換える変更ではありません。だからこそ、既存運用をそのまま放置するのではなく、現在の公式手順と自社の運用手順がずれていないかを確認するのが現実的です。(GitHub)
特に確認したいのは次の点です。
- eligible assignmentを持つユーザーが、実際にMy rolesからロールをactivateできるか
- MFAや追加認証が、期待したタイミングで要求されるか
- 承認が必要なロールで、承認者が不在になっていないか
- 理由入力やチケット番号が、監査で追える内容になっているか
- 有効化後、対象アプリや管理ポータルに権限が反映されるまでの挙動を把握しているか
- deactivation後も、アプリ側キャッシュにより一時的にアクセスできる可能性を考慮しているか
「Prerequisites: None」をライセンス不要と誤解しない
対象のロール有効化手順ページでは、Prerequisitesは「None」とされています。これは、ユーザーが自分に割り当てられたeligible roleをactivateする手順において、追加の前提条件を大きく置いていないという文脈で読むべきです。(Microsoft Learn)
一方、PIMを利用するテナントには有効なライセンスが必要です。Microsoftのライセンス説明では、PIMを使うにはMicrosoft Entra ID P2またはMicrosoft Entra ID Governanceのライセンスが必要とされています。また、eligibleまたはtime-bound assignmentを持つユーザー、承認者、アクセスレビュー担当者などもライセンス確認の対象になります。(Microsoft Learn)
運用上は、次のように切り分けると誤解を防げます。
| 確認対象 | 見るべきポイント |
|---|---|
| 手順上の前提条件 | eligible role assignmentを持つユーザーがactivateできるか |
| テナント全体の前提 | PIMを利用できるライセンスがあるか |
| 監査・承認担当者 | 承認者やレビュー担当者にも必要なライセンスがあるか |
| モバイル利用 | Azure mobile appでPIMを使うユーザーのライセンス条件を満たすか |
PIMの反映は速いが、アプリ側の反映は別問題
公式ページでは、ロールがactivateされるとPIMが一時的なactive assignmentを数秒以内に作成し、deactivationまたは有効期限切れ時にもactive assignmentを削除すると説明されています。重要なのは、その後に続く注意点です。アプリケーション側がユーザーのロール状態をキャッシュしている場合、アクセス付与や解除が即座に反映されないことがあります。場合によっては、サインアウトとサインインのやり直しが有効です。(Microsoft Learn)
これは、現場でよくあるトラブルの原因になります。
| よくある現象 | 原因として考えられること | 対応 |
|---|---|---|
| activateしたのに管理画面に入れない | アプリ側が以前の「権限なし」状態をキャッシュしている | サインアウト・再サインイン、ブラウザー変更、少し待って再試行 |
| deactivateしたのに操作できるように見える | アプリ側が以前の「権限あり」状態をキャッシュしている | 操作ログを確認し、セッション終了や再認証を促す |
| 管理ポータルによって反映タイミングが違う | 各アプリの認可・セッション設計が異なる | 重要サービスごとに検証手順を作る |
compliance teamsは、PIM上でactive assignmentが削除された時刻だけでなく、対象アプリ側の操作ログも合わせて見る必要があります。「PIMで無効化済みだから完全に操作不能」と単純化しないほうが安全です。
Microsoft Entra admin centerでロールを有効化する手順
公式手順では、eligible role assignmentを持つユーザーがMicrosoft Entra admin centerにサインインし、ID Governance配下のPrivileged Identity ManagementからMy rolesを開いて、Microsoft Entra rolesを選択します。その後、対象ロールのActivateを選び、必要に応じて追加認証、スコープ、開始時刻、理由を入力して有効化します。(Microsoft Learn)
| 手順 | 操作 | 実務上の注意点 |
|---|---|---|
| 1 | Microsoft Entra admin centerにサインイン | eligible assignmentを持つユーザーでサインインする |
| 2 | ID Governance > Privileged Identity Management > My rolesを開く | My rolesは自分に割り当てられたeligible/active role確認の入口 |
| 3 | Microsoft Entra rolesを選択 | Azure resource rolesと混同しない |
| 4 | 対象ロールのActivateを選択 | 作業に必要なロールだけを選ぶ |
| 5 | Additional verification requiredが出たら認証 | MFAはセッション状態により再要求されない場合がある |
| 6 | Scopeを必要最小限に設定 | 可能な場合、最小スコープに絞る |
| 7 | 必要に応じて開始時刻を指定 | 予定作業なら作業開始直前に合わせる |
| 8 | Reasonに理由を入力 | 監査で読める具体的な理由を書く |
| 9 | Activateを選択 | 承認が必要な場合はpending approvalになる |
理由欄には「作業の目的」「対象システム」「変更チケット番号」「予定作業時間」を含めると、後から監査しやすくなります。
悪い例:
作業のため良い例:
INC-2026-0424-001: Exchange Onlineの配送ルール誤設定修正。対象はcontoso.comテナント、本日14:00-15:00の承認済み変更作業。PIMの理由入力は、単なる入力欄ではなく、後日の説明責任を支える証跡です。特にグローバル企業では、タイムゾーン、チケット番号、対象環境、本番・検証の区別まで書くと、監査やインシデントレビューで役立ちます。
MFA・承認・スコープ設定で見るべきポイント
MFAは「毎回必ず出る」とは限らない
公式手順では、追加検証が必要な場合はAdditional verification requiredを選び、指示に従ってセキュリティ検証を行うとされています。また、認証はセッションごとに一度だけ必要と説明されています。(Microsoft Learn)
つまり、管理者が「毎回MFAが表示されるはず」と考えていると、実際の動きとずれることがあります。より強く再認証を求めたい場合は、PIMのロール設定だけでなく、Conditional Access authentication contextやAuthentication Strengthsを組み合わせる設計が必要です。Microsoftのロール設定ドキュメントでは、activation時にConditional Access policyの要件を満たすよう設定できること、また毎回の再認証を求めるにはauthentication contextを対象にした条件付きアクセスポリシーでsign-in frequencyをEvery timeに設定する考え方が説明されています。(Microsoft Learn)
承認者は複数設定し、ロックアウトを避ける
PIMでは、eligible assignmentのactivationに承認を要求できます。Microsoftのロール設定ドキュメントでは、承認を要求する場合は少なくとも1人の承認者を選択し、推奨として少なくとも2人の承認者を選ぶことが示されています。(Microsoft Learn)
特に危険なのは、すべてのGlobal AdministratorやPrivileged Role Administratorがeligible assignmentのみで、activationに承認が必要なのに、承認者が設定されていない状態です。この条件が重なるとテナントからロックアウトされる可能性があるため、emergency access accountsと明示的な承認者の設定が必要です。(Microsoft Learn)
| 対象ロール | 推奨される設定例 | 理由 |
|---|---|---|
| Global Administrator | eligible中心、承認必須、短時間、有効な緊急用アカウントを別管理 | 影響範囲が最大のため |
| Privileged Role Administrator | 承認必須、複数承認者、理由・チケット必須 | PIM自体を管理できるため |
| Conditional Access Administrator | 強い再認証、承認、変更チケット必須 | アクセス制御を変更できるため |
| Security Administrator | MFAまたは認証コンテキスト、理由必須 | セキュリティ設定や調査に影響するため |
| Exchange/SharePoint/Teams Administrator | 理由・チケット必須、必要に応じて承認 | 業務影響が大きいサービス管理権限のため |
スコープは「必要最小限」を基本にする
公式手順では、必要に応じてScopeを選び、アクセスが必要なMicrosoft Entra resourcesを指定できると説明されています。また、必要最小限のリソースへのアクセスを要求することがベストプラクティスとして示されています。(Microsoft Learn)
実務では、「とりあえず全体スコープでactivateする」運用が定着しやすい点に注意が必要です。特に複数部門、複数リージョン、複数管理単位を持つ組織では、ロールとスコープをセットで設計しないと、PIMを導入しても過剰権限が残ります。
Microsoft Graph APIでPIMロール有効化を扱う場合
Microsoft Graph APIを使うと、PIMで有効化可能なロールの確認やselfActivateのリクエストを自動化できます。公式ページでは、現在のユーザーがactivateできるeligible roleを取得する例として、次のエンドポイントが示されています。(Microsoft Learn)
GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleEligibilityScheduleRequests/filterByCurrentUser(on='principal')ただし注意点があります。ユーザーがグループメンバーシップ経由でrole eligibilityを得ている場合、このMicrosoft Graphリクエストではそのeligibilityが返らないと説明されています。API連携で「対象者にeligible roleがない」と判定する前に、直接割り当てなのか、グループ経由なのかを確認してください。(Microsoft Learn)
selfActivateでは、roleAssignmentScheduleRequestsに対してaction: selfActivateを送ります。実装時は、principalId、roleDefinitionId、directoryScopeId、justification、scheduleInfo、必要に応じてticketInfoを含めます。公式ページでは、expirationにAfterDurationを使った例も示されています。(Microsoft Learn)
{
"action": "selfActivate",
"principalId": "<user-id>",
"roleDefinitionId": "<role-definition-id>",
"directoryScopeId": "/",
"justification": "INC-2026-0424-001: 承認済み変更作業のため",
"scheduleInfo": {
"startDateTime": "2026-04-24T05:00:00.000Z",
"expiration": {
"type": "AfterDuration",
"duration": "PT2H"
}
},
"ticketInfo": {
"ticketNumber": "INC-2026-0424-001",
"ticketSystem": "ServiceNow"
}
}APIでPIMを扱うidentity teamsは、通常のディレクトリロール割り当てAPIとPIMのスケジュール要求を混同しないことが重要です。Microsoft GraphのPIM API概要では、PIMで管理するactive role assignmentsにはunifiedRoleAssignmentScheduleRequestを使う考え方が示されており、PIM管理対象のロール割り当てを直接unifiedRoleAssignmentやdirectoryRoleで扱うのではなく、PIMを使うよう説明されています。(Microsoft Learn)
また、PIM for Microsoft Entra rolesのアクティビティはMicrosoft Entra audit logsに記録され、Microsoft Graphのdirectory audits APIでも読み取れると説明されています。自社のSIEMや監査基盤に連携する場合は、PIMのactivation request、approval、deactivation、role assignment変更をセットで取得できるように設計しましょう。(Microsoft Learn)
Azure mobile appでのPIMロール有効化
2026年4月時点の公式ページでは、PIMがAzure mobile appで利用可能であり、Microsoft Entra IDとAzure resource rolesのeligible assignmentsをactivateしたり、期限切れが近い割り当てのrenewal request、pending requestの状態確認ができると説明されています。(Microsoft Learn)
これは、オンコール担当者やインシデント対応チームには便利です。たとえば、夜間にSecurity Administratorロールを短時間だけ有効化し、検知アラートの確認や緊急ブロックを行うといった使い方ができます。
ただし、モバイル対応は「手軽に特権を有効化できる」ことでもあります。導入する場合は、次の条件をあわせて確認してください。
| 確認項目 | 推奨対応 |
|---|---|
| 端末管理 | Intune管理済み、または条件付きアクセスで準拠端末を要求する |
| 認証 | MFA、パスワードレス、認証強度の要件を明確にする |
| 承認 | 高リスクロールはモバイルからでも承認フローを省略しない |
| 理由入力 | モバイルでも入力しやすい理由テンプレートを用意する |
| 監査 | モバイル経由のactivationも通常のPIMログとして確認する |
| 緊急時 | 承認者不在時の連絡経路と緊急用アカウントを整備する |
また、公式ページでは、管理ロールをactivateするユーザーがモバイルデバイスでMicrosoft Teamsにサインインしている場合、Teamsアプリ側で通知継続のためにTeamsを開くよう求める通知が表示されることがあり、この挙動は設計上の動作だと説明されています。ヘルプデスクには、この問い合わせが来る可能性を共有しておくとよいでしょう。(Microsoft Learn)
承認ワークフローと監査で押さえること
PIMでは、ロールごとにactivation時のMFA、承認、理由入力、最大有効時間、通知設定などを構成できます。Microsoftのロール設定ドキュメントでは、これらのrole settingsはロール単位で定義され、同じロールに対するすべての割り当てに適用されると説明されています。また、Microsoft Entra roleのPIM role settingsを管理するには、少なくともPrivileged Role Administratorが必要です。(Microsoft Learn)
承認が必要なロールでは、承認者が24時間以内にapproveまたはdenyする必要があります。Microsoft Entra roles向けの承認ドキュメントでは、24時間以内に承認されなかった場合、eligible userは新しいリクエストを再送信する必要があり、この24時間の承認時間枠は構成変更できないと説明されています。(Microsoft Learn)
compliance teamsが特に見るべき項目は次の通りです。
| 監査項目 | 確認内容 |
|---|---|
| 誰がactivateしたか | ユーザー、ロール、時刻、スコープ |
| なぜactivateしたか | 理由、チケット番号、作業対象 |
| 誰が承認したか | 承認者、承認時刻、承認理由 |
| どれくらい有効だったか | 開始時刻、終了時刻、手動deactivateの有無 |
| 実際に何を操作したか | 対象アプリや管理ポータル側の操作ログ |
| 例外があったか | 緊急対応、承認者不在、期限切れ、再申請 |
ロール設定では、activation時にbusiness justificationやticket informationを要求できます。ただし、ticket informationは情報入力用のフィールドであり、チケットシステムとの相関は強制されないと説明されています。したがって、ServiceNow、Jira、Azure DevOpsなどの変更管理システムと整合させる場合は、理由欄のテンプレートやSIEM側の突合ルールを別途設計する必要があります。(Microsoft Learn)
よくある失敗と対策
PIMの導入後に起きやすい失敗は、機能不足よりも運用設計の不足から発生します。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| ユーザーがMy rolesでロールを見つけられない | eligible assignmentがない、別ディレクトリを見ている、グループ経由割り当ての扱いを誤解している | 直接割り当て・グループ経由・ディレクトリ選択を確認する |
| activate後も管理画面に入れない | アプリ側キャッシュやセッションの影響 | サインアウト・再サインイン、別ブラウザー、少し待って再試行 |
| deactivate後も操作できるように見える | アプリ側が権限あり状態をキャッシュしている | PIMログだけでなく対象アプリの操作ログも確認 |
| 承認が止まる | 承認者が不在、通知を見落としている | 承認者を複数設定し、代替連絡経路を決める |
| MFAが毎回出ない | 同一セッションで認証済み | 条件付きアクセスのauthentication contextやsign-in frequencyを検討 |
| ロックアウトのリスクがある | 全GA/PRAがeligibleのみ、承認必須、承認者未設定 | emergency access accountsと明示的な承認者を設定 |
| APIでeligible roleを取得できない | グループメンバーシップ経由のeligibilityが返らないケース | 割り当て方式を確認し、API結果だけで判断しない |
| 監査で理由が説明できない | 理由欄が抽象的 | チケット番号、対象、目的、時間を含む入力ルールを作る |
| モバイル利用で問い合わせが増える | Teams通知やモバイル認証の挙動を周知していない | ヘルプデスクFAQに追加する |
なお、activateされたロールはPIMポータルでDeactivateできますが、公式ページではactivation後5分以内はrole assignmentをdeactivateできないと説明されています。短時間作業の手順書では、この点も明記しておくと混乱を防げます。(Microsoft Learn)
security admins、identity teams、compliance teams別の対応ポイント
security adminsが確認すべきこと
security adminsは、特権ロールの常時付与を減らすことを最優先にしてください。Global Administrator、Privileged Role Administrator、Conditional Access Administrator、Security Administratorのような高リスクロールは、eligible assignmentを基本にし、承認、MFA、理由入力、短い有効時間を組み合わせます。
また、条件付きアクセス管理者やセキュリティ管理者自身も高権限者です。PIMで守るべき対象に、PIMやConditional Accessを変更できる管理者を含めることが重要です。
identity teamsが確認すべきこと
identity teamsは、PIMのロール設定、eligible assignment、Graph API連携、ライセンス、監査ログ取得を一貫した運用として整備します。
具体的には、次の作業が優先です。
- Microsoft Entra rolesごとのPIM policyを棚卸しする
- 常時active assignmentを洗い出す
- eligible assignmentの付与理由と有効期限を確認する
- Graph APIでの自動化対象を決める
- API連携でグループ経由eligibilityを見落とさないようにする
- Azure mobile app利用時の条件付きアクセスを確認する
compliance teamsが確認すべきこと
compliance teamsは、「PIMを導入しているか」だけでなく、「PIMの証跡が監査で説明できる形になっているか」を見ます。
理由欄が「メンテナンスのため」だけでは、後から作業目的や承認根拠を説明しにくくなります。変更チケット番号、対象サービス、作業内容、承認者、作業時間を紐付けるルールを作り、PIMログと対象アプリの操作ログを突合できるようにしておきましょう。
2026年4月更新後に行うべきチェックリスト
Microsoft Entra PIM ロール有効化の運用を見直すなら、次の順番で進めると効率的です。
| 優先度 | チェック内容 | 担当 |
|---|---|---|
| 高 | Global AdministratorとPrivileged Role Administratorの常時active assignmentを確認 | security admins / identity teams |
| 高 | PIM利用に必要なMicrosoft Entra ID P2またはID Governanceライセンスを確認 | identity teams |
| 高 | 高リスクロールでMFA、承認、理由入力が有効か確認 | security admins |
| 高 | 承認者が複数設定され、退職者や異動者が残っていないか確認 | identity teams |
| 高 | emergency access accountsを整備し、通常運用とは別に監視 | security admins |
| 中 | 理由欄・チケット番号の入力ルールを標準化 | compliance teams |
| 中 | Graph API連携でPIM schedule requestを正しく使っているか確認 | identity teams |
| 中 | Azure mobile app利用を許可する条件を明文化 | security admins |
| 中 | activate/deactivate後のアプリ側キャッシュ挙動を主要サービスで検証 | identity teams |
| 中 | PIMログと対象サービスの操作ログをSIEMで突合 | compliance teams |
| 低 | ヘルプデスク向けFAQにTeams mobile通知やMFA再要求の挙動を追加 | identity teams |
最初に取り組むべきなのは、すべてのロールを細かく最適化することではありません。まずは、影響範囲の大きいロールから、常時activeを減らし、eligible化し、activation条件を厳格化することです。
まとめ: 今回の更新は「PIM運用の棚卸し」の合図
2026年4月24日に更新された「Activate a Microsoft Entra role in PIM」は、公開差分を見る限り、PIMの操作を大きく変える新機能発表ではありません。しかし、Microsoft Entra PIM ロール有効化の公式手順が現行化されたタイミングとして、管理者ロールの運用を見直す価値があります。(Microsoft Learn)
特に重要なのは、eligible assignmentを基本にすること、activate時にMFA・承認・理由入力を適切に求めること、アプリ側キャッシュによる反映遅延を想定すること、そして監査で説明できる証跡を残すことです。
次に取るべき行動は明確です。高リスクなMicrosoft Entra rolesから順に、常時active assignment、PIM role settings、承認者、理由入力ルール、監査ログ連携を確認してください。PIMは設定して終わりではなく、特権アクセスを継続的に絞り込み、説明可能にするための運用基盤です。
コメント