PowerShellのインストール手順｜7.6 LTSをwinget・MSI・Linux・macOSで入れる

PowerShell 7のインストールは、Windowsならwinget install --id Microsoft.PowerShell --source wingetの1行で終わります。迷うのはその手前で、MSIとMSIXのどちらが入るのか、社内PCへ一括で配るにはどの形式を選ぶのか、今入っている7.4をいつまで使えるのか、という判断です。この記事では2026年9月時点のMicrosoft Learnを根拠に、Windows・Ubuntu・macOSそれぞれのインストールコマンド、配布用のmsiexecプロパティ、インストール後の確認手順、7.4 LTSと7.5のサポート終了に向けた移行判断までをまとめました。コマンドライン操作そのものに慣れていない場合はCLIとは？コマンドライン操作の仕組みとGUIとの使い分けを先に読むと手順を追いやすくなります。

まとめ：PowerShell 7を入れる前に決めておく版と配布形式の4点

第一に、入れる版は7.6系のLTSにします。PowerShellのサポートライフサイクルでは、7.6は2026年3月18日リリースで2028年11月14日までサポートされ、7.4 LTSと7.5はどちらも2026年11月10日で終わります。今から入れるなら7.6以外を選ぶ理由はほぼありません。

第二に、Windowsの個人端末ならwingetで足ります。ただし7.6.0のパッケージからwingetの既定はMSIXに変わりました。MSIXは1ユーザー単位の導入で、PowerShellリモート処理やマシン全体の実行ポリシー設定が使えません。

第三に、社内PCやサーバーへ配るならMSIをmsiexecで無人インストールします。公式ドキュメントには7.7.0以降MSIを提供しないと明記されているため、MSI前提の配布手順は7.6系の間に見直しが要ります。

第四に、Windows PowerShell 5.1は消えません。7は別フォルダーへ入り、5.1と並んで動きます。起動コマンドもpwshとpowershellで分かれます。

Windowsでwingetを使ってPowerShell 7.6をインストールする手順

個人の開発端末へ入れる場合の標準手順です。WindowsにPowerShell 7をインストールする（Microsoft Learn）はWinGetを推奨の方法としています。

Windows PowerShell 5.1と7の違いとpwshの有無を確かめる手順

Windowsに最初から入っているのはWindows PowerShell 5.1で、実行ファイルはpowershell.exeです。PowerShell 7は.NETの上で動く別製品で、実行ファイルの名前はpwsh.exeです。7を入れても5.1は置き換わらず、$Env:ProgramFiles\PowerShell\7という別の場所へ入ります。すでに入っているかどうかは、コマンドプロンプトかWindows PowerShellで次を打てば分かります。

where.exe pwsh
pwsh -NoProfile -Command '$PSVersionTable.PSVersion.ToString()'

1行目で場所が返らなければ未導入です。返った場合は2行目の版を見て、7.4や7.5なら後述の移行判断へ進んでください。なお、Windows PowerShell ISEは5.1専用のエディターで、7のスクリプトを編集する用途には使えません。

winget installの1行で入る7.6系とMSIXが既定になった変更点

wingetはWindows 11とWindows Server 2025にApp Installerの一部として同梱されています。Windows Server 2022以前では使えないため、サーバーには次章のMSIかZIPを選びます。

winget search --id Microsoft.PowerShell --exact
winget install --id Microsoft.PowerShell --source winget

2026年9月時点の公式ドキュメントでは、検索結果の版は7.6.6.0と示されています。インストール後はターミナルを開き直して、pwshで起動してください。開き直さないと、PATHが更新される前のシェルのままpwshが見つからないという状態になります。

見落としやすいのは形式です。7.6.0以降のwingetパッケージは既定でMSIXを入れます。7.5以前の手順書どおりに同じコマンドを打っても、入るものが変わっている点に注意してください。

–installer-type wixでMSIを指定する場合と7.7でMSIが消える点

MSIX特有の制約を避けたい場合は、インストーラーの種類を指定してMSIを入れます。

winget install --id Microsoft.PowerShell --source winget --installer-type wix

ここで押さえておく事実が1つあります。公式ドキュメントには「PowerShell 7.7.0リリース以降、使用できるMSIパッケージはありません。WinGetはMSIXパッケージのみをインストールします」と書かれています。7.7は2026年9月時点でプレビュー段階ですが、MSIの配布経路を組んでいる組織は、7.6系のサポート期間中にMSIX前提の配布へ移す計画を立てておくことになります。

社内PCへMSIでサイレント配布するmsiexecのプロパティ設定

複数台へ同じ構成で入れる場合は、画面操作を伴わないmsiexecでの導入が基本です。配布元はGitHubのPowerShellリリースページで、x64とarm64のMSIが版ごとに置かれています。

msiexecに渡す配布用プロパティとADD_PATH・USE_MUの既定値

公式ドキュメントに載っている無人インストールの例を、7.6.6のx64版に当てはめると次の形になります。

$msiParams = @(
    '/package'
    'PowerShell-7.6.6-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

運用で効くのは3つです。USE_MUとENABLE_MUはどちらも既定が1で、Microsoft UpdateやWSUS、Configuration Manager経由の更新を受け取る設定になります。ADD_PATH=1を付けないとpwshをフルパスでしか呼べません。ENABLE_PSREMOTING=1はWinRMの受け口を開くため、リモート管理を使わない端末では外してください。テレメトリを止めたい場合は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を並べて動作差を確かめたいときも、別フォルダーへZIPを展開する方法で共存が可能です。前提条件の確認は行われないため、WSMan経由のリモート処理を使う場合は要件を自分で満たす必要があります。ダウンロード経路によってはUnblock-Fileでブロックを外す手順も要ります。

LinuxとmacOSにPowerShell 7を入れるaptとpkgのコマンド

PowerShell 7はクロスプラットフォームで、CIのLinuxランナーや開発用のMacでも同じスクリプトを動かせます。Windows上でLinux環境を併用する場合の構成はWSLで開発環境を構築する手順にまとめています。

Ubuntu 24.04のpackages.microsoft.com登録とapt導入

UbuntuにPowerShell 7をインストールする（Microsoft Learn）が推奨するのは、Microsoftのパッケージリポジトリを登録して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

対象は2026年9月時点で26.04、24.04、22.04の3版です。25.10のような中間リリースはMicrosoftのテスト対象外なので、GitHubのdebを直接入れる手動の方法になります。もう1つ確認しておきたいのが、.NETの取得元です。このリポジトリを登録すると.NETのパッケージもMicrosoft側から取れるようになり、Ubuntu標準の.NETと版が混ざる不具合が起き得ると公式が警告しています。.NETを別用途で入れているサーバーでは、リポジトリの優先順位を先に決めておいてください。

macOSは署名付きpkgが推奨でHomebrewは代替扱いに変わった

macOSにPowerShell 7をインストールする（Microsoft Learn）では、推奨がGitHubのpkgファイルに変わり、Homebrewでの導入は「代替方法」のページへ移されました。2026年5月のリリース以降、pkgはMicrosoftの署名と公証を受けています。Apple Siliconならpowershell-7.6.6-osx-arm64.pkg、Intel Macならosx-x64を選んで開くだけです。

対応版はmacOS 27、26、15で、macOS 27はArm64のみです。インストール後は/usr/local/bin/pwshにシンボリックリンクが作られ、pwshで起動できます。ユーザープロファイルは~/.config/powershell/profile.ps1から読まれるので、bashやzshの設定ファイルとは別管理です。シェル設定の読み込み順の考え方は.bashrcとは？.bash_profileとの読み込み順の違いと対比すると整理しやすくなります。

インストール後にpwshの版と実行ポリシー・更新経路を確認する

入れた直後に3つだけ確かめておくと、後の更新やスクリプト実行で詰まりません。

$PSVersionTableと$PSHOMEで版と入れ方を見分ける確認コマンド

PowerShell 7を起動して次を実行します。

$PSVersionTable.PSVersion
$PSHOME
[System.Runtime.InteropServices.RuntimeInformation]::FrameworkDescription

$PSHOMEの値で入れ方を逆引きできます。$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

スクリプトが実行できないときは、まず7側の設定を直接確かめます。

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行で確認と更新ができます。

winget list --id Microsoft.PowerShell --upgrade-available
winget upgrade --id Microsoft.PowerShell

winget upgradeは、最初に入れたときと同じ形式（MSIかMSIX）で更新します。MSIでUSE_MU=1を付けて入れた端末はWindows Updateの流れで更新が届くため、台数が多い環境ではこちらに任せるほうが手間がかかりません。起動時の「新しいバージョンがあります」という通知は、24時間に1回の確認で、リリースから7日を超えた版だけが対象です。LTSの更新だけ知りたい場合は環境変数POWERSHELL_UPDATECHECKにLTSを設定します。

7.4 LTSと7.5のサポートが2026年11月10日に終わる前の移行判断

ここからは入れ方ではなく、どの版をいつまで使うかの判断です。サポートライフサイクルの表を基に言い切ります。

7.4と7.5を使い続けてよい期限と7.6 LTSへ上げる順番

7.4 LTSと7.5は同じ日に終わります。7.5から7.6へ移るのを待っていた組織も、7.4に留まっていた組織も、2026年11月10日が同じ期限になるということです。この日を過ぎるとセキュリティ更新も止まります。

順番は、検証用に1台だけZIPで7.6を並べて入れ、社内スクリプトとモジュールを流してから、配布の形式ごと切り替える流れが安全です。7.4から7.6へ上げる場合は.NETが2世代進むため、独自のバイナリモジュールや.NETのAPIを直接呼ぶスクリプトを優先して確かめてください。

PowerShell 7を入れず5.1のままで済ませてよい場面と入れる条件

5.1のままでよいのは、ActiveDirectoryモジュールなどWindowsに付属する管理モジュールだけを使い、スクリプトをWindows上でしか動かさない場合です。5.1はWindowsの構成要素としてOSのサポートに従うため、期限の管理も要りません。一部のモジュールは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は$Env:ProgramFiles\PowerShell\7という別フォルダーに入り、5.1と並んで動きます。スタートメニューにも両方が表示され、起動コマンドは5.1がpowershell、7がpwshです。5.1でしか動かないモジュールを使う作業は、これまでどおり5.1側で続けられます。

管理者権限が無い端末でもインストールできますか？

Microsoft StoreかMSIXで入れる方法は1ユーザー単位の導入なので、端末の管理ポリシーが許していれば使えます。ZIP版を自分のフォルダーへ展開する方法でも動きます。ただし社内PCではソフトウェアの導入自体が規程で制限されていることが多いため、情報システム部門の配布経路に乗せるのが筋です。

起動時に「最新版をインストールしてください」と出るのはなぜですか？

PowerShell 7の更新通知機能です。24時間に1回、新しい版が出ていないかを確認し、リリースから7日を超えた版があれば起動時に表示します。自動で更新はしないため、最初に入れたときと同じ方法で更新してください。通知を止めたい場合は環境変数POWERSHELL_UPDATECHECKにOffを設定します。

プレビュー版の7.7を安定版と一緒に入れられますか？

安定版と一緒にインストール可能です。プレビュー版は7-previewという別フォルダーに入り、pwsh-previewで起動するので安定版と共存します。wingetならMicrosoft.PowerShell.Previewを指定します。プレビュー版は公式サポートの対象外で破壊的変更を含むため、本番のスクリプト実行には使わないでください。

アンインストールはどうすればよいですか？

入れた方法で変わります。wingetならwinget uninstall --id Microsoft.PowerShell、MSIなら「プログラムと機能」から削除、ZIPなら展開したフォルダーを消します。Ubuntuはsudo apt-get remove powershellです。どの方法で入れたか分からない場合は、先に$PSHOMEの値で判別してから作業してください。

関連記事

• CLIとは？コマンドライン操作の仕組みとGUIとの使い分けを実装視点で解説：PowerShellを含むコマンドライン操作の前提知識です。
• WSLで開発環境を構築する手順｜.wslconfig調整とDocker連携・肥大化の対処：Windows上でLinuxのシェルと併用する構成です。
• Nushellとは？次世代シェルの特徴・インストール・基本コマンドを解説：PowerShellと同じく構造化データを扱う別のシェルとの比較に使えます。
• ghコマンド（GitHub CLI）とは？インストール方法と使い方・コマンド一覧：PowerShell上で使うことの多いCLIツールの導入手順です。
• Hyper-Vの有効化と仮想マシン作成手順｜PowerShell操作とWSL2との併存：インストールしたPowerShellでWindowsの管理作業を行う実例です。