この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。Microsoft LearnのForEach-Object -Parallel、PowerShell並列実行、about_Classesを確認し、旧コードのRunspaceに関する誤解と擬似性能値を修正しました。検証ステータス：✅ Microsoft PowerShell公式資料確認済み
数百台・数千台のサーバーをPowerShellで確認するとき、コードをクラス化することより先に決めたいのが、同時実行数、タイムアウト、失敗時の扱い、結果の形式です。並列化は速くなる可能性がありますが、接続先やネットワークへ負荷を集中させるため、台数に比例してThrottleLimitを増やせばよいわけではありません。
ForEach-Object -ParallelはPowerShell 7以降
ForEach-Object -ParallelはPowerShell 7.0で導入されました。Microsoftのドキュメントでは既定のThrottleLimitは5です。またPowerShell 7.1以降は、既定でRunspace PoolのRunspaceを再利用します。
Windows PowerShell 5.1で同じ構文は使えません。5.1を維持する場合はRunspace APIなど別の実装が必要になるため、記事やスクリプトには対応バージョンを明記します。
まずは「読むだけ」の監視から始める
初期検証では、自動復旧を入れず、疎通結果などを構造化して返すだけにすると安全です。
$servers = @('server01','server02','server03')
$results = $servers | ForEach-Object -Parallel {
$name = $_
$ok = Test-Connection $name -Count 1 -Quiet -ErrorAction SilentlyContinue
[pscustomobject]@{
ComputerName = $name
Reachable = [bool]$ok
CheckedAt = Get-Date
}
} -ThrottleLimit 5
$results | Format-Table -AutoSizeこの形なら、結果をCSVやJSONへ保存したり、「失敗したものだけ次の詳細確認へ回す」といった段階的な処理へ広げられます。
クラスは便利だがRunspace境界を意識する
PowerShellクラスを使えば、監視結果のプロパティやメソッドを明示できます。しかし並列処理では別Runspaceが動くため、呼び出し元の状態がそのまま安全に共有されるとは限りません。Microsoftのabout_Classesでも、クラスとRunspace affinityを扱う際の注意が示されています。
そのため最初は、並列ブロックからPSCustomObjectの単純なデータを返し、集約後に必要な型へ変換する設計が理解しやすくなります。
大量実行で見る4つの値
| 値 | 見る理由 |
|---|---|
| ThrottleLimit | 同時実行数を制限し、接続先と実行端末の過負荷を防ぐ |
| Timeout | 応答しない端末で全体処理が止まるのを防ぐ |
| 成功 / 失敗数 | 「完了した」だけではなく監視品質を確認する |
| 所要時間 | 並列化の効果を実測する |
自動復旧は監視と分離する
旧記事では監視とサービス再起動を同じ流れに入れていましたが、大規模環境では「検知」と「変更」を分離した方が安全です。まず異常候補を一覧化し、対象・影響・メンテナンス条件を確認してから、承認された復旧処理へ渡します。
特に多数の端末へ変更を加えるスクリプトは、dry-run、対象台数上限、実行ログ、停止条件を用意してから運用します。
公式情報
- Microsoft Learn ― ForEach-Object
- Microsoft Learn ― 並列実行を使用してパフォーマンスを最適化する
- Microsoft Learn ― about_Classes
この記事の更新履歴
- 2026-09-14 追加：PowerShell 7/5.1差、ThrottleLimit、Runspace境界、自動復旧分離の考え方を追加。
- 2026-09-14 変更：大規模監視を「クラス中心」から「安全な並列実行と構造化結果中心」の設計へ再構成。
- 2026-09-14 削除：内部metadata/style_prompt、本文H1、未検証ドラフト表記、擬似性能値、Runspace内でクラスが自動共有されるという断定を削除。
