Microsoft Entra ID Governance / Access Reviews / Entitlement Management の今回の更新で最初に押さえるべき点は、機密性の高い記録システムへのアクセス管理を、個別の申請・手作業・年次棚卸しから、アクセスパッケージと定期レビューを中心にした継続的な統制へ寄せる流れが強まっていることです。
2026年4月19日に Microsoft Tech Community で公開された記事では、電子健康記録、いわゆる EHR を例に、Microsoft Entra ID Governance を使って「誰が、どの記録システムへ、どの権限で、いつまでアクセスできるか」を管理する考え方が整理されています。医療機関向けの文脈が中心ですが、IAM チーム、コンプライアンス担当、金融・公共・製薬・研究機関などの規制業種の IT リーダーにとっても重要な示唆があります。(TECHCOMMUNITY.MICROSOFT.COM)
ポイントは、新しい単体機能の発表というより、Access Reviews と Entitlement Management を、機密記録システムの中核的なガバナンスコントロールとして位置付け直す実務メッセージとして読むことです。
今回の更新で何が重要なのか
Microsoft の記事では、EHR のような機密性の高い業務システムに対し、Microsoft Entra ID Governance を使って、プロビジョニング、Entitlement Management、Access Reviews を組み合わせる流れが示されています。EHR の例として Epic、Oracle Health、Meditech が挙げられており、複雑な臨床ロール、動的なケアチーム、細かな権限モデルを前提に、クラウド主導の ID ライフサイクル管理へ移行する考え方が説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
実務上の読み替えは、次の通りです。
| 観点 | これまで起きがちな状態 | 今回の更新で強調されている方向性 |
|---|---|---|
| 権限付与 | チケット、メール、Excel、個別グループ追加で対応 | Access Package にまとめ、承認・期限・正当化理由をポリシー化 |
| 権限の見直し | 年1回の棚卸し、監査前の突貫確認 | Access Reviews で定期・臨時レビューを運用に組み込む |
| 退職・異動対応 | HR 連携後も一部アプリ権限が残る | Joiner-Mover-Leaver とアプリプロビジョニングを連動 |
| 監査証跡 | 誰が承認したか、なぜ残したかが散在 | レビュー結果、承認理由、期限、削除結果を追跡可能にする |
| 対象システム | Microsoft 365 や一部 SaaS が中心 | EHR など業務中核・規制対象システムにも統制を広げる |
特に重要なのは、「アクセス権を付ける仕組み」だけでなく、「付けた権限が今も妥当かを確認し、不要なら外す仕組み」までを一連の統制として扱う点です。
Microsoft Entra ID Governance 利用者が最初に確認すべき変更点
今回の内容を受けて、Microsoft Entra ID Governance を利用している組織が最初に確認すべき変更点は、製品画面の新ボタンではなく、ガバナンス設計の優先順位です。
Access Reviews は監査対応用ではなく、権限維持の判断基盤になる
Access Reviews は、グループメンバーシップ、エンタープライズアプリへのアクセス、ロール割り当てを定期的に確認し、適切な人だけがアクセスを継続できるようにする機能です。Microsoft Learn でも、過剰なアクセス権は侵害リスクや監査指摘につながるため、リソース所有者が定期的にアクセスを確認する必要があると説明されています。(Microsoft Learn)
実務では、Access Reviews を「監査のために年1回実施するチェック」と捉えると効果が限定されます。機密記録システムでは、次のようなタイミングでレビューを設計すべきです。
| レビュー対象 | 推奨される見直しタイミング | 判断する人 |
|---|---|---|
| 医療記録、顧客記録、研究データなどへの高権限アクセス | 月次または四半期 | 業務オーナー、部門責任者、コンプライアンス担当 |
| 外部委託先、共同研究者、取引先アカウント | プロジェクト単位、契約更新前、四半期 | リソース所有者、委託元責任者 |
| 管理者ロール、特権グループ | 月次またはイベント発生時 | IAM 管理者、セキュリティ責任者 |
| 例外的に許可したアクセス | 期限前、監査サイクル前 | 例外承認者、リスクオーナー |
レビュー頻度を上げればよいわけではありません。Microsoft の展開計画ドキュメントでも、レビューサイクルが頻繁すぎたり、レビュアーが少なすぎたりすると、判断品質が落ちる可能性があるとされています。(Microsoft Learn)
つまり、最初に決めるべきなのは「毎月レビューするか」ではなく、どの権限を、誰が、どの根拠で、どの期限内に判断するかです。
Entitlement Management は「申請フォーム」ではなくアクセス設計の単位になる
Entitlement Management は、アクセス要求ワークフロー、アクセス割り当て、レビュー、有効期限を自動化し、ID とアクセスのライフサイクルを大規模に管理するための機能です。中心となる Access Package は、ユーザーが業務を行うために必要なリソースをひとまとめにした単位です。(Microsoft Learn)
今回の Microsoft の記事では、EHR のように数百から数千の細かな権限が存在し得るシステムに対し、臨床ロールを Access Package としてモデル化し、承認済み・期限付き・監査しやすい形にする考え方が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
これは、医療以外の業界でもそのまま使える考え方です。
| 業界・部門 | Access Package 化しやすい例 | 含めるリソースの例 |
|---|---|---|
| 医療 | 救急部門医師、外来受付、薬剤部、監査担当 | EHR アプリ、部門グループ、記録参照権限、Teams、SharePoint |
| 金融 | 法人審査担当、AML 調査担当、支店管理者 | 顧客管理アプリ、審査システム、機密資料サイト |
| 公共 | 住民情報担当、税務担当、外部委託業者 | 業務アプリ、閲覧専用ロール、委託先用グループ |
| 製薬・研究 | 臨床試験担当、研究データ管理者、外部 CRO | 研究データサイト、試験管理アプリ、期限付き外部アクセス |
失敗しやすいのは、Access Package を既存の部署名だけで作ることです。部署名は分かりやすい一方、実際のアクセス要件と一致しないことがあります。たとえば「看護部」全体に同じ権限を与えるより、「夜勤担当」「病棟担当」「一時応援」「教育担当」のように、業務とリスクが変わる単位で分けた方がレビューしやすくなります。
プロビジョニングは HR 連携だけで終わらせない
Microsoft の記事では、プロビジョニングの出発点として「信頼できるソース」を置き、HR システムだけでなく、資格情報システム、給与システム、スプレッドシート、フラットファイル、SQL テーブルなどの記録システムから Microsoft Entra ID へデータを取り込む考え方が説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Learn でも、API-driven inbound provisioning は HR アプリ、給与アプリ、スプレッドシート、SQL テーブルなどの system of record と Microsoft Entra ID の同期を支援する仕組みとして説明されています。(Microsoft Learn)
ここでの実務ポイントは、「入社したらアカウントを作る」だけでは不十分ということです。機密記録システムでは、次の属性が権限判断に直結します。
| 属性 | なぜ重要か |
|---|---|
| 所属部署 | 基本的なアクセス範囲を決める |
| 職務・ロール | 閲覧、更新、承認、管理などの操作権限を決める |
| 勤務場所・施設 | 地域・病院・支店単位のデータアクセスを制限する |
| 雇用形態 | 常勤、派遣、委託、外部ユーザーで承認経路や期限を変える |
| 資格・認定 | 医療、金融、法務、研究などで特定業務の可否を判断する |
| 契約終了日・異動日 | 自動削除、期限付きアクセス、レビュー対象化に使う |
たとえば医療機関で「医師」という属性だけを使うと、診療科、施設、当直、研修医、外部応援などの違いを表現できません。逆に属性を細かくしすぎると運用できなくなります。最初は、アクセス判断に実際に使う属性だけを最小セットで整備するのが現実的です。
影響範囲：誰が何を見直すべきか
今回の更新は、IAM チームだけの話ではありません。Access Reviews と Entitlement Management を機密記録システムに適用するには、IT、セキュリティ、業務部門、コンプライアンスが同じ設計を共有する必要があります。
| 役割 | すぐ確認すべきこと | 初動 |
|---|---|---|
| IAM チーム | Access Package、グループ、アプリ割り当てが業務ロールと一致しているか | 重要システムの権限一覧を棚卸しし、Access Package 候補を作る |
| コンプライアンス担当 | レビュー証跡、承認理由、期限、未回答時の扱いが監査要件を満たすか | 監査で説明すべき証跡項目を定義する |
| セキュリティチーム | 過剰権限、休眠アカウント、外部ユーザー、特権ロールが可視化されているか | 高リスク権限からレビュー対象を決める |
| 業務部門オーナー | 自部門のアクセス判断を誰が行うか | リソースオーナーと代理レビュアーを決める |
| 規制業種の IT リーダー | EHR や顧客記録など、最重要システムに Entra 統制を広げられるか | パイロット対象システムを1つ選ぶ |
Microsoft の Access Reviews 展開計画では、IT 管理、セキュリティ、開発、事業部門、コーポレートガバナンスなど複数のステークホルダーを巻き込むことが推奨されています。特に事業部門は、内部・外部ユーザーのアクセスを承認または否認する役割を持ち、ガバナンス部門は過去レビューの結果や記録保管を確認する役割を担います。(Microsoft Learn)
実務で最初にやるべき5つの確認
今回の更新を受けて、すでに Microsoft Entra ID Governance を利用している組織は、次の順番で確認すると無理なく進められます。
機密記録システムを1つ選んで対象を絞る
最初から全社展開を狙うと、権限体系、レビュアー、承認経路、例外処理が複雑になりすぎます。まずは、次の条件に当てはまるシステムを1つ選びます。
- 監査や規制対応で説明責任が大きい
- 個人情報、医療情報、金融情報、研究データなどを扱う
- 権限が増え続けている
- 外部委託先やゲストユーザーが関与する
- 退職・異動後の権限残存が問題になりやすい
医療機関なら EHR、金融機関なら顧客記録や審査システム、公共機関なら住民情報系システムが候補になります。
既存権限を「業務ロール」に変換する
次に、現在のグループやアプリロールをそのまま Access Package に移すのではなく、業務ロールへ変換します。
悪い例は、「EHR_Group_01」「App_Admin_A」「SharePoint_Read_All」のような技術名をそのまま申請対象にすることです。申請者にも承認者にも意味が分からず、レビュー時に「残してよいか」を判断できません。
良い例は、次のような名前です。
| Access Package 名の例 | 承認者が判断しやすい理由 |
|---|---|
| 救急外来 医師向け EHR 参照・記録更新 | 対象者、業務、権限範囲が分かる |
| 法人審査 一時支援アクセス 30日 | 期限付き業務であることが分かる |
| 外部監査人 記録参照のみ 14日 | 外部ユーザーかつ読み取り専用と分かる |
| 研究データ管理者 承認付きアクセス | 高権限で承認が必要だと分かる |
Access Package は、単なる IT リソースの束ではありません。業務側が理解できるアクセス権のカタログとして設計することが重要です。
承認、期限、正当化理由をポリシーに入れる
Entitlement Management の Access Package では、誰が要求できるか、承認が必要か、正当化理由を収集するか、割り当て期間をどうするかをポリシーで制御できます。Microsoft の記事でも、Access Package によって、承認済み、期限付き、監査しやすい形のアクセスを実現できると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
機密記録システムでは、最低限次の項目を決めておきます。
| 設定項目 | 実務上の判断基準 |
|---|---|
| 要求できるユーザー | 全社員ではなく、対象部門・対象職種・接続組織に絞る |
| 承認者 | 上長だけでなく、リソースオーナーやコンプライアンス担当を含める |
| 正当化理由 | 「業務上必要」ではなく、案件名・患者対応・監査目的などを記載させる |
| 有効期限 | 常時必要なロールと一時アクセスを分ける |
| 再レビュー | 長期アクセスは定期レビューを必須にする |
| 未回答時の扱い | 高リスク権限は原則削除、低リスク権限は手動判断など方針を決める |
特に、未回答時の扱いは事前合意が必要です。レビュアーが期限内に回答しない場合に自動削除するのか、保留するのかで業務影響が大きく変わります。
Access Reviews の自動適用は段階的に使う
Access Reviews では、レビュー結果に基づいてアクセス削除を自動適用できます。Microsoft Learn では、レビュー完了後に承認されなかったユーザーをリソースから自動的に削除する設定が説明されています。(Microsoft Learn)
ただし、機密記録システムでいきなり自動削除を有効にすると、必要な業務アクセスまで失われる可能性があります。最初のパイロットでは、次の段階を踏むと安全です。
| 段階 | 運用方法 | 目的 |
|---|---|---|
| 第1段階 | 自動適用せず、レビュー結果だけ取得 | レビュアーの判断品質と対象範囲を確認する |
| 第2段階 | 低リスク権限のみ自動削除 | 業務影響が小さい範囲で運用を検証する |
| 第3段階 | 高リスク権限も条件付きで自動削除 | 未回答・休眠・期限切れアクセスを減らす |
| 第4段階 | 定期レビューを標準運用に組み込む | 監査証跡と最小権限を継続的に維持する |
Microsoft の展開計画でも、パイロットでは自動適用をせずに結果を管理できるレビューから始めること、削除されたアクセスを記録して必要時に復旧できるようにすること、監査ログを確認することが推奨されています。(Microsoft Learn)
外部ユーザーと委託先を別枠で管理する
EHR や顧客記録システムでは、外部委託先、監査人、共同研究者、システムベンダーが関与するケースがあります。外部ユーザーは雇用終了の HR シグナルでは管理できないことが多いため、Access Package の期限、接続組織、Access Reviews を組み合わせる必要があります。
注意点は、外部ユーザーを一括で「ゲスト」として扱わないことです。監査人、保守ベンダー、共同研究者、一時支援者では、必要な権限、期間、承認者、レビュー頻度が異なります。
たとえば、保守ベンダーには短期間の特権アクセスが必要になる場合がありますが、監査人には読み取り専用で十分なことがあります。ここを同じ Access Package にすると、過剰権限や監査説明の弱さにつながります。
よくある失敗と回避策
技術グループをそのまま Access Package にしてしまう
既存の Microsoft Entra グループやアプリロールをそのまま Access Package 化すると、短期的には移行が楽です。しかし、承認者が内容を理解できず、レビュー時に「何のための権限か」が分からなくなります。
回避策は、技術グループを裏側のリソースとして扱い、Access Package 名と説明文は業務用語で書くことです。説明文には、対象業務、含まれる主な権限、想定利用期間、誤申請時のリスクを入れると判断しやすくなります。
レビュアーを IT 部門だけにしてしまう
IT 部門はグループ名やアプリ設定は分かりますが、個々のユーザーが業務上アクセスを継続すべきかまでは判断できません。Access Reviews の価値は、アクセス判断を業務オーナーに委譲できる点にあります。
Microsoft の計画ドキュメントでも、Access Reviews は継続アクセスの確認と対応の責任をビジネスオーナーへ移し、より正確なアクセス判断につなげる文化的変化として説明されています。(Microsoft Learn)
IT 部門はレビュー設計、証跡、例外処理、自動化を担い、業務部門は「この人にこの権限が今も必要か」を判断する、という役割分担にするべきです。
期限付きアクセスと恒久アクセスを混在させる
一時的な応援、監査、保守作業、プロジェクト参加の権限を恒久アクセスと同じパッケージに入れると、不要な権限が残りやすくなります。
回避策は、Access Package を「常時業務用」と「一時アクセス用」に分けることです。特に外部ユーザーや高権限ロールは、最初から有効期限を短く設定し、延長時に再承認を求める設計が向いています。
監査証跡として何を残すか決めていない
Access Reviews を実施しても、監査時に必要な説明が不足していると効果が半減します。最低限、次の情報を残せるようにします。
| 証跡項目 | 監査で説明できること |
|---|---|
| 申請者 | 誰がアクセスを求めたか |
| 承認者 | 誰がアクセスを認めたか |
| 正当化理由 | なぜ必要だったか |
| 付与された権限 | どのリソースに何ができたか |
| 有効期限 | いつまで許可されたか |
| レビュー結果 | 継続、削除、未回答の判断 |
| 削除実績 | 不要アクセスが実際に外されたか |
「レビューを実施した」だけではなく、レビュー結果に基づいて不要権限が減ったことまで示せる状態にするのが理想です。
今回の更新をどう評価すべきか
今回の Microsoft のメッセージは、医療業界に限定されたものではありません。むしろ、Microsoft Entra ID Governance を、Microsoft 365 や一般的な SaaS のアクセス管理だけでなく、EHR のような業務中核システムや機密記録システムへ広げる方向性を示しています。
Microsoft Learn でも、Microsoft Entra ID Governance は、ID とアクセスの自動化、ビジネスグループへの委譲、可視性向上を通じて「適切な人が適切なリソースへアクセスできる」状態を支援するソリューションと説明されています。(Microsoft Learn)
実務上は、次の3つの変化として捉えると分かりやすいです。
| 変化 | 意味 |
|---|---|
| 手作業の権限付与から、ポリシー化されたアクセス要求へ | Entitlement Management と Access Package が中心になる |
| 年次棚卸しから、継続的なアクセスレビューへ | Access Reviews が監査前作業ではなく運用プロセスになる |
| IT 主導の管理から、業務オーナーを含む統制へ | リソース所有者が継続アクセスを判断する |
特に規制業種では、アクセス制御は「セキュリティ対策」だけでなく、「監査で説明できる業務統制」です。誰がアクセスしてよいかを IT だけで決めるのではなく、業務責任者が判断し、その結果をシステム上で追跡できる形にすることが重要になります。
導入・見直し時の実践チェックリスト
Microsoft Entra ID Governance / Access Reviews / Entitlement Management の見直しを始める場合は、次のチェックリストを使うと初動を整理しやすくなります。
| チェック項目 | 確認内容 |
|---|---|
| 対象システム | 最初に統制対象にする機密記録システムを1つ決めたか |
| 権限一覧 | 現在のグループ、アプリロール、特権、外部ユーザーを把握したか |
| 業務ロール | 技術名ではなく、業務単位で Access Package 候補を定義したか |
| 承認経路 | 上長、リソースオーナー、コンプライアンス担当の役割を決めたか |
| 有効期限 | 一時アクセスと恒久アクセスを分けたか |
| レビュー頻度 | リスクに応じて月次、四半期、年次を使い分けたか |
| 未回答時の扱い | 自動削除、保留、エスカレーションの方針を決めたか |
| 外部ユーザー | 委託先、監査人、共同研究者を別管理できているか |
| 監査証跡 | 申請理由、承認者、レビュー結果、削除実績を追跡できるか |
| パイロット | 自動適用前に小規模な検証を行う計画があるか |
最初のゴールは、すべての権限を完璧に自動化することではありません。最重要システムの高リスク権限について、誰が承認し、いつまで有効で、いつ見直され、不要ならどう削除されるかを明確にすることです。
まとめ：まずは高リスク権限を Access Package と Access Reviews に乗せる
2026年4月19日の Microsoft の更新は、Microsoft Entra ID Governance / Access Reviews / Entitlement Management を、機密記録システムの実務的な統制基盤として活用する流れを示しています。EHR を例にしていますが、顧客記録、金融審査、住民情報、研究データなど、規制・監査・個人情報保護が重いシステムにも同じ考え方を適用できます。
次に取るべき行動は明確です。まず、最もリスクの高い記録システムを1つ選び、既存の権限を業務ロールに整理します。そのうえで、Access Package に承認、期限、正当化理由を組み込み、Access Reviews で継続アクセスを定期的に確認します。
最初から大規模展開を狙うより、高リスク権限を小さく選び、レビュー結果を監査証跡として残し、不要アクセスを実際に削除することが重要です。これにより、Microsoft Entra ID Governance は単なる ID 管理ツールではなく、規制業種に求められるアクセス統制の実行基盤として機能し始めます。
コメント