Microsoftは2026年9月10日、Windowsのライセンス認証を自動化してきた企業に対し、slmgr.vbsへの依存をPowerShellの新モジュールOSLicenseへ移すよう案内した。VBScriptは現在も追加機能として既定で有効だが、Microsoftは将来これをWindowsから完全に削除する計画で、その時点ではslmgr.vbsを予備経路として使えなくなる。もっとも、消えるのはVBScriptで書かれた管理ツールであり、Windowsの認証基盤そのものではない。移行の成否を左右するのは三つのコマンド名の置換より、端末ごとの提供状態と既存自動化が前提にしてきた出力、権限、実行経路を検証できるかどうかだ。
VBScript廃止で止まるのは、認証を呼び出す管理経路
slmgr.vbsはWindows Script Host上で動き、Software Licensing Serviceを操作する管理スクリプトだ。オンライン認証やプロダクトキーの導入に加え、KMS、Active Directoryベース認証、オフライン認証など広い操作面を持つ。したがってVBScriptエンジンがなくなると、このファイルをcscript.exeやwscript.exeから呼ぶ処理は動かない。
一方、ライセンスサービスまでVBScriptで実装されているわけではない。Windows Server vNextのプレビュー利用者がVBScriptを外した仮想マシンでslmgr.vbsを実行すると「スクリプトエンジンが見つからない」という趣旨のエラーになったが、設定アプリからの認証には成功した。Microsoft社員も同社コミュニティーで、設定アプリの認証はVBScriptに依存しないと説明している。これは特定のプレビュー環境での報告であり、あらゆる構成の動作保証ではないものの、管理入口と認証基盤を分けて考える根拠になる。
企業で影響を受けるのは、slmgr.vbsを直接たたくバッチだけとは限らない。OS展開用のタスクシーケンスや端末管理製品、グループポリシーから間接的に呼び出していれば、担当者がスクリプトの存在を意識しないまま依存が残っている可能性がある。Microsoftが早めの棚卸しを求めるのは、この隠れた呼び出しを完全削除前に見つけるためだ。
OSLicenseで変わる、認証操作と結果の受け取り方
OSLicenseはWindows PowerShell 5.1を要件とし、公開された一覧にはGet系4、Invoke系4、Set系3の計11 cmdletが並ぶ。対象はOSのライセンスに加え、Active Directoryベース認証、KMS、サブスクリプションライセンスに分かれる。従来の一つのVBScriptへ多数のスイッチを渡す形から、照会、操作、設定の役割ごとにPowerShellコマンドを使い分ける形へ変わる。
Microsoftが示した代表的な対応は次の三つだ。
| 既存の呼び出し | OSLicenseの例 | 主な目的 |
|---|---|---|
slmgr.vbs /ato |
Invoke-OSLicense -ActivateOnline |
オンライン認証 |
slmgr.vbs /ipk <key> |
Invoke-OSLicense -InstallProductKey <key> |
プロダクトキー導入 |
slmgr.vbs /dlv |
Get-OSLicenseInfo |
詳細なライセンス情報の取得 |
この表はMicrosoftの移行ブログが「よく使われる三つの作業」に示した対応で、全スイッチの一対一互換表ではない。コマンドと引数も公開時点の参照文書で確かめるよう明記されている。
技術上の利点は、結果を文字列から構造化データへ変えられる点にある。Get-OSLicenseInfoはローカルのSoftware Licensing用CIMクラスを照会し、ライセンス状態、猶予期間、KMS設定などをPowerShellオブジェクトとして返す。表示言語に左右される文字列の切り出しから、プロパティを指定する処理へ移せる。ただし、既存の監視がslmgr.vbsの標準出力や終了コードを条件分岐に使っていれば、新しい出力を受け取る側も書き換えなければならない。
移行先は用意されたが、提供条件はまだ一本化されていない
Windows 11についてMicrosoftのブログは、2026年8月27日公開のKB5120998 Preview以降をOSLicenseの前提としている。対象はWindows 11 24H2と25H2で、同更新のOSビルドはそれぞれ26100.9278と26200.9278だ。ただしKB5120998はプレビュー更新として段階的に配信されたため、対象版を使っているだけで全端末に同じ時点で届いたとは判断できない。
2026年9月14日時点で、MicrosoftのWindows IT Pro BlogはWindows 11の前提をKB5120998以降と明示する一方、OSLicenseモジュールの参照ページは適用KBを「要確認」と記しており、公式文書間で提供条件の記述が揃っていない。
| Microsoftの公開ページ | 取得時点の記載 |
|---|---|
| Windows IT Pro Blog（9月10日付） | Windows 11はKB5120998 Preview以降 |
| OSLicenseモジュール参照 | 利用可能になるWindows UpdateのKB番号は要確認 |
これは2026年9月14日に両ページのWindows 11向け前提条件を照合した結果である。KB5120998の変更一覧にもOSLicenseという名称は見当たらないが、モジュールが同更新に含まれないことを示す証拠にはならない。文書の更新が追いついていない可能性もある。移行担当者はKBの表記だけを信頼せず、対象端末でGet-Module -ListAvailable OSLicenseなどを用いてモジュールの実在を確認する必要がある。
Windows Serverはさらに段階が早い。Microsoftは一般提供を「次のメジャー版」に予定し、早期検証先としてWindows Server vNext Preview Build 29651以降を挙げた。次期版の正式名称と提供日は示しておらず、Windows Server 2025へのバックポートも確認できない。現行サーバー群へ一斉に移行できるという発表ではない。
三つのコマンド対応から、既存の自動化全体を検証する
コマンド置換の前に、実際に使っているslmgr.vbsのスイッチを洗い出す必要がある。公式文書にはKMSホストの探索やキャッシュ、Active Directoryベース認証、トークン認証、オフライン認証、rearmまで多数の操作が載る。三つの代表例だけを置き換えても、企業固有の運用を覆えるとは限らない。
次に確かめるのは実行時の契約だ。Microsoftは、コマンドと引数、必要な権限、出力の解析方法を検証項目に挙げ、リモート実行とログの取り方も見直すよう求めている。OSLicenseの各cmdletはローカルコンピューターへの操作として文書化されるため、slmgr.vbsでリモートコンピューター名を渡していた処理を、そのまま移植できる保証はない。PowerShell Remotingや端末管理製品からの配布を使うなら、その経路を含めて試すことになる。
状態変更にも固有の注意がある。Invoke-OSLicenseは一度に一つの操作を選ぶ設計で、操作を指定しなければ出力せず、何も変更しない。Set-KmsLicenseInfoは指定したKMS設定だけを変更するが、管理者権限で起動したPowerShellを必要とする。一部の整数値はPowerShell側ではなくライセンスサービスが妥当性を判定するため、例外の有無だけで成功とせず、戻り値と変更後の状態まで確認する方が安全だ。
移行試験は、代表的な端末群でオンライン認証、キー導入、状態照会を通し、使っている場合はKMSやオフライン認証も加える。さらに、成功と失敗のログが既存の監視へ届くか、再実行時に想定外の状態変更を起こさないかを確かめる。そこで初めて、古い呼び出しを段階的に外せる。
2027年前後は既定無効化の目安、完全削除日は未定
Microsoftの廃止計画は三段階に分かれる。現在のPhase 1ではVBScriptがFeature on Demandとして既定で有効だ。Phase 2はおおむね2027年に既定無効へ移し、必要な利用者が明示的に有効化する形になる。Phase 3では将来のWindowsから機能自体を削除するが、その日付は決まっていない。
したがって、2027年をslmgr.vbsの完全停止日と読むのは正確ではない。ただ、既定無効化が始まれば、見落としていた依存は新しい端末や更新済み環境で表面化しやすくなる。完全削除後にはVBScriptを有効に戻す逃げ道も、slmgr.vbsを予備系に残す選択肢もなくなる。
利用組織が今確認できるのは、どの自動化がVBScriptを呼び、対象OSにOSLicenseが届き、同じ業務結果を新しい出力と権限で再現できるかだ。Phase 3の日付を待つのではなく、2027年前後の既定無効化までにこの三点を検証できれば、Windows認証の運用をVBScriptの寿命から切り離せる。