【セキュリティ対策】VBScriptの平文コードを保護する VBE化と暗号化の限界・運用上の注意点
業務自動化の現場において、WSH（Windows Script Host）とVBScriptの機動力はいまだに色褪せることがない。メモ帳さえあれば数分でツールが組み上がり、追加のランタイムインストールの手間もなく、OSの奥深くまでアクセスできる。
しかし、ここにひとつの「致命的なジレンマ」が立ちはだかる。
自動化スクリプトには、しばしば「データベースの接続文字列」「APIのシークレットキー」「特権アカウントのパスワード」「社内ニッチな業務ロジック（知財）」をハードコードせざるを得ない瞬間が存在する。
「スクリプトファイルを社内共有サーバーに置いたら、一般社員に中身の平文を見られてしまった」
「退職予定者がソースコードをごっそりコピーしていった」
こうしたセキュリティインシデントを防ぐために、古くからWindows標準で用意されている難読化手法が VBE (VBScript Encoded) 化 である。
本記事では、`screnc.exe` を用いたVBE化の正確な実務手順から、「なぜVBEはセキュリティの免罪符にならないのか」というエンジニア必知の暗号化の限界、そしてプロダクション環境における正しい防衛設計までを、チーフアーキテクトの視点からロジカルかつシャープに伝授する。
—
1. VBE (VBScript Encoded) の正体と `screnc` によるエンコード手順
まず大前提として認識してほしい。VBE化は「暗号化 (Encryption)」ではなく「難読化 (Obfuscation)」である。
Windows（正確にはWSHランタイム）には、拡張子が `.vbe` や `.jse` のファイルをネイティブに実行する機能が備わっている。これは、スクリプトの実行エンジンに「このコードは読みにくくエンコードされているから、内部でデコードして実行しなさい」と指示しているに過ぎない。
screnc.exe の入手と実行
Windowsには標準でスクリプトエンコーダーである `screnc.exe` がインストールされている（あるいはMicrosoftから無償ダウンロード可能）。
実務でVBE化を行う際は、手動でコマンドを叩くのではなく、ビルドバッチまたは後述するPowerShell/VBScriptによるラッパーを通じて自動化すべきである。
@ECHO OFF
REM ==============================================================================
REM スクリプト難読化バッチ (build_vbe.bat)
REM 概要: 開発用の平文 .vbs を、本番用の難読化済み .vbe へコンパイルする
REM ==============================================================================
SETLOCAL
SET “SCRENC=C:\Program Files (x86)\Microsoft Script Encoder\screnc.exe”
SET “TARGET_DIR=C:\Automation\Scripts”
IF NOT EXIST “%SCRENC%” (
ECHO [ERROR] Script Encoder が見つかりません。パスを確認してください。
EXIT /B 1
)
ECHO [INFO] VBScriptのエンコードを開始します…
“%SCRENC% /e VBS “%TARGET_DIR%\MasterProcess.vbs” “%TARGET_DIR%\MasterProcess.vbe”
IF %ERRORLEVEL% EQU 0 (
ECHO [SUCCESS] 難読化が完了しました。
) ELSE (
ECHO [ERROR] エンコードに失敗しました。エラーコード: %ERRORLEVEL%
)
ENDLOCAL
エンコードされた `.vbe` ファイルの中身をメモ帳で開くと、以下のような文字列に変貌していることが確認できる。
@~^LQAAAA==@#@&.D`k+ (中略) `^#~@
人間が目視してパスワードやロジックを読み取ることは、この瞬間不可能になる。
—
2. 【重要】VBEの致命的な限界と「解読リスク」の現実
開発プロジェクトのリーダーとして、君たちに最も強く伝えなければならないのは、「VBEは高度なセキュリティ保護には全く役立たない」という冷徹な事実だ。
① 逆コンパイル（デコード）の容易さ
VBEのアルゴリズムは数十年前に設計されたものであり、現在ではインターネット上に無数の「VBE Decoder（逆エンコーダー）」や、Python等で書かれた数行のデコードスクリプトが落ちている。
悪意を持った人間が `.vbe` ファイルを入手すれば、1分足らずで元の平文 `.vbs` に復元されてしまう。
② メモリ上（プロセス）での露出
VBScriptが実行される瞬間、Windowsのメモリ上では平文のコードが展開されている。プロセスダンプやメモリ解析ツールを使えば、実行中のコードを抜き取ることは容易だ。
結論：VBEを使うべき真の目的
「プロ級のハッカーからの防御」をVBEに期待してはならない。VBEを導入する目的は、以下の2点に限定される。
1. 「一般ユーザーがうっかりメモ帳で開いて設定値を書き換えてしまう事故（誤操作）」の防止
2. 「ファイル一覧を一瞥したときに、機微情報が丸見えになっている状態（心理的・コンプライアンス上のリスク）」の回避
—
3. プロダクション環境における「真の機密情報管理」設計
では、パスワードやAPIキーを安全に扱いたい場合、VBScript / WSH環境ではどう設計すべきなのか。
答えは「コードの中に機微情報を書かない（分離する）」ことだ。
以下のプロダクションコード例を見てほしい。設定値（接続情報など）をコードから完全排除し、外部の暗号化された設定ファイル、または環境変数から安全に読み込む設計パターンである。
プロダクション品質の堅牢なスクリプト例 (`SecureAutomation.vbs`)
‘ ==============================================================================
‘ 業務自動化テンプレートスクリプト (SecureAutomation.vbs)
‘ アーキテクチャ: 設定分離型・エラーハンドリング完備・ロギング実装
‘ ==============================================================================
Option Explicit
‘ メイン処理の実行
Main
Sub Main()
Dim objFSO, objShell, configPath
Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objShell = CreateObject(“WScript.Shell”)
On Error Resume Next
‘ 1. 設定ファイル（INI または JSON）のパスを特定（スクリプトと同階層）
configPath = objFSO.GetParentFolderName(WScript.ScriptFullName) & “\config.ini”
If Not objFSO.FileExists(configPath) then
Call WriteLog(“FATAL”, “設定ファイルが見つかりません: ” & configPath)
WScript.Quit(1)
End If
‘ 2. 設定値の読み込み（機微情報は平文コードから排除）
Dim dbConnectionString, apiSecretKey
dbConnectionString = ReadIniFile(configPath, “Database”, “ConnectionString”)
‘ ※環境変数から機微情報を動的取得するアプローチも強力
apiSecretKey = objShell.ExpandEnvironmentStrings(“%MY_API_SECRET%”)
If apiSecretKey = “%MY_API_SECRET%” Then
apiSecretKey = ReadIniFile(configPath, “API”, “FallbackKey”) ‘ フォールバック
End If
If Err.Number <> 0 Then
Call WriteLog(“FATAL”, “設定値の読み込み中にエラーが発生しました: ” & Err.Description)
WScript.Quit(2)
End If
On Error GoTo 0 ‘ エラー監視を通常に戻す
‘ 3. 業務ロジックの実行
Call WriteLog(“INFO”, “業務プロセスを開始します。”)
‘ (ここに実際のDB処理やAPI通信処理を記述)
‘ 例: Call ExecuteDatabaseTask(dbConnectionString)
Call WriteLog(“INFO”, “業務プロセスが正常に完了しました。”)
Set objShell = Nothing
Set objFSO = Nothing
End Sub
‘ ——————————————————————————
‘ 汎用関数: INIファイルから指定セクション・キーの値を取得する
‘ ——————————————————————————
Function ReadIniFile(filePath, section, key)
Dim objFile, line, currentSection, targetKey
Dim fso, retVal
Set fso = CreateObject(“Scripting.FileSystemObject”)
Set objFile = fso.OpenTextFile(filePath, 1) ‘ ForReading
currentSection = “”
targetKey = LCase(Trim(key))
retVal = “”
Do While Not objFile.AtEndOfStream
line = Trim(objFile.ReadLine)
‘ コメントや空行をスキップ
If line <> “” And Left(line, 1) <> “;” And Left(line, 1) <> “#” Then
If Left(line, 1) = “[” And Right(line, 1) = “]” Then
currentSection = Trim(Mid(line, 2, Len(line) – 2))
Else
Dim delimiterPos
delimiterPos = InStr(line, “=”)
If delimiterPos > 0 And LCase(currentSection) = LCase(section) then
Dim k, v
k = LCase(Trim(Left(line, delimiterPos – 1)))
v = Trim(Mid(line, delimiterPos + 1))
If k = targetKey Then
retVal = v
Exit Do
End If
End If
End If
End If
Loop
objFile.Close
Set objFile = Nothing
Set fso = Nothing
ReadIniFile = retVal
End Function
‘ ——————————————————————————
‘ ログ出力関数（運用保守の必須要件）
‘ ——————————————————————————
Sub WriteLog(level, message)
Dim fso, logFile, logPath
Set fso = CreateObject(“Scripting.FileSystemObject”)
logPath = fso.GetParentFolderName(WScript.ScriptFullName) & “\execution.log”
‘ ログファイルが存在しない場合は新規作成（追記モード: 8）
Set logFile = fso.OpenTextFile(logPath, 8, True)
logFile.WriteLine “[” & Now() & “] [” & level & “] ” & message
logFile.Close
Set logFile = Nothing
Set fso = Nothing
End Sub
—
4. チーフアーキテクトからの実務提言
VBScriptを業務自動化のインフラとして使い続けるのであれば、セキュリティと運用のバランスを以下のポリシーで統制してほしい。
1. コードの難読化（VBE化）は「お化粧」と割り切る
悪意ある第三者からの防御ではなく、一般ユーザーによる誤改ざん防止の保険として、ビルドプロセスの中に `screnc.exe` を組み込むのはアリだ。しかし「これでパスワードが安全になった」と勘違いしてはならない。
2. 機密情報はファイルや環境変数へ外出しする
パスワードや接続文字列は、アクセス権限（ACL）が適切に設定されたフォルダ内の設定ファイル（INI/JSON）に隔離するか、Windowsの「資格情報マネージャー」、あるいは「環境変数」から取得する設計を徹底せよ。
3. 限界を見極め、モダンな代替手段へ移行する舵取りを行う
VBScriptは強力だが、現代のセキュリティ基準（ゼロトラスト・多要素認証・強固な暗号化要件）においてはレガシーな技術である。新規の複雑なシステムや、クラウド連携が必須の自動化であれば、最初から PowerShell (Core) や Python、あるいは Azure Functions / Power Automate へのリプレースを検討するのが、プロのエンジニアとしての正しい決断である。
技術の特性を正しく理解し、コントロール下置くこと。それこそが、堅牢で保守性の高い自動化基盤を作り上げる唯一の道である。
