Active Directory のデータベース NTDS.dit が肥大化すると、レプリケーション障害やディスク枯渇が心配になります。しかし「大きい＝すぐ危険」ではありません。本記事では、影響の整理から不要オブジェクト削除、オンライン／オフライン デフラグの使い分け、実務で失敗しない判断基準まで具体的に解説します。
最初に現状把握：増えているのは NTDS.dit か、ログか
「NTDS.dit が大きい」と感じたとき、まず確認したいのは 本当に NTDS.dit が増えているのか、それとも トランザクションログ（edb*.log）が増え続けているのか です。ディスク枯渇の直接原因がログ側だった、というケースは珍しくありません。
代表的な確認方法は次のとおりです（パスは環境により異なります）。
# NTDS フォルダーのサイズ内訳をざっと見る（例）
dir C:\Windows\NTDS
# PowerShell で大きい順に並べる（例）
Get-ChildItem $env:windir\NTDS |
Sort-Object Length -Descending |
Select-Object Name,@{n='MB';e={[math]::Round($_.Length/1MB,1)}}| ファイル（例） | 役割 | サイズが増える典型パターン | 見落としがちなポイント |
|---|---|---|---|
| NTDS.dit | AD DS のデータベース本体 | オブジェクト追加・属性更新の累積、内部空き領域の蓄積 | 削除してもすぐ縮まない（内部空き領域として残る） |
| edb.log / edbxxxxx.log | トランザクションログ | 変更が多い、バックアップが取れていない/失敗している | システム状態バックアップなどの成功でログが整理される設計が多い |
| edb.chk | チェックポイント | 通常は小さい | これ単体が増えるより、ログの増加を疑う |
| res1.log / res2.log | 予約ログ（緊急用） | 基本固定 | 削除・改変は避ける |
ログが異常に増え続けている場合は、NTDS.dit の圧縮より先に「バックアップが正常に回っているか」「ログ保存先の設計（DB/ログ分離）が適切か」を点検すると、停止作業なしで解決することがあります。
NTDS.dit が肥大化する仕組みを先に押さえる
NTDS.dit は Active Directory Domain Services（AD DS）が使うデータベースです。内部的には ESE（Extensible Storage Engine）というトランザクション型データベースで、ユーザー／コンピューター／グループ、OU、GPO の情報（正確にはそれらの属性）、AD 統合 DNS ゾーンのレコードなどが格納されます。
ポイントは、NTDS.dit の「ファイルサイズ」と「実データ量」は必ずしも一致しないことです。オブジェクトを大量に作成・変更するとデータベースは拡張されますが、その後に削除しても 空き領域はファイルの中に残る ことが多く、見た目のサイズがすぐに縮まるとは限りません。これは異常というより、ESE の設計上自然な挙動です。
| よくある状況 | NTDS.dit が増える主な理由 | すぐにやりがちな誤対応 | 正しい方向性 |
|---|---|---|---|
| 人事異動・入退社が多い | ユーザー作成・属性変更・グループ更新が多い | いきなりオフライン デフラグ | 棚卸し→不要オブジェクト削除→必要なら圧縮 |
| AD 統合 DNS のレコードが膨大 | 動的更新の蓄積、スカベンジ未実施 | DNS だけを見て AD を疑わない | DNS のエージング/スカベンジ＋不要ゾーン整理 |
| 削除が多いのにサイズが減らない | 内部空き領域として残り再利用される | 「壊れている」と判断 | オンライン保守の理解＋容量回収が必要ならオフライン圧縮 |
| 特定の DC だけサイズが極端に大きい | 内部空き領域の偏り、削除履歴、役割差、あるいは複製問題 | サイズだけで「同期不良」と決めつける | repadmin/dcdiag で健全性確認→必要なら再構築を含め検討 |
レプリケーションへの影響：サイズだけで判断しない
AD のレプリケーション（複製）は、基本的に「データベースファイルを丸ごと送る」仕組みではなく、変更（デルタ）を変更追跡情報にもとづいて転送します。そのため、既に稼働している DC 間のレプリケーションは、NTDS.dit が大きいだけで直ちに致命的になることは一般的には多くありません。
ただし、サイズ増大は “別のところ” で不利になりやすいのが実務の落とし穴です。特に次の場面は影響が表面化しやすいので、優先的に点検します。
| 影響が出やすい場面 | なぜ不利になるか | 現場で起きる困りごと | 対策の方向性 |
|---|---|---|---|
| 新規 DC の昇格（プロモーション） | 初回同期で多量のデータを取り込み、I/O と時間が増える | 昇格が長時間化、WAN 越しで失敗 | IFM（Install From Media）やサイト設計、不要データ削減 |
| バックアップ／復元（特にシステム状態） | バックアップ対象が増え、転送・保管・復元が重い | バックアップ時間が延びる、保管容量が逼迫 | 整理→容量回収（必要な場合のみ）→バックアップ設計見直し |
| ディスク空きが少ない DC | ログや一時ファイルで一気に枯渇しやすい | 更新失敗、サービス不安定化、再起動ループ | 空き容量確保、ログ/DB の分離、監視のしきい値設定 |
| 検索・認証が遅い/CPU 高騰 | サイズよりも I/O やメモリ、属性の使い方が効く | ログオン遅延、管理操作が重い | 性能診断（メモリ、ディスク、クエリ）、不要属性・不要同期の抑制 |
結論としては、「複製が遅いから、まずデフラグ」ではなく、複製・ディスク・バックアップ・運用のどこに課題があるかを切り分け、根本原因（不要オブジェクトや運用設計）を先に潰すのが最短です。
まずやるべきこと：AD 内の不要オブジェクトを整理する
サイズ削減を狙う場合でも、最初に取り組むべきは「削除してよいデータを減らす」ことです。オフライン デフラグはあくまで“圧縮手段”であり、増大要因が残ったままだと、数か月で元に戻ることが珍しくありません。
整理の優先度が高いオブジェクト例
- 長期間ログオンしていない休眠ユーザー、退職者アカウント
- 無効化されたまま放置されているユーザー／コンピューター
- 一時的な検証用 OU、過去プロジェクトのセキュリティグループ
- 誤って大量作成されたオブジェクト（スクリプト誤動作など）
- スカベンジされていない DNS 動的レコード（AD 統合 DNS の場合）
「削除したのに減らない」の背景：tombstone と AD ごみ箱
オブジェクトを削除すると、直ちに完全消去されるのではなく、一般に tombstone（墓石）、または AD ごみ箱（AD Recycle Bin）が有効な場合は 削除済みオブジェクト として一定期間保持されます。これは誤削除に備える設計で、期間が過ぎるとガベージコレクションにより最終的に除去されます。
この「保持期間」が長いほど、削除済みデータが残り続け、結果として NTDS.dit が大きく見えることがあります。もちろん、保持期間を短くする判断には復旧要件とのトレードオフがあるため、業務要件（誤削除から何日戻したいか）を先に決めることが重要です。
| 対応 | 何が起きるか | メリット | 注意点 |
|---|---|---|---|
| 無効化（disable） | オブジェクトは残り、属性も維持される | 復旧が簡単、監査上も追跡しやすい | DB サイズは基本増えたまま。棚卸しをしないと永遠に残る |
| 削除（delete） | 一定期間保持後に最終削除される（挙動は構成による） | 運用を回せば確実に減らせる | 保持期間中はすぐには減らない。誤削除リスクに備えた手順が必要 |
| 完全削除の運用を徹底 | 不要物を計画的に消し、内部空き領域を増やす | 長期的に DB の成長を抑えられる | 戻せない前提のため、承認フローとバックアップが必須 |
棚卸しに使える PowerShell の例
「何を消せばよいか」を人手で追うのは大変です。まずは候補を機械的に洗い出し、担当部署と合意しながら削除へ進めるのが安全です。
# 90日以上ログオンしていないユーザー（例）
Search-ADAccount -UsersOnly -AccountInactive -TimeSpan 90.00:00:00 |
Select-Object Name,SamAccountName,LastLogonDate,Enabled |
Sort-Object LastLogonDate
# 無効化されているユーザー
Get-ADUser -Filter 'Enabled -eq $false' -Properties LastLogonDate |
Select-Object Name,SamAccountName,LastLogonDate |
Sort-Object LastLogonDate
# 90日以上ログオンしていないコンピューター（例）
Search-ADAccount -ComputersOnly -AccountInactive -TimeSpan 90.00:00:00 |
Select-Object Name,LastLogonDate |
Sort-Object LastLogonDate重要なのは、抽出したリストをそのまま削除しないことです。例えば「共有端末用アカウント」「定期バッチ用サービスアカウント」など、ログオンしない前提のものが混ざります。例外の管理（除外 OU、命名規則、説明欄の必須化）をセットで整えると、以後の棚卸しの精度が上がります。
オンライン デフラグは自動で走るが、ファイルサイズは基本的に縮まらない
AD DS は定期的にガベージコレクション（内部メンテナンス）を行い、その一部としてオンライン デフラグ（オンライン最適化）も実施します。これにより データベース内部の空き領域が再利用されやすくなるため、削除や変更が多い環境では特に重要です。
一方で、オンライン デフラグの主目的は“内部の整理”であり、NTDS.dit のファイルサイズそのものを縮めてディスク容量を返すことではありません。ディスク容量として取り戻したい場合は、次に説明するオフライン デフラグ（コンパクション）が候補になります。
| 項目 | オンライン デフラグ（自動） | オフライン デフラグ（圧縮/コンパクション） |
|---|---|---|
| 目的 | 内部空き領域の整理・再利用性向上 | ファイルサイズを縮め、ディスク容量を回収 |
| 停止の有無 | 停止なし（サービス稼働中） | 停止が必要（DSRM 等） |
| 効果 | 性能改善や空き領域再利用に寄与 | サイズ減の効果が明確（ただし削減率は状況次第） |
| リスク | 低い | 手順ミスで復旧が難しくなる可能性。必ずバックアップと検証 |
| 実施頻度 | 自動（定期） | 必要時のみ（“容量回収”という要件がある時） |
オフライン デフラグ（コンパクション）をやるべきかの判断基準
「大きいから縮めたい」という気持ちは分かりますが、オフライン作業には停止とリスクが伴います。現場での判断は、次のように要件ベースで整理するとブレません。
| 状況 | オフライン デフラグの優先度 | 理由 | 代替案 |
|---|---|---|---|
| ディスク空きが逼迫し、増設がすぐにできない | 高い | 容量回収が直接効く | DB/ログの移動、不要データ削除、他 DC への役割分散 |
| DC を別サーバーへ移行し、容量を最適化したい | 中〜高 | 移行前に縮めるとバックアップや転送が楽 | demote/repromote、IFM での再構築 |
| 見た目は大きいが空き容量に余裕があり障害もない | 低い | 停止リスクに見合わない | オンライン保守＋定期棚卸しで運用改善 |
| 単一 DC 環境（冗長なし） | 要慎重 | 停止＝ドメイン停止になりやすい | まず冗長化を検討、移行計画と合わせて実施 |
実施前に必ず揃えるチェックリスト
- システム状態バックアップが直近で取得できている（復元手順も確認済み）
- 対象 DC を停止しても業務影響が限定的（複数 DC、サイト設計、FSMO 役割などを確認）
- オフライン圧縮用の作業領域に十分な空きがある（コンパクションは新規ファイルを作るため）
- 作業の前後で dcdiag / repadmin を実行し、レプリケーションが健全である
- 作業時間帯、ロールバック、関係者連絡（認証影響、DNS 影響）を手順に明記
オフライン デフラグ（圧縮）の代表的な流れ
具体的なコマンドは環境・バージョン・配置パスによって異なるため、ここでは「現場で外さない」ための流れを示します。慣れていない場合は、同一バージョンの検証環境で一連の動作確認を行ってから本番に適用してください。
作業の全体像
- 対象 DC のバックアップ（システム状態）を取得し、復元手順を確認する
- 他 DC が稼働していること、FSMO 役割が集中していないことを確認する
- DSRM（Directory Services Restore Mode）等のオフライン状態で起動する
- ntdsutil でデータベースをコンパクションし、新しい NTDS.dit を作成する
- 既存の NTDS.dit を退避し、コンパクション後ファイルへ置き換える
- 通常起動し、イベントログとレプリケーション健全性を確認する
コマンド例（概略）
以下は「どんな操作をするか」を掴むための概略例です。パスや実行方法は環境で異なるため、必ず自組織の標準手順に合わせてください。
ntdsutil
activate instance ntds
files
info
compact to D:\NTDS_Compact
quit
quitコンパクションは“新しいデータベースファイルを別場所に作る”形で進むため、作業先に十分な空き容量が必要です。置き換え後は、起動確認だけで終えず、次の章の dcdiag/repadmin で複製と整合性をチェックします。
demote/repromote で「結果的にサイズが整う」ケースもある
複数 DC があり、対象 DC を作り直しても問題ない場合、降格（demote）→再昇格（repromote）が結果的に最も簡単で安全なことがあります。再昇格時には、レプリケーションにより必要なデータが取り込まれるため、不要な空き領域を抱えた古いデータベースを引きずりにくいからです。
ただし、次の条件では難易度が上がります。
- 対象 DC が FSMO を保持している（事前に移動が必要）
- DNS、DHCP、証明書サービスなど他役割を併設している
- 単一 DC 環境、または拠点の唯一の DC で停止が許されない
| 手段 | メリット | デメリット | 向いている状況 |
|---|---|---|---|
| オフライン デフラグ | 容量回収が明確。役割は維持したまま実施可能 | 停止と手順リスク。作業領域が必要 | 容量回収が必須で、役割を変えずに最小変更で済ませたい |
| demote/repromote | “作り直し”で歪みを持ち込みにくい。手順が標準化しやすい | 役割移動や再設定が必要になる場合。業務影響が読みにくいことも | 複数 DC があり、対象 DC を再構築しても運用上問題が少ない |
健全性チェック：dcdiag / repadmin で見るべきポイント
NTDS.dit のサイズ議論は、レプリケーションが健全であることが前提です。作業前後の確認項目として、最低限次を押さえます。
| コマンド例 | 見たい観点 | 結果の読み方（例） |
|---|---|---|
repadmin /replsummary | 複製エラー率、遅延の傾向 | Fails が継続して出る、最大遅延が突出するなら原因調査を優先 |
repadmin /showrepl | 各パートナーごとの複製状態 | 特定相手だけ失敗するならネットワーク/サイト/名前解決/認証を疑う |
dcdiag /v | DC のヘルス（DNS 登録、サービス、広告など） | DNS 関連の警告が多い環境は、サイズより先に名前解決の整備が効く |
repadmin /queue | 複製キュー（未送信変更）の滞留 | キューが伸び続けるなら帯域不足やエラーの可能性が高い |
ここでエラーが出ている場合、オフライン デフラグを急ぐよりも、まず複製の根治（DNS、サイトリンク、FW、時刻同期、セキュアチャネル等）を優先してください。複製が壊れた状態で DB をいじると、復旧が難しくなるためです。
容量問題を再発させない運用のコツ
NTDS.dit の肥大化は「一度直して終わり」ではなく、日々の運用の積み重ねで差が出ます。最後に、現場で効きやすい再発防止策をまとめます。
アカウントのライフサイクルを決めて自動化する
- 退職・異動時のフローに「無効化→一定期間後に削除」を組み込む
- 説明欄（description）や管理者情報（managedBy）に棚卸しの責任者を残す
- 例外（サービスアカウント等）は専用 OU と命名規則で分離する
AD 統合 DNS を使っているなら、スカベンジ設計を見直す
動的更新が多い環境では、DNS レコードが増え続け、結果的に AD に格納されるデータ量も増えがちです。DNS のエージング/スカベンジを適切に設計し、不要レコードを自動的に掃除できるようにすると、長期的な肥大化を抑えやすくなります。
バックアップとログの関係も意識する
ディスクが苦しい現場では、NTDS.dit だけでなくトランザクションログが容量を押すことがあります。バックアップ運用が途切れるとログが残り続ける可能性があるため、監視は「NTDS.dit のサイズ」だけでなく、NTDS フォルダー全体（DB・ログ・チェックポイント）で見ると事故が減ります。
監視は「しきい値」と「伸び方」をセットで
- ディスク空き容量の絶対値（例：残り 15% 未満）
- 1日/1週間の増加率（急増はスクリプト誤動作や大量更新の兆候）
- レプリケーション遅延（repadmin /replsummary の傾向）
よくある質問
NTDS.dit が大きいだけで、レプリケーションが遅くなりますか？
「大きいから遅い」とは言い切れません。複製は変更分が主であり、ボトルネックはネットワーク帯域、DNS/サイト設計、エラーの有無、ディスク I/O、CPU/メモリなどにあることが多いです。まず repadmin で遅延と失敗を可視化し、原因を切り分けてください。
オンライン デフラグが走っているなら、オフラインは不要ですか？
ディスク容量を回収したい要件がなければ、不要なことが多いです。オンライン デフラグは内部空き領域の再利用性を高めるのが目的で、ファイルサイズを小さくする目的とは別です。「容量を返してほしい」時だけ、計画的にオフラインを検討します。
最短で安全にサイズを整理したい場合は？
複数 DC があり、対象 DC を作り直せるなら demote/repromote が有力です。一方、役割や依存関係が多く作り直しが難しいなら、バックアップと停止計画を揃えた上でオフライン デフラグを選びます。いずれにせよ、最初に不要オブジェクト削除と複製健全性の確認を行うことが成功の近道です。
コメント