【実務・中級編】【レガシー刷新】VBScript から PowerShell への移行ガイド：既存WSH資産の移植手法とオブジェクト対応表 – VBScript (Visual Basic Scripting Edition)解析バイブル

VBScript (Visual Basic Scripting Edition)

2026.08.24

【レガシー刷新】VBScript から PowerShell への移行ガイド：既存WSH資産の移植手法とオブジェクト対応表

開発現場の片隅で、今なおひっそりと稼働し続けるVBScript。Windowsの標準機能として長年愛されてきたものの、現代のインフラ環境やセキュリティ基準においては、もはや「技術的負債の塊」と言わざるを得ません。

こんにちは。チーフアーキテクトの私だ。
「動いているから触るな」と放置された`.vbs`ファイル群が、ある日突然のOSアップデートやセキュリティポリシーの強化によってシステムを停止させる――そんな悪夢を、私は幾度となく目撃してきた。

VBScriptの非推奨化（Deprecated）は既定路線だ。いつまでもレガシーにしがみつくのは、自らシステムの寿命を縮めているようなもの。今こそ、PowerShellへの移行（モダナイゼーション）を断行すべき時だ。

今回は、長年VBScriptで構築されてきたWSH（Windows Script Host）資産を、安全かつスマートにPowerShellへ移植するための極意を、ロジカルかつシャープに伝授しよう。

—

なぜVBScriptのままではいけないのか？

「VBScriptはシンプルで手軽だ」という神話は捨てなければならない。
最大の問題は、「モダンなエラーハンドリングの欠如」「非同期処理の困難さ」、そして「セキュリティ上の脆弱性（COMオブジェクトの無差別な生成）」にある。

VBScriptの `On Error Resume Next` に依存したコードは、エラーを握りつぶし、潜在的なバグを隠蔽する最悪のアンチパターンだ。プロセスの生存確認、詳細な例外キャッチ、そしてリモート実行への耐性を考慮するならば、PowerShellへの移行は必然の選択となる。

—

WSHオブジェクトとPowerShellコマンドレットの完全対応表

VBScriptからPowerShellへの移行における最大の難所は、「使い慣れたCOMオブジェクトやWSHメソッドの置き換え先を知る」ことだ。
以下の対応表を頭に叩き込んでほしい。これだけで移行作業の8割は完了したも同然だ。

—

移行の実践：レガシーなファイル処理スクリプトの刷新

百聞は一見に如かず。実務でよくある「ログファイルを読み込み、条件に合致する行を別ファイルに出力する」というバッチ処理を例に、VBScriptとPowerShellの書き方の違い、そして「なぜPowerShellの書き方が優れているのか」を比較しよう。

【旧世代】VBScriptによる実装（アンチパターン）

‘ =====================================================================
‘ レガシーVBScript版：エラーハンドリングが脆弱でメモリ効率も悪い
‘ =====================================================================
Option Explicit

Dim fso, tsIn, tsOut, line
Set fso = CreateObject(“Scripting.FileSystemObject”)

‘ エラー対策のつもりで仕掛けられた罠（バグの温床）
On Error Resume Next

Set tsIn = fso.OpenTextFile(“C:\Logs\app.log”, 1) ‘ 読み込み
If Err.Number <> 0 Then
WScript.Echo “ファイルを開けませんでした: ” & Err.Description
WScript.Quit 1
End If

Set tsOut = fso.CreateTextFile(“C:\Logs\error_filtered.log”, True)

Do Until tsIn.AtEndOfStream
line = tsIn.ReadLine
‘ “ERROR”が含まれる行だけを抽出
If InStr(line, “ERROR”) > 0 Then
tsOut.WriteLine line
End If
Loop

tsIn.Close
tsOut.Close
Set tsOut = Nothing
Set tsIn = Nothing
Set fso = Nothing

WScript.Echo “処理完了”

このコードのどこがダメか？

`On Error Resume Next` のせいで、予期せぬI/Oエラーが起きても処理が続行（あるいは中途半端に終了）する。
オブジェクトの解放漏れ（メモリリーク）が起きやすい。
全行をループで回すため、巨大なログファイルに対して極めて非効率。

—

【新世代】PowerShellによるプロダクションコード

同じ処理を、PowerShellのパイプラインと強固なエラーハンドリング（`try-catch`）を用いて実装する。

<# .SYNOPSIS ログファイルからエラー行を抽出するモダンなPowerShellスクリプト .DESCRIPTION FSOを使わず、PowerShellのネイティブコマンドレットとストリーム処理により高速かつ堅牢にログをフィルタリングします。 .NOTES Author: Chief Architect Requirement: PowerShell 5.1 or higher / PowerShell 7+ >

厳格なエラーモードの有効化（スクリプト内の予期せぬエラーで即停止）
Set-StrictMode -Version Latest
$ErrorActionPreference = “Stop”

$InputPath = “C:\Logs\app.log”
$OutputPath = “C:\Logs\error_filtered.log”

try {
Write-Host “ログのフィルタリング処理を開始します…” -ForegroundColor Cyan

# 入力ファイルの存在確認（VBScriptのようにErrオブジェクトに頼らない）
if (-not (Test-Path -Path $InputPath)) {
throw “入力ファイルが見つかりません: $InputPath”
}

# パイプラインとGet-Contentの組み合わせによる高速処理
# -ReadCount を用いることで大容量ファイルでもメモリを圧迫しない
Get-Content -Path $InputPath -ReadCount 1000 | ForEach-Object {
# $_ は現在のオブジェクト（行の塊）を示す
$_ | Where-Object { $_ -match “ERROR” }
} | Set-Content -Path $OutputPath -Encoding UTF8

Write-Host “処理が正常に完了しました。出力先: $OutputPath” -ForegroundColor Green
}
catch [System.IO.IOException] {
Write-Error “ファイルI/Oエラーが発生しました: $_”
exit 1
}
catch {
Write-Error “予期せぬエラーが発生しました: $_”
exit 1
}

プロのアーキテクトが仕込んだ設計ポイント：
1. `$ErrorActionPreference = “Stop”`: VBScriptの悪しき習慣であるエラー無視を根絶し、問題が発生した瞬間に安全にスクリプトを異常終了させる。
2. `Test-Path` による事前検証: ファイルが存在しないリスクを事前にスマートに排除。
3. 適切な例外キャッチ (`try-catch`): IOExceptionなどを明確にキャッチし、デバッグを容易にしている。

—

移行プロジェクトを成功させるための実践的ステップ

一気にすべてのVBScriptを書き換える必要はない。現場の混乱を避けるための段階的移行（ストラングラー・フィグ・パターン）を推奨する。

1. インベントリの作成: 社内で稼働している`.vbs`ファイルを洗い出し、「頻度」「重要度」「依存関係」でマッピングする。
2. 影響度の低いものからPoC（概念実証）: 定期的なログ削除や、単発のファイル移動といった非クリティカルなスクリプトからPowerShell（`.ps1`）へ書き換える。
3. 実行権限（ExecutionPolicy）のクリア: 組織のグループポリシー（GPO）等でPowerShellのスクリプト実行が制限されている場合があるため、インフラ部門と事前に調整しておく。
4. タスクスケジューラの移行: `wscript.exe “C:\path\script.vbs”` で登録されているタスクを、`powershell.exe -NoProfile -ExecutionPolicy Bypass -File “C:\path\script.ps1″` へ置き換える。

—

結びに代えて

VBScriptは過去の遺物だ。いつまでもレガシーな技術にしがみついていると、インフラの進化に取り残されるだけでなく、セキュリティインシデントの温床となる。

PowerShellへの移行は、単なる「言語の置き換え」ではない。それは、あなたのシステムの信頼性をモダンな水準へと引き上げる、極めて重要なエンジニアリング投資である。
この記事を読んだ今この瞬間から、あなたのプロジェクトのレガシー刷新をスタートさせてほしい。