グループポリシーでWindows 11／10の「設定」アプリを整理するなら、「設定ページの表示」ポリシーにshowonly:またはhide:とページ識別子を指定します。たとえば社内端末で「バージョン情報」と「Bluetooth」だけを見せる場合はshowonly:about;bluetoothです。識別子はMicrosoftの現行ms-settings: URI一覧から取得し、GPO値には接頭辞を入れません。設定を隠すことと変更権限を禁止することは別なので、標準ユーザー、個別の管理ポリシー、段階展開も組み合わせます。
設定ページの表示ポリシーでできること
Settings Page Visibilityは、Windowsの「設定」アプリに表示するページを限定するポリシーです。hide:は指定したページだけを隠し、それ以外を表示します。showonly:は指定ページだけを表示し、それ以外を隠します。あるカテゴリ内の全ページが隠れるとカテゴリ自体も表示されません。Microsoftの現行資料では、非表示ページへURI、エクスプローラーのコンテキストメニューなどから直接移動しても、設定アプリの先頭ページへ戻されます。
このポリシーはWindows 10 version 1703以降とWindows 11で利用でき、コンピューター構成とユーザー構成の両方にあります。端末にサインインする全ユーザーへ同じ表示を適用するならコンピューター構成、特定ユーザーだけならユーザー構成を検討します。ただし、同じ端末へ両方を競合させると結果が分かりにくくなります。対象、目的、所有者を決め、専用GPOの一方へ集約して実機のResultant Set of Policyで確認します。
非表示はセキュリティ境界ではない
設定ページを隠すと利用者の誤操作と問い合わせを減らせますが、設定値そのものへのすべての変更経路を禁止するわけではありません。従来のコントロールパネル、コマンド、PowerShell、レジストリ、アプリ独自UI、管理APIなど別経路が残る設定があります。ローカル管理者は多くの構成を変更できるため、「ページが見えないから保護済み」と判断してはいけません。
変更を本当に禁止したい項目は、該当するAdministrative Templates、Security Settings、Policy CSP、アプリ制御、デバイス制御などの専用ポリシーで強制します。日常利用者を標準ユーザーにし、ローカル管理者付与を最小化することも基本です。Page Visibilityは利用者体験を整理する補助統制として位置付け、ネットワーク、更新、アカウント、回復、プライバシーなど高影響項目は「非表示」と「設定値の強制」を別々にテストします。
対象ページはms-settings URI一覧から選ぶ
Windows設定の各ページには、ms-settings:about、ms-settings:bluetooth、ms-settings:network-proxyのようなURIがあります。GPOへ入力する識別子はms-settings:を除いたabout、bluetooth、network-proxyです。複数ページはセミコロンで区切り、空白や全角記号を混ぜません。表示名を英訳して推測せず、Microsoftの最新「Launch Windows Settings」一覧で対象OSに対応するURIを確認します。
設定ページの有無はWindowsのバージョン、エディション、ビルド、ハードウェア、追加機能で異なります。showonlyに書いても、通常は存在しないページや必要なデバイスがないページを強制表示しません。また、Windows 11ではカテゴリ構成やURIの意味が更新されることがあります。管理対象の最古・最新ビルドを代表する検証機でURIを直接開き、意図したページへ移動することを確認してからポリシー文字列へ採用します。
hideとshowonlyの選び方
hide方式は「大半のページは使わせ、危険または不要な数ページだけ隠す」場合に向きます。例としてモバイルホットスポットとプロキシだけを隠すなら、hide:network-mobilehotspot;network-proxyです。Windowsの更新で新しい設定ページが追加された場合、そのページは既定で表示されるため、新機能を自動的に許容する運用になります。一般社員PCで少数の設定だけ制限する場合に扱いやすい方式です。
showonly方式は、キオスク、共有端末、教室、現場端末など「許可したページ以外を見せたくない」場合に向きます。例としてバージョン情報とBluetoothだけならshowonly:about;bluetoothです。新しいページはリストへ追加するまで隠れるため統制は強くなりますが、ヘルプデスクが必要とする表示、アクセシビリティ、ネットワーク切り分け、更新状況まで隠す恐れがあります。許可する業務シナリオを先に洗い出します。
GPOを専用オブジェクトとして作成する
Group Policy Management Consoleで対象ドメインまたは検証OUに専用GPOを作り、すぐ全社OUへリンクしない状態で編集します。パスは「コンピューターの構成」または「ユーザーの構成」→「管理用テンプレート」→「コントロール パネル」→「設定ページの表示」です。ポリシーを有効にし、Options欄へ検証済みの一行文字列を入力します。GPO名、変更番号、対象OS、方式、URI一覧、所有者、ロールバック値を説明へ残します。
組織がCentral Storeを使う場合、GPMCはドメインのPolicyDefinitionsを参照します。Microsoftの現行GPO資料は、必要に応じてControlPanel.admxと対応するControlPanel.admlをCentral Storeへ配置するよう案内しています。テンプレートが古くポリシーが表示されない場合は、GPOを別の端末で無理に直接編集せず、Central Store全体の互換性とバックアップを確認して更新します。ADMXだけ、または言語ADMLだけを差し替えると表示エラーの原因になります。
コンピューター構成とユーザー構成を使い分ける
コンピューター構成は、共有PCや端末役割ごとに一貫した画面を見せる場合に適します。端末OUへGPOをリンクし、実際にその端末を利用する複数の標準ユーザーで確認します。ユーザー構成は、同じ端末でも職務や利用者グループで表示を変えたい場合に適します。ユーザーOU、セキュリティフィルター、必要ならループバック処理の既存設計を確認し、想定外の管理者やサービスアカウントへ適用しません。
セキュリティフィルターは「Authenticated Usersを外して対象グループだけ」といった変更でRead権限まで失うと、GPOの評価自体が変わります。WMIフィルターはOSビルド条件に使えますが、複雑にすると評価と障害調査が難しくなります。まず検証OUへ少数端末を置く単純な範囲で動作を確かめ、必要性が明確な場合だけフィルターを追加します。管理者向けの緊急GPOや別OUで設定画面へ戻せる運用も用意します。
値の構文を機械的に確認する
文字列は先頭をshowonly:またはhide:のどちらか一つにし、その後へ識別子をセミコロン区切りで並べます。GPO値にはms-settings:を含めません。末尾セミコロン、カンマ区切り、全角コロン、重複、存在しないURI、表示名、URL全体の貼り付けを避けます。変更票では、元の公式URIとGPO用識別子を二列で管理するとレビューしやすくなります。
MicrosoftはWindows 11 version 22H2以降で、URIにquietmomentsを含むページを隠すと、System配下のNotificationsページ全体が隠れる挙動を警告しています。古いブログのURI一覧を使うと、現在のカテゴリで予想より広い影響が出る場合があります。対象ビルド別に、設定トップ、カテゴリ、対象ページ、直接URI、通知やネットワークの関連導線をテストし、一つのURI名だけを見て影響範囲を決めません。
検証端末でGPO適用と画面を確認する
検証端末で通常のポリシー更新を待つか、変更時間帯にgpupdateを実行し、設定アプリを閉じて開き直します。適用結果はgpresult /hでHTMLレポートへ出し、対象GPOが適用済みか、Denied GPOに入っていないか、ComputerとUserのどちらが値を提供したかを確認します。設定画面の見た目だけでなく、端末名、ユーザー、OSエディション、ビルド、ポリシー更新時刻を証跡へ残します。
showonlyなら許可ページが開くことと、それ以外の代表ページが隠れることを両方試します。hideなら対象ページのナビゲーション、ms-settings:直接起動、コンテキストメニューからの移動を試し、設定トップへ戻ることを確認します。さらにコントロールパネル、通知領域、ネットワークアイコン、検索、業務アプリから同じ機能へ到達できるか調べます。変更権限の禁止が目的なら、別経路で値を変えられないことまで確認します。
利用者とヘルプデスクへの影響を先に確認する
ネットワークページを隠すと、利用者がWi-Fi、プロキシ、VPN、IP設定を確認できず、遠隔支援の初動が遅れる場合があります。Windows Update、回復、アカウント、時刻、言語、アクセシビリティを隠す場合も同様です。隠す理由、代替UI、問い合わせ窓口、管理者が確認する手順をヘルプデスクへ渡し、利用者向け手順書の画面と矛盾しないか確認します。
showonlyを使う専用端末でも、サポート担当がOSビルド、デバイス情報、ネットワーク状態を確認する経路を残します。一般ユーザーには不要でも、キオスクの保守アカウントには必要なページがあるなら、ユーザー構成を分けるか、保守用OUとGPO切替を設計します。ローカル管理者でログインすれば必ずポリシーを回避できるとは限らないため、障害時にGPMCからリンクやスコープを安全に戻せる権限と手順を用意します。
段階展開とロールバックを準備する
展開はIT検証、代表利用者、少数部門、全体の順に行い、問い合わせ、ネットワーク接続、更新、サインイン、Bluetooth、印刷、リモート支援など対象URIに関係する業務を観測します。Windows 10と11、複数ビルド、ノートPCとデスクトップ、標準ユーザーと管理用ユーザーを含めます。GPO変更とADMX更新を同時に行わず、問題時にどちらが原因か切り分けられるようにします。
ロールバックは、直前のポリシー値へ戻すか「未構成」にし、通常のGPO更新後にgpresultと画面を再確認します。GPO全体のリンク解除は同じオブジェクトに別設定がある場合の影響が広いため、Page Visibility専用GPOに分けておくと安全です。削除やレジストリ清掃を先に行わず、適用元、継承、クラウドMDMのPageVisibilityList、ローカルポリシーの競合を調べます。戻し完了の条件を「全ページが再表示」だけでなく業務動作まで定義します。
IntuneやPolicy CSPとの併用は最終値を確認する
同じPageVisibilityListはIntuneのSettings CatalogやPolicy CSPでもデバイス・ユーザースコープへ配布できます。Microsoft Entra参加や共同管理端末では、GPOとMDMが同じ設定を別の値で配る可能性があります。GPOからIntuneへ移行中なら、対象グループ、割り当て、除外、MDM診断レポート、レジストリ、gpresultを照合し、どちらを正とするか決めます。
管理経路を切り替える際は、旧GPOを未構成にしてから新MDMを配るのか、検証リングだけ先に移すのかを計画します。両方を同時に強制して偶然同じ結果になる状態は、将来の変更で競合します。コンピューターとユーザー、オンプレミスとクラウド、Windows 10と11の四つの軸で適用表を作り、端末で有効な最終UIと実際の変更制御を確認します。ページ表示は利用者体験、専用設定ポリシーはセキュリティ統制として責任を分けます。
確認チェックリスト
- 制御目的がページ非表示か、設定値の強制・変更禁止かを分ける
- 対象OSビルドでMicrosoft公式ms-settings URIを直接開いて確認する
- GPO値からms-settings:を除きshowonlyまたはhideをセミコロン区切りで作る
- コンピューター構成とユーザー構成を競合させず専用GPOで管理する
- gpresult、直接URI、別導線、標準ユーザーで実際の適用を確認する
- 検証OUから段階展開し、未構成または直前値へ戻す手順を保持する
Windowsの設定アプリは、Settings Page Visibilityポリシーとshowonly:／hide:で整理できます。識別子は公式のms-settings: URIから接頭辞を除き、セミコロンで並べます。GPOはコンピューターまたはユーザーのどちらかへ目的に合わせて適用し、gpresultと対象ビルドの実画面で確認します。ただしページを隠すだけでは、別UIや管理コマンドからの変更を防ぐ完全なセキュリティ制御になりません。標準ユーザー、項目別ポリシー、段階展開、ヘルプデスク手順、ロールバックを組み合わせて運用してください。
コメント