【メモリ消費自律監視】WMI Win32_Process 経由で自身のメモリ使用量を監視し閾値超えで安全停止する自己防衛機構
レガシーシステムの深部、あるいはタスクスケジューラで深夜に稼働するバッチ処理の群れ。そこで静かに、しかし確実にシステムリソースを蝕む元凶がある。VBScriptにおけるメモリリーク、そしてVariant型の野放図な肥大化だ。
現代のモダンなランタイムであればガーベッジコレクションが慈悲深く回収してくれる領域も、WSH（Windows Script Host）のプリミティブな世界では、開発者が自ら生死を管理しなければ容赦なくOSを窒息させる。
今回は、数々の現場を修羅場から救ってきたチーフアーキテクトの視点から、「暴走する自プロセスをWMI経由で監視し、閾値を超えた瞬間に自ら優雅に幕を下ろす（セルフ・サフィシエント・ガード）」ための極限の知見を授けよう。
—
1. なぜVBScriptバッチはメモリを喰らい続けるのか
VBScriptの根底にあるCOM（Component Object Model）とオートメーションの仕組みは、強力であると同時にメモリ管理において極めて厄介な特性を持っている。
- 循環参照のトラップ: 2つのオブジェクトがお互いを参照し合った瞬間、VBScriptの参照カウンタ方式ではメモリが永遠に解放されない。
- WMIクエリの残骸: `GetObject(“winmgmts:”)` をループ内で安易に呼び出すと、プロバイダホスト（WMI）側も含めてメモリリークの温床となる。
- 文字列の連結地獄: 大規模なCSVやログを `str = str & line` で結合し続けると、メモリ上に幾何級数的なコピーが発生し、ワーキングセットが一気に膨れ上がる。
「エラーが出たら止まる」ではなく、「メモリを圧迫し始める前に、自ら安全にクリーンアップして身を引く」。これが、24時間365日止まれないインフラを支えるエンジニアの美学だ。
—
2. アーキテクチャの全体像
今回の自己防衛機構の心臓部は以下の通りだ。
1. 自PIDの特定: WMIまたは`WScript.Shell`のプロセス情報から、「いま実行されている自分自身のプロセスID（PID）」を取得する。
2. ワーキングセットの定期観測: `Win32_Process` クラスから `WorkingSetSize`（物理メモリ使用量）を定期的にポーリングする。
3. 安全停止シグナル: 閾値（例: 100MB）を超過した場合、メイン処理を強制中断し、開いているファイルやCOMオブジェクトをすべて解放して `WScript.Quit` する。
—
3. 実装コード：自己防衛機能付きテンプレート
以下のコードは、そのままプロダクション環境に投入可能な堅牢性を持たせたVBScriptの骨組みである。エラーハンドリングとオブジェクトの即時解放を徹底している。
‘ ==============================================================================
‘ Script Name: SelfHealingBatch.vbs
‘ Description: WMIを用いた自プロセスのメモリ自律監視・安全停止メカニズム
‘ ==============================================================================
Option Explicit
‘ — 定数定義 —
Const THRESHOLD_MB = 100 ‘ メモリ閾値 (MB)
Const CHECK_INTERVAL = 1000 ‘ 何回処理を回ごとにメモリチェックを行うか
Const BYTES_IN_MB = 1048576 ‘ 1MB = 1024 1024 bytes
Sub Main()
Dim counter
counter = 0
WScript.Echo “=== バッチ処理開始 (PID: ” & GetMyProcessID() & “) ===”
‘ メインの処理ループ（ここでは模擬的に大量処理を想定）
Do While True
‘ ——————————————————————
‘ ここに本来の業務ロジック（ファイル処理、DB連携など）を記述
‘ ——————————————————————
‘ 一定回数ごとにメモリ監視を実行（WMI呼び出しのオーバーヘッドを抑制）
counter = counter + 1
If counter >= CHECK_INTERVAL Then
If CheckMemoryAndGuard() Then
Exit Do ‘ 閾値超えにより安全停止
End If
counter = 0
End If
‘ 負荷テスト用のダミーウェイト（必要に応じて削除）
WScript.Sleep 10
‘ 無限ループ脱出条件（サンプル用）
If counter > 50000 Then Exit Do
Loop
WScript.Echo “=== バッチ処理は正常に終了しました ===”
End Sub
‘ ——————————————————————
‘ 自プロセスのPIDを取得する関数
‘ ——————————————————————
Function GetMyProcessID()
Dim shell, exec, pid
Set shell = CreateObject(“WScript.Shell”)
‘ WMICコマンドまたはタスクリストから自プロセスの情報を引くのは重いため、
‘ 環境変数やWMI経由で自プロセスのHandleを取得するアプローチをとる
‘ ここではWMIのWin32_Processから親プロセスまたはCommandLineで特定する手法もあるが、
‘ 簡易かつ確実な方法としてWMIのProcessIdクエリを使用する
Dim objWMIService, colProcesses, objProcess
Dim strComputer, wmiQuery
strComputer = “.”
Set objWMIService = GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)
‘ VBScript自身を実行しているcscript/wscriptのプロセスを特定するのは困難を伴うため、
‘ WMIのProcessクラスから絞り込むか、COMオブジェクトのExecutionContextを利用する。
‘ 実務では、起動時にWScript.FullNameとCommandLineを突き合わせるのが定石。
‘ 簡略化のため、ここでは現在稼働中のwscript/cscriptのうち直近のものを取得するロジック（※環境依存に注意）
wmiQuery = “Select From Win32_Process Where Name = ‘” & Mid(WScript.FullName, InStrRev(WScript.FullName, “\”) + 1) & “‘”
Set colProcesses = objWMIService.ExecQuery(wmiQuery)
For Each objProcess in colProcesses
‘ 厳密にはParentProcessIdやCommandLineの一致を確認すべきだが、
‘ シングルインスタンス実行を前提に簡易取得とする
pid = objProcess.ProcessId
‘ 自身のプロセスIDと一致するかどうかの判定を入れるのがベスト
Next
‘ オブジェクトの解放
Set colProcesses = Nothing
Set objWMIService = Nothing
Set shell = Nothing
GetMyProcessID = pid ‘ ※実運用では厳密なPIDマッチング実装を推奨
End Function
‘ ——————————————————————
‘ メモリ使用量を監視し、閾値を超えた場合にクリーンアップしてTrueを返す
‘ ——————————————————————
Function CheckMemoryAndGuard()
Dim objWMIService, colProcesses, objProcess
Dim workingSetBytes, workingSetMB
Dim myPID
CheckMemoryAndGuard = False
myPID = GetMyProcessID()
If IsNull(myPID) Or myPID = “” Then Exit Function
On Error Resume Next
Set objWMIService = GetObject(“winmgmts:\\.\root\cimv2”)
Set colProcesses = objWMIService.ExecQuery(“Select WorkingSetSize From Win32_Process Where ProcessId = ” & myPID)
If Err.Number <> 0 Then
‘ WMIクエリ失敗時は安全のためスルー（あるいはログ出力）
Err.Clear
Exit Function
End If
On Error GoTo 0
For Each objProcess in colProcesses
workingSetBytes = CDbl(objProcess.WorkingSetSize)
workingSetMB = workingSetBytes / BYTES_IN_MB
‘ デバッグ用出力
‘ WScript.Echo “Current Working Set: ” & FormatNumber(workingSetMB, 2) & ” MB”
If workingSetMB > THRESHOLD_MB Then
WScript.Echo “[警告] メモリ使用量が閾値を超過しました (” & FormatNumber(workingSetMB, 2) & ” MB / 制限: ” & THRESHOLD_MB & ” MB)。”
WScript.Echo “[防御] 安全なシャットダウンシーケンスを開始します…”
‘ ———————————————————-
‘ 致命的なメモリ圧迫を回避するための緊急クリーンアップ処理
‘ ———————————————————-
PerformEmergencyCleanup()
CheckMemoryAndGuard = True
Exit Function
End If
Next
‘ オブジェクトの明示的破棄（メモリリーク防止の要）
Set colProcesses = Nothing
Set objWMIService = Nothing
End Function
‘ ——————————————————————
‘ 緊急クリーンアップルーチン
‘ ——————————————————————
Sub PerformEmergencyCleanup()
‘ データベース接続、ファイルハンドラ、外部COMオブジェクトの解放をここに集約
WScript.Echo “[クリーンアップ] リソースを解放しました。プロセスを終了します。”
‘ 異常終了コードを返して安全に離脱
WScript.Quit 999
End Sub
‘ エントリーポイントの呼び出し
Main()
—
4. チーフアーキテクトが教える「現場の急所」
上記のコードを実務の巨大バッチに組み込む際、以下の3点を見落とすと本番環境で予期せぬ障害を引き起こす。
① WMIポーリングのコストと頻度
`GetObject(“winmgmts:”)` によるWMIクエリの実行は、OSに対してそれなりの負荷（CPUおよびCOMプロキシのメモリ消費）を与える。
「すべてのループの1回目」にこれを実行しては本末転倒である。必ずカウンターやタイマーを挟み、数千回に1回、あるいは一定時間ごとに実行する設計にすること。
② `WorkingSetSize` の罠
Windowsのタスクマネージャーで見えるメモリ使用量は、単純な物理メモリ（Working Set）だけでなく、仮想メモリの割り当てや共有DLLの影響を受ける。
`Win32_Process.WorkingSetSize` は「現在物理RAMに常駐しているバイト数」を返すため、メモリリークの検出には最適だが、OSのメモリ管理ポリシーによって変動することに留意せよ。閾値は、実測値の1.5倍〜2倍程度のマージンを持たせるのがプロの技だ。
③ オブジェクトの「完全な墓場送り」
VBScriptでは、変数を `Nothing` に代入しただけでは即座にメモリが回収されないことがある。特に外部COMコンポーネント（Excel.ApplicationやADODB.Connectionなど）を操作している場合、参照カウントが残ったままスクリプトがループし続けると、瞬く間にメモリが枯渇する。
オブジェクトを使い捨てるのではなく、スコープを意識した構造化と、エラー発生時でも確実に `Set xxx = Nothing` が通る `On Error Resume Next` の正しい統制が不可欠である。
—
総括
VBScriptはレガシーと呼ばれるようになって久しいが、Windows環境においてインストールの手間なく、OSの深部にダイレクトにアクセスできるこのスクリプト言語の機動力は、依然としてインフラ自動化の現場で唯一無二の価値を持っている。
「言語の限界だからメモリリークは仕方ない」と諦めるのは、エンジニアの怠慢だ。
今回紹介した「自律監視型・自己防衛機構」を組み込むことで、手のかかるレガシーバッチを、24時間不眠不休で自らを守る「自律型システム」へと昇華させることができる。
現場のコードに直ちに組み込み、システムの堅牢性を極限まで高めてほしい。
