- WMIとPowerShellのCIMコマンドレットを使用すると、ローカルおよびリモートの管理情報を効率的に照会および変更できます。
- CimSessionsとWSManまたはDCOMを組み合わせることで、最新のネットワーク機器と旧式のネットワーク機器の両方への安全かつ互換性のあるアクセスが可能になります。
- 高度な関数、モジュール、ジョブ、およびDSCを使用することで、PowerShellは完全なインフラストラクチャ自動化言語へと進化します。
- PowerShellは、ローカル、リモート、Azure、およびMicrosoft 365の管理を単一の環境に統合し、反復的な手作業を削減します。
Windowsシステムの管理業務に携わっていると、遅かれ早かれPowerShell、WMI、そして高度な自動化ツールに出会うことになるでしょう。単にいくつかのコマンドの実行方法を知っているだけでは十分ではありません。数十台、数百台ものサーバーを管理する場合、情報を収集し、変更を適用し、タスクを繰り返す際に、混乱したりシステムを壊したりすることなく、体系的で安全なアプローチが求められます。
以下では、WMI、CIM、PowerShellのリモート通信を活用して、単純なクエリから複雑なインフラストラクチャシナリオまで、あらゆるものを自動化する方法について、冷静かつ徹底的に解説します。また、これらがモジュール、バックグラウンドタスク、Azure、Microsoft 365、そしてシステム管理者の日常業務に大きな違いをもたらす高度な機能とどのように連携するのかについても見ていきます。
PowerShellの機能強化と高度な自動化の概要
Windows PowerShellは初期バージョンから大きく進化しており、その進化の大部分はWindows Server 2012によってもたらされました。Windows Server 2012では、リモート通信が改善され、利用可能なコマンドレットが拡張され、デバッグ、バックグラウンドジョブ、制限付きエンドポイントなどの操作が容易になり、セキュリティが向上しました。
この環境の重要なコンセプトの一つは、管理者が高度な機能、再利用可能なモジュール、そして包括的なヘルプシステムを活用することで、複雑なコーディングをすることなく、コマンドレットのような動作を実現できる点です。つまり、ばらばらのグラフィカルツールに頼るのではなく、サーバー、ネットワーク、Active Directory、Azure、またはMicrosoft 365の管理プロセスを自動化する、一貫性のあるスクリプトとモジュールのセットを構築できるということです。
高度な自動化の分野では、タスクを非同期で実行するジョブ、ワークフロー、PowerShell DSC を使用した構成ベースの管理、JEA (Just Enough Administration) や PowerShell Web Access などのセキュリティオプションといった機能が際立っており、各ユーザーが何をどこから実行できるかを詳細に制御できます。
このエコシステム全体は、WMIやCIMと特に相性が良い。なぜなら、オペレーティングシステムによって公開される管理情報（ハードウェア、サービス、プロセス、ネットワーク構成、インストール済みソフトウェアなど）が、大量自動化向けに設計されたPowerShellコマンドを使用してクエリ、フィルタリング、変更できるオブジェクトのセットとなるからである。
WMIとCIM：主要概念と実務上の違い
Windows Management Instrumentation（WMI）は、PowerShellに依存しないテクノロジーであり、長年にわたりWindowsに組み込まれています。オペレーティングシステム、ハードウェア、および多くのアプリケーションに関する管理情報のリポジトリを提供します。WMI自体はPowerShellに依存しませんが、PowerShellはタスクの自動化にWMIを幅広く活用しています。
PowerShell エコシステムにおける WMI の後継として当然に位置づけられるのが、PowerShell 3.0 で導入されたCIM (Common Information Model) コマンドレットです。これらのコマンドレットは CimCmdlets モジュールにまとめられており、Get-CimInstance、Get-CimClass、New-CimInstance、Invoke-CimMethod、Register-CimIndicationEvent、Set-CimInstance、Remove-CimInstance などのコマンドが含まれています。
Windows PowerShell の旧バージョン（Windows 10 PowerShell 5.1 や Windows 11 PowerShell など）では、従来の WMI コマンドレット（Get-WmiObject、Invoke-WmiMethod、Register-WmiEvent、Remove-WmiObject、Set-WmiInstance）が引き続き利用できます。ただし、これらのコマンドレットは非推奨となり、PowerShell 6 以降のバージョンには含まれていないため、レガシー スクリプトの保守や古いコードのレビューにのみ役立ちます。
「CIMコマンドレットでWMIを照会する」という話は、矛盾ではありません。CIMコマンドレットは依然としてWMI情報にアクセスしますが、WSManなどのより新しいプロトコルと、より一貫性のあるAPIを使用します。実際には、新規開発においてはCIMに重点を置き、WMIコマンドレットは、移行や既存スクリプトの理解が必要な場合にのみ検討すべきです。
従来、多くの管理者はWMIへのクエリにWQLクエリ言語を使用したVBScriptを使用していました。例えば、 root\CIMV2名前空間に接続し、Win32_BIOSなどのクラスをクエリしていました。現在では、Get-CimInstanceコマンドレットに-Queryパラメーターを渡すことで、同じWQLクエリを再利用できます。これにより、ロジックを最初から書き直すことなく、VBScriptからPowerShellへの移行が大幅に簡素化されます。
Get-CimInstance の実践的な使用法と効率的なクエリ
日常業務において、PowerShell で WMI を照会する最も自然な方法は、完全な WQL クエリを記述するのではなく、 Get-CimInstance コマンドレットに -ClassName パラメーターを指定することです。たとえば、BIOS 情報を取得するには、Get-CimInstance -ClassName Win32_BIOS を使用すると、Manufacturer、Name、SerialNumber、SMBIOSBIOSVersion などのプロパティを持つオブジェクトが返されます。
PowerShell ではすべてがオブジェクトなので、必要なものだけを簡単にフィルタリングして選択できます。シリアル番号だけに関心がある場合は、結果を `Select-Object -Property SerialNumber` にパイプするか、`Select-Object -ExpandProperty SerialNumber` を使用してプロパティを持つオブジェクトではなく単純な文字列を出力できます。もう 1 つの一般的なオプションは、ドット構文 (`Get-CimInstance ...`).SerialNumber` を使用して値に直接アクセスすることです。
デフォルトでは、 WMIクエリは実際に使用するよりも多くのプロパティを返すことに注意してください。ローカルマシンでは通常問題ありませんが、多数のリモートマシンにクエリを実行すると、処理時間の増加と不要なネットワークトラフィックの増加につながります。そこで役立つのが、`Get-CimInstance`コマンドレットの`-Property`パラメーターです。このパラメーターを使用すると、ソースから取得するプロパティを制限できます。
例えば、-Property SerialNumber を指定することで、転送されるデータ量を削減し、特に大規模な環境において、クエリの速度と効率性を向上させることができます。数十台、数百台のマシンで実行されるインベントリや監査スクリプトを設計する際には、この「必要なものだけを要求する」という考え方が非常に重要になります。
要約すると、Get-CimInstance は、具体的なクラス、従来の WQL クエリ、または取得を最適化したい特定のプロパティのいずれを扱う場合でも、シンプルさ（コマンドラインが 1 つだけ）と柔軟性の強力なバランスを提供します。
CIM、セッション、WSMan/DCOMプロトコルを使用した遠隔相談
ローカルマシンから離れてリモートマシンにアクセスする場合、権限、通信プロトコル、パフォーマンスなど、いくつかの要素が関係してきます。PowerShellは「危険」だと考える人も多いですが、実際には特別な権限は付与されません。グラフィカルインターフェイスや他のツールとまったく同じ権限しか持たず、それ以上でもそれ以下でもありません。
十分な権限がない状態で `Get-CimInstance -ComputerName Server -ClassName Win32_BIOS` を実行しようとすると、「アクセスが拒否されました」というエラーが表示されます。これは PowerShell 自体に問題があるわけではなく、セッションを実行しているユーザーに WMI の情報にアクセスする権限がないためです。もちろん、ドメイン管理者としてコンソールを開くことはできますが、その場合、すべてのコマンドがその権限で実行されるため、多くの環境では不必要なリスクとなります。
推奨されるのは、最小権限の原則を適用し、必要な場合にのみ権限を昇格することです。-Credential パラメーターをサポートするコマンドレットでは、対象のコマンドに対してのみ代替資格情報を指定できます。ただし、Get-CimInstance は -Credential を直接受け付けないため、CimSessions が優れた解決策として役立ちます。
CimSession は、リモート コンピューターへの永続的な接続であり、New-CimSession コマンドレットを使用してコンピューター名と資格情報を渡して作成できます (例: New-CimSession -ComputerName dc01 -Credential (Get-Credential))。このセッションは、$CimSession などの変数に格納され、Get-CimInstance コマンドレットで -ComputerName パラメーターの代わりに -CimSession パラメーターを使用することで再利用できます。これにより、複数のクエリを単一の接続に統合できます。
資格情報要件に加えて、Get-CimInstance コマンドレットは既定でWSMan プロトコル (WinRM ベース)を使用します。つまり、リモート マシンには WSMan スタック バージョン 3.0 以上がインストールされている必要があります。これは通常、PowerShell 3.0 以降に含まれています。この接続方法を使用するには、マシンの WSMan スタック バージョンを `Test-WSMan -ComputerName RemoteComputer` コマンドレットで確認し、「Stack」の値が 3.0 以上であることを確認してください。
CIMセッションとDCOMおよび下位互換性
Get-WmiObject に基づく古い WMI コマンドレットは、DCOM プロトコルに依存しており、これは古いバージョンの Windows ではまだサポートされています。問題は、より新しいシステムでは、ファイアウォールがデフォルトで DCOM をブロックすることが多く、そのまま使用するには特定のポートを開放する必要があり、組織のセキュリティ ポリシーに違反する可能性があることです。
CIM コマンドレットは、強力な中間的な解決策を提供します。`New -CimSessionOption -Protocol Dcom`を使用してセッション オプションを作成し、それを変数 (たとえば `$DCOM`) に保存してから、`New-CimSession` と組み合わせて、WSMan の代わりに DCOM を使用する CimSession を生成できます。これにより、PowerShell がインストールされていない Windows Server 2000 より前の古いサーバーにも接続できます。
ドメイン管理者資格情報や昇格アカウントの資格情報を変数に格納しておくと、毎回入力する必要がなくなるので便利です（例：$Cred = Get-Credential）。その後、New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred のようなコマンドを実行することで、WSManをサポートしていないもののWMIを備えている古いサーバーに対して、DCOM経由でCimSessionを開始できます。
スクリプト作成者の視点から見ると、最大の利点は、`Get-CimInstance` の出力がプロトコルによって変化しないことです。WSMan を使用する場合でも DCOM を使用する場合でも、同じオブジェクトとプロパティを取得できます。これにより、適切なプロトコルの検出を関数にカプセル化し、残りのコードが常に CimSessions を透過的に扱うことができるため、ロジックが大幅に簡素化されます。
実際、Test-WSManコマンドレットを使用してWSManをテストし、利用できない場合はNew-CimSessionOptionコマンドレットを使用して自動的にDCOMに切り替えるカスタム関数を作成するのはごく一般的です。これにより、最新のサーバーとレガシーサーバーが混在する環境全体でCimSessionの作成を標準化でき、すべてのスクリプトに接続ロジックを重複して記述する必要がなくなります。
CimSessionsの管理、リスト化、およびクリーニング
CimSession を頻繁に使用するようになると、不要な接続が蓄積されないように、セッションの管理が重要になります。Get -CimSession コマンドレットを使用すると、開いているすべてのセッションを一覧表示し、それらがどのマシンを指しているか、どのプロトコル (WSMAN または DCOM) を使用しているかを確認できます。これは、接続や認証の問題を診断する際に非常に役立ちます。
また、既存のセッションを変数に取得することもできます。たとえば、$CimSession = Get-CimSession のようにして、Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS という単一のコマンドで使用して、複数のコンピューターを一度に照会し、WSMan セッションと DCOM セッションを同じ操作で組み合わせることができます。
情報の分析が完了したら、不要なリソースを開いたままにしないよう、セッションを閉じることをお勧めします。Get -CimSession | Remove-CimSession コマンドレットは、現在のプロファイルからすべてのアクティブな CimSession を一度に削除します。あるいは、特定のセッションを Remove-CimSession コマンドレットに渡して、一部のセッションのみを閉じることもできます。
この方法で作業することで、接続と切断のサイクルを制御できます。これは、スケジュールされたタスク、自動化ランブック、または継続的インテグレーションパイプライン内でスクリプトを使用する場合に強く推奨されます。これらのプロセスでは、クリーンアップを明示的に計画しないと、セッションがハングアップしてしまう可能性があります。
PowerShellは包括的な自動化言語である。
PowerShellは、WMIやCIMといった従来のツールにとどまらず、汎用的な自動化言語として広く普及し、一般的なWindows管理スクリプトの枠をはるかに超える機能を持つようになりました。LinuxやWindowsへのインストールから、NuGetを介した配布可能なモジュールの開発、さらにはVisual Studio Codeのような最新の開発環境まで、その高度な機能に特化した書籍や講座が数多く存在します。
一般的な出発点としては、 PowerShellの高度な機能を徹底的に理解することです。これらの機能を使うと、パラメーターの定義、検証の実行、構造化された出力の生成、そしてネイティブのコマンドレットとほぼ同等のレベルでの統合ヘルプへのアクセスが可能になります。そこから、コードをモジュールに整理することで、運用チーム内での共同作業が容易になります。これらのモジュールをバージョン管理し、社内または公開のNuGetベースのリポジトリに公開できるからです。
カスタムオブジェクトやクラスを扱うことも重要であり、従来の直線的なスクリプトよりもはるかにリッチなデータモデルへの道が開かれます。これにより、PowerShellエンジンを活用して、ビジネスロジックをカプセル化し、構造を再利用し、自社の管理チーム向けに内部APIを設計することが可能になります。
高度な自動化の分野では、バックグラウンドジョブとワークフローが重要な役割を果たします。これにより、非同期タスクの管理、コンソールをブロックすることなく長時間の処理を実行、複数のマシンにまたがる複雑なシーケンスのオーケストレーションが可能になります。これらの機能は、WMI/CIMへの一括クエリやリモート管理シナリオに最適です。これらのシナリオでは、システムの変更実装やデータ返却を待つ必要がある場合がよくあります。
もう一つの重要な構成要素は、PowerShell DSC（Desired State Configuration）です。これは、インフラストラクチャの望ましい構成（役割、機能、サービス、ファイル、セキュリティ設定など）を定義し、それらの状態を繰り返し適用できる機能です。WMI/CIM経由で取得した情報と組み合わせることで、逸脱を検出し、事前に修正し、手作業を減らしながら一貫性のある環境を維持できます。
PowerShell を使用したローカル、リモート、およびクラウド管理
ローカルレベルでは、PowerShellはActive Directoryドメインサービスの管理、ネットワークの構成、サーバーの管理を行うためのコマンドレットを提供します。Windows 10以降のバージョンでは、統合がさらに強化され、Webサイトの作成からActive Directoryオブジェクトの管理、ネットワークアダプタの構成まで、あらゆる作業を自動化できます。
あまり知られていないものの非常に便利なコンポーネントとして、PSProvidersとPSDrivesがあります。これらを使用すると、ファイルシステム、レジストリ、Active Directoryなど、さまざまなストレージ場所を、まるでナビゲート可能なドライブであるかのように扱うことができます。これにより、例えば、ハードドライブを操作するのと同じ構文を使用して、リモートコンピュータ上にActive Directoryグループ、レジストリキー、またはフォルダ構造を作成できます。
リモート管理に関して、PowerShellは1台または複数のコンピューターに接続し、ユーザーに代わってコマンドを実行するための強力な機能を統合しています。永続的なPSSessionセッション、高度なリモート処理技術、1対多シナリオ（複数のサーバーを同時に管理する場合）、または特定のケースをデバッグするための1対1シナリオを使用できます。もちろん、これらすべてはリモートアクセスのアーキテクチャとセキュリティモデルを尊重しながら行われます。
クラウドは今日、極めて重要な役割を果たしています。Azure PowerShellとAzure Cloud Shellを使用すれば、仮想マシン、ストレージ、サブスクリプションをコマンドラインから直接管理できます。ハイブリッド環境や完全にAzureでホストされた環境を管理する場合、Azure PowerShellモジュールをインストールして使いこなせるようになることはほぼ必須です。
一方、PowerShellはMicrosoft 365（Exchange Online、SharePoint Online、Teams、ユーザー、ライセンス）の管理ツールとしても広く普及しています。アカウントの作成と管理から、グループ、SharePointサイト、Microsoft TeamsなどのExchange Onlineリソースの管理まで、あらゆる作業をスクリプトで自動化できるため、Webポータルでの手作業を大幅に削減できます。
スクリプト作成、パイプライン構築、および最適な作業方法
WMIとCIMを使った高度な自動化を最大限に活用するには、PowerShellのパイプラインモデルを習得することが不可欠です。他のシェルとは異なり、PowerShellではプレーンテキストではなく、完全なオブジェクトを渡すため、情報の選択、並べ替え、測定、フィルタリング、列挙、変換を非常に高い精度で行うことができます。
パイプラインの操作を習得するには、選択コマンドレットとフィルタリングコマンドレットを正しく使用すること、複雑なオブジェクトを列挙する方法を理解すること、そして情報を失うことなくコマンドとスクリプト間でデータを渡す方法を学ぶ必要があります。これは、より高度なロジックを構築するための一時的なデータ構造として機能する変数、配列、ハッシュテーブルを体系的に使用することで強化されます。
次のステップはスクリプト作成です。コマンドを再利用可能なスクリプトにパッケージ化し、フロー制御（if、for、foreach）を適用したり、CSVファイルなどの形式からデータをインポートしたり、ユーザー入力を処理したり、エラー処理やイベントログを記録したりします。これらすべてによって、個別のコマンドから、より堅牢な組み込みツールへと移行できます。
WMI/CIM を使用した大規模な自動化環境では、トラブルシューティングとエラー処理が特に重要です。ネットワーク障害、権限設定の誤り、クラスの欠落などが適切に管理されないと、プロセスが停止してしまう可能性があるためです。try/catch ブロック、設定可能なエラー処理、詳細なログ記録機能を使用することで、これらの状況を予測し、より効果的に対応できます。
最後に、関数とモジュールに関するすべての要素が、一連のプロセスを完結させます。スクリプトに署名して整合性を確保し、関数をモジュールにパッケージ化し、それらのモジュールを社内または公開リポジトリに配布し、組織内で共有ツールのエコシステムを構築します。こうすることで、WMI、CIM、リモート処理に関するあらゆる新しい開発が、一貫性があり保守しやすいスイートに統合されます。
上記すべて（WMI/CIM、リモートセッション、スクリプト、非同期ジョブ、DSC、Azure、Microsoft 365）を組み合わせることで、PowerShellによる高度な自動化が管理の中核となる環境が実現します。確固たるベストプラクティス、CimSessions（WSManとDCOMの両方）の賢明な活用、そしてモジュール式のスクリプト設計により、グラフィカルウィザードや個別のツールだけに頼る場合よりも、異種混在のインフラストラクチャを、一貫性、セキュリティ、そしてはるかに効率的な方法で管理できます。
