オンプレミスActive Directory廃止への進め方：依存を減らす理由と移行計画

企業のPCや業務システムを管理してきたオンプレミスのActive Directoryについて、依存を減らし、将来的な廃止を検討する方向性が示されています。SaaSの利用や社外で働く機会が増えた企業では、新しい端末やサービスまで社内ドメインを前提にする必要があるか、見直す価値があります。

Microsoft自身も、Microsoft Entra IDなどへの移行を通じた「AD最小化」を案内しています。企業が取るべき方針は、新しいAD依存を増やさず、既存の依存を解消した範囲からクラウド中心へ移すこと です。

この記事では、Active DirectoryをWindows ServerのActive Directory Domain Services（AD DS）という意味で使用します。製品の位置づけと公式ガイダンスは、2026年10月31日時点で確認しています。

なぜオンプレミスADへの依存を見直すのか

AD DSは、ユーザーやグループ、Windowsのドメイン参加、認証、グループポリシーをまとめて扱う基盤です。社内のWindows環境には有用ですが、企業IT全体をこの基盤に結び付け続けると、次の課題が生じます。

サーバーを維持する仕事が残る

ドメインコントローラーという認証を担うサーバーには、更新、監視、バックアップ、復旧の準備が必要です。冗長化した場合は、複製や拠点間接続も管理します。担当者には認証とネットワークの両方の知識が求められます。

ドメインコントローラーをAzureなどの仮想マシンへ移しても、AD DSの運用責任は残ります。サーバーの設置場所を変えることと、ADへの依存をなくすことは別です。 Microsoftのディレクトリサービス比較

社外の端末管理が社内ネットワークに結び付きやすい

自宅へ直送したPCの初期設定や、長期間出社しない端末への設定配布では、社内ネットワークへの接続が前提だと運用が複雑になります。クラウドからの管理に移せる業務を整理すると、VPNや出社を必要とする場面を減らせます。

ただし、Entra参加したPCでも、AD依存のファイル共有などを使う間はドメインコントローラーへの到達性が必要になる場合があります。PCの参加先を変えるだけで、業務全体がVPN不要になるわけではありません。Entra参加端末からオンプレミスへのSSO

SaaS連携とアカウント管理の経路が増える

AD DSだけではSaaS向けの認証を直接担えず、クラウドID基盤との同期やフェデレーションなどを組み合わせます。入退社時にどこでアカウントを変更するか、どの経路で認証するかが増えると、権限の削除漏れや障害の切り分けも管理課題になります。

新しいサービスは、クラウドID基盤とのシングルサインオン（SSO）やアカウント連携を前提に選定し、AD連携を必須条件にする必要があるかを検討します。ADとEntra IDの比較

Windows以外も含めた管理を設計し直す必要がある

Macやスマートフォンを含む環境では、Windowsのドメイン参加やグループポリシーだけで端末管理を完結できません。OSごとの登録方式と、MDM（モバイルデバイス管理）による設定配布を設計する必要があります。

Oktaも、ADへの依存を見直す資料で、非Windows端末への対応や維持負担を課題として挙げています。ただし、同社製品を提供する立場での提言であり、自社の要件との照合が必要です。Oktaの解説

特権の侵害が広範囲へ影響する

ADの管理者権限やドメインコントローラーが侵害されると、多くのアカウントやシステムに影響する可能性があります。Microsoftも、過剰な権限の削減、管理専用端末の利用、ドメインコントローラーの保護を案内しています。

移行中も、残るADには更新・監視・復旧対策を続けます。クラウド移行後にもID基盤の管理者権限や認証情報の保護は必要です。ADを保護するためのベストプラクティス

MicrosoftもAD最小化とクラウド移行を推進している

Microsoft Learnの「クラウドへの移行」は、ADへの依存削減から完全な廃止までを視野に入れた公式ガイダンスです。概要では、クラウド接続、ハイブリッド、クラウド優先、オンプレミスADの最小化、クラウドのみ、という5段階を示しています。Microsoftの移行概要

特に「クラウド優先」の実装ガイドは、新規WindowsクライアントのEntra参加、Intuneなどによる管理、新規アプリのモダン認証への対応を推奨しています。調達や変更管理でも、新たなAD依存を追加しないか評価する考え方です。クラウド優先アプローチの実装

したがって、「MicrosoftもAD依存の縮小とEntra IDへの移行を推進している」と説明できます。一方、この方針をAD DS製品全体の終了告知や、全企業に共通する廃止期限と解釈することはできません。依存が残るシステムを保護しながら移行する計画が必要です。

移行後は認証・端末管理・初期設定を分けて考える

Microsoft製品を中心に構成する場合、主な役割は次のように整理できます。

役割	主な選択肢	確認すること
ユーザー・デバイスのIDとアクセス制御	Microsoft Entra ID	認証、SSO、条件付きアクセスの設計
端末の設定・アプリ・状態の管理	Microsoft Intune	対象OS、管理設定、アプリ配布、準拠性の判定
Windowsの初期設定と登録	Windows Autopilot	端末調達から利用開始までの登録・配布手順

Entra IDは、AD DSをそのままクラウドへ移したものではありません。既存のLDAP参照、Kerberos認証、GPOなどを、すべて同じ方法で置き換えられるとは限りません。役割と実装を分けて移行します。Microsoftの機能比較

端末側の詳細は、Microsoft Intuneの機能とEntra ID・ADとの違いとWindows Autopilotによる初期設定を参照してください。

廃止へ向けた実務の進め方

以下は公式ガイダンスを踏まえた計画例です。ADの停止日を先に決めるより、業務ごとに「何への依存がなくなれば移行できるか」を定義すると進めやすくなります。

1. ADへの依存関係を棚卸しする

PCの台数だけで判断せず、認証、設定、データ、運用の経路を洗い出します。

対象	確認する依存の例	移行方針の例
ユーザー・グループ	ADを起点とする作成、同期、権限付与	管理元と入退社処理をクラウドへ移す
PC・GPO	ドメイン参加、ログオンスクリプト、アプリ配布	Entra参加とMDMで再設計する
業務アプリ	LDAP、Windows統合認証、サービスアカウント	認証改修、SaaS化、期限付きの維持を選ぶ
ファイル・印刷	ADグループの権限、共有パス、印刷認証	データ・権限・利用手順をセットで移す
ネットワーク・証明書	DNS、NPS/RADIUS、Wi-Fi・VPN認証、AD CS	AD関連サービスの存続要件を個別に調べる

各項目には、業務責任者、移行先、検証方法、残す理由、見直し時期を記録します。利用者への聞き取りだけでなく、設定や認証ログでも実態を確認します。

2. 新規PC・新規サービスで依存を増やさない

新しいPCはEntra参加とIntune管理を標準候補にし、新規アプリはSAMLやOpenID ConnectによるSSO、SCIMなどによるアカウント連携を確認します。対応できないものは、理由を明記した例外として管理します。

端末調達時から方針を適用すれば、すべての既存PCを一度に移す必要はありません。更新のタイミングを利用し、少人数の検証から対象を広げます。

3. GPOと端末運用を移行する

既存のGPOは、そのままコピーする前に、現在も必要な設定かを確認します。Intuneのグループポリシー分析では、GPOを取り込み、MDMで対応できる設定や未対応の設定を調べられます。全項目を移せる保証ではないため、設定カタログなどで再設計し、実機で適用結果を検証します。グループポリシー分析

検証にはサインインだけでなく、アプリ配布、暗号化と回復キー、更新、ローカル管理者、紛失時対応、再セットアップを含めます。利用者のデータとプロファイルの移行方法も決めます。

4. アプリとID管理の依存を順に解消する

LDAPやWindows統合認証を使うアプリは、認証改修やサービス更新と合わせて移行します。ユーザー・グループの管理元、入退社処理、アプリへの権限付与も移す必要があります。PCのクラウド管理が完了しても、アカウントの作成元がADなら依存は残ります。Microsoftの移行ワークストリーム

どうしても従来型のドメイン機能が必要な場合は、ADを限定的に維持するか、要件に応じてMicrosoft Entra Domain Servicesを検討します。後者も従来型認証を提供するサービスなので、導入だけでAD型の依存が消えるわけではありません。

5. 廃止条件を満たしてからADを撤去する

最後のドメインコントローラーを撤去する前に、少なくとも以下を確認します。

ユーザー、端末、サーバー、サービスがAD認証を必要としない。
LDAP、GPO、スクリプト、タスク、サービスアカウントの依存を解消している。
ID同期やフェデレーションの構成変更後も、認証とアカウント管理が正常に動く。
DNSや証明書など、関連サービスの代替と切り替えを検証している。
通常業務、月次処理などの定期業務、障害時の復旧手順を検証している。

廃止手順と切り戻し条件を定め、承認された変更計画で実施します。単にドメインコントローラーの電源を切ることを、廃止完了とはしません。

完全廃止が難しい場合も、縮小を進める

改修できない基幹システムやサーバーがあれば、当面ADを残す判断もあります。その場合も、対象を限定し、必要な権限だけを与え、更新・監視・復旧テストを継続します。残した依存には、次の更改時期や再評価の条件を設定します。

効果の評価には、残るAD依存アプリ数、ドメイン参加PC数、特権アカウント数、月々の運用工数などを使えます。費用はクラウドのライセンス、移行作業、併存期間の二重運用も含めて比較します。クラウド移行だけで費用削減や安全性向上が自動的に実現するとは限りません。

まずは依存関係の一覧を作り、次回のPC更新と新規サービス導入からクラウド優先の方針を適用することが、廃止へ向けた着実な第一歩になります。