Windows PowerShell 5.1とPowerShell 7は何が違うのですか？

別製品です。5.1はWindowsに同梱され.NET Framework上で動くもので、Microsoftは新機能の追加を終了しており、サポートはWindows本体のライフサイクルに従います。7は.NET(旧.NET Core)上で動く別インストールの製品で、現在の開発の主軸です。7は5.1を置き換えるのではなく、別ディレクトリにインストールされてサイドバイサイドで共存し、実行ファイル名もpowershell.exeとpwsh.exeで区別されます。

PowerShell 7をインストールすると既存の5.1のスクリプトは壊れますか？

壊れません。7は別ディレクトリ(既定でProgram Files\PowerShell\7)にインストールされ、モジュール置き場もプロファイルも5.1とは別に管理されます。タスクスケジューラなどでpowershell.exeを起動している既存の仕組みは、これまでどおり5.1で動き続けます。だからこそ逆に、「7を入れただけでは何も移行されていない」点に注意が必要で、7で動かしたいスクリプトは起動コマンドをpwsh.exeへ明示的に切り替える必要があります。

PowerShell 7で今までのスクリプトが文字化けするのはなぜですか？

既定の文字エンコーディングが変わったためです。5.1はコマンドレットごとに既定が異なり(Out-FileはUTF-16LE、Get-ContentはANSIなど)、7は一律BOMなしUTF-8です。日本語環境ではShift_JIS前提のファイル連携が多いため、既定のまま移行すると読み書きの両方で化け得ます。ファイル入出力の-Encodingを明示すること、非ASCII文字を含むスクリプト自体をBOM付きUTF-8で保存することの2点でほぼ防げます。

PowerShell 7で動かないモジュールはどうすればよいですか？

まず7で普通にImport-Moduleして動くか確認します。動かない場合、Windows互換機能(Import-Module -UseWindowsPowerShell)を使うと、バックグラウンドの5.1プロセスにモジュールを読み込み、リモーティング経由で7から使えます。ただし返ってくるのはシリアライズされたオブジェクトでメソッドが呼べない、ローカルのWindowsでしか動かない、といった制約があります。制約に引っかかる処理は、無理をせずその部分だけ5.1のまま残すのが現実的です。

社内スクリプトの5.1から7への移行はどう進めればよいですか？

一斉切り替えではなく段階移行にします。まずタスクスケジューラとスクリプト置き場から.ps1を棚卸しし、それぞれを7(pwsh)で実行テストして動くかを確認します。動いたものから#Requires -Version 7を書き足し、タスクスケジューラの起動コマンドをpowershell.exeからpwsh.exeに更新します。5.1でしか動かないものは無理に移行せず、どちらで動かすべきかを明示した上で残します。7自体はMSIまたはwingetで導入し、更新の配布方法もセットで決めておきます。

PowerShell 5.1と7の違いと移行手順

更新履歴(3件・最終更新 2026年08月02日)

この記事に加えた変更の記録です。アーカイブした更新前のバージョンは、DOI付きの固定URLから読めます。

2026年08月02日: 記事の冒頭に「この記事の知識マップ」節を追加しました。本文で扱っている概念とその関係を、要約・図・詳細ページへのリンクにまとめたものです。本文の主張は変えていません。
2026年08月01日: 外部レビュー(1283件)への対応として本文を更新しました。個々の変更内容は、この下の履歴を参照してください。
2026年08月01日: 棚卸しCSVの列の意味と書式例の表を追加し、何を見るために作る表なのかを明示しました。7のプロセスと`WinPSCompatSession`の関係図を追加して「7にあるのは入口だけ」であることを示し、ISEの扱い(新機能開発は終了、削除予定はなし)と移行先、どの7を入れるかの判断表、移行完了の合格基準と突き合わせのコードを追加しました。
2026年07月18日: 初版公開

この記事を引用する(DOI（登録済みアーカイブ）: 10.5281/zenodo.21590143)

以下のDOIは過去に登録されたアーカイブを指しており、現在の本文とは一致しない場合があります。現在の本文を参照するときは、このページのURLを使用してください。

小村豪(2026)「Windows PowerShell 5.1とPowerShell 7の違い ── 社内スクリプト移行の実務ガイド」合同会社小村ソフト. https://comcomponent.com/blog/windows-powershell-5-vs-powershell-7-migration/

DOI（登録済みアーカイブ）: 10.5281/zenodo.21590143
DOI（前回登録した版）: 10.5281/zenodo.21733089

「PowerShell 7を入れると、いま動いている5.1のスクリプトは壊れるのでしょうか」「5.1のまま使い続けてもよいのでしょうか」。社内の運用スクリプトを抱える現場で、よく聞かれる質問です。

最初に押さえたいのは、Windows PowerShell 5.1とPowerShell 7は、置き換えではなく共存する別製品だということです。7をインストールしても5.1は消えません。一方、既存タスクが powershell.exe を起動している限り、そのタスクは5.1で動き続けます。「7を導入した」と「スクリプトを7へ移行した」は別の状態です。¹²³⁴

移行で調べるべきなのは、インストールの影響よりも、実際に7で動かしたときの違いです。とくに日本語のファイル連携では、既定の文字コードが変わるため、読み書きの両方で文字化けが起き得ます。5.1専用モジュールへの依存や、タスクの起動引数も確認が必要です。⁵⁶³

この記事は、社内スクリプトを保守する情シス・運用担当者向けに、方針を決める → 棚卸しする → 7を用意する → 互換性を確認する → テストして起動先を切り替える順で説明します。一斉切り替えではなく、確認できたスクリプトから移すための実務ガイドです。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全26件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

1. 先に結論：新規は7、既存は確認できたものから移す

MicrosoftはWindows PowerShell 5.1への新機能追加を終了しており、そのサポートはWindows本体のライフサイクルに紐づきます。PowerShell 7は開発の主軸で、リリースごとにベースとなる.NETのサポートポリシーに沿ってサポート期間が設定されます。¹⁷

5.1が明日なくなるという話ではありません。ただし、これから書くもの・長く使うものは7を基準にし、既存資産は段階移行するのが本記事の方針です。7で動かすために処理が複雑になるなら、5.1専用の部分を無理に移す必要はありません。

論点	選択肢	判断の目安
新規スクリプトの基準	5.1 / 7	原則7。5.1は新機能追加なしの現状維持で、開発の主軸は7¹⁷
既存スクリプトの移行	一斉切り替え / 段階移行	棚卸し→7でテスト→通ったものから起動コマンド更新。サイドバイサイドだから段階移行できる⁴
5.1専用モジュールがある	移行を諦める / -UseWindowsPowerShell / その処理だけ5.1に残す	互換機能はシリアライズ制約(メソッド不可)を理解した上で。複雑になるなら5.1に残す方が保守しやすい⁶
バージョンの明示	何もしない / #Requires	全スクリプトに#Requiresか実行時チェックを入れる。想定外バージョンでの実行を実行前に止める⁸
ファイル入出力	既定に任せる / -Encoding明示	常に明示。5.1と7の既定差による文字化けを構造的に防ぐ⁵
7の更新運用	手動で入れ直す / MSIのMicrosoft Update連携かwinget	更新経路を決めてから配る。放置された古い7が最も危険³²

必要な箇所だけ確認する場合は、次の順に進んでください。

確認したいこと	読む章
5.1と7の関係、いま動いている実行環境	2章
移行対象の洗い出しと、7の導入・更新方法	3章・4章
文字化け、モジュール、実行バージョンへの対策	5章・6章・7章
「移行できた」と判断する基準と、タスクの切替	8章・9章

2. まず実行環境を確認する：5.1と7はどこが別なのか

2.1. 実行ファイル・配置先・サポートの違い

名前は似ていますが、基盤となる.NET、実行ファイル、インストール先が異なります。

項目	Windows PowerShell 5.1	PowerShell 7
入手方法	Windowsに同梱¹	別途インストール(MSI/winget等)²
基盤	.NET Framework 4.x⁴	.NET(7.4は.NET 8.0など)⁴³
実行ファイル	powershell.exe	pwsh.exe³
インストール先	$Env:windir\System32\WindowsPowerShell\v1.0⁴	$Env:ProgramFiles\PowerShell\7⁴
今後の開発	新機能の追加なし¹	開発の主軸。LTS/Stableのリリースあり⁷
サポート期間	Windows本体のライフサイクルに従う⁷	ベースの.NETのサポートポリシーに従う⁷

7は別ディレクトリにインストールされ、5.1とサイドバイサイドで動きます。モジュールの置き場(PSModulePath)、プロファイル、イベントログも別々です。ただし、7側の PSModulePath には5.1のモジュールパスも含まれるため、多くの既存モジュールを7から読み込めます。⁴²

この共存が、段階移行を可能にします。既存の powershell.exe を使う仕組みはそのまま残し、移行候補を pwsh.exe で確認できます。インストールしただけで既存タスクの実行先が変わるわけではありません。²³

2.2. 「いまどちらで動いているか」を確認する

$PSVersionTable は、現在のセッションのPowerShellバージョン情報を保持する自動変数です。次の2項目を見れば、5.1か7かを確認できます。⁹

# 自分がどちらのPowerShellにいるかを確認する
$PSVersionTable.PSVersion   # 5.1.x なら Windows PowerShell、7.x なら PowerShell 7
$PSVersionTable.PSEdition   # Desktop = Windows PowerShell / Core = PowerShell 7

スクリプトの実行テストでも、起動先を切り替えたあとでも、この区別を使います。「端末に7が入っているか」だけでなく、「その処理がどちらで実行されているか」を確認するためです。

3. 棚卸し：スクリプトと起動コマンドをセットで記録する

3.1. スクリプト置き場とタスクスケジューラを調べる

最初に、スクリプト置き場とタスクスケジューラから、動いている .ps1 と起動コマンドを洗い出します。次の例は、タスクの実行ファイル名と引数に powershell または pwsh が含まれるものをCSVへ出すものです。

# タスクスケジューラから、PowerShellを起動しているタスクを洗い出す
Get-ScheduledTask | ForEach-Object {
    foreach ($action in $_.Actions) {
        # cmd.exe /c powershell ... のような間接起動も拾うため、実行ファイルと引数の両方を見る
        if ("$($action.Execute) $($action.Arguments)" -match 'powershell|pwsh') {
            [pscustomobject]@{
                TaskPath  = $_.TaskPath        # タスク名はフォルダー内でしか一意でないため、パスも控える
                TaskName  = $_.TaskName
                Execute   = $action.Execute    # powershell.exe か pwsh.exe か
                Arguments = $action.Arguments
            }
        }
    }
} | Export-Csv -Path .\ps-tasks.csv -NoTypeInformation -Encoding UTF8

ps-tasks.csv は4列です。値は書式の例で、実際の内容は環境ごとに異なります。

列	内容	値の例
TaskPath	タスクのフォルダー。タスク名はフォルダー内でしか一意ではない	`\` や `\Contoso\Batch\`
TaskName	タスク名	`DailyReport`
Execute	起動する実行ファイル	`powershell.exe` / `C:\Program Files\PowerShell\7\pwsh.exe` / `cmd.exe`
Arguments	引数の文字列	`-NoProfile -ExecutionPolicy RemoteSigned -File C:\scripts\daily-report.ps1`

3.2. CSVでは、実行ファイルと引数を分けて読む

このCSVで確認したいのは、次の3点です。

見つけた呼び出し	確認すること
`Execute` が `powershell.exe`	まだ5.1で実行しているタスク。7への移行候補として記録する
`Execute` が `cmd.exe`	`Arguments` の中にあるPowerShellの起動部分を開いて確認する
`Arguments` に `-File` も `-Command` もない	位置指定で渡している内容を確認する。`pwsh.exe` への切替時には引数の解釈が変わるため、9章で明示する

タスク名はフォルダー内でしか一意ではないので、TaskName だけでなく TaskPath も残します。この分類をしておくと、どのスクリプトを試験し、どの起動設定を書き換えるのかを追えるようになります。

どちらで動かすべきかの記録は、移行の最後まで先送りしません。棚卸しの段階から5.1に残すもの・7を目指すものを分け、7章の #Requires や実行時チェックで明示します。テストに通ったものは、その結果に合わせて指定を確定します。

4. 7を用意する：導入方法・更新経路・編集環境を決める

4.1. 導入先に合わせてLTS・パッケージ形式を選ぶ

PowerShell 7は、MSIパッケージやwingetで導入します。版の選択と配布方法は、次の目安で決めます。⁴²⁷

論点	選択肢	判断の目安
どの版か	LTS / Stable	業務サーバーはLTS。LTSは.NETのLTSに対応する版で、更新は重大なセキュリティ修正と保守に絞られ、既存のワークロードへの影響が最小になるよう設計されています。Stableは新機能を含む代わりに、次のLTSが出てから約6か月でサポートが終わります⁷
クライアント端末	winget	公式がWindowsクライアントでの推奨方法として挙げています²
サーバー・多数展開	MSIパッケージ	Windows Serverと企業展開に最適と明記されています。コマンドラインのプロパティで更新経路まで指定できます²
MSIX(ストア)版	注意	ユーザー単位のインストールで全ユーザー向けにできず、アプリのサンドボックスによりWSMan経由のPowerShell Remotingが使えないなどの制限があります。サーバーには向きません²

wingetを使う場合の例です。

# wingetでのインストール。更新も winget upgrade で同じ経路に乗る
winget install --id Microsoft.PowerShell --source winget

# MSIパッケージで入れたい場合(サーバー・配布管理ツール向け)
winget install --id Microsoft.PowerShell --source winget --installer-type wix

wingetで入れることと、MSIで入れることは同じではありません。PowerShell 7.6.0のwingetパッケージ以降、winget install --id Microsoft.PowerShell は既定でMSIXを入れます。MSIが必要なら、例のように --installer-type wix を付けます。²

また、wingetはWindows Server 2022以前では使えません。Windows Server 2025でも同梱されるのはデスクトップエクスペリエンス版です。サーバー群への展開は、MSIパッケージを前提に計画するのが無難です。²

導入する版とサポート期間、利用できるパッケージ形式は、配布前に公式のインストール案内とライフサイクル情報を確認してください。上のwinget例は導入形式を示すもので、LTSの版を固定する指定ではありません。²⁷

4.2. 更新の配布方法も、インストール前に決める

7.2以降のMSIには、Microsoft Update経由で更新を受け取るオプションがあり、既定で有効です。WSUSや構成管理ツールの通常の更新フローに乗せられます。wingetで管理するなら、更新も winget upgrade の経路に揃えます。³²

避けたいのは、各端末へ個別に入れたまま、古い7が残り続ける状態です。「どう配るか」と「どう更新するか」をセットで決めてから導入します。

4.3. ISEでは7を実行できない：編集環境も切り替える

Windows PowerShell ISEは、Windowsから削除される予定はなく、セキュリティと優先度の高い修正も継続されます。ただし、新機能の開発は終了しており、対応するのはPowerShell 5.1以前だけです。7用のスクリプトをISEで書き、そのまま7で実行する運用にはできません。¹⁰

公式が案内する移行先は、Visual Studio CodeとPowerShell拡張機能です。統合コンソールで使うPowerShellのバージョンを切り替えられ、追加のパスも設定できます。ISEに慣れた人向けの操作感を再現するガイドも用意されています。¹⁰

情シスの現場ではISEの利用者も多いため、スクリプトの移行と編集環境の乗り換えを同じタイミングで案内してください。

5. 文字化けを防ぐ：データの入出力とスクリプトの保存を分ける

5.1. 同じコードでも、既定の文字コードが違う

日本語環境の移行で最初に確認したいのが、文字エンコーディングです。5.1はコマンドレットごとに既定が異なり、7はBOMなしUTF-8を既定にします。⁵

操作	5.1の既定	7の既定
Out-File・リダイレクト(`>`)	UTF-16LE(BOM付き)⁵	BOMなしUTF-8⁵
Set-Content / Add-Content	ANSI(日本語環境ではShift_JIS)⁵	BOMなしUTF-8
Get-Content(BOMなしファイル)	ANSI⁵	BOMなしUTF-8
Export-Csv	ASCII(日本語が失われる)⁵	BOMなしUTF-8
スクリプト自体の解釈(BOMなし)	ANSIコードページ⁵	UTF-8

たとえば、同じ Out-File の1行でも出力されるバイト列が変わります。

# 同じ1行でも、5.1と7ではできあがるファイルのバイト列が違う
'こんにちは' | Out-File -FilePath C:\temp\hello.txt
# 5.1で実行 → UTF-16LE(BOM付き)のファイル
# 7で実行   → BOMなしUTF-8のファイル

対策は、連携するデータファイルの文字コードと、スクリプト自身の保存形式の2つに分けて考えます。

5.2. データファイル：受け渡し先に合わせて `-Encoding` を明示する

Shift_JIS前提の連携では、読み取りと書き込みの両方が確認対象です。5.1の Get-Content がBOMなしファイルをANSI(日本語環境ではShift_JIS)として読んでいた場合、7へ替えるとUTF-8として解釈され、文字化けし得ます。書き出し側も、連携先が期待する文字コードを維持する必要があります。⁵

ファイル入出力では -Encoding を明示します。7ではコードページ番号(-Encoding 932)や登録名を指定でき、7.4以降は ansi という値も使えます。5.1と7を両方対象にする書き方は7.2節で示します。⁵

CSV処理の具体例は「PowerShellでExcel・CSV業務処理を自動化する」にまとめています。

5.3. スクリプト自身：非ASCII文字を含むならBOM付きUTF-8で保存する

データファイルとは別に、.ps1 自体の文字コードも確認してください。BOMなしUTF-8の日本語コメント入りスクリプトを5.1が読むと、ANSIとして誤解釈し、文字化けや構文エラーになることがあります。⁵

公式の推奨どおり、非ASCII文字を含むスクリプトをBOM付きUTF-8で保存すれば、5.1と7の両方で正しく解釈できます。データの -Encoding 明示と、この保存形式の統一が、移行時の文字化けを防ぐ基本です。⁵

6. モジュール互換性：7で直接動くか、5.1に任せるかを決める

6.1. 調べる対象は、モジュールだけではない

7は多くの既存モジュールを読み込めますが、そのまま動かないものもあります。まず通常の Import-Module で確認し、Microsoft製モジュールは公式の互換性ページも参照します。⁴¹¹

確認するもの	主な違い・影響
同梱モジュール	PSWorkflow / PSWorkflowUtility、PSScheduledJob、ISE用モジュール、Microsoft.PowerShell.LocalAccountsなどは7に含まれない³
スナップイン	モジュール以前の古い拡張形式で、7ではサポートされない³
.NET Frameworkに依存する処理	.NETのメソッドを直接呼ぶスクリプトは、基盤の変更によって挙動が変わることがある⁴³
コマンドレットの出力	`Export-Csv` は既定で `#TYPE` 行を出さず、`Group-Object` はソートされたグループを返すなど、出力に依存した処理へ影響する変更がある³

逆方向にも注意が必要です。三項演算子や ForEach-Object -Parallel など、7で追加された構文・機能を使うスクリプトは5.1では動きません。両方で動くように書くのか、実行する版を固定するのかを、スクリプトごとに決めます。⁴

6.2. Windows互換機能は、裏の5.1に処理を任せる仕組み

7で直接読み込めないモジュールには、Windows互換機能を使える場合があります。次は公式ドキュメントの例です。

# 7に対応していないモジュールを、互換機能経由で読み込む(公式ドキュメントの例)
Import-Module -Name ScheduledTasks -UseWindowsPowerShell

この機能は、モジュールを7向けに変換するものではありません。バックグラウンドでWindows PowerShell 5.1のプロセスを起動し、WinPSCompatSession にモジュールを読み込みます。7側には、暗黙のリモーティングで生成したプロキシモジュールがインポートされます。⁶

flowchart LR
    subgraph PS7["pwsh.exe ── PowerShell 7 のプロセス"]
        SCRIPT["スクリプト本体"]
        PROXY["プロキシモジュール<br/>暗黙のリモーティングで生成された入口。<br/>本体ではない"]
    end
    subgraph PS51["powershell.exe ── 裏で起動する 5.1 のプロセス"]
        SESSION["WinPSCompatSession<br/>互換機能で読み込んだ全モジュールが<br/>1つのランスペースを共有する"]
        MOD["5.1でしか動かないモジュールの本体"]
    end
    SCRIPT --> PROXY
    PROXY -->|"コマンドの呼び出しを転送"| SESSION
    SESSION --> MOD
    MOD -->|"結果"| SESSION
    SESSION -.->|"シリアライズされた値の写しだけが戻る<br/>メソッドは呼べない"| SCRIPT

7側にあるのは本体ではなく、呼び出しの入口だけです。7から5.1へ処理を頼み、結果の写しを受け取ります。System32配下の5.1専用モジュールは、名前指定やコマンドの自動検出でも、この仕組みで暗黙的に読み込まれます。⁶

6.3. 戻り値・実行場所・共有状態の制約を確認する

Windows互換機能には、次の制約があります。⁶

制約	スクリプト側で確認すること
シリアライズされた値をやり取りする	生オブジェクトではなく、プロパティのスナップショットが戻る。返ってきたオブジェクトのメソッドは呼べない
ローカルWindows限定で、5.1が必要	7だけで処理が完結するわけではない
全モジュールが1つのランスペースを共有する	互換機能で読み込むものは、同じ5.1プロセス内で動く
既定の読み込み拒否リストがある	PSScheduledJobなど、一部のモジュールは読み込みを拒否される

「取得した結果のメソッドを呼ぶ」「パイプラインの途中で生オブジェクトが必要」という処理は、戻ってきた値を7で扱う形では成立しません。パイプライン全体を5.1側で実行し、最終結果だけを受け取る方法もあります。⁶

ただし、そのために複雑になるくらいなら、該当する処理だけ5.1に残す方が保守しやすい場合があります。7で読み込めたことだけで移行完了とせず、直接実行なのか互換機能経由なのかと、戻り値の使い方まで確認します。

7. 実行する版を明示する：`#Requires` と実行時チェック

7.1. 専用スクリプトは、想定外の環境で動き始めないようにする

移行期間中は、5.1用と7用のスクリプトが混在します。途中まで動いてから壊れないよう、必要なバージョンやエディションをコードに明示します。

#Requires は、条件を満たさないPowerShellでは、スクリプトが実行される前に拒否させるための指定です。⁸

#Requires -Version 7.0
# このスクリプトは7専用(ForEach-Object -Parallel などを使用)。
# powershell.exe(5.1)で起動された場合、ここから先は一切実行されない

5.1に残すスクリプトには #Requires -PSEdition Desktop を書きます。Desktop がWindows PowerShell、Core がPowerShell 7系のエディション名です。-Version は必要なバージョン、-PSEdition は必要なエディションを指定するものとして使い分けます。⁸⁹

この明示は棚卸しの時点から進め、7でのテストに通ったものには #Requires -Version 7.0 を付けます。誰が見ても「どちらで動かす処理か」が分かる状態にしてから、起動設定を切り替えます。

7.2. 両対応にする処理だけ、`$PSVersionTable` で分岐する

両方で動かすスクリプトで、一部の処理だけ挙動を変えたい場合は、$PSVersionTable を使います。次は5章のShift_JIS読み取りを、実行環境に応じて指定する例です。⁹⁵

# 5.1と7の両対応スクリプトで、バージョン差がある処理だけ分岐する
if ($PSVersionTable.PSVersion.Major -ge 6) {
    $enc = 932            # 7: コードページ番号でShift_JISを指定できる
} else {
    $enc = 'Default'      # 5.1: Default = システムのANSIコードページ
}
Get-Content -LiteralPath $path -Encoding $enc

5.1側の Default は、そのシステムのANSIコードページです。日本語環境でのファイル連携という前提を確認し、スクリプトの保存形式とデータの文字コードを混同しないようにします。

8. テスト：「例外なく終わった」ではなく成果物で判定する

8.1. 実行テストの合格条件を決める

棚卸ししたスクリプトを pwsh で実行し、動作と出力ファイルを確認します。5.1と7は共存するため、既存の起動設定を切り替える前に、7でのテストを進められます。²

この共存は、同じ業務処理を本番で二重実行してよいという意味ではありません。出力比較は検証用の入出力先を用意して行い、変更系の処理は対象を確認してから試します。エラーになったら、5章の文字コード、6章のモジュール・.NET API・出力の違いを切り分けます。

合格条件は、次の7点です。

pwsh -NoProfile -File <スクリプト> が最後まで走り、$LASTEXITCODE が0で終わる。
エラーストリームに何も出ていない。想定内の警告は、内容を確認して許容する。
依存モジュールがすべて7で読み込める。Import-Module が通るだけでなく、互換機能経由になっていないかも確認する。
出力ファイルの中身が5.1版と一致する。
出力ファイルのエンコーディングが受け取り側の期待どおりである。Shift_JIS前提の連携先があるなら、とくに確認する。
変更系の処理は -WhatIf で対象が5.1のときと同じであることを確認した。
実行時間が極端に伸びていない。互換機能経由で遅くなる場合も確認する。

8.2. 出力の内容とバイト列を分けて比較する

同じスクリプトを5.1と7で実行し、出力を残して突き合わせます。次の例は、daily-report.ps1 が作る report.csv を比較するものです。

# 5.1と7で同じスクリプトを実行し、出力ファイルを比較する
& "$Env:windir\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -File .\daily-report.ps1
Move-Item .\report.csv .\report-51.csv -Force
& "$Env:ProgramFiles\PowerShell\7\pwsh.exe" -NoProfile -File .\daily-report.ps1
Move-Item .\report.csv .\report-7.csv -Force

# 行単位の差分。実行日時など毎回変わる列があるなら、その列を除いてから比較する
Compare-Object (Get-Content .\report-51.csv) (Get-Content .\report-7.csv)

# バイト単位で一致するかまで見る(BOMや改行コードの差はここに出る)
(Get-FileHash .\report-51.csv).Hash -eq (Get-FileHash .\report-7.csv).Hash

差分が出たら、まず値が違うのか、文字コード・BOM・改行コードが違うのかを分けます。実行日時など毎回変わる列は除いて比較し、Get-FileHash ではバイト単位の一致まで確認します。文字列の比較で差がなく、ハッシュだけ一致しない場合も、5章の文字コードや改行コードを確認してください。

比較する側の読み取りでも、ファイルの文字コードを確認します。-Encoding の指定が必要な連携では、5章の方針を比較時にも適用してください。

移行完了の基準は「7で例外なく終わること」ではなく、「5.1のときと同じ成果物が出ること」です。内容だけでなく、受け取り側が読める形式であることまで確かめてから、次の切替へ進みます。

9. 起動先を切り替える：ここまで行って初めて7への移行になる

テストに通ったスクリプトは7章の実行条件を確定し、タスクスケジューラのアクションを更新します。ここを忘れると、7へ移行したつもりでも、タスクは5.1のまま動き続けます。

# 変更前(5.1で実行される):
#   powershell.exe -NoProfile -ExecutionPolicy RemoteSigned -File C:\scripts\daily-report.ps1
# 変更後(7で実行される):
#   "C:\Program Files\PowerShell\7\pwsh.exe" -NoProfile -File C:\scripts\daily-report.ps1

実行ファイル名だけを機械的に置き換えないでください。pwsh.exe では、最初の位置指定パラメーターが -Command から -File に変わっています。位置指定でコマンド文字列を渡していた呼び出しは解釈が変わるため、スクリプトファイルなら -File、コマンド文字列なら -Command を明示します。3章で分類した呼び出しを、ここで確認します。³

実行ポリシーや署名は「PowerShellの実行ポリシーとスクリプト署名」、バッチファイルからの移行判断は「バッチをPowerShellに移行すべきか」を参照してください。

5.1専用のものは powershell.exe を使う設定と Desktop の指定を残します。すべてを同時に替えるのではなく、棚卸しの一覧とテスト結果を対応させながら、確認できたものから起動先を更新します。

10. まとめ

5.1と7は共存する別製品です。7のインストールだけで既存タスクの実行先は変わらず、powershell.exe から pwsh.exe へ起動設定を替えて初めて、その処理が7で動きます。5.1は新機能追加なしでWindowsのライフサイクルに従い、新規スクリプトは7を基準にします。¹⁷²³

移行時は、データ入出力の -Encoding とスクリプトのBOM付きUTF-8保存、モジュールの直接実行と互換機能経由の違い、#Requires と $PSVersionTable による実行環境の明示を確認します。互換機能で複雑になる処理は、無理をせず5.1に残します。⁵⁶⁸⁹

進め方は、棚卸し → 7の導入と更新経路の決定 → 実行テスト → 実行条件の確定 → 起動コマンドの更新です。テストでは処理結果とファイル形式を突き合わせ、成果物が同じであることを確かめます。この段階移行が、既存の運用を保ちながら7へ移す基本です。

参考リンク

Microsoft Learn, What is Windows PowerShell?. Windows PowerShellとPowerShellが別製品であること、Windows PowerShellはWindows同梱で.NET Framework上に構築され最新版が5.1であること、Microsoftが新機能による更新を行っておらず、サポートが使用中のWindowsのバージョンに紐づくことについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, Install PowerShell 7 on Windows. PowerShell 7がWindows PowerShell 5.1を置き換えず、新しいディレクトリにインストールされてサイドバイサイドで実行されること、既定のインストール先が$Env:ProgramFiles\PowerShell\7であること、winget・MSI等のインストール方法について。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵
Microsoft Learn, Differences between Windows PowerShell 5.1 and PowerShell 7.x. 実行ファイル名がpowershell.exeからpwsh.exeに変わりサイドバイサイドを支えること、最初の位置指定パラメーターが-Commandから-Fileに変わったこと、PSWorkflow・PSScheduledJob・LocalAccounts等のモジュールとスナップインが7に含まれないこと、Export-Csvの#TYPE既定省略やGroup-Objectのソート済み出力などの挙動変更、各バージョンのベース.NET、7.2以降のMSIのMicrosoft Update連携オプションについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³
Microsoft Learn, Migrating from Windows PowerShell 5.1 to PowerShell 7. PowerShell 7が5.1とのサイドバイサイド共存を前提に設計されていること(別のインストールパス・PSModulePath・プロファイル・イベントログ)、5.1のインストール先と7のインストール先、多くの既存モジュールが7で動作しUseWindowsPowerShellで互換性を補えること、三項演算子やForEach-Object -Parallelなどの新機能、MSI/ZIPによる展開について。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹
Microsoft Learn, about_Character_Encoding. Windows PowerShell 5.1の既定エンコーディングがコマンドレットごとに一貫しないこと(Out-FileとリダイレクトはUTF-16LE、Set-Content/Get-ContentはANSI、Export-CsvはASCIIなど)、PowerShell 6以降が一律BOMなしUTF-8を既定とすること、BOMなしスクリプトを5.1がANSIと誤解釈するため非ASCII文字を含むスクリプトはBOM付きUTF-8で保存すべきこと、コードページ番号指定や7.4のansi値について。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵
Microsoft Learn, about_Windows_PowerShell_Compatibility. 互換機能がバックグラウンドのWindows PowerShell 5.1プロセス(WinPSCompatSession)にモジュールを読み込み、暗黙のリモーティングでプロキシモジュールを生成する仕組みであること、UseWindowsPowerShellによる明示的な読み込みと自動読み込みの両方があること、シリアライズされた値で動作し生オブジェクトではないこと・ローカルWindows限定・単一ランスペース共有・既定の読み込み拒否リストという制約について。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
Microsoft Learn, PowerShell Support Lifecycle. PowerShell 7にLTSとStableのリリース区分があり、サポート終了日がベースの.NETのサポートポリシーに従うこと、Windows PowerShellはWindowsのコンポーネントとしてWindowsのサポートライフサイクルに従うことについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹
Microsoft Learn, about_Requires. #Requires文が、指定したPowerShellバージョン(-Version)、エディション(-PSEdition CoreまたはDesktop)、モジュールなどの前提条件を満たさない限りスクリプトの実行自体を拒否することについて。 ↩ ↩² ↩³ ↩⁴
Microsoft Learn, about_Automatic_Variables. $PSVersionTableが現在のセッションのPowerShellバージョン詳細を保持する読み取り専用ハッシュテーブルであること、PSEditionプロパティが5.1(フル機能版Windows)ではDesktop、6以降ではCoreの値を取ることについて。 ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Using Visual Studio Code for PowerShell Development. Windows PowerShell ISEがWindowsに残るものの新機能開発は終了しており、PowerShell 5.1以前でのみ動作すること、Windowsからの削除予定がなくセキュリティと優先度の高い修正は継続されること、PowerShell開発ではVisual Studio CodeとPowerShell拡張機能を使うこと、セッションメニューで使用するPowerShellを切り替えたりパスを追加設定できること、ISEの操作感をVS Codeで再現するガイドが用意されていることについて。 ↩ ↩²
Microsoft Learn, PowerShell 7 module compatibility. Microsoft製の各モジュール(Windows管理系モジュールを含む)のPowerShell 7対応状況がまとめられていることについて。 ↩

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

Windowsアプリ開発

業務アプリ、装置連携、通信ツールなどの Windows ソフト開発を支援します。

サービスを見るお問い合わせ

既存Windowsソフトの改修・保守

既存 Windows ソフトの機能追加、保守、段階的モダナイゼーションを支援します。

サービスを見るお問い合わせ

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

Windows PowerShell 5.1とPowerShell 7は何が違うのですか？: 別製品です。5.1はWindowsに同梱され.NET Framework上で動くもので、Microsoftは新機能の追加を終了しており、サポートはWindows本体のライフサイクルに従います。7は.NET(旧.NET Core)上で動く別インストールの製品で、現在の開発の主軸です。7は5.1を置き換えるのではなく、別ディレクトリにインストールされてサイドバイサイドで共存し、実行ファイル名もpowershell.exeとpwsh.exeで区別されます。
PowerShell 7をインストールすると既存の5.1のスクリプトは壊れますか？: 壊れません。7は別ディレクトリ(既定でProgram Files\PowerShell\7)にインストールされ、モジュール置き場もプロファイルも5.1とは別に管理されます。タスクスケジューラなどでpowershell.exeを起動している既存の仕組みは、これまでどおり5.1で動き続けます。だからこそ逆に、「7を入れただけでは何も移行されていない」点に注意が必要で、7で動かしたいスクリプトは起動コマンドをpwsh.exeへ明示的に切り替える必要があります。
PowerShell 7で今までのスクリプトが文字化けするのはなぜですか？: 既定の文字エンコーディングが変わったためです。5.1はコマンドレットごとに既定が異なり(Out-FileはUTF-16LE、Get-ContentはANSIなど)、7は一律BOMなしUTF-8です。日本語環境ではShift_JIS前提のファイル連携が多いため、既定のまま移行すると読み書きの両方で化け得ます。ファイル入出力の-Encodingを明示すること、非ASCII文字を含むスクリプト自体をBOM付きUTF-8で保存することの2点でほぼ防げます。
PowerShell 7で動かないモジュールはどうすればよいですか？: まず7で普通にImport-Moduleして動くか確認します。動かない場合、Windows互換機能(Import-Module -UseWindowsPowerShell)を使うと、バックグラウンドの5.1プロセスにモジュールを読み込み、リモーティング経由で7から使えます。ただし返ってくるのはシリアライズされたオブジェクトでメソッドが呼べない、ローカルのWindowsでしか動かない、といった制約があります。制約に引っかかる処理は、無理をせずその部分だけ5.1のまま残すのが現実的です。
社内スクリプトの5.1から7への移行はどう進めればよいですか？: 一斉切り替えではなく段階移行にします。まずタスクスケジューラとスクリプト置き場から.ps1を棚卸しし、それぞれを7(pwsh)で実行テストして動くかを確認します。動いたものから#Requires -Version 7を書き足し、タスクスケジューラの起動コマンドをpowershell.exeからpwsh.exeに更新します。5.1でしか動かないものは無理に移行せず、どちらで動かすべきかを明示した上で残します。7自体はMSIまたはwingetで導入し、更新の配布方法もセットで決めておきます。

著者プロフィール

記事の著者プロフィールページです。

小村豪

合同会社小村ソフト代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

プロフィールを見るお問い合わせ

公開リンク

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal