ExecuteGlobalの深淵：動的コード実行におけるスコープ汚染と、堅牢なアーキテクチャへの回帰
レガシーシステムの保守、あるいは複雑なWSH（Windows Script Host）ベースの自動化基盤を設計する際、我々はしばしば「動的な柔軟性」という甘い誘惑に直面する。
その筆頭が `ExecuteGlobal` ステートメントだ。
外部の `.vbs` ファイルや設定ファイルを、あたかも自身のコードの一部であるかのように、その場で評価・実行する。一見すると、共通設定をスマートに読み込むためのエレガントな手法に見えるだろう。しかし、プロフェッショナルとして断言しておく。`ExecuteGlobal` を無策に利用することは、自らのプログラムに時限爆弾を埋め込む行為に等しい。
本稿では、`ExecuteGlobal` が引き起こす「変数スコープの汚染」と「コード注入によるセキュリティリスク」のメカニズムを解剖し、真に堅牢なシステムを構築するための「カプセル化」と「オブジェクト指向的アプローチ」について解説する。
1. ExecuteGlobal のメカニズムと「スコープ汚染」の正体
VBScriptにおける `Execute` と `ExecuteGlobal` は、実行されるコードの「コンテキスト（文脈）」が決定的に異なる。
- `Execute`: 実行されるコードは、呼び出し元の「ローカルスコープ」内に展開される。
- `ExecuteGlobal`: 実行されるコードは、スクリプト全体の「グローバルスコープ」に直接展開される。
この「グローバルスコープへの直結」こそが、破滅の入り口である。
スコープ汚染（Scope Pollution）のシナリオ
例えば、共通設定を管理する `config.vbs` が存在し、そこに `Dim timeout` という宣言があるとしよう。メインの実行スクリプト側でも、処理のタイムアウトを制御するために `Dim timeout` を宣言していた場合、`ExecuteGlobal` を実行した瞬間に、メインスクリプトが保持していたはずの変数の参照、あるいは宣言そのものが、外部ファイルの内容によって上書き・干渉される。
これは単なる「値の書き換え」に留まらない。意図しない変数の再宣言による実行時エラー、あるいは、本来ローカルで完結すべきはずのロジックが、外部ファイルの影響でグローバルな状態に依存してしまう「非決定的な挙動」を引き起こす。これは、大規模なシステムにおいてデバッグを不可能にする致命的な欠陥となる。
2. セキュリティの脆弱性：コード注入（Code Injection）の脅威
`ExecuteGlobal` を使用するということは、「外部ファイルの内容を、信頼できる命令として実行する」ことを意味する。
もし、その設定ファイルが書き込み権限の緩い共有ディレクトリに置かれていたり、他のプロセスから操作可能であった場合、攻撃者は設定ファイルの中に以下のようなコードを忍び込ませることが可能だ。
' 悪意のある設定ファイルへの注入例
WScript.CreateObject("WScript.Shell").Run "cmd.exe /c calc.exe", 1, True
' あるいは、より静かにシステム情報を外部へ送信するペイロード設定ファイルは単なる「値（Key-Value）」の集合体であるべきだ。そこに「ロジック（命令）」が混入することを許容した時点で、そのシステムはもはや制御不能な攻撃対象（Attack Surface）へと変貌する。
3. 伝説的アーキテクチャによる解決策：Dictionaryオブジェクトによるカプセル化
我々が目指すべきは、コードを動的に実行することではなく、「データを動的にロードし、それをカプセル化されたオブジェクトとして扱う」ことである。
`ExecuteGlobal` を捨て、`Scripting.Dictionary` を用いて設定値を管理する設計へと移行せよ。これにより、スコープの汚染を物理的に遮断し、コードとデータの分離を徹底できる。
【実践】堅牢な設定ロード・エンジンの実装例
以下に、設定ファイルを「コード」としてではなく、「データ」として安全に読み込むプロフェッショナルな実装パターンを示す。
' ==========================================================================
' Module: SecureConfigLoader
' Description: ExecuteGlobalを使用せず、Dictionaryを用いて設定を安全にロードする
' ==========================================================================
Option Explicit
' メイン処理
Sub Main()
Dim objConfig, strConfigPath
strConfigPath = "config.txt" ' 設定ファイル（コードではなく、Key=Value形式）
' 1. 設定のロード（カプセル化されたオブジェクトとして取得）
Set objConfig = LoadSettings(strConfigPath)
If objConfig Is Nothing Then
WScript.Echo "Error: 設定の読み込みに失敗しました。"
WScript.Quit 1
End If
' 2. 設定値の利用（スコープ汚染の心配なし）
WScript.Echo "Timeout Value: " & objConfig("Timeout")
WScript.Echo "Server Address: " & objConfig("ServerAddr")
' 3. オブジェクトの明示的解放（メモリ管理の極意）
Set objConfig = Nothing
End Sub
' --------------------------------------------------------------------------
' Function: LoadSettings
' Purpose: 設定ファイルを解析し、Scripting.Dictionaryとして返す
' --------------------------------------------------------------------------
Function LoadSettings(ByVal strFilePath)
Dim objFSO, objFile, strLine, arrParts
Dim objDict
' エラーハンドリングの開始
On Error Resume Next
Set objFSO = CreateObject("Scripting.FileSystemObject")
' ファイルの存在確認
If Not objFSO.FileExists(strFilePath) Then
Set objFSO = Nothing
Set LoadSettings = Nothing
Exit Function
End If
Set objDict = CreateObject("Scripting.Dictionary")
Set objFile = objFSO.OpenTextFile(strFilePath, 1) ' ForReading
Do Until objFile.AtEndOfStream
strLine = Trim(objFile.ReadLine)
' 空行およびコメント行（;）をスキップ
If strLine <> "" And Left(strLine, 1) <> ";" Then
' "=" で分割
arrParts = Split(strLine, "=", 2)
If UBound(arrParts) = 1 Then
' Key=Value の形式でDictionaryに格納
' Trimで不要な空白を除去し、クリーンなデータを保持する
objDict.Add Trim(arrParts(0)), Trim(arrParts(1))
End If
End If
Loop
objFile.Close
' リソースの解放
Set objFile = Nothing
Set objFSO = Nothing
If Err.Number <> 0 Then
WScript.Echo "Critical Error during loading: " & Err.Description
Set objDict = Nothing
Set LoadSettings = Nothing
Else
Set LoadSettings = objDict
End If
On Error GoTo 0
End Function
' 実行
Mainこの設計の卓越した点
1. 完全な分離（Isolation）: 設定ファイルは `Key=Value` のテキスト形式であり、VBScriptの命令（`Execute`）を含めることができない。これにより、コード注入攻撃を構造的に不可能にしている。
2. スコープの保護: 設定値は `Dictionary` オブジェクトの中に閉じ込められている。メインスクリプトの変数名と設定ファイルのキー名が衝突しても、オブジェクトのプロパティとして扱われるため、グローバルな変数空間を汚染することはない。
3. リソース管理（Memory Management）: `FileSystemObject` や `File` オブジェクトを、処理終了直後に `Set … = Nothing` で明示的に解放している。これは、長時間稼働するWSHプロセスにおけるメモリリークを防ぎ、システム全体の安定性を担保するための鉄則である。
4. 堅牢なエラー処理: `On Error Resume Next` を最小限の範囲で使用し、ファイル不在や読み込みエラーを適切にハンドリングしている。
結論：アーキテクトの責務
`ExecuteGlobal` は、プロトタイプを素早く作るための「劇薬」だ。使いこなせば強力だが、本番環境の基盤に組み込むにはあまりにリスクが高い。
シニアエンジニア、そしてアーキテクトとしての責務は、単に「動くコード」を書くことではない。「壊れない構造」を設計することだ。データの流入口（I/O）を厳格に定義し、オブジェクトによるカプセル化を徹底すること。この基本に立ち返ることこそが、レガシーな環境から次世代の堅牢なシステムへと昇華させる唯一の道である。
「利便性に魂を売るな。堅牢性に魂を込めよ。」
