ドメインコントローラーの冗長化設計｜DC障害で業務が止まらない構成の考え方

「DCが1台落ちただけで、社内の全員がログインできなくなりました」——朝9時、出社した社員が一斉にパスワードエラーに遭遇する。ヘルプデスクに電話が殺到し、原因究明と復旧に追われる中、業務は完全に止まっています。

ドメインコントローラーは「あって当たり前」のインフラです。だからこそ、落ちたときの影響が甚大になります。

この記事では、DC障害で業務を止めないための冗長化設計の考え方と、実務でよくある落とし穴を解説します。

ドメインコントローラーとは——ADの心臓部を理解する
DCが止まると何が起きるか——障害の影響範囲を知る
冗長化の基本設計——2台構成の考え方とサイト設計
FSMOロールの配置——5つの特殊役割をどう分散させるか
1. 実務での配置推奨
拠点間・クラウド構成での冗長化パターン
よくある失敗パターン4選
冗長化設計チェックリスト
まとめ

ドメインコントローラーとは——ADの心臓部を理解する

ドメインコントローラー（DC：Domain Controller） Active Directoryのデータベースを保持し、認証・認可・ポリシー適用を担うサーバー。ユーザーのログイン要求を処理し、グループポリシーを配布する。ADドメイン環境において中心的な役割を持つ。

DCが担う主な役割を整理します。

役割	内容	止まったときの影響
認証（Kerberos/NTLM）	ユーザーのログイン要求を処理	ログインできなくなる
DNSサービス	ドメイン名の名前解決	ネットワーク全体に影響
グループポリシー配布	セキュリティ設定の適用	設定変更・新規適用が止まる
ADデータベース管理	ユーザー・グループ情報の保持	アカウント管理ができなくなる
FSMOロール	特定の管理操作を一元処理	特権操作ができなくなる

DCはこれだけの役割を一手に担っています。1台しかない環境でDCが落ちると、上記のすべてが同時に停止します。

Active Directoryの基本的な仕組みについては「Active Directoryとは？Windows認証基盤の仕組みと設計の基本」を参照してください。

DCが止まると何が起きるか——障害の影響範囲を知る

DCが停止したとき、何がどこまで影響するかを把握しておくことが冗長化設計の出発点です。

即時影響（数分以内）

新規ログインが失敗する：Kerberosチケットの発行ができないため、新たにログインしようとしたユーザーはエラーになる
DNS名前解決が失敗する：DCがDNSサーバーを兼ねている場合、ドメイン内の名前解決が止まり、ファイルサーバーやプリンターへのアクセスも失敗する

短期影響（数時間以内）

既存セッションへの影響：Kerberosチケットには有効期限（既定10時間）があるため、既にログイン済みのユーザーもチケット更新時にエラーになる
グループポリシーの更新停止：ポリシーの変更が反映されなくなる

長期影響（DC停止が続く場合）

パスワード変更ができなくなる：パスワード変更要求を処理するDCが不在になる
新規アカウント作成・変更ができなくなる：AD管理操作が全停止する

キャッシュによる一時的な救済

Windowsはドメインログイン情報をローカルにキャッシュします（既定で直近10件）。DCが停止していても、過去にそのPCでログインしたことがあるユーザーはキャッシュ認証でログインできる場合があります。

ただしこれは「完全に止まらない」ではなく「しばらく動く」だけです。新規PCや初回ログインユーザーはキャッシュがなく即座に影響を受けます。

冗長化の基本設計——2台構成の考え方とサイト設計

なぜ2台では「最低限」なのか

DCの冗長化で最初に検討するのは2台構成です。

1台がプライマリとして稼働し、もう1台がレプリカとしてADデータベースを同期します。1台が障害を起こしても、もう1台が認証処理を継続できます。

ADレプリケーション（AD Replication） 複数のDC間でActive Directoryのデータベース（ユーザー情報・グループ・ポリシーなど）を同期する仕組み。既定では変更が発生してから15秒以内に同一サイト内のDCへ伝播する。

ただし2台構成には注意点があります。

状況	リスク
2台同時障害	完全停止（可能性は低いが゛ゼロではない）
メンテナンス中の障害	1台をメンテ中にもう1台が落ちると完全停止
FSMOロール集中	一方にFSMOが集中していると機能制限が発生

本番環境では最低2台、できれば3台以上を推奨します。3台目は障害時のフェイルオーバー余裕を持たせるためです。

物理配置の考え方

DCを2台用意しても、同じラックや同じ物理サーバー上に置くと意味がありません。

❌ 悪い例
　物理サーバーA（仮想化基盤）
　　├── DC1（VM）
　　└── DC2（VM）
　→ 物理サーバーAが落ちると両方停止

✅ 良い例
　物理サーバーA
　　└── DC1（VM）
　物理サーバーB
　　└── DC2（VM）
　→ 一方の物理障害でも認証継続

クラウド環境（Azure IaaS）でDCを構成する場合は、可用性ゾーンを分けて配置することが推奨されます。

ADサイトの設計

拠点が複数ある環境ではADサイトの設計が重要です。

ADサイト（AD Site） Active Directoryにおける「物理的な拠点」を表す概念。サイトを定義することで、クライアントが近くのDCに認証要求を向けるよう制御できる。サイト間のレプリケーションスケジュールも管理できる。

サイトを正しく設計しないと、東京のユーザーが大阪のDCに認証要求を出してしまい、WAN帯域を無駄に消費したり、レスポンスが遅くなったりします。

拠点ごとにDCを配置する場合の基本設計は以下です。

東京サイト
　├── DC1（プライマリ・FSMO保持）
　└── DC2（レプリカ）

大阪サイト
　└── DC3（レプリカ・ローカル認証用）

サイト間レプリケーション：DC1 ⇔ DC3（スケジュール制御）

大阪のユーザーはDC3に認証要求を出すため、WAN越しの遅延が発生しません。DC3が停止した場合は自動的に東京のDCにフォールバックします。

FSMOロールの配置——5つの特殊役割をどう分散させるか

FSMOロール（Flexible Single Master Operations） Active Directoryの特定の管理操作を「1台のDCだけが担当する」仕組み。競合を防ぐために単一マスター方式を採用している。5つのロールが存在し、それぞれ担当DCが異なる場合がある。

FSMOには5つのロールがあります。

ロール	範囲	役割	止まったときの影響
スキーママスター	フォレスト	ADスキーマの変更を管理	スキーマ変更ができなくなる（即時影響は小さい）
ドメイン名前付けマスター	フォレスト	ドメインの追加・削除を管理	ドメイン追加ができなくなる
RIDマスター	ドメイン	セキュリティIDの払い出しを管理	新規アカウント作成が eventually できなくなる
PDCエミュレーター	ドメイン	パスワード変更・時刻同期・ロックアウト管理	パスワード変更・ロックアウト解除が遅延・失敗する
インフラストラクチャマスター	ドメイン	グループメンバーシップの参照を管理	クロスドメイン参照に影響（単一ドメインなら影響小）

実務での配置推奨

2台構成の場合

DC1：PDCエミュレーター・RIDマスター・インフラストラクチャマスター
DC2：スキーママスター・ドメイン名前付けマスター

PDCエミュレーターは最も影響が大きいロールです。パスワード変更・アカウントロックアウト解除・時刻同期をすべて担うため、最も信頼性の高いDCに配置します。

3台以上の場合

DC1（メイン）：PDCエミュレーター・RIDマスター
DC2（サブ）：スキーママスター・ドメイン名前付けマスター・インフラストラクチャマスター
DC3（拠点用）：FSMOなし（レプリカのみ）

FSMOロールの現在の配置は以下のコマンドで確認できます。

# FSMOロールの保持DCを確認する
netdom /query fsmo

拠点間・クラウド構成での冗長化パターン

パターン① オンプレのみ・複数拠点構成

本社（東京）
　├── DC1：PDCエミュレーター・RIDマスター保持
　└── DC2：レプリカ

支社（大阪）
　└── DC3：レプリカ（ローカル認証用）

サイトリンク：東京 ⇔ 大阪
レプリケーション間隔：180分（既定）※WAN帯域に応じて調整

支社DCは「あるといい」ですが、WAN帯域が十分あり拠点規模が小さい場合は本社DCのみで運用するケースも現実的です。その場合、WAN障害でログインできなくなるリスクとトレードオフになります。

パターン② ハイブリッド構成（Azure IaaS + オンプレ）

クラウド移行の過渡期に多い構成です。

オンプレ（東京DC）
　├── DC1：FSMO保持
　└── DC2：レプリカ

Azure（Japan East）
　└── DC3：レプリカ（Azure参加端末用）

接続：ExpressRoute または VPN Gateway

Azure上のDCはAzureに参加しているサーバー・VM向けのローカル認証を担います。オンプレとAzureの両方にDCを置くことで、どちらが障害を起こしても認証が継続できます。

ただし、この構成には注意点があります。オンプレとAzure間のVPN Gateway・ExpressRouteが切断された場合、オンプレ側からDC3へ到達できなくなります。「オンプレDCの障害」には有効ですが、「ネットワーク障害」には無力という点を設計時に把握しておいてください。VPN障害時の認証継続を重視する場合は、オンプレ側に最低2台のDCを維持することが前提になります。

この構成ではEntra IDとの連携設計も絡んできます。詳しくは「Entra IDとオンプレAD連携｜ハイブリッド構成の設計と注意点」を参照してください。

パターン③ Entra IDのみ（クラウドネイティブ）

オンプレADを持たず、Entra IDだけで管理する構成です。DCという概念がなくなり、Microsoftのクラウド基盤が可用性を担保します。

新規構築の小規模環境や、M365中心の企業では現実的な選択肢です。ただし既存のオンプレAD依存のシステム（レガシーアプリ・プリントサーバー等）がある場合は移行コストが発生します。

なお、現実の企業環境ではこのパターン③を選択できるケースは限られます。長年運用してきたWindowsファイルサーバー・基幹業務システム・プリントサーバーなどがKerberos認証に依存している場合、Entra IDだけでは認証を代替できません。結果として多くの企業はパターン②のハイブリッド構成を選ばざるを得ないのが実態です。Microsoftが Entra ConnectやEntra Cloud Syncといったハイブリッド連携ツールを積極的に整備し続けているのも、この現実を反映しています。完全なクラウドネイティブ移行は「新規構築のスタートアップ」か「レガシーシステムの完全刷新を済ませた企業」でなければ、現時点では現実的な選択肢になりにくいと理解しておいてください。

よくある失敗パターン4選

① DCを1台しか用意しない

「サーバーコストを抑えたい」「小規模だから1台で十分」という判断でDCを1台だけ構築するケースです。DCは認証基盤であり、止まると業務全体が止まります。仮想化環境であれば追加コストは最小限に抑えられるため、最低2台は必ず用意してください。

② 同一物理サーバー上にDCを2台立てる

仮想化環境でDCを2台作ったものの、両方とも同じ物理サーバー上に配置してしまうパターンです。物理サーバーの障害・メンテナンス・再起動で両方のDCが同時に停止します。DCは必ず異なる物理ホストに分散してください。

③ FSMOロールの場所を把握していない

「FSMOロールがどのDCにあるか知らない」という状態で運用しているケースは珍しくありません。FSMOを保持するDCが障害を起こすと、パスワード変更やアカウント作成ができなくなります。定期的にnetdom query fsmoで確認し、どのDCがどのロールを持っているかを記録しておくことが重要です。