PowerShell 7のインストールは、Windowsならwinget install --id Microsoft.PowerShell --source wingetの1行で終わります。迷うのはその手前です。MSIとMSIXのどちらが入るのか、社内PCへ配るにはどの形式を選ぶのか、今入っている7.4や7.5をいつまで使えるのか。2026年10月には、7.6.6と7.6.7が日本語環境で起動直後に落ちる不具合も出ました。この記事では、2026年11月2日時点のGitHubリリースとMicrosoft Learnを根拠に、Windows・Ubuntu・macOSのインストールコマンド、MSIの配布プロパティ、起動しない端末の直し方、7.4 LTSと7.5のサポート終了に向けた移行判断までをまとめました。コマンドライン操作そのものに慣れていない場合は、先にCLIとは？コマンドライン操作の仕組みとGUIとの使い分けを読むと手順を追いやすくなります。
まとめ：PowerShell 7を入れる前に決めておく版と配布形式の5点
第一に、入れる版は7.6系のLTSで、2026年11月2日時点の最新は7.6.9（10月25日公開）です。PowerShellのサポートライフサイクルでは、7.6は2028年11月14日までサポートされ、7.4 LTSと7.5はどちらも2026年11月10日で終わります。Microsoft Learnのインストール手順はまだ7.6.6のファイル名で書かれているので、版番号はGitHubのリリースページで確かめてください。
第二に、7.6.6か7.6.7を使っている端末は、すぐ7.6.8以降へ上げます。日本語UIのWindows Terminalなどで、更新通知の表示処理が原因で起動直後に落ちることがあります。7.6.8でこの更新通知機能そのものが削除されました。
第三に、Windowsの個人端末ならwingetで足ります。ただし7.6.0以降、wingetは既定でMSIXを入れます。MSIXは1ユーザー単位の導入で、WinRMでのリモート受け口やマシン全体の実行ポリシーを設定できません。
第四に、社内PCやサーバーへ配るならMSIをmsiexecで無人インストールします。7.7.0以降はMSIが提供されないと公式ドキュメントに明記され、10月29日に出た7.7.0-rc.1の配布物にもMSIはありません。MSI前提の配布手順は7.6系の間に見直しが要ります。
第五に、Windows PowerShell 5.1は消えません。7は別フォルダーに入り、起動コマンドもpwshとpowershellで分かれます。
Windowsでwingetを使ってPowerShell 7.6をインストールする手順
個人の開発端末へ入れる場合の標準手順です。WindowsにPowerShell 7をインストールする（Microsoft Learn）は、Windowsクライアントでの推奨をWinGetとしています。
Windows PowerShell 5.1と7の違いとpwshの有無を確かめる手順
Windowsに最初から入っているのはWindows PowerShell 5.1で、実行ファイルはpowershell.exeです。PowerShell 7は.NETの上で動く別製品で、実行ファイルはpwsh.exeです。7を入れても5.1は置き換わりません。MSI版の既定の保存先は$Env:ProgramFiles\PowerShell\7で、MSIX版やZIP版は保存先が異なります。すでに入っているかは、コマンドプロンプトかWindows PowerShellで次を打てば分かります。
where.exe pwsh
pwsh -Version1行目で場所が返らない場合は、未導入かPATH未登録です。スタートメニューや展開先も確認してください。場所が返った場合は2行目の版を見ます。7.6.6か7.6.7なら後述の起動クラッシュの章へ、7.4や7.5なら移行判断の章へ進んでください。なお、Windows PowerShell ISEが対応する実行環境は5.1で、PowerShell 7の実行・デバッグには対応しません。7の開発にはVisual Studio CodeとPowerShell拡張機能を使います。
winget installの1行で入る7.6.9とMSIXが既定になった変更点
wingetはWindows 11とWindows Server 2025にApp Installerの一部として入っています。Windows Server 2025でもデスクトップエクスペリエンス付きの構成だけで、Server 2022以前では使えません。サーバーには次章のMSIかZIPを選びます。
winget search --id Microsoft.PowerShell --exact
winget install --id Microsoft.PowerShell --source wingetwingetのパッケージ定義（winget-pkgsのMicrosoft.PowerShell）には10月25日付で7.6.9.0が登録されているため、検索結果の版は7.6.9.0になります。Learnの出力例は7.6.6.0のままなので、表示が違っても異常ではありません。インストール後はpwshで起動します。既存のシェルにPATHの変更が反映されずpwshが見つからない場合は、ターミナルを終了して起動し直してください。
見落としやすいのは形式です。7.6.0以降のwingetパッケージは既定でMSIXを入れます。7.5以前の手順書どおりに同じコマンドを打っても、入るものが変わっています。
–installer-type wixでMSIを指定する場合と7.7でMSIが消える点
MSIX特有の制約を避けたい場合は、インストーラーの種類を指定してMSIを入れます。7.6.9のマニフェストではMSIはマシン単位（Scope: machine）で、実行時に管理者権限への昇格を求めます。
winget install --id Microsoft.PowerShell --source winget --installer-type wix公式ドキュメントには「PowerShell 7.7.0リリース以降、使用できるMSIパッケージはありません。WinGetはMSIXパッケージのみをインストールします」とあります。実際、v7.7.0-rc.1のリリースに並ぶWindows向けの配布物はZIP 5種とmsixbundleだけでした。MSIで配布経路を組んでいる組織は、7.6系のサポート期間中にMSIXかZIPへの移行計画を立てておくことになります。
MSIインストーラーの画面で選ぶ項目とmsiexecの配布プロパティ
MSIはv7.6.9のリリースページからx64・arm64・x86の3種を入手できます。ダブルクリックで入れる場合も、msiexecで配る場合も、決める項目は同じです。
インストーラー画面のチェック項目と既定でオンになる設定
画面に出るチェック項目は、そのままmsiexecのプロパティに対応しています。既定値はMSIを作るWiXの定義ファイル（assets/wix/Product.wxs）で確かめました。
| 画面の表示 | プロパティ | 既定 |
|---|---|---|
| Add PowerShell to Path Environment Variable | ADD_PATH | オン |
| Register Windows Event Logging Manifest | REGISTER_MANIFEST | オン |
| Enable PowerShell remoting | ENABLE_PSREMOTING | オフ |
| Disable Telemetry | DISABLE_TELEMETRY | オフ |
| Add ‘Open here’ context menus to Explorer | ADD_EXPLORER_CONTEXT_MENU_OPENPOWERSHELL | オフ |
| Add ‘Run with PowerShell 7’ context menu for PowerShell files | ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL | オフ |
| Enable updating PowerShell through Microsoft Update or WSUS | USE_MU | オン |
| Use Microsoft Update when I check for updates | ENABLE_MU | オン |
開発端末なら既定のまま進めて問題ありません。任意の作業フォルダーからpwshだけで起動したい場合は、Pathへの追加を有効にします。無効でも、スタートメニューや実行ファイルのパスを指定して起動できます。リモート管理の受け口を開くEnable PowerShell remotingは、管理される側のサーバー以外ではオフのままにします。同じ定義ファイルでは、上書きインストール時に前回の選択値を読み戻す処理が入っているため、7.6.6から7.6.9へ上げても設定は引き継がれます。
msiexecで社内PCへサイレント配布するコマンド
次は7.6.9のx64版を無人インストールするPowerShell用の例です。MSIを保存したフォルダーを作業場所にして、管理者として起動したWindows PowerShellから実行します。
$msiParams = @(
'/package'
'PowerShell-7.6.9-win-x64.msi'
'/quiet'
'ADD_EXPLORER_CONTEXT_MENU_OPENPOWERSHELL=1'
'ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL=1'
'ENABLE_PSREMOTING=1'
'REGISTER_MANIFEST=1'
'USE_MU=1'
'ENABLE_MU=1'
'ADD_PATH=1'
)
msiexec.exe @msiParamsこれは主要な導入オプションを有効にした例です。不要な項目は配布方針に合わせて0を明示します。ただし、ENABLE_MU=0は既存のMicrosoft Update設定を解除する指定ではありません。更新の有効・無効は、端末の既存設定と組織のグループポリシーも確認します。プロパティを省略すると、既定値や前回のインストール設定が使われる場合があります。USE_MUとENABLE_MUを1のままにすると、Microsoft Update・WSUS・Configuration Manager経由で7.6系の更新が届きます。ENABLE_PSREMOTING=1はWinRMの受け口を開くため、Ansibleなどから管理する端末だけに付けます。WinRMとSSHのどちらで管理するかはAnsibleでWindowsを管理する手順：WinRM・SSHの接続設定で比べています。テレメトリを止めるならDISABLE_TELEMETRY=1を足します。
Intuneで配る場合も、このプロパティ群をそのままコマンドラインに渡せます。配布の仕組みや端末管理の設計まで含めて整えたい場合は、Microsoft 365・Copilot導入支援でIntuneの構成と併せてご相談いただけます。
MSIX版で動かないリモート処理とLocalMachine実行ポリシーの制約
MSIX版はアプリのサンドボックス内で動き、$PSHOMEへの書き込みが禁止されます。そのため公式ドキュメントでは次のコマンドが非対応とされています。
Register-PSSessionConfiguration（WinRM経由のリモート受け口の登録）Set-ExecutionPolicy -Scope LocalMachine（マシン全体の実行ポリシー）Update-Help -Scope AllUsersとEnable-ExperimentalFeature -Scope AllUsers
導入はユーザー単位だけで、全ユーザー向けのプロファイルも作れません。SSHでの外向きのリモート処理と、現在のユーザーのプロファイルは使えます。リモート管理の対象になる端末ではMSIX版を避け、MSIかZIPを選びます。
ZIP版でArm機やServer Coreに入れて複数の版を並べる方法
ZIP版は展開するだけでpwsh.exeが動く形式で、Windows Server Core、Windows IoT、Armベースの端末へ入れる手段として公式に挙がっています。7.4と7.6を並べて動作差を確かめたいときも、別フォルダーへ展開すれば共存できます。前提条件の確認は行われないため、WSMan経由のリモート処理を使う場合は要件を自分で満たします。スタートメニューへの登録とPATHへの追加も手作業です。ダウンロード経路によってはUnblock-Fileでブロックを外す手順も要ります。
LinuxとmacOSにPowerShell 7を入れるaptとpkgのコマンド
PowerShell 7はWindows・Linux・macOSで動きます。OS固有のAPIやモジュールに依存しないスクリプトは共有できますが、各環境で動作確認が必要です。Windows上でLinux環境を併用する構成はWSLで開発環境を構築する手順にまとめています。
Ubuntu 24.04と22.04のpackages.microsoft.com登録とapt導入
UbuntuにPowerShell 7をインストールする（Microsoft Learn）が推奨するのは、Microsoftのパッケージリポジトリ（PMC）を登録してaptで入れる方法です。
sudo apt-get update
sudo apt-get install -y wget apt-transport-https software-properties-common
source /etc/os-release
wget -q https://packages.microsoft.com/config/ubuntu/$VERSION_ID/packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
rm packages-microsoft-prod.deb
sudo apt-get update
sudo apt-get install -y powershell
pwshパッケージ名はpowershellを指定します。名前から最新のLTSが入りそうなpowershell-ltsは、Ubuntu 24.04向けのPMCでは11月2日時点で7.4.22が最新で、11月10日にサポートが切れる7.4系が入ります。powershellのほうは7.6.9まで揃っています。
もう1つ確認したいのが.NETの取得元です。Ubuntu 24.04向けのMicrosoftリポジトリには.NETパッケージはありません。Ubuntu 22.04ではMicrosoft側からも一部の.NETパッケージを取得でき、Ubuntu標準の.NETと版が混ざる不具合が起き得ると公式が警告しています。.NETを別用途で入れているサーバーでは、リポジトリの優先順位を先に決めておいてください。
Ubuntu 26.04のPMC配布状況とGitHubのdebによる導入
Learnのサポート表には26.04が載っていますが、11月2日にpackages.microsoft.com/ubuntu/26.04/prodのパッケージ一覧を確かめた時点では、PowerShellはpowershell-preview（7.7.0-preview.5まで）しかありませんでした。上のスクリプトどおりに進めると、最後のapt-get install -y powershellでパッケージが見つからずに止まります。PMCへ26.04を追加したPR #27765では、メンテナーが「.NET 11向けだけでバックポートしない」とコメントしています。26.04では当面、GitHubのdebを直接入れます。次の例はx64（amd64）環境向けで、wgetが必要です。未導入なら先にsudo apt-get updateとsudo apt-get install -y wgetを実行してください。
wget https://github.com/PowerShell/PowerShell/releases/download/v7.6.9/powershell_7.6.9-1.deb_amd64.deb
sudo apt-get install -y ./powershell_7.6.9-1.deb_amd64.deb
rm powershell_7.6.9-1.deb_amd64.debapt-get installにファイルのパスを渡すと、依存パッケージも一緒に解決されます。この方法はリポジトリを登録しないため、apt upgradeでは更新されません。月例の更新ごとにdebを入れ直す運用になります。25.10のような中間リリースはMicrosoftのテスト対象外です。
macOSの署名付きpkgとHomebrew formulaの選択基準
macOSにPowerShell 7をインストールする（Microsoft Learn）では、推奨はGitHubのpkgファイルです。2026年5月のリリース以降、pkgはMicrosoftの署名と公証を受けています。Apple Siliconならpowershell-7.6.9-osx-arm64.pkg、Intel Macならpowershell-7.6.9-osx-x64.pkgを開くだけです。対応版はmacOS 27・26・15で、macOS 27はArm64だけです。
Homebrewは扱いが変わりました。以前のcask（Microsoftのpkgを入れる方式）は2026年2月26日にformulaへ移され、今のbrew install powershellはHomebrewのコミュニティがソースからビルドした7.6.9を入れます。Microsoftがビルドした実行ファイルが要るならpkgを選びます。caskで入れたままの端末は、brew uninstall --cask powershellで外してからformulaを入れると公式の代替手順ページにあります。
pkgでインストールした場合は/usr/local/bin/pwshにシンボリックリンクが作られます。Homebrew版は、Homebrewのbin配下（Apple Siliconなら/opt/homebrew/bin）に起動用スクリプトが置かれます。ユーザープロファイルは~/.config/powershell/profile.ps1から読まれ、bashやzshの設定ファイルとは別管理です。シェル設定の読み込み順は.bashrcとは？.bash_profileとの読み込み順の違いと対比すると整理しやすくなります。
7.6.6と7.6.7が起動直後に落ちる不具合と7.6.8以降への更新
2026年10月20日から、7.6.6を起動するとプロンプトが出る前に「Process terminated.」と表示されて終了する、という報告がGitHubに相次ぎました（issue #28131ほか）。日本語、中国語、ドイツ語、韓国語のUIで報告されています。Windows PowerShell 5.1は無関係で、7.4系と7.5系も対象外です。
日本語UIで「totalWidth (‘-10’)」と出て終了する原因
原因は、起動時に新しい版を知らせる更新通知の表示処理です。7.6.6のソース（UpdatesNotification.cs）は、通知文の1行目が最も長い前提で、2行目と3行目の余白をPadRightで計算します。7.6.6は翻訳済みの通知文を初めて同梱した版で、日本語の通知文は3行目（URLの行）のほうが長くなります。7.6.6の日本語リソースから行の長さを数えると、安定版向けの通知文で余白の幅は-10になり、負の値を渡されたPadRightが例外を投げてプロセスごと落ちます。同じ計算で中国語は-17、ドイツ語は-1になり、issueに貼られたエラーの数値と一致しました。
落ちるのは、更新通知が有効（既定）なまま、次の3つが揃って起動時に通知を表示しようとしたときです。
- 版が7.6.6か7.6.7で、UIが英語以外
- Windows Terminalなど、仮想端末シーケンスに対応したホストで起動している
- 公開から7日を過ぎた新しい版がある（7.6.6は7.6.7が出た10月13日の7日後、7.6.7は7.6.8が出た10月22日の7日後から該当）
開発チームはこの不具合を機に、PR #28242で更新通知機能そのものを削除しました。7.6.8のリリースノートには「Remove the Update Notification feature from PowerShell」とあります。7.5系と7.4系のソースには翻訳済みの通知文が入っていないため、英語の通知文のまま動き、この計算は負になりません。
起動できない端末でPOWERSHELL_UPDATECHECKを切って7.6.9へ上げる手順
pwshが立ち上がらない状態でも、コマンドプロンプトかWindows PowerShell 5.1から直せます。まず更新通知を止める環境変数を設定し、ターミナルを開き直してから更新します。
setx POWERSHELL_UPDATECHECK Off
winget upgrade --id Microsoft.PowerShellsetxはユーザー環境変数に書き込み、以後に起動したプロセスから効きます。POWERSHELL_UPDATECHECKにOffを入れると通知の処理が丸ごと止まり、7.6.6でも起動できるようになります。wingetを使わずMSIで入れた端末は、7.6.9のMSIを上書きインストールしても同じ結果になります。7.6.8以降はこの変数を読む処理自体が無くなったため、更新後は消しても残しても動作は変わりません。環境変数の設定場所と反映のタイミングは環境変数とは？Linux・Windowsの設定方法で解説しています。Windows Terminalのプロファイル設定や更新手順はWindows Terminalの最新版と更新手順にまとめています。
インストール後のpwshの版・実行ポリシー・更新経路の確認
入れた直後に3つ確かめておくと、後の更新やスクリプト実行で詰まりません。
$PSVersionTableと$PSHOMEで版と入れ方を見分ける確認コマンド
PowerShell 7を起動して次を実行します。
$PSVersionTable.PSVersion
$PSHOME
[System.Runtime.InteropServices.RuntimeInformation]::FrameworkDescriptionWindowsでは、$PSHOMEの値からインストール方法を絞り込めます。以下のWindows用パスによる判別は、UbuntuやmacOSには適用しません。$Env:ProgramFiles\PowerShell\7ならMSIの可能性があり（「プログラムと機能」で要確認）、$Env:ProgramFiles\WindowsApps\で始まればMSIX、$HOME\.dotnet\toolsなら.NETグローバルツール、それ以外ならZIPの可能性が高い、というのが公式の判別基準です。3行目は土台の.NETの版を返し、7.6系なら.NET 10系が表示されます。引き継いだ端末で、誰がどの方法で入れたか分からないときに役立ちます。
実行ポリシーは5.1と別の場所に保存されるpowershell.config.json
Windowsでスクリプトが実行できないときは、まず1行目でPowerShell 7側の設定を確認します。2行目は、CurrentUserをRemoteSignedに変更する必要がある場合だけ実行してください。MachinePolicyやUserPolicyが設定されている場合は、そちらが優先されます。
Get-ExecutionPolicy -List
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser実行ポリシーについて（7.6版）によると、PowerShell 7はCurrentUserの設定をユーザー別のpowershell.config.jsonに、LocalMachineの設定を$PSHOME/powershell.config.jsonに保存します。保存先が5.1とは別なので、5.1で設定した値が7でも効いている前提で考えないでください。グループポリシーで管理する場合も、7向けにはPowerShellCoreExecutionPolicy.admxという別のテンプレートを使います。LinuxとmacOSではUnrestrictedで固定され、変更できません。
winget upgradeとMicrosoft Updateで7.6系を最新に保つ手順
公式にサポートされるのは各リリースの最新の更新版だけです。7.6.0のまま止めておくと、7.6系のサポート期間内でもサポート対象外になります。wingetで入れた端末は次の2行で確認と更新ができます。ただし、このコマンドは7.6系への固定を保証しません。7.6 LTSを維持する場合は、先にwinget pin add --id Microsoft.PowerShell --exact --version "7.6.*"で更新範囲を制限します。この制限はWinGet経由の更新にだけ適用されます。
winget list --id Microsoft.PowerShell --upgrade-available
winget upgrade --id Microsoft.PowerShellwinget upgradeは、更新先にも同じ形式が提供されている場合に、現在のインストール形式（MSIかMSIX）を維持します。MSIが提供されない7.7以降への更新では、この条件を満たしません。MSIでUSE_MU=1のまま入れた端末にはWindows Updateの流れで更新が届くため、台数が多い環境ではこちらに任せるほうが手間がかかりません。7.6.8で更新通知が無くなり、起動時に新しい版を知らせる表示は出なくなりました。更新が止まっていないかは、上のwinget listか$PSVersionTableで定期的に確かめます。
10月23日前後には、winget upgradeやwinget listが「0x80070057 : The parameter is incorrect.」で止まる現象も報告されました（winget-cli issue #6622）。winget側のパッケージ定義に7.6.8と7.6.8.0が重複して登録されたのが原因で、重複は解消済みです。手元のキャッシュが古いままならwinget source update --name wingetを実行してから更新し直してください。
PowerShell 7.6のリリース履歴と7.7 RCの状況
7.6系の更新はおおむね月1回で、10月は不具合対応で3回出ました。各版の公開日と主な中身をGitHubのリリースノートから抜き出しています。
| 版 | 公開日 | 主な変更 |
|---|---|---|
| 7.6.9 | 2026-10-25 | .NET SDK 10.0.403へ更新 |
| 7.6.8 | 2026-10-22 | 更新通知機能を削除 |
| 7.6.7 | 2026-10-13 | MSIX版のPATH処理を修正 |
| 7.6.6 | 2026-09-08 | 翻訳リソースを同梱 |
| 7.6.5 | 2026-08-14 | pwsh -fileのドットソース動作を修正 |
| 7.6.4 | 2026-07-20 | .NET SDK 10.0.302へ更新 |
| 7.6.3 | 2026-06-16 | .NET SDK 10.0.301へ更新 |
| 7.6.2 | 2026-05-21 | AppContainer内での動作に対応 |
| 7.6.1 | 2026-04-21 | 更新通知を公開1週間後に遅延 |
| 7.6.0 | 2026-03-18 | 7.6 LTSの初版（.NET 10） |
7.6.7には、ユーザー別のpowershell.config.jsonが壊れていても読み込みエラーで止まらないようにする修正も入っています。.NET SDKの更新が中心の版も適用対象です。PowerShellの公式サポート対象は各リリースの最新更新版なので、更新内容を確認して適用します。土台の.NET 10のサポート期限やSDKの選び方は.NET 10（LTS）とは？SDKの選び方とサポート期限で扱っています。
次の7.7は、10月29日に7.7.0-rc.1が出ました。土台は.NET 11（SDK 11.0.100-rc.3）で、Windows向けはZIPとmsixbundleだけになり、MSIはありません。wingetのMicrosoft.PowerShell.Previewは11月2日時点でまだ7.7.0-preview.5（7.7.5.0）です。7.7はLTSではないため、本番は7.6系に置いたまま、検証用の端末で動作を確かめる段階です。
7.4 LTSと7.5のサポートが2026年11月10日に終わる前の移行判断
7.4 LTSと7.5を運用している場合は、2026年11月10日までに7.6 LTSへの移行を完了する計画を立てます。
7.4と7.5を使い続けてよい期限と7.6 LTSへ上げる順番
| 版 | 土台の.NET | 最新の更新版 | サポート終了 |
|---|---|---|---|
| 7.6（LTS） | .NET 10.0 | 7.6.9 | 2028年11月14日 |
| 7.5 | .NET 9.0 | 7.5.13 | 2026年11月10日 |
| 7.4（LTS） | .NET 8.0 | 7.4.22 | 2026年11月10日 |
7.4 LTSと7.5のどちらから移行する場合も、2026年11月10日までの完了を目指します。10月25日に出た7.4.22と7.5.13が、11月の月例で次の版が出なければ最後の更新になります。期限を過ぎるとセキュリティ更新も止まります。
順番は、検証用に1台だけZIPで7.6.9を並べて入れ、社内スクリプトとモジュールを流してから、配布の形式ごと切り替える流れが安全です。7.4から7.6へ上げる場合は.NETが2世代進むため、独自のバイナリモジュールや.NETのAPIを直接呼ぶスクリプトを優先して確かめてください。7.6.6や7.6.7を経由させず、7.6.9を直接入れます。
PowerShell 7を入れず5.1のままで済ませてよい場面と入れる条件
5.1のままでよいのは、ActiveDirectoryモジュールなどWindowsに付属する管理モジュールだけを使い、スクリプトをWindows上でしか動かさない場合です。5.1はWindowsの構成要素なので、サポート期限は利用中のWindowsの期限に従います。一部のモジュールは5.1でしか動かないと公式も認めています。
逆に、次のどれかに当てはまるなら7を入れます。LinuxのCIランナーやMacでも同じスクリプトを動かしたい場合。ForEach-Object -Parallelのような7以降の構文を使いたい場合。GitHub CLIのようなCLIツールと組み合わせ、WindowsとLinuxで同じ自動化スクリプトを共有したい場合です。ツール側の導入例はghコマンド（GitHub CLI）のインストール方法と使い方にまとめています。反対に、Hyper-Vの操作のようなWindows固有の管理作業が中心なら、Hyper-Vの有効化と仮想マシン作成手順｜PowerShell操作で扱う作業は5.1のままでも進められるので、無理に切り替える必要はありません。
よくある質問
PowerShellのインストールで検索されることの多い疑問に答えます。
PowerShell 7を入れるとWindows PowerShell 5.1は消えますか？
消えません。7は5.1とは別にインストールされ、並んで動きます。保存先は導入形式によって異なり、MSI版の既定値は$Env:ProgramFiles\PowerShell\7です。スタートメニューにも両方が表示され、起動コマンドは5.1がpowershell、7がpwshです。5.1でしか動かないモジュールを使う作業は、これまでどおり5.1側で続けられます。
管理者権限が無い端末でもインストールできますか？
Microsoft StoreかMSIXで入れる方法は1ユーザー単位の導入なので、端末の管理ポリシーが許していれば使えます。ZIP版を自分のフォルダーへ展開する方法でも動きます。MSIはマシン単位の導入で、管理者権限が要ります。社内PCではソフトウェアの導入自体が規程で制限されていることが多いため、情報システム部門の配布経路に乗せるのが筋です。
起動時の「新しいバージョンがあります」という通知が出なくなったのはなぜですか？
7.6.8で更新通知機能が削除されたためです。7.6.6と7.6.7で通知の表示処理が起動クラッシュを起こしたことを受けて、開発チームはMicrosoft UpdateとMicrosoft Storeによる更新の仕組みが成熟したことを理由に機能ごと外しました。今後はwinget list --id Microsoft.PowerShell --upgrade-availableやMicrosoft Updateで更新を確かめます。7.4系と7.5系には通知機能が残っています。
プレビュー版の7.7を安定版と一緒に入れられますか？
入れられます。ZIP版は任意の別フォルダーへ展開し、その中のpwsh.exeを起動します。WindowsのMSIXプレビュー版は別パッケージとして入り、pwsh-previewで起動するので安定版と共存します。wingetならMicrosoft.PowerShell.Previewを指定します。11月2日時点でwingetに載っているのは7.7.0-preview.5で、最新の7.7.0-rc.1はGitHubのZIPかmsixbundleから入れます。プレビュー版は公式サポートの対象外なので、本番のスクリプト実行には使わないでください。
アンインストールはどうすればよいですか？
入れた方法で変わります。wingetならwinget uninstall --id Microsoft.PowerShell、MSIなら「プログラムと機能」から削除、ZIPなら展開したフォルダーを消します。Ubuntuはsudo apt-get remove powershell、Homebrewはbrew uninstall powershellです。macOSで推奨したpkg版は、sudo rm -rf /usr/local/bin/pwsh /usr/local/microsoft/powershellで本体のフォルダーと起動用のシンボリックリンクを削除します。複数の版を配置している場合は、削除対象を確認してから作業してください。どの方法で入れたか分からない場合は、先に$PSHOMEの値で判別してから作業してください。
