ADのドメインとOU設計｜組織構造をActive Directoryに落とし込む実務ガイド

Active Directory設計・運用
2026.04.21

「インストールしたらとりあえず動いた」——ADの構築はそこで終わりにしてしまいがちです。

しかし初期状態のADは、ユーザーもコンピューターも「デフォルトのコンテナ」に無分類で積み上がっていく状態です。この状態のまま運用を続けると、GPOが意図通りに適用されない、管理者アカウントと一般アカウントが混在して権限の把握ができない、組織変更のたびに設定変更が膨大になる——といった問題が積み上がります。

ADは「動かすこと」より「正しく設計すること」が重要です。その設計の土台になるのがドメイン設計とOU設計です。

Active Directoryの全体像については「Active Directoryとは？Windows認証基盤の仕組みと設計の基本」を先にご覧ください。この記事ではドメインとOU設計の実務パターンを掘り下げます。

「とりあえずデフォルトのまま」で起きる問題

ADをインストールした直後、ユーザーは CN=Users,DC=example,DC=com というコンテナに、コンピューターは CN=Computers,DC=example,DC=com というコンテナに入ります。これはADのデフォルトの格納場所で、OUではありません。

デフォルトコンテナ（Users・Computers） ADインストール時に自動作成される格納場所。OUと異なりGPOを直接リンクできないため、設計上の器として使うべきではない。

このデフォルトコンテナをそのまま使い続けると3つの問題が起きます。

GPOを細かく適用できない。 OUにしかGPOをリンクできないため、デフォルトコンテナに入ったままのオブジェクトには個別のポリシーを当てられません。全体に同じポリシーしか適用できない状態になります。

管理が属人化する。 誰がどのコンテナにいるか整理されていないため、担当者が変わると「どこに何があるか分からない」状態になります。

権限の委任ができない。 OUごとに管理権限を委任できますが、
デフォルトコンテナでは適切な委任設計ができません。

例えば「東京拠点のPCはIT担当の田中さんに管理させたい」という場合、
OU=東京_PCを作成して田中さんに管理権限を委任すれば、
田中さんは東京拠点のPCだけを管理できます。
しかしデフォルトのComputersコンテナにPCが混在している状態では、
田中さんにコンテナの管理権限を渡すと
他の拠点のPCまで操作できてしまいます。
結果として「全員に広い権限を渡すか、委任を諦めるか」の二択になり、
最小権限の原則が守れなくなります。

まず「デフォルトコンテナを使わない」ことが、AD設計の第一歩です。

参考：Active Directory の組織単位（OU）の設計 | Microsoft Learn

ドメイン設計の基本——1つか、複数か

シングルドメインで十分なケースとは

ほとんどの中小規模環境ではシングルドメインで十分です。1つのドメインで全ユーザー・全コンピューターを管理し、OU設計で組織構造を表現する構成です。

シングルドメイン 1つのドメインで全オブジェクトを管理する構成。管理がシンプルで、中小規模環境に適している。

管理コストが低く、設計がシンプルで、障害時の影響範囲も把握しやすい。「複数拠点がある」「子会社がある」という理由だけでは、マルチドメインにする必要はありません。OUで拠点や部門を分ければ十分です。

マルチドメインが必要になる条件

以下のような場合に複数ドメインの検討が必要になります。

条件 理由
セキュリティポリシーを完全に分離したい ドメインをまたいだポリシー強制ができないため
法的・コンプライアンス要件で分離が必要 子会社・海外拠点の法規制が異なる場合
数万規模のオブジェクトを管理する 大規模環境でのレプリケーション負荷軽減

中小規模の現場でマルチドメインにすると管理コストが跳ね上がるため、本当に必要な理由がない限りシングルドメインを選ぶべきです。

ドメイン・ツリー・フォレストの関係を整理する

ツリー（Tree） 同じDNS名前空間を共有する複数のドメインの集合。親子関係を持つ。

フォレスト（Forest） 1つ以上のツリーの集合。フォレスト内のドメインは信頼関係（トラスト）を持つ。AD全体の管理境界。

実務では「フォレスト＝AD全体の境界」と覚えておけば十分です。中小規模環境では1フォレスト・1ツリー・1ドメインの構成が標準です。

参考：Active Directory のフォレスト設計 | Microsoft Learn

OU設計の考え方——何を軸に分けるか

OUをどう分けるかは「GPOをどう適用したいか」「管理権限をどう委任したいか」の2点から逆算して考えます。組織図をそのままADに移すのではなく、運用上の目的に合わせて設計することが重要です。

OU（Organizational Unit：組織単位） AD内でユーザーやコンピューターをグループ化する管理単位。GPOの適用範囲の制御と管理権限の委任に使う。

地理（拠点）軸・部門軸・機能軸の3パターン

OU設計の軸は大きく3つあります。

地理（拠点）軸： 東京本社・大阪支社・名古屋支社のように拠点でOUを分けます。拠点ごとにネットワーク環境やセキュリティポリシーが異なる場合に有効です。

部門軸： 営業部・開発部・経理部のように部門でOUを分けます。部門ごとのアクセス権・GPO設定が異なる場合に有効です。ただし組織変更のたびにOU移動が必要になるリスクがあります。

機能軸： ユーザー・コンピューター・サーバ・サービスアカウントのように「オブジェクトの種類」でOUを分けます。GPO適用をシンプルに保てるため、特に管理者OUの分離に有効です。

実務では地理軸と機能軸の組み合わせが最もバランスが取れています。部門軸は組織変更への脆弱性があるため、トップレベルOUには使わない方が安全です。

GPO適用を意識したOU設計にする理由

GPOはOU単位でリンクするため、「このOUにはこのポリシーを当てたい」という設計が先にないと、後から修正するのが困難になります。OU設計とGPO設計は切り離して考えられません。

GPO（Group Policy Object） ADからドメイン内のユーザーやコンピューターに設定を一括適用するオブジェクト。OUにリンクして使用する。

GPO設計の詳細については「グループポリシー（GPO）設計入門｜セキュリティ設定を一括管理する方法」（公開予定）で解説します。

OU設計でやりがちな失敗——深すぎる階層

OUの階層は3〜4階層以内に収めることを推奨します。

組織図を忠実に再現しようとして5階層・6階層の深いOU構造を作ってしまうケースがあります。深い階層はGPOの継承関係が複雑になり、「なぜこのポリシーが適用されているのか」の追跡が困難になります。また管理者が直感的に構造を把握できなくなります。

「シンプルに保つ」がOU設計の原則です。

実務で使えるOU設計の型

中小規模環境向けの基本パターン

100〜500ユーザー規模の環境での標準的な構成例です。

example.local（ドメイン）
├── OU=Servers          ← サーバ類
├── OU=Workstations     ← 一般PC
├── OU=Users_General            ← 一般ユーザー
│   ├── OU=Tokyo
│   └── OU=Osaka
├── OU=Groups           ← セキュリティグループ
├── OU=ServiceAccounts  ← サービスアカウント
└── OU=Admin            ← 管理者アカウント（分離）

ポイントは Servers・Workstations・Users_General・Admin を最上位で分離することです。コンピューターとユーザーを分離することで、それぞれに適切なGPOを当てやすくなります。

管理者OUを分離する——特権アカウント保護の視点

管理者アカウントを一般ユーザーと同じOUに置くことは避けてください。管理者OUを専用に作成し、一般ユーザーOUとは完全に分離することを推奨します。

理由は2つです。管理者アカウントに適用するGPO（より強いパスワードポリシー・ログオン制限など）を一般ユーザーとは別に設定できること。そして後述するTier0保護の実装において、管理者OUが分離されていることが前提になるからです。

最小権限の観点からの特権アカウント設計については「最小権限の原則とは？実務での考え方と設計例」も参照してください。AD特権アカウントの詳細設計は「AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務」（公開予定）で解説します。

コンピューターOUとユーザーOUを分ける理由

ユーザーに適用するGPO（デスクトップ設定・ソフトウェア配布など）とコンピューターに適用するGPO（セキュリティ設定・Windows Update管理など）は性質が異なります。同じOUに混在させると、意図しないポリシーが適用されるリスクがあります。

ユーザーOUとコンピューターOUは必ず分離してください。

サービスアカウントも同様です。サービスアカウントを一般ユーザーOUに混在させると、棚卸しや監査が困難になります。ServiceAccounts OUを専用に作成し、そこに集約する設計を推奨します。サービスアカウントの権限設計については「サービスアカウントの権限設計｜最小権限を守るためのパターンと実務ガイド」を参照してください。

参考：OU の設計に関する推奨事項 | Microsoft Learn

ドメイン参加時に押さえておくべきこと

デフォルトのComputers・Usersコンテナは使わない

新しいPCをドメイン参加させると、デフォルトでは CN=Computers コンテナに入ります。新しいユーザーを作成すると CN=Users に入ります。これらはOUではないためGPOをリンクできません。

redircmp と redirusr コマンドでデフォルト格納先を変更することを推奨します。これにより新規オブジェクトが自動的に設計したOUに入るようになります。

redircmp "OU=Workstations,DC=example,DC=local"
redirusr "OU=Users_General,DC=example,DC=local"

OU移動と権限・GPOへの影響

ユーザーやコンピューターを別のOUに移動すると、移動先のOUにリンクされたGPOが適用されます。移動前のOUのGPOは適用されなくなります。

組織変更・異動対応でOU移動を行う際は、移動先のGPO内容を事前に確認することが重要です。意図しないポリシー変更（例：ソフトウェアの削除・制限の追加）が発生する可能性があります。

IDライフサイクル管理の観点での異動対応については「IDライフサイクル管理とは？入社・異動・退職で権限を正しく管理する方法」も合わせてご覧ください。

OU・ドメイン設計チェックリスト

ドメイン設計

  • シングルドメインで要件を満たせるか検討したか
  • マルチドメインにする明確な理由があるか
  • ドメイン名（DNS名）は将来を見据えた命名か

OU設計

  • デフォルトコンテナ（Users・Computers）を使っていないか
  • OU階層は3〜4階層以内に収まっているか
  • ユーザーOUとコンピューターOUが分離されているか
  • 管理者OUが一般ユーザーOUと分離されているか
  • サービスアカウント専用OUが存在するか
  • GPO適用を意識したOU構造になっているか

運用

  • redircmp / redirusr でデフォルト格納先を変更したか
  • OU移動時のGPO影響確認手順が定められているか
  • 定期的なOU構造の棚卸しルールがあるか

まとめ——OU設計はGPOと権限設計の土台

ADの設計において、OU構造は後から変えるのが最も難しい部分の一つです。GPO・権限委任・特権アカウント管理、すべてがOU設計を前提に動きます。最初に「動けばいい」で作った構造が、数年後の運用の足かせになります。

シンプルな構造から始め、目的ごとにOUを分離する——この原則を守るだけで、管理しやすく・攻撃に強いAD環境の土台ができます。

次のステップは、このOU構造の上にGPOを設計することです。「グループポリシー（GPO）設計入門｜セキュリティ設定を一括管理する方法」（公開予定）で詳しく解説します。

OU設計を実際の環境で試してみたい方は、
「AD演習編 Vol.1｜VirtualBoxでAD環境をゼロから構築する」でVirtualBox上に
AD環境を構築してから実践することをおすすめします。

 

あわせてご覧ください

 

コメント

タイトルとURLをコピーしました