PowerShellで「バージョン確認」をしようとして、$PSVersionTable と Get-Host のどちらを見るべきか迷った経験はないでしょうか。ある端末では5.1、別の端末では7系と表示され、Windows TerminalやVSCodeでは結果が変わって見える――この状況では、更新判断やスクリプト互換性の確認が一気に難しくなります。
本記事では、PowerShell本体のバージョンを誤りなく確定する最短コマンドを起点に、Windows PowerShell 5.1とPowerShell 7の見分け方、結果がズレる典型原因と切り分け手順まで、運用でそのまま使える形で整理いたします。さらに、スクリプト内でのバージョン分岐テンプレートや、複数端末をリモートで棚卸しする方法も提示します。読了後には、「どの環境でも同じ基準で、迷わずバージョンを確定できる」状態に到達できるはずです。
※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。
PowerShellバージョン確認で最初に押さえる要点
PowerShellのバージョン確認は一見単純ですが、実際には「何のバージョンを指しているのか」が混ざりやすく、誤判定が起きやすい領域です。特に社内運用や手順書化の場面では、端末ごとの結果が揺れると、更新判断・互換性判断・トラブル切り分けが一気に難しくなります。まずは、バージョンという言葉が指し得る対象を分解し、以降の記事全体で判断基準を固定いたします。
確認したいのは本体かホストかを切り分ける
PowerShellの「バージョン」と言われたとき、代表的に混同される対象は次の3つです。
PowerShell本体のバージョン
実行中のPowerShellエンジン（言語機能・標準コマンド群・ランタイムとの連携）の版です。互換性やスクリプトの動作差は、基本的にこの本体版に強く依存します。本記事では、最優先でこの値を確認します。ホストのバージョン
PowerShellを「動かしている側」のアプリ（ConsoleHost、Windows PowerShell ISE、VSCodeの統合ターミナル、各種ホスト）が持つ情報です。ホストはユーザー体験（入出力、表示、履歴、エンコード、UI）に影響する一方で、本体版とは別物です。ここを本体版と誤認すると、端末間で矛盾した結果が出ます。モジュールのバージョン
PowerShellGetやPSReadLineなど、追加機能としてインストールされるモジュールの版です。本体が同じでもモジュール版が違えば挙動が変わることがあります。ただし、これは「本体のバージョン確認」とは別レイヤーの話です。
運用の基本方針としては、次の優先順位が安全です。
本体版の確定：
$PSVersionTable.PSVersion系統の確定：
$PSEdition（Desktop / Core）ホスト情報：必要なときだけ
Get-Hostで補助的に確認依存モジュール：問題が疑われる場合に追加で確認
この順序を守るだけで、バージョン確認に起因する混乱の大半は抑制できます。
Windows PowerShell 5.1とPowerShell 7は別物として扱う
Windows環境では、PowerShellが歴史的経緯により二系統で共存し得ます。
Windows PowerShell 5.1（主にWindows標準）
実行ファイルの代表例はpowershell.exeです。長年Windows標準として搭載され、社内端末で最も遭遇率が高い系統です。古い運用資産（バッチや古いスクリプト、古いモジュール）との親和性が高い一方、新しい機能はPowerShell 7系に集約される傾向があります。PowerShell 7系（クロスプラットフォーム系統）
実行ファイルの代表例はpwshです。Windowsに追加インストールして利用する構成が一般的で、Linux/macOSでも同じ系統を使えます。新しい構文・改善・標準コマンドの挙動差もあり、5.1と完全互換ではありません。
運用で重要なのは、「端末にPowerShellが何種類入っているか」よりも、「いま自分がどちらを起動しているか」を明確にすることです。Windows TerminalやVSCodeなどは起動プロファイル次第で powershell.exe と pwsh を簡単に切り替えられるため、同じ端末でも確認結果が変わり得ます。したがって本記事では、起動中のセッションに対して本体版を確定することを最優先として解説いたします。
PowerShellのバージョンを最短で確認するコマンド
ここでは「最短で、かつ誤りにくい」確認を軸に、段階的に情報量を増やす形で整理いたします。目的が「一瞬で版を知りたい」だけであっても、運用では「どの系統か」「どの実行ファイルか」まで押さえると再現性が高まります。
$PSVersionTable.PSVersionで本体バージョンを確認する
本体バージョン確認の第一選択肢は、次の1行です。
この出力は、実行中セッションのPowerShell本体版を示します。表示形式は環境により見え方が多少異なる場合がありますが、少なくとも以下の点が重要です。
Major（メジャー）：互換性や機能差の境目になりやすい
例：5.x と 7.x は大きく系統が異なります。Minor/Patch（マイナー/パッチ）：不具合修正や機能追加の差
例：同じ7でも7.2と7.4では挙動差があることがあります。
スクリプト内で利用しやすい形で取得する場合は、次が実用的です。
運用手順書では、最小限として「ToString()で文字列にしたもの」を記録させると、報告フォーマットが統一しやすくなります。
$PSVersionTableで詳細情報をまとめて確認する
次に、環境差の切り分けに必要な関連情報も含めて確認します。
$PSVersionTable は複数のキーを持つ情報集合で、PowerShell本体版だけでなく、実行環境の特性が含まれます。切り分けに効く典型例は以下です。
PSVersion：本体の版（最重要）
PSEdition：Desktop/Core（系統判定に重要）
CLR/WSMan：リモートや互換性・動作差の手掛かりになる場合あり
特に「同じ端末なのに、手順どおりに実行しても結果が違う」というときは、PSVersionだけでなくPSEditionも合わせて記録することで、誤起動（5.1のつもりが7だった等）を早期に発見できます。
$PSEditionでDesktopとCoreを見分ける
系統判定の最短は、次の1行です。
一般的には次のように解釈します。
Desktop：主に Windows PowerShell 5.1 系統Core：主に PowerShell 7 系統
運用上は「PSVersionの数字」だけで判断してもよいのですが、誤起動・誤認を避けるなら PSVersionとPSEditionをセットで記録させるのが堅牢です。例えば、問い合わせ対応では以下のような記録があるだけで話が早くなります。
PSVersion：5.1.19041.x
PSEdition：Desktop
どこから起動：ISE／Windows Terminal／VSCode など
pwshやpowershell.exeから一発で取得する
「いま開いているシェルがどちらか分からない」「端末棚卸しで強制的に両方確認したい」といった場合は、実行ファイルを明示して版を取得します。
ここで -NoProfile を付ける意義は、プロファイル（ユーザーの初期化スクリプト）による表示変更や関数上書きの影響を避け、素の状態で同じコマンドを実行するためです。運用では「確認コマンドはNoProfileを付ける」というルールにしておくと、端末ごとのばらつきを抑えられます。
確認コマンド早見表
| 何のバージョンか | 推奨コマンド | 取得できる内容 | 使いどころ |
|---|---|---|---|
| PowerShell本体 | $PSVersionTable.PSVersion | 本体Version | 原則これを採用 |
| PowerShell本体の詳細 | $PSVersionTable | Edition/CLR等も含む | 切り分け用の記録 |
| Edition | $PSEdition | Desktop/Core | 5.1と7系の判定 |
| 実行ファイル明示 | powershell.exe ... / pwsh ... | 各系統の版 | 共存端末の棚卸し |
| ホスト | Get-Host | Hostの情報 | UIやホスト依存の調査 |
| モジュール | Get-Module -ListAvailable | 存在する版の一覧 | 複数版混在確認 |
| モジュール | Get-InstalledModule | Gallery管理の導入済み | 導入状況の確認 |
PowerShellのバージョンがズレる原因と対処
「バージョンがズレる」と感じる典型パターンは、ほとんどが起動系統の取り違え、またはホスト情報と本体情報の混同に起因します。ここでは、誤判定の頻出原因と、運用での回避策を明確にいたします。
Get-Hostが示すのはホスト情報になり得る
Get-Host は次のようにホスト情報を返します。
ここで表示される Version は「PowerShell本体のPSVersion」と一致することもありますが、ホスト実装や状況により、本体版の確定情報としては不適切な場合があります。したがって、本記事の推奨は以下のとおりです。
本体版の確定：
$PSVersionTable.PSVersionを使うホストの特定・UI差の調査：必要なときだけ
Get-Hostを使う
運用手順書では、Get-Host のみを掲載すると混乱を招きやすいため、掲載する場合は「ホスト用」「参考」と明記することを推奨いたします。
また、現場でありがちな誤りとして、「ブログで見たからGet-Hostで確認して報告した」というケースがあります。この場合、報告値が“本体版”でない可能性があるため、必ず $PSVersionTable.PSVersion で再確認するフローにしておくことが安全です。
Windows TerminalやVSCodeでの確認ポイント
Windows TerminalやVSCodeは便利な一方、起動するシェルが複数になりやすく、「自分がいま何を起動しているか」を見失いやすい環境です。対策として、次の確認をセットで実行すると、取り違えが減ります。
ポイントは次のとおりです。
PSVersionとPSEditionで系統を確定する
これが最優先です。UIがTerminalでもVSCodeでも、本体はここで確定します。Get-Commandで実行ファイルのパスを確認する
pwshやpowershellがどのパスを指しているかは、複数インストールやPATH設定により変わり得ます。パスを添えて報告させると、棚卸しが正確になります。
運用設計としては、ユーザーに「Terminal上でPowerShellと書いてあっても、必ずPSVersionとPSEditionで確認する」と周知すると、問い合わせ件数が減ります。
ISE利用時に注意すべき点
Windows PowerShell ISEは、社内で根強く利用される一方、PowerShell 7系の標準的な開発体験とは別の前提で動いていることがあります。ISE上での確認も、基本は変わりません。
本体版の確定：
$PSVersionTable.PSVersion系統の確定：
$PSEdition
また、ISE利用者は「ISEを開いた＝PowerShellを開いた」と認識しがちですが、実際には「ISEというホスト上でPowerShellが動いている」状態です。従って、ホスト情報（Get-Host）と本体版（PSVersionTable）を混同しないよう、手順書や教育資料で明示することが重要です。
PowerShellバージョン確認を自動化する方法
運用では「人が目視で確認する」だけでなく、「スクリプト内で判定して処理を分岐する」「複数端末から自動収集する」まで踏み込むことで、作業の品質と再現性が大幅に向上します。ここでは、安全に使えるテンプレートと棚卸し例を提示いたします。
スクリプトでのVersion比較と分岐テンプレート
バージョンに応じて処理を分岐したい場合、文字列比較ではなく [Version] として比較するのが基本です。文字列比較は 7.10 と 7.9 のようなケースで誤判定が起き得ますが、Version型比較ならそのリスクを避けられます。
運用でさらに堅牢にする場合、以下の観点も加えるとよいです。
Editionで大枠を判定してから、Versionで細部を判定する
例えばCore/ Desktopで使える機能差がある場合、先にPSEditionで分けると読みやすくなります。プロファイルの影響を避ける
自動化では-NoProfileの付与を標準化すると、端末ごとの差が減ります。
また、非常に古い環境では $PSVersionTable 自体が存在しない可能性があります。その場合に備えるテンプレート例は次のとおりです。
「未知」として扱う方針を採ることで、誤った数字を作ってしまうリスクを避けられます。運用では、未知の場合は手動調査に回すルールが現実的です。
リモートで端末のPowerShellバージョンを棚卸しする
複数端末を対象に「実際に動いているPowerShell本体版」を取得する場合、リモート実行で同じコマンドを走らせるのが最も確実です。例えば端末名配列を用意し、Invoke-Command で取得します。
ここでの実務的な要点は次のとおりです。
返す形式は
[pscustomobject]で統一する
端末数が増えるほど、文字列出力では集計しにくくなります。オブジェクトで返すと、CSV化・ソート・フィルタが容易です。ComputerNameは必ず返す
端末名がないと結果の突合ができません。$env:COMPUTERNAMEは簡便です。
結果を資産管理や台帳に載せるなら、CSV化が便利です。
運用では、次のような項目を追加すると、後続作業（更新計画・影響調査）がやりやすくなります。
実行ファイルの存在（pwshがあるか）
主要モジュールの版（PSReadLineなど）
OSバージョン（必要な場合）
ただし、項目を増やしすぎると取得失敗や権限問題が増えるため、最初はPSVersion/PSEdition/端末名の3点から始め、必要に応じて拡張するのが安全です。
併せてモジュールのバージョンも確認する
本体版が同じでも、モジュールの版の違いで挙動が変わることがあります。特に次のような場面では、モジュール版確認が切り分けに有効です。
インストール・更新系のエラーが出る
タブ補完や履歴の挙動が端末で違う
Galleryからの導入可否が端末で違う
存在する版を一覧する場合は、次が基本です。
この出力で「同じモジュールが複数バージョン存在する」ケースがあります。複数版があると、読み込まれる版が状況により変わる可能性があります。問題が出ている場合は、次も合わせて確認します。
こちらは「現在セッションで読み込まれている版」を確認するのに使えます。
つまり運用上は、次の使い分けが明確です。
-ListAvailable：端末内に存在する全版（混在の有無）付けない：いま読み込まれている版（実害の原因調査）
Gallery管理下の「導入済み」を確認したい場合は、環境が整っていれば次も候補です。
ただし、これは利用環境・設定・権限に左右されるため、手順書では「利用できる場合」の補助として載せるのが安全です。
PowerShellバージョン確認のチェックリストとFAQ
最後に、現場で迷いがちなポイントを「チェックリスト」と「FAQ」で固定化いたします。運用では、問い合わせ対応テンプレートとしてそのまま流用できる形を意識しています。
結果が期待と違うときの確認順
以下は、バージョン確認結果が想定と食い違うときの、推奨切り分け順です。上から順に潰すことで、原因に最短で到達しやすくなります。
本体確認は
$PSVersionTable.PSVersionで実行しましたかGet-Hostだけで判断していないか確認してください。$PSEditionを同時に確認しましたか
Desktop/Coreが異なると、同じ端末でも起動している系統が違う可能性があります。どの実行ファイルで起動しているかを確認しましたか
Terminal/VSCodeではプロファイルによりpwshとpowershell.exeが切り替わります。Get-Command pwshとGet-Command powershellのSourceを確認しましたか
PATHや複数インストールで、指している実体が想定と違う場合があります。リモート実行かローカル実行かを明確にしましたか
リモートの場合、取得できているのは「リモート側の値」です。実行場所の取り違えがないか確認してください。プロファイル（初期化スクリプト）の影響を排除しましたか
可能であれば-NoProfileを付けて再確認してください。モジュール版の差が影響していないかを確認しましたか
本体が同じでも、モジュール版が異なると挙動が変わることがあります。
このチェックリストを手順書の末尾に置き、「迷ったらここに戻る」導線にすると、自己解決率が上がります。
よくある質問
Q. $PSVersionTable が出ない場合はどうすればよいですか。
A. 非常に古いPowerShell環境の可能性があります。まず次で存在確認を行い、存在しない場合は「未知」として扱い、手動調査に切り替える運用が安全です。
Q. Get-Host の Version を使ってよい場面はありますか。
A. ホストを特定したい場合（ISEかConsoleHostか等）や、UI・ホスト依存の挙動を調査したい場合には有効です。ただし「本体バージョンの確定」用途では、$PSVersionTable.PSVersion を優先してください。
Q. PowerShell 7が入っているかを確認する方法はありますか。
A. 端末上で pwsh が実行可能かを確認し、実行できる場合は pwsh 上で $PSVersionTable.PSVersion を取得してください。
Q. 5.1と7でスクリプトが動かないとき、最初に確認すべき点は何ですか。
A. まず「どの系統で動かしているか」を確定するために、次の2点を記録してください。
$PSVersionTable.PSVersion$PSEdition
そのうえで、依存モジュールの版や、利用しているコマンドの互換性（5.1専用機能、7専用機能）がないかを確認すると、切り分けが進みます。
Q. モジュールのバージョン確認はどのコマンドが適切ですか。
A. 端末内に存在する全バージョンの棚卸しには Get-Module -ListAvailable、いま読み込まれている版の確認には Get-Module（-ListAvailableなし）を使うのが基本です。Gallery導入済みの確認は、環境が整っていれば Get-InstalledModule が候補です。
まとめ
PowerShellのバージョン確認は、確認対象を取り違えないことが最重要です。本記事では運用での再現性を重視し、本体バージョンは$PSVersionTable.PSVersionで確定する方針を軸に解説いたしました。加えて、$PSEditionでDesktop/Coreを判定することで、Windows PowerShell 5.1とPowerShell 7系の取り違えを防げます。
特にWindows TerminalやVSCodeのように起動プロファイルが複数になりやすい環境では、「画面上の見た目」ではなく、PSVersionとPSEditionと実行ファイルの実体で判断するのが安全です。運用としては、次の行動が効果的です。
端末ごとの棚卸しが必要なら、
Invoke-Commandで一括取得しCSV化する問題が疑われる場合は、本体版に加えてモジュール版（
Get-Module -ListAvailable）も確認する仕様変更や環境更新が入った際は、手順書の確認コマンド（NoProfile含む）を定期的に見直す
PowerShellは更新や共存が起こりやすい領域ですので、今後仕様や導入状況が変わった場合でも、「本体版を確定する」→「系統を確定する」→「実行ファイルとホストを確認する」の順に戻っていただければ、安定した判断が可能です。