【VBScriptを掌握する極限の知見】ネットワーク透過型・自己更新モジュール（Self-Updating Script）の実装アーキテクチャ
レガシーシステムの深淵において、VBScriptは今なおインフラの隠れた歯車として稼働し続けている。
だが、数十台、あるいは数百台のクライアント端末に散らばるローカルVBScriptの「バージョン管理」と「配布・更新」において、多くのシステム管理者が頭を悩ませてきた。ファイルサーバーの共有フォルダに最新版を置いても、ショートカットを叩くユーザーがローカルにキャッシュした古いスクリプトを惰性で実行し続け、サポートデスクがパンクする――これはレガシー運用における永遠の呪縛である。
この呪縛を断ち切る唯一の解が、「自己更新モジュール（Self-Updating Script Architecture）」だ。
本稿では、VBScriptの実行環境（WSH）の特性とOSのファイルロック挙動を熟知したシニアエンジニア向けに、ローカルで起動したスクリプト自身がネットワーク上の最新コードとバージョンを比較し、必要に応じて安全に自分自身を上書き・再起動する極限の仕組みを解説する。
—
1. アーキテクチャの核心：なぜ「その場で上書き」が成立するのか？
Windows OSのファイルシステム（NTFS）の仕様上、「現在実行中のプロセスが開いているファイルを、同一プロセスから上書き・削除することは不可能（Sharing Violation）」である。
VBScript（`cscript.exe` または `wscript.exe`）がメモリ上にロードされ実行されている最中に、自らを書き換えることは理論上できない。
では、どうやって動的差し替えを実現するのか？ アーキテクチャの全貌はこうだ。
1. ブートローダー（ラッパー）パターンの採用
ユーザーが直接実行する「ローカルの小規模なスクリプト（Launcher）」を用意する。
2. ネットワーク上の本体との比較
ランチャーは起動直後、ネットワーク共有（UNCパス）にある「マスター本体」と、ローカルにある「実体スクリプト」のバージョン情報を突合する。
3. 安全なアップデート処理
ローカルのバージョンが古い場合、または存在しない場合、ネットワークからローカルへ最新スクリプトをサイレントにダウンロード（上書きコピー）する。
4. プロセスの委譲（自己再起動）
最新コードの配置が完了したら、`WshShell.Run` を用いて新しいローカルスクリプトを別プロセスとして起動し、自身（Launcher）は速やかに `WScript.Quit` で消滅する。
この一連のライフサイクルを数ミリ秒のオーバヘッドで完結させることで、ユーザーに意識させることなく「常に最新のコードベース」を強制する。
—
2. 実装コード：完全自律型・自己更新スクリプト
以下のコードは、エラーハンドリング、オブジェクトの明示的解放、メモリ最適化、そしてネットワーク切断時のフォールバック（オフライン稼働）を考慮したプロダクション品質の実装である。
‘ ==============================================================================
‘ Script Name : AutoUpdateLoader.vbs
‘ Description : ネットワーク共有から最新VBScriptを取得・更新して実行するブートローダー
‘ Architect : Chief Architect (Legacy Systems Integration)
‘ ==============================================================================
Option Explicit
‘ 厳格なエラー制御の開始
On Error Resume Next
Dim fso, wshShell
Set fso = CreateObject(“Scripting.FileSystemObject”)
Set wshShell = CreateObject(“WScript.Shell”)
‘ — 定数定義 —
‘ ネットワーク上のマスターリポジトリ（UNCパスを指定）
Const NETWORK_REPO = “\\server01\share\AppMaster\scripts\”
Const SCRIPT_NAME = “MainProcess.vbs”
‘ ローカルの作業ディレクトリ（ユーザープロファイル配下など権限枯渇しない領域）
Dim localDir, localScriptPath, remoteScriptPath
localDir = wshShell.ExpandEnvironmentStrings(“%LOCALAPPDATA%\EnterpriseApp\”)
localScriptPath = localDir & SCRIPT_NAME
remoteScriptPath = NETWORK_REPO & SCRIPT_NAME
‘ — 1. ローカル作業環境の保証 —
If Not fso.FolderExists(localDir) Then
fso.CreateFolder(localDir)
End If
‘ — 2. バージョン判定とアップデートロジック —
Dim needsUpdate
needsUpdate = False
If Not fso.FileExists(localScriptPath) Then
‘ ローカルに実体がない場合は強制ダウンロード
needsUpdate = True
Else
‘ ネットワーク上のマスターが存在する場合のみ比較
If fso.FileExists(remoteScriptPath) Then
Dim remoteFile, localFile
Set remoteFile = fso.GetFile(remoteScriptPath)
Set localFile = fso.GetFile(localScriptPath)
‘ 最終更新日時（DateLastModified）を比較してバージョン差異を検知
If remoteFile.DateLastModified > localFile.DateLastModified Then
needsUpdate = True
End If
‘ オブジェクトの明示的解放（メモリリーク防止）
Set remoteFile = Nothing
Set localFile = Nothing
Else
‘ 【オフライン耐性】ネットワークが不通の場合はローカルの既存版で継続稼働
WScript.Echo “[WARN] Network repository is unreachable. Running in offline mode.”
End If
End If
‘ — 3. 動的差し替え（上書きコピー）の実行 —
If needsUpdate Then
‘ ファイルコピー（Overwrite = True）
fso.CopyFile remoteScriptPath, localScriptPath, True
If Err.Number <> 0 Then
‘ 権限エラーや排他制御でコピー失敗時のフォールバック
WScript.Echo “[ERROR] Failed to update script: ” & Err.Description
Err.Clear
End If
End If
‘ — 4. メモリとCOMオブジェクトの完全解放 —
‘ 実行コンテキストを引き渡す前に、確実にリソースを解放する
Set fso = Nothing
Set wshShell = Nothing
‘ — 5. 最新スクリプトの起動と自プロセスの終了 —
If fso.FileExists(localScriptPath) Then
Dim objShellExec
Set objShellExec = CreateObject(“WScript.Shell”)
‘ cscript.exeを使用することで、コンソール出力を維持したまま本体に処理を移譲
‘ 第二引数の “1” はウィンドウ表示、True/False は同期非同期（ここでは非同期で自プロセス即終了）
objShellExec.Run “cscript.exe //nologo “”” & localScriptPath & “”””, 1, False
Set objShellExec = Nothing
End If
‘ ブートローダーとしての役割を終え、終了
WScript.Quit(0)
—
3. シニアエンジニアが押さえるべき「極限の知見」と罠
このシンプルな構造の裏には、レガシー環境特有の深刻な罠が潜んでいる。現場で発生しうる致命的なトラブルを防ぐためのアーキテクチャ上の知見を共有する。
A. オブジェクトのライフサイクルとメモリ最適化
VBScriptの背後にあるCOM（Component Object Model）の参照カウント機構は、GC（ガベージコレクション）のように自動でスマートに回収されないケースがある。特に長期間稼働するプロセスや、ループ内でWMIやFileSystemObjectを生成破棄するコードでは、明示的な `Set obj = Nothing` によるデストラクタの強制呼び出しが必須である。
今回のコードでも、ファイル比較処理が終わった時点で `remoteFile` や `localFile` を速やかに解放している。これを怠ると、ファイルハンドルがリークし、次回の更新時に「アクセスが拒否されました (Permission Denied)」を引き起こす。
B. ネットワークの断絶（オフライン環境）への耐性
工場内の端末や、VPN接続が不安定なリモートワーカーの環境において、「ネットワーク共有が見つからない」という事象は日常茶飯事である。
もしネットワークに接続されていないという理由だけでスクリプト全体がクラッシュしたら、業務システムとして失格である。上記コードでは、`If fso.FileExists(remoteScriptPath) Then` による存在確認と、`On Error Resume Next` の適切なスコープ管理により、「ネットワークがあれば最新化、なければローカルキャッシュで無心に稼働する」という堅牢なフォールバックを実現している。
C. タイムスタンプ比較の限界とハッシュ検証への拡張
今回のサンプルコードでは、実装の軽量性と速度を重視し、ファイルの最終更新日時（`DateLastModified`）をバージョン差異の基準に採用した。
しかし、ファイルサーバーの時刻同期ズレ（NTPの不調など）が発生するインフラ環境では、誤検知のリスクが生じる。より厳密なエンタープライズ環境を構築する場合は、ネットワーク上に `version.txt` や `checksum.json`（SHA-256ハッシュ値が記載されたメタデータ）を置き、それをHTTP（IIS経由）やAPI経由で取得して比較するロジックへと昇華させるべきである。
—
4. 運用管理の極み：タスクスケジューラとの統合
この自己更新モジュールを真に強力なインフラ武器にするには、ユーザーのデスクトップにバラまいたショートカットから実行させるのではなく、Windowsタスクスケジューラと組み合わせる。
- 端末のログオン時、または毎日定時にバックグラウンドでこのブートローダーを走らせる。
- ユーザーは常に最新の業務ロジックを意識することなく、バックグラウンドで自動的にコードが最新化される。
- 配布サーバー側の `MainProcess.vbs` を1箇所差し替えるだけで、全拠点の端末のロジックが瞬時にバージョンアップされる。
VBScriptというレガシーな言語であっても、アーキテクチャの設計思想次第で、モダンなCI/CDパイプラインに匹敵する「自動デプロイメント機構」を自社環境に構築することが可能となる。
古の技術を呪うのではなく、その制約を理解し、手なずけることこそが、真のインフラエンジニア・アーキテクチャの美学である。
