はじめに
第9回は、Windows管理の代名詞とも言える グループポリシー（GPO） を取り上げます。
Linuxで数千台のサーバー設定を管理する場合、Ansible、Puppet、Chef、あるいは最近ではTerraformといった構成管理ツール（IaC）を使うのが一般的です。Windowsの世界では、それらが普及する遥か前から「GPO」という強力な一元管理メカニズムがOSにネイティブ実装されていました。
「設定ファイルが散らばっていて管理できない」というLinuxエンジニアの悩みを、Windowsがどう解決しているのかを解剖します。
1. GPOとは何か？（Linux構成管理との対比）
GPO（Group Policy Object）を端的に定義すると、「Active Directory（AD）内の特定オブジェクトに対して、レジストリ設定やセキュリティ権限を強制適用する仕組み」 です。
Linuxエンジニアの感覚に翻訳すると、以下のようになります。
| 比較項目 | Linux (Ansible等) | Windows (GPO) |
|---|---|---|
| 方式 | プッシュ型（SSH経由） | プル型（クライアントがSMB経由でDCのSYSVOLを参照・取得） |
| 定義ファイル |
.yml, .conf
|
ADMX / ADML（XMLベースの管理用テンプレート） |
| 適用タイミング | コマンド実行時 | OS起動時 / ログオン時 / 90〜120分間隔（ランダムオフセットあり） |
| 構成の維持 | 定期的なPlaybook実行が必要 | OSが自動で再適用（構成ドリフトを自動修正） |
補足： GPOのプル間隔はデフォルト90分＋0〜30分のランダムオフセットです。すべてのクライアントが同時にDCへ問い合わせてアクセスが集中するのを防ぐ設計になっています。
2. 優先順位の鉄則：「LSDOU」を覚えよう
GPOには複数の設定が重なった場合の強力な優先ルールがあります。これを LSDOU と呼びます。Linuxの変数オーバーライド（例：Ansibleの group_vars vs host_vars）に近い考え方です。
- L (Local): ローカルグループポリシー（そのマシン自身の個別設定）
- S (Site): Active Directoryの「サイト」（物理的な拠点単位）
- D (Domain): ドメイン全体
- OU (Organizational Unit): 組織単位（もっとも細かい区分）
後から適用されるものが優先（上書き） されます。つまり、OUに紐付けられた設定が、ドメイン全体の設定を上書きします。「最後に書いたものが勝つ」Ansibleの変数優先度と同じ考え方です。
ポイント：
セキュリティ設定を「ドメイン全体（D）」にかけると、全サーバーに影響が出てしまいます。Linuxで特定のホストグループだけに設定を当てるように、Windowsでも「サーバー用OU」や「端末用OU」を作成し、そこに適切なGPOをリンクさせるのが定石です。
応用：「適用しない（ブロック継承・強制）」
- Block Inheritance：子OU側で「上位のGPOを無視する」設定。特定部署だけ別ポリシーを適用したい場合に使います。
- Enforced（No Override）：親GPO側で「下位に上書きさせない」設定。セキュリティ基準をどのOUにも例外なく徹底させたい場合に使います。
3. 設定の実体はどこにあるのか？
Linuxエンジニアが最も気になるのは「その設定データはどこに保存され、どう流れるのか？」でしょう。
管理用テンプレート（ADMXファイル）
GPOの設定項目（「パスワードの長さを14文字にする」など）の定義は、/etc のようなテキストではなく、ADMX というXMLファイルに記述されています。これは単なる「GUIエディターのUIを生成するための型紙（スキーマ定義）」であり、設定の実体ではありません。ADMLは言語ファイルで、UIの表示テキストを多言語化する役割を持ちます。
C:\Windows\PolicyDefinitions\ ← ADMXファイル（設定スキーマ）
C:\Windows\PolicyDefinitions\ja-JP\ ← ADMLファイル（日本語表示テキスト）
SYSVOLフォルダ
実際のGPOの設定内容は、ドメインコントローラー（DC）内の SYSVOL と呼ばれる共有フォルダに保存されます。
\\<ドメイン名>\SYSVOL\<ドメイン名>\Policies\{GPO-GUID}\
├── Machine\ ← コンピューター設定
└── User\ ← ユーザー設定
クライアントはSMBプロトコル経由でSYSVOLを参照し、自身のバージョン番号（CSEバージョン）と比較して変更があればダウンロード・適用します。SYSVOLはDC間でDFSレプリケーションにより自動同期されるため、複数のDCが存在する環境でも設定の一貫性が保たれます。
レジストリへの書き込み
最終的に、GPOで指定された設定はクライアントのレジストリに書き込まれます。レジストリはWindowsが設定・状態情報を永続化するための階層型データベースで、HKLM\Software\Policies\ 以下がGPOの書き込み先として使われます。
# GPOが書き込むキーの例（管理用テンプレート設定）
HKLM\SOFTWARE\Policies\Microsoft\Windows\
HKCU\SOFTWARE\Policies\Microsoft\
Linuxで例えるなら、/etc/ 以下に設定ファイルを書き込むイメージに近いです。ただし、レジストリはバイナリ形式の一元管理データベースであるため、直接テキストエディタで編集することはできません。
4. 実践：エンジニアのためのGPOデバッグ
「設定が反映されない！」というトラブルは、Windows管理で最も多い問題の一つです。Linuxで ansible-playbook --check を叩くように、以下のコマンドを使いこなしましょう。
設定を即座に反映させる（gpupdate）
デフォルトでは90〜120分の間隔で反映されますが、テスト時は待っていられません。
# 設定を今すぐ同期する（Linuxの systemctl reload に近い）
gpupdate /force
# コンピューター設定のみ（ユーザー設定は除外）
gpupdate /force /target:computer
# ユーザー設定のみ
gpupdate /force /target:user
適用状況を調査する（gpresult）
どのポリシーが適用され、どれが競合で除外（Filtered/Not Applied）されたのかを確認します。
# 適用されているGPOのサマリーを表示
gpresult /R
# 詳細なHTMLレポートを生成してブラウザで確認
gpresult /H C:\temp\gpreport.html
# 別ユーザーの適用状況を確認（管理者権限が必要）
gpresult /R /user <ドメイン>\<ユーザー名>
gpresult /R の出力には以下のセクションが含まれます。
| セクション | 内容 |
|---|---|
| Applied GPOs | 実際に適用されたGPO一覧 |
| Denied GPOs | リンクはあるが適用されなかったGPO（フィルタリング等の理由付き） |
| The following GPOs were not applied | 空（設定なし）のため処理されなかったGPO |
よくあるトラブルシュート：
- 設定が反映されない →
gpupdate /force後にgpresult /Rで "Applied GPOs" に目的のGPOがあるか確認 - 意図しない設定になる →
gpresult /Hの詳細レポートで「どのGPOがどの設定を書いたか」を確認 - DCへの接続 →
nltest /dsgetdc:<ドメイン名>で認識しているDCを確認
おわりに
GPOは、数千台のWindowsマシンを「一瞬で一貫したセキュリティ状態にする」ための強力な仕組みです。しかし、一度設定を誤れば、一瞬で全マシンのログインを不可能にするリスクも秘めています。
LinuxエンジニアがAnsibleのコードをGitで管理するように、Windows管理においてもGPOのバックアップと変更管理を徹底することが、要塞化の第一歩となります。
# GPOをバックアップする（変更前に必ず実行）
Backup-GPO -All -Path C:\GPOBackup\
# 特定のGPOだけバックアップ
Backup-GPO -Name "セキュリティベースライン" -Path C:\GPOBackup\
今回の「エンジニアの知恵」
WindowsのGUI（グループポリシー管理エディター）で設定できる項目は数千ありますが、実は 「基本設定（Group Policy Preferences）」 を使えば、Linuxの ln -s のようなショートカット（シンボリックリンク相当）の作成や、ファイル・レジストリの配布といった「よりAnsibleに近い」柔軟な操作も可能です。
通常のGPO設定との大きな違いは、ユーザーがローカルで上書きできる点です。「強制はしないが、デフォルト値を配布したい」という用途に向いています。