【バッチ組み込みVBS】Windowsバッチ内でVBScriptを動的生成・実行・自動削除するワンライナー運用術
開発現場において、最も頭を悩ませる問題の一つが「環境依存とファイル散逸」だ。
クライアント端末や社内共有サーバーに業務自動化ツールを展開する際、「VBSファイル単体で配ると、ユーザーが誤ってファイルを削除する」「ショートカットのパスが狂う」「バージョン管理が煩雑になる」といったトラブルが絶えない。
ここで提案するのが、Windowsバッチ（.bat / .cmd）の中にVBScriptを内包し、実行時にメモリ上または一時ファイルとして動的生成、即座に実行して、事後に完全消去する「ワンライナー運用術」である。
この手法を極めれば、配布物は常に「ただの1つのバッチファイル」だけで完結し、かつVBScriptの強力なGUI操作（`MsgBox`や`InputBox`、WMI制御、Excel/COM操作）の恩恵を完全に受けることができる。
今回は、現場のプロが実践している、バグの起きない堅牢な動的生成の設計思想と、実務でそのまま使えるプロダクションコードを伝授しよう。
—
なぜ「バッチ単体」ではなく「VBSハイブリッド」なのか？
バッチファイル（Cmd.exe）は環境構築不要でどこでも動くという最大のメリットがあるが、致命的な弱点がある。
- 文字コード問題（UTF-8とShift-JISの壁）
- 貧弱な文字列操作と、複雑な条件分岐の書きにくさ
- 標準でポップアップGUI（メッセージボックス）が出せない
一方で、VBScriptはWindows環境であればレガシーから最新まで追加ランタイムなしで動作し、COMオブジェクトを介してOSの深部まで制御できる。
この両者の長所を組み合わせるための最適解が、「バッチが起動するたびに、自分自身の内部にあるVBScriptの断片を一時ファイルとして吐き出し、WScriptで実行して、用が済んだら秒速で消す」というライフサイクル管理である。
—
堅牢な設計における3大鉄則
適当に `echo` でVBScriptを出力しようとすると、文字コードの化け、ダブルクォーテーションの衝突、そしてファイルロックの罠に嵌まる。プロフェッショナルとして、以下の3点は絶対に死守せよ。
1. 文字コードは Shift-JIS（CP932）で統一する
バッチファイル自体をShift-JISで保存し、出力する一時VBSもOSのデフォルトエンコーディングに合わせることで、日本語の文字化けを根絶する。
2. エスケープ地獄の回避
VBScript内のダブルクォーテーション（`”`）や特殊文字をバッチ内でどう扱うか。基本は「バッチ内では極力ダブルクォーテーションを出力時に重ねる」、あるいは「VBS側をシングルクォーテーション中心で記述する」ことで構文エラーを防ぐ。
3. 確実なクリーンアップ（Trap構文）
途中でスクリプトが異常終了しても、一時ファイルが野良プロセスとして残らないよう、バッチの制御構文（`1>nul 2>nul` やエラーハンドリング）で確実に削除を保証する。
—
【プロダクションコード】実務で使える完全版バッチ
以下のコードは、バッチファイルから動的にVBScriptを生成し、ユーザーに入力を促すGUI（InputBox）を表示、その結果を受け取ってバッチ側の処理に繋げる実用的なテンプレートだ。
メモ帳に貼り付け、拡張子を `.bat` （例：`deploy_tool.bat`）として保存して即座に検証してほしい。
@echo off
setlocal enabledelayedexpansion
chcp 932 > nul
:: ==============================================================================
:: 処理名: VBS動的生成・実行・自動削除 テンプレート
:: 概要 : バッチの機動力とVBSのGUI機能を融合させた実務向けワンライナー運用術
:: ==============================================================================
:: 1. 一意な一時VBSファイルのパスを生成（タスクIDやPIDの代わりとしてランダム値を利用）
set “TEMP_VBS=%TEMP%\wk_script_%RANDOM%.vbs”
set “TEMP_OUT=%TEMP%\wk_result_%RANDOM%.txt”
echo [INFO] 一時VBScriptを動的生成します…
:: 2. VBScriptの動的吐き出し（Redirectionを利用）
:: ※バッチ内の特殊文字（^, %, <, >）はキャレット(^)でエスケープすること
(
echo Option Explicit
echo Dim objArgs, userInput, fso, ts
echo
echo ‘ WScript.Argumentsからバッチ側からの引数を受け取ることも可能だが、今回はシンプルにGUIを表示
echo userInput = InputBox(“業務システムのデプロイ先サーバー名を入力してください:”, “デプロイ自動化ツール”, “srv-prod-01”)
echo
echo ‘ キャンセルされた、または空欄の場合は処理を中断
echo If userInput = “” Then
echo WScript.Quit(1)
echo End If
echo
echo ‘ 結果を一時ファイルに書き出す（文字コード: Shift-JIS）
echo Set fso = CreateObject(“Scripting.FileSystemObject”)
echo Set ts = fso.CreateTextFile(“%TEMP_OUT:\\=\\%”, True, False)
echo ts.Write userInput
echo ts.Close
echo
echo WScript.Quit(0)
) > “%TEMP_VBS%”
:: 3. VBScriptの実行（cscript または wscript）
:: GUIを伴うため wscript を使用。バッチ側で終了を同期させるために “start /wait” を活用
echo [INFO] VBScriptによるGUI入力を待機中…
wscript.exe “//Nologo” “%TEMP_VBS%”
set “VBS_EXIT_CODE=%ERRORLEVEL%”
:: 4. 終了コードの判定と結果の回収
If %VBS_EXIT_CODE% NEQ 0 (
echo [WARN] ユーザーによって操作がキャンセルされました。
goto CLEANUP
)
:: 一時ファイルから結果読み込み
for /f “usebackq delims=” %%A in (“%TEMP_OUT%”) do (
set “SERVER_NAME=%%A”
)
echo [SUCCESS] 入力されたサーバー名: %SERVER_NAME%
:: ここに実際の業務処理（robocopyやAPI叩きなど）を記述する
:: 5. 【最重要】ライフサイクル完結：一時ファイルの完全削除
:CLEANUP
echo [INFO] 一時ファイルをクリーンアップしています…
if exist “%TEMP_VBS%” del /f /q “%TEMP_VBS%”
if exist “%TEMP_OUT%” del /f /q “%TEMP_OUT%”
echo [INFO] すべての処理が正常終了しました。
pause
exit /b 0
—
コードの急所とアーキテクトの視点
上記のコードにおいて、プロのエンジニアとして注目すべきポイントを解説する。
1. パスのエスケープ処理 (`%TEMP_OUT:\=\%`)
VBScriptのコードブロック内でファイルパスを指定する際、バッチ変数の遅延展開やリダイレクションの絡みでバックスラッシュ（`\`）が意図せず解釈されるリスクがある。
そのため、出力時に `%TEMP_OUT:\\=\\%` と記述することで、VBScript側で正しく解釈されるエスケープされたパス文字列を安全に流し込んでいる。
2. `wscript.exe //Nologo` と同期処理
バッチファイルからVBSを呼び出す際、`wscript` はデフォルトだと非同期（Fire and Forget）で動くことがある。バッチ側でユーザーの入力結果を待たずに次の処理が進んでしまうバグを防ぐため、`start /wait` を使うか、あるいはコンソール出力を制御する `cscript` に切り替える設計が不可欠となる。今回はGUI（InputBox）を出すため `wscript` を採用しつつ、プロセスが終了するまでバッチがブロックされる挙動を利用している。
3. ゴミを残さない「クリーンアップの徹底」
例外が発生しようが、ユーザーがウィンドウを閉じようが、最後に必ず `:CLEANUP` ラベルへジャンプし、`del /f /q` で痕跡を消し去る。この「環境を汚さない美学」こそが、野良スクリプトを社内ニッチツールから「堅牢な業務システム」へと昇華させる条件である。
—
応用：データベースやAPI連携への発展
この「バッチ＋動的VBS」のアーキテクチャが完成していれば、VBScriptの強みである ADODBによるSQL Server / Oracle / Accessへの直結クエリ発行 や、MSXML2.ServerXMLHTTPを用いた社内REST APIへのJSON送信 が、一切のインストール作業なしでバッチの実行コード内に内包できるようになる。
「Pythonを入れる権限がない」「PowerShellの実行ポリシー（ExecutionPolicy）が厳しく阻まれる」という閉ざされたレガシー・セミモダン混在のWindows環境において、本手法は今なお最強のカードの1つである。
現場の自動化を次のステージへ引き上げるために、ぜひこのデザインパターンをあなたの引き出しに加えてほしい。
