Visio VBAの死角：VSDXの「見えない残滓」を排除し、メモリ枯渇からシステムを救う極限の作法
業務自動化において、Visioは最も「厄介な隣人」だ。
特にVSDXを大量に扱うバッチ処理において、メモリリークやGhost Process（ゾンビ化したVisioプロセス）に頭を悩ませた経験はないだろうか？
多くの開発者は、`Document.Close` を呼べば事足りると信じている。だが、それは甘美な幻想だ。Visioのオブジェクトは、COMの参照カウントと内部のXML DOM構造が複雑に絡み合っており、単に閉じるだけではメモリ空間に「負の遺産」が蓄積される。
本稿では、数千枚の図面を連続処理してもシステムを停止させない、Visio VBAのメモリ管理の極意を伝授する。
—
1. なぜ `Document.Close` だけでは不十分なのか
Visioにおいて `Document.Close` を呼び出す際、デフォルトの挙動に身を任せてはいけない。特に重要なのは、「保存の確認」や「不要なイベントの発生」を完全に抑制することだ。
連続処理において、以下の2つの罠がシステムを崩壊させる。
1. Savedフラグの不一致: Visioが「変更があった」と誤認し、バックグラウンドで不要なダイアログを待機させる（UIスレッドのスタック）。
2. イベントハンドラの残留: 図面を閉じても `Document` オブジェクトの参照が生きている限り、メモリは解放されない。
2. メモリを解放する「強制破棄」のベストプラクティス
以下のコードは、Documentを確実に破棄し、プロセスをクリーンに保つための定石である。
‘ @brief VSDXを保存せず、かつメモリから完全に解放する極限のルーチン
Public Sub ForceCloseDocument(ByRef doc As Visio.Document)
If doc Is Nothing Then Exit Sub
‘ 1. イベント抑止：閉じ際の無駄な更新チェックを停止
Application.EventsEnabled = False
‘ 2. 変更フラグを強制的に「保存済み」に偽装
‘ これにより、Closeメソッドでの警告ダイアログや保存処理を回避する
doc.Saved = True
‘ 3. Closeメソッドの引数指定
‘ visSaveChangesNo を明示することで、物理的な上書きを確実に防ぐ
doc.Close
‘ 4. オブジェクトの明示的破棄
‘ VBAの参照カウントを確実にゼロにする
Set doc = Nothing
‘ 5. イベント再開
Application.EventsEnabled = True
‘ 6. ガベージコレクションの誘発（必要に応じて）
‘ 大規模処理の区切りでは、OSレベルでの解放を促す
DoEvents
End Sub
3. システム管理者への提言：ゾンビプロセスを消す力
もし、処理の途中で予期せぬエラーが発生し、Visioプロセスがタスクマネージャーに居座り始めたらどうするか。`Application.Quit` も届かない状況では、Windows APIを叩くしかない。
以下は、プロセスIDを特定して強制終了する、システム保守の最終手段である。
‘ Win32 APIを使用してVisioプロセスを強制終了する
If VBA7 Then
Private Declare PtrSafe Function TerminateProcess Lib “kernel32” (ByVal hProcess As LongPtr, ByVal uExitCode As Long) As Long
Else
Private Declare Function TerminateProcess Lib “kernel32” (ByVal hProcess As Long, ByVal uExitCode As Long) As Long
End If
‘ ※注：この手法は最終手段である。
‘ 通常は Application.Quit を正しく呼び出し、その後で
‘ Set visApp = Nothing を実行するライフサイクル管理を徹底すること。
4. アーキテクトの視点：なぜ「連続処理」でフリーズするのか
VSDXファイルは本質的にZIP圧縮されたXMLの集合体だ。`Document.Open` を繰り返すたびに、Visioの描画エンジン（`visio.exe`）は内部キャッシュを肥大化させる。
これを防ぐためのアーキテクチャ上の鉄則は以下の3点だ。
- Applicationの再利用: `Application` オブジェクトをループ内で何度も `CreateObject` してはならない。1つのプロセスを使い回し、ドキュメントのみを入れ替えるのが最短経路だ。
- DoEventsの適切な配置: 連続処理の100回に1回程度 `DoEvents` を挟むことで、Windowsメッセージキューの溢れを防ぐ。
- PDF出力後の即時Close: PDF出力（`ExportAsFixedFormat`）直後に `ForceCloseDocument` を実行すること。PDF出力は非常にメモリを食うため、放置は自殺行為である。
結び：技術は細部に宿る
高度な自動化とは、派手な機能の実装ではない。「いかにしてメモリを汚さず、処理を淡々と完遂させるか」という、徹底的なリソース管理の積み重ねに他ならない。
Visioという、一見レガシーなツールであっても、その内部挙動を深く理解し、制御下に置くことができれば、それは強力な自動化エンジンへと姿を変える。今日紹介した「破棄の作法」をコードに組み込み、あなたのシステムが二度とメモリ枯渇で悲鳴を上げないことを願う。
―― さあ、コードを書け。ただし、細部までこだわり抜いて。
