PowerShellで複数PCの状態を収集する ― CIMセッションとWinRMを分けて考える

この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。PowerShellのCIM・Remotingの役割を見直し、旧記事の「Ping成功=WinRM利用可能」「CIMなら常に5985/5986」という単純化や擬似性能値を修正しました。

検証ステータス：✅ PowerShell標準機能の役割を再整理

複数PCの状態を集めるとき、まず区別したいのはネットワーク疎通、CIM接続、PowerShell Remotingです。Pingが通るからCIMやWinRMが使えるとは限らず、Pingが遮断されていても管理プロトコルが利用できる環境もあります。

実際の接続を試して判定する

前段でTest-Connectionだけを成功条件にせず、必要な管理プロトコルのセッション生成を実際に試します。

$session = $null
try {
    $session = New-CimSession -ComputerName $computer -ErrorAction Stop
    $os = Get-CimInstance -CimSession $session -ClassName Win32_OperatingSystem
    $disk = Get-CimInstance -CimSession $session -ClassName Win32_LogicalDisk -Filter 'DriveType=3'

    [pscustomobject]@{
        ComputerName = $computer
        Status       = 'OK'
        Caption      = $os.Caption
        FreeMemoryMB = [math]::Round($os.FreePhysicalMemory / 1KB, 0)
        DiskCount    = @($disk).Count
    }
}
catch {
    [pscustomobject]@{
        ComputerName = $computer
        Status       = 'FAILED'
        Error        = $_.Exception.Message
    }
}
finally {
    if ($session) { Remove-CimSession $session }
}

イベントログは別の収集経路として扱う

Get-WinEvent -ComputerNameと、Invoke-Command { Get-WinEvent ... }では通信経路・前提が同じとは限りません。組織でPowerShell Remotingを標準化しているなら、リモート側でGet-WinEventを実行して必要な件数だけ返す設計も候補です。

大量PCでは段階化する

1. 対象リストを固定する。
2. 低コストな基本情報を収集する。
3. 失敗理由を対象ごとに保存する。
4. 異常PCだけ詳細ログ取得へ進める。
5. 変更操作は監視処理と分ける。

PowerShell 7ではForEach-Object -Parallelも使えますが、ThrottleLimitを上げ過ぎると管理端末・ネットワーク・対象PCへ負荷を集中させます。まず小さな同時実行数から実測します。

公式情報

• Microsoft Learn ― New-CimSession
• Microsoft Learn ― Get-WinEvent
• Microsoft Learn ― Security considerations for PowerShell Remoting using WinRM

この記事の更新履歴

• 2026-09-14 追加：CIMセッションの実接続で判定する例と、イベントログ経路を分ける考え方を追加。
• 2026-09-14 変更：一括監視コード中心から、接続方式・失敗理由・段階収集を重視する設計へ変更。
• 2026-09-14 削除：内部style_prompt、本文H1、擬似性能値、Ping結果をWinRM可否と同一視する説明を削除。