A3.1 選ぶときの判断基準

モジュールは一度入れるとその PC のどのスクリプトからも見えます。プロジェクト単位で隔離する仕組みがないぶん、入れる判断がそのまま PC の状態として残ります。

ギャラリーのページを眺めて決めるのではなく、次の6つを順に確かめます。どれも Find-Module だけで確認でき、ダウンロードは要りません。

① 提供元が公式か

ギャラリーは誰でも公開できます。名前だけでは本家か模倣かが分かりません。Find-Module の返す Author・CompanyName・ProjectUri を見ます。

Find-Module -Name PSScriptAnalyzer | Format-List Name, Author, CompanyName, ProjectUri

ProjectUri は開いて確かめます。star 数ではなく、直近の issue に返事が付いているかを見ます。

② 最終更新日

更新日は PublishedDate で見ます。

Find-Module -Name ImportExcel | Select-Object Name, Version, PublishedDate

Name          : ImportExcel
Version       : 7.8.10
PublishedDate : 2024/10/21 23:45:09

似た名前の値に引っかからない

メタデータには lastUpdated という、いかにも更新日らしい項目があります。両方を並べて見ます。

(Find-Module -Name ImportExcel).AdditionalMetadata |
	Select-Object published, lastUpdated

published   : 2024/10/21 23:45:09 +09:00
lastUpdated : 2026/08/26 00:00:01 +09:00

同じモジュールで2 年近い開きがあります。lastUpdated はギャラリー側のフィードを作り直した時刻で、どのモジュールを調べても実行した当日が返ります。4 本試して 4 本とも当日でした。

更新が止まっている＝除外、ではない

ImportExcel は 2024-10 で止まっていますが、Excel ファイルの読み書きという役割は変わりません。役割が完成しているモジュールは更新されないのが正常です。

逆に、動く環境が変わり続けるもの（クラウド API のクライアント、SQL Server 運用）が 2 年止まっていたら、それは危険信号です。更新日は単独では判断できず、何をするモジュールかとセットで見ます。

③ 5.1 と 7 の両方で動くか

タグに PSEdition_Desktop（＝Windows PowerShell 5.1）と PSEdition_Core（＝PowerShell 7）が入っています。

(Find-Module -Name Pester).Tags | Where-Object { $_ -like 'PSEdition_*' }

④ 依存の重さ

-IncludeDependencies を付けると、ダウンロードせずに依存を含む全件が一覧できます。返る件数がそのまま「増えるフォルダの数」です。

Find-Module -Name PSScriptAnalyzer -IncludeDependencies | Measure-Object

Count : 1

Find-Module -Name Microsoft.Graph -IncludeDependencies | Measure-Object

Count : 40

⑤ ダウンロード数を信用しない

ギャラリーで最初に目に入るのがダウンロード数です。これを選定根拠にできない例が実際にあります。

Find-Module -Name PSWindowsUpdate | ForEach-Object { $_.AdditionalMetadata.downloadCount }

2147474038

21 億 4747 万。世界人口の 4 分の 1 が 1 回ずつ入れた計算になります。この値は Int32 の上限 2147483647 のわずか 9,609 下で、上限に張り付いた飽和値と読むのが自然です。

⑥ 廃止されたモジュールは自分で消さない限り居座る

この PC には AzureRM が残っています。

Get-Module -ListAvailable AzureRM | Select-Object Name, Version, ModuleBase

Name       : AzureRM
Version    : 5.7.0
ModuleBase : C:\Program Files\WindowsPowerShell\Modules\AzureRM\5.7.0

AzureRM は Azure 操作の旧モジュールで、後継の Az に置き換わっています。それでも提供終了はギャラリー側の話であって、入れた PC からは何も起きません。残るものを数えます。

Get-ChildItem 'C:\Program Files\WindowsPowerShell\Modules' -Directory |
	Where-Object Name -like 'Azure*' |
	ForEach-Object { Get-ChildItem $_.FullName -Recurse -File } |
	Measure-Object -Property Length -Sum |
	Select-Object @{n='Files';e={$_.Count}}, @{n='SizeMB';e={[math]::Round($_.Sum/1MB)}}

Files  : 1124
SizeMB : 215

57 フォルダ・1,124 ファイル・215 MB。ファイルの最終更新は 2018-04-06 で、8 年前のまま AllUsers スコープに置かれています。しかも AzureRM.* は 53 個に分かれているので、Uninstall-Module AzureRM だけでは本体の 1 フォルダしか消えません。

A3.2 リストと概要

8 本に絞りました。網羅は目的ではありません。職種を問わず効くものを先に置き、対象がはっきり決まっているものを後ろに置いています。

一覧

版数・公開日・依存数は Find-Module の実測値です（2026-08-26 時点）。

どれから入れるか

この一覧に入れなかったもの

A3.3 詳細 — 4本を掘り下げる

PSScriptAnalyzer — 書いた直後に見つける

構文としては通るが、後で問題になる書き方を指摘します。JavaScript の ESLint、C# の Roslyn Analyzer にあたる位置づけです。

VS Code の PowerShell 拡張は内部でこれを使っているので、拡張を入れた人はすでに結果だけは見ています（エディタ上の緑の波線）。単体で入れると、同じ判定をコマンドラインと CI から呼べるようになります。

# 1ファイルを見る
Invoke-ScriptAnalyzer -Path .\deploy.ps1

# フォルダごと再帰する
Invoke-ScriptAnalyzer -Path .\src -Recurse

# 深刻なものだけに絞る
Invoke-ScriptAnalyzer -Path .\src -Recurse -Severity Error, Warning

# どんな規則があるか見る
Get-ScriptAnalyzerRule | Select-Object RuleName, Severity, CommonName

# 自動で直せるものを直す
Invoke-ScriptAnalyzer -Path .\deploy.ps1 -Fix

よく出る指摘

プロジェクトごとに規則を決める

既定の規則をそのまま全部使うと、既存のスクリプトでは指摘が数百件出ます。設定ファイルに置いて絞ります。

# PSScriptAnalyzerSettings.psd1
@{
	Severity = @('Error', 'Warning')

	ExcludeRules = @(
		'PSUseSingularNouns'
		'PSAvoidUsingWriteHost'
	)
}

Invoke-ScriptAnalyzer -Path .\src -Recurse -Settings .\PSScriptAnalyzerSettings.psd1

ImportExcel — Excel を入れずに xlsx を読み書きする

Excel ファイルを PowerShell から扱う方法には、Excel 本体を COM で起動するやり方があります。ImportExcel はそれとは別の道で、EPPlus という .NET のライブラリを同梱していて Excel を必要としません。

# 読む（1行 = 1オブジェクト。Import-Csv と同じ形で返る）
$rows = Import-Excel -Path .\売上.xlsx

# シートを指定する
$rows = Import-Excel -Path .\売上.xlsx -WorksheetName '2026年8月'

# 見出しが3行目から始まるブック
$rows = Import-Excel -Path .\売上.xlsx -StartRow 3

# 見出し行が無いので自分で名前を付ける
$rows = Import-Excel -Path .\売上.xlsx -NoHeader -HeaderName '日付','商品','金額'

# 書く（テーブル書式と自動列幅を付ける）
$rows | Export-Excel -Path .\集計.xlsx -AutoSize -TableName '売上'

# 既存ブックに別シートとして足す
$rows | Export-Excel -Path .\集計.xlsx -WorksheetName '明細' -Append

# 書き終わったら Excel で開く
$rows | Export-Excel -Path .\集計.xlsx -AutoSize -Show

# ピボットテーブルを付ける
$rows | Export-Excel -Path .\集計.xlsx -AutoSize `
	-IncludePivotTable -PivotRows '商品' -PivotData @{ '金額' = 'Sum' }

Import-Csv との違い

SecretManagement + SecretStore — 平文パスワードをコードから消す

2 本セットになっているのは、役割が分かれているからです。

この分け方の利点は、スクリプト側のコードが金庫の種類に依存しないことです。手元では SecretStore、本番では Azure Key Vault、という切り替えが Register-SecretVault の 1 行だけで済みます。

# 金庫を登録する（最初の1回だけ）
Register-SecretVault -Name LocalStore `
	-ModuleName Microsoft.PowerShell.SecretStore `
	-DefaultVault

# しまう（値は対話で聞かれる。コマンド履歴に残らない）
Set-Secret -Name 'DbPassword'

# 資格情報として丸ごとしまう
Set-Secret -Name 'SvcAccount' -Secret (Get-Credential)

# 取り出す（既定で [SecureString] が返る）
$sec = Get-Secret -Name 'DbPassword'

# PSCredential としてしまったものは PSCredential で返る
$cred = Get-Secret -Name 'SvcAccount'
Invoke-Command -ComputerName SRV01 -Credential $cred -ScriptBlock { hostname }

# 名前だけ一覧する（値は出ない）
Get-SecretInfo

# 登録してある金庫を見る
Get-SecretVault

更新が 2022 年で止まっていることをどう見るか

この 2 本の最終公開は 2022-01-27 です。A3.1 の ② に照らすと 4 年半動いていません。それでも採用する理由は 3 つあります。

• Microsoft 公式で、ProjectUri の GitHub は現役（issue に返答が付いている）
• やることが「窓口を提供する」だけで、機能を足す余地がほとんど無い
• 実際に動く部分（金庫）は差し替え可能なので、金庫側が更新されれば恩恵を受けられる

更新日は単独では判断材料にならないという ② の話が、そのまま当てはまる例です。

Pester — 同梱の 3.4.0 は使えない

Pester は Windows に同梱されています。この PC で見るとこうなります。

Get-Module -ListAvailable Pester | Select-Object Name, Version, ModuleBase

Name       : Pester
Version    : 3.4.0
ModuleBase : C:\Program Files\WindowsPowerShell\Modules\Pester\3.4.0

一方、ギャラリーの最新は 6.1.0（2026-08-11 公開）です。メジャーバージョンが 3 つ離れています。

問題は数字の差ではなく、3 系と 5 系以降で書き方が別物になっていることです。同梱の 3.4.0 のまま最近の記事のコードを打つと、Pester の使い方が間違っているのではなく構文エラーになります。

書き方

JavaScript 経験者には Jest の describe / it、Java・C# 経験者には JUnit の @Test や MSTest の [TestMethod] と同じ構造です。Should -Be が assert にあたります。

# tests\calc.tests.ps1
BeforeAll {
	. (Join-Path $PSScriptRoot '..\src\calc.ps1')
}

Describe 'Add-Number' {

	It '2 と 3 を足すと 5 になる' {
		Add-Number 2 3 | Should -Be 5
	}

	It '数値でない値を渡すと例外になる' {
		{ Add-Number 'a' 1 } | Should -Throw
	}

	It '複数の入力をまとめて確かめる' -ForEach @(
		@{ A = 1; B = 1; Expected = 2 }
		@{ A = 0; B = 5; Expected = 5 }
		@{ A = -3; B = 3; Expected = 0 }
	) {
		Add-Number $A $B | Should -Be $Expected
	}
}

# 実行する
Invoke-Pester -Path .\tests

# CI 用（失敗すると終了コードが 0 以外になる）
Invoke-Pester -Path .\tests -CI

新しい版を入れても古い版は消えない

Install-Module Pester -Scope CurrentUser をしても、C:\Program Files\WindowsPowerShell\Modules\Pester\3.4.0 はそのまま残ります。両方が見える状態になるので、スクリプト側で版を名指しします。

# スクリプトの先頭で明示する
#Requires -Modules @{ ModuleName = 'Pester'; ModuleVersion = '5.0' }

# または読み込み時に指定する
Import-Module Pester -MinimumVersion 5.0

A3.4 導入と運用

入れるときは -Scope CurrentUser を付ける

Install-Module の既定は AllUsers で、管理者権限が要り、PC を使う全員に影響します。個人の作業で入れるなら CurrentUser です。

Install-Module -Name PSScriptAnalyzer -Scope CurrentUser

探しに行く場所は $env:PSModulePath に並んでいます。この PC の pwsh 7 ではこうなっていました（ユーザー名は伏せています）。

$env:PSModulePath -split ';'

C:\Users\<username>\Documents\PowerShell\Modules
C:\Program Files\PowerShell\Modules
c:\program files\powershell\7\Modules
C:\Users\<username>\Documents\WindowsPowerShell\Modules
C:\Users\<username>\AppData\Local\Google\Cloud SDK\google-cloud-sdk\platform\PowerShell
C:\Program Files\WindowsPowerShell\Modules
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules

7 の一覧には 5.1 側の AllUsers フォルダも入っています。A3.1 ⑥ の AzureRM が 7 からも見えていたのはこのためです。他社製ツール（この PC では Google Cloud SDK）が自分の場所を差し込んでいることもあります。

オフライン環境へ配る — Save-Module

インターネットに出られない PC には Install-Module が使えません。出られる PC でダウンロードだけして、フォルダごと運びます。

# 出られる PC で、依存ごとフォルダに落とす
Save-Module -Name ImportExcel -Path C:\work\offline

# 版を固定したいとき
Save-Module -Name Pester -RequiredVersion 6.1.0 -Path C:\work\offline

C:\work\offline\
└── ImportExcel\
    └── 7.8.10\
        ├── ImportExcel.psd1
        ├── ImportExcel.psm1
        └── ...

# 出られない PC で、CurrentUser のモジュールフォルダへ丸ごとコピーする
Copy-Item C:\work\offline\ImportExcel `
	-Destination "$HOME\Documents\PowerShell\Modules" -Recurse

# 見えるようになったか確認する
Get-Module -ListAvailable ImportExcel

Save-Module は依存も一緒に落とします。A3.1 ④ で数えた通り、Microsoft.Graph なら 40 フォルダになります。運ぶ前に Find-Module -IncludeDependencies で件数を見ておくと、想定外の容量に驚かずに済みます。

依存を明示する — #Requires -Modules

03.3 の通り、PowerShell には package.json にあたるものがありません。必要なモジュールはスクリプト自身に書きます。

#Requires -Version 5.1
#Requires -Modules ImportExcel

# 版まで縛る
#Requires -Modules @{ ModuleName = 'Pester'; ModuleVersion = '5.0' }

# 複数まとめて
#Requires -Modules ImportExcel, PSScriptAnalyzer

# 管理者権限も要求できる
#Requires -RunAsAdministrator

足りない環境で実行すると、本体が 1 行も動く前に止まり、不足しているモジュール名がエラーに出ます。Import-Module を本体の途中に書いた場合と違って、ファイルを半分処理してから失敗することがありません。

廃止モジュールを掃除する

まず何が入っているかを見る

# 導入済みを名前順に見る
Get-Module -ListAvailable |
	Select-Object Name, Version, ModuleBase |
	Sort-Object Name

# 同じ名前で複数の版が入っているものを探す
Get-Module -ListAvailable |
	Group-Object Name |
	Where-Object Count -gt 1 |
	Select-Object Name, Count

# ギャラリーから入れたものだけに絞る
Get-InstalledModule | Select-Object Name, Version, InstalledDate

消す

# PowerShellGet で入れたものを消す
Uninstall-Module -Name PSWindowsUpdate -AllVersions

# 何が消えるか先に見る
Uninstall-Module -Name PSWindowsUpdate -AllVersions -WhatIf

A3.1 ⑥ の AzureRM のように多数のモジュールに分かれているものは、Uninstall-Module AzureRM だけでは束ね役の 1 フォルダしか消えません。AzureRM.* の 53 個も対象にする必要があります。AllUsers に入っているので、いずれにせよ管理者権限が要ります。

会社の PC での制約

実行ポリシー

モジュール自体は実行ポリシーの影響を受けませんが、モジュールを呼ぶスクリプトが動かなければ意味がありません。スコープごとの設定を見ます。

Get-ExecutionPolicy -List

5.1 この PC での結果です。

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process          Bypass
  CurrentUser       Undefined
 LocalMachine      Restricted

pwsh 7 同じ PC の 7 では LocalMachine が RemoteSigned でした。実行ポリシーは 5.1 と 7 で別々に保存されています。「7 では動くのに 5.1 では動かない」の原因がこれということがあります。

プロキシ

Find-Module が Unable to resolve package source 'https://www.powershellgallery.com/api/v2' で失敗するときは、たいていプロキシです。

$proxy = 'http://proxy.example.co.jp:8080'

# 認証なしのプロキシ
Find-Module -Name ImportExcel -Proxy $proxy

# 認証ありのプロキシ
Find-Module -Name ImportExcel -Proxy $proxy -ProxyCredential (Get-Credential)

-Proxy と -ProxyCredential は Install-Module・Save-Module にも同じように付きます。毎回打つのが面倒なら、プロファイル（03.3）に $PSDefaultParameterValues で既定値を置けます。

5.1 もう一段の壁 — TLS 1.2 と古い PowerShellGet

5.1 では、プロキシを越えても通信自体が失敗することがあります。この PC の 5.1 を見ます。

Get-Module -ListAvailable PowerShellGet | Select-Object Name, Version, ModuleBase

Name       : PowerShellGet
Version    : 1.0.0.1
ModuleBase : C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1

Windows 同梱の 1.0.0.1 です。7 側は 2.2.5 でした。この古い版は既定で TLS 1.0/1.1 を使おうとしますが、PowerShell Gallery は TLS 1.2 以上しか受け付けません。

# そのセッションだけ TLS 1.2 にする
[Net.ServicePointManager]::SecurityProtocol =
	[Net.SecurityProtocolType]::Tls12

# そのうえで PowerShellGet 自体を新しくする
Install-Module -Name PowerShellGet -Scope CurrentUser -Force

5.1 で最初につまずくのはたいていここで、モジュール名を間違えているわけでもプロキシの設定が悪いわけでもありません。7 側は 2.2.5 が同梱されているのでこの手当てが要りません。

PSResourceGet は 7 に同梱済み

A3.2 の一覧に Microsoft.PowerShell.PSResourceGet を入れましたが、この PC ではすでに使える状態でした。

Get-Module -ListAvailable Microsoft.PowerShell.PSResourceGet |
	Select-Object Name, Version, ModuleBase

Name       : Microsoft.PowerShell.PSResourceGet
Version    : 1.2.0
ModuleBase : C:\program files\powershell\7\Modules\Microsoft.PowerShell.PSResourceGet

PowerShell 7.4 以降に同梱されています（この PC は 7.6.3）。一方、5.1 側では 0 件でした。Install-PSResource を 5.1 で使いたければ、そちらには別途入れる必要があります。

この付録が Find-Module で通しているのは、5.1 と 7 のどちらでも同じコマンドが使えるからです。7 だけを相手にする場面では Find-PSResource のほうが速く動きます。

入れる前の確認