Microsoft Entra ID Governance / My Access の注目すべき更新は、承認者が過去に承認したアクセス パッケージの割り当てを、My Access から取り消せるようになったことです。これにより、誤承認、業務要件の変更、契約終了、監査指摘などが発生したときに、管理者だけに依存せず、承認した本人がアクセスを速やかに止められます。Microsoft は 2026 年 3 月末までにこの機能を一般提供として案内しており、2026 年 4 月 16 日時点で確認すべき Microsoft Entra ID Governance の実務上重要な変更点です。(Microsoft Learn)
この更新は単なる「取り消しボタンの追加」ではありません。Just-in-Time access、最小権限、アクセス レビュー、監査対応を現場で回すうえで、承認後の例外処理をより小さな権限単位で閉じられるようにする変更です。Identity governance admins や compliance teams は、アクセス パッケージの設計、承認者の責任範囲、証跡の残し方を見直す価値があります。
My Access の承認取り消し機能で何が変わったのか
Microsoft Entra ID Governance の Entitlement Management では、アクセス パッケージを使って、Microsoft Entra セキュリティ グループ、Microsoft 365 グループと Teams、エンタープライズ アプリ、SharePoint Online サイトなどへのアクセスをまとめて管理できます。アクセス パッケージは、ユーザーが業務やプロジェクトに必要なリソース一式へアクセスするための単位として設計されます。(Microsoft Learn)
今回の更新では、My Access の承認履歴から、承認者が自分の過去の承認判断を取り消せます。Microsoft Learn の手順では、My Access で Approvals > History を開き、取り消したい承認済みリクエストを選択し、Remove から理由を入力してアクセスを削除します。前提として、承認者には Microsoft Entra ID Governance ライセンスが必要です。(Microsoft Learn)
特に重要なのは、Microsoft のリリース情報で「承認を行った本人だけが取り消せる」と説明されている点です。複数の承認者が同じ承認者グループに属していても、過去に承認した当人以外はその承認を取り消せません。(Microsoft Learn)
この制約は、運用上は少し不便に見えるかもしれません。しかし、監査の観点では「誰が承認し、誰が取り消したのか」を明確にしやすくなります。承認責任を曖昧にせず、承認者自身に後続の説明責任を持たせる設計と考えると理解しやすいでしょう。
なぜ Just-in-Time access governance に効くのか
Just-in-Time access governance の要点は、必要な人に、必要な期間だけ、必要な権限を付与することです。従来の課題は、承認までは丁寧に制御していても、承認後に状況が変わったときの取り消しが遅れやすいことでした。
たとえば、次のようなケースです。
| ケース | 従来起きやすかった問題 | 承認取り消しで改善できる点 |
|---|---|---|
| 外部パートナーの作業が予定より早く終了した | 契約終了日やアクセス期限まで権限が残る | 承認者が不要と判断した時点で取り消せる |
| 誤って広いアクセス パッケージを承認した | 管理者への依頼や棚卸しまで残存する | 承認者本人が履歴から修正できる |
| 申請理由と実際の利用目的が違った | 次回レビューまで検知・是正が遅れる | 業務判断を知る承認者が即時対応できる |
| 監査で不要アクセスを指摘された | IAM チームに削除作業が集中する | 承認ライン側で是正アクションを実行しやすい |
アクセス パッケージには、承認、ライフサイクル設定、有効期限、アクセス レビューなどを組み合わせられます。Microsoft の作成ガイドでも、ポリシーによって誰が要求できるか、承認やライフサイクル設定をどうするかを定義すると説明されています。(Microsoft Learn)
つまり今回の取り消し機能は、既存のガバナンスを置き換えるものではありません。むしろ、承認後の例外処理を Just-in-Time の考え方に近づける補助線です。アクセス期限やレビュー周期を待たず、承認者が「もう不要」と判断した時点でアクセスを閉じられることに価値があります。
管理者とコンプライアンス担当が見るべき実務ポイント
この機能を有効に活かすには、「使えるようになった」で終わらせず、アクセス パッケージの運用設計に落とし込む必要があります。
承認者の選び方を見直す
承認者が取り消し権限を持つ以上、承認者は単なる形式上の上長ではなく、アクセスの必要性を判断できる人物であるべきです。
たとえば、外部ベンダー向けの SharePoint サイトであれば、技術部門の管理者よりも、実際にベンダーの作業範囲を管理するプロジェクト オーナーの方が適切な場合があります。逆に、特権的な管理ロールや機密データを含むアクセス パッケージでは、業務部門だけでなく、IAM チームやセキュリティ担当を承認フローに含めるべきです。
判断基準はシンプルです。
| アクセスの種類 | 承認者に求める判断 |
|---|---|
| プロジェクト用 Teams / SharePoint | その人がプロジェクトに参加しているか |
| SaaS アプリの業務ロール | 業務上そのロールが必要か |
| セキュリティ グループ | グループ経由で何にアクセスできるか理解しているか |
| 特権ロールに近いアクセス | リスクと期限を説明できるか |
| 外部ユーザーのアクセス | 契約・作業範囲・終了条件を把握しているか |
承認者がリソースの意味を理解していないと、取り消し機能があっても使われません。特にグループ名だけでは権限範囲が分かりにくい環境では、アクセス パッケージ名と説明文を見直すことが重要です。
取り消し理由の記録ルールを決める
My Access の取り消し手順では、理由を入力して Remove を実行します。(Microsoft Learn) この理由欄は、監査対応や後続調査の手がかりになります。
おすすめは、自由記述だけに任せず、組織内で理由の型を決めることです。
| 理由カテゴリ | 記入例 |
|---|---|
| 作業完了 | Project Alpha の検証作業完了のため |
| 誤承認 | 申請対象リソースを誤認して承認したため |
| 申請内容不一致 | 申請理由と実際の利用目的が一致しないため |
| 契約・所属変更 | 契約終了、または担当チーム変更のため |
| セキュリティ対応 | インシデント調査に伴う一時停止のため |
「不要のため」だけでは、後から見たときに判断根拠が分かりません。compliance teams が監査で説明しやすいように、最低限「何が変わったのか」「なぜアクセスを残せないのか」が分かる文面にしましょう。
アクセス パッケージの粒度を細かくしすぎない
承認後に取り消せるからといって、アクセス パッケージを無制限に細分化すると、利用者にも承認者にも負担が増えます。一方で、1つのアクセス パッケージに広すぎる権限を詰め込むと、取り消し時の影響が大きくなります。
実務では、次の粒度が扱いやすいです。
| 粒度 | 向いている例 | 避けたい状態 |
|---|---|---|
| プロジェクト単位 | 一時的な共同作業、外部委託、検証環境 | 期間や担当者が頻繁に変わるのに期限がない |
| 業務ロール単位 | 経理閲覧者、ヘルプデスク担当、監査閲覧者 | ロール名が実際の権限範囲とズレている |
| アプリ単位 | 特定 SaaS の利用者、管理者、閲覧者 | 1パッケージに複数部門の権限を混在させる |
| データ分類単位 | 機密データ閲覧、個人情報処理、役員資料 | 承認者がデータ感度を判断できない |
取り消しやすさを高めるには、承認者が「このアクセスを止めてもよい」と判断できる単位で設計することが大切です。
My Access での取り消し手順
承認者が取り消しを行う流れは、次のように整理できます。
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | My Access にサインイン | 対象テナントが正しいか確認する |
| 2 | Approvals から History を開く | Pending ではなく承認履歴を見る |
| 3 | 取り消したい承認済みリクエストを選択 | 申請者、アクセス パッケージ、承認日を確認する |
| 4 | Remove を選択 | 削除対象が正しいか再確認する |
| 5 | 理由を入力して Remove を実行 | 監査で説明できる理由を書く |
Microsoft Learn では、承認者が承認済みリクエストを選び、Remove によって申請者のアクセス パッケージへのアクセスを削除すると説明されています。(Microsoft Learn)
ここで注意したいのは、「リクエスト履歴を消すこと」と「実際のアクセスを外すこと」は同じではない点です。別の管理画面で完了済みリクエストを削除しても、アクティブな割り当てが残る可能性があります。Microsoft Learn でも、アクセス パッケージの Assignments からアクティブな割り当てを確認・削除する手順が説明されています。(Microsoft Learn)
承認者による My Access の取り消しは、承認判断を戻す運用に適しています。一方、IAM 管理者が棚卸しや一括整理を行う場合は、Microsoft Entra admin center の Assignments や Requests、必要に応じて Microsoft Graph を使う運用も検討します。
どの場面で使うべきか
この機能は、日常運用のすべての削除作業を承認者に押し付けるためのものではありません。効果が出やすいのは、承認者が状況変化を最初に把握する場面です。
外部ユーザーや委託先のアクセス管理
外部ユーザーのアクセスは、プロジェクト終了、契約変更、担当者交代によって必要性が急に変わります。Entitlement Management では、外部組織のユーザーがアクセス パッケージを要求できるポリシーや、承認、有効期限、アクセス レビューを組み合わせられます。(Microsoft Learn)
承認者が過去の承認を取り消せると、外部ユーザーの不要アクセスを早く閉じやすくなります。特に「契約はまだ残っているが、この担当者の作業は終了した」というケースでは、アクセス期限を待たずに取り消せる点が有効です。
誤承認や過剰承認の是正
承認画面では、申請理由、開始日、終了日、業務上の説明などを確認できます。Microsoft Learn でも、承認者はリクエストの詳細を見て、承認または拒否の判断に使うと説明されています。(Microsoft Learn)
それでも、似た名前のアクセス パッケージを誤認したり、申請者の所属変更に気づかず承認したりすることはあります。取り消し機能があることで、誤承認を次回レビューまで放置せず、承認者自身が修正できます。
監査・内部統制での即時是正
監査で「このユーザーにこの権限は不要ではないか」と指摘された場合、IAM チームだけが削除できる設計だと、是正に時間がかかります。承認者が取り消し可能な範囲では、業務部門側が説明と是正を同時に進めやすくなります。
ただし、監査証跡を重視する場合は、取り消し前後の状態を残す運用も重要です。たとえば、アクセス パッケージ名、申請者、承認者、承認日、取り消し日、理由、関連チケット番号を記録しておくと、後続の監査対応が楽になります。
運用設計で失敗しやすいポイント
「承認者なら誰でも取り消せる」と誤解する
今回の機能では、承認を行った本人だけが取り消せると Microsoft は説明しています。承認者グループ内の別メンバーが代わりに取り消せる設計ではありません。(Microsoft Learn)
そのため、休職・退職・異動した承認者が過去に承認したアクセスをどう処理するかは、別途管理者運用で考える必要があります。IAM チームは、承認者が不在の場合のエスカレーション先を決めておきましょう。
アクセス期限やレビューの代替にしてしまう
取り消し機能は便利ですが、有効期限やアクセス レビューの代わりではありません。人が気づいたときだけ取り消す設計では、不要アクセスが残る可能性があります。
基本は次の組み合わせです。
| 制御 | 役割 |
|---|---|
| 有効期限 | 一時アクセスを自動的に終わらせる |
| 承認 | 付与前に必要性を確認する |
| アクセス レビュー | 定期的に継続要否を確認する |
| My Access での取り消し | 承認後の状況変化に即応する |
| 管理者による割り当て削除 | 例外対応、一括整理、承認者不在時の是正に使う |
Just-in-Time access governance を強めるには、これらを組み合わせる必要があります。取り消しボタンだけで最小権限が実現するわけではありません。
アクセス パッケージ名が分かりにくい
承認者が履歴から取り消すには、どのアクセス パッケージが何を意味するか分かる必要があります。
悪い例は、次のような名前です。
AP-001General AccessProject UsersSharePoint Access
これでは、取り消し対象を誤るリスクがあります。
改善例は次の通りです。
Vendor access - Project Alpha - SharePoint readFinance app - Invoice approver - 30 daysSOC analyst tools - temporary investigation accessHR confidential site - external auditor read-only
日本語環境でも、グローバル運用を想定するなら、英語名と日本語説明を併記する設計が扱いやすい場合があります。特に多国籍企業では、アクセス パッケージ名、説明、申請理由のテンプレートを英語基準で統一しておくと、監査や委託先対応で混乱が減ります。
導入後に確認したいチェックリスト
この更新を受けて、Identity governance admins と compliance teams は次の項目を確認するとよいでしょう。
| 確認項目 | 見直す理由 |
|---|---|
| 重要なアクセス パッケージの承認者が適切か | 取り消し判断をできる人に承認を任せるため |
| アクセス パッケージ名と説明が具体的か | 承認履歴から誤りなく対象を選べるようにするため |
| 取り消し理由の記入ルールがあるか | 監査証跡として使える状態にするため |
| 承認者不在時のエスカレーションがあるか | 本人しか取り消せない制約に備えるため |
| 有効期限とアクセス レビューが設定されているか | 手動取り消しに依存しすぎないため |
| 外部ユーザー向けパッケージの期限が妥当か | 契約・作業終了後の残存アクセスを減らすため |
| IAM チームと業務部門の責任分界が明確か | 取り消し依頼の滞留を防ぐため |
まず優先すべきは、特権に近いアクセス、外部ユーザー向けアクセス、機密データに関係するアクセス パッケージです。すべてのパッケージを一度に見直すより、リスクの高いものから承認者と期限設定を確認する方が現実的です。
まとめ：承認後の「閉じる力」が最小権限を強くする
My Access で過去に承認したアクセス パッケージ割り当てを取り消せるようになったことで、Microsoft Entra ID Governance は承認前の制御だけでなく、承認後の是正にも使いやすくなりました。Microsoft の説明では、承認者は過去の承認判断を取り消し、申請者のアクセスを削除できます。(Microsoft Learn)
実務での価値は、アクセスを付与するスピードではなく、不要になったアクセスを適切な責任者が早く閉じられる点にあります。Just-in-Time access governance を強化したい組織は、次の順番で対応すると効果的です。
- 重要なアクセス パッケージを洗い出す
- 承認者が本当にアクセス要否を判断できるか確認する
- 取り消し理由の記録ルールを決める
- 有効期限とアクセス レビューを見直す
- 承認者不在時の管理者対応フローを用意する
承認は入口の統制です。今回の更新で強化されたのは、承認後に不要アクセスを閉じる出口の統制です。最小権限を実務で維持するには、この「閉じる力」を運用設計に組み込むことが欠かせません。
コメント