UWPオプションパッケージを削除するとメインアプリも消える問題｜Windows 11 23H2のAppListEntry=”none”挙動と回避策

UWP ベースの製品で「オプション パッケージ（Add‑On）」だけを削除したはずが、メイン アプリまで一緒に消えてしまう——最近の Windows 11 23H2 環境で報告が増えている現象です。本稿では、AppListEntry="none" を両者に設定したときにのみ再現する点に着目し、再現条件、検証手順、原因の推測、実務的な回避策、そして社内周知や QA の観点まで、現場で役立つ形で詳細に整理します。

問題の全体像と結論（先に要点）

次の構成でのみ、オプション パッケージのアンインストール時にメイン アプリが同時に削除される事象が再現します。

• メイン アプリ（例：AtomicSuite）と、依存するオプション パッケージ（Add‑On）がある。
• 両方の Package.appxmanifest の VisualElements に AppListEntry="none" を設定している（＝スタート メニューに非表示）。

この条件を外し、どちらか一方（推奨はメイン アプリ側）から AppListEntry="none" を外すと、オプション パッケージだけを安全に削除でき、メイン アプリは残ります。通常の依存関係ルール（メイン ← オプション）に照らすと OS 側の挙動に起因する可能性が高く、重大なビジネス影響がある製品では MS サポート チケットの起票を推奨します。

背景：UWP オプション パッケージと AppListEntry の役割

UWP／MSIX のオプション パッケージ（Optional Package, Add‑On）は、メイン アプリに追加機能・コンテンツを提供するためのパッケージです。仕組みとしては、オプション パッケージがメイン アプリへ依存（MainPackageDependency）し、メイン アプリはオプション パッケージに依存しません。したがって、通常はオプション パッケージを削除してもメイン アプリが消えることはありません。

一方、AppListEntry はスタート メニューへの表示制御を担う属性で、"none" を指定すると「起動エントリを作らない（ユーザーに表示しない）」という扱いになります。運用上は「ユーザーが直接起動しない補助モジュール」や「検証用途の構成」で使われることがあります。

典型的なマニフェスト例（メイン アプリ）

<Package ... xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10">

典型的なマニフェスト例（オプション パッケージ）

<Package ... xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10">

上記のように両方のパッケージで AppListEntry="none" を設定しているときに、本事象が発生します。

現象の詳細

• 操作手順：設定 > アプリ > インストール済みアプリ からオプション パッケージのみをアンインストール。
• 期待結果：メイン アプリは残る。
• 実際の結果：メイン アプリまで同時に削除される。

再現条件の簡易マトリクス

メイン アプリの AppListEntry	オプション パッケージの AppListEntry	結果（オプション削除時）
none	none	メインも削除される（再現）
none	未設定 or 表示	オプションのみ削除、メインは残る
未設定 or 表示	none	オプションのみ削除、メインは残る
未設定 or 表示	未設定 or 表示	オプションのみ削除、メインは残る

この挙動は、Windows 11 23H2 の複数のビルド（例：22631.4037 など）で確認されています。OS のバージョン差やエディションによる再現率の違いは今のところ決定打はなく、AppListEntry の組み合わせがもっとも重要なトリガーになっています。

推測される原因（技術的考察）

公式に「バグ」と明言されているわけではありませんが、通常の依存関係（メインは独立、オプションは従属）のルールと結果が逆転しているため、OS のアンインストーラが「起動エントリを持たないアプリ群」を一体として扱ってしまう可能性が考えられます。特に AppListEntry="none" は UI 上の表示抑制だけでなく、内部の「ユーザーが直接起動しない構成（ヘッドレス）」のヒントとして評価されている節があり、関連付くパッケージをまとめてクリーンアップするロジックに誤って巻き込まれている、という推測です。

また、設定アプリのアンインストール パスは、PowerShell の Remove-AppxPackage 直叩きと比較して、関連パッケージの探索や順序制御が追加実装されている可能性があり、ここでの依存解決が正しく働かない場合、結果としてメイン アプリに対しても削除フラグが伝播してしまうことがあり得ます。

再現手順（開発者向け検証スクリプト付き）

以下はローカル sideload 環境での検証例です。製品名やパスは適宜読み替えてください。

1) インストール

# 管理者 PowerShell


# メイン アプリをインストール

Add-AppxPackage -Path "C:\Packages\AtomicSuite_1.0.0.0_x64.msix"

# オプション パッケージをインストール（メインに依存）

Add-AppxPackage -Path "C:\Packages\AtomicSuite.AddOn_1.0.0.0_x64.msix" 

2) オプションだけを削除（設定アプリ操作の代替としてコマンドで検証）

# オプション パッケージのパッケージ ファミリ名を検索


Get-AppxPackage | Where-Object {$_.Name -like "AtomicSuite.AddOn*"} | Select Name, PackageFullName

# オプション パッケージを削除

Remove-AppxPackage -Package "AtomicSuite.AddOn_1.0.0.0_x64__publisher" 

3) 検証

# メインが残っているか


Get-AppxPackage | Where-Object {$_.Name -like "AtomicSuite*"} | Select Name, PackageFullName, Status 

OS や UI パスの違いで挙動が変わることがあるため、設定アプリ（GUI）と PowerShell の両方で確認することをお勧めします。発生環境では、GUI からのアンインストール時にメインが巻き添えで削除されやすいという報告が多い傾向です。

設計別の検証チェックリスト

観点	確認ポイント	合否の目安
AppListEntry	メインとオプションの双方に none を設定していないか	どちらか一方は none を避ける
依存関係	オプションに MainPackageDependency が正しく設定されているか	メインの識別子・発行元・バージョンが一致
アンインストール	GUI と PowerShell の双方で挙動を確認したか	オプションのみ削除できること
ログ	AppX 展開/削除ログに異常な依存解決が出ていないか	エラー/警告がないこと

対処方針（優先度順の推奨）

重大インシデント相当（本番影響）

• 即時の回避策：メイン アプリ側から AppListEntry="none" を外す（＝スタート メニューにはメインのみ表示）。もしくは、メインは表示のまま、オプション側だけ none にする。
• プロダクト変更：リリース中の MSIX/Appx を更新（マイナーバージョンで可）。
• サポート対応：Microsoft へサポート チケットを起票（Developer Tools → Windows UWP Development → Windows Universal App Dev → Runtime Platform）。

検証・パイロット段階

• フィードバック：Feedback Hub で「Developer Platform → API Feedback」を選択し、再現手順・ログ・動画を添付。
• 社内共有：QA/CS 向けに「既知の制限」として周知（テンプレートは後述）。

恒久対策の選択肢

• 起動 UI の整理：メイン アプリはユーザー可視、オプションは不可視に統一。
• 機能提供方式の見直し：オプション パッケージではなく、アプリ内ダウンロード/有効化（例：AppExtension 的な設計、またはクラウド連携）へ移行。
• インストーラー側で制御：ユーザーにアンインストール操作をさせず、アプリ設定画面から機能 ON/OFF のみを操作（パッケージ削除ではなく機能フラグ切替）。

意思決定のための比較表

選択肢	メリット	デメリット	適用場面
メインのみ表示	ユーザー操作が明快。巻き添え削除の回避。	スタート メニューにアイコンが増える。	一般消費者向け/業務端末での標準
オプションのみ非表示	追加機能を裏方化。誤操作を抑制。	開発/サポート時に起動確認がしづらい。	コンテンツや言語パックのような補助機能
両方非表示	検証/自動化で便利な場合もある。	本件のリスク（メイン削除）。UX が不明瞭。	限定的な検証・PoC のみに推奨

設定例：安全なマニフェストへの書き換え

推奨パターン A（メインを表示・オプションは非表示）

もっとも事故が少ない構成です。

<!-- Main: 表示（AppListEntry 属性を削除 or 設定しない） -->







 

推奨パターン B（両方表示）

サポート/検証容易性を優先する場合に検討します。

<uap:VisualElements DisplayName="AtomicSuite" ... > </uap:VisualElements>


  

運用：ログ採取と事後検証

現象を再現した端末から、次の情報を収集しておくと、原因切り分けとサポート連携がスムーズです。

• イベント ログ：イベント ビューアー → アプリケーションとサービス ログ → Microsoft → Windows → AppXDeployment-Server → Operational。アンインストール要求、依存解決、関連パッケージの扱いに関するイベントを時系列でエクスポート。
• パッケージ情報：Get-AppxPackage の出力（Name、PackageFullName、Publisher、Version）。
• マニフェスト：ビルド時の Package.appxmanifest（VisualElements の実設定）とシンボル付きビルド番号。
• 再現動画：設定アプリでの削除操作から削除完了まで。

簡易ダンプ スクリプト

$name = "AtomicSuite"


Get-AppxPackage | Where-Object {$_.Name -like "$name*"} |
Select-Object Name, PackageFullName, Publisher, Version, InstallLocation |
Format-List 

品質保証（QA）観点：テスト ケース提案

次の観点を回帰テストに組み込むことで、OS 更新やパッケージ更新による再発を抑制します。

• 組み合わせ網羅：AppListEntry の 4 パターン（前掲マトリクス）をすべて検証。
• 削除パスの差分：設定アプリ、PowerShell、会社独自の管理ツール（MDM 等）でそれぞれ挙動を比較。
• 多ユーザー環境：ローカル管理者と一般ユーザー、複数プロファイルでの有無。
• バージョン相違：メイン 1.0 + オプション 1.1 など、クロス バージョンの削除挙動。
• OS ロールアウト：Windows Update 前後の差分（23H2 の月次品質更新を含む）。

テスト結果の記録サンプル

OS ビルド	メイン	オプション	削除パス	結果	備考
22631.4037	AppListEntry=none	AppListEntry=none	設定アプリ	メインも削除（再現）	UI 表示抑制構成
22631.4037	表示	AppListEntry=none	設定アプリ	OK（オプションのみ）	推奨構成
22631.4037	AppListEntry=none	表示	PowerShell	OK（オプションのみ）	回避構成

ユーザー保護の設計：誤操作と権限管理

本件は「ユーザーがオプションを誤って削除した」ことから顕在化するケースが多く、UI/権限設計で被害を最小化できます。

• アプリ内の機能 ON/OFF：パッケージ削除ではなくアプリ設定のフラグ切替に置換。
• 管理者専用の削除導線：MDM/Intune で IT 管理者のみがオプション配布・回収。
• アラート表示：オプション削除前に「メインに影響が及ぶ可能性」を警告（現象が解消するまでの暫定）。
• 診断レポート自動収集：削除失敗や巻き添え検知時に、イベント ログ・バージョン情報を zip 化してサポートへ送付可能に。

よくある質問（FAQ）

Q. AppListEntry="none" にしたのに検索結果や「設定 > アプリ」から見えてしまいます。非表示じゃないの？

A. AppListEntry="none" はスタート メニューの起動エントリを抑制するもので、すべての UI からの非表示を保証する属性ではありません。検索や設定の一覧には表示され得ます。

Q. オプション パッケージを完全にユーザーから触れないようにするには？

A. 機能の配布/回収をアプリ内フラグやサーバー連携で制御し、パッケージの追加・削除という操作自体をユーザーに与えない設計が有効です。IT 管理下の端末では MDM での配信/回収も選択肢です。

Q. 既に巻き添えでメインが削除されました。復旧は？

A. ストア・配布サーバー・MSIX からメインを再インストールしてください。設定/ユーザーデータはクラウド ローミングやプロファイル設計により復元性が異なるため、バックアップ/サインイン同期の戦略を併用してください。

社内向けアナウンスのテンプレート（コピペ可）

【お知らせ】Optional Package アンインストール時の注意
対象: Windows 11 23H2 端末、AtomicSuite v1.x 系
内容: オプション パッケージのみ削除しても、条件によりメイン アプリが同時に削除される可能性があります。
条件: メイン/オプションの両方で AppListEntry="none" を設定した構成
暫定対策: メイン側は AppListEntry を設定しない（表示）/ オプション側のみ "none"
ユーザー向け案内: 機能停止は「アプリ内の設定」から実施し、設定アプリのアンインストールは行わないでください。
問合せ先: プロダクトサポート（内線 1234 / メール support@example）

実務 Tips：ビルドと配布の安全弁

• CI のマニフェスト検査：ビルド前に AppListEntry="none" がメイン/オプション双方に同時指定されていないかを XML で静的解析。
• 段階的配布：社内リング（開発 → 早期利用 → 全社）の順でロールアウトし、設定アプリ経由の削除操作を敢えて混ぜたテストを事前実施。
• テレメトリ：アンインストール起点の再インストール率を監視。異常値を検知したらプロンプト導線の改善を優先。

静的検査のサンプル（PowerShell）

# ビルド成果物中の 2 つの manifest を読み、同時 "none" を検出


[xml]$main = Get-Content ".\Main\Package.appxmanifest"
[xml]$opt  = Get-Content ".\Optional\Package.appxmanifest"

$mainNone = $main.Package.Applications.Application.VisualElements.AppListEntry -eq "none"
$optNone  = $opt.Package.Applications.Application.VisualElements.AppListEntry -eq "none"

if ($mainNone -and $optNone) {
Write-Error "メイン/オプション双方に AppListEntry='none' が設定されています。ビルドを停止します。"
exit 1
} else {
Write-Host "OK: 安全な構成です。"
} 

まとめ：安全な既定と継続的な観測を

本事象は、両パッケージに AppListEntry="none" を設定したときにのみ顕在化する、依存関係の常識に反する挙動です。根本的な修正が入るまでは、

• メインは表示（AppListEntry を外す）、オプションは非表示、の一貫したポリシーにする。
• アンインストールは原則ユーザーにさせず、アプリ内の機能切替で対応する。
• 発生時のログ/証跡を整備し、重大影響があればサポート起票を行う。

設計・QA・運用にまたがる「安全弁」を重ねることで、巻き添え削除という最悪の体験を未然に防ぐことができます。プロダクトの信頼性とユーザーの生産性を守るために、今日からチェックリストを CI に組み込み、テスト計画に反映していきましょう。

付録：トラブルシューティング早見表

症状	確認すること	一次対処	二次対処
オプション削除でメインも消えた	両方の AppListEntry が none か	メインを再インストール、構成変更	ログ添付でサポート起票
ユーザーがオプションを頻繁に削除	UI に削除導線が残っているか	削除導線の撤去/警告追加	機能フラグ化・MDM 制御
検証端末だけ再現	OS ビルド差、配布経路の差	同一ビルド/同一パスで再試験	環境差分の抽出と是正

再掲：推奨アクション表

影響度	推奨アクション	詳細
重大なビジネス影響	Microsoft サポート チケットを起票	「Developer Tools → Windows UWP Development → Windows Universal App Dev → Runtime Platform」を選択。Microsoft 側の不具合と判断されれば無償対応。
軽微・検証レベル	Feedback Hub に投稿	カテゴリは「Developer Platform → API Feedback」。再現手順・ログを添付。MSFT 回答者が社内転送を実施。
回避策（当面）	どちらか一方のみ AppListEntry="none"	推奨は「メインは表示、オプションを非表示」。この構成ではオプション削除時もメインは残ることを確認済み。