Windows 11 で wsappx の CPU 使用率が高くなり、「AppX Deployment Service（AppXSVC）を無効にすれば軽くなるのでは？」と考える方もいると思います。
結論からいうと、AppXSVC のスタートアップの種類が「自動」になっているだけなら、手動や無効へ変更する必要はありません。
Microsoft は、2025年12月に配信された KB5072033（OS ビルド 26200.7462 / 26100.7462）で、AppXSVC のスタートアップの種類を「自動」に変更しました。
Microsoft が公表している変更理由は、一部のシナリオにおける信頼性の向上です。
配信された当時、筆者環境でも実際に確認したところ、AppXSVC が「自動」の状態でも、何もしていないアイドル時の wsappx は次の状態でした。
- CPU 使用率：
0% - メモリー使用量：約
60MB
Microsoft Store でアプリの更新を実行した場合はメモリー使用量が増加し、CPU 使用率も一時的に上昇しました。
なお、2026年8月時点（Windows 11 Home、OS ビルド 26200.9168）で再確認したところ、アイドル時の wsappx のメモリー使用量は約 18MB でした。
筆者環境では、Microsoft Store で更新を確認しただけの場合、wsappx のメモリー使用量は数十 MB 増加し、CPU 使用率は一時的に約 25% 前後まで上昇しました。
更新可能なアプリが見つかって実際の更新処理が始まると、メモリー使用量は 170MB を超え、CPU 使用率も 50% を超えることがありました。
このことから、wsappx の負荷は一定ではなく、更新の有無や処理内容によって大きく変化することが分かります。更新確認だけであれば比較的軽い負荷ですが、アプリのダウンロードやインストール中は CPU とメモリーの使用量が大きく増える場合があります。
つまり、「AppXSVC が自動だから重い」のではなく、AppX / MSIX アプリのインストールや更新処理が実際に行われているときに負荷が上がると考える方が適切です。
wsappx と AppXSVC とは
wsappx は、Microsoft Store アプリや AppX / MSIX パッケージに関連する処理で表示されるプロセスです。
その中で AppX Deployment Service（AppXSVC）は、アプリ パッケージの展開、インストール、更新などに関係しています。
そのため、Microsoft Store でアプリをインストールしたり、バックグラウンドで Store アプリの更新が行われたりすると、wsappx の CPU 使用率が一時的に高くなることがあります。
これは処理が終了すれば負荷が下がるのであれば、基本的には異常ではありません。
実際に wsappx の負荷を確認してみた
筆者環境では、AppXSVC が「自動」になっている状態でリソース使用量を確認しました。
アイドル状態
PC 起動後、Microsoft Store などを操作せずに確認した結果です。
- CPU 使用率：
0% - メモリー使用量：約
18MB
この状態では、AppXSVC が自動起動されていても CPU を使用し続けているわけではありませんでした。
Microsoft Store のアプリ更新中
Microsoft Store でアプリの更新が行われている状態では、
- CPU 使用率：一時的に上昇し、50％ を超える
- メモリー使用量：
170MBを超える
となりました。
こちらは AppX / MSIX パッケージを処理しているため、負荷が増えること自体は不自然ではありません。
wsappx の CPU 使用率が高い場合に確認すること
まず、CPU 使用率が高い状態が一時的なのか、長時間続いているのかを確認してください。
Microsoft Store の更新中やアプリのインストール直後だけ高くなり、その後 0% 近くまで下がるのであれば、正常な処理である可能性があります。
一方、
- 長時間 CPU 使用率が高い
- PC を再起動しても繰り返す
- Microsoft Store を使用していないのに頻繁に発生する
- ファンが回り続ける
- PC の操作が明らかに重くなる
という場合は、Microsoft Store アプリの更新処理などが繰り返されていないか確認する価値があります。
また、筆者環境では、Microsoft Store で更新を確認すると wsappx だけでなく、Microsoft Defender の Antimalware Service Executable の CPU 使用率も同時に上昇することを確認しました。
一方、ESET を使用した環境では、同様の CPU 使用率上昇は確認できませんでした。
ただし、セキュリティソフトの種類だけでなく、リアルタイム保護やスキャン対象などの設定内容によっても挙動は変わる可能性があります。そのため、wsappx の CPU 使用率が高い場合は、使用しているセキュリティソフトの CPU 使用率も同時に確認すると、原因の切り分けに役立ちます。
Microsoft Store の自動更新は現在オフにできない場合がある
以前の Microsoft Store では、Store の設定画面からアプリの自動更新をオフにできました。
しかし現在の Microsoft Store では、環境によっては次のメッセージが表示され、自動更新を完全に停止できない状態になっています。
更新を一時停止できません
このデバイスで更新を一時停止するには、管理者特権が必要です。
筆者も読者からこの件について問い合わせを受け、実際に確認しました。
その際、レジストリの AutoDownload の値を変更することで、自動更新を停止できることを確認しています。
ただし、Microsoft Store アプリの自動更新を長期間停止したまま使用することはおすすめしません。
理由は後述します。
PowerShell で Microsoft Store の自動更新を一時停止する
レジストリ エディターを直接開いて値を書き換えることもできますが、値やキーを間違えて編集するリスクがあります。
このため、ここでは PowerShell から対象の値だけを変更します。
管理者としてターミナルを開き、まず現在の値を確認します。
Get-ItemPropertyValue -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsStore\WindowsUpdate" -Name AutoDownload筆者環境では通常、4になっていました。
自動更新を停止する場合は、次のコマンドを実行します。
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsStore\WindowsUpdate" -Name AutoDownload -Type DWord -Value 2もう一度、
Get-ItemPropertyValue -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsStore\WindowsUpdate" -Name AutoDownloadを実行し、2と表示されれば変更されています。
筆者環境では、AutoDownload = 2 に変更することで Microsoft Store アプリの自動更新が停止することを確認しました。
なお、このレジストリ位置については 筆者環境での実機検証結果です。
Microsoft が公開しているグループ ポリシー用の設定では、別のレジストリ パス、
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStoreの AutoDownload が使用され、
2：アプリの自動更新を無効4：アプリを自動更新
と定義されています。
このため、2 / 4 の意味そのものは Microsoft の公開情報とも一致しています。
コマンド プロンプトを使用する場合
管理者としてコマンド プロンプトを開き、次のコマンドでも変更できます。
コマンドプロンプトの開き方を見る
1.Windowsキー + R を押して「ファイル名を指定して実行」を開きます。
2.「cmd」と入力します。
3.Shiftキー ＋ Ctrlキーを押しながら Enter を押してください。
4.「ユーザーアカウント制御」が表示されたら「はい」をクリックします。
現在値の確認：
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsStore\WindowsUpdate" /v AutoDownload自動更新を停止：
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsStore\WindowsUpdate" /v AutoDownload /t REG_DWORD /d 2 /fMicrosoft Store の自動更新を元に戻す
確認が終わったら、基本的には自動更新を元に戻すことをおすすめします。
PowerShell の場合：
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsStore\WindowsUpdate" -Name AutoDownload -Type DWord -Value 4コマンド プロンプトの場合：
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsStore\WindowsUpdate" /v AutoDownload /t REG_DWORD /d 4 /fその後、現在値を確認して 4 に戻っていることを確認してください。
Store の自動更新を停止したままにしない方がよい理由
Microsoft Store の自動更新を止めると、バックグラウンドでアプリが更新されることを防げます。
そのため、「wsappx の高負荷が Store アプリの自動更新によるものなのか」を切り分ける目的では有効です。
しかし、常時停止する設定としてはおすすめしません。
Microsoft は、Windows Update には Microsoft Store アプリの更新プログラムが含まれないと明記しています。
つまり、
Windows Update
↓
Windows のシステム コンポーネントが更新される
Microsoft Store
↓
Store 経由で配布されるアプリやコンポーネントが更新されるというように、更新経路が分かれています。
Windows 11 では、一部のシステム機能が Store 経由で更新されるアプリやコンポーネントと連携しています。
そのため、Windows 側だけ新しくなり、依存する Store アプリが古いまま残るという組み合わせになると、正常に動作しなくなる場合があります。
筆者も以前、Windows Update 後に Windows のシステム側だけが更新され、関連する「問い合わせ」アプリが古いままだったことで不具合が発生したケースを経験しています。
Store アプリを更新すると問題が解消しました。
この経験からも、Microsoft Store の自動更新を停止する設定は、高負荷の原因を調査するための一時的な切り分けとして使用することをおすすめします。
自動更新を停止した場合は手動で更新する
自動更新を一時停止した状態で使用する場合は、Microsoft Store を定期的に開いてアプリを手動更新してください。
特に Windows Update を適用した後は、Store 側にも更新がないか確認しておくと安全です。
AppXSVC を「手動」や「無効」に戻すのはおすすめしない
wsappx の CPU 使用率が高いからといって、AppXSVC 自体を無効化することはおすすめしません。
KB5072033 で Microsoft が意図的に AppXSVC を「自動」へ変更しており、その理由として信頼性向上を挙げています。
また、筆者環境では AppXSVC が「自動」の状態でも、アイドル時の CPU 使用率は 0% でした。
したがって、「自動 = 常に CPU を使用している」ではありません。
高負荷が発生している場合は、サービスの起動種類を変更するよりも、そのとき AppXSVC が何の処理をしているのかを調べる方が重要です。
まとめ
Windows 11 の wsappx や AppXSVC の CPU 使用率が高くなった場合、AppXSVC のスタートアップが「自動」になっていることだけを原因と考えないようにしてください。
Microsoft は KB5072033 で、信頼性向上を目的として AppXSVC を「自動」へ変更しています。
筆者環境では、
- アイドル時：CPU
0%、メモリー約18MB - Store 更新時：CPU が一時的に上昇、メモリー
170MBを超える
という結果でした。
そのため、負荷が高い場合は、
- 一時的な Store 更新処理か確認する
- 高負荷が長時間続くか確認する
- 必要なら Store 自動更新を一時停止して切り分ける
- 原因確認後は自動更新を元に戻す
という順番がおすすめです。
特に、Microsoft Store の自動更新を恒久的に停止することはおすすめしません。
Windows Update と Store アプリの更新は別経路であり、Windows 側だけが更新されて Store アプリが古いままだと、依存関係によって不具合につながる可能性があります。Microsoft も Windows Update に Store アプリの更新は含まれないことを明記しています。
コメント