こんにちは、今回はシリーズ第２回ドメイン環境の構築 - 検証環境の構築手順について解説いたします！

連載の構成

第1章：基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎

【★今回です★】第2章：ドメイン環境の構築 - 検証環境の構築手順

第3章：クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順

第4章：プロキシサーバーと統合Windows認証

第5章：ブラウザ設定と認証 - 各ブラウザでの設定方法

第6章：トラブルシューティング - よくある問題と解決方法

第7章：セキュリティとベストプラクティス - 本番環境での考慮事項

第8章：実践的な構成例 - AIセキュリティツールとの統合事例

第2章：ドメイン環境の構築

2.1 ドメイン名の設計

2.1.1 ドメイン名の命名規則

Active Directoryを構築する際、最初に決めなければならない重要な要素がドメイン名です。これは、会社を設立する際に社名を決めるのと同じくらい重要な決定です。一度決めてしまうと後から変更するのは非常に困難なため、慎重に検討する必要があります。

【ドメイン名決定会議】
社長：「新しいADシステムのドメイン名を決めたいんだが」
IT管理者：「はい、これは慎重に決める必要があります」
総務部長：「会社名でいいんじゃない？『田中商事』だから tanaka-shoji？」
IT管理者：「ちょっと待ってください。ドメイン名には守るべきルールがあるんです」

ドメイン名の基本的なルールを理解するために、まず DNS（Domain Name System）の構造を見てみましょう。ドメイン名は階層構造になっており、右から左に向かって、より具体的になっていきます。

【ドメイン名の構造】
IT管理者：「例えば、server.tokyo.jp.qualiteg.com という名前があったとします」

解説：
- com: トップレベルドメイン（TLD）
- qualiteg: セカンドレベルドメイン（組織名）
- jp: サブドメイン（国・地域）
- tokyo: サブドメイン（拠点）
- server: ホスト名（個別のコンピューター）

営業部長：「住所みたいなものか」
IT管理者：「その通りです！日本.東京都.港区.田中ビル みたいな構造です」

ドメイン名に使える文字には制限があります。

【使える文字・使えない文字】
新入社員：「かっこいい名前にしたいです！qualiteg☆japan とか」
IT管理者：「残念ながら、特殊文字は使えません」

使える文字：
- 英字（a-z, A-Z）※大文字小文字は区別されない
- 数字（0-9）
- ハイフン（-）※最初と最後以外

使えない文字：
- アンダースコア（_）
- スペース
- 日本語
- 特殊文字（@, #, $, ☆ など）

新入社員：「qualiteg_japan もダメ？」
IT管理者：「はい、アンダースコアは使えないんです。qualiteg-japan ならOKです」

長さの制限もあります。

【ドメイン名の長さ】
総務部長：「qualiteg-information-technology-corporation-limited-japan.com はどう？」
IT管理者：「長すぎます！各ラベル（ドット区切りの部分）は63文字以内です」

総務部長：「全体では？」
IT管理者：「全体で255文字以内ですが、実用上は短い方がいいです」

社員A：「なんで短い方がいいの？」
IT管理者：「毎日入力することを想像してください」
社員A：「確かに...qualiteg-information-technology-corporation-limited-japan\yamada とか打ちたくない」

2.1.2 .localドメインの問題点

多くの組織で「.local」というトップレベルドメインが使われてきましたが、実はこれには問題があります。

【.localドメインの歴史】
ベテラン管理者：「2000年代は みんな .local を使ってたんだ」
新人：「なぜですか？」
ベテラン：「Microsoftの古いドキュメントで推奨されてたし、内部用として分かりやすかったから」

新人：「じゃあ、うちも qualiteg.local でいいですね」
ベテラン：「待って！今は問題があることが分かってるんだ」

.localドメインの最大の問題は、mDNS（Multicast DNS）との競合です。

【mDNSとの競合】
（会議室にて）
営業：「MacBookから社内サーバーにアクセスできません！」
IT管理者：「また .local の問題か...」

解説：
MacやiPhone：「.local はmDNS（Bonjour）用の特別な名前だ」
Windows AD：「.local は私のドメイン名だ」
Mac：「printer.local を探そう...あれ？mDNSで探すの？それともDNSサーバーに聞くの？」

結果：混乱して正しく名前解決できない

IT管理者：「AppleデバイスとWindows環境が混在すると問題が起きやすいんです」

実際のトラブル例を見てみましょう。

【.localドメインのトラブル】
月曜日
田中：「Windows PCからは file-server.qualiteg.local にアクセスできます」
IT：「よかった」

火曜日  
山田：「私のMacからアクセスできません！」
IT：「.local の問題ですね...DNSの設定を調整します」

水曜日
鈴木：「iPhoneから社内Wikiが見れません」
IT：「また .local か...」

木曜日
佐藤：「Linux サーバーから名前解決が不安定です」
IT：「.local にしなければよかった...」

さらに、将来的な問題もあります。

【将来の拡張性の問題】
社長：「クラウドサービスと連携したい」
IT管理者：「.local ドメインは問題があります」

社長：「どんな？」
IT管理者：「例えば、Office 365やAzure ADと連携する時...」
- SSL証明書が取得できない（.localは公式TLDではない）
- 外部サービスが .local を認識しない
- ハイブリッド構成が複雑になる

社長：「じゃあ最初から .local を避けるべきだったのか」
IT管理者：「はい、今から構築するなら別の選択肢を推奨します」

2.1.3 推奨されるドメイン名の形式

現在のベストプラクティスに基づいた、推奨されるドメイン名の形式を見ていきましょう。

【推奨パターン1：サブドメイン方式】
IT管理者：「最も推奨される方法は、会社が所有する公開ドメインのサブドメインを使うことです」

社長：「うちは qualiteg.com を持ってるが？」
IT管理者：「それなら ad.qualiteg.com や corp.qualiteg.com がお勧めです」
IT管理者：「今回の例では jp.qualiteg.com を使いましょう」

メリット：
- 公式なドメイン名なのでSSL証明書が取得可能
- 外部サービスとの連携が容易
- DNS の管理が明確

営業部長：「でも、外部から見えちゃうんじゃ？」
IT管理者：「いい質問です。これを『スプリットDNS』で解決します」

スプリットDNS（Split DNS）の説明を見てみましょう。

【スプリットDNSの仕組み】
IT管理者：「内部と外部で異なるDNS応答を返します」

外部からのアクセス：
訪問者：「qualiteg.com のIPアドレスは？」
外部DNS：「133.167.109.189 です（公開Webサーバー）」
訪問者：「jp.qualiteg.com は？」
外部DNS：「そんなレコードはありません」（内部情報は非公開）

内部からのアクセス：
社員：「qualiteg.com のIPアドレスは？」
内部DNS：「192.168.1.100 です（内部Webサーバー）」
社員：「jp.qualiteg.com は？」
内部DNS：「192.168.1.10 です（ドメインコントローラー）」

推奨パターン2：予約済みTLDの使用も見てみましょう。

【.internalドメインの使用】
IT管理者：「もう一つの選択肢は、.internal という予約済みTLDを使うことです」

新人：「qualiteg.internal ですか？」
IT管理者：「はい。これは内部使用専用として予約されているので安全です」

メリット：
- 外部と競合しない
- 内部用途であることが明確
- 将来的にも安全

デメリット：
- SSL証明書は公式認証局から取得できない
- 比較的新しいので、古いシステムで問題が出る可能性

実際の選択プロセスを見てみましょう。

【ドメイン名決定のチェックリスト】
会議室での検討：
IT管理者：「では、チェックリストで確認しましょう」

1. 外部ドメインを所有している？
   社長：「qualiteg.com を持っています」 → Yes

2. 将来的にクラウド連携の予定は？
   社長：「Office 365導入を検討中」 → Yes

3. SSL証明書が必要？
   IT管理者：「Exchange ServerやVPNで必要」 → Yes

4. Apple製品を使用？
   営業：「営業部はiPad使ってます」 → Yes

IT管理者：「すべてYesなので、jp.qualiteg.com を推奨します」

2.1.4 将来を見据えたドメイン設計

ドメイン名は一度決めると変更が困難なため、将来の拡張を考慮した設計が重要です。

【10年後を想像する】
経営企画：「5年後には海外展開を考えています」
IT管理者：「それなら、地域別のサブドメインを考慮すべきです」

現在：
- jp.qualiteg.com（単一ドメイン）

将来の拡張案：
- jp.qualiteg.com（日本）
- us.qualiteg.com（アメリカ）
- eu.qualiteg.com（ヨーロッパ）

経営企画：「なるほど、最初から階層を考えておくのか」

M&A（合併・買収）への対応も考慮しましょう。

【企業買収シナリオ】
2024年：Qualitegスタート
- jp.qualiteg.com

2026年：山田工業を買収
社長：「山田工業を買収したが、ADはどうする？」

選択肢1：統合
- 山田工業のユーザーを jp.qualiteg.com に移行
- メリット：管理が一元化
- デメリット：移行作業が大変

選択肢2：信頼関係
- jp.qualiteg.com と jp.yamada-kogyo.com で信頼関係
- メリット：移行作業が最小限
- デメリット：管理が複雑

選択肢3：最初から親会社構造
- group.qualiteg.com（親）
- jp.group.qualiteg.com（子）
- yamada.group.qualiteg.com（子）

クラウド時代の考慮も重要です。

【ハイブリッド環境への対応】
IT管理者：「最近はオンプレミスとクラウドの併用が一般的です」

従来の設計：
- 社内AD：qualiteg.local（問題あり）
- クラウド：qualiteg.onmicrosoft.com
→ 名前が違うので統合が複雑

推奨設計：
- 社内AD：jp.qualiteg.com
- Azure AD：qualiteg.com
→ 同じドメイン名で統合が容易

新人：「最初から統合を考えた名前にするんですね」
IT管理者：「その通り。後から変更するのは地獄です」

命名規則ドキュメントの重要性も忘れてはいけません。

【命名規則の文書化】
IT管理者：「決定したルールは必ず文書化しましょう」

Qualiteg AD命名規則 v1.0
========================
1. ドメイン名
   - 本番環境：jp.qualiteg.com
   - 開発環境：dev.jp.qualiteg.com
   - 災害対策：dr.jp.qualiteg.com

2. サイト名
   - 東京本社：TOKYO-HQ
   - 大阪支社：OSAKA-BR
   - 名古屋営業所：NAGOYA-SO

3. サーバー命名
   - DC：DC01-TKY, DC02-TKY
   - ファイル：FS01-TKY
   - メール：EX01-TKY

4. OU構造
   - 第1階層：地域（Tokyo, Osaka）
   - 第2階層：部門（Sales, Admin, IT）
   - 第3階層：用途（Users, Computers, Groups）

新人：「これがあれば、誰が作業しても統一できますね」
IT管理者：「はい、属人化を防ぐためにも重要です」

2.2 Windows Serverの役割と機能

2.2.1 AD DS（Active Directory Domain Services）ロールとは

Windows Serverは、様々な機能を「役割」として追加できる仕組みになっています。これは、スマートフォンにアプリをインストールするような感覚に似ています。

【Windows Serverの考え方】
新人：「Windows Server買ったらすぐAD使えるんですよね？」
先輩：「いや、それは違うよ」

（スマホに例えると）
新人：「スマホ買ったらLINE使えるんですよね？」
先輩：「LINEアプリをインストールしないと使えないでしょ？」
新人：「あ、そうか」
先輩：「Windows Serverも同じ。AD DS役割をインストールする必要がある」

役割（ロール）と機能（フィーチャー）の違いを理解しましょう。

【レストランに例えると】
オーナー：「新しくレストランを開きたい」

役割（主要な機能）：
- シェフ（料理を作る）→ AD DS（認証サービス）
- ウェイター（接客）→ Web Server（IIS）
- レジ係（会計）→ DHCP Server
- 店長（全体管理）→ DNS Server

機能（補助的な機能）：
- 包丁（料理の道具）→ .NET Framework
- 伝票（記録用）→ 管理ツール
- エプロン（身だしなみ）→ Windows Backup

オーナー：「必要な役割だけ雇えばいいのか」

AD DS役割の中身を見てみましょう。

【AD DSロールをインストールすると】
IT管理者：「AD DSロールには色んなコンポーネントが含まれています」

インストールされるもの：
1. Active Directory データベース（NTDS.dit）
   → 全ユーザー/コンピューター情報を保存
   
2. 認証サービス
   - Kerberos認証（KDC = Key Distribution Center）
   - NTLM認証
   - LDAP（Lightweight Directory Access Protocol）サービス

3. レプリケーションサービス
   → 複数DC間でデータ同期

4. グループポリシー処理エンジン
   → ポリシーの作成・配布

5. 管理ツール
   - Active Directory ユーザーとコンピューター
   - Active Directory サイトとサービス
   - グループポリシー管理

新人：「結構たくさん入ってるんですね」
IT管理者：「これら全部で『AD DS』という役割なんです」

インストールの流れを見てみましょう。

【実際のインストール作業】
IT管理者：「では、AD DSロールをインストールしてみましょう」

ステップ1：サーバーマネージャーを開く
画面：「ようこそ」
IT管理者：「管理 → 役割と機能の追加」

ステップ2：インストールの種類
選択肢：
- 役割ベースまたは機能ベースのインストール ← これを選択
- リモートデスクトップサービスのインストール

ステップ3：役割の選択
□ Active Directory Domain Services ← チェック
□ Active Directory Rights Management サービス
□ DHCP サーバー
□ DNS サーバー ← 通常は一緒にチェック
□ ファイルサービスおよび記憶域サービス
...

新人：「DNSも必要なんですか？」
IT管理者：「はい、第1章で説明した通り、ADにはDNSが必須です」

2.2.2 役割のインストールと昇格の違い

多くの初心者が混乱するポイントが、「役割のインストール」と「ドメインコントローラーへの昇格」の違いです。

【よくある勘違い】
新人：「AD DSロールのインストール完了！これでドメインコントローラーですね！」
先輩：「ちょっと待って、まだ半分だよ」
新人：「え？インストール終わったのに？」

（例えると）
新人：「医学部卒業しました！これで医者ですね！」
先輩：「いや、医師免許取らないと医者じゃないよ」
新人：「あ、そうか...」

役割インストール後の状態を確認してみましょう。

【インストール直後】
サーバー：「AD DSロールはインストールされました」
サーバー：「でも、私はまだただのメンバーサーバーです」
サーバー：「ドメインコントローラーになるには『昇格』が必要です」

確認方法：
IT管理者：「システムのプロパティを見てみましょう」
- コンピューター名：SERVER01
- ドメイン：WORKGROUP ← まだワークグループ！

新人：「本当だ、まだドメインじゃない」

昇格（Promotion）のプロセスを見てみましょう。

【DC昇格ウィザード】
IT管理者：「では、昇格を始めます」

サーバーマネージャーの通知：
「構成が必要です AD DS」← クリック

配置構成の選択：
○ 新しいフォレストを追加する ← 最初のDCならこれ
○ 既存のドメインにドメインコントローラーを追加する
○ 既存のフォレストに新しいドメインを追加する

新人：「フォレストって何ですか？」
IT管理者：「ADの最上位の管理単位です。会社全体みたいなもの」

昇格中に行われることを詳しく見てみましょう。

【昇格の裏側】
ウィザード：「ドメイン名を入力してください」
IT管理者：「jp.qualiteg.com」

ウィザード：「では、以下の作業を行います」

1. ADデータベースの作成
   場所：C:\Windows\NTDS\ntds.dit
   
2. SYSVOL フォルダーの作成
   場所：C:\Windows\SYSVOL
   用途：グループポリシーの保存

3. DNS ゾーンの作成
   - jp.qualiteg.com の正引きゾーン
   - 必要なSRVレコードの登録

4. Administrator アカウントの変換
   ローカル管理者 → ドメイン管理者

5. 各種サービスの起動
   - Kerberos Key Distribution Center
   - Intersite Messaging
   - DFS Replication

進行状況：
[■■■■■□□□□□] 50% 完了
「ADデータベースを作成しています...」

昇格完了後の確認をしましょう。

【再起動後の確認】
（自動的に再起動）
IT管理者：「昇格が完了しました。確認してみましょう」

システムのプロパティ：
- コンピューター名：DC01
- ドメイン：jp.qualiteg.com ← ドメインになった！

サービスの確認：
- Active Directory Domain Services：実行中
- DNS Server：実行中
- Kerberos Key Distribution Center：実行中

新人：「おお、本当にドメインコントローラーになった！」
IT管理者：「これでユーザー登録ができるようになりました」

2.2.3 必要な役割の組み合わせ

ADを中心とした環境では、複数の役割を組み合わせて使用することが一般的です。それぞれの組み合わせパターンを見ていきましょう。

【小規模環境（～50ユーザー）】
社長：「うちは小さい会社だから、サーバー1台で全部やりたい」
IT管理者：「それなら、オールインワン構成ですね」

SERVER01 に導入する役割：
□ AD DS（必須）
□ DNS Server（必須）
□ DHCP Server（強く推奨）
□ ファイルサービス（推奨）
□ 印刷とドキュメントサービス（必要に応じて）

社長：「1台で大丈夫？」
IT管理者：「50人程度なら問題ありません。ただし、バックアップは必須です」

中規模環境の構成も見てみましょう。

【中規模環境（50～500ユーザー）】
IT部長：「可用性を考えて、複数サーバーで構成したい」
IT管理者：「役割を分散させましょう」

推奨構成：
DC01（プライマリ）：
- AD DS
- DNS Server
- DHCP Server（プライマリ）

DC02（セカンダリ）：
- AD DS
- DNS Server  
- DHCP Server（セカンダリ）

FS01（ファイルサーバー）：
- ファイルサービス
- DFS（Distributed File System）

APP01（アプリケーション）：
- Web Server (IIS)
- アプリケーションサーバー

IT部長：「DCを2台にする理由は？」
IT管理者：「1台が故障しても、もう1台で認証できます」

DHCPフェールオーバーの設定も重要です。

【DHCP冗長化の会話】
ネットワーク担当：「DHCPサーバーが止まったら、新しいPCがIPもらえない」
IT管理者：「だから、DHCP フェールオーバーを設定します」

設定内容：
DC01 DHCP：192.168.1.100～192.168.1.199（50%）
DC02 DHCP：192.168.1.200～192.168.1.254（50%）

または

フェールオーバー モード：
- ロードバランス（通常時は50:50で分担）
- ホットスタンバイ（DC02は待機、DC01障害時に引き継ぎ）

ネットワーク担当：「これで安心だ」

大規模環境での役割設計も見てみましょう。

【大規模環境（500ユーザー以上）】
CTO：「全国に拠点があるので、それを考慮した設計を」
IT管理者：「拠点ごとにDCを配置し、役割も専用サーバーに分けます」

東京本社：
- DC-TKY-01, DC-TKY-02（AD DS + DNS）
- DHCP-TKY-01, DHCP-TKY-02（DHCP専用）
- FS-TKY-01, FS-TKY-02（ファイルサーバー）
- PRINT-TKY-01（プリントサーバー）

大阪支社：
- DC-OSA-01（AD DS + DNS）
- 東京のDHCPサーバーをDHCPリレーで利用

名古屋営業所：
- RODC-NGY-01（読み取り専用DC）

RODC（Read-Only Domain Controller）の説明をしましょう。

【小規模拠点でのRODC】
営業所長：「名古屋は5人しかいないけど、DCは必要？」
IT管理者：「RODCという選択肢があります」

RODCの特徴：
- ユーザー情報は読み取り専用（変更不可）
- パスワードはキャッシュのみ（全員分は保存しない）
- 物理的セキュリティが弱い拠点向け

営業所長：「盗まれても被害が限定的ということ？」
IT管理者：「その通りです。認証は高速化されますが、情報漏洩リスクは最小限」

役割の依存関係も理解しておきましょう。

【役割間の依存関係】
新人：「好きな役割を好きなサーバーに入れていいんですか？」
IT管理者：「いえ、依存関係があります」

必須の組み合わせ：
AD DS → DNS Server（必須）
理由：ADはDNSなしでは機能しない

推奨の組み合わせ：
AD DS + DNS + DHCP
理由：認証インフラはまとめた方が管理しやすい

避けるべき組み合わせ：
AD DS + Exchange Server + SQL Server + ファイルサーバー
理由：負荷が集中しすぎる

新人：「バランスが大事なんですね」

仮想化での考慮事項も重要です。

【仮想環境での役割配置】
仮想化担当：「全部仮想マシン（VM）でいいよね？」
IT管理者：「基本的にはOKですが、注意点があります」

推奨事項：
1. 少なくとも1台の物理DCを用意
   理由：仮想基盤障害時の復旧用

2. 仮想DCは異なる物理ホストに配置
   理由：物理ホスト障害の影響を限定

3. 時刻同期の設定に注意
   VM：「ホストと時刻同期します」
   IT管理者：「いや、DCは独自に時刻同期して」
   理由：Kerberos認証は時刻のズレに敏感

4. スナップショットは使わない
   仮想化担当：「バックアップはスナップショットで」
   IT管理者：「DCはスナップショット非推奨です」
   理由：USN（Update Sequence Number）ロールバックが発生する

2.3 DHCPの役割と設定

2.3.1 DHCPが配布する情報

DHCP（Dynamic Host Configuration Protocol）は、ネットワークに接続されたデバイスに必要な設定を自動的に配布するサービスです。

【DHCPがない世界】
月曜日の朝
新入社員A：「PCをネットワークにつなぎたいんですが」
IT担当：「はい、この設定をしてください」
- IPアドレス：192.168.1.101
- サブネットマスク：255.255.255.0
- デフォルトゲートウェイ：192.168.1.1
- DNSサーバー：192.168.1.10

新入社員A：「え、なんですかこれ...」

同じ日の午後
新入社員B：「私もPCを...」
IT担当：「えーっと、192.168.1.102で...」（また同じ説明）

新入社員C：「私も...」
IT担当：「もう無理！」

DHCPが配布する基本情報を見てみましょう。

【DHCP導入後】
新入社員：「PCをLANケーブルにつなぎました」
PC：「DHCPサーバーさん、設定ください！」（DHCPディスカバー）
DHCPサーバー：「はい、これをどうぞ」（DHCPオファー）

配布される情報：
1. IPアドレス：192.168.1.150
2. サブネットマスク：255.255.255.0
3. デフォルトゲートウェイ：192.168.1.1
4. リース期間：8時間

PC：「この設定でいいです」（DHCPリクエスト）
DHCPサーバー：「確認しました。使ってください」（DHCPアック）

新入社員：「もうネット使える！簡単！」
IT担当：「楽になった...」

DNSサーバー情報の重要性を理解しましょう。

【DNSサーバーの設定配布】
営業部員：「なんでDHCPでDNSサーバーの設定が重要なの？」
IT管理者：「実例で説明しましょう」

DHCPでDNSサーバーを配布しない場合：
PC：「IPアドレスもらった！192.168.1.150」
PC：「file-server.jp.qualiteg.com にアクセスしたい」
PC：「でも、DNSサーバーがわからない...名前解決できない」
ユーザー：「ファイルサーバーにつながらない！」

DHCPでDNSサーバーを配布する場合：
PC：「IPアドレスと一緒にDNSサーバー（192.168.1.10）ももらった」
PC：「file-server.jp.qualiteg.com は...DNSに聞こう」
DNS：「それは192.168.1.20です」
PC：「アクセス成功！」

オプション情報の配布も重要です。

【DHCP オプション】
IT管理者：「DHCPは基本情報以外にも、様々なオプション情報を配布できます」

よく使うオプション：
Option 003：ルーター（ゲートウェイ）
Option 006：DNSサーバー
Option 015：DNSドメイン名
Option 066：TFTPサーバー（PXEブート用）
Option 067：ブートファイル名

設定例：
IT管理者：「Option 015でドメイン名を配布してみましょう」
DHCPサーバー設定：
- Option 015: jp.qualiteg.com

結果：
PC：「ping file-server」（短縮名）
PC：「DNSサフィックス jp.qualiteg.com を自動付加」
PC：「ping file-server.jp.qualiteg.com として解決」

2.3.2 DNSサーバー情報の設定方法

DHCPでDNSサーバー情報を正しく配布することは、AD環境において極めて重要です。

【間違った設定の例】
新人管理者：「DHCPの設定完了しました！」
先輩：「DNSサーバーは何に設定した？」
新人：「ルーターのアドレス（192.168.1.1）です」
先輩：「それじゃダメだ！」

結果：
PC：「ドメインにログインしたい」
PC→ルーター：「jp.qualiteg.com のDCはどこ？」
ルーター：「知らない。インターネットで探してみる」
インターネットDNS：「そんなドメイン知らない」
PC：「ログインできない...」

正しい設定方法を見てみましょう。

【Windows Server DHCPでの設定】
IT管理者：「DHCPマネージャーを開いて設定します」

手順：
1. DHCPマネージャーを起動
2. サーバー → IPv4 → スコープ → スコープオプション

設定内容：
006 DNSサーバー：
  - 192.168.1.10（DC01）
  - 192.168.1.11（DC02）← 冗長性のため複数指定

015 DNSドメイン名：
  - jp.qualiteg.com

IT管理者：「必ずDCのIPアドレスを指定します」

ルーターのDHCP機能を使う場合の設定も見てみましょう。

【市販ルーターでの設定】
中小企業社長：「高いサーバー買わずに、ルーターのDHCP使えない？」
IT管理者：「使えますが、設定に注意が必要です」

ヤマハルーターの例：
dhcp scope 1 192.168.1.2-192.168.1.254/24
dhcp scope option 1 dns=192.168.1.10 192.168.1.11
dhcp scope option 1 domain=jp.qualiteg.com

バッファロールーターの例（GUI）：
詳細設定 → LAN → DHCPサーバー
- DNSサーバーの通知：手動設定
- プライマリDNS：192.168.1.10
- セカンダリDNS：192.168.1.11

重要：「ルーターのIPを通知」ではなく「手動設定」を選択！

優先順位の重要性も理解しておきましょう。

【DNS優先順位の影響】
IT管理者：「DNSサーバーは優先順位も重要です」

良い例：
プライマリDNS：192.168.1.10（DC01）
セカンダリDNS：192.168.1.11（DC02）

悪い例：
プライマリDNS：8.8.8.8（Google）
セカンダリDNS：192.168.1.10（DC01）

営業：「Google DNSの方が速いんじゃない？」
IT管理者：「社内の名前解決ができません」

実例：
PC：「file-server.jp.qualiteg.com はどこ？」
PC→Google DNS：「知らない」
PC：「じゃあ存在しないんだ」（セカンダリに聞かない）
結果：アクセス失敗

2.3.3 DHCPサーバーの配置（DC同居vs別サーバーvsルーター）

DHCPサーバーをどこに配置するかは、ネットワーク規模や管理方針によって決定します。

【配置パターンの比較】
経営層：「DHCPサーバーはどこに置くのがいい？」
IT管理者：「それぞれメリット・デメリットがあります」

パターン1：DCと同じサーバー（小規模向け）
メリット：
- サーバー台数が少なくて済む（コスト削減）
- 管理が一箇所で完結
- AD連携機能が使いやすい

デメリット：
- DCの負荷が増える
- DCトラブル時にDHCPも停止

パターン2：専用サーバー（中～大規模）
メリット：
- 負荷分散
- 独立した管理が可能
- DCトラブルの影響を受けない

デメリット：
- サーバー台数が増える（コスト増）
- 管理箇所が増える

パターン3：ルーターのDHCP機能（小規模）
メリット：
- 追加コストなし
- ハードウェアが安定
- 設定が簡単

デメリット：
- 高度な機能が使えない
- AD連携機能がない
- 詳細なログが取れない

実際の選択例を見てみましょう。

【小規模企業（20名）での選択】
社長：「うちは20人の会社だけど、どれがいい？」
IT管理者：「ルーターのDHCPで十分です」

構成：
- DC01：AD DS + DNS
- ルーター：DHCP機能（DNSはDC01を指定）

社長：「なぜルーターで十分なの？」
IT管理者：「20台程度なら、IPアドレス管理も簡単ですし、ルーターは24時間安定稼働しますから」

中規模企業での選択も見てみましょう。

【中規模企業（200名）での選択】
IT部長：「200人規模だと、どうすべき？」
IT管理者：「DCサーバーにDHCPも同居させ、冗長化します」

構成：
- DC01：AD DS + DNS + DHCP（アクティブ）
- DC02：AD DS + DNS + DHCP（スタンバイ）

DHCP フェールオーバー設定：
- モード：ホットスタンバイ
- DC01：通常時はすべて処理
- DC02：DC01障害時に自動引き継ぎ

IT部長：「専用サーバーにしなくていいの？」
IT管理者：「200人程度なら、最近のサーバーは余裕で処理できます」

大規模環境での考慮も見てみましょう。

【大規模企業（2000名）での選択】
CTO：「全国10拠点、2000名の環境ではどうする？」
IT管理者：「DHCP専用サーバーを地域ごとに配置します」

東京本社（800名）：
- DC-TKY-01, DC-TKY-02：AD DS + DNS
- DHCP-TKY-01, DHCP-TKY-02：DHCP専用（冗長化）

大阪支社（400名）：
- DC-OSA-01：AD DS + DNS
- DHCP-OSA-01：DHCP専用

その他拠点（各100名以下）：
- 各拠点のルーター：DHCPリレーで東京/大阪のDHCPを利用

CTO：「なぜ専用サーバー？」
IT管理者：「この規模だと、DHCPの負荷も大きく、詳細なログ分析も必要だからです」

DHCPリレーの説明をしましょう。

【DHCPリレーとは】
地方営業所長：「うちの営業所は5人だけど、DHCPサーバー必要？」
IT管理者：「DHCPリレーを使えば、本社のDHCPサーバーを使えます」

通常のDHCP（同一ネットワーク）：
PC：「設定ください！」（ブロードキャスト）
DHCPサーバー：「はい、どうぞ」

問題：
PC（営業所）：「設定ください！」（ブロードキャスト）
ルーター：「ブロードキャストは他のネットワークに転送しない」
DHCPサーバー（本社）：「聞こえない...」

DHCPリレー使用時：
PC（営業所）：「設定ください！」（ブロードキャスト）
ルーター：「DHCPリレー機能で本社のDHCPサーバーに転送」
DHCPサーバー（本社）：「営業所のPCですね。これをどうぞ」
ルーター：「PCに中継します」

営業所長：「なるほど、営業所にサーバー不要なんだ」

AD統合DHCPの利点も見てみましょう。

【Windows ServerでDHCPを使う利点】
開発者：「ルーターのDHCPで十分じゃない？」
IT管理者：「Windows ServerのDHCPには高度な機能があります」

1. 動的DNS更新の連携
PC：「IP 192.168.1.150 をもらいました」
DHCP：「DNSに登録しておきます」
DHCP→DNS：「PC-001 = 192.168.1.150 で登録して」
DNS：「登録しました」

2. MACアドレス予約
IT管理者：「社長のPCはいつも同じIPにしたい」
DHCP設定：
- MACアドレス：AA:BB:CC:DD:EE:FF
- 予約IP：192.168.1.100
結果：社長のPCは常に.100

3. ユーザークラス/ベンダークラス
IT管理者：「ノートPCとデスクトップで設定を変えたい」
- デスクトップ：リース期間8日
- ノートPC：リース期間8時間

4. 詳細な監査ログ
監査：「誰がいつどのIPを使ったか記録が必要」
DHCPログ：
2024-01-15 09:00:00, PC-001, 192.168.1.150, AA:BB:CC:DD:EE:FF

最後に、選択の指針をまとめましょう。

【DHCPサーバー配置の決定フロー】
IT管理者：「以下の質問で最適な配置を決めましょう」

Q1：ユーザー数は？
- 50名以下 → Q2へ
- 50-500名 → DC同居を推奨
- 500名以上 → 専用サーバー推奨

Q2：（50名以下の場合）AD連携機能は必要？
- 不要 → ルーターDHCP
- 必要 → DC同居

Q3：拠点数は？
- 1拠点 → 上記の推奨に従う
- 複数拠点 → 主要拠点にDHCP、他はリレー

Q4：可用性の要求は？
- 通常 → 単一DHCP
- 高い → DHCP冗長化（フェールオーバー）

新人：「これで適切な配置が決められますね」
IT管理者：「はい、ただし将来の成長も考慮してください」

まとめ

今回は、Active Directory環境構築の第一歩となるドメイン環境の構築について解説しました。

ドメイン名の設計では、かつて推奨されていた「.local」ドメインがmDNSとの競合やSSL証明書の取得不可などの問題を抱えていることを学びました。現在のベストプラクティスは、所有する公開ドメインのサブドメイン（例：jp.qualiteg.com）を使用し、スプリットDNSで内部と外部を分離する方法です。将来の拡張性も考慮し、最初から適切な命名規則を文書化しておくことが重要です。

Windows ServerへのAD DS役割のインストールと、ドメインコントローラーへの昇格は別のプロセスであることも理解しました。医学部を卒業しても医師免許が必要なように、役割をインストールしただけではDCにはならず、「昇格」という手順が必要です。

DHCPサーバーの配置については、企業規模に応じて最適な選択が異なります。小規模ならルーターのDHCP機能、中規模ならDCとの同居、大規模なら専用サーバーという指針を示しました。重要なのは、DHCPで配布するDNSサーバー情報を必ずDCのIPアドレスに設定することです。

次回予告

第3章では、いよいよクライアントPCとサーバーをドメインに参加させる手順を詳しく解説します。

「ドメイン参加」ボタンをクリックするだけ...と思いきや、実はその裏側では複雑な処理が行われています。コンピューターアカウントの事前作成は必要？ドメイン参加時の命名規則は？OUはどう設計する？Windows 10/11の参加手順の違いは？

さらに、「ドメイン参加できない！」というトラブルシューティングも実例を交えて解説。DNSの名前解決、時刻同期、ファイアウォールなど、つまずきやすいポイントと解決方法を会話形式でわかりやすくお伝えします。

次回も「社長も新人もわかる」をモットーに、実践的な内容をお届けします。お楽しみに！