Microsoft IntuneのMulti Admin Approvalは、重要な変更を「1人の管理者だけで即時反映させない」ための承認機能です。アプリ配布、Windows向けスクリプト、デバイスのワイプ、RBAC、コンプライアンスポリシー、設定カタログの構成ポリシーなどを保護対象にし、別の管理者が承認してから変更を適用できます。管理者アカウントの侵害や誤操作による大きな影響を抑えたい組織では、まず高リスクな操作から段階的に有効化するのが現実的です。(Microsoft Learn)
2026年5月時点で特に確認したいポイントは、Multi Admin Approvalの対象がコンプライアンスポリシーと設定カタログで作成したデバイス構成ポリシーにも広がっていること、Windows PowerShellスクリプトの承認判断にChange Review Agentの提案を同じ画面で確認できるようになっていること、さらにAdmin tasksから承認タスクをまとめて扱えることです。(Microsoft Learn)
Microsoft IntuneのMulti Admin Approvalとは
Microsoft IntuneのMulti Admin Approval、略してMAAは、保護対象にしたリソースの変更を、別の管理者の承認があるまで適用しない仕組みです。たとえば、管理者Aがデバイスのワイプを実行しようとしても、管理者Bが承認するまでIntuneはその変更を反映しません。承認者は承認だけでなく拒否もできます。(Microsoft Learn)
この機能の目的は、単なる「ダブルチェック」ではありません。管理者アカウントが侵害された場合や、権限を持つ担当者が誤って広範囲に影響する設定を変更した場合でも、別アカウントによる確認を挟むことで被害を抑えることにあります。
特に次のような環境では導入効果が大きくなります。
- IntuneでWindows端末、モバイル端末、アプリ配布を一元管理している
- ヘルプデスクや運用担当者に一部のリモート操作権限を付与している
- PowerShellスクリプトやWin32アプリをIntuneから展開している
- RBACロールや管理者グループの変更を複数人で管理したい
- 監査対応として、変更理由と承認履歴を残したい
2026年5月時点で押さえるべき変更点
Multi Admin Approval自体は「重要操作に承認を追加する機能」ですが、最新のIntune運用では対象範囲と承認画面の使い勝手が重要になっています。
| 変更・確認ポイント | 管理者への影響 |
|---|---|
| コンプライアンスポリシーがMAA対象に対応 | 準拠状態の判定基準を変更する前に、別管理者の承認を求められる |
| 設定カタログのデバイス構成ポリシーがMAA対象に対応 | Windowsなどの構成変更を本番反映する前に承認フローを挟める |
| Change Review Agentの提案がMAA画面に表示可能 | Windows PowerShellスクリプトのリスク判断を承認画面内で確認しやすくなる |
| Admin tasksでMAAリクエストを集中管理可能 | 承認担当者が複数の場所を移動せず、対応すべきタスクを確認しやすくなる |
コンプライアンスポリシーや設定カタログの構成ポリシーは、端末の準拠判定、条件付きアクセス、セキュリティ設定に直結しやすい領域です。ここがMAAの対象になることで、「うっかり全社端末に厳しすぎる設定を配布した」「テスト前のコンプライアンス条件を本番に適用した」といった事故を抑えやすくなります。(Microsoft Learn)
また、Change Review Agentを構成済みで実行済みの場合、Windows PowerShellスクリプトのMAAリクエストに対して、My requestsやAll requestsタブにAgent Response列が表示されます。承認者はMAAノードから離れずに、リスクベースの提案を確認できます。(Microsoft Learn)
Multi Admin Approvalで保護できる対象範囲
Microsoft Learnの公式情報では、IntuneのMAAアクセスポリシーで次のリソースを保護できます。すべてのIntune操作が対象になるわけではないため、自社の運用で「どこに承認を入れるべきか」を分けて考える必要があります。(Microsoft Learn)
| リソース | 保護される主な操作 | 実務上の注意点 |
|---|---|---|
| Apps | アプリのデプロイ | アプリ保護ポリシーは対象外 |
| Compliance policies | コンプライアンスポリシーの作成・管理 | 条件付きアクセスと組み合わせている場合は影響確認が重要 |
| Configuration policies | 設定カタログ経由のポリシー作成・管理 | 端末設定の広範囲な変更を防ぎやすい |
| Device actions | wipe、retire、delete | 誤操作の影響が大きいため優先度が高い |
| Role-based access control | ロール権限、管理者グループ、メンバーグループ割り当ての変更 | 設定順序を誤ると運用が詰まる可能性がある |
| Scripts | Windowsデバイス向けスクリプト展開 | スクリプト内容のレビュー体制が必要 |
| Tenant Configuration | デバイスカテゴリの作成・編集・削除 | 棚卸しや割り当て運用に影響する |
| Access policies | MAAアクセスポリシー自体の変更 | 自動的に保護され、作成時の選択肢には表示されない |
実務では、最初からすべてを保護するよりも、影響が大きい順に有効化するほうが失敗しにくくなります。優先度が高いのは、デバイスのワイプや削除、Windows PowerShellスクリプト、RBAC、全社向けアプリ配布、コンプライアンスポリシーです。
導入前に確認すべき前提条件
MAAを使うには、少なくとも2つの管理者アカウントが必要です。リクエストした管理者は、自分自身のリクエストを承認できません。これは承認グループのメンバーであっても同じです。また、グローバル管理者やIntune管理者が送信した変更でも、別の管理者による承認が必要です。(Microsoft Learn)
管理者ライセンスの確認
既定では、MAAワークフローに参加する管理者にはIntuneライセンスが必要です。ライセンス未割り当ての管理者にもIntune管理センターへのアクセスを許可する場合は、Allow access to unlicensed adminsを有効化します。ただし、古いテナントでこの設定を有効化すると元に戻せません。事前に運用ポリシーを確認してから実施してください。(Microsoft Learn)
なお、2021年7月より後に作成されたテナントでは、ライセンス未割り当て管理者のアクセスが既定でサポートされます。2021年7月より前のテナントでは、必要に応じて手動で有効化します。ネストされたセキュリティグループのメンバーは未ライセンス管理者機能に含まれず、アクセス変更の反映に最大48時間かかる場合があります。(Microsoft Learn)
承認グループの条件
承認者は、単にIntuneの権限を持っているだけでは不十分です。承認対象のアクセスポリシーに割り当てられた承認グループのメンバーであり、対象リソースのRead権限を持ち、さらに承認者のセキュリティグループ自体がIntuneロール割り当てのメンバーグループとして直接追加されている必要があります。(Microsoft Learn)
ここで失敗しやすいのが、グループ種別です。承認グループにはセキュリティグループを使います。配布リスト、Microsoft 365グループ、メール有効なセキュリティグループはサポートされません。また、個々のユーザーが別経路で権限を持っていても、承認グループ自体がIntuneロールに直接割り当てられていないと要件を満たしません。(Microsoft Learn)
アクセスポリシーの作成手順
Multi Admin Approvalのアクセスポリシーは、Intune管理センターのTenant administrationから作成します。各ポリシーで選択できるプロファイルタイプは1つです。複数の対象をまとめて1つのポリシーにするのではなく、アプリ、スクリプト、デバイス操作などを分けて設計します。(Microsoft Learn)
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 事前確認 | 管理者アカウント、承認グループ、RBACロールを確認 | リクエスト者と承認者を別アカウントにする |
| ポリシー作成 | Tenant administration > Multi Admin Approval > Access policies > Create | 名前、説明、Profile typeを設定 |
| 承認者設定 | Approversで承認グループを追加 | 除外グループなどの複雑な構成はサポートされない |
| 作成内容確認 | Review + Createで保存 | 保存後すぐに完全適用されるわけではない |
| 別管理者が承認 | 別アカウントで新しいアクセスポリシーを承認 | 承認者に必要な権限があるか確認 |
| 作成者が完了 | 最初の管理者がCompleteを選択 | Complete後に保護が有効になる |
重要なのは、アクセスポリシーの作成自体にも承認が必要になる点です。作成しただけで完了したと思い込むと、実際には保護が有効になっていない可能性があります。必ず別管理者の承認後、作成者側でCompleteまで実行してください。(Microsoft Learn)
変更リクエストと承認の流れ
MAAが有効な対象を変更すると、保存前の画面でBusiness justification、つまり業務上の正当性を入力してリクエストを送信します。この説明は承認者が判断する材料になるため、「設定変更の理由」だけでなく「対象範囲」「想定される影響」「ロールバック方法」まで書くと承認がスムーズです。(Microsoft Learn)
承認者は、Tenant administration > Multi Admin ApprovalのReceived requests、またはAdmin tasksからリクエストを確認できます。Business justificationを開くと詳細を確認でき、Approver notesにコメントを入れてApprove requestまたはReject requestを選択します。(Microsoft Learn)
承認された後も、変更は自動的に完了しません。元のリクエスト者がMy requestsから対象リクエストを開き、Completeを選択して初めてIntuneが変更を処理します。承認後3日以内に処理されないリクエストはExpiredになり、再送信が必要です。(Microsoft Learn)
リクエスト状態の見方
| 状態 | 意味 | 対応 |
|---|---|---|
| Needs approval | 承認待ち | 承認者に確認を依頼する |
| Approved | Intuneで処理中、または完了操作待ち | リクエスト者がCompleteを確認 |
| Completed | 正常に適用済み | 監査ログや対象ポリシーで結果確認 |
| Rejected | 承認者が拒否 | Approver notesを確認して修正 |
| Canceled | リクエスト者がキャンセル | 必要なら再作成 |
| Expired | 期限切れ | 変更リクエストを再送信 |
運用で失敗しやすいポイント
通知が送られない
Intuneは、新しいMAAリクエストの作成や状態変更時に通知を送信しません。緊急変更では、承認者にTeamsやメールなど別の連絡手段で知らせる運用が必要です。特に障害対応時は、「リクエストを出したのに誰も見ていない」という状態が起きやすいため、承認担当者リストと連絡ルールを事前に決めておきましょう。(Microsoft Learn)
同じオブジェクトに承認待ちがあると新規リクエストできない
同じオブジェクトに対して既に承認待ちのリクエストがある場合、新しいリクエストは送信できません。複数の担当者が同じアプリやポリシーを同時に修正する環境では、変更管理の順番を整理しておく必要があります。(Microsoft Learn)
RBACの保護は設定順序に注意する
Role-based access controlを保護対象にすると、RBACロールやロール割り当ての変更にもMAA承認が必要になります。これは強力ですが、MAAに必要な承認グループやロール割り当てを整える前に有効化すると、必要なRBAC設定を変更できない「デッドロック」に近い状態になる可能性があります。(Microsoft Learn)
Microsoftの公式情報では、この状態を避けるために、他のMAAアクセスポリシーとRBAC割り当てを正しく構成・確認してからRoleポリシーを有効化することが推奨されています。問題が発生した場合は、Roleポリシーのアクセスポリシーを削除し、3〜5分待ってから必要なRBAC割り当てを完了し、その後必要に応じてRoleポリシーを再作成します。(Microsoft Learn)
管理者・開発者が確認すべき実務ポイント
Intune管理者は、まず「どの操作を承認制にするか」ではなく、「承認なしで実行されると最も困る操作は何か」から考えるべきです。端末削除、ワイプ、全社配布アプリ、PowerShellスクリプト、条件付きアクセスに影響するコンプライアンス条件は優先度が高い領域です。
開発者やアプリ配布担当者は、Win32アプリやPowerShellスクリプトの展開フローに注意が必要です。公式情報では、MAAが有効なテナントではWin32アプリ作成中にPowerShellスクリプトをアップロードできず、先にアプリを作成してからスクリプトを追加または変更する必要があるとされています。また、enforceSignatureCheckやrunAs32Bitなど一部のスクリプトプロパティは現時点でMAAリクエストなしに編集できるものの、将来の更新で承認が必要になる予定とされています。(Microsoft Learn)
PowerShellスクリプトを申請する場合は、承認者が判断しやすいように、Business justificationに次の内容を含めるとよいでしょう。
- スクリプトの目的
- 対象デバイスまたは対象グループ
- 変更するレジストリ、ファイル、サービス、設定項目
- 管理者権限の要否
- 事前検証したテスト端末
- 失敗時の戻し方
- 実行後に確認するログや検出条件
Change Review Agentを使える環境では、Windows PowerShellスクリプトのMAAリクエストに対して、リスクベースの推奨事項やコンテキスト情報を確認できます。ただし、これは承認判断を支援する機能であり、承認者の責任を置き換えるものではありません。利用にはIntune Plan 1、Microsoft Entra ID P2、Microsoft Defender Vulnerability Management、Microsoft Security Copilotなどの要件があります。(Microsoft Learn)
監査ログと変更管理もセットで確認する
MAAを有効にしても、承認フローだけで運用が完成するわけではありません。Intuneには、作成、更新、削除、割り当て、リモートアクションなどの変更を記録する監査ログがあります。監査ログはTenant administration > Audit logsから確認でき、必要に応じてAzure Monitorへルーティングすることもできます。(Microsoft Learn)
実務では、MAAの承認履歴、Intune監査ログ、社内の変更申請番号をひも付けると、後から「誰が、何を、なぜ、誰の承認で変更したのか」を追いやすくなります。特に金融、医療、教育、委託運用など、説明責任が重い環境ではこの設計が重要です。
導入時のおすすめ順序
最初から全領域にMAAを適用すると、運用が止まったように感じることがあります。まずは影響が大きく、かつ承認ルールを作りやすい領域から始めましょう。
| フェーズ | 対象 | 狙い |
|---|---|---|
| 第1段階 | Device actions、Scripts | 破壊的操作や高リスクなスクリプト展開を防ぐ |
| 第2段階 | Apps、Compliance policies | 全社展開や準拠判定への影響を抑える |
| 第3段階 | Configuration policies | 設定カタログ経由の構成変更を統制する |
| 第4段階 | RBAC、Tenant Configuration | 管理権限やテナント設定の変更を厳格に管理する |
テストでは、実際に1つの小さな変更を作成し、申請、承認、Complete、監査ログ確認まで通します。承認者に見える情報が十分か、通知がない状態でも運用できるか、緊急時に誰へ連絡するかを確認してから本番対象を広げると安全です。
まとめ：Intuneの重要変更は「承認」と「完了」まで運用設計する
Microsoft IntuneのMulti Admin Approvalは、重要な変更に別管理者の承認を必須化することで、管理者アカウント侵害や誤操作のリスクを下げる機能です。2026年5月時点では、コンプライアンスポリシーや設定カタログの構成ポリシーにも対応し、Windows PowerShellスクリプトではChange Review Agentの提案をMAA画面で確認できるなど、実務で使える範囲が広がっています。
導入時は、デバイス操作、スクリプト、アプリ配布、コンプライアンス、RBACの順にリスクを評価し、承認グループとRBACロールを先に整えてください。特にRBACを保護する場合は、MAAに必要なロール割り当てを済ませてから有効化することが重要です。
次に取るべき行動は、自社テナントで「承認なしで実行されると困るIntune操作」を一覧化し、まず1つの低リスクなアクセスポリシーで申請からCompleteまでの流れを検証することです。MAAは設定して終わりではなく、承認者、連絡手段、変更理由の書き方、監査ログ確認まで含めて設計すると、現場で使えるセキュリティ統制になります。
コメント