Windows 11のWMICがFoDごと消える、古い運用スクリプトはCIM移行を急ぐ段階に

Microsoftは、Windows 11からWindows Management Instrumentation Command-line、すなわちWMICを外す段階をもう一つ進めた。8月14日付のRelease Preview更新KB5120998では、24H2と25H2にWMICを含めず、機能オンデマンド（Feature on Demand、FoD）としても提供しないとしている。wmic.exeが見当たらない新規インストールを想定するだけでは足りない状態になる。

WMICは以前から非推奨だった。しかし、必要になればFoDで戻せた期間と、戻せない今回とでは、運用上の意味が違う。バッチファイルや監視設定に実行ファイル名が残っていれば、警告ではなく依存関係の破断として表面化する。一般提供の時期は未公表だが、管理者とソフトウェア提供者は、配信前に何を置き換えるかを決めておく必要がある。

KB5120998で「再追加」の逃げ道が閉じる

対象はWindows 11 Release Preview ChannelのBuild 26100.9267（24H2）とBuild 26200.9267（25H2）である。Microsoftのリリースノートは、2026年8月から両バージョンにWMICが含まれなくなり、FoDも利用できなくなると記す。これは現時点で広く一般提供された更新だと確認されたわけではない。リリースノートは段階的なロールアウトと通常のロールアウトを説明する一方、全利用者へ届く日付は示していない。

それでも範囲は狭くない。24H2と25H2はこのRelease Preview更新を共有しており、将来の25H2への機能更新を避ければ済む話ではない。24H2を保守中の端末も対象に入る。社内でRelease Previewを先行適用する組織は、一般配信前の確認材料として使えるが、本番環境へ一律に展開済みと扱うべきではない。

今回消えるFoDは、古い手順で利用されたWMIC~~~~である。以前のドキュメントにはWindows 11 22H2以降の機能として載り、24H2では事前インストールされないことも説明されていた。だが、KB5120998の状態に到達した後、その記載を手掛かりに再インストールする回避策を案内するのは誤りになる。

2021年から続いた段階的な撤去

Microsoftがクライアント版WindowsでWMICを非推奨としたのは2021年である。非推奨は新しい開発を行わず、将来の削除を知らせる区分だった。直後に既存の運用が動かなくなったわけではない。

その後の変化を追うと、今回の更新がどこを切り替えるのかが分かる。

時期	Windows側の状態	管理者が取れた選択
2021年	WMICを非推奨化	既存の呼び出しを残しつつ移行を準備できた
2022年、Windows 11 22H2	FoDとして事前インストール・有効化	必要な端末では従来のコマンドを使えた
2024年、23H2／24H2	既定で無効、または事前インストールなし	FoDを追加して戻せた
2025年、25H2へのアップグレード	インストール済みWMICを削除	FoDによる再追加は可能だった
2026年8月のRelease Preview	WMICを含まず、FoDも提供しない	代替経路へ移る必要がある

以前の既定変更では、端末イメージや手順書にFoDの追加を組み込めば当面はしのげた。今回はその選択肢がなくなる。wmicを呼び出す.batや.cmdに加え、PowerShellからwmic.exeを起動する.ps1も調査対象になる。ログオンスクリプトやスケジュールされたタスク、展開パッケージにも文字列としての呼び出しが残り得る。資産管理・監視エージェントと運用文書も、障害時には同じ依存関係になる。

消えるのはwmic.exe、WMIは残る

削除対象はWMICというコマンドラインのラッパーであり、Windows Management Instrumentation（WMI）の基盤やサービスそのものではない。ここを混同すると、移行範囲を必要以上に大きく見積もる。MicrosoftはWMIをPowerShellのコマンドレット、.NETのSystem.Management、COM API、ほかの言語から引き続き利用できるとしている。

WMICは、WMIクラスへの問い合わせをコマンドの文字列と整形済みのテキストで扱う入口だった。例えばMicrosoftが示す移行例では、wmic path win32_process get NameはGet-CimInstance Win32_Process | Select-Object Nameへ置き換える。前者は実行結果の列を表示するのに対し、後者はCimInstanceオブジェクトをパイプラインへ渡す。ここが、見た目以上に大きな差になる。

既存のWQL（WMI Query Language）も捨てる必要はない。PowerShellのドキュメントは、Get-WmiObjectで使えるWQLクエリをGet-CimInstance -Queryでも使えると説明する。ただし、WMI cmdletはすでに非推奨で、PowerShell 6以降には含まれない。PowerShell 7系の相違点一覧にもGet-WmiObjectなどWMI v1のcmdletは削除済みとある。新しい処理はCIM cmdletを基準に設計するのが自然である。

移行はコマンド名より出力契約を直す

wmicをGet-CimInstanceへ機械的に置き換えても、すべての自動化がそのまま動くわけではない。WMICの出力を空白で分割したり、列見出しを探したり、ローカライズされた表示文字列を比較したりするスクリプトは、オブジェクトを返すPowerShellの書き方へ組み替える必要がある。この違いはMicrosoftの移行例とCIM cmdletの返り値から導ける実装上の注意点である。

置換したコマンドが成功した後も確認は続く。プロセスの終了コードとエラー時の分岐を、呼び出し元と一緒に確かめるべきである。必要なプロパティが揃うか、空の結果をどう扱うかも試す。例えばプロセス名だけが必要ならSelect-Object Nameで明示する。元のスクリプトがテキスト表を後続のツールへ渡していたなら、その受け渡し形式も新たに定義し直す必要がある。

リモート問い合わせはさらに条件が増える。Get-CimInstanceは既定でWSManを使う。Microsoftは別資格情報で接続するためのCimSessionと、古いシステム向けにDCOMを使うNew-CimSessionOptionの例を示している。認証情報、利用する転送方式、ファイアウォールの通過条件、返るオブジェクトの形を同じテストで確かめなければ、端末上の単発テストだけでは移行完了と言えない。

一般配信前に洗い出すべき依存関係

最初に、リポジトリと展開用スクリプトからwmicとwmic.exeの呼び出しを探す。タスク定義と運用手順も同じように調べる。ヒットした箇所は、対話用の手順と自動実行を分けて扱う。前者はCIMコマンドへ書き換えた説明を用意し、後者は実行アカウントと対象端末の組み合わせで試験する。

次に、問い合わせの目的を分類する。Win32_Processのようなクラスから値を取るだけなら、Get-CimInstanceと明示的なプロパティ選択で置き換えやすい。一方、BIOS情報をWin32_BIOSから得る処理でも、後段がテキストの並びに依存していれば、同じ値が取れたことだけでは不足する。結果を利用する監視製品や配布ツールの仕様も確認しなければならない。

Microsoftは、WMICに依存するアプリケーションとスクリプトに加え、自動展開や監視への影響を警告している。ツールと運用文書も更新対象だ。一般提供日が決まるのを待つのではなく、Release Previewの端末で代替処理を実行し、戻り値、権限、リモート接続まで通ることを確認できた時点で、WMICなしの運用へ移せる。