VBScriptを掌握する：WMIから紐解くOS稼働時間の「正確な」算出ロジック
業務自動化の現場において、サーバーや端末の死活監視・メンテナンス管理は避けて通れないタスクだ。しかし、多くのエンジニアが「なんとなく」ネットの断片的なコードを拾い、変換エラーやロケール依存のバグに泣かされているのを目にする。
VBScriptは枯れた言語だが、だからこそ「OSの深淵（WMI）」をいかに安全に叩くかが、一流のアーキテクトと素人の分かれ道となる。今回は、`Win32_OperatingSystem` を用いたOS稼働時間算出の、決定版とも言える実装を伝授する。
—
1. なぜ「CIM_DATETIME」の変換でつまづくのか
WMIが返す `LastBootUpTime` は、標準的なDate型ではない。`20231027103000.000000+540` のような特殊な形式（CIM_DATETIME）だ。
ここを `CDate()` でキャストしようとするのは愚策だ。環境のロケール設定に依存し、日付の順序が入れ替わったり、変換エラーでスクリプトが停止するリスクが高い。「外部環境に依存しない堅牢な解析関数」を自前で持つこと。 これがプロの鉄則である。
—
2. 堅牢な稼働時間算出ロジック（プロダクションコード）
以下のコードは、エラーハンドリングを最小限に抑えつつ、解析ロジックを独立させた「コピペで即戦力」のテンプレートだ。
‘ — 稼働時間算出スクリプト —
Option Explicit
Dim objWMIService, colOS, objOS
Dim strBootTime, dtBootTime, dtNow, diffSeconds
‘ WMI接続：エラーハンドリングの定石
Set objWMIService = GetObject(“winmgmts:\\.\root\cimv2”)
Set colOS = objWMIService.ExecQuery(“Select LastBootUpTime From Win32_OperatingSystem”)
For Each objOS In colOS
strBootTime = objOS.LastBootUpTime
‘ CIM_DATETIMEをVBScript Date型へ変換
dtBootTime = WMIDateToDate(strBootTime)
dtNow = Now()
‘ 秒単位での差分算出
diffSeconds = DateDiff(“s”, dtBootTime, dtNow)
WScript.Echo “最終起動日時: ” & dtBootTime
WScript.Echo “連続稼働時間: ” & FormatUptime(diffSeconds)
Next
‘ WMIの日付文字列をDate型へ変換する関数
Function WMIDateToDate(wmiDate)
Dim strDate
‘ YYYYMMDDHHMMSS の形式をスライスして結合
strDate = Mid(wmiDate, 1, 4) & “/” & Mid(wmiDate, 5, 2) & “/” & Mid(wmiDate, 7, 2) & ” ” & _
Mid(wmiDate, 9, 2) & “:” & Mid(wmiDate, 11, 2) & “:” & Mid(wmiDate, 13, 2)
WMIDateToDate = CDate(strDate)
End Function
‘ 経過秒数を読みやすい文字列に変換
Function FormatUptime(seconds)
Dim d, h, m, s
d = seconds \ 86400
h = (seconds Mod 86400) \ 3600
m = (seconds Mod 3600) \ 60
s = seconds Mod 60
FormatUptime = d & “日 ” & h & “時間 ” & m & “分 ” & s & “秒”
End Function
—
3. 実務で「生き残る」ための設計指針
1. リソースの解放を怠るな
VBScriptはガベージコレクションが強力とは言えない。特にWMIオブジェクトをループ内で扱う場合、`Set obj = Nothing` を明示的に呼び出すクセをつけろ。メモリリークは、数ヶ月連続稼働する自動化タスクでは致命的なバグとなる。
2. 外部連携（DB/ファイル）の罠
取得した稼働時間をログファイルに書き出す際、時刻のタイムゾーンには細心の注意を払え。`LastBootUpTime` はUTCベースで返されることもある（特にクラウド環境）。必要に応じて `WScript.Shell` から `tzutil /g` を叩くか、環境のオフセット値を補正するロジックを組み込むのが、「真に信頼できる」システムを作る技術だ。
3. 保守性への投資
上記の `WMIDateToDate` のように、ロジックを関数化して切り出すことは、単なるコードの整理ではない。「テスト可能にする」ための構造化だ。将来的にPowerShellへ移行する際にも、この関数単位のロジックは資産としてそのまま移植できる。
—
結論：コードは「書く」のではなく「守る」もの
自動化ツールは、書いたその瞬間からメンテナンスが始まる。環境に依存する関数を避け、文字列操作による地道な変換を行い、計算結果を抽象化する。このアプローチこそが、何年経ってもバグを出さない「伝説的なスクリプト」の作り方だ。
さあ、このコードをベースに、君の現場の監視システムを一段上のレベルへ引き上げてほしい。健闘を祈る。
