2027年に予定されているVBScript（VBS）の完全廃止。まだ先のことと感じられるかもしれませんが、MECMやIntune環境で長年VBSを活用して自動化を行ってきた企業様にとっては、避けては通れない課題です。

本記事では、実際に弊社が手掛けたVBSからPowerShellへの移行事例をもとに、移行のステップや具体的な作業内容について詳しく解説します。

VBSの廃止とPowerShellへの移行

Windows 11 24H2より、VBScriptは「オンデマンド機能」へとフェーズが変わりました。これにより、2027年頃にはOSから完全に廃止される予定です。

ここで注意が必要なのは、オンデマンド機能化＝「標準状態では利用できず、個別にインストールが必要な状態」を指す点です。今後、新規端末の導入やOSアップデートのタイミングで、既存のVBSスクリプトが突然動かなくなるリスクを孕んでいます。

弊社でも先日、お客様より「MECMで配信しているパッケージがVBSで作られているため、将来を見据えてPowerShellへ刷新したい」とのご依頼をいただき、移行プロジェクトを実施いたしました。

移行の工程

VBSとPowerShellは設計思想や構文が根本的に異なります。単純なコードの書き換えだけでは、思わぬ不具合を招く可能性があるため、以下の4つの工程を経て慎重に進めます。

1. 既存のVBSの解析

まずは現行のVBSが「何を行っているのか」を可視化します。

• 処理の目的（例：アプリのサイレントインストール、設定変更）
• 実行順序と依存関係
• 条件分岐のロジック（OSバージョン、ファイル存在確認など）

解析結果は「処理仕様一覧」としてExcel等にまとめ、後のコーディングやテストで活用します。

2. PowerShellによる実装

解析したロジックを、PowerShellの作法に則って書き直します。

• ファイル・フォルダ操作、レジストリ操作の置換
• 詳細なエラーハンドリング（Try-Catch）の実装
• MECM/Intune環境特有の「SYSTEMコンテキスト」での動作を考慮したコード設計

3. ローカル環境での実行テスト

スクリプト単体での動作確認です。パッケージ作成担当者は、ローカルPC上でインストールとアンインストールを繰り返し、期待通りの挙動になるかを検証します。

管理者権限での実行や、コマンドライン引数の受け渡しが正しく機能するか、この段階で徹底的に洗い出します。

4. MECM/Intuneでの配信検証

最終段階として、実際の管理コンソールからクライアントPCへ配信テストを行います。

• 実行コンテキスト（ユーザー権限か、システム権限か）
• 実行タイミング（ログオン時、アイドル時など）
• 終了コードの制御（再起動が必要な場合のコード返却など）

「ローカルでは動くが、MECM経由だと動かない」というケースは多々あるため、この実機検証が最も重要です。

VBSからPowerShellへ書き換える際のポイント

VBSのコードをPowerShellに移植する際、単にコマンドを置き換えるだけでは不十分です。MECM/Intuneでの運用を見据えた、実装のコツと注意点を解説します。

1. 初期設定・共通処理：エラーハンドリングの刷新

VBSでは 「On Error Resume Next」 でエラーを無視する書き方が多用されていましたが、PowerShellでは「Try-Catch」による例外処理が基本です。

例外処理

スクリプト全体を

Try { ... } Catch { ... }

で囲み、予期せぬエラーが発生した際も必ずログを残して終了（Exit 1など）するように設計します。

ログ出力

VBSの FileSystemObject による書き込みは、PowerShellの 「Out-File -Append」 や 「Add-Content」 で簡潔に記述できます。タイムスタンプ付与用の共通関数を作っておくと便利です。

2. メッセージ表示：HTAからの脱却

VBS時代、リッチな画面表示によく使われていた「HTA（HTML Application）」は、Internet Explorerコンポーネントに依存しているため、今後のWindows 11環境では動作が不安定になるリスクがあります。

メッセージの表示

実行中メッセージを表示し続ける場合は、PowerShellから.NETの 「Windows.Forms」 を呼び出すか、トースト通知を活用する手法に切り替えます。

メッセージを閉じる

処理終了時にHTAを閉じていた処理は、PowerShellの 「Stop-Process」 で対象のウィンドウプロセスを確実に終了させる制御へと変更します。

3. 前提条件チェック：型定義の活用

バージョン比較やファイルの有無確認は、PowerShellの強みが最も活きる部分です。

バージョンの比較

ファイルバージョンの比較は、VBSのような文字列比較ではなく、PowerShellの [version] 型を使用します。

if ([version]$current -lt [version]"2.0") { ... }

このように記述することで、”10.0″ が “2.0” より小さいと判定されるような「文字列比較特有のミス」を防げます。

4. 実行ロジック：SYSTEM権限

MECMやIntuneで配信する場合、スクリプトは「SYSTEM権限」で動作します。ここがローカルテストで最もハマりやすいポイントです。

新しいプロセスの開始

VBSの WshShell.Run は、PowerShellでは Start-Process に置き換えます。その際、必ず -Wait パラメータを使い、インストーラーが終了するまでスクリプトが先に進まないように制御します。

PowerShellの Start-Process が推奨されるのは、SYSTEM権限下での挙動を細かく制御できるためです。

終了コード

$process = Start-Process ... -PassThru

のように -PassThru を使用してプロセスオブジェクトを取得し、

$process.ExitCode

で戻り値を判定するのが鉄則です。

5. 処理結果返却

スクリプトが正常に終わったかどうかを、エンドポイント管理側に正しく伝える必要があります。

スクリプトの最後には必ず

Exit $LastExitCode

を記述します。

成功なら 0、再起動が必要なら 3010 など、MECMが理解できる標準的なリターンコードを返すよう設計することで、配信ステータスの管理が正確になります。

6. 設定値の管理：ハードコードを避ける

VBSではスクリプト内に直接値を書き込むこと（ハードコード）が多かったのですが、PowerShellでは必要に応じてスクリプト引数「Param」を活用しましょう。

param([string]$PackageName = "MyApp")

のように引数として定義しておけば、スクリプト本体を書き換えずにコマンドライン引数で動作を変更できるため、再利用性が大幅に高まります。

（まとめ）移行チェックリスト

• On Error Resume Next を Try-Catch に置き換えたか？
• HTA/IE依存のGUIを.NET/WPFに置き換えたか？
• [version] 型を使ってバージョン比較をしているか？
• Start-Process -Wait でインストーラーの終了を待機させているか？
• 適切な Exit Code を返しているか？

最後に

VBScriptの完全廃止は2027年ですが、すでにWindows 11環境では「動かなくなる前兆」が始まっています。直前になって慌てて移行するのではなく、PCの入れ替えやOS更新のタイミングに合わせて、計画的にPowerShellへ移行することをお勧めします。

弊社では、長年培ったエンドポイント管理のノウハウを活かし、既存VBSの解析からPowerShell化、そしてMECM/Intuneでの配信検証までをワンストップでサポートいたします。

「自社にVBSのコードが読み解ける人がいない」「移行作業のリソースが足りない」といったお悩みがありましたら、ぜひお気軽にご相談ください。