【260文字制限の罠】Windowsの長尺パス（MAX_PATH）問題に対するFSOの限界と失敗しないパス設計
レガシーシステムの自動化や、深い階層に迷宮のように入り組んだファイルサーバーの巡回処理において、VBScriptの`Scripting.FileSystemObject`（以下、FSO）は諸刃の剣だ。
特に、いわゆる「260文字の壁（MAX_PATH制限）」に直面した瞬間、FSOは突如として容赦のないランタイムエラーを吐き、堅牢であるべきバッチ処理を死に至らしめる。
今回は、OSの深層とCOMコンポーネントの挙動を知り尽くしたアーキテクトの視点から、このMAX_PATH問題の正体と、現場で生き残るための実戦的防衛策を解き明かす。
—
なぜFSOは長尺パスの前で膝を屈するのか
WindowsカーネルのファイルAPIは歴史的経緯から、長らくMAX_PATH（260文字：ドライブ名や終端のNULL文字を含む）を基本設計の限界としてきた。
FSOはこのWin32 APIの薄いラッパーに過ぎないため、パス文字列が260文字を超過した瞬間、内部で呼び出している`FindFirstFile`や`CreateFile`などのAPIが失敗し、FSO側でトラップ不可能な例外（「パスが見つかりません」等）を発生させる。
さらに深刻なのは、近代のWindows（Windows 10 / Server 2016以降）で「レジストリやマニフェストで長尺パス（Long Paths）を有効化」していたとしても、FSO自体がこの拡張空間に対応しきれていないケースが多々あるという点だ。FSOに依存し続ける限り、いつか必ず地雷を踏む。
—
失敗しないパス設計の要諦：ShortPathプロパティの功罪
この制限を回避する古典的かつ現実的なアプローチの一つが、FSOの `File` または `Folder` オブジェクトが持つ `ShortPath` プロパティの活用だ。
`ShortPath` は、いわゆる8.3形式（DOS形式）のパス（例: `C:\PROGRA~1\…`)を返す。これにより、物理的な文字数を強制的に260文字以内に圧縮し、FSOのパースエラーを回避することが可能になる。
しかし、シニアエンジニアとして警告しておかねばならない。`ShortPath` の取得自体が、対象ファイルへの実アクセスを伴うため、数万ファイルを扱うバッチでは強烈なパフォーマンスのボトルネックになる。 さらに、OSの設定（NTFSのレジストリ `NtfsDisable8dot3NameCreation`）で8.3形式の生成が無効化されている環境では、このプロパティにアクセスした瞬間に別の例外が発生するというジレンマを抱えている。
—
実装コード：オブジェクトの明示的解放と堅牢なエラーハンドリング
では、極限の環境下でどのようにスクリプトを構築すべきか。
以下のコードは、メモリの肥大化を防ぐためにFSOインスタンスを適切に制御し、例外をスルーして処理を継続する防衛的コードのテンプレートである。
Option Explicit
‘ —————————————————————–
‘ 巨大階層走査スクリプト：MAX_PATH防衛モデル
‘ —————————————————————–
Sub TraverseFolder(ByVal strFolderPath)
Dim objFSO, objFolder, objSubFolder, objFile
Dim objShell, objShortPath
‘ FSOのインスタンス生成（ループ内での生成を避け、スコープを意識する）
Set objFSO = CreateObject(“Scripting.FileSystemObject”)
On Error Resume Next
Set objFolder = objFSO.GetFolder(strFolderPath)
‘ フォルダ取得に失敗した場合（MAX_PATH超過やアクセス権エラー）のフェイルセーフ
If Err.Number <> 0 Then
WScript.Echo “[WARNING] フォルダアクセス失敗スキップ: ” & Left(strFolderPath, 50) & “… (Error: ” & Err.Description & “)”
Err.Clear
On Error GoTo 0
Set objFSO = Nothing
Exit Sub
End If
On Error GoTo 0
‘ ファイル処理ループ
For Each objFile In objFolder.Files
On Error Resume Next
‘ ここで長尺パスに触れる可能性があるため個別にエラーハンドリング
Dim targetPath
targetPath = objFile.Path
If Err.Number <> 0 Then
‘ パスが長すぎる場合のショートパスフォールバック試行
‘ ※環境依存があるため、WMIやShellオブジェクトの活用も視野に入れる
targetPath = objFile.ShortPath
End If
‘ — 実処理をここに記述 —
‘ WScript.Echo targetPath
Err.Clear
On Error GoTo 0
Next
‘ 再帰的走査（サブフォルダ）
For Each objSubFolder In objFolder.SubFolders
TraverseFolder objSubFolder.Path
Next
‘ —————————————————————–
‘ メモリ最適化：COMオブジェクトの明示的解放
‘ VBScriptのガベージコレクションに頼らず、スコープ抜ける前に破棄する
‘ —————————————————————–
Set objFile = Nothing
Set objSubFolder = Nothing
Set objFolder = Nothing
Set objFSO = Nothing
End Sub
‘ 実行エントリーポイント
Call TraverseFolder(“C:\DeepPathTargetDirectory”)
—
チーフアーキテクトからの提言：FSOの限界を見極めよ
前述の通り、`ShortPath` にも環境依存の限界がある。真にこの問題に終止符を打ちたいのであれば、VBScript単体での解決に固執してはならない。
1. PowerShellへの移行: `.NET Framework` の `System.IO.DirectoryInfo` や `System.IO.FileInfo` をベースにしたスクリプトであれば、マニフェスト等と組み合わせることで長尺パス（`\\?\` プレフィックス空間）を完全にネイティブ制御できる。
2. WMI / ShellCOMの活用: FSOが音を上げるパスであっても、`Shell.Application` オブジェクト経由であれば、一部の制限をバイパスしてシェル空間のアイテム操作が可能な場合がある。
レガシーなVBScript資産を維持しつつ延命を図る場合でも、「FSOは260文字の境界線上で戦っている」というハードウェア・OS制約の共通認識をチーム全体で持ち、例外発生時のリスクヘッジ（スキップログの記録とアラート通知）をアーキテクチャレベルで組み込むことが、プロフェッショナルなシステム運用の絶対条件である。
