ハードウェア・アイデンティティの掌握：Drive.SerialNumberを用いた実行環境制御の極致
業務自動化の現場において、スクリプトは「単に動く」だけでは不十分だ。真にプロフェッショナルなエンジニアが構築するコードは、「それが実行されるべき場所で、実行されるべき時のみ動作する」という、環境に対する厳格な規律（Integrity）を備えていなければならない。
特に、レガシーな資産として残るVBScriptを用いた自動化ソリューションにおいて、特定の端末（PC個体）や特定のストレージ環境でのみ動作を許可する「実行ガードロジック」の実装は、意図しない環境でのデータ破損や誤動作を防ぐための、極めて重要な防波堤となる。
本稿では、`FileSystemObject` (FSO) の `Drive.SerialNumber` プロパティを軸に、単なるコードの書き方を越えた、オブジェクトのライフサイクル、メモリ管理、そしてシステムアーキテクチャとしての安全な実装手法について詳解する。
1. `Drive.SerialNumber` の正体と、エンジニアが陥る「誤解」
まず、技術的な定義を正確に整理しておく。`FileSystemObject.Drives(“C:”).SerialNumber` が返す値は、物理的なディスクの製造番号（Physical Serial Number）ではない。それは、「ボリューム・シリアル番号（Logical Volume Serial Number）」である。
これは、ドライブがフォーマットされた際にOSによって割り当てられる論理的な識別子だ。
ここが設計の分岐点となる
シニアエンジニアとして、以下の差異を脳内に刻んでおく必要がある。
- ボリューム・シリアル（FSOで取得可能）: フォーマット時に変わる。OSレベルの論理的な識別。
- 物理シリアル（WMIやWindows APIが必要）: ハードウェアそのものの識別。フォーマットしても変わらない。
「特定のPCでのみ動かしたい」という要件に対し、ユーザーがOSの再インストールやフォーマットを行う可能性があるならば、FSOのシリアル番号のみに依存する設計は、保守フェーズにおいて「ライセンス失効」という名のトラブルを招く。しかし、「特定の暗号化ドライブや、特定の管理用パーティション内でのみ動作させたい」という用途であれば、FSOによるボリューム識別は、軽量かつ極めて強力な武器となる。
2. 実装における「極限の作法」：メモリとオブジェクトのライフサイクル
VBScriptはCOM（Component Object Model）のラッパーである。FSOのような重厚なオブジェクトを扱う際、多くの初級者が犯す最大の過ちは、オブジェクトの解放を怠ることだ。
特に、タスクスケジューラによって長時間稼働するバックグラウンドプロセスや、他のアプリケーションから呼び出されるコンポーネントとしてスクリプトを設計する場合、オブジェクトの明示的な破棄（`Set obj = Nothing`）を怠れば、メモリリークや、稀にプロセスがゾンビ化する原因となる。
以下に、実戦投入可能な「堅牢な実行ガード・テンプレート」を示す。
【実戦コード】環境識別による実行制御ロジック
' ==========================================================================
' Script Name: EnvironmentGuard.vbs
' Description: 特定のボリュームシリアル番号を持つ環境でのみ実行を許可する
' Author: Chief Architect
' ==========================================================================
Option Explicit
' 許可されたボリュームシリアル番号を定数として定義（実運用では外部ファイルやレジストリから取得を推奨）
Const ALLOWED_SERIAL = "1234-ABCD"
Const TARGET_DRIVE = "C:"
Dim objFSO, objDrive, currentSerial
' --------------------------------------------------------------------------
' メインルーチン
' --------------------------------------------------------------------------
Call Main()
Sub Main()
' 1. 環境チェックの実行
If Not IsEnvironmentValid(TARGET_DRIVE, ALLOWED_SERIAL) Then
' 異常検知時は標準エラー出力にメッセージを出し、終了コード 1 を返して即座に終了する
WScript.StdErr.WriteLine "[ERROR] Unauthorized Environment: Drive serial mismatch."
WScript.Quit 1
End If
' 2. 許可された環境でのみ、以下のビジネスロジックが実行される
WScript.StdOut.WriteLine "[INFO] Environment Verified. Starting mission-critical task..."
ExecuteBusinessLogic
End Sub
' --------------------------------------------------------------------------
' 環境検証関数
' --------------------------------------------------------------------------
Function IsEnvironmentValid(strDrive, strTargetSerial)
Dim objFSO, objDrive
Dim bResult
bResult = False
On Error Resume Next ' エラーハンドリングの開始（ドライブが存在しない等の例外対策）
' オブジェクトの生成
Set objFSO = CreateObject("Scripting.FileSystemObject")
' ドライブオブジェクトの取得
Set objDrive = objFSO.GetDrive(strDrive)
If Err.Number = 0 Then
' シリアル番号の照合（大文字小文字を区別しないよう比較）
If UCase(objDrive.SerialNumber) = UCase(strTargetSerial) Then
bResult = True
End If
Else
' ドライブが見つからない、あるいはアクセス権限がない場合
WScript.StdErr.WriteLine "[ERROR] Failed to access drive: " & strDrive & " (" & Err.Description & ")"
End If
' 【極めて重要】オブジェクトの明示的解放
' スコープを抜ける前に確実にメモリから解放する
Set objDrive = Nothing
Set objFSO = Nothing
On Error GoTo 0 ' エラーハンドリングを元に戻す
IsEnvironmentValid = bResult
End Function
' --------------------------------------------------------------------------
' ビジネスロジック（ここには本来の業務処理を記述する）
' --------------------------------------------------------------------------
Sub ExecuteBusinessLogic()
' ここに、機密性の高い、あるいは環境依存の強い処理を記述
WScript.StdOut.WriteLine "[SUCCESS] Process completed successfully."
End Sub3. アーキテクトの視点：システム間連携と堅牢性の向上
上記のコードは、単なる「if文による分岐」ではない。プロフェッショナルな設計として、以下の3点を担保している。
I. エラー・レジリエンス（回復力）
`On Error Resume Next` を使用しているが、これは「エラーを無視するため」ではなく、「エラーが発生した際に、オブジェクトの解放処理へ確実に到達させるため」である。ドライブが存在しない、あるいはネットワークドライブが切断されているといった状況下でスクリプトがクラッシュすることは、自動化システムにおいては致命的な欠陥だ。
II. 標準入出力（StdOut/StdErr）の分離
`WScript.StdOut` と `WScript.StdErr` を使い分けている。これは、このスクリプトを他のバッチファイルやPowerShell、あるいはC#で書かれた親プロセスから呼び出すことを想定している。
- Stdout: 正常な進捗、結果を出力。
- Stderr: エラーメッセージを出力。
これにより、呼び出し側のエンジニアは、終了コード（`WScript.Quit 1`）とエラー出力を見て、即座に異常を検知できる。
III. 最小権限と計算資源の最適化
`FileSystemObject` は非常に便利だが、全てのドライブ情報を走査するような実装は避けるべきだ。`GetDrive(strDrive)` を用いて、対象となるドライブのみをピンポイントで指定することで、I/O負荷を最小限に抑えている。
4. さらなる高みへ：WMIへの移行検討
もし、要件が「ボリュームの再フォーマットに耐えうる、物理的なハードウェア識別」へと進化した場合、エンジニアは `FileSystemObject` を捨て、WMI (Windows Management Instrumentation) へと舵を切らなければならない。
' WMIを用いた物理シリアル取得の概念例
Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_PhysicalMedia")
For Each objItem in colItems
' ここで物理的なシリアル番号にアクセス可能
' SerialNumber = objItem.SerialNumber
NextFSOは「手軽な論理制御」に、WMIは「厳格な物理制御」に適している。この使い分けこそが、レガシー環境を統べるアーキテクトの審美眼である。
結論
`Drive.SerialNumber` は、初心者にとっては単なる「番号取得のプロパティ」に過ぎないかもしれない。しかし、我々プロフェッショナルにとっては、システムの整合性を守り、予期せぬ環境での暴走を阻止するための、精密な「検問所」である。
オブジェクトのライフサイクルを制御し、エラーを予測し、標準入出力を設計する。この積み重ねが、単なる「スクリプト」を「信頼に足るシステム」へと昇華させるのである。
