Microsoft Entraの「Account Discovery for Application Access Governance」は、接続済みアプリケーション内に残っているローカルアカウントや孤立アカウントを見つけ、Microsoft Entra IDユーザーと照合できるかを可視化する機能です。結論から言うと、管理者が最初に行うべきことは、重要度の高い業務アプリから順に検出レポートを作成し、「放置されたアカウント」「Entra ID上のユーザーと一致するが未割り当てのアカウント」「すでに管理下にあるアカウント」を仕分けることです。
公式ロードマップでは、この機能は「Launched」とされ、一般提供時期はJune CY2026、対象はMicrosoft Entra、Web、Worldwide Standard Multi-TenantおよびGCCと示されています。プレビューはApril CY2026として掲載されています。(Microsoft) Microsoft Entraのリリース情報でも、Account DiscoveryはMicrosoft Entra ID Governanceで一般提供され、接続済みアプリ内の孤立アカウントを含む全アカウントの可視化に役立つ機能として説明されています。(Microsoft Learn)
Microsoft Entra Account Discoveryで何が変わるのか
従来、Microsoft Entra IDでアプリのSSOやプロビジョニングを構成していても、アプリ側に以前から存在するローカルアカウントや、退職者の残存アカウント、別経路で作成されたアカウントまでは見落とされがちでした。
Account Discoveryは、この「Microsoft Entra ID Governanceの外側にあるアクセス」を見つけ、アプリケーションアクセスガバナンスの対象に取り込むための入口になります。公式説明では、接続済みアプリに誰がアクセスできるかを可視化し、ローカルアカウントや孤立アカウントを発見し、Microsoft Entra IDユーザーと一致できるアカウントを識別するとされています。(Microsoft)
| 観点 | 変更点 | 実務上の意味 |
|---|---|---|
| 可視化 | 接続済みアプリ内の既存アカウントを検出できる | アプリ側に残った退職者・共有アカウント・手動作成アカウントを棚卸ししやすくなる |
| 分類 | ローカルアカウント、未割り当てユーザー、割り当て済みユーザーに分類 | 削除、紐付け、アクセスパッケージ化などの判断を分けられる |
| ガバナンス連携 | 検出後、アクセスパッケージ、アクセスレビュー、ライフサイクルワークフローと連携可能 | 一度きりの棚卸しではなく、継続的なアクセス管理に移行しやすい |
| 対象環境 | Roadmap上はWorldwide Standard Multi-TenantとGCC、Web、Microsoft Entraが対象 | GCC HighやDoDまで自動的に対象とみなさず、自社テナントでの表示を確認する |
| 提供状態 | Launched、一般提供はJune CY2026 | プレビュー検証済みの組織は、本番運用ルールへの組み込みを検討する段階 |
重要なのは、Account Discoveryが「自動的に不要アカウントを削除する機能」ではない点です。あくまで検出・分類・判断材料の提供が中心です。検出後に誰をアプリへ割り当てるか、誰をアクセスパッケージで管理するか、どのローカルアカウントを削除または例外管理するかは、管理者とアプリ所有者が決める必要があります。
検出結果は3種類に分類される
Microsoft Learnでは、Account Discoveryがターゲットアプリケーションからユーザーアカウントを取得し、3つのカテゴリに分類すると説明されています。(Microsoft Learn) この分類を理解しておくと、検出レポートを見た後の対応がぶれません。
| 分類 | 意味 | 優先して確認すべきポイント | 代表的な対応 |
|---|---|---|---|
| Local accounts | アプリ側には存在するが、Microsoft Entra IDに一致するユーザーがないアカウント | 退職者、共有アカウント、サービス用アカウント、別経路で作成されたユーザー、属性不一致 | 削除、無効化、既存ユーザーへの正しい紐付け、例外管理 |
| Unassigned users | Microsoft Entra IDユーザーとは一致するが、エンタープライズアプリに割り当てられていないアカウント | 本来Entra ID Governanceで管理すべき利用者か | アプリのユーザーとグループへ割り当て、またはアクセスパッケージへ移行 |
| Assigned users | Microsoft Entra IDユーザーと一致し、すでにアプリに割り当てられているアカウント | 属性マッピングやロールが適切か | 原則対応不要。ただし権限や属性同期の見直し対象にはなる |
Local accountsには、退職者のアカウント、アプリ内で直接作成されたサービスアカウントや共有アカウント、Microsoft Entra ID以外のプロセスで作られたユーザー、属性の品質問題で一致しなかったユーザーなどが含まれ得ます。Microsoft Learnでも、これらを削除するか、既存のMicrosoft Entra IDユーザーに一致させるか、現状維持するかを確認するよう説明されています。(Microsoft Learn)
一方、Unassigned usersは「一致するMicrosoft Entra IDユーザーはいるが、エンタープライズアプリに割り当てられていない」状態です。この場合は、エンタープライズアプリの「Users and groups」で適切なユーザーまたはグループを割り当てることで、以後のプロビジョニングサイクルで管理対象にできます。(Microsoft Learn)
影響範囲：管理者・開発者・アプリ所有者が見るべきポイント
Microsoft Entra管理者への影響
管理者にとって最大の影響は、アプリ側に残っていた「見えていないアクセス」を棚卸しできるようになることです。特に次のような環境では、早めに検証する価値があります。
- 退職者や異動者のアプリ権限が残りやすい
- SaaS管理者がアプリ側で直接ユーザーを作成している
- 以前から使っているアプリを後からMicrosoft Entra IDに接続した
- アプリごとのアクセスレビューを監査対応で求められている
- SCIMプロビジョニングを使っているが、既存ユーザーの初期棚卸しが不十分
Microsoft Entra ID Governanceは、適切なユーザーが適切なリソースへ適切なタイミングでアクセスできるようにするための可視性とプロセスを提供するものです。アプリケーションアクセスガバナンスでは、アクセス設定、ユーザープロビジョニング、アクセスチェック、監査・リスク管理目的のレポート作成が重要になります。(Microsoft Learn)
開発者・SaaS連携担当者への影響
開発者やSaaS連携担当者は、SCIM APIやコネクタの挙動を確認する必要があります。Microsoft Learnでは、SCIMベースのコネクタでAccount Discoveryを利用するには、対象アプリケーションがRFC 7644 Section 3.4.2.4のページネーションをサポートしている必要があると説明されています。(Microsoft Learn)
実装・連携で特に見落としやすいのは、次の3点です。
| 確認項目 | 注意点 |
|---|---|
| ページネーション | 大量ユーザーを全件取得できないと、検出レポートが不完全になる可能性がある |
| マッチング属性 | Account Discoveryは直接マッピングされた最初の一致属性を使う。式ベースの変換はマッチングに使えない |
| 属性品質 | メールアドレス、userName、externalIdなどの値が古い・重複していると、Local accountsとして誤判定される可能性がある |
特に独自アプリやSCIM対応を内製している場合は、「通常のプロビジョニングは動くが、全ユーザー列挙は不安定」という状態になりがちです。Account Discoveryを正しく使うには、個別ユーザーの作成・更新だけでなく、一覧取得とページングが安定していることを確認しましょう。
アプリ所有者・業務部門への影響
アプリ所有者は、検出されたアカウントの扱いを判断する役割を持ちます。IT部門だけで「Local accountsだから削除」と判断すると、バッチ連携用アカウントや監査用アカウント、外部委託先が使う業務アカウントを止めてしまうリスクがあります。
アプリ所有者には、少なくとも次の確認を依頼します。
| 確認する内容 | 判断基準 |
|---|---|
| そのアカウントは現在も業務で必要か | 最終利用日、担当部署、業務プロセス、代替手段で判断 |
| 人に紐づくアカウントか | 個人利用ならMicrosoft Entra IDユーザーへ紐付ける |
| 共有・サービス用途か | 所有者、用途、有効期限、認証情報の管理責任者を明確にする |
| 権限が過剰ではないか | 管理者権限、エクスポート権限、個人情報閲覧権限を優先確認 |
| 今後もアプリ側で直接作成してよいか | 原則はEntra ID Governance経由に寄せ、例外は申請制にする |
利用前に確認すべき前提条件
Account Discoveryを使うには、ライセンス、権限、プロビジョニング設定、マッチング属性がそろっている必要があります。Microsoft Learnでは、Microsoft Entra ID GovernanceアドオンまたはMicrosoft Entra Suite、プロビジョニング構成済みのエンタープライズアプリ、有効な資格情報と成功した接続テスト、直接マッチング属性、Application Administratorなどのロールが前提条件として示されています。(Microsoft Learn)
| 項目 | 確認内容 | 不備がある場合の影響 |
|---|---|---|
| ライセンス | Microsoft Entra ID Governanceアドオン、またはMicrosoft Entra Suiteがあるか | 機能を利用できない |
| 対象アプリ | エンタープライズアプリでプロビジョニングが構成されているか | Discover identitiesを実行できない、または結果が得られない |
| 接続情報 | プロビジョニング資格情報が有効で、テスト接続が成功するか | アプリ側アカウントを取得できない |
| マッチング属性 | Microsoft Entra IDと対象アプリ間で直接の一致属性が設定されているか | ユーザー照合が正しくできない |
| 管理者ロール | Application Administrator、Cloud Application Administrator、Hybrid Identity Administratorのいずれかを持つか | 操作権限が不足する |
| SCIM対応 | 対象アプリがユーザー一覧取得とページネーションをサポートするか | 検出結果が0件、または不完全になる可能性がある |
ライセンスについては、Microsoft Entra ID Governanceのライセンス基礎ページでも、Account DiscoveryにはMicrosoft Entra ID GovernanceアドオンまたはMicrosoft Entra Suiteが必要であり、ターゲットアプリの既存ユーザーアカウントを検出し、Entraアカウントと一致するユーザーや孤立アカウントを識別する機能だと説明されています。(Microsoft Learn)
対象コネクタと非対応コネクタを確認する
Account Discoveryは、すべてのアプリで同じ精度の結果が得られるわけではありません。Microsoft Learnでは、Atlassian Cloud、SCIM、Salesforce、SAP Cloud Identity Services、ECMA、GitHub Enterprise Cloudが「確立された検出動作」を持つコネクタとして挙げられています。一方で、HR provisioning、ServiceNow、AWS、Snowflakeは現在サポートされないアプリケーションとして示されています。(Microsoft Learn)
| 種別 | 公式ドキュメント上の扱い | 実務での見方 |
|---|---|---|
| Atlassian Cloud、Salesforce、SAP Cloud Identity Servicesなど | 完全な検出結果を一貫して受け取れるコネクタとして掲載 | 優先的にパイロット対象にしやすい |
| SCIM汎用コネクタ | 対象アプリのSCIM実装に依存 | ページネーション、全件取得、属性値の安定性を検証する |
| ECMA | SQL、LDAP、Web Services、PowerShellコネクタ経由でオンプレミスアプリを支援 | レガシーアプリ棚卸しに有用。ただし設計・テストは慎重に行う |
| HR provisioning、ServiceNow、AWS、Snowflake | 現時点でAccount Discovery非対応として掲載 | 代替の棚卸し方法やアプリ側レポートを併用する |
検出レポートが0件になる場合は、単に「対象アプリにユーザーがいない」と判断しないでください。公式ドキュメントでは、単一の直接マッチング属性が設定されているか、式が使われていないかを確認し、さらにベンダーにSCIM標準のページネーション対応を確認するよう案内されています。(Microsoft Learn)
管理者が実行すべき展開手順
まずは重要アプリを3〜5個に絞る
最初から全アプリに広げるより、リスクが高く、効果が見えやすいアプリから始めます。優先度が高いのは次のようなアプリです。
- 個人情報、財務情報、顧客情報を扱う
- 管理者権限を持つユーザーが多い
- 退職者や外部委託先の利用が多い
- アプリ側で手動ユーザー作成が行われてきた
- 監査でアクセスレビューの証跡が求められる
- Microsoft Entra IDへの統合前から長く使われている
この段階では、アプリの数を増やすよりも、検出結果をどう処理するかの運用ルールを固めることが重要です。
プロビジョニング設定とマッチング属性を確認する
対象アプリを決めたら、Microsoft Entra admin centerでエンタープライズアプリを開き、Provisioning設定を確認します。公式手順では、Microsoft Entra admin centerにApplication Administrator以上でサインインし、Identity > Applications > Enterprise applicationsから対象アプリを選択し、Provisioningで資格情報とテスト接続を確認したうえでDiscover identitiesを選択します。(Microsoft Learn)
特に確認すべき設定は次の通りです。
| 設定 | 推奨される確認 |
|---|---|
| Provisioning Status | 既存のプロビジョニングが意図通り構成されているか |
| Admin Credentials | 接続テストが成功するか |
| Attribute mappings | Microsoft Entra IDとアプリ側で直接比較できる属性があるか |
| Matching precedence | 複数の一致属性がある場合、最初の属性が妥当か |
| Scope | すべての対象ユーザーを検出できるスコープになっているか |
式ベースの変換はAccount Discoveryのマッチングには使えません。複数の一致属性が構成されている場合も、使われるのは最初の一致属性です。(Microsoft Learn) そのため、メールアドレスの変更が多い組織や、外部ユーザーの命名規則が複雑な組織では、検出前に属性品質を確認しておく必要があります。
Discover identitiesを実行し、完了時間を見込む
Discover identitiesを実行すると、プロビジョニングサービスが対象アプリケーションからユーザーアカウントを取得し、カテゴリ別に表示します。Microsoft Learnでは、検出レポートの生成には少なくとも30分かかり、対象アプリに含まれるアカウント数が多いほど時間が長くなり、25万アカウントのアプリでは12時間以上かかる場合があると説明されています。(Microsoft Learn)
大規模アプリでは、以下を事前に決めておくと混乱を防げます。
| 準備項目 | 理由 |
|---|---|
| 実行タイミング | 大量取得でアプリ側API制限に影響する可能性を考慮する |
| アプリ所有者への連絡 | 検出後の判断に業務知識が必要になる |
| 結果確認担当 | Local accounts、Unassigned users、Assigned usersで担当を分ける |
| 判断期限 | 棚卸しだけで終わらせず、削除・紐付け・例外化まで進める |
| 証跡保存 | 監査や後続レビューに備えてCSVやチケットに残す |
検出後の対応：削除・紐付け・ガバナンス化を分けて考える
検出結果を見た後は、すべてを一律に処理しないことが大切です。特にLocal accountsは、不要アカウントだけでなく、サービスアカウント、共有アカウント、属性不一致の正規ユーザーも含み得ます。
| 検出結果 | ありがちな失敗 | 推奨対応 |
|---|---|---|
| 退職者らしきLocal account | アプリ所有者に確認せず即削除する | 最終ログイン、データ所有、業務影響を確認して無効化または削除 |
| 共有アカウント | 個人ユーザーに無理に紐付ける | 所有者、用途、有効期限、認証情報管理方法を記録して例外管理 |
| 属性不一致の正規ユーザー | 孤立アカウントと誤認する | メール、userName、externalIdなどを修正して再検出 |
| Unassigned user | 全員を一括でアプリに割り当てる | 部署・職務・必要権限で分け、グループまたはアクセスパッケージで管理 |
| Assigned user | 管理下だから確認不要とする | 管理者権限や高リスクロールだけはアクセスレビュー対象にする |
検出後は、既存ユーザーをエンタープライズアプリやアクセスパッケージへ割り当てることもできます。Microsoft Learnでは、検出後にPowerShell 7.xでスクリプトを実行し、相関済みユーザーをアプリやアクセスパッケージに割り当てる方法が説明されています。-DryRunで変更前に結果を確認でき、-OutputFileで監査用CSVを出力できます。(Microsoft Learn)
本番で一括割り当てを行う前に、必ずドライランを実行してください。特にアクセスパッケージへ割り当てる場合は、部門、雇用形態、利用目的、ロールに応じてルールを分けるべきです。「一致したから全員同じ権限」は、ガバナンス強化ではなく権限の平準化によるリスク拡大になりかねません。
アクセスパッケージ・アクセスレビュー・ライフサイクルワークフローに接続する
Account Discoveryの価値は、検出レポートを作って終わりではありません。見つけた既存アクセスをMicrosoft Entra ID Governanceの運用に乗せることで、継続的な管理に変えられます。
Microsoft Learnでは、検出後に既存ユーザーをアクセスパッケージへ割り当て、アクセスレビューでアクセスを認証し、ライフサイクルワークフローでライフサイクル管理を自動化できると説明されています。また、Entitlement managementで誰がアプリへのアクセスを要求できるかを管理し、ユーザーライフサイクルイベントに基づくプロビジョニング・デプロビジョニングを自動化できます。(Microsoft Learn)
実務では、次の流れが現実的です。
| フェーズ | 実施内容 | 成果物 |
|---|---|---|
| 検出 | Discover identitiesで既存アカウントを棚卸し | 検出レポート |
| 分類 | Local、Unassigned、Assignedを確認 | 対応方針リスト |
| 是正 | 不要アカウントの削除、属性修正、アプリ割り当て | チケット、変更履歴 |
| ガバナンス化 | アクセスパッケージ、承認、期限、レビューを設定 | アクセス管理ポリシー |
| 継続監視 | 定期的に再検出・アクセスレビュー | 監査証跡、改善ログ |
この流れにすると、Microsoft Entra Account Discoveryは単なる棚卸し機能ではなく、「アプリ導入時の初期統制」と「既存アプリの権限是正」をつなぐ仕組みになります。
移行・展開時に失敗しやすいポイント
マッチング属性を安易に決めない
メールアドレスだけで一致させると、改姓、ドメイン変更、外部ユーザー、過去の移行データでズレが出ることがあります。属性が古いだけの正規ユーザーをLocal accountと判断して削除してしまうと、業務影響が出ます。
最初のパイロットでは、検出結果のうちLocal accountsを数十件サンプリングし、本当にMicrosoft Entra IDに対応ユーザーがいないのか確認しましょう。属性品質の問題が多い場合は、削除作業より先にマッピングとデータ修正を行うべきです。
「検出できたアカウント」をそのまま承認しない
Unassigned usersは、Microsoft Entra IDユーザーと一致しているため、つい全員をアプリに割り当てたくなります。しかし、すでにアプリを使っていた事実と、今後も業務上必要であることは別です。
アクセスパッケージに移行する場合は、次の条件を入れると統制しやすくなります。
- 申請理由を必須にする
- 承認者をアプリ所有者または部門管理者にする
- 有効期限を設定する
- 高権限ロールは別パッケージにする
- 四半期または半期ごとにアクセスレビューを行う
サービスアカウントを人間ユーザーとして扱わない
アプリ内のサービスアカウントや共有アカウントを、無理に個人ユーザーへ紐付けると責任追跡が曖昧になります。人間が使うアカウントなのか、システムが使うアカウントなのかを分けて管理してください。
サービスアカウントを残す場合は、最低限次の情報を台帳化します。
| 項目 | 記録内容 |
|---|---|
| 所有者 | 部門名、責任者、代替責任者 |
| 用途 | バッチ、API連携、監査、移行作業など |
| 権限 | 管理者権限の有無、参照・更新・削除権限 |
| 認証情報管理 | 保管場所、ローテーション周期、緊急停止方法 |
| 有効期限 | 常設か、プロジェクト終了時に削除するか |
| レビュー周期 | 月次、四半期、半期など |
大規模アプリでは処理時間とAPI制限を見込む
Account Discoveryは、対象アプリから全ユーザーアカウントを取得します。大量のユーザーを持つアプリでは、検出レポート生成に長時間かかる可能性があります。公式ドキュメントでも、25万アカウント規模では12時間以上かかる例が示されています。(Microsoft Learn)
大規模アプリでは、業務ピーク時間を避け、アプリベンダーのAPI制限や監査ログの増加も確認しておくと安全です。
非対応コネクタを無理に対象にしない
ServiceNow、AWS、Snowflakeなど、公式ドキュメントで現在非対応とされているアプリでは、Account Discovery以外の方法で棚卸しを行う必要があります。(Microsoft Learn) アプリ側のユーザーエクスポート、SIEMログ、アクセスレビュー、手動照合などを併用しましょう。
管理者向けチェックリスト
| チェック項目 | OKの状態 | NG例 |
|---|---|---|
| 対象アプリを選定したか | 重要度、データ感度、監査要件で優先順位がある | すべてのアプリを同時に始める |
| ライセンスを確認したか | Microsoft Entra ID GovernanceまたはMicrosoft Entra Suiteがある | P1/P2だけで使えると思い込む |
| 権限を確認したか | 必要な管理者ロールで操作する | Global Administratorを常用する |
| プロビジョニング接続を確認したか | 資格情報とテスト接続が成功している | 古いシークレットのまま実行する |
| 直接マッチング属性を確認したか | 一致に使う属性が安定している | 式変換や変更されやすい属性に依存する |
| 検出結果の判断基準を用意したか | 削除、紐付け、例外管理の基準がある | Local accountを一律削除する |
| アプリ所有者を巻き込んだか | 業務判断できる担当者がいる | ITだけで業務アカウントを判断する |
| ドライランを実施したか | 一括割り当て前に影響範囲を確認する | PowerShellで即時本番反映する |
| 証跡を残すか | CSV、チケット、監査ログに残す | 口頭判断で処理する |
| 継続運用に組み込むか | アクセスレビューやアクセスパッケージへ接続する | 一度だけ棚卸しして終わる |
次に取るべき対応
Microsoft Entra Account Discovery for Application Access Governanceは、Microsoft Entra ID Governanceの外側に残っていたアプリ権限を見つけるための実用的な更新です。特に、長年使っているSaaS、手動でユーザー追加してきた業務アプリ、退職者アカウントが残りやすいアプリでは、早めに検証する価値があります。
まずは、重要度の高いアプリを3〜5個選び、プロビジョニング接続、直接マッチング属性、対象コネクタの対応状況を確認してください。そのうえでDiscover identitiesを実行し、Local accounts、Unassigned users、Assigned usersを分類します。不要アカウントは削除または無効化し、正規ユーザーはエンタープライズアプリやアクセスパッケージに取り込み、継続的なアクセスレビューへつなげることが重要です。
この機能を「検出レポート」だけで終わらせず、アプリ所有者の承認、アクセスパッケージ、ライフサイクルワークフロー、監査証跡まで含めて設計すれば、Microsoft Entra ID Governanceによるアプリケーションアクセスガバナンスを一段強化できます。
コメント