--- title: "PowerShell 7のインストール手順｜7.6 LTS（7.6.9）をwinget・MSI・Linux・macOSで入れる" url: "https://www.issoh.co.jp/tech/details/17921/" published: 2026-09-28 updated: 2026-11-02 categories: ["OS"] publisher: "株式会社一創" --- # PowerShell 7のインストール手順｜7.6 LTS（7.6.9）をwinget・MSI・Linux・macOSで入れる 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との使い分け](/tech/details/13574/)を読むと手順を追いやすくなります。 ## まとめ：PowerShell 7を入れる前に決めておく版と配布形式の5点 第一に、入れる版は7.6系のLTSで、2026年11月2日時点の最新は**7.6.9**（10月25日公開）です。[PowerShellのサポートライフサイクル](https://learn.microsoft.com/ja-jp/powershell/scripting/install/powershell-support-lifecycle?view=powershell-7.6)では、7.6は2028年11月14日までサポートされ、7.4 LTSと7.5はどちらも2026年11月10日で終わります。Microsoft Learnのインストール手順はまだ7.6.6のファイル名で書かれているので、版番号は[GitHubのリリースページ](https://github.com/PowerShell/PowerShell/releases)で確かめてください。 第二に、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）](https://learn.microsoft.com/ja-jp/powershell/scripting/install/install-powershell-on-windows?view=powershell-7.6)は、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 -Version ``` 1行目で場所が返らない場合は、未導入か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 winget ``` wingetのパッケージ定義（[winget-pkgsのMicrosoft.PowerShell](https://github.com/microsoft/winget-pkgs/tree/master/manifests/m/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のリリース](https://github.com/PowerShell/PowerShell/releases/tag/v7.7.0-rc.1)に並ぶWindows向けの配布物はZIP 5種とmsixbundleだけでした。MSIで配布経路を組んでいる組織は、7.6系のサポート期間中にMSIXかZIPへの移行計画を立てておくことになります。 ## MSIインストーラーの画面で選ぶ項目とmsiexecの配布プロパティ MSIは[v7.6.9のリリースページ](https://github.com/PowerShell/PowerShell/releases/tag/v7.6.9)からx64・arm64・x86の3種を入手できます。ダブルクリックで入れる場合も、`msiexec`で配る場合も、決める項目は同じです。 ### インストーラー画面のチェック項目と既定でオンになる設定 画面に出るチェック項目は、そのまま`msiexec`のプロパティに対応しています。既定値はMSIを作るWiXの定義ファイル（[assets/wix/Product.wxs](https://github.com/PowerShell/PowerShell/blob/v7.6.9/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の接続設定](/tech/details/18467/)で比べています。テレメトリを止めるなら`DISABLE_TELEMETRY=1`を足します。 Intuneで配る場合も、このプロパティ群をそのままコマンドラインに渡せます。配布の仕組みや端末管理の設計まで含めて整えたい場合は、[Microsoft 365・Copilot導入支援](/service/erp%5Fcrm/microsoft365/)で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で開発環境を構築する手順](/tech/details/17354/)にまとめています。 ### Ubuntu 24.04と22.04のpackages.microsoft.com登録とapt導入 [UbuntuにPowerShell 7をインストールする（Microsoft Learn）](https://learn.microsoft.com/ja-jp/powershell/scripting/install/install-ubuntu?view=powershell-7.6)が推奨するのは、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](https://github.com/PowerShell/PowerShell/pull/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.deb ``` `apt-get install`にファイルのパスを渡すと、依存パッケージも一緒に解決されます。この方法はリポジトリを登録しないため、`apt upgrade`では更新されません。月例の更新ごとにdebを入れ直す運用になります。25.10のような中間リリースはMicrosoftのテスト対象外です。 ### macOSの署名付きpkgとHomebrew formulaの選択基準 [macOSにPowerShell 7をインストールする（Microsoft Learn）](https://learn.microsoft.com/ja-jp/powershell/scripting/install/install-powershell-on-macos?view=powershell-7.6)では、推奨は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](https://formulae.brew.sh/formula/powershell)へ移され、今の`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との読み込み順の違い](/tech/details/17871/)と対比すると整理しやすくなります。 ## 7.6.6と7.6.7が起動直後に落ちる不具合と7.6.8以降への更新 2026年10月20日から、7.6.6を起動するとプロンプトが出る前に「Process terminated.」と表示されて終了する、という報告がGitHubに相次ぎました（[issue #28131](https://github.com/PowerShell/PowerShell/issues/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](https://github.com/PowerShell/PowerShell/pull/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.PowerShell ``` `setx`はユーザー環境変数に書き込み、以後に起動したプロセスから効きます。`POWERSHELL_UPDATECHECK`に`Off`を入れると通知の処理が丸ごと止まり、7.6.6でも起動できるようになります。wingetを使わずMSIで入れた端末は、7.6.9のMSIを上書きインストールしても同じ結果になります。7.6.8以降はこの変数を読む処理自体が無くなったため、更新後は消しても残しても動作は変わりません。環境変数の設定場所と反映のタイミングは[環境変数とは？Linux・Windowsの設定方法](/tech/details/17616/)で解説しています。Windows Terminalのプロファイル設定や更新手順は[Windows Terminalの最新版と更新手順](/tech/details/11320/)にまとめています。 ## インストール後のpwshの版・実行ポリシー・更新経路の確認 入れた直後に3つ確かめておくと、後の更新やスクリプト実行で詰まりません。 ### $PSVersionTableと$PSHOMEで版と入れ方を見分ける確認コマンド PowerShell 7を起動して次を実行します。 ``` $PSVersionTable.PSVersion $PSHOME [System.Runtime.InteropServices.RuntimeInformation]::FrameworkDescription ``` Windowsでは、`$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版）](https://learn.microsoft.com/ja-jp/powershell/module/microsoft.powershell.core/about/about%5Fexecution%5Fpolicies?view=powershell-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.PowerShell ``` `winget 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](https://github.com/microsoft/winget-cli/issues/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の選び方とサポート期限](/tech/details/9954/)で扱っています。 次の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）のインストール方法と使い方](/tech/details/3547/)にまとめています。反対に、Hyper-Vの操作のようなWindows固有の管理作業が中心なら、[Hyper-Vの有効化と仮想マシン作成手順｜PowerShell操作](/tech/details/17468/)で扱う作業は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`の値で判別してから作業してください。 ## 関連記事 - [Windows Terminalの最新版は1.25（Preview 1.26）｜新機能・Kitty対応・更新手順【2026年10月】](/tech/details/11320/) - [AnsibleでWindowsを管理する手順：WinRM・SSHの接続設定とansible.windowsのPlaybook例【2.21系】](/tech/details/18467/) - [.NET 10（LTS）とは？SDKの選び方と入手・サポート期限・C# 14と移行を解説](/tech/details/9954/) - [WSLで開発環境を構築する手順｜.wslconfig調整とDocker連携・肥大化の対処](/tech/details/17354/) - [Nushellとは？特徴・インストール・基本コマンドとbashからの移行を0.116で解説](/tech/details/10198/) --- 出典: [PowerShell 7のインストール手順｜7.6 LTS（7.6.9）をwinget・MSI・Linux・macOSで入れる]()（株式会社一創）