【深層階層の呪縛】VBScriptでMAX_PATHの壁を粉砕する：\?\プレフィックスの極意
諸君、レガシーシステムの墓場で「パスが長すぎます」というエラーに頭を抱える日々を過ごしていないか。
Windows APIの歴史的遺産である`MAX_PATH`（260文字制限）。現代のWindows 10/11ではレジストリ設定で緩和可能だが、保守を任された我々が触れる現場には、そんな甘い環境は存在しない。システム管理者やエンジニアとして、環境依存のレジストリ変更に頼らず、コードの力だけで深層階層を制圧する技術こそが、真の自動化の矜持だ。
今日は、VBScriptにおける「`\\?\` UNCプレフィックス」を用いた回避策と、その先にあるメモリ管理の深淵について解説する。
—
1. MAX_PATH制限の正体と回避のメカニズム
Windowsのファイル操作API（`CreateFile`等）は、内部的に`MAX_PATH`を基準としたバッファを確保する。この制限を物理的に突破する唯一の鍵が、パスの先頭に付与する特殊なプレフィックスだ。
- `\\?\` (Long Path Prefix): Windows APIに対して「これ以降は絶対パスとして扱い、解析をスキップせよ」と命令するフラグだ。これを通すことで、最大32,767文字までのパスを扱えるようになる。
注意点:
- 相対パスは使用不可。必ず絶対パスを渡すこと。
- UNCパス（ネットワークドライブ）の場合は `\\?\UNC\server\share\…` と記述する必要がある。
—
2. VBScriptによる実装：FileSystemObjectの限界と突破
ご存知の通り、VBScriptの標準オブジェクトである`Scripting.FileSystemObject`（FSO）は、この`\\?\`プレフィックスを解釈できない場合がある（特に古いOS環境や内部のAPIラッパーが古い場合）。
FSOで失敗する場合、我々はShell.Applicationや、より原始的なWScript.Shellのコマンドライン呼び出し、あるいは`ADODB.Stream`を駆使したバイナリ操作に切り替える必要がある。
実践コード：\?\ を用いたファイル操作（Shellオブジェクト経由）
‘ 深層階層のファイルを物理的に削除、あるいはコピーする際の極限アプローチ
‘ FSOがエラーを吐く場合、Shellオブジェクトで名前空間を操作する
Option Explicit
Dim objShell, strLongPath, strPrefixPath
Set objShell = CreateObject(“Shell.Application”)
‘ 対象の深層パス（例：260文字超のフォルダ）
strLongPath = “C:\Very\Deep\Folder\…\TargetFile.txt”
‘ \\?\ プレフィックスを強制付与
strPrefixPath = “\\?\” & strLongPath
‘ 警告：この操作はゴミ箱を経由しない可能性があるため注意が必要
‘ FSOのMoveやDeleteが失敗する場合、WScript.ShellでCMDを叩くのが最も確実
Dim objWshShell
Set objWshShell = CreateObject(“WScript.Shell”)
‘ CMDのDELコマンドはプレフィックスを正しく解釈する
‘ /F:読み取り専用解除 /Q:確認なし
objWshShell.Run “cmd /c del /F /Q “”” & strPrefixPath & “”””, 0, True
‘ — メモリの明示的解放：オブジェクトのライフサイクルを制御せよ —
Set objWshShell = Nothing
Set objShell = Nothing
—
3. チーフアーキテクトからの助言：メモリとパフォーマンスの設計
VBScriptはガベージコレクションを搭載しているが、それは「いつか消える」という楽観的な期待に過ぎない。特に大量のファイルを再帰的に走査するバッチ処理において、`Set = Nothing`を怠ることはメモリリークを招き、システム全体を緩慢な死へと導く。
- 再帰呼び出しを避ける: 深い階層の処理では、再帰関数よりもスタックを使ったイテレータを推奨する。スタックオーバーフローのリスクを回避し、メモリを定数的に消費させろ。
- オブジェクトのスコープ: ループ内でオブジェクトを生成し続けるな。可能な限りループの外で定義し、ループ内ではプロパティの更新のみを行うこと。
- API直叩きの誘惑を捨てろ: `WScript.Shell`で外部プロセスを叩くのは非効率に見えるが、レガシー環境の「文字化け」や「パス制限」を確実に突破する最終手段だ。パフォーマンスを気にするなら、処理対象のパスリストをテキストファイルへ一時出力し、それをバッチ処理で一括処理するパイプラインアーキテクチャを組むのが正解だ。
—
結論
`MAX_PATH`は、現代のストレージアーキテクチャから見れば化石のような制限だ。しかし、この制限を理解し、`\\?\`を使いこなすことは、Windowsの低レベルな挙動を理解しているという証明に他ならない。
技術とは、単に便利なライブラリを使うことではない。「OSが何を求めているのか」を理解し、その制約の裏側を突くことだ。
今日から君たちのコードが、どんなに深い階層のファイルであっても、何食わぬ顔で処理を完遂することを期待している。健闘を祈る。
