>
>
公開日
最終更新日
Active Directory（アクティブディレクトリ、AD）とは、Windows環境のユーザーやPCを一元管理し、認証とアクセス権限を制御するMicrosoftのディレクトリサービスです。中心となるサービスはActive Directory Domain Services（AD DS）で、管理の効率化とセキュリティ統制がメリットです。
本記事では、自社管理のサーバーなどで運用するオンプレADの仕組みや注意点、Microsoft Entra IDとの違い、クラウドとの相性を解説します。公式ドキュメントのMicrosoft Learn（learn.microsoft.com）も参照しながら、情シス担当者向けに棚卸しと段階移行の判断ポイントを整理します。用語から押さえたい方は「Active Directoryとは」の章から、移行の要否を先に判断したい方は「導入・移行判断フローと棚卸し表」の章から読み進められます。
Active Directoryとは
この記事で単に「AD」と書く場合は、Active Directory全般を指します。この名称は複数の関連サービスの総称で、一般にオンプレADと呼ばれる認証基盤の中心はActive Directory Domain Services（AD DS）です。
本記事のポイント
一般にオンプレADと呼ぶ基盤の中心は、Active Directory Domain Servicesです。
ドメインコントローラーが認証を担い、グループポリシーがWindows端末の設定を統制します。
Microsoft LearnはMicrosoft Entra IDをクラウドとオンプレミスのアプリ向けIDaaSと位置づけており、ADをそのままクラウドへ置き換える製品ではありません。
導入のメリットは、ID・端末設定・権限変更を集約しやすい点にあります。
導入・廃止は社員数だけで決めず、業務アプリの認証方式と端末管理の要件から判断します。
AD DSとオンプレADの位置づけ
Active Directory Domain Servicesを略したAD DSが、この記事で扱うADの中心です。
Microsoftは、ユーザーごとに一つのIDで複数のオンプレミスシステムを管理するため、Windows 2000でAD DSを導入しました。Microsoft Learnの説明は、サービスの起源を示しています。現在の運用では、ディレクトリに登録したIDを使って、PCへのログオンや社内システムの利用を制御します。
「オンプレ」は物理的に社内へ設置する構成を指すことが多いものの、AD DSは仮想サーバーやクラウド上の仮想マシンでも運用できます。設置場所を変えても、ドメインコントローラーの保守責任やADへの依存関係が自動でなくなるわけではありません。
ドメイン・OU・フォレストの基本用語
ADの用語は、認証を共有する範囲、管理対象を整理する単位、複数ドメインを束ねる構造に分けると理解しやすくなります。
用語 | 役割 | 設計時の着眼点 |
|---|---|---|
ドメイン | ユーザーやコンピューターを共通のディレクトリで管理する単位 | 認証や管理を共有する範囲を決めます |
ドメインコントローラー | AD DSを実行し、ディレクトリ情報の保持や認証を担うサーバー | 台数、配置、DNS、バックアップを設計します |
OU | ドメイン内の管理対象を整理する組織単位 | ポリシー適用や管理権限の委任に使います |
グループ | ユーザーなどをまとめ、アクセス権を割り当てる単位 | 部署名だけでなく業務上の役割で整理します |
ツリー | 連続した名前空間を持つドメインのまとまり | ドメイン間の名前と関係を整理します |
フォレスト | スキーマなどを共有する、一つ以上のドメインの集合 | 組織間の分離や信頼関係を検討します |
OUとグループは混同しやすい用語です。たとえば「営業部のPCへ設定を配る」場合はOUとポリシーの関係を設計し、「営業資料を閲覧できる社員をまとめる」場合はグループへアクセス権を付けます。組織図をそのままOUに写す前に、誰が端末を管理するか、どこまで設定を共通化するかを決めます。
企業の認証基盤としての利用
ADを見直す際は、古い技術として切り離す前に、既存システムがどこで認証に依存しているかを調べます。
ファイルサーバー、業務アプリ、複合機などは認証をADに任せていることがあるため、棚卸し表で一件ずつ認証方式を記録します。
Microsoft Entra IDの詳細は、Microsoft Entra IDの基本機能や具体的な導入事例で扱っています。本記事では、ADの役割を理解するための対比に絞ります。
Active Directoryの基本機能と認証の仕組み
ADは、ディレクトリによる情報管理、ドメインコントローラーによる認証、グループポリシーによる設定配布を組み合わせて社内環境を統制します。
ディレクトリは「会社のIT名簿」、ドメインコントローラーは「通行証を発行する窓口」と考えると、役割をつかみやすくなります。ただし、通行証を持つ利用者がどの資料を開けるかは、ファイルサーバーなどの利用先に設定したアクセス権も使って判断します。
ユーザー・グループの管理
管理者は、ユーザー、グループ、コンピューターをADへ登録し、入社・異動・退職に伴う変更を管理します。
権限を社員一人ずつへ直接付けると、異動後に古い権限が残りやすくなります。「経理データ閲覧」「経理データ更新」のように権限別のグループを作り、担当業務に応じて所属を変更する運用にします。人事担当が異動日を通知し、情シスがグループを変更し、データ管理者が利用範囲を承認する流れまで決めると、担当者間の抜けを減らせます。
グループポリシーによる端末設定の管理
グループポリシーは、Windows端末やユーザーへ共通設定を配布する仕組みです。
グループポリシーオブジェクトをGPOと呼び、画面ロック、パスワード関連設定、リムーバブルメディアの利用制限、プリンター設定などを管理します。すべての設定を一度に配布せず、検証用OUで業務アプリへの影響を試してから対象を広げます。適用されない端末があれば、ネットワーク接続、OUの配置、適用対象、設定の競合を順に調べます。
JumpCloudの製品比較では、ADのGPOによる制御対象はWindowsであり、非Windows端末には別の管理手段が必要と整理しています。Macやスマートフォンが混在する環境では、Windows向け設定をそのまま転用せず、端末の種類ごとに管理製品と設定を分けます。
Kerberos・NTLMによる認証と認可
ADの認証は主にKerberosを使い、既存システムとの互換性のためにNTLMも扱います。
NTT東日本も、社内ネットワーク向けの認証プロトコルとしてKerberosとNTLMを挙げています。Kerberosでは、認証後に発行されるチケットを利用してサービスへアクセスします。NTLMはチャレンジレスポンス方式を使うため、Kerberosとは認証の流れが異なります。
利用者がドメインのユーザーとしてPCへサインインします。
Kerberosを使う場合、PCがドメインコントローラーと通信し、認証に必要なチケットを取得します。
PCがファイルサーバーなどの利用先へ、サービス用のチケットを提示します。
利用先がユーザーやグループの情報とアクセス権を照合し、閲覧・更新などの操作を許可します。
認証は「誰かを確かめる処理」、認可は「何を許可するかを決める処理」です。ADで認証できても、共有フォルダーのアクセス権がなければ、そのフォルダーは開けません。トラブル対応では、ログオン失敗と権限不足を分けて調べます。
クラウド認証との方式の違い
Kerberos・NTLMとSAML・OpenID Connectは、同じ認証連携でも前提とする環境や情報の受け渡し方が異なります。
方式 | 主な使い方 | 情報の受け渡し方 | 移行時の調査対象 |
|---|---|---|---|
Kerberos | Windowsドメイン内のサービス認証 | チケットを使います | サービスアカウント、名前解決、時刻同期を調べます |
NTLM | 互換性を要する既存環境の認証 | チャレンジレスポンスを使います | 利用アプリと接続先を特定します |
SAML | Webサービス間の認証連携 | 認証結果を記したアサーションを渡します | サービス側の連携設定と属性を調べます |
OpenID Connect | Web・モバイルアプリの認証連携 | IDトークンなどを利用します | アプリ登録、属性、認証後の処理を調べます |
OAuth 2.0はアクセス権の委任を扱う枠組みで、OpenID Connectはその上に認証の仕組みを加えています。FIDO2は利用者の認証手段であり、SAMLなどの連携方式と同じ分類ではありません。LDAPも認証連携全体を指す言葉ではなく、ディレクトリへ問い合わせるためのプロトコルです。詳しい区別は、LDAPの仕組みとActive Directoryとの具体的な違いで整理しています。
▶ 関連記事: LDAPとは？ADとの違いや仕組みをわかりやすく解説
▲ Kerberos認証によるチケット取得と利用先へのアクセス許可の流れ
Active Directoryによる管理負担の削減と権限統制
ADを使うと、社員や端末ごとに繰り返していた設定変更を集約し、退職・異動時の権限変更を共通の手順で実行できます。
入社・異動・退職に伴うアカウント管理
入退社対応では、人事情報を受け取る窓口と処理期限を決め、ADの変更と業務サービス側の変更を対応づけます。
入社時はアカウント作成と所属グループの設定、異動時は旧権限の削除と新権限の付与、退職時は利用停止を実施します。人数が少なくても機密データや複数拠点を扱うなら管理の集約が役立ちます。一方、クラウドサービスだけで業務が完結する組織では、ADの新規構築よりクラウドID管理を先に検討します。
人事情報から各サービスのアカウント操作まで連携させる場合は、アカウント管理を自動化するプロビジョニングの仕組みとデプロイとの違いが参考になります。
退職者アカウントと残存権限への対処
退職時は、ADのアカウント停止に加え、連携サービスのセッションや独立したアカウントも停止対象に含めます。
退職者のアカウントや権限が残ったままだと、在職中に使っていた情報へ退職後もアクセスできる状態が続きます。
退職予定日と利用終了時刻を人事・所属部門・情シスで共有し、終了時刻にアカウントを無効化します。共有ID、個別発行されたSaaSのID、外部共有リンク、貸与端末も同じ作業票で扱います。ADで止められる範囲と、それ以外の処理を分けると、「ADを止めたので全サービスも停止済み」という見落としを防げます。
シングルサインオンと組織変更への対応
対応する社内システムでは、一度の認証を利用して複数のサービスへアクセスできます。
シングルサインオン（SSO）によって認証操作を減らせますが、ADに登録しただけで全SaaSが自動的に対象になるわけではありません。各システムの対応方式に合わせて連携を設定します。
組織変更では、業務上の役割と権限の対応表を先に更新します。たとえば、経理部から営業部へ異動する社員は、新しいグループへ加えるだけでは不十分です。旧部署の権限を外し、兼務がある場合だけ期限付きの例外として残します。所属情報と実際の権限を別々に棚卸しすると、過去の異動で残った権限も見つけやすくなります。
▶ 関連記事: SSOとは？シングルサインオンの種類や導入の落とし穴を解説
Active Directoryのデメリットと失敗パターン
オンプレADでは、認証基盤の可用性、サーバー保守、監査ログの収集まで運用側が設計しなければなりません。
サーバー更改と冗長化の負担
業務継続を要する環境では、ドメインコントローラーを複数台に分散し、片方を停止しても認証を継続できる構成を設計します。
複数台構成はAD DSの技術的な動作条件ではなく、単一障害点を避けるための運用上の構成です。同一の物理ホストやストレージ上に2台置くだけでは、共通基盤の故障に対応できません。拠点間の回線障害も想定し、停止時にどの拠点で何の業務を続けるかを決めます。
見積もりでは、サーバー、Windows Serverとアクセスに関するライセンス、バックアップ、監視、障害対応、更改作業を分けます。既存の仮想基盤を使えるか、外部委託するかで費用が変わるため、根拠のない一律の金額は置きません。レプリケーションは誤変更も複製するため、冗長化とは別に復旧用バックアップを用意します。
社外端末への設定反映の遅れ
社外PCがドメインコントローラーへ到達できない構成では、GPO更新やパスワード変更後の動作に支障が出る場合があります。
キャッシュされた資格情報でPCへログオンできても、新しい設定や認証情報が反映されたとは限りません。障害票には、社内LAN・VPNへの接続状況、最後に正常利用できた時刻、変更直後かどうかを記録します。常時社外で使うPCがあるなら、クラウド型の端末管理へ移す設定と、ADとの通信を残す処理を分けて検証します。
監査ログの取りこぼし
ADを導入しただけでは、全端末・全サーバーの操作履歴を一元保管して分析できる状態にはなりません。
認証イベントはドメインコントローラー、ファイル操作はファイルサーバー、端末内の操作は各端末というように、必要な証跡は複数の場所へ分散します。対象操作に応じて監査ポリシーやオブジェクト側の監査設定を設計し、イベントログ収集基盤へ転送します。保存容量、保持期間、時刻同期、収集失敗の通知も運用に含めます。
監査担当が「特定フォルダーの削除者を追いたい」と求めるなら、ログオン履歴だけでは足りません。検証用ファイルを実際に削除し、実行者・対象・時刻が検索できるかを試します。
管理者権限と移行作業の失敗
日常業務のIDに高権限を付けたまま使う運用や、依存関係を調べずにサーバーを停止する作業は避けます。
通常業務でDomain Adminsを使用：メールやWeb閲覧用のIDとAD管理用IDを分離し、管理端末と利用経路も限定します。
高権限IDの同期を無条件で許可：同期対象とクラウド側ロールを別々に審査します。ADの所属グループがそのままクラウド管理者権限になるとは限りませんが、同じ資格情報の使い回しは避けます。
DNSを調べずにドメインコントローラーを降格：端末、サーバー、ネットワーク機器が参照するDNSと、認証先を切り替えてから停止を試します。
FSMOやSID履歴の扱いを一括処理：FSMOはドメインやフォレストで特定の管理役割を担うドメインコントローラーを指し、SID履歴は移行前のIDが持っていたアクセス権を引き継ぐための属性です。ドメインコントローラー更改と別ドメインへの移行を区別し、作業に関係する項目だけを手順へ入れます。
AD FSによる連携を残す場合も、証明書更新やサーバー保守を移行対象から外さないようにします。構成を整理する際は、ADFSの仕組みや導入するメリット・デメリットを参照できます。
▶ 関連記事: プロビジョニングとは？デプロイとの違いや種類を解説
Active Directoryの安全な運用と復旧体制
ADの運用担当者は、権限変更の承認、管理者IDの保護、監査ログの点検、復旧訓練を通常業務へ組み込みます。
アカウント停止の期限と承認経路
退職・異動の通知を受けたら、処理予定日、担当者、承認者、完了記録を同じ作業票に残します。
停止期限は、退職時刻に停止する、翌営業日までに停止するなど、業務とリスクに合わせて社内規程で決めます。
長期休職、委託契約の終了、兼務解除も対象に含めます。退職者のデータを引き継ぐ場合は、本人のIDを使い続けず、データ管理者が引き継ぎ先へ権限を付与します。
多要素認証とアクセス経路の制限
クラウドサービスやリモートアクセスへ多要素認証を適用する場合は、どの認証経路が保護対象になるかを分けて設計します。
Microsoft Entra IDやOktaと連携しても、すべてのWindowsログオンや既存の認証方式に自動で多要素認証が付くわけではありません。社外からのアクセス、管理画面への接続、端末へのログオンを別の経路として整理し、各経路の認証方式と代替手段を決めます。条件付きアクセスを使う構成では、対象ユーザー、アプリ、端末の条件を限定して検証し、締め出しに備えた管理手順も用意します。
クラウド側の認証を集約する設計は、クラウド型ID管理サービスであるIDaaSの機能や導入メリットで詳しく扱っています。
バックアップと復旧訓練の実施
障害対策では、バックアップの取得結果だけでなく、復元後に認証と業務を再開できるかまで試します。
誤削除からの復元、単一サーバー障害、フォレスト全体が侵害された場合では、復旧方法が異なります。システム状態を含むバックアップの方式、隔離して保管するコピー、復旧に使う管理者情報を整理します。バックアップ基盤へAD管理者と同じ経路で侵入できる構成なら、資格情報と保管先を分離します。
情シスが、対象障害と業務停止の許容時間を決めます。
隔離した検証環境で、手順書に沿って復元します。
DNS、レプリケーション、ユーザー認証、主要業務アプリの順に動作を試します。
復旧時間と手順の不足を記録し、次の訓練までに修正します。
訓練は定期的に実施し、サーバー更改や認証方式の変更後にも行います。通常のレプリケーションで戻す処理と、権威復元（バックアップから戻した内容を他のドメインコントローラーへ優先して複製する操作）など特別な操作が関わる処理を混ぜず、障害別に手順を分けます。
▶ 関連記事: ADFSとは？認証の仕組みや構築要件・移行判断を解説
オンプレADとMicrosoft Entra IDの違い・移行動向
Microsoft Entra IDへの移行は、ADの設置場所を変える作業ではなく、認証と端末管理の要件を別の仕組みへ移す作業です。
認証基盤と端末管理の比較
比較では、ID管理と端末管理を同じ製品の機能として一括りにせず、別の役割として確認します。
Microsoftは公式ドキュメントで、AD DSとMicrosoft Entra IDの役割の違いを整理しています。Entra IDは旧称Azure ADに当たります。端末制御を含めて比較する場合は、Microsoft Intuneを組み合わせた構成と対比します。
比較軸 | AD DS中心の構成 | Entra ID＋Intune中心の構成 |
|---|---|---|
認証の対象 | Windowsドメインと社内リソースを中心に設計します | Microsoft 365やSaaSなどのクラウド利用を中心に設計します |
端末設定 | GPOを中心に管理します | Intuneの構成・コンプライアンスポリシーなどで管理します |
端末の登録 | ドメイン参加を使います | Entra参加など、利用要件に合う登録方式を選びます |
利用者側の保守 | ドメインコントローラー、DNS、更新、バックアップを扱います | クラウド設定、端末管理、連携、権限の保守を扱います |
移行時の課題 | 既存アプリと認証基盤への依存を整理します | GPOの代替、アプリ連携、端末移行を検証します |
GPOの設定とIntuneの設定には、一対一で対応しない項目があります。移行表では「同じ設定で置換」「別の制御へ変更」「業務上不要として廃止」「AD側へ残す」に分類します。設定数だけを進捗指標にせず、業務要件を満たしたかで判定します。
2026年の市場データとハイブリッド運用
AD依存を残しながらクラウド認証を利用する構成も、移行の選択肢に入ります。
Mordor IntelligenceのADセキュリティ市場レポートは、2026年のハイブリッド展開のシェアを37.22％としています。対象はADセキュリティ市場であり、全企業のAD構成比ではありません。この数値だけでハイブリッドを「全企業の主流」とは断定できませんが、オンプレ全廃に限定しない検討材料になります。
国内のクラウドID管理について、ITRは2026年4月公表の市場調査で、2024年度のIDaaS市場を前年度比23.9％増の303億5,000万円と集計し、2024～2029年度の年平均成長率を9.5％と予測しています。売上規模の拡大は、自社のADをすぐ廃止できる根拠にはなりません。実際の移行範囲は、残るアプリと端末の要件から決めます。
AD継続・同期・段階廃止の条件
KerberosやLDAPに依存する業務が残るなら、ADの継続またはハイブリッド運用から検討します。
既存アプリがSAMLやOpenID Connectへ対応でき、端末設定も代替できるなら、クラウド中心へ進めます。対応できないアプリがある場合は、改修、製品変更、認証基盤の残置を比較します。Microsoft Entra Domain Services（クラウド上でドメイン参加やKerberos認証などの機能を提供するサービス）やクラウドKerberos trust（Entra IDで認証した端末からオンプレミスのリソースへKerberosで接続する方式）などの関連方式もありますが、用途が異なるため、名称だけで置換可能と判断しません。
同期構成では、Microsoft Entra Connectの対象OU、属性、IDの一致方法、認証方式を決めます。退職者の利用停止は、同期が完了するまでの時間だけに依存させず、クラウド側のセッション処理も作業票に含めます。Okta AD Agentによる連携を使う場合も、同期対象と障害時の切り分けを定義します。
複数OSを含む構成ではJumpCloudなども比較対象になります。製品を選ぶ前に「クラウド認証」「Windows設定」「Mac設定」「LDAP・RADIUS連携」を分け、各要件をどのサービスで満たすかを表にします。クラウド移行の詳細は、Entra IDへの具体的な移行対策や機能・料金プランで扱っています。
▶ 関連記事: IDaaSとは？導入メリット・デメリットと失敗しない選び方を解説
▲ AD DS中心の構成とEntra ID・Intune中心の構成の比較
国内企業のActive Directory導入・移行事例
国内企業の事例は、クラウド管理への移行、ADを残した認証連携、サーバー運用の外部化に分けると、自社の選択肢と対応づけられます。
以下の数値は各社の事例公表時点の実績です。2018年・2019年の事例は過去の施策と成果を示しており、現在の構成やサービス条件は変化している可能性があります。現行サービスの仕様や見積もりではなく、移行方式を比較する材料として扱います。
企業・業種・対象規模 | 時点 | 課題 | 施策 | 成果・到達点 |
|---|---|---|---|---|
NTTコミュニケーションズ／通信／社内PC約40,000台と従業員のID | 2024年 | 従来のオンプレミス中心のID・PC管理の見直し | Microsoft Entra IDとMicrosoft Intuneによるクラウド管理へ移行 | 約40,000台を対象にクラウド管理へ移行 |
清水建設／建設／社外からの業務アクセス端末 | 2018年 | 社外からの業務アクセス基盤の運用負担 | リモートアクセス基盤を導入し、ADと認証連携 | ADと認証連携したリモートアクセス基盤を導入 |
東部瓦斯／ガス／各拠点のADサーバー11台 | 2019年 | 分散したサーバーの更新・保守作業 | ADサーバーをクラウドサービスへ移行 | Windows Update等のOSレベルの運用負担を軽減 |
NTTコミュニケーションズのクラウド管理への移行
NTTコミュニケーションズの事例では、IDとPCの管理を一緒に見直しています。
Microsoftが2024年に公表した事例は、社内PC約40,000台と従業員のIDを、Microsoft Entra IDとMicrosoft Intuneによる管理へ移した取り組みを扱っています。自社で同様の方向を選ぶ場合は、認証の切り替えだけで計画を終えず、端末設定と利用者サポートも移行対象に含めます。
清水建設のADを生かした認証連携
清水建設の事例は、ADを残したまま社外アクセスの運用を改善した例です。
IIJが2018年5月に取材した事例では、社外からの業務アクセスでADと認証連携するリモートアクセス基盤を紹介しています。社内システムの依存が強いなら、認証基盤を廃止する前にアクセス経路を改善する方法も選べます。
東部瓦斯のサーバー運用の外部化
東部瓦斯の事例は、ADの機能を利用しながら保守負担を減らした例です。
IIJの2019年2月時点の事例は、拠点に分散した11台のADサーバーを移行し、OSレベルの更新運用の負担を減らした成果を示しています。機能の置換が難しく、保守要員が不足している場合は、クラウドID管理への全面移行と、ADの運用委託を別案として比較します。
連携方式を検討するときは、シングルサインオンの仕組みや導入における注意点も併せて整理できます。
▶ 関連記事: Entra ID（旧Azure AD）とは？機能・料金や移行対策
Active Directoryの導入・移行判断フローと棚卸し表
導入・移行の方針は、社員数ではなく、認証の依存先、端末設定、運用体制を確認して決めます。
業務要件に基づく判断フロー
最初にADを使う業務を特定し、残す機能と置き換える機能を分けます。
Kerberos・NTLM・LDAPを使う業務がある場合：対象アプリと管理者を特定し、改修・代替できるまではAD継続またはハイブリッドを選びます。
AD認証の依存がなく、GPOを代替できる場合：クラウド中心のID・端末管理を小規模な対象で試します。
依存を残す一方、サーバー保守が負担の場合：ADの運用委託やホスティングも比較し、機能移行とは別に保守負担を見積もります。
依存関係を把握できていない場合：ドメインコントローラーの削減を先送りし、認証ログと接続設定から対象を調べます。
社員数が同じでも、工場設備を持つ企業とSaaS中心の企業では選択が変わります。拠点間回線、オフライン利用、端末のOS、委託先の利用、既存のMicrosoft 365契約も判断条件へ加えます。少人数でも止められない業務があるなら、認証の冗長化と復旧体制を先に整えます。
そのまま使える棚卸しテンプレート
棚卸し表には対象名に加え、責任者、依存先、停止時の影響、移行後の扱いまで記録してください。
対象 | 記録する項目 | 判断への使い方 |
|---|---|---|
ユーザー・グループ | 所属、業務責任者、利用状態、権限、期限 | 不要IDを停止し、同期対象を絞ります |
端末 | OS、参加方式、利用場所、管理者、接続経路 | クラウド管理へ移す対象と例外端末を分けます |
業務アプリ・複合機 | 認証方式、参照先、サービスアカウント、製品担当者 | 認証を置換できるか、ADを残すかを決めます |
GPO | 目的、対象OU、設定内容、所有者、業務への影響 | 置換・変更・廃止・残置に分類します |
共有フォルダー | データ責任者、利用グループ、機密区分、監査対象 | 移行先のアクセス権と監査設定を設計します |
特権ID | 用途、利用者、利用端末、クラウド側権限 | 通常IDとの分離と同期範囲を決めます |
インフラ依存 | DNS、証明書、RADIUS、VPN、バックアップ | 認証以外に停止する機能を洗い出します |
同期対象OUは、現行OUをすべて選ぶ前に用途を分類します。検証用、休眠、管理用、機器用のオブジェクトを整理し、アプリが参照する属性と合わせて対象を決めます。削除対象から外したつもりのIDが別の仕組みで再作成されないよう、人事データや自動処理との関係も記録します。
権限整理には、ロールベースアクセス制御であるRBACの設計例とABACとの違いを利用できます。役割ごとの権限表を作り、部署の承認者が過不足を判定する運用にします。
段階移行のフェーズと完了条件
移行日程は一律の月数ではなく、前のフェーズの完了条件を満たした時点で次へ進めます。
フェーズ | 担当と作業 | 次へ進む条件 |
|---|---|---|
要件整理 | 情シスと業務責任者が依存関係と停止影響を整理します | 対象、責任者、残置する機能が決まっています |
設計 | 情シスが同期範囲、認証、端末設定、ログ、復旧を設計します | 例外と切り戻し手順を文書化しています |
限定検証 | 利用部署と情シスが代表端末・アプリで試します | 通常業務、パスワード変更、社外利用、退職処理を再現できています |
段階展開 | 情シスが対象部署を分けて展開し、窓口が問い合わせを記録します | 重大障害がなく、例外の担当と対処方法が決まっています |
旧環境の整理 | 情シスが残存通信と認証を調べ、停止試験を実施します | 業務影響がなく、復旧方法と記録を保管しています |
たとえば、社外PCを先にクラウド管理へ移し、社内の基幹アプリだけAD認証へ残す計画も組めます。その場合の完了は「AD廃止」ではなく、「対象端末の移行完了」と「残す認証基盤の運用確立」に分けます。すべての移行を一つの終了日に押し込まず、業務側が合意できる単位で進めます。
▶ 関連記事: RBACとは？ABACとの違いや読み方・情シス向け設計手順を解説
▲ 業務要件と認証依存に応じたActive Directory導入・移行の判断フロー
よくある質問
導入前は、ADが必要な業務、Windows以外の端末管理、移行費用の前提を分けて確認します。
Q：小規模企業でもADの導入は必要ですか？
A：社員数だけでは決まりません。WindowsファイルサーバーやAD認証を使う業務があるなら導入を検討し、SaaS中心で認証・端末管理の要件を満たせるならクラウド中心の構成から検討します。
Q：MacもADで管理できますか？
A：MacをADへ参加させる構成はありますが、Windows向けGPOと同じ端末制御は行えません。Macの設定やアプリ配布も管理するなら、Microsoft Intune、Jamf Proなどの対応する管理製品とID基盤を組み合わせます。
Q：AD移行の期間と費用はどのように見積もりますか？
A：ユーザー数に加え、認証依存アプリ、GPO、拠点、端末の再設定、利用者サポート、復旧検証を作業単位へ分解して見積もります。既存契約で使える機能を整理し、不足するライセンスと移行作業費を分けて比較します。
Q：ADを廃止する前に何を試しますか？
A：対象のドメインコントローラーへ依存する認証、DNS、アプリ連携を整理したうえで、切り戻せる停止試験を行います。通常業務だけでなく、端末再起動、パスワード変更、社外利用、定期バッチも試し、影響が残れば依存先を解消してから廃止へ進みます。
まとめ
Active Directoryは、ユーザーやコンピューターの情報を管理し、社内システムの認証・認可を支える基盤です。クラウド移行を考えるときも、社員数やサーバーの古さだけで廃止を決めず、認証依存と端末設定を切り分けます。
まず明日、主要業務アプリの認証方式、GPOの目的、特権ID、退職者の停止手順を棚卸し表へ記入します。業務責任者と残す機能を合意し、限定検証の結果を見て、AD継続・ハイブリッド運用・クラウド中心の構成へ進めます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
