「Windows PowerShell をアンインストールしたいのに、設定の［アプリ］→［インストールされているアプリ／追加と削除］に出てこない」──この現象は正常です。本記事では PowerShell 5.1 と PowerShell 7 を見分け、消すべきでない理由と、代わりに“使わせない”ための現実的な制御方法を具体的に解説します。
Windows PowerShell が「追加/削除」に出てこないのは不具合ではない
まず押さえておきたいのは、一般的に「アプリの追加/削除（設定のアプリ一覧）」に表示されるのは、主に次のような“アプリとしてインストールされたもの”だという点です。
- Microsoft Store アプリ
- MSI/EXE で追加インストールしたアプリ
- 一部のドライバやランタイム（製品による）
一方で Windows PowerShell（特に Windows に標準搭載される 5.1 系）は、多くの Windows 環境で「OS の中核コンポーネント」に近い扱いです。Windows の管理機能や内部処理、周辺ツールが PowerShell に依存しているケースもあるため、通常のアプリのように“単体で完全アンインストール”する導線は用意されていません。
最初に確認：あなたが消したいのは「Windows PowerShell 5.1」か「PowerShell 7」か
「PowerShell」と一口に言っても、Windows には大きく分けて 2 系統が存在します。ここを取り違えると、不要な作業をしたり、逆に必要なものを残したままになったりします。
| 項目 | Windows PowerShell（5.1 など） | PowerShell（7.x：pwsh） |
|---|---|---|
| 位置づけ | Windows に標準搭載（OS の一部） | 別途インストールする新系統（アプリ） |
| 実行ファイル | powershell.exe | pwsh.exe |
| 代表的な場所 | C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe | C:\Program Files\PowerShell\7\pwsh.exe |
| 「追加/削除」に表示 | 基本的に表示されない | 表示される（インストール方法による） |
| 削除の考え方 | 原則アンインストール不可（非推奨） | 通常のアプリ同様にアンインストール可能 |
自分の PowerShell の種類とバージョンを確認する方法
PowerShell を開いて、次のコマンドを実行すると判断がつきます。
$PSVersionTable.PSVersion
加えて、実行ファイルのパスを見ればより確実です。
where powershell
where pwsh
結論：Windows PowerShell（主に 5.1）はアンインストール前提ではない
Windows PowerShell 5.1 は、Windows 10/11 や Windows Server の多くで標準搭載されており、管理系の仕組みや一部の標準ツールが内部で呼び出すことがあります。ここを無理に削ると、目に見えて壊れる機能が出ないように見えても、後から次のような問題として表面化しやすくなります。
- 管理ツールやスクリプトの一部が動かない／エラーになる
- 更新処理や構成変更の一部で想定外の失敗が起きる
- トラブル時の復旧手段（診断・修復）が減る
- 別の機能の修復に時間がかかる（原因が PowerShell だと気づきにくい）
そのため、個人 PC でも業務端末でも、基本方針は 「消す」のではなく「使わせない・実行を制限する」です。
「アンインストールしたい」という要望が出やすい代表的な理由
現場でよくある背景を整理すると、対処を決めやすくなります。
| よくある動機 | 想定される状況 | おすすめの方向性 |
|---|---|---|
| セキュリティ的に不安 | 攻撃で PowerShell が悪用されると聞いた | ログ強化＋実行制御（AppLocker/WDAC/ポリシー） |
| 使う予定がない | 一般ユーザーに触らせたくない | ショートカット非表示＋起動制限 |
| 古いスクリプトが残っていて怖い | 誰が何を実行しているかわからない | 監査（記録）を整備して段階的に制御 |
| PowerShell 7 を入れた覚えがある | 7 系（pwsh）を削除したい | アプリとしてアンインストール |
どうしても「消したい」に近づけるなら：PowerShell 2.0 を無効化する
完全なアンインストールではありませんが、環境によっては 古い PowerShell 2.0（互換機能）が有効になっていることがあります。2.0 は古い仕様で、現在の運用では不要なことが多いため、攻撃面（アタックサーフェス）を減らす目的で無効化を検討する価値があります。
ただし、端末の世代や構成によって項目が出ない場合もあります。表示されない場合は「元から無効」か「その機能が存在しない」ケースが多いです。
GUI（画面）から PowerShell 2.0 を無効化する手順
- 「Windows の機能の有効化または無効化」を開く（optionalfeatures.exe と入力してもOK）
- 一覧から 「Windows PowerShell 2.0」（または類似の項目）を探す
- チェックが付いていれば外す
- 再起動が求められたら再起動する
DISM で PowerShell 2.0 を無効化する例
管理者権限のコマンド プロンプト（または PowerShell）で実行します。
dism /online /Disable-Feature /FeatureName:MicrosoftWindowsPowerShellV2 /NoRestart
dism /online /Disable-Feature /FeatureName:MicrosoftWindowsPowerShellV2Root /NoRestart
実行後は再起動して反映を確認します。組織端末では、先に検証機で影響確認してから展開するのが安全です。
PowerShell 7（pwsh）が対象なら：通常のアプリとしてアンインストールできる
もし削除したいのが PowerShell 7（新しい PowerShell）であれば、こちらはアプリとしてインストールされているため、一般的な手順でアンインストールできます。
設定画面からのアンインストール
- ［設定］→［アプリ］→［インストールされているアプリ］（または［アプリと機能］）
- 検索欄に PowerShell と入力
- 「PowerShell 7.x」など該当項目のメニューからアンインストール
winget でアンインストールする例
端末の管理や自動化に慣れている場合は、winget を使うと状況把握がしやすいことがあります。
winget list --name PowerShell
winget uninstall --name "PowerShell"
インストール方法（MSI / Store / 企業配布）によって識別名が異なるため、まず list で表示を確認してから uninstall するのがコツです。
現実的な解決策：「消す」のではなく「使わせない／実行させない」
Windows PowerShell 5.1 を無理に削除しようとすると、将来の更新やトラブルシュートで詰みやすくなります。そこで、要件に合わせて次のいずれか（または組み合わせ）で 実行を制御するのが現実的です。
個人PC・小規模環境でやりやすい対策
- ショートカットを非表示（スタートメニュー、タスクバー、配布アイコンなど）
- 既定のターミナルを変更（Windows Terminal を使っている場合、既定プロファイルを「コマンド プロンプト」や別シェルに）
- 一般ユーザーの権限を絞る（最小権限運用に寄せる）
ただし、ショートカットを消すだけでは、ファイル名指定実行や別経路で起動できるため「抑止」止まりです。実行そのものを止めたい場合は次の“制御系”が必要になります。
組織端末・セキュリティ要件がある環境での定番
| 方法 | 止められる強さ | 導入難易度 | 向いているケース |
|---|---|---|---|
| グループポリシー（スクリプト実行の制御） | 中（設定次第） | 低〜中 | 「ps1 を走らせたくない」などスクリプト中心の制御 |
| AppLocker | 高 | 中 | 特定 EXE（powershell.exe / pwsh.exe）自体をブロックしたい |
| WDAC（Windows Defender Application Control） | 非常に高 | 高 | ゼロトラスト寄りの堅牢運用、ホワイトリスト設計 |
| SRP（ソフトウェア制限ポリシー） | 中〜高 | 中 | 古い運用や簡易ブロック（環境次第） |
グループポリシーで「スクリプト実行」を制御する考え方
グループポリシーには、PowerShell のスクリプト実行に関する設定が用意されています。代表的には、端末に対して 署名済みスクリプトのみ許可のような運用に寄せることで、野良スクリプト実行のリスクを下げられます。
注意点として、実行ポリシー（ExecutionPolicy）は「強いセキュリティ境界」ではなく、ユーザーが回避できる場面もあります。確実に止めたい場合は AppLocker / WDAC のようなアプリ制御が必要です。
AppLocker で powershell.exe / pwsh.exe をブロックするポイント
AppLocker を使う場合は、次の 3 点をセットで考えると失敗しにくいです。
- ブロック対象を網羅：powershell.exe、pwsh.exe、powershell_ise.exe（必要なら）
- 例外（許可）を設計：管理者や特定端末は許可、運用スクリプトは署名して許可
- 監査モードで検証してから強制：いきなり強制すると業務影響が出やすい
特に「監査モード → ログで影響確認 → 段階的に強制」は、トラブルを最小化する基本ルートです。
ログ（監査）を強化して“悪用されても追える”状態にする
PowerShell を完全に消せない以上、検知と追跡もセットで整えるとセキュリティ対策として完成度が上がります。具体例としては次のようなものがあります。
- スクリプトブロックログ（Script Block Logging）
- モジュールログ（Module Logging）
- トランスクリプション（実行履歴の記録）
「止める」だけだと、例外運用や管理者作業で結局 PowerShell を使う場面が残ります。だからこそ、許可する場面を最小にしつつ、許可した範囲は記録するという設計が現実的です。
Windows 10/11 のエディション別：使える「実行制御」が変わる
PowerShell を制御する方法はいくつかありますが、Windows のエディションによって“使える武器”が変わります。特に AppLocker はエディション制限があるため、検討時にここを見落とすと「設定したのに効かない」という事故につながります。
| エディション | グループポリシー（ローカル/ドメイン） | AppLocker | WDAC | 現実的な落としどころ |
|---|---|---|---|---|
| Home | 制限が多い | 基本的に利用不可 | 運用が難しいことが多い | ショートカット抑止＋権限管理＋端末用途を限定 |
| Pro | 利用可（ドメイン参加も可） | 組織要件次第で制限あり | 設計・検証が必要 | ポリシー＋監査ログ強化、必要なら上位版へ |
| Enterprise / Education | 利用可 | 利用可 | 利用可 | AppLocker/WDAC で強制＋監査を標準化 |
端末が Home の場合、「アンインストールしたい」という相談が出がちですが、実は“制御手段が限られる”ことが背景になっているケースもあります。業務で制御が必要なら、端末エディションや管理方式（Intune など）を含めて見直す方が根本解決になります。
Windows Terminal の既定プロファイルを変更して「うっかり起動」を減らす
Windows 11 では Windows Terminal が標準で入っていることが多く、ターミナルを開いた時に PowerShell が既定になっている環境もあります。PowerShell を禁止まではしないにしても、一般ユーザーに触らせたくない場合は、既定を「コマンド プロンプト」に寄せるだけで問い合わせが減ることがあります。
- Windows Terminal を開く
- 設定（歯車アイコン）を開く
- 「起動」または「Startup」相当の項目で 既定のプロファイルを選ぶ
- 「コマンド プロンプト」や、許可している別シェルに変更して保存
これは“権限制御”ではなく UI 上の抑止ですが、特に共有 PC・キオスク端末などでは効果が出やすい小技です。
実行ポリシー（ExecutionPolicy）でできること・できないこと
PowerShell の実行ポリシーは、スクリプトの実行条件を制御する仕組みです。ただし、設計上「誤操作を防ぐ」色が強く、強い攻撃者を止めるための防御壁にはなりません。それでも、運用ルールとしては有効なので、役割を理解したうえで使うのがおすすめです。
| ポリシー | 概要 | 向いている場面 | 注意点 |
|---|---|---|---|
| Restricted | 原則としてスクリプト実行を禁止 | 一般ユーザー端末で「誤って実行」を減らす | 運用で必要なスクリプトが動かなくなる |
| AllSigned | 署名済みスクリプトのみ許可 | 企業での標準運用（署名基盤あり） | 署名プロセス整備が必須 |
| RemoteSigned | 外部から入手したスクリプトに署名を要求 | 開発者PCや小規模運用の折衷 | 内部作成スクリプトは動くため過信しない |
現在の設定を確認する例：
Get-ExecutionPolicy -List
ポリシーを変更する例（管理者権限が必要なことがあります）：
Set-ExecutionPolicy -ExecutionPolicy AllSigned -Scope LocalMachine
「確実に PowerShell を起動させない」ことが目的なら、ExecutionPolicy だけで完結させず、AppLocker/WDAC のような実行制御を本線にしてください。
チェックリスト：PowerShell を整理・制御する前に確認しておくこと
- PowerShell 7（pwsh）が入っていないか（追加インストールの有無）
- PowerShell 2.0 の互換機能が有効になっていないか
- 業務アプリや運用ツールが PowerShell を呼び出していないか
- 管理者作業（パッチ適用、監視、バックアップ）に PowerShell を使っていないか
- ブロックするなら「例外（許可）」の設計ができているか
- 監査ログをどこに集約し、誰が見るか（運用体制）
この確認を飛ばすと、「止めたら業務が止まった」「止めたのに抜け道が残っていた」といったトラブルになりがちです。焦ってアンインストール方向に走る前に、まずは現状把握から着手しましょう。
「インストールされた更新プログラム」に PowerShell 関連が見える場合の考え方
質問でよく挙がるのが、「コントロール パネル → プログラムと機能 → インストールされた更新プログラム」に Windows Management Framework（WMF）のような項目が見えるケースです。
これは主に、古い OS 世代（例：Windows 7 / Windows Server 2008 R2 など）で PowerShell を含む管理フレームワークを更新として導入していた名残です。該当更新をアンインストールできる場合もありますが、次のようなリスクがあります。
- .NET や管理系コンポーネントとセットで変化し、別機能が壊れる
- OS が想定する管理フレームワークのバージョンが戻り、運用が崩れる
- 更新の再適用や整合性の修復で手間が増える
「消せるように見えるから消す」のではなく、その端末で PowerShell に依存している機能がないかを先に洗い出してから判断してください。業務端末なら、検証機で十分にテストしてからが前提です。
やってはいけない対応：ファイル削除・リネーム・権限いじりでの“力技”
検索すると「powershell.exe を削除する」「System32 の実行ファイルをリネームする」「権限を外して起動できなくする」などの情報を見かけます。しかし、これはおすすめできません。
- システム保護（Windows Resource Protection）や更新で元に戻ることがある
- 別コンポーネントの整合性が崩れ、想定外の不具合が出る
- トラブル時に復旧手段が減り、結果として復旧コストが跳ね上がる
「PowerShell をなくしたい」という目的に対して、OS 自体を不安定にするアプローチは本末転倒になりやすいです。
目的別：最短で迷わない“おすすめルート”
| あなたの目的 | 最短ルート | 補足 |
|---|---|---|
| PowerShell 7 を消したい | 設定のアプリ一覧、または winget でアンインストール | 対象が pwsh か確認してから |
| Windows PowerShell 5.1 を見えなくしたい | ショートカット非表示＋既定シェル変更 | “抑止”としては有効 |
| 一般ユーザーに PowerShell を起動させたくない | AppLocker / WDAC で powershell.exe をブロック | 監査→強制で段階導入 |
| スクリプト実行を最小化したい | 署名運用＋ポリシー設定＋ログ強化 | 運用手順（署名）をセットで作る |
| 攻撃面を少しでも減らしたい | PowerShell 2.0 無効化＋監査強化 | 古い互換機能の整理 |
よくある質問
Windows PowerShell をアンインストールできないのは、バグですか？
バグではありません。Windows PowerShell 5.1 は OS の標準コンポーネントとして扱われるため、通常のアプリのように一覧に出てきません。
「PowerShell を削除したらセキュリティが上がる」のでは？
狙いは理解できますが、PowerShell は管理者の運用でも使われるため、無理な削除で端末が不安定になると逆にリスクが増えます。削除ではなく、実行制御とログ強化をセットで考える方が実務的です。
PowerShell 7 と Windows PowerShell は共存しますか？
共存します。多くの端末では、Windows PowerShell（powershell.exe）と PowerShell 7（pwsh.exe）が同時に存在し、用途に応じて使い分けられます。削除したい対象を取り違えないことが重要です。
まとめ：追加/削除に出てこないなら、まず“種類の見極め”と“制御”へ
Windows PowerShell が「追加/削除」に出てこないのは、標準搭載コンポーネントとして扱われているためで、基本的に単体アンインストールは想定されていません。どうしてもリスクを下げたい場合は、PowerShell 2.0 の無効化や、PowerShell 7 のみをアプリとして削除するなど、現実的で副作用の少ない手順から進めましょう。
そして本命は「使わせない」設計です。個人環境なら抑止、組織端末なら AppLocker/WDAC とログを組み合わせ、業務影響を最小にしつつセキュリティを上げる運用に寄せるのが、長期的にトラブルの少ない解決策になります。
コメント