Visio VBAの深淵：大規模VSDXのPDF出力におけるメモリリークとの決別
業務自動化において、Visioは最も「扱いづらく、かつ強力」なツールの一つだ。特に数百ページに及ぶ図面ファイルを連続してPDF出力する際、多くのエンジニアが直面するのが「Visioプロセスの肥大化」と「メモリリークによるクラッシュ」である。
今回は、単にコードを動かすレベルではなく、「プロセスを死なせない」ためのリソース管理の極意を伝授する。
—
1. なぜVisioのメモリリークは防げないのか
Visio VBAで `Application` や `Document` を不用意に扱えば、バックグラウンドにゾンビプロセスが残る。これはCOMオブジェクトの参照カウントが適切にデクリメント（解放）されていないことが原因だ。
特に大規模PDF出力において犯しがちな過ちは以下の通り。
- グローバル変数の安易な利用: `Application` をモジュールレベルで保持し続けると、終了時にメモリが解放されない。
- ドキュメントの「閉じ忘れ」: `ActiveDocument.Close` を呼んでも、参照が残っていればメモリ上にオブジェクトが滞留する。
- イベントハンドラの残留: PDF出力完了を待つ際の `DoEvents` やループ処理が、Visioの描画エンジンを疲弊させる。
—
2. アーキテクトが教える「クリーンな破棄」の鉄則
メモリリークを防ぐための戦術は一つ。「関数内で生成し、関数内で確実に殺す」こと。これに尽きる。
堅牢なPDF出力の実装例
以下は、メモリをクリーンに保ちつつ、安定してPDFを生成するためのプロダクションコードだ。
Option Explicit
‘ 大規模処理用の堅牢なPDF出力メソッド
Public Sub ExportVisioToPdf(ByVal vsdxPath As String, ByVal pdfOutputPath As String)
Dim visApp As Visio.Application
Dim visDoc As Visio.Document
‘ 1. インスタンスの生成（新しく作成することで、既存のゴミと切り離す）
Set visApp = New Visio.Application
visApp.Visible = False ‘ バックグラウンドで静かに処理させる
visApp.AlertResponse = 7 ‘ ダイアログを表示させず、自動的に「No」で応答
On Error GoTo Cleanup
‘ 2. ドキュメントを開く（ReadOnly推奨：ロック回避）
Set visDoc = visApp.Documents.OpenEx(vsdxPath, visOpenRO + visOpenNoWorkspace)
‘ 3. PDFエクスポート実行
‘ PDF出力はVisioの重い処理の一つ。ここでメモリを消費する
visDoc.ExportAsFixedFormat visFixedFormatPDF, pdfOutputPath, visDocTypeDrawing, visSZOutputQualityPrint
Cleanup:
‘ 4. 徹底した解放プロセス（ここが最重要）
If Not visDoc Is Nothing Then
visDoc.Close
Set visDoc = Nothing
End If
If Not visApp Is Nothing Then
visApp.Quit
Set visApp = Nothing
End If
‘ エラーハンドリング
If Err.Number <> 0 Then
Debug.Print “Error ” & Err.Number & “: ” & Err.Description
End If
End Sub
—
3. なぜこの設計なのか：プロの思考
このコードには、現場で生き残るための3つの「意図」がある。
1. `visOpenRO` (Read Only) の指定:
大規模図面をサーバーから開く際、読み取り専用で開かないと、Visioは一時ファイル（ロックファイル）を生成し、これが連続処理においてファイルシステム上のオーバーヘッドになる。読み取り専用こそが正義だ。
2. `visApp.AlertResponse = 7`:
自動化において「ユーザーの操作待ち」は最大の敵だ。エラー時にダイアログが裏で止まると、プロセスが永久に終了せず、メモリが解放されないまま溜まっていく。これを防ぐ。
3. インスタンスの使い回し禁止:
「1つのアプリケーションインスタンスで複数のファイルを開いては閉じる」のは、Visioのメモリ管理においては自殺行為だ。「1ファイル処理ごとにプロセスを再起動する」。これが最も確実で、現代のPCリソースであれば十分に高速なアプローチである。
—
4. さらに上を目指すエンジニアへ：プロセス監視の視点
もし、数百ファイルという単位で処理を回すなら、VBAだけでは力不足だ。VBAを呼び出す側の親プロセス（VB.NETやPowerShell）で、VisioのプロセスIDを監視することをお勧めする。
- 処理開始前に `Get-Process` でVisioのPIDをメモする。
- 処理終了後に、そのPIDがゾンビ化していないか確認し、`process.Kill()` を投げる。
ここまでやって初めて「業務自動化エンジニア」と名乗れる。Visioはレガシーなツールだが、その特性を理解し、いなすことができれば、これほど強力なドキュメントオートメーションの相棒は他に存在しない。
コードをコピペして満足するな。その裏で動く「メモリのライフサイクル」をイメージせよ。それが、システムを止めない唯一の道だ。
