Beyond Temp Files: Mastering Real-Time Inter-Process Communication via WScript.Shell.Exec
レガシーなWindows環境における自動化、あるいは現代的なマイクロサービスとレガシーなVBA/VBScript資産の橋渡しにおいて、我々エンジニアが直面する最大の課題の一つは「プロセス間通信（IPC）」である。
多くの開発者は、プロセス間でデータを渡す際、安易に「一時ファイル（Temp Files）」や「環境変数」に頼る。しかし、それはアーキテクチャとして極めて脆弱だ。一時ファイルはディスクI/Oのオーバーヘッドを生むだけでなく、セキュリティ上の痕跡を残し、ファイルロックによる競合（Race Condition）を誘発する。環境変数もまた、スコープが限定的であり、動的な大量データの受け渡しには適さない。
真に堅牢なシステムを構築する者は、`WScript.Shell.Exec` が提供する標準入出力（Standard I/O）のパイプを直接制御する。本稿では、子プロセスに対して動的にコマンドを送り、そのレスポンスをリアルタイムに解析する、極限のプロセス制御手法について詳解する。
1. 概念の深層：`Run` ではなく `Exec` を選ぶ理由
WSH（Windows Script Host）において、プロセスを起動するメソッドは主に2つある。`Run` メソッドと `Exec` メソッドだ。
- `Run` メソッド: プロセスを起動し、終了を待機するか、あるいは投げっぱなしにする。戻り値は終了コード（Exit Code）のみであり、プロセスとの「対話」は不可能である。
- `Exec` メソッド: プロセスを実行し、そのプロセスを操作するための `WshExec` オブジェクトを返す。このオブジェクトこそが、標準入力（StdIn）、標準出力（StdOut）、標準エラー出力（StdErr）へのストリームへのゲートウェイとなる。
我々が求める「双方向の動的な制御」を実現するためには、`Exec` によるストリーム操作が不可欠である。
2. デッドロックの罠：パイプのバッファリング問題
`Exec` を使用する際に、シニアエンジニアが最も警戒すべきはデッドロック（Deadlock）である。
Windowsのパイプにはバッファ（容量）が存在する。子プロセスが大量のログを標準出力に書き出し、親プロセス（VBScript）がそれを読み取らずに標準入力へ書き込みを続けようとすると、子プロセスの出力バッファが溢れ、子プロセスは「書き込み完了」を待って停止する。一方で親プロセスは「書き込み完了」または「子プロセスの終了」を待つ。結果、両者が互いに待ち状態となり、システムは沈黙する。
これを回避するためには、「書き込み」と「読み取り」のサイクルを、ストリームの空き状況に応じて慎重に制御する必要がある。
3. 実装解：双方向対話型プロトコルの構築
以下に、子プロセス（ここでは例として `cmd /c` を用いた擬似的な対話インターフェース）に対して、コマンドを送り、そのレスポンスを一行ずつ解析する堅牢な実装パターンを示す。
' **
' Module: IPC_Master_Pattern.vbs
' Description: WScript.Shell.Exec を用いた標準入出力による双方向通信の極致
' Author: Legendary Chief Architect
' **
Option Explicit
Dim objShell, objExec
Dim strCommand, strInput, strResponse
Set objShell = CreateObject("WScript.Shell")
' ターゲットとなるプロセスを指定 (例: cmd.exe を対話モードで起動)
' 実際の実装では、自作のCLIツールやPythonスクリプト等を指定する
strCommand = "cmd.exe /k echo Ready_to_receive"
On Error Resume Next
Set objExec = objShell.Exec(strCommand)
If Err.Number <> 0 Then
WScript.Echo "Error: Failed to execute process. " & Err.Description
WScript.Quit 1
End If
On Error GoTo 0
' --- メイン・インタラクション・ループ ---
' このループは、プロセスが生存している限り、あるいは特定の終了条件を満たすまで継続する
Do While objExec.Status = 0 ' 0 = Running
' 1. 標準出力の解析 (Non-blocking的なアプローチ)
' AtEndOfStream を確認することで、読み取り待ちによるブロッキングを最小限に抑える
If Not objExec.StdOut.AtEndOfStream Then
strResponse = objExec.StdOut.ReadLine
' レスポンスの解析ロジック
If InStr(strResponse, "Ready_to_receive") > 0 Then
WScript.Echo "[System] Process is ready. Sending command..."
' 2. 標準入力への書き込み (Command Injection)
' コマンドの末尾には必ず改行コード(vbCrLf)を付与すること
objExec.StdIn.WriteLine "echo Hello_from_VBScript"
objExec.StdIn.WriteLine "exit" ' プロセスを終了させるコマンド
Else
WScript.Echo "[Output] " & strResponse
End If
End If
' 3. 標準エラー出力の監視 (重要: エラーを無視しない)
If Not objExec.StdErr.AtEndOfStream Then
WScript.Echo "[ERROR] " & objExec.StdErr.ReadLine
End If
' CPU負荷軽減のための微小なウェイト (WScript.Sleep)
' これを怠ると、Busy-waitingによるCPU使用率のスパイクを招く
WScript.Sleep 100
Loop
' --- 後処理とメモリ管理 ---
' オブジェクトのライフサイクルを明示的に管理する
' これを行わないと、プロセスがゾンビ化したり、ハンドルがリークしたりする可能性がある
WScript.Echo "[System] Process exited with code: " & objExec.ExitCode
Set objExec = Nothing
Set objShell = Nothing
WScript.Echo "[System] Cleanup complete."4. アーキテクチャとしての最適化：極限の知見
この実装を実戦投入するにあたり、以下の3点を肝に銘じておくことだ。
I. `ReadLine` vs `ReadAll`
`ReadAll` メソッドは、ストリームが閉じられる（EOFに達する）まで呼び出し元をブロックする。リアルタイムな制御が必要な場合、`ReadAll` は禁忌である。常に `AtEndOfStream` プロパティを監視し、`ReadLine` を用いて「断片的な情報」を逐次処理せよ。
II. エラーハンドリングの徹底
`StdErr`（標準エラー出力）の監視を怠る者は、デバッグ不能なシステムを量産する。子プロセスが内部的なエラーで停止した際、その原因は `StdErr` にのみ記録される。メインのロジックとは別に、常に `StdErr` のストリームをチェックする機構を組み込むのが、プロフェッショナルの作法である。
III. 明示的なリソース解放
VBScript は COM オブジェクトの参照カウンタに基づき動作する。`Set obj = Nothing` は単なる作法ではない。特に `WshExec` オブジェクトが生きている限り、その子プロセスへのハンドルは保持され続ける。プロセスが終了した後、即座にオブジェクトを解放することで、OSリソースの枯渇を防ぎ、システムの長期安定稼働を保証できる。
結論
`WScript.Shell.Exec` を介したプロセス間通信は、一時ファイルに頼る低レイヤーな手法とは一線を画す、洗練されたエンジニアリングの領域である。パイプの特性を理解し、デッドロックを回避し、ストリームを制御する。この技術をマスターすることこそが、レガシー環境における自動化の「真の支配者」への道である。
