PowerShell 7.4・7.5のサポート終了｜7.6 LTSへの移行前チェック

PowerShell 7.4や7.5を使うスクリプトが今も動いていると、更新を後回しにしたくなるかもしれません。ただ、動作していることと、セキュリティ更新を受けられることは別です。両バージョンは2026年11月にサポート終了を迎えました。

移行先の候補はPowerShell 7.6 LTSです。まず起動している版と実行ファイル、使っているモジュールを押さえると、更新後に「いつものタスクだけ動かない」という状況を切り分けやすくなります。ここではWindowsで移行前に確認したい点を整理します。

7.4・7.5と7.6 LTSの期限を確認する

PowerShellのサポートライフサイクル資料では、終了日は次のように案内されています。

サポートが終わった版には、セキュリティ修正を含む更新が提供されなくなります。7.6系でも、その系統の最新の更新版を使うことがサポートの前提です。また、PowerShellだけでなく、実行するWindowsのサポート期限も確認しておきたいところです。

Windows PowerShell 5.1は別の扱いで、Windowsのライフサイクルに従います。「PowerShell 7.4が終了したから5.1も同時に終了した」とは判断できません。PowerShell 7は5.1を置き換えるのではなく、別の場所にインストールされ、併存します。

今開いているPowerShellの版を調べる

Windows Terminalやエディターの表示名だけでは、実際に動いている版を取り違えることがあります。調べたいPowerShellのウィンドウで、次を実行してください。Windows PowerShell 5.1とPowerShell 7で使える確認方法です。

$PSVersionTable.PSVersion.ToString()
$PSVersionTable.PSEdition
$PSHOME

上から順に、バージョン番号、エディション、実行中のPowerShellのインストール先が表示されます。5.1ならエディションはDesktop、PowerShell 7ならCoreです。ここで7.4系や7.5系が出た環境を、移行前の確認対象として整理できます。

この結果はそのウィンドウで実行中のPowerShellの情報です。同じPCでも、タスクスケジューラ、エディター、サービスから起動するPowerShellは異なる場合があります。自動処理については、設定されている実行ファイルのパスと引数も控えておくと、後で比較しやすくなります。

pwshの呼び出し先を確認する

PowerShell 7をコマンド名で起動するときは、通常pwshを使います。現在の検索パスで見つかる実行ファイルは、次のように並べられます。

Get-Command pwsh -CommandType Application -All |
    Select-Object Name, Source

Sourceに実行ファイルの場所が表示されます。複数行なら、見つかった候補を比較できます。-CommandType Applicationで実行ファイルに絞っているため、同名の関数やエイリアスはこの一覧に含まれません。

見つからないというエラーが出ても、PC全体にPowerShell 7がないとは限りません。ZIPを展開しただけで検索パスに入れていない場合などもあります。起動用ショートカットや管理者の配布設定にあるパスと、実行中の$PSHOMEを見比べると手掛かりになります。なお、絶対パスを指定して起動するタスクは、この検索結果だけでは切り替わりません。

使っているモジュールと変更点を照合する

移行前のシェルで、利用可能なモジュール名と版を控えておきます。

Get-Module -ListAvailable |
    Sort-Object Name, Version |
    Select-Object Name, Version

-ListAvailableは、そのセッションのモジュール検索パスから見つかる一覧です。読み込み済みの一覧ではなく、このコマンド自体が各モジュールをインポートするわけでもありません。複数の版が並ぶ場合もあります。移行先でも同じ一覧を取り、実際のスクリプトが使うモジュールの対応PowerShell、必要な.NET、提供元の移行案内を照合してください。名前が見つかっただけで、業務処理の互換性が確認できたことにはなりません。

7.6の変更点では、特に次のような箇所が確認の手掛かりになります。

• ThreadJobのモジュール名：7.6ではMicrosoft.PowerShell.ThreadJobに変わっています。Start-ThreadJobというコマンド名は変わりませんが、モジュール名を付けて呼び出すスクリプトは見直しが必要です。
• Join-Pathの引数：-ChildPathが文字列配列を受け取る型に変わっています。引数の型を調べる処理や独自ラッパーがある場合は、期待する結果と比較するポイントになります。
• 7.4からの移行：7.6だけでなく、7.5で入った変更も確認します。例えばConvertTo-JsonのBigIntegerの扱いや、Test-Pathの日付条件に関する修正があります。

詳細は7.6の変更点と7.5の変更点を、使っている処理に合わせて読むと絞り込めます。パスを組み立てる基本的な例は、Join-Pathの使い方でも紹介しています。

本番を更新する前に処理を試す

更新方法は、WinGet、MSI、MSIX、ZIPなど、現在の配布方法に合わせて選びます。会社で管理されている端末は管理者の配布方針に従い、個別に別方式を重ねない方が更新経路を整理しやすくなります。対応OSや各方式の制約はWindowsへの公式インストール手順で確認できます。

PowerShell 7の更新では既存版が置き換わり、起動パスを変えなくてもジョブが使う版が変わる場合があります。先に別の検証環境、または別フォルダーに展開したZIP版を使い、検証する実行ファイルを明確にしておくと、本番への影響を分けられます。

本番とは別の環境や検証用データで、代表的なスクリプトを7.6の更新版に通します。認証先、書き込み先、メール送信先などが本番を向いたままになっていないかも、実行前に点検してください。

• 同じ入力から、想定した出力ファイルやJSONが得られるか。
• 成功時と失敗時の終了コード、エラー処理、ログの内容が期待どおりか。
• 対話実行だけでなく、実運用と同じ起動方法・引数・作業フォルダーで動くか。
• 必要なモジュールと外部コマンドが、想定した版・場所から使われるか。

問題がなければ、管理している起動設定を段階的に切り替え、更新後の版と実行ファイルの場所をもう一度照合します。ファイルに関わる処理なら、Test-Pathによるファイル・フォルダーの確認も組み合わせると、実行場所の違いを探しやすくなります。

7.4・7.5のサポート終了への対応は、7.6を入れるだけで終わらせず、実際に動くシェル、依存モジュール、自動処理の起動先までそろえることがポイントです。手元の対話画面と日々動くジョブを分けて確認すると、移行後の取り残しを減らせます。

参考資料

• Microsoft Learn：PowerShell Support Lifecycle
• PowerShell Team：PowerShell 7.6 LTSの一般提供
• Microsoft Learn：自動変数
• Microsoft Learn：Get-Command
• Microsoft Learn：Get-Module