Active Directory依存を減らす4つの優先領域｜Microsoft Entra ID移行の進め方

Active Directory（AD）を今すぐ全面廃止する必要はありません。優先すべきなのは、ADをすべての認証・アクセス制御・権限管理の前提にしている状態をほどき、Microsoft Entra IDへ段階的に重心を移すことです。

Microsoftは、認証の近代化、クラウドでのアクセス判断、IDガバナンスの拡張、アプリ・端末・基盤の依存削減という4つの領域を、AD依存を減らすための実務的な出発点として示しています。これは「ADを一晩で置き換える」という提案ではなく、必要なAD環境は残しながら、新しいシステムやアクセス制御をクラウド中心へ切り替えていく考え方です。(TECHCOMMUNITY.MICROSOFT.COM)

この記事では、Active Directory依存が問題になり始めている兆候、4つの優先領域、移行対象の決め方、最初の90日で進める手順を具体的に解説します。

Active Directory依存を減らすとは何か

AD依存を減らすことは、ドメインコントローラーを直ちに停止することではありません。

目標は、次のような重要処理がADや社内ネットワークに集中している状態を見直すことです。

• クラウドサービスへサインインするたびにオンプレミス認証基盤が必要
• 社外から利用するにはVPN接続が必須
• アクセス可否をADグループと接続元IPアドレスだけで判断
• 入退社や異動時の権限変更を管理者が手作業で実施
• 新しいアプリにもLDAP、Kerberos、NTLMを採用
• Windows端末の管理をドメイン参加とグループポリシーだけに依存

Active Directory Domain ServicesとMicrosoft Entra IDは、役割が異なります。AD DSは、ドメイン参加、グループポリシー、LDAP、Kerberos、NTLMなど、主にオンプレミス環境の認証と端末管理を担います。一方、Microsoft Entra IDは、クラウドアプリへの認証、モダン認証、条件付きアクセス、クラウド上のIDガバナンスを担います。したがって、単純なサーバー置換ではなく、機能単位で移行先を決める必要があります。(Microsoft Learn)

観点	AD中心の構成	Entra ID中心の構成
ユーザー認証	Kerberos、NTLM、LDAP、オンプレミスフェデレーション	OAuth 2.0、OpenID Connect、SAML、クラウド認証
アクセス判断	ドメイン所属、ADグループ、社内ネットワーク	ユーザー、端末、アプリ、リスク、セッションなどのシグナル
Windows端末	AD参加、グループポリシー	Microsoft Entra参加、Microsoft Intune
外部ユーザー	社内用ADアカウントを個別発行	外部ユーザー自身のIDを利用し、期限付きでアクセス付与
クラウドワークロード	ADサービスアカウント、固定パスワード	マネージドID、サービスプリンシパル、証明書
権限管理	ADグループへの手動追加・削除	申請、承認、期限、アクセスレビューの自動化

ADが残っていても、クラウドアプリの認証、アクセス判断、端末管理、外部ユーザー管理をEntra IDへ移せば、AD障害や社内ネットワーク障害の影響範囲を小さくできます。

Active Directory依存が足かせになっている5つの兆候

Microsoftは、クラウド利用やAI活用が進む組織において、従来のADだけでは対応しにくくなっている兆候を挙げています。特に、次の状態が複数当てはまる場合は、AD依存の棚卸しを始める段階です。(TECHCOMMUNITY.MICROSOFT.COM)

兆候	現場で起こりやすいこと	最初に確認する対象
保守作業が増え続けている	ドメインコントローラー、AD FS、証明書、バックアップ、同期サーバーの保守に追われる	認証経路、AD FS、Microsoft Entra Connect、同期方式
場所が信頼の基準になっている	社内IPアドレスやVPN接続だけでアクセスを許可している	VPN、NPS、プロキシ、接続元IPを使うポリシー
業務の中心がクラウドアプリに移っている	Microsoft 365やSaaSを使う一方、認証だけが社内設備に残る	SaaS、業務Webアプリ、フェデレーション設定
従業員以外のIDが増えている	委託先、取引先、期間雇用者、サービスアカウントの棚卸しが追いつかない	ゲスト、共有アカウント、サービスプリンシパル
AIや自動処理を導入し始めている	AIエージェントや自動化ツールに広すぎる権限を与えてしまう	非人間ID、API権限、固定シークレット、所有者

一つだけ当てはまるからといって、ADが直ちに問題になるわけではありません。重要なのは、AD障害が起きたときにどこまで業務が止まるか、ADを変更しなければ新しいサービスを導入できない状態になっていないかを確認することです。

優先領域1：認証をMicrosoft Entra ID中心へ近代化する

最初の優先領域は、ユーザーがどこで認証されるかを見直すことです。

特にAD FSなどのオンプレミスフェデレーションを経由してクラウドサービスへサインインしている場合、サーバー、証明書、ロードバランサー、DNS、ネットワーク、ドメインコントローラーのいずれかに障害が発生すると、クラウドサービスまで利用できなくなる可能性があります。

Microsoftは、要件が許す場合、Microsoft Entra Password Hash Synchronization（PHS）を、依存関係が少なく回復性の高いハイブリッド認証方式として説明しています。PHSは同期時にはADを使用しますが、クラウドへの認証処理そのものはオンプレミス環境に依存しません。一方、Pass-through Authentication（PTA）は、サインイン時にオンプレミスのエージェントとドメインコントローラーが必要です。(Microsoft Learn)

認証方式の棚卸しで確認する項目

アプリ名だけを一覧化しても、AD依存は判断できません。少なくとも次の項目を記録します。

確認項目	記録する内容
認証先	Entra ID、AD FS、AD DS、アプリ内ローカルアカウント
認証プロトコル	OpenID Connect、OAuth、SAML、LDAP、Kerberos、NTLMなど
多要素認証	適用済み、対象外、アプリ側MFA、未対応
AD停止時の動作	利用可能、既存セッションのみ可能、全面停止、不明
所有者	業務部門、システム管理者、ベンダー
移行候補	直接Entra ID連携、Application Proxy、改修、廃止
ロールバック方法	旧認証への切り戻し手順、設定バックアップ

「ADを使用しているか」ではなく、ADが停止したときに新規サインインできるかまで確認するのがポイントです。

認証近代化の進め方

クラウドアプリとモダン認証対応アプリを先に移す

SAMLやOpenID Connectに対応しているアプリは、Microsoft Entra IDへ直接接続しやすい対象です。Microsoftも、アプリ移行ではモダン認証プロトコルを利用するアプリから着手し、従来のプロトコルを使うアプリにはApplication Proxyなどを検討する方法を案内しています。(Microsoft Learn)

移行しやすい対象には、次のようなものがあります。

• SaaSアプリ
• ブラウザーで利用する業務システム
• AD FSでSAML認証しているアプリ
• 新規開発中で認証方式を変更できるアプリ
• 利用者が限定され、切り戻しやすい社内システム

管理者からフィッシング耐性のある認証を導入する

MFAを有効にするだけでなく、管理者や機密情報を扱う利用者には、Windows Hello for Business、パスキー、FIDO2セキュリティキー、証明書ベース認証などを段階的に導入します。Microsoftは、これらをフィッシング耐性のある認証方式として推奨しています。(Microsoft Learn)

全社員へ一斉展開するのが難しい場合は、次の順序が現実的です。

1. 緊急アクセス用アカウントを整備する
2. グローバル管理者など高権限アカウントへ導入する
3. 経理、人事、法務など高機密部門へ拡大する
4. 新入職者の標準方式にする
5. 既存利用者を部門単位で移行する

レガシー認証を利用しているアプリを特定する

フィッシング耐性のある認証を導入しても、古い認証フローが残っていれば、攻撃者に別の入口を与えることになります。

ただし、利用状況を確認せずにレガシー認証を一括で遮断すると、複合機、監視装置、古いメールソフト、バッチ処理などが停止する可能性があります。サインインログと利用部門を確認し、例外には所有者と廃止期限を設定してから段階的にブロックします。(Microsoft Learn)

優先領域2：アクセス可否をクラウド側で判断する

従来の構成では、「社内ネットワークから接続している」「ドメイン参加端末である」といった条件が、信頼の主な根拠になりがちです。

しかし、クラウドアプリ、テレワーク、BYOD、外部ユーザーが増えると、場所だけでは安全性を判断できません。Microsoft Entra Conditional Accessでは、ユーザー、端末、アプリ、ネットワーク、サインインリスクなどを組み合わせて、許可、拒否、追加認証などを判断できます。AIエージェントを対象としたアクセス制御でも、ユーザーやエージェントのコンテキスト、端末、場所、セッションリスクなどの利用が進められています。(Microsoft Learn)

場所を捨てるのではなく、判断材料の一つにする

社内IPアドレスや拠点情報が不要になるわけではありません。ただし、「社内からなら無条件で許可する」という設計は避けます。

例えば、次のように複数の条件を組み合わせます。

利用場面	アクセス判断の例
一般的なクラウドアプリ	MFAを要求し、既知のリスクがあるサインインを制限
経理・人事システム	準拠済み端末または管理対象端末を要求
管理ポータル	フィッシング耐性のあるMFAと管理端末を要求
外部ユーザー	MFA、利用可能なアプリ、セッション時間を制限
高リスクサインイン	追加認証、パスワード変更、またはアクセス拒否
レガシー認証	利用実態を確認したうえで遮断

これにより、社外からでも安全な端末と強い認証を使えば業務を続けられ、反対に社内ネットワークからでも危険なサインインは拒否できます。

条件付きアクセスはレポート専用モードから始める

条件付きアクセスの失敗で多いのが、全ユーザーを対象にした強いポリシーを、影響確認なしで有効化することです。

次の順序で展開します。

1. 緊急アクセス用アカウントを用意する
2. 対象アプリと利用者を限定する
3. レポート専用モードで影響を確認する
4. サインインログから遮断対象を調べる
5. 小規模なパイロットグループで有効化する
6. 部門単位で対象を広げる
7. 例外に所有者と終了日を設定する

Microsoftも、ポリシーの誤設定による管理者ロックアウトを防ぐため、緊急アクセス用アカウントの除外と、レポート専用モードでの事前確認を推奨しています。(Microsoft Learn)

優先領域3：IDガバナンスを従業員以外にも広げる

ADグループへの追加と削除だけでは、委託先、取引先、ゲスト、特権管理者、サービスアカウント、AIエージェントまで一貫して管理することは困難です。

Microsoft Entra ID Governanceでは、アクセス申請、承認、期限、定期レビュー、ライフサイクル処理などを組み合わせて、必要な人やIDへ必要な期間だけ権限を付与できます。Entitlement Managementでは、アクセス要求、割り当て、レビュー、期限切れを含むライフサイクルを自動化できます。(Microsoft Learn)

IDの種類ごとに管理方法を分ける

IDの種類	優先して実施すること
正規職員・従業員	入社、異動、退職と権限変更を連動させる
委託先・期間雇用者	契約終了日を設定し、自動失効させる
取引先・ゲスト	自身の所属組織のIDを利用し、定期レビューを行う
特権管理者	常時付与を減らし、必要時だけ有効化する
サービスアカウント	所有者、用途、資格情報、最終利用日を記録する
サービスプリンシパル	API権限と同意内容を定期的に確認する
AIエージェント	代理実行の範囲、参照データ、実行可能な操作を限定する

特に外部ユーザーは、プロジェクト終了後もアクセスが残りやすい対象です。アクセスレビューを定期実行し、グループやアプリの所有者に継続利用の必要性を確認させる仕組みが有効です。Microsoft Entraのアクセスレビューでは、週次、月次、四半期、年次などの周期を設定し、不要と判断されたアクセスの削除を自動化できます。(Microsoft Learn)

権限付与より先に「所有者」を決める

IDガバナンスが機能しない最大の原因は、誰がアクセスの必要性を判断するのか決まっていないことです。

次の責任者を明確にします。

• アプリの業務上の所有者
• アクセスを承認する部門責任者
• ゲストの契約期間を把握する担当者
• サービスアカウントを使用するシステムの管理者
• 定期レビューで未回答だった場合の最終判断者
• AIエージェントの操作範囲とデータ利用に責任を持つ担当者

「情報システム部門がすべて判断する」運用では、業務上必要なアクセスかどうかを正しく判断できません。承認判断は業務部門へ委任し、情報システム部門は仕組みと監査を担当する形が現実的です。

優先領域4：アプリ・端末・基盤のAD依存を順番に減らす

認証だけをEntra IDへ移しても、アプリがLDAPを使い、端末がドメイン参加を要求し、サービスがADアカウントで実行されていれば、ADは停止できません。

最後の優先領域では、ADに依存する技術要素を分類し、代替手段があるものから順番に減らします。

対象	代表的なAD依存	移行先・対応例	注意点
SaaS・Webアプリ	AD FS、LDAP、ADグループ	Entra IDとのSAML／OpenID Connect連携	クレーム、ロール、ユーザー割り当てを確認
オンプレミスWebアプリ	Kerberos、Windows統合認証	Application Proxyなどを経由して公開	バックエンドのAD依存は残る場合がある
Windows端末	AD参加、GPO、コンピューターアカウント	Microsoft Entra参加、Intune	GPOをそのまま複製せず、必要な設定を選別
ファイル共有	Kerberos、ADグループ	クラウドストレージへの移行、権限再設計	パス固定の業務アプリや大量データに注意
印刷	プリントサーバー、端末GPO	Universal Printなど	複合機の対応状況と印刷要件を確認
Wi-Fi・VPN	NPS、RADIUS、端末証明書	証明書配布、クラウド管理、ゼロトラストアクセス	機器と認証方式の対応確認が必要
バッチ・サービス	ADサービスアカウント、gMSA	マネージドID、サービスプリンシパル、証明書	固定シークレットへの置換は避ける
サーバー管理	ドメイン参加、GPO	用途に応じてADを継続、管理方式を分離	Windows Serverまで一律にEntra参加へ移さない
DNS・DHCPなど	AD統合DNS、ドメインサービス	必要性を評価し、最後に統合・縮小	アプリ移行前にDCを減らさない

端末移行は新規端末から始める

既存端末を一斉にAD参加から外すより、入れ替え端末や新規配備端末をMicrosoft Entra参加とIntune管理にする方が安全です。

Microsoft Entra参加端末はクラウドアプリへSSOできます。また、オンプレミスAD環境が残っている場合、一定の条件下でファイル共有などのオンプレミスリソースへSSOすることも可能です。ただし、ドメインコントローラーへの到達性が必要なアプリや、コンピューターアカウントを使ったマシン認証に依存するアプリは、そのままでは利用できない場合があります。(Microsoft Learn)

パイロット対象には、次の条件を満たす端末を選びます。

• 主にMicrosoft 365やSaaSを利用する
• ローカル管理者権限が不要
• 古い業務クライアントを利用しない
• 社内ファイル共有やプリンターへの依存が少ない
• 問題発生時に代替端末を用意できる
• 利用者が検証に協力できる

一方、工場、窓口、検査装置、閉域ネットワークなど、マシン認証や古い業務アプリへの依存が強い端末は後回しにします。

アプリは移行可能性より「業務影響」で分類する

技術的に移行できるアプリから無条件に着手するのではなく、業務影響と移行難易度を組み合わせます。

分類	代表例	対応
効果が高く移行しやすい	SaaS、モダン認証対応Webアプリ	最優先でEntra IDへ移行
効果は高いが検証が必要	全社利用のAD FSアプリ、オンプレミスWebアプリ	パイロットと切り戻し計画を作成
効果が限定的で依存が強い	古いクライアントサーバー型アプリ	更改時期までADを継続
利用実態がない	旧システム、停止済みサービス、未使用の証明書利用先	移行せず廃止
所有者が不明	古いサービスアカウント、用途不明のLDAP通信	停止前に通信・ログ・担当部門を調査

ADを残すこと自体は失敗ではありません。問題なのは、残す理由、所有者、次回の見直し日が決まっていない状態です。

移行対象を決めるための依存関係台帳

AD依存の棚卸しでは、アプリ名、サーバー名、担当者だけを記録しても不十分です。次の項目を含む依存関係台帳を作成します。

項目	記入例
システム名	経費精算システム
業務所有者	経理課
技術所有者	情報システム部
利用者数	全職員、特定部門、外部委託先
IDの作成元	AD、Entra ID、アプリ内DB
認証経路	ブラウザー→AD FS→AD DS
認可方法	ADグループ、アプリ内ロール
使用プロトコル	SAML、LDAP、Kerberosなど
端末要件	ドメイン参加、マシン証明書
サービスアカウント	アカウント名、所有者、権限
AD停止時の影響	新規ログイン不可、全面停止など
移行候補	Entra ID直接連携、Application Proxy、廃止
切り戻し方法	旧設定復元、DNS切り戻し
見直し期限	次回更改、契約更新、四半期レビュー

台帳作成時には、管理者への聞き取りだけでなく、サインインログ、AD FSの利用状況、LDAP通信、サービスアカウントのログオン、DNS問い合わせなど、実際の利用データも確認します。

最初の90日で進める実行例

組織規模によって期間は変わりますが、最初からAD廃止プロジェクトを立ち上げるより、短期間で確認できる成果を作る方が進めやすくなります。

1～30日：現状と障害影響を把握する

• 認証方式とAD依存アプリを一覧化する
• AD FS、PTA、PHSなど現在のサインイン方式を確認する
• ドメインコントローラー停止時の影響を整理する
• 緊急アクセス用アカウントを確認する
• 外部ユーザー、サービスアカウント、特権アカウントを棚卸しする
• 新規システムでレガシー認証を採用しない原則を決める

この段階では、移行日を決めるより「何が止まるか分からない」状態をなくすことを優先します。

31～60日：低リスクの対象で実績を作る

• モダン認証対応アプリを1つEntra IDへ移行する
• 管理者向けにフィッシング耐性のある認証を試行する
• 条件付きアクセスポリシーをレポート専用モードで評価する
• 長期間利用されていないゲストのアクセスレビューを実施する
• 新規端末をMicrosoft Entra参加とIntune管理で試行する
• 所有者不明のサービスアカウントを分類する

Microsoftのアプリ移行ガイダンスでも、アプリを発見・分類し、パイロット、テスト、本番移行の順に進める段階的な方法が示されています。(Microsoft Learn)

61～90日：新しい標準を定着させる

• 新規アプリはEntra ID連携を標準要件にする
• 新規端末はMicrosoft Entra参加を第一候補にする
• 外部ユーザーには終了日または定期レビューを必須にする
• 条件付きアクセスを部門単位で有効化する
• レガシー認証の例外に廃止期限を設定する
• 移行できないシステムには、残す理由と再評価日を記録する

重要なのは、既存システムの移行だけでなく、新しいAD依存を増やさないことです。新規導入の審査基準を変えなければ、移行する一方で新しい依存関係が追加され続けます。

Active Directory依存削減で失敗しやすいポイント

ADを停止する日から先に決める

終了日を先に宣言すると、移行できないシステムが例外として残り、急場しのぎの構成が増えます。

先に決めるべきなのは、次の内容です。

• 新規システムで許可する認証方式
• ADに残してよい依存関係
• 例外を承認する責任者
• 例外の再評価期限
• 移行完了と判断する基準

Microsoft Entra IDをADの完全な代替品として扱う

Microsoft Entra IDは、LDAPサーバーやドメインコントローラーをそのままクラウドへ移したものではありません。

Kerberos、NTLM、LDAP、グループポリシー、マシン認証を必要とするシステムは、アプリ改修、代替製品への移行、橋渡しサービスの利用、またはADの継続が必要です。(Microsoft Learn)

ハイブリッド参加を最終状態にしてしまう

Microsoft Entraハイブリッド参加は、既存のAD参加端末にクラウド機能を追加する有効な移行手段です。ただし、端末が引き続きADとドメインコントローラーへ依存するため、それだけではAD依存の解消になりません。

既存端末にはハイブリッド参加、新規端末にはMicrosoft Entra参加というように、移行期間と最終状態を分けて設計します。

MFAを導入しただけで認証近代化が完了したと考える

MFAを導入しても、次の状態が残っていれば依存とリスクは残ります。

• レガシー認証が許可されている
• 管理者がパスワードと一般的なMFAだけを使用している
• クラウドへのサインインがAD FSやPTAに全面依存している
• 緊急アクセス用アカウントがない
• アプリ内ローカルアカウントが放置されている

認証方式、認証経路、回復性、例外の4点をまとめて見直す必要があります。

人のアカウントだけを棚卸しする

実際には、固定パスワードを持つサービスアカウントやサービスプリンシパルが、AD削減の障害になることがあります。

バッチ、バックアップ、監視、データ連携、PowerShellスクリプト、API連携についても、実行ID、所有者、権限、資格情報の保管場所を確認します。クラウド上の処理では、可能な範囲でマネージドIDなど、固定資格情報を持たない方式へ移します。(Microsoft Learn)

ADを残すべきケース

次のような環境では、ADを当面残す判断が合理的です。

• LDAP、Kerberos、NTLMが必須の業務システムがある
• コンピューターアカウントによるマシン認証が必要
• Windows Serverの管理にグループポリシーを使用している
• 工場設備、医療機器、検査装置など、認証方式を変更できない
• ネットワーク分断時にも拠点内で認証する必要がある
• アプリ改修費が更改までの維持費を大きく上回る
• 法令、監査、契約上の要件を満たす代替方式がまだない

ただし、残す対象は「AD全体」ではなく、必要な機能とシステムに限定します。ドメインコントローラーの台数、不要な信頼関係、使われていないGPO、古い管理者グループ、休眠アカウントまで維持する必要はありません。

Active Directory依存を減らすために最初に行うこと

Active Directory依存を減らす4つの優先領域は、次のとおりです。

1. サインインとMFAをMicrosoft Entra ID中心へ移し、認証経路を近代化する
2. 場所だけに依存せず、ユーザー、端末、アプリ、リスクを使ってアクセスを判断する
3. 従業員だけでなく、外部ユーザー、特権ID、サービスID、AIエージェントまでガバナンス対象にする
4. アプリ、端末、サービスアカウント、ネットワーク基盤のAD依存を一つずつ減らす

最初に着手すべきなのは、ドメインコントローラーの削減ではありません。アプリごとに認証経路、使用プロトコル、AD停止時の影響、所有者、移行候補を記録した依存関係台帳を作成してください。

そのうえで、モダン認証に対応したクラウドアプリ、新規端末、外部ユーザー管理など、効果が高く移行しやすい領域からEntra IDへ移します。ADを必要とするシステムは無理に切り離さず、残す理由と再評価期限を明確にすることが、停止事故を防ぎながら依存を減らす現実的な進め方です。