グループポリシー(GPO)実務入門 ── 仕組み・反映確認・Intuneとの使い分け

小村 豪

doi:10.5281/zenodo.22054221

グループポリシー(GPO)実務入門 ── 仕組み・反映確認・Intuneとの使い分け

2026年08月01日 01:00 · 更新日: 2026年09月07日 · 小村豪 · Windows, グループポリシー, Active Directory, Intune, PC管理, PowerShell, 情報システム

更新履歴(8件・最終更新 2026年09月07日)

この記事に加えた変更の記録です。アーカイブした更新前のバージョンは、DOI付きの固定URLから読めます。

2026年09月07日: 専用キー外に残るレジストリ値とポリシー専用キーの違いが明確になるよう、比較の1文を言い換えた。更新前のバージョンを見る (DOI: 10.5281/zenodo.22637444)
2026年09月07日: グループポリシーの主張と例外を維持し、症状別の案内、適用対象と優先順位、反映時期と確認結果、テンプレート管理とIntune併用の判断を追いやすく整理した。
2026年08月22日: 知識マップの関係を総点検し、説明文と食い違っていた関係(向きの逆転・過剰な一般化・述語の取り違え)を修正しました。本文の説明は変えていません。
2026年08月22日: 知識マップの関係を総点検し、説明文と食い違っていた関係(向きの逆転・過剰な一般化・述語の取り違え)を修正しました。本文の説明は変えていません。
2026年08月22日: 知識マップの関係を総点検し、説明文と食い違っていた関係(向きの逆転・過剰な一般化・述語の取り違え)を修正しました。本文の説明は変えていません。
2026年08月22日: 知識マップの関係を総点検し、説明文と食い違っていた関係(向きの逆転・過剰な一般化・述語の取り違え)を修正しました。本文の説明は変えていません。
2026年08月22日: 知識マップの関係を総点検し、説明文と食い違っていた関係(向きの逆転・過剰な一般化・述語の取り違え)を修正しました。本文の説明は変えていません。
2026年08月21日: 仕組みの説明を図で追えるよう、Mermaid図を20点追加しました。ワークグループとドメイン参加の違い、GPOの2系統、LSDOUの処理順序と後勝ち、リンク順、継承のブロックと強制、セキュリティフィルターの適用判定とグループ変更の反映タイミング、ループバック処理、DCへの到達可否と設定が反映される経路、RSoPレポートとGroupPolicy運用ログの確認手順、ポリシー値とアプリ設定の優先関係、切り分け手順、セントラルストアの仕組みと更新手順、GPOとIntuneの使い分けとGroup Policy analyticsでの仕分け、客先GPOがアプリの前提を変える構図と開発側の備えを図にしています。本文の文章とコード、参考リンクは変えていません。
2026年08月01日: 初版公開

この記事を引用する(DOI: 10.5281/zenodo.22054221)

この記事はZenodoにアーカイブされています。常に最新版へ解決されるDOIと、いま表示している版に固定されたDOIの両方を下に示します。

小村豪(2026)「グループポリシー(GPO)実務入門 ── 仕組み・反映確認・Intuneとの使い分け」合同会社小村ソフト. https://doi.org/10.5281/zenodo.22054221 https://comcomponent.com/blog/group-policy-practical-guide/

DOI(最新版): 10.5281/zenodo.22054221
DOI(この版): 10.5281/zenodo.22637689

「GPOを変えたのに反映されない」「gpupdateを実行しても設定が変わらない」「開発機では動くアプリが、客先のPCでだけ動かない」。こうした問題は、どのGPOが対象になり、どの設定が優先され、いつ処理されたかを分けると調べやすくなります。

グループポリシーは、Windowsの設定を組織で配布・管理する仕組みです。「GPOで配ってある」という説明だけでは、そのPCやユーザーに何が効いているかまでは分かりません。設定を配る側の構成と、受け取った側の結果を突き合わせる必要があります。

本記事は、AD環境を引き継いだ中小企業の情シス担当者と、ドメイン参加PCへ業務アプリを導入する開発者に向けた実務入門です。適用順序、反映のタイミング、gpresultとイベントログによる切り分け、ADMXとセントラルストア、Intuneとの使い分けを整理します。説明は2026年8月時点の一次情報にもとづきます。

困っていることから読む

困っていること	最初に確認すること	読む箇所
GPOやADの管理を引き継いだ	ローカルとドメイン、PCとユーザーの違い	GPOの基本
ローカルで直した設定が元に戻る	LSDOUの処理順と、競合時に勝つGPO	優先順位と継承
特定の人・PCだけ適用されない	フィルターの権限と、グループ変更の反映	セキュリティフィルター
gpupdate /forceでも変わらない	DCへの到達可否と、前景処理が必要な設定	反映のタイミング
どこで失敗しているか分からない	適用・拒否・優先するGPOを順に見る	反映確認と切り分け
ポリシーをやめたのに値が残る	ポリシー専用キーか、その外への書き込みか	レジストリとの関係
管理端末によって設定項目が違う	ADMX/ADMLとセントラルストアの参照先	テンプレート管理
社外端末の管理やIntune併用を考えている	端末の基盤・所在と、設定の管理主体	管理手段の判断表
客先でだけ業務アプリが動かない	実行ポリシー・ファイアウォール・実行アカウント	開発者の確認事項

初めて読む場合は、2章で用語を押さえ、3〜4章で仕組みを理解してから5章の確認手順へ進んでください。調査中なら5章を起点にし、結果に応じて優先順位や反映時期の説明へ戻れます。

1. まず結論

「どの設定が勝つか」と「いつ届くか」は別の問題

グループポリシーは、ローカル→サイト→ドメイン→OU(LSDOU)の順に処理され、同じ設定が競合したら後勝ちです。ローカルGPOは最も弱い層になります。ただし、継承のブロックや強制によって既定の流れは変わります。¹

反映は、起動時・サインイン時の前景処理と、既定約90分+0〜30分のランダムオフセットによるバックグラウンド更新の二本立てです。ドメインコントローラーの背景更新は既定5分です。gpupdate /force は全設定の再適用であり、サインインや再起動でしか処理されない設定まで、その場で反映する万能コマンドではありません。²³

変更を繰り返す前に、受け取った結果を確認する

切り分けの起点は gpresult /h のRSoPレポートです。適用されたGPO、拒否されたGPOと理由、設定ごとの「優先するGPO」を確認します。処理の失敗や遅延を深掘りするときは、GroupPolicy運用ログを使います。⁴⁵

管理用テンプレートの設定は、原則としてレジストリの Software\Policies などに書かれ、ポリシー対応アプリはその値を独自設定より優先します。「未構成」は値を書きません。ただし、専用キーの外へ書き込む設定もあるため、値が残る場合は書き込み先まで確認します。⁶

管理方法と、アプリが依存する前提をそろえる

ADMXの定義は、ドメイン運用ではSYSVOLの PolicyDefinitions セントラルストアへ集約します。GPMCが共通のテンプレートを参照するための仕組みです。⁷

GPOとIntuneは、端末のアイデンティティ基盤と所在に合わせて使い分けます。ハイブリッド環境では、同じ設定の二重構成を避け、領域ごとに管理主体を決めます。移行の仕分けにはGroup Policy analyticsが使えます。⁸⁹

開発者にとってもGPOは環境仕様の一部です。実行ポリシー、ファイアウォールのローカル規則マージ、プロキシやドライブ構成など、アプリの前提を変える設定が集中配布されます。「客先でだけ動かない」ときは、その前提をレポートと実値で確認します。¹⁰¹¹

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全29件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. グループポリシーとは何か ── ローカルGPOとドメインGPO

グループポリシーは、管理者がWindowsの設定を集中定義し、対象のコンピューターやユーザーへ適用する仕組みです。設定のかたまりを GPO(グループポリシーオブジェクト) と呼びます。

最初に、「そのPCの中で管理するローカルGPO」と「ADから配布するドメインGPO」を分けます。

設定の置き場所: ローカルか、ドメインか

	ローカルGPO	ドメインGPO
編集ツール	gpedit.msc(ローカルグループポリシーエディター)	GPMC(グループポリシー管理コンソール)+グループポリシー管理エディター
保存場所	そのPC自身。コンピューター向けは1つだが、ユーザー向けは「管理者/非管理者/特定ユーザー別」の複数ローカルGPO(MLGPO)も作れる¹²	Active Directory(サイト・ドメイン・OUにリンクして配布)
適用範囲	そのPCだけ	リンク先の配下にあるコンピューター/ユーザー全体
優先順位	最も弱い(ドメインGPOに上書きされる)¹	ローカルより強い。ドメインGPO同士はリンク先とリンク順で決まる
典型的な用途	ワークグループPC・検証機の単体設定	組織の標準設定の配布・強制

ワークグループ(ドメイン非参加)のPCが処理するのはローカルGPOだけです。¹ つまり「GPOで管理されている」と言うとき、実務上はほぼドメインGPOを指しています。

flowchart TB
    accTitle: ワークグループPCとドメイン参加PCが処理するGPO
    accDescr: ワークグループのPCが処理するのはローカルGPOだけであり、ドメイン参加PCはローカルGPOに加えてActive Directoryから配布されるドメインGPOも処理する
    pc{"PCの参加形態は?"}
    pc -->|ワークグループ| wg["ローカルGPOのみ処理"]
    pc -->|ドメイン参加| dom["ローカル+ドメインGPO"]
    dom -.-> note["実務のGPOはほぼドメインGPO"]

図1: ワークグループPCはローカルGPOだけを処理し、ドメイン参加PCはドメインGPOも処理する。

設定の対象: PCか、ユーザーか

どのGPOにも、中身は大きく2系統あります。

コンピューターの構成: そのPCにサインインする誰に対しても効く設定。起動時に適用されます。
ユーザーの構成: そのユーザーがどのPCにサインインしても効く設定。サインイン時に適用されます。

「PCに紐づく設定か、人に紐づく設定か」という軸は、このあとの適用順序でも反映確認でも一貫して登場します。同じ項目が両方の構成に存在する設定もあるので、設定を探すときは必ず両方の系統を見る癖をつけてください。

flowchart TB
    accTitle: GPOの中身の2系統
    accDescr: どのGPOにもコンピューターの構成とユーザーの構成の2系統があり、コンピューターの構成は起動時に適用されてそのPCにサインインする誰にでも効き、ユーザーの構成はサインイン時に適用されてそのユーザーがどのPCにサインインしても効く
    gpo["GPOの中身"] --> comp["コンピューターの構成"]
    gpo --> user["ユーザーの構成"]
    comp --> boot["起動時に適用"]
    user --> logon["サインイン時に適用"]
    boot -.-> anyone["サインインする誰にでも効く"]
    logon -.-> anypc["どのPCでも効く"]

図2: GPOにはPCに紐づくコンピューターの構成と、人に紐づくユーザーの構成の2系統がある。

3. 適用の仕組み ── LSDOUの「後勝ち」と継承の制御

3.1. LSDOU: ローカル→サイト→ドメイン→OU

ドメイン参加PCでは、GPOは次の順序で処理されます。¹

ローカルGPO
サイトにリンクされたGPO
ドメインにリンクされたGPO
OU(組織単位)にリンクされたGPO ── 上位のOUから順に処理され、最後に対象のコンピューター/ユーザーが直接所属するOUのGPOが処理される

頭文字を取った呼び名が LSDOU です。これは「優先順位の高い順」ではなく、処理する順序を表しています。

同じ設定を複数のGPOが構成していると、後から処理されたGPOが勝ちます。競合しない設定は単純に足し合わされます。¹

この既定の順序では、対象に最も近いOUのGPOが強く、ローカルGPOが最も弱くなります。「gpedit.mscで直したのに元へ戻る」のは、この仕様どおりの動作です。継承を変える例外は3.2節で確認します。

flowchart TB
    accTitle: LSDOUの処理順序と後勝ち
    accDescr: GPOはローカル、サイト、ドメイン、OUの順に処理され、競合時は後から処理されたGPOが勝つため、対象に近いOUのGPOが最も強くローカルGPOが最も弱い
    l["1. ローカルGPO"] --> s["2. サイト"]
    s --> d["3. ドメイン"]
    d --> ou["4. OU（上位から順に）"]
    ou --> win["競合時は後勝ち"]
    win -.-> strongest["対象に近いOUのGPOが最強"]
    win -.-> weakest["ローカルGPOが最弱"]

図3: LSDOUは処理される順であり、同じ設定が競合したときは後から処理されたGPOが勝つ。

同じ場所では、リンク順の小さい番号が勝つ

同じサイト・ドメイン・OUに複数のGPOがリンクされている場合は、GPMCの「リンクされたグループポリシーオブジェクト」タブにあるリンク順を確認します。

番号が最も小さいGPOが最後に処理され、最も優先されます。「小さい番号だから先に処理される」と読まないことが重要です。¹

flowchart TB
    accTitle: 同じ場所に複数のGPOがある場合のリンク順
    accDescr: 同じサイトやドメインやOUに複数のGPOがリンクされている場合はGPMCのリンク順で処理順が決まり、番号が最も小さいGPOが最後に処理されて最も優先される
    multi["同じ場所に複数のGPO"] --> tab["GPMCのリンク順で決まる"]
    tab --> last["番号最小のGPOが最後に処理"]
    last --> win["後勝ちで最も優先される"]

図4: 同一のリンク先では、リンク順の番号が最も小さいGPOが最後に処理されて勝つ。

3.2. 継承のブロックと強制(Enforced)

継承のブロックと強制は、3.1節の既定の順序に例外を作る仕組みです。どこに設定するかと、何を止めるかを分けて読みます。¹

継承のブロック: ドメインやOUに設定すると、上位からのGPOの継承を止められます。「このOUだけは全社標準を受けたくない」場合の道具です。
強制(Enforced、旧称: 上書き禁止): GPOのリンクに設定すると、そのGPOは下位で継承ブロックされていても必ず適用され、下位のGPOに上書きされなくなります。継承ブロックと強制が衝突したときは強制が勝ちます。¹

flowchart TB
    accTitle: 継承のブロックと強制の関係
    accDescr: 継承のブロックは上位からのGPOの継承を止めるが、強制されたGPOは下位で継承ブロックされていても必ず適用され、下位のGPOにも上書きされない
    upper["上位からのGPO"] --> blocked{"下位で継承ブロック?"}
    blocked -->|いいえ| inherit["そのまま継承される"]
    blocked -->|はい| enforced{"GPOに強制の設定?"}
    enforced -->|いいえ| stop["継承が止まる"]
    enforced -->|はい| apply["必ず適用される"]
    apply -.-> noover["下位のGPOに上書きされない"]

図5: 継承のブロックは上位からの継承を止めるが、強制されたGPOはブロックを越えて必ず適用される。

強制は、使う目的を限定する

強制は既定の「後勝ち」を変えるため、多用するとRSoPを読んでも直感と合わない結果が増えます。全社で必ず守らせたいセキュリティ設定などに限定するのが定石です。

ここまでが継承と優先順位の話です。対象にGPOを適用できるかどうかは、次のセキュリティフィルターでも確認します。

3.3. セキュリティフィルター処理

適用には「読み取り」と「適用」の両方が必要

リンク先だけでなく、誰に適用するかもGPO単位で絞れます。対象のユーザーまたはコンピューターが、そのGPOに対して「読み取り」と「グループポリシーの適用」の両方のアクセス許可を持っていることが必要です。¹³

既定では、ユーザーとコンピューターの両方を含むAuthenticated Usersに両許可があるため、リンク先の配下全員が対象になります。これを特定のセキュリティグループへ絞るのが、セキュリティフィルター処理です。

フィルターはGPO全体に効きます。GPO内の設定ごとに、別々の対象へ絞る仕組みではありません。¹³

ユーザー向けGPOでは、PCの読み取り権限も残す

対象を絞るときは、Authenticated Usersから「読み取り」まで外さないようにします。MS16-072(2016年)以降、ユーザー向けポリシーはコンピューターのセキュリティコンテキストで取得されるためです。PCがGPOを読めなければ、対象ユーザーに両許可があっても適用されません。¹⁴

必要な許可は、次の二つに分けて考えます。

対象グループには、読み取り+グループポリシーの適用を与える。
Authenticated Users、またはDomain Computersには、読み取りだけを残す。「適用」の許可は不要です。¹⁴

flowchart TB
    accTitle: セキュリティフィルターの適用判定
    accDescr: GPOが適用されるには対象のユーザーまたはコンピューターが読み取りとグループポリシーの適用の両許可を持つ必要があり、ユーザー向けGPOはさらにコンピューターアカウントが読み取れることが必要になる
    target["GPOのリンク先配下の対象"] --> perm{"読み取りと適用の両許可?"}
    perm -->|いいえ| deny["フィルターで拒否"]
    perm -->|はい| usergpo{"ユーザー向けGPO?"}
    usergpo -->|いいえ| apply["適用される"]
    usergpo -->|はい| comp{"コンピューターが読み取り可?"}
    comp -->|はい| apply
    comp -->|いいえ| deny2["適用されない（MS16-072）"]

図6: 適用には「読み取り」と「グループポリシーの適用」の両方が要り、ユーザー向けGPOではコンピューターアカウントの読み取りも必要。

グループを変えた後は、新しいトークンで確認する

「コンピューター向け設定なのにユーザーだけをグループへ入れた」という対象の取り違えは、よくあるつまずきです。まず、設定がPC向けかユーザー向けかを確認します。

もう一つが、「グループから外したのに適用され続ける」という問題です。メンバーシップはサインイン時に作られたセキュリティトークンで評価されるため、バックグラウンド更新を待つだけでは変わりません。

ユーザーのグループ変更はサインアウト→サインイン、コンピューターの変更は再起動で新しいトークンになってから、フィルターへ反映されます。

flowchart TB
    accTitle: グループ変更がフィルターに反映されるまで
    accDescr: グループメンバーシップはサインイン時に作られたセキュリティトークンで評価されるため、ユーザーの変更はサインインし直し、コンピューターの変更は再起動で新しいトークンになって初めてフィルターに反映される
    change["グループのメンバーを変更"] --> old["古いトークンのままでは未反映"]
    old --> u["ユーザーはサインインし直し"]
    old --> c["コンピューターは再起動"]
    u --> token["新しいトークンで評価"]
    c --> token
    token --> ok["フィルターに反映"]
    old -.-> bg["バックグラウンド更新では解消しない"]

図7: グループ変更はサインアウトや再起動で新しいトークンが作られて初めてフィルターに反映される。

共有PCの応用: ループバック処理

共有PCやリモートデスクトップサーバーでは、「そのPCにサインインする人全員に、ユーザーの構成を差し替えたい」場合があります。そのための特殊モードがループバック処理です。

コンピューターの場所にもとづいてユーザー設定を適用し、置換とマージの2モードがあります。キオスク端末や教室PCで使う応用機能で、本記事では存在の紹介にとどめます。¹⁵

flowchart TB
    accTitle: ループバック処理の考え方
    accDescr: ループバック処理はコンピューターの場所にもとづいてユーザーの構成を適用する特殊モードで、置換とマージの2モードがあり、共有PCやキオスク端末などサインインした人全員に同じユーザー設定を効かせたい場面で使われる
    shared["共有PC・キオスク端末など"] --> lb["ループバック処理"]
    lb --> base["コンピューターの場所で決める"]
    base --> rep["置換モード"]
    base --> mrg["マージモード"]
    lb -.-> aim["サインインした全員に効く"]

図8: ループバック処理はコンピューターの場所にもとづいてユーザーの構成を適用する特殊モードで、置換とマージの2モードがある。

4. いつ反映されるか ── 前景処理とバックグラウンド更新

設定を変更しても、適用タイミングがまだ来ていない場合があります。ここでは、端末がDCへ接続できるかと、その設定がどのタイミングで処理されるかを分けます。²

起動・サインイン時と、稼働中の更新を分ける

種類	タイミング	対象
前景(フォアグラウンド)処理	コンピューターの構成: 起動時/ユーザーの構成: サインイン時	すべての設定
バックグラウンド更新	既定で約90分ごと+0〜30分のランダムオフセット(全端末が一斉に取りに来ないようずらされる)	バックグラウンド処理に対応する設定のみ
バックグラウンド更新(ドメインコントローラー)	既定で5分ごと	同上

まず、DCへ到達できることが前提

ドメインコントローラーに到達できる稼働中の端末なら、バックグラウンド更新に対応する設定は、既定では2時間程度で行き渡ります。オフライン端末やVPN未接続の持ち出しPCには、次にDCへつながるまで届きません。

前景処理でしか適用されない設定は、さらに起動やサインインを待つ必要があります。

gpupdateと/forceの違い

急ぐ場合は対象PCで gpupdate を実行します。通常は変更された設定だけを適用し、/force を付けると、変更の有無にかかわらず全設定を再適用します。³

rem 変更分のみ更新(通常はこれで十分)
gpupdate

rem 全設定を再適用(キャッシュ済みの状態を疑うとき)
gpupdate /force

flowchart TB
    accTitle: DCへの到達可否と反映の届き方
    accDescr: ドメインコントローラーに到達できる稼働中の端末にはバックグラウンド更新に対応する設定が2時間程度で行き渡るが、オフラインやVPN未接続の持ち出しPCには次にDCへつながるまで届かない
    pc{"DCに到達できる?"}
    pc -->|はい| ok["2時間程度で行き渡る"]
    pc -->|いいえ| ng["つながるまで届かない"]
    ng -.-> ex["オフラインやVPN未接続の持ち出しPC"]

図9: DCに到達できる稼働中の端末には2時間程度で行き渡るが、オフラインの端末には次にDCへつながるまで届かない。

/forceでも、前景処理は省略できない

ユーザー向けのソフトウェアインストールとフォルダーリダイレクトはサインイン時、コンピューター向けのソフトウェアインストールは起動時にしか処理されません。³

gpupdate の /logoff は更新後のサインアウト、/boot は更新後の再起動を行うためのオプションです。/force を付けても変わらないときは、その設定がサインインや再起動を必要とする種類かを確認してください。³

flowchart TB
    accTitle: 設定が反映される経路
    accDescr: GPOの変更はバックグラウンド更新対応の設定なら既定約90分と0〜30分のオフセットで届き、前景処理でしか適用されない設定は起動やサインインを待つ必要があり、急ぐ場合のgpupdateにも前景処理用の設定には/logoffや/bootが要る
    change["GPOを変更"] --> kind{"バックグラウンド更新に対応?"}
    kind -->|はい| bg["約90分+0〜30分で更新"]
    kind -->|いいえ| fg["起動・サインイン時に適用"]
    bg --> done["反映"]
    fg --> done
    rush["急ぐ場合"] -.-> upd["gpupdateを実行"]
    upd -.-> force["/forceで全再適用"]
    upd -.-> reboot["前景は/logoffや/boot"]

図10: バックグラウンド更新で届くのは対応する設定だけで、前景処理でしか適用されない設定はgpupdate後もサインアウトや再起動が要る。

5. 反映されない時の切り分け ── gpresult・イベントログ・レジストリ

確認する道具は、役割が違います。gpresultは適用の結果、運用ログは処理の経過、レジストリは書き込まれた実値を見るものです。いきなり設定を変え直すのではなく、結果から原因を絞ります。

確認したいこと	使うもの	次に調べること
目的のGPOが適用されたか	gpresultのRSoPレポート	適用・拒否の一覧と理由
同じ設定を別GPOが上書きしていないか	設定ごとの「優先するGPO」	LSDOU、リンク順、強制
処理そのものが失敗・遅延していないか	GroupPolicy運用ログ	ActivityIDで処理1回分を確認
アプリが参照する値は何か	レジストリとADMXの定義	ポリシー専用キーか、その外か

5.1. gpresult /h でRSoPを確認する

複数のGPOが重なった最終結果をRSoP(ポリシーの結果セット)と呼びます。標準ツールの gpresult で、管理者権限のコマンドプロンプトからHTMLレポートへ出力すると読みやすくなります。⁴⁵

次の例では、出力先の C:\temp フォルダーを用意してから実行します。レポートを読むときは、調べたいPCとユーザーの結果になっていることも確認してください。

rem ユーザー+コンピューター両方のRSoPをHTMLレポートに出力
gpresult /h C:\temp\gp-report.html /f

rem コンソールで概要だけ確認する場合
gpresult /r
gpresult /scope computer /r

「適用された」だけで確認を終えない

レポートでは、次の3点を順に見ます。目的のGPOが一覧にあっても、目的の設定が別のGPOに上書きされていれば、期待する値にはなりません。

適用されたGPOの一覧 ── 目的のGPOが入っているか
拒否されたGPOの一覧と理由 ── セキュリティフィルターやWMIフィルター、空のGPOなど、適用されなかった理由が表示されます⁵
設定ごとの「優先するGPO」 ── 目的の設定がどのGPOの値で決まったか。別のGPOが勝っていれば3章の優先順位を見直します

flowchart TB
    accTitle: RSoPレポートで最初に見る3点
    accDescr: gpresultのレポートではまず適用されたGPOの一覧に目的のGPOが入っているかを見て、次に拒否されたGPOの一覧と理由を確認し、最後に設定ごとの優先するGPOでどのGPOの値が勝ったかを特定する
    rep["RSoPレポートを開く"] --> one["1. 適用されたGPOの一覧"]
    one --> two["2. 拒否されたGPOと理由"]
    two --> three["3. 設定ごとの優先するGPO"]
    three -.-> review["別のGPOが勝っていれば見直し"]

図11: RSoPレポートは適用されたGPO、拒否されたGPOと理由、設定ごとの優先するGPOの順に見る。

5.2. GroupPolicy運用ログ

処理の失敗や遅延を追う

gpresultだけでは分からない失敗や、処理時間が長すぎる問題は、イベントビューアーのGroupPolicy運用ログで確認します。

場所は「アプリケーションとサービスログ > Microsoft > Windows > GroupPolicy > Operational」です。ログ名は Microsoft-Windows-GroupPolicy/Operational で、処理の開始から終了までと、適用・拒否されたGPOの一覧、拒否理由が記録されます。⁵

ActivityIDで、処理1回分に絞る

ポリシー処理の1回ごとに、一意のActivityIDが割り当てられます。システムログの警告・エラーからActivityIDを拾い、カスタムビューで同じ処理のイベントだけに絞るのが、Microsoftが案内する手順です。別の処理の記録を混ぜず、1回の開始から終了までを追います。⁵

flowchart TB
    accTitle: GroupPolicy運用ログの絞り込み手順
    accDescr: GroupPolicy運用ログではポリシー処理の1回ごとに一意のActivityIDが割り当てられるため、システムログの警告やエラーからActivityIDを拾い、カスタムビューでその1回分のイベントだけに絞り込んで読む
    sys["システムログの警告・エラー"] --> aid["ActivityIDを拾う"]
    aid --> cv["カスタムビューで絞り込み"]
    cv --> one["処理1回分のイベントを読む"]
    one -.-> rec["適用と拒否のGPO一覧が理由付き"]

図12: 運用ログはシステムログからActivityIDを拾い、カスタムビューでポリシー処理1回分だけに絞り込んで読む。

5.3. レジストリのPoliciesキーとの関係

管理用テンプレート(次章)のポリシーは、最終的にはレジストリ値として書き込まれます。書き込み先は、原則として次のポリシー専用キーです。⁶

HKEY_LOCAL_MACHINE\Software\Policies(コンピューターの構成。推奨の場所)
HKEY_CURRENT_USER\Software\Policies(ユーザーの構成。推奨の場所)
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

ポリシー値は、アプリ独自の設定より先に参照される

ポリシー対応のアプリは、Policiesキーを先に読み、値があればそれを優先し、なければ独自の設定や既定値を使う、という動きをします。「未構成」のポリシーはレジストリに値を書きません。⁶

つまり、ポリシー専用キーを使う管理用テンプレートは、アプリ自身の設定を書き換えて「刺青(tattooing)」を残すのではなく、別の場所へ強制値を置く仕組みです。構成をやめれば、アプリは自分の設定へ従う状態に戻れます。

flowchart TB
    accTitle: ポリシー値とアプリ設定の優先関係
    accDescr: ポリシー対応のアプリはまずPoliciesキーを読んで値があればそれを優先し、なければ自分の設定や既定値を使い、未構成のポリシーはレジストリに何も書かない
    app["ポリシー対応アプリが設定を読む"] --> haspol{"Policiesキーに値がある?"}
    haspol -->|はい| pol["ポリシー値を優先"]
    haspol -->|いいえ| pref["自分の設定や既定値を使う"]
    notconf["未構成のポリシー"] -.-> nowrite["レジストリに何も書かない"]

図13: ポリシーはアプリ自身の設定を書き換えるのではなく、別の場所に置かれた強制値が優先参照される仕組み。

専用キーの外に書く設定は、値が残ることに注意する

すべてのポリシーが、専用キーに書くわけではありません。 たとえば「Win32の長いパスを有効にする」は、HKLM\SYSTEM\CurrentControlSet\Control\FileSystem の LongPathsEnabled に書き込みます。古い世代やサードパーティ製のテンプレートにも、任意のパスへ書くものがあります。

この種の設定は、ポリシーの構成をやめても値が残ります。目的の設定がどのキーへ書くかを、ADMXの定義、設定の説明文、gpresultのレポートで確認してください。

スクリプトやグループポリシー基本設定(Preferences)で専用キーの外へ書き込んだ値も、通常のレジストリ値です。ポリシー専用キーとは異なり、構成をやめても値が残るものとして扱います。

実際の書き込み先を確認する

まずPoliciesキーの実値を見ます。ただし、そこに無いだけで「GPOの影響が無い」と決めず、専用キーの外へ書く設定かどうかも確認します。次のコマンドは、多くのポリシーが使うPolicies配下を見る例です。

# ポリシーで配布された値を直接確認する例(多くのポリシーは Policies 配下に書かれる)
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

flowchart TB
    accTitle: 反映されない時の切り分け手順
    accDescr: まずgpresultのRSoPレポートで適用されたGPOと拒否されたGPOを確認し、足りなければGroupPolicy運用ログをActivityIDで絞り込み、配布された実値はレジストリのPoliciesキーで直接確かめる
    start["設定が反映されない"] --> rsop["gpresult /h でRSoPを確認"]
    rsop --> found{"適用と拒否の理由が分かる?"}
    found -->|はい| fix["優先順位やフィルターを見直す"]
    found -->|いいえ| oplog["GroupPolicy運用ログを見る"]
    oplog -.-> aid["ActivityIDで1回分に絞り込む"]
    rsop -.-> reg["Policiesキーの実値を直接確認"]

図14: 切り分けはgpresult /hを起点に、足りなければGroupPolicy運用ログ、実値はPoliciesキーの直接確認で機械的に進める。

6. 管理用テンプレート(ADMX)とセントラルストア

ADMXは設定の定義、ADMLは表示文字列

GPMCの「管理用テンプレート」に並ぶ項目は、ADMXファイルで設定の定義を、ADMLファイルで言語ごとの表示文字列を記述しています。

各PCの C:\Windows\PolicyDefinitions にはOS付属の定義があり、管理ツールはそれを読み込んで設定画面を組み立てます。⁷

ドメインでは、共通のセントラルストアを参照する

ドメイン運用では、DCのSYSVOL配下に PolicyDefinitions フォルダーを作ります。例は \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions です。

内容はドメイン内の全DCへ複製され、グループポリシーツールは既定でセントラルストアを参照するようになります。管理端末ごとにテンプレートのバージョンが違い、見える項目が食い違う問題を防ぐための仕組みです。ADMLは、ja-JP など言語別のサブフォルダーへ置きます。⁷

flowchart TB
    accTitle: セントラルストアの仕組み
    accDescr: ドメインコントローラーのSYSVOL配下にPolicyDefinitionsフォルダーを作成すると内容が全ドメインコントローラーに複製され、グループポリシーツールが既定でセントラルストアを参照するため管理端末ごとの定義の食い違いがなくなる
    create["SYSVOL配下に作成"] --> cs["PolicyDefinitions"]
    cs --> repl["全DCに複製される"]
    cs --> ref["GPツールが既定で参照"]
    ref -.-> benefit["端末ごとの定義の食い違いが消える"]
    cs -.-> adml["ADMLは言語別フォルダーへ"]

図15: SYSVOLのPolicyDefinitionsは全ドメインコントローラーに複製され、グループポリシーツールが既定で参照する。

更新は、作業フォルダーで準備してから切り替える

新しいWindows向けのADMXは、Microsoftがバージョンごとに配布しています。更新するのはセントラルストア側です。各PCの C:\Windows\PolicyDefinitions をダウンロード版で置き換える方法は、サポートされていません。⁷

既存ストアの更新は、本番フォルダーへ直接上書きせず、次の順に進めます。

PolicyDefinitions-24H2 のようなバージョン名の作業フォルダーを用意する。
OS分と、Office・Edgeなどアプリ分のADMX一式をそろえる。
現行の PolicyDefinitions を PolicyDefinitions-23H2 などへリネームし、退避する。
作業フォルダーを PolicyDefinitions へリネームして、本番として参照させる。⁷

参照されるのは PolicyDefinitions という名前のフォルダーです。バージョン名のフォルダーに置いただけでは反映されません。旧フォルダーを退避しておけば、問題が起きたときに戻せます。⁷

flowchart TB
    accTitle: セントラルストア更新の手順
    accDescr: 更新はバージョン名の作業フォルダーにOS分とアプリ分のADMX一式をそろえ、現行フォルダーをリネームして退避してから作業フォルダーを本番名のPolicyDefinitionsへリネームし、問題が起きたら退避した旧フォルダーへ戻す
    work["バージョン名の作業フォルダー"] --> gather["OS分とアプリ分をそろえる"]
    gather --> evac["現行をリネームして退避"]
    evac --> rename["作業フォルダーを本番名へ"]
    rename --> live["本番として参照される"]
    live -.-> back["問題時は旧フォルダーへ戻す"]

図16: 更新は作業フォルダーで一式をそろえ、現行を退避してからリネームで本番化する。

7. GPO vs Intune(MDM/CSP) vs 手動・スクリプト ── 判断表

Windows端末の構成管理の選択肢は、いまはGPOだけではありません。Intuneに代表されるMDMは、CSP(構成サービスプロバイダー)という仕組みを通じてOS設定を構成します。どれを軸にするかの判断表です。

観点	ドメインGPO	Intune(MDM/CSP)	手動・スクリプト配布
前提	ADドメイン参加+ドメインコントローラーへの接続	Intuneライセンス+端末のIntune登録(Entra参加/ハイブリッド参加のほか、BYOD等のEntra登録デバイスも登録方式しだいで対象)	なし(だからこそ統制もない)
社外・在宅端末への到達	VPN等でDCに届かないと更新されない	インターネット経由で届く	手作業次第
設定の粒度・網羅性	最も広い(管理用テンプレート+セキュリティ設定+スクリプト等)	拡大中だが、GPO全設定と同等ではない⁹	書いた分だけ
強制力	ポリシーとして強制(Policiesキー優先)⁶	ポリシーとして強制(CSP)	ユーザーが変更すれば戻らない
適用の確認手段	gpresult / GroupPolicy運用ログ⁴⁵	Intune管理センターのレポート	自前で仕組みを作る
向いている環境	オンプレAD中心・社内LAN常駐の端末	クラウド中心・持ち出し端末・拠点分散	数台規模、または他の手段の補完

判断の軸は、端末の基盤と所在

基本は、端末がADとMicrosoft Entraのどちらを基盤にしているかと、どこで使うかです。オンプレADへドメイン参加した社内据え置きPCにはGPOが確実で、Entra参加のモバイルPCにはドメインGPOは届きません。

社内常駐と持ち出し端末を、同じ到達条件だと考えないことが重要です。

ハイブリッドでは、設定ごとに管理主体を決める

中小企業でも、ドメイン参加とIntune登録を組み合わせたハイブリッド運用は多くあります。ここで避けたいのが、同じ設定をGPOとMDMの両方で構成することです。

Policy CSPには、競合時にMDMを優先する MDMWinsOverGP があります。ただし、対象はPolicy CSP内の対応ポリシーだけです。その制御下にない設定を二重構成すると、どちらが勝つかは保証されません。Microsoftも二重構成を避けるよう案内しています。⁸

「この領域はGPO、この領域はIntune」と管理主体を決め、片方へ寄せるのが原則です。

flowchart TB
    accTitle: GPOとIntuneの使い分け
    accDescr: 端末のアイデンティティ基盤がオンプレADで社内常駐ならGPO、Entra参加や社外の端末ならIntuneが適し、ハイブリッドでは同じ設定の二重構成を避けて設定領域ごとに管理主体を片方へ寄せる
    q{"端末の基盤と所在は?"}
    q -->|AD参加で社内常駐| gpo["GPOが確実で粒度も細かい"]
    q -->|Entra参加や社外| intune["Intuneなら社外にも届く"]
    q -->|ハイブリッド| split["領域ごとに片方へ寄せる"]
    split -.-> warn["二重構成は結果が保証されない"]
    split -.-> ana["仕分けにGroup Policy analytics"]

図17: 使い分けは端末のアイデンティティ基盤と所在で決め、ハイブリッドでは同じ設定をGPOとMDMの両方で構成しない。

Group Policy analyticsは、移す前の仕分けに使う

移行検討の入口は、Intuneの Group Policy analytics です。GPMCからXMLでエクスポートしたGPOをインポートすると、設定ごとにMDM対応・非推奨・対応不能を分析できます。対応済みの設定は、Intuneの設定カタログポリシーへ移行できます。⁹

「全部を移すツール」ではなく、移せるもの・移せないもの・捨てるものを仕分ける道具として使います。

Windows Updateの管理主体も同じ文脈で再編が進んでいます。「WSUS非推奨後のWindows Update管理」も参照してください。

flowchart TB
    accTitle: Group Policy analyticsでの仕分け
    accDescr: GPMCからXML形式でエクスポートしたGPOをGroup Policy analyticsにインポートすると設定ごとにMDMでサポートされているか非推奨や対応不能かを仕分けでき、対応済みの設定は設定カタログポリシーへ移行できる
    exp["GPMCからXMLでエクスポート"] --> imp["analyticsにインポート"]
    imp --> ana["設定ごとに対応状況を分析"]
    ana --> ok["MDM対応済み"]
    ana --> dep["非推奨・対応不能"]
    ok --> mig["設定カタログポリシーへ移行"]

図18: Group Policy analyticsはエクスポートしたGPOをインポートし、MDMへ移せる設定と移せない設定を仕分ける。

8. 開発者視点の落とし穴 ── 客先GPOがアプリの動作を変える

最後に、受託開発の立場で押さえておくべき話です。客先のGPOは、あなたのアプリの前提条件を静かに書き換えます。「開発機では動くのに客先で動かない」の一因として、ファイアウォールやウイルス対策と並んでGPOは常連です。実例ベースで挙げます。

PowerShellの実行ポリシー

実行ポリシーはGPOで集中構成でき、GPO由来のMachinePolicy/UserPolicyスコープは、ローカルやプロセスで設定した値より常に優先されます。¹⁰ インストーラーや運用スクリプトが「-ExecutionPolicy Bypassを付ければ動くはず」という前提で作られていると、GPO管理下では起動すらしません。詳細は「PowerShellの実行ポリシーとスクリプト署名」を参照してください。

ファイアウォールのローカル規則マージ無効化

GPO/Intuneでファイアウォールを集中管理している環境では、プロファイル単位で「ローカル規則のマージ」(AllowLocalPolicyMerge)を無効化できます。無効の環境では、インストーラーがローカルに登録した受信規則は存在していても適用されません。¹¹ サーバー型アプリの導入前に必ず確認すべきポイントで、「Windowsファイアウォールと業務アプリ」で詳しく扱っています。

ドライブ割り当て・プロキシなどの環境構成

ネットワークドライブの割り当てやプリンターなどはグループポリシー基本設定(Preferences)で配布されているのが定番です。¹⁶ 「Zドライブがあるはず」「プロキシは直結のはず」といった環境仮定は、サインインするユーザーやPCの所属OUによって崩れます。ユーザーの構成で配布された設定はサービスやタスクの実行アカウントには当然適用されないことも、常駐型アプリでは見落としがちです。

そもそも設定が「戻せない」

管理用テンプレート由来の設定はユーザーが画面から変更できなくなっている(項目がグレーアウトする)のが普通です。「お客様側で設定を変えてもらえば直ります」が通用しない、というのは対応方針の設計に効いてきます。

flowchart TB
    accTitle: 客先GPOが変えるアプリの前提
    accDescr: 客先のGPOは実行ポリシーの強制、ファイアウォールのローカル規則マージ無効化、ドライブやプロキシの配布、ユーザーが設定を戻せない状態という形でアプリの前提条件を変え、客先でだけ動かない事象の一因になる
    gpo["客先のGPO"] --> ep["実行ポリシーの強制"]
    gpo --> fw["ローカル規則マージ無効"]
    gpo --> env["ドライブ・プロキシ配布"]
    gpo --> lock["設定を戻せない"]
    ep --> sym["客先でだけ動かない一因に"]
    fw --> sym
    env --> sym
    lock --> sym

図19: 客先のGPOは実行ポリシーやファイアウォール、環境構成などアプリの前提条件を静かに書き換える。

開発側は、導入前と障害時の確認を決めておく

備えは次の3つです。

場面	開発側で準備すること
導入前	実行ポリシー、待ち受けポート、書き込み先、プロキシ経路などを導入要件として文書化し、客先情シスへ確認を依頼する
トラブル時	憶測で設定を変えず、`gpresult /h` のレポートと `HKLM\Software\Policies` 配下の実値を確認する(5章)
設計時	管理者権限が必要な処理と、不要な処理を分ける

権限の線引きは「管理者特権はいつ必要か」で扱っています。GPOは敵ではなく、環境の仕様です。 仕様として扱い、管理者と確認する項目をそろえれば、切り分けを機械的に進められます。

flowchart TB
    accTitle: 開発側の3つの備え
    accDescr: 開発側の備えはアプリが依存する環境前提を導入要件として文書化して導入前に客先情シスへ確認を依頼すること、トラブル時はgpresultのレポートとPoliciesキーの実値を確認すること、管理者権限が必要な処理を設計段階で分けておくことの3つになる
    dev["開発側の備え"] --> doc["1. 環境前提を文書化"]
    dev --> chk["2. gpresultと実値で確認"]
    dev --> priv["3. 権限の要否を設計で分離"]
    doc -.-> ask["導入前に客先情シスへ確認依頼"]

図20: 開発側の備えは環境前提の文書化、gpresultと実値での確認、管理者権限の要否の設計分離の3つ。

9. まとめ

グループポリシーはGPO単位の設定をローカル→サイト→ドメイン→OU(LSDOU)の順に処理する仕組みで、競合は後勝ちです。対象に近いOUのGPOが最も強く、ローカルGPOが最も弱い層です。
継承のブロック・強制(Enforced)・セキュリティフィルター処理で既定の流れを制御できます。強制は継承ブロックにも勝つため、多用は禁物です。
適用は起動時・サインイン時の前景処理と、既定約90分+ランダムオフセットのバックグラウンド更新の二本立てです。gpupdate /forceは全設定の再適用であり、サインインや再起動でしか処理されない設定には効きません。
反映されないときは gpresult /h → GroupPolicy運用ログ → レジストリのPoliciesキー、の順で機械的に切り分けます。拒否されたGPOには理由が表示されます。
管理用テンプレートの定義はADMX/ADMLで、ドメイン運用ではSYSVOLのセントラルストアに集約します。更新時はローカルのPolicyDefinitions置き換えではなくセントラルストア側を入れ替えます。
GPOかIntuneかは端末のアイデンティティ基盤と所在で決め、ハイブリッドでは同じ設定の二重構成を避けて管理主体を片方に寄せます。移行の仕分けにはGroup Policy analyticsが使えます。
開発者にとって客先GPOは環境仕様の一部です。実行ポリシー・ファイアウォール・ドライブやプロキシ構成などの前提を文書化し、gpresultで確認できる体制を作っておけば、「客先でだけ動かない」の多くは怖くありません。

参考リンク

Microsoft Learn, Group Policy processing and precedence. グループポリシーがローカルGPO→サイト→ドメイン→OUの順に処理され、後から処理されたGPOが競合時に上書きすること(競合しない設定は集約される)、同一コンテナー内の複数GPOはリンク順で処理されリンク順最小のGPOが最後に処理されて最優先になること、強制(Enforced)・リンク無効化・ユーザー/コンピューター設定の無効化・継承のブロックという例外、強制されたGPOは下位の継承ブロックがあっても適用され続けること、ワークグループのコンピューターはローカルGPOのみ処理すること、起動時にコンピューターポリシー・サインイン時にユーザーポリシーが適用される流れについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Microsoft Learn, ADMX_GroupPolicy Policy CSP. コンピューターのグループポリシーがシステム起動時に必ず適用され、既定で90分ごと+0〜30分のランダムオフセットでバックグラウンド更新されること、ユーザーのグループポリシーがサインイン時に必ず適用され同じく既定90分+0〜30分オフセットで更新されること、ドメインコントローラーの既定更新間隔が5分であること、更新間隔を0〜64,800分の範囲で構成できることについて。 ↩ ↩²

Microsoft Learn, gpupdate. gpupdateが既定では変更のあったポリシー設定のみ適用し/forceで全設定を再適用すること、ユーザー向けソフトウェアインストールやフォルダーリダイレクトのようにバックグラウンド更新では処理されずサインイン時に処理される拡張のための/logoff、コンピューター向けソフトウェアインストールのように起動時に処理される拡張のための/boot、/target:{computer

user}や/waitの各オプションについて。

↩ ↩² ↩³ ↩⁴

Microsoft Learn, gpresult. gpresultがポリシーの結果セット(RSoP)を表示するコマンドであること、/hでHTML・/xでXMLのレポートを出力し/fで上書きできること、/rで概要表示・/v・/zで詳細表示ができること、/scope {user

computer}で対象を絞れること、サイト・ドメイン・OUのメンバーシップにもとづいて重なり合ったポリシーの結果セットが生成されることについて。

↩ ↩² ↩³

Microsoft Learn, Applying Group Policy troubleshooting guidance. グループポリシーの切り分けで管理者権限のコマンドプロンプトからgpresult /hを実行してGPOが適用されない理由を確認する手順、GroupPolicy運用ログ(Microsoft-Windows-GroupPolicy/Operational)に適用されたGPOの一覧と拒否されたGPOの一覧が拒否理由とともに記録されること、ポリシー処理のインスタンスごとに一意のActivityIDが割り当てられ、カスタムビューで該当インスタンスのイベントだけを絞り込む手順、GPSvcのデバッグログの有効化について。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, Implementing Registry-based Policy. レジストリベースのポリシーの格納先がHKCU\Software\PoliciesとHKLM\Software\Policies(推奨の場所)およびHKCU/HKLMのSoftware\Microsoft\Windows\CurrentVersion\Policiesに限られること、「未構成」状態ではレジストリに値を書かないこと、アプリはまずポリシーキーを読み、無ければプリファレンス値を読むべきでポリシーキーが常にプリファレンスキーに優先すること、格納できるデータ型がREG_DWORD・REG_SZ・REG_EXPAND_SZであること、ポリシー更新時にアプリがポリシーキーを再確認すべきことについて。 ↩ ↩² ↩³ ↩⁴
Microsoft Learn, How to create and manage the Central Store for Group Policy Administrative Templates in Windows. 管理用テンプレートが定義本体のADMXと言語別表示文字列のADMLに分かれていること、セントラルストアをドメインコントローラーのSYSVOL配下のPolicyDefinitionsフォルダー(例: \contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions)として作成すること、内容がドメイン内の全ドメインコントローラーに複製されグループポリシーツールが既定でセントラルストアを参照すること、ADMLがen-USやko-KRのような言語別フォルダーに置かれること、ダウンロード版ADMXでC:\Windows\PolicyDefinitionsを置き換えるのはサポートされないこと、更新時はPolicyDefinitions-24H2のようなバージョン名の新フォルダーにOS分とアプリ拡張分のADMX/ADML一式をそろえ、現行フォルダーをPolicyDefinitions-23H2等にリネームして退避したうえで新フォルダーを本番名のPolicyDefinitionsへリネームする手順が案内されていること、重大な問題が起きた場合に旧フォルダーへ戻せることがこの方式の利点とされることについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, ControlPolicyConflict Policy CSP. MDMWinsOverGPポリシー(既定値0)を1に設定するとPolicy CSP内の対応ポリシーについてMDM設定がグループポリシーに優先すること、適用対象がPolicy CSP内のポリシーに限られDefender CSPなど他のCSPには適用されないこと、この制御下にない設定をGPOとMDMの両方で構成すると競合状態になりどちらが勝つか保証されないため二重構成を避けるべきとされていることについて。 ↩ ↩²
Microsoft Learn, Analyze your on-premises GPOs using Group Policy analytics in Microsoft Intune. Group Policy analyticsがオンプレミスのGPOをインポート・分析し、Intuneを含むMDMプロバイダーがサポートする設定と非推奨・利用不能な設定を表示すること、GPMCからXML形式でエクスポートしたGPOをインポートすること、インポートしたGPOを設定カタログポリシーへ移行してデバイスに展開できることについて。 ↩ ↩² ↩³
Microsoft Learn, about_Execution_Policies. 実行ポリシーのスコープがMachinePolicy・UserPolicy・Process・CurrentUser・LocalMachineの優先順で評価されること、MachinePolicyとUserPolicyがグループポリシーによって設定されるスコープであり、下位のスコープでより緩い(または厳しい)ポリシーを設定しても優先順位の高いポリシーが有効になること、Get-ExecutionPolicy -Listで全スコープの設定を確認できることについて。 ↩ ↩²
Microsoft Learn, Windows Firewall rules. GPOやCSPによるファイアウォールの集中管理環境でプロファイル単位に「ローカル規則のマージ」(AllowLocalPolicyMerge)を無効化でき、無効の場合はローカルで作成した規則が適用されず、受信接続が必要なアプリの規則は集中配布が必須になることについて。 ↩ ↩²
Microsoft Learn, Step-by-Step Guide to Managing Multiple Local Group Policy Objects. Windows Vista以降のローカルGPOが「ローカルコンピューターポリシー」「管理者/非管理者用」「特定ユーザー用」の複数レイヤー(MLGPO)を持つこと、ローカルコンピューター→管理者/非管理者→ユーザー別の順に処理され最後に読まれるユーザー別が最も優先されること、ドメイン非参加PCの管理向けの機能であることについて。 ↩
Microsoft Learn, Security filtering using GPMC. セキュリティフィルター処理がGPOの設定を受け取るユーザーとコンピューターを絞り込む仕組みであること、GPOが適用されるには対象のユーザーまたはコンピューターが「読み取り」と「グループポリシーの適用」の両方のアクセス許可を持つ必要があること、既定で全GPOにAuthenticated Users(ユーザーとコンピューターを含む)へ両許可が与えられていること、フィルターはGPO全体に働き設定ごとには使えないことについて。 ↩ ↩²
Microsoft Learn, Deploying Group Policy Security Update MS16-072 (KB3163622). MS16-072適用後はユーザーのグループポリシーがコンピューターのセキュリティコンテキストで取得されるという設計変更、そのためコンピューターアカウントがGPOの読み取りアクセスを必要とすること、セキュリティフィルター処理等でAuthenticated Usersの許可を外している場合はAuthenticated UsersまたはDomain Computersに「読み取り」(「グループポリシーの適用」は不要)を追加する必要があることについて。 ↩ ↩²
Microsoft Learn, Loopback processing of Group Policy. ループバック処理が、コンピューターオブジェクトの場所にもとづいてユーザー設定のGPOセットを適用する機能であること、公共エリア・ラボ・教室のような特殊用途のコンピューターを想定した仕組みであること、Active Directory環境でのみサポートされ、マージと置換のモードがあることについて。 ↩
Microsoft Learn, Group Policy Preferences Getting Started Guide. グループポリシー基本設定(Preferences)がドライブの割り当て・プリンター・スケジュールされたタスク・サービス・フォルダーオプションなどを構成するGPMCの拡張群であること、アイテムレベルターゲット処理による絞り込みができること、ユーザーによる変更を制限せずに設定を配布でき、強制する設定としない設定を選べる(ポリシーとは性格が異なる)ことについて。 ↩

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

Windowsアプリ開発

業務アプリ、装置連携、通信ツールなどの Windows ソフト開発を支援します。

サービスを見るお問い合わせ

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

gpupdate /force を実行したのに設定が反映されません。なぜですか？: まず、その設定が「バックグラウンド更新では反映されない種類」でないかを確認してください。ユーザー向けソフトウェアインストールやフォルダーリダイレクトはサインイン時に、コンピューター向けソフトウェアインストールは起動時にしか処理されないため、gpupdateの完了後にサインアウト(/logoff)や再起動(/boot)が必要です。次に gpresult /h でRSoPレポートを出力し、そのGPOが「適用されたGPO」に入っているか、「拒否されたGPO」に理由付きで入っていないかを確認します。適用されているのに動作が変わらない場合は、より優先順位の高い別のGPOが同じ設定を上書きしている(後勝ち)可能性を疑ってください。レポートには各設定の「優先するGPO」が表示されるので、どのGPOが勝っているかまで特定できます。
gpresult に「フィルターで拒否」と表示されるのはどういう意味ですか？: そのGPOはリンクの場所としては対象に入っているものの、フィルター処理によって適用対象から外された、という意味です。代表的な原因はセキュリティフィルター処理で、GPOを適用するにはユーザーまたはコンピューターがそのGPOに対して「読み取り」と「グループポリシーの適用」の両方のアクセス許可を持っている必要があります。既定ではAuthenticated Usersに両方が許可されていますが、特定のグループに絞る運用をしている場合、グループへの追加漏れやコンピューターアカウントの入れ忘れで拒否されます。またユーザー向けGPOでは、対象ユーザーに両方の許可を与えるだけでは足りません。MS16-072以降、ユーザーポリシーはコンピューターのセキュリティコンテキストで取得されるため、Authenticated UsersまたはDomain Computersに「読み取り」(「適用」は不要)を残しておく必要があります。ほかにWMIフィルターの条件不一致や、GPO側でユーザー/コンピューター側の設定が無効化されているケースもあります。拒否理由はgpresultのレポートとGroupPolicy運用ログの両方に記録されます。
GPOとIntuneのどちらで管理すべきですか？: 端末のアイデンティティ基盤に合わせるのが基本です。オンプレミスADにドメイン参加している端末が中心で、社内ネットワークに常時つながっているなら、GPOが最も確実で粒度も細かい選択肢です。Microsoft Entra参加の端末やドメインコントローラーに接続しない在宅端末が増えているなら、社外でも構成が届くIntune(MDM/CSP)が適します。両方が混在するハイブリッド環境では、同じ設定をGPOとMDMの両方で構成すると競合して結果が保証されないため、設定領域ごとにどちらで管理するかを決めて片方に寄せるのが原則です。移行を検討する段階では、IntuneのGroup Policy analyticsで既存GPOをインポートすると、MDMで対応済みの設定と非対応・非推奨の設定を仕分けできます。
ローカルグループポリシー(gpedit.msc)で設定した内容が、ドメインの設定に上書きされます。仕様ですか？: 仕様です。グループポリシーはローカル→サイト→ドメイン→OUの順(LSDOU)で処理され、後から処理されたものが競合時に勝つため、ローカルGPOは最も弱い層になります。ドメインGPOが同じ設定を構成していれば、ローカルでの変更は常に上書きされます。逆に、ドメイン側が「未構成」にしている設定であれば、ローカルGPOの値がそのまま生きます。検証などでどうしてもローカル設定を優先したい場合でも、ドメイン参加PCでこの優先順位を覆す方法はないため、検証用OUを作ってドメイン側のGPOを調整するか、ドメイン非参加の検証機を使うのが現実的です。
開発した業務アプリが客先環境でだけ動きません。GPOが原因か確かめる方法はありますか？: 客先の管理者に依頼して、問題のPCで管理者権限のコマンドプロンプトから gpresult /h report.html を実行してもらい、RSoPレポートを確認するのが第一歩です。実行ポリシーによるスクリプト停止、ファイアウォールのローカル規則マージ無効化、プロキシやドライブ割り当ての構成など、アプリの動作を変える設定が適用されていないかを見ます。あわせて、レジストリの HKLM\Software\Policies と HKCU\Software\Policies 配下に関連製品のポリシー値が書かれていないかを確認すると、管理用テンプレート由来の強制設定を機械的に洗い出せます。開発側でできる備えとしては、アプリが依存する前提(実行ポリシー、受信ポート、書き込み先フォルダーなど)を導入手順書に明記し、導入前に客先の情シスに確認してもらうことです。

著者プロフィール

記事の著者プロフィールページです。

小村豪

合同会社小村ソフト代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

プロフィールを見るお問い合わせ

公開リンク

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

ブログ一覧に戻る