Windows 11 Enterprise and Education の端末から、不要な標準搭載アプリをどう安全に外すかは、情シスやエンドポイント管理者にとって地味ながら重要な課題です。2026年4月18日時点の注目点は、Release Preview build 26100.8313 / 26200.8313 で「Remove Default Microsoft Store packages」ポリシーに dynamic app removal list が追加され、管理者がアプリの Package Family Name を指定して、削除対象をより柔軟に制御できるようになったことです。(Windows Blog)
結論から言えば、この変更は「Windows 11 のプリインストールアプリ削除を、手作業のスクリプト運用からポリシーベース管理へ寄せる」ための重要な前進です。ただし、現時点では Release Preview の更新であり、dynamic list は Intune Settings Catalog ではまだ利用できないと案内されています。検証は Group Policy または custom OMA-URI を前提に進めるのが現実的です。(Windows Blog)
Windows 11 のプリインストールアプリ削除は何が変わったのか
今回の更新で注目すべきなのは、Windows 11 Enterprise and Education 向けの「Policy-Based Removal of Preinstalled Microsoft Apps」です。
Microsoft は、Windows 11 Builds 26100.8313 and 26200.8313、KB5083631 を Release Preview Channel に提供し、その中で「Remove Default Microsoft Store packages」ポリシーに dynamic app removal list のサポートを追加したと説明しています。対象は Windows 11 version 24H2 の Build 26100 系と、Windows 11 version 25H2 の Build 26200 系です。(Windows Blog)
従来のポリシーベース削除では、管理者は用意されたアプリ一覧から削除対象を選ぶ運用が中心でした。今回の dynamic list により、追加の MSIX / APPX パッケージ化アプリについて、Package Family Name を指定して削除対象に含められるようになります。(Windows Blog)
これは、単に「消せるアプリが増えた」という話ではありません。企業や教育機関が、端末の用途、セキュリティ方針、サポート体制に合わせて、標準アプリの構成をより細かく統制できるようになるという意味があります。
たとえば、次のような現場で効果があります。
| 利用シーン | 管理者が実現したいこと | dynamic list が効く理由 |
|---|---|---|
| 学校・教育機関の端末 | 学習に不要なアプリやゲーム系アプリを減らす | 端末単位で削除対象を統一しやすい |
| コールセンター・窓口端末 | 業務に不要なアプリを表示させない | ユーザーごとの手作業削除を減らせる |
| 高セキュリティ部門 | 利用を許可したアプリだけに近い状態へ寄せる | アプリ追加・復元をポリシーで抑制しやすい |
| Autopilot 展開 | 初回サインイン前後の体験を標準化する | デバイス構成プロファイルと組み合わせやすい |
| グローバル企業 | 地域ごとに不要な Microsoft Store アプリを整理する | GPO や OMA-URI で構成をテンプレート化しやすい |
Remove Default Microsoft Store packages ポリシーの基本
「Remove Default Microsoft Store packages」は、Windows にあらかじめプロビジョニングされている Microsoft Store アプリを削除するためのデバイスレベルポリシーです。Microsoft Learn では、MDM、CSP 構成プロファイル、Group Policy で管理できる機能として説明されています。(Microsoft Learn)
重要なのは、このポリシーがユーザー単位ではなくデバイス単位で効くことです。つまり、同じ端末を複数ユーザーが使う場合、あるユーザーだけにアプリを残し、別のユーザーだけから消す、といった細かな例外制御には向きません。Microsoft Learn でも、アプリ削除を有効にした場合、そのデバイス上のすべてのユーザーに対して対象アプリが削除されると説明されています。(Microsoft Learn)
対象エディションと前提条件
現時点で押さえるべき前提は次の通りです。
| 項目 | 内容 |
|---|---|
| 対象エディション | Windows 11 Enterprise、Windows 11 Education |
| 管理単位 | デバイスレベル |
| 管理方法 | Intune、CSP / custom OMA-URI、Group Policy |
| GPO の場所 | Computer Configuration > Administrative Templates > Windows Components > App Package Deployment |
| ポリシー名 | Remove Default Microsoft Store packages from the system |
| 注意点 | multi-session 環境はサポート対象外と案内されている |
Microsoft Learn では、この機能の前提として Windows 11 version 25H2 以降、Enterprise / Education エディション、MDM 登録またはドメイン参加、そしてデバイスターゲティングが必要とされています。(Microsoft Learn)
一方、2026年4月17日の Windows Insider Blog では、Release Preview build 26100.8313 / 26200.8313 に dynamic app removal list の追加が案内されています。Release Preview の機能は段階的に提供される場合があるため、管理者は「対象ビルドなら全端末で即利用できる」と決めつけず、検証端末でポリシーの表示・適用・ログを確認する必要があります。(Windows Blog)
dynamic app removal list が管理者にもたらすメリット
dynamic app removal list の価値は、アプリ削除の対象を Microsoft が用意した固定リストだけに縛られにくくなる点にあります。
Microsoft の案内では、管理者はアプリの Package Family Name を指定することで、追加の MSIX / APPX パッケージ化アプリを削除できるとされています。(Windows Blog)
これにより、Windows enterprise admins は次のような運用に近づけます。
標準イメージの作り込みを減らせる
従来、不要な inbox apps を削除するために、展開イメージのカスタマイズ、PowerShell スクリプト、初回ログオン時の処理を組み合わせていた組織は少なくありません。
しかし、スクリプトベースの削除は、Windows Update、アプリの再プロビジョニング、ユーザーごとのインストール状態によって結果がぶれやすいのが難点です。ポリシーベース削除に寄せることで、「どの端末グループに、どのアプリ削除方針を適用したか」を GPO や MDM の管理画面で追いやすくなります。
ユーザーによる再インストールを抑制しやすい
Microsoft Learn では、削除対象として選択されたアプリは、ポリシーが有効な間は再インストールがブロックされると説明されています。(Microsoft Learn)
これは実務上かなり重要です。単にアプリをアンインストールしただけでは、ユーザーが Microsoft Store から再インストールできるケースがあります。業務端末で「消しても戻される」状態が続くと、管理者は問い合わせ対応や棚卸しに追われます。
ポリシーベースで削除と再インストール抑制を組み合わせることで、端末構成を一定に保ちやすくなります。
部門別・用途別のアプリ構成を作りやすい
企業の Windows 11 管理では、「全社共通の最小構成」と「部門ごとの例外」のバランスが重要です。
たとえば、次のように分けると運用しやすくなります。
| 端末グループ | 残すアプリの考え方 | 削除候補の考え方 |
|---|---|---|
| 一般業務端末 | Outlook、Teams、必要なユーティリティ | ゲーム、ニュース、天気など業務に不要なもの |
| 教室・演習室端末 | 授業で使うブラウザ、Office、学習ツール | 個人利用色の強いアプリ |
| キオスク端末 | 指定アプリ、Edge、認証に必要なコンポーネント | ほぼすべての不要アプリ |
| 開発者端末 | Terminal、Notepad、Paint など業務上使うもの | 組織で不要と判断したコンシューマー系アプリ |
| 共有端末 | サポートしやすい最小限のアプリ | ユーザーごとの利用差が大きいアプリ |
ポイントは、「使わないから消す」ではなく、「業務影響が小さく、サポート方針として削除してもよいものから始める」ことです。
GPO、Intune、custom OMA-URI のどれで管理すべきか
今回の dynamic list では、2026年4月時点の Microsoft の説明として「Intune Settings Catalog ではまだ利用できず、Group Policy または custom OMA-URI で検証する必要がある」とされています。(Windows Blog)
そのため、管理方法の選び方は次のように考えると実務に落とし込みやすくなります。
| 管理方法 | 向いている環境 | 注意点 |
|---|---|---|
| Group Policy | Active Directory 参加端末、オンプレ中心の管理 | 最新 ADMX テンプレートの更新が必要 |
| Intune Settings Catalog | クラウド管理中心、標準リストの削除を使う環境 | dynamic list の UI 反映は遅れる可能性がある |
| custom OMA-URI | Intune で先行検証したい環境 | XML / ADMX-backed policy の形式ミスに注意 |
| ローカル GPO | 単体検証、ラボ端末 | 本番運用にはスケールしにくい |
Microsoft Learn では、Group Policy を使う場合は最新の Windows 11 ADMX テンプレートを使うこと、Intune で設定がまだ表示されない場合は custom OMA-URI を一時的な回避策として使うことが案内されています。(Microsoft Learn)
ハイブリッド管理では二重設定を避ける
特に注意したいのが、Intune と GPO の二重設定です。
Microsoft Learn では、同じデバイスに Intune と GPO の両方で削除ポリシーを適用することは避けるべきだと説明されています。どちらのポリシーが後から到着したかによって結果が変わり、適用が予測しにくくなるためです。(Microsoft Learn)
ハイブリッド参加端末では、次のように整理しておくと事故を防げます。
| 状況 | 推奨される考え方 |
|---|---|
| 既存の GPO 管理が強い | まず GPO で検証し、Intune 側では同じ設定を作らない |
| Autopilot / Intune 主体 | custom OMA-URI で検証し、GPO では未構成にする |
| 移行期 | 対象 OU やデバイスグループを分け、同一端末に両方を当てない |
| トラブル発生時 | レジストリ、gpresult、MDM 診断ログで適用元を確認する |
dynamic list 検証前に作るべきアプリ削除ポリシー設計
アプリ削除は、技術的には簡単に見えても、運用上の影響が出やすい領域です。いきなり全社に展開するのではなく、次の順番で設計してください。
削除候補を「安全」「要確認」「原則残す」に分ける
まず、プリインストールアプリを一括で消すのではなく、業務影響に応じて分類します。
| 分類 | 判断基準 | 例 |
|---|---|---|
| 安全に削除しやすい | 業務利用がなく、代替手段が明確 | ゲーム系、ニュース系など |
| 要確認 | 一部部門で使う可能性がある | Photos、Paint、Camera、Quick Assist など |
| 原則残す | サポート、認証、業務フローに影響しやすい | Teams、Outlook、Terminal、Notepad など |
| 削除非推奨 | 既定のファイル種類やプロトコル処理に関わる | 既定ハンドラーになっているアプリ |
Microsoft の CSP ドキュメントでも、一般的なファイル種類やプロトコルの既定ハンドラーであるアプリを削除すると、ユーザー体験が低下する可能性があるため推奨しない旨が記載されています。(Microsoft Learn)
Package Family Name を正確に確認する
dynamic list では Package Family Name の指定が鍵になります。表示名やアプリ名だけで判断すると、別パッケージを対象にしたり、バージョン依存の PackageFullName と混同したりする恐れがあります。
検証端末で PowerShell を管理者権限で開き、次のように確認します。
Get-AppxPackage -AllUsers |
Select-Object Name, PackageFamilyName, PackageFullName |
Sort-Object NameMicrosoft の Get-AppxPackage ドキュメントでは、このコマンドレットがユーザープロファイルにインストールされた app packages の一覧を取得すると説明されています。また、-AllUsers を使う場合は管理者権限が必要です。(Microsoft Learn)
削除ポリシーに使う識別子は、原則として PackageFamilyName を確認してから登録します。PackageFullName はバージョンやアーキテクチャを含むため、アプリ更新で変わる可能性があります。運用テンプレートに残すなら、次のような棚卸し表を作ると後から見直しやすくなります。
| 表示名 | Name | PackageFamilyName | 削除方針 | 業務影響メモ |
|---|---|---|---|---|
| 例: Clipchamp | Microsoft.Clipchamp | 検証端末で確認 | 部門により削除 | 広報・教育部門で利用有無を確認 |
| 例: Weather | Microsoft.BingWeather | 検証端末で確認 | 削除候補 | 業務利用なしなら削除しやすい |
| 例: Quick Assist | MicrosoftCorporationII.QuickAssist | 検証端末で確認 | 要確認 | ヘルプデスクが使う場合は残す |
| 例: Windows Terminal | Microsoft.WindowsTerminal | 検証端末で確認 | 原則残す | 管理者・開発者端末で必要になりやすい |
ここで、インターネット上の一覧をそのまま貼り付けないことが大切です。アプリの提供状況、地域、ビルド、インストール状態によって確認結果が変わる可能性があります。必ず自社の標準ビルドで採取してください。
GPO で検証する手順
Release Preview build 26100.8313 / 26200.8313 の dynamic list は、まず GPO で検証するのが分かりやすい選択肢です。Microsoft の案内でも、dynamic list は Group Policy または custom OMA-URI で検証する必要があるとされています。(Windows Blog)
検証用 OU と端末を用意する
本番 OU にいきなりリンクせず、検証用 OU を作ります。対象端末は、業務ユーザーの本番端末ではなく、同じ Windows 11 エディションとビルドを持つ検証機にしてください。
最低限、次の3台で確認すると失敗に気づきやすくなります。
| 検証端末 | 目的 |
|---|---|
| 新規プロビジョニング端末 | OOBE / 初回サインイン時の削除確認 |
| 既存ユーザープロファイルあり端末 | サインアウト・サインイン後の挙動確認 |
| 例外部門相当の端末 | 残すべきアプリが消えないか確認 |
GPO の場所を開く
Group Policy Management Console で、対象 GPO を編集します。
Computer Configuration
> Administrative Templates
> Windows Components
> App Package Deployment
> Remove Default Microsoft Store packages from the systemMicrosoft Learn では、Group Policy のパスとしてこの場所が案内されています。ポリシーを有効にすると、HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx\RemoveDefaultMicrosoftStorePackages 配下に構成が反映されます。(Microsoft Learn)
削除対象アプリを選ぶ
従来のリストから削除対象を選び、dynamic list が利用できる環境では追加の Package Family Name を登録します。
本番投入前に確認すべき観点は次の通りです。
| 確認項目 | 見るポイント |
|---|---|
| ポリシーが端末に届くか | gpupdate /force 後にレジストリと gpresult を確認 |
| アプリが削除されるタイミング | OOBE、OS アップグレード後、ポリシー更新後のユーザーサインイン |
| 既存ユーザーの見え方 | すぐ消えない場合があるため再サインインで確認 |
| 再インストール抑制 | Microsoft Store から戻せないか確認 |
| 業務影響 | 既定アプリ、ファイル関連付け、ヘルプデスク手順を確認 |
Microsoft Learn では、削除処理は OOBE、OS アップグレード後のユーザーサインイン、ポリシー更新後のユーザーサインインで実行されると説明されています。また、既にサインイン中のセッションでポリシーを有効化しても、即時に削除されるわけではない点に注意が必要です。(Microsoft Learn)
Intune / custom OMA-URI で考える場合のポイント
Intune 管理の組織では、Settings Catalog で使いたくなるはずです。ただし、今回の dynamic list は、少なくとも Microsoft の 2026年4月17日時点の案内では Intune Settings Catalog では利用できないとされています。(Windows Blog)
そのため、Intune で先行検証するなら custom OMA-URI を使う想定になります。
Microsoft Learn では、RemoveDefaultMicrosoftStorePackages CSP の OMA-URI として次のパスが案内されています。(Microsoft Learn)
./Device/Vendor/MSFT/Policy/Config/ApplicationManagement/RemoveDefaultMicrosoftStorePackagesこのポリシーは ADMX-backed policy であり、CSP ドキュメントでは文字列形式の設定として扱われます。ADMX-backed policy は SyncML 形式や XML エンコードに注意が必要です。(Microsoft Learn)
custom OMA-URI で失敗しやすい点
| 失敗しやすい点 | 何が起きるか | 対策 |
|---|---|---|
| ユーザーグループに割り当てる | ポリシーが効かない、Not applicable になる | デバイスグループに割り当てる |
| XML の形式ミス | ポリシーが適用されない | 小さなアプリ数で検証してから増やす |
| Intune と GPO の二重適用 | 適用結果が予測しにくい | 管理チャネルを一つに決める |
| ESP 設定が不十分 | 初回サインイン時にアプリが一時表示される | Autopilot では ESP でデバイス構成完了を待つ |
| 削除後の復元手順を決めていない | 業務影響時に復旧が遅れる | 再プロビジョニング方法を事前に用意する |
Microsoft Learn では、Autopilot 利用時にポリシーがデバイス構成として早く届けば、ユーザーがデスクトップに到達する前にアプリ削除を実行できる可能性があると説明されています。一方、最初のサインイン時にポリシーが届いていない場合、アプリが一時的に表示されることがあります。(Microsoft Learn)
削除後の確認方法
ポリシーを適用したら、「画面から消えたか」だけで判断しないでください。スタートメニューの表示、Appx パッケージの状態、ログ、ポリシー適用状況をセットで確認します。
レジストリでポリシー受信を確認する
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx\RemoveDefaultMicrosoftStorePackages"Microsoft Learn では、このレジストリパス配下のキーの存在により、デバイスがポリシーを受信したことを確認できると説明されています。(Microsoft Learn)
PowerShell で Appx パッケージを確認する
Get-AppxPackage -AllUsers |
Select-Object Name, PackageFamilyName |
Sort-Object Name削除前と削除後で結果を保存しておくと、どのパッケージが残っているか比較できます。
Get-AppxPackage -AllUsers |
Select-Object Name, PackageFamilyName, PackageFullName |
Sort-Object Name |
Export-Csv C:\Temp\appx-after-policy.csv -NoTypeInformation -Encoding UTF8イベントログを確認する
Microsoft Learn では、AppxDeployment-Server の Operational ログで、削除成功や失敗に関するイベントを確認できると案内されています。たとえば Event ID 606 は初回ユーザーログオン後に削除ポリシーでパッケージが正常に削除された場合、Event ID 614 は削除に失敗した場合、Event ID 762 は削除ポリシーがある状態でパッケージインストールがトリガーされた場合に関連します。(Microsoft Learn)
Applications and Services Logs
> Microsoft
> Windows
> AppxDeployment-Server
> OperationalGPO の適用状況を確認する
GPO で検証している場合は、次のコマンドでレポートを出します。
gpresult /h C:\Temp\gpresult.htmlレポート内で RemoveDefaultMicrosoftStorePackages や App Package Deployment を確認します。
削除対象にする前に注意したいアプリ
プリインストールアプリの削除では、「不要そうに見えるが、現場では使われている」アプリに注意が必要です。
Quick Assist
Quick Assist は、ヘルプデスクがユーザー支援に使っている場合があります。削除すると、遠隔サポート手順そのものを変える必要が出ます。
Photos / Paint / Camera
業務で画像確認、簡易編集、本人確認、現場写真の確認などに使われることがあります。高度な業務アプリではないため軽視されがちですが、削除すると「ちょっと画像を開く」作業で問い合わせが発生することがあります。
Notepad / Windows Terminal
管理者や開発者向け端末では残す方が自然です。特に Windows Terminal は、PowerShell、コマンドプロンプト、WSL を使う環境では業務ツールとして扱うべきです。
Teams / Outlook for Windows
Microsoft 365 の利用方針と密接に関係します。クラシック版 Outlook、new Outlook、Teams の展開方針が混在している組織では、削除前にコミュニケーション基盤の責任者と確認してください。
削除後に戻したい場合の考え方
ここは管理者が見落としやすいポイントです。
Microsoft Learn では、ポリシーのアプリ一覧で対象アプリの選択を外しただけでは、削除済みアプリは再インストールされないと説明されています。削除後に戻すには、まず削除ポリシー側でブロックを外し、そのうえで Microsoft Store、ISO、Intune Win32 app、プロビジョニングパッケージなどで再プロビジョニングする必要があります。(Microsoft Learn)
つまり、削除ポリシーは「オンにしたら戻すのも簡単」と考えるべきではありません。少なくとも本番展開前に、次の復旧手順を用意しておくべきです。
| 復旧シナリオ | 必要な作業 |
|---|---|
| 誤って削除対象にした | ポリシーで対象を False / 未選択に変更し、同期または gpupdate を実行 |
| 一部部門だけ戻したい | 対象デバイスを別グループ・別 OU に移す |
| アプリを再インストールしたい | Store、Intune、ISO、プロビジョニングパッケージなどで再配布 |
| ユーザーが Store から戻せない | ポリシーでブロックが残っていないか確認 |
| スタートメニューにプレースホルダーが残る | ユーザーに意図したブロックであることを案内し、必要に応じてタイル整理を行う |
本番展開前のチェックリスト
dynamic app removal list を本番に入れる前に、次のチェックリストを満たしているか確認してください。
| チェック項目 | 合格基準 |
|---|---|
| 対象端末のエディション | Windows 11 Enterprise / Education である |
| 対象ビルド | 検証対象の Release Preview または対応済みビルドである |
| 管理チャネル | GPO、Intune、custom OMA-URI のどれか一つに統一している |
| ADMX | GPO 利用時は最新 Windows 11 ADMX を配置している |
| Package Family Name | 自社標準端末で取得した値を使っている |
| 削除対象 | 安全、要確認、残す、削除非推奨に分類済み |
| 業務影響 | ヘルプデスク、教育、開発、現場部門の利用を確認済み |
| 復旧手順 | 再プロビジョニング方法を用意済み |
| ログ確認 | レジストリ、PowerShell、Event Viewer、gpresult の確認手順がある |
| 段階展開 | 検証 OU / パイロットグループから開始する |
管理者が取るべき次のアクション
今回の dynamic app removal list は、Windows 11 Enterprise and Education の inbox apps 管理を、よりポリシーベースで標準化するための更新です。特に、GPO や custom OMA-URI でアプリ削除を厳密に管理したい Windows enterprise admins にとって、検証する価値があります。
ただし、現時点では Release Preview の更新であり、Intune Settings Catalog からすぐに dynamic list を操作できる段階ではありません。まずは検証端末で Package Family Name を棚卸しし、削除してよいアプリと残すべきアプリを分類してください。そのうえで、GPO または custom OMA-URI を使い、小さなデバイスグループから段階的に試すのが安全です。
最初にやるべきことは、全アプリの一括削除ではありません。自社の標準 Windows 11 Enterprise / Education 端末で Get-AppxPackage -AllUsers を実行し、削除候補リストと復旧手順をセットで作ることです。そこまで準備できれば、今回の dynamic list は、不要なプリインストールアプリを減らしつつ、サポートしやすい Windows 11 環境を作るための実用的な選択肢になります。
コメント