Visio VBAの世界で長きにわたりシステムを構築し、数多のメモリリークと戦ってきた諸兄に、今回は大規模図面のPDF出力における根源的な問題と、それを克服するための『極限の知見』を提示する。一般的な`Set obj = Nothing`だけでは決して解決し得ない、Visio COMオブジェクトの深淵に迫る。
—
Visio VBAの深淵：大規模PDF出力におけるメモリリークの闇を断つ
Visio VBAを用いた自動化は、かつて多くの企業で業務効率化の要とされてきた。特に大量の図面をプログラムで生成し、PDFとして出力するバッチ処理は、今もなお多くのレガシーシステムで稼働していることだろう。しかし、大量のページや複雑な図形を含むVisio図面を処理する際、多くのエンジニアが直面するのが「メモリリーク」という名の、底なし沼のような問題である。
なぜ、オブジェクトを`Nothing`に設定してもメモリが解放されないのか？ なぜ、Visioアプリケーションプロセスは肥大化し、最終的にシステムをクラッシュさせるのか？ その問いに対する答えは、COMオブジェクトのライフサイクル管理の複雑さ、VBAの言語仕様、そしてVisioアプリケーション自体のアーキテクチャに深く根差している。
本稿では、単なる表面的なオブジェクト解放に留まらず、Visioプロセスを安定稼働させるための本質的なメモリ管理術、そして必要とあらばWindows APIをも駆使する、シニアエンジニア向けの戦略を解説する。
1. Visio COMオブジェクトのライフサイクルとVBAの限界
VBAからVisioのオブジェクト（`Application`, `Document`, `Page`, `Shape`など）を操作する際、我々はCOM（Component Object Model）インターフェースを介してVisioプロセス内のオブジェクトを参照している。COMの基本は参照カウントであり、各オブジェクトがどれだけの参照元から参照されているかを内部的に管理している。参照カウントがゼロになれば、そのオブジェクトは解放されるはず、というのがCOMの建前だ。
しかし、VBA環境下ではこの参照カウントが期待通りに機能しない場面が多々ある。
- 循環参照: オブジェクトAがBを参照し、BがAを参照するようなケース。参照カウントがゼロにならず、メモリ上に残存する。
- VBAのガベージコレクションの非力さ: VBA自身には強力なガベージコレクタが存在しない。`Set obj = Nothing`は参照カウントを減らす指示ではあるが、即座の解放を保証するものではない。特に、Visioアプリケーション内部でキャッシュされているオブジェクトや、イベントハンドラが設定されたオブジェクトなどは、VBA側で`Nothing`にしてもVisioプロセスが参照を持ち続けることがある。
- Visioアプリケーション自体の永続性: `Visio.Application`オブジェクトは、一度起動すると様々な内部リソース（UI情報、Undoスタック、クリップボード、図面キャッシュ、アドオン情報など）を抱え込む。たとえ開いた`Document`を閉じ、`Application`オブジェクトを`Nothing`にしても、Visioプロセスそのものが完全にクリーンな状態に戻るとは限らない。特に、UIが表示されている状態で操作を行った場合、この傾向は顕著だ。
これらの特性を理解せず、漫然とオブジェクトを解放しているだけでは、大規模なバッチ処理において必ずメモリリークに遭遇する。
2. 大規模図面処理におけるメモリリークのメカニズム
大量のページを持つ図面を処理する際、Visioは各ページの図形データだけでなく、レイアウト情報、スタイル、マスターシェイプへの参照など、膨大な情報をメモリ上に展開する。
例えば、100ページある図面を処理する場合を考えてみよう。
‘ 擬似コード
Dim app As Visio.Application
Dim doc As Visio.Document
Dim page As Visio.Page
Set app = New Visio.Application
Set doc = app.Documents.Open(“C:\path\to\large_drawing.vsdx”)
For Each page In doc.Pages
‘ ここでページに対する複雑な操作や、PDF出力処理を行う
‘ 例えば、Page.ExportAsFixedFormat …
Next page
‘ 一般的な解放処理
Set page = Nothing
Set doc = Nothing
Set app = Nothing
このコードのどこに問題があるのか？ `For Each`ループの内部で`page`オブジェクトが次々に参照され、ループを抜けた後で`Set page = Nothing`としても、`doc.Pages`コレクションそのものが保持する参照が残存する可能性がある。さらに、`ExportAsFixedFormat`メソッドは、内部的に一時ファイルを作成したり、Visioプロセス内でPDF変換エンジンを起動したりするため、それらのリソースが適切に解放されないと、Visioプロセスのメモリフットプリントは増大の一途を辿る。
特に、以下の要素がメモリリークを加速させる。
- 複雑な図形: 大量の頂点を持つ図形、多数のグループ化された図形、OLEオブジェクトの埋め込み。
- マスターシェイプの多用: マスターシェイプは効率的だが、大量のマスターを参照している場合、それらのキャッシュが肥大化する。
- イベントハンドラの残留: 図面やページ、図形にイベントハンドラを設定した場合、解放時に明示的に解除しないと参照が残りやすい。
- Undoスタック: VisioはデフォルトでUndo操作のための履歴をメモリに保持する。プログラム的に操作しても、この履歴が蓄積されることがある。
3. 【上級者向け】メモリリークを防ぐオブジェクト解放テクニック
ここからが本題だ。単なる`Set obj = Nothing`を超えた、より確実な解放戦略を提示する。
3.1. 厳格な解放順序と多重解放
オブジェクトは「最も内側の参照」から「外側」へと順序立てて解放する。そして、必要であれば、複数回`Nothing`を設定することも厭わない。これはCOMの参照カウントがVBAから見えにくいことへの対症療法だが、実効性がある。
Public Sub ExportLargeVisioDocumentToPdfStrict(ByVal filePath As String, ByVal outputPath As String)
Dim app As Visio.Application
Dim doc As Visio.Document
Dim page As Visio.Page
Dim pagesToProcess As Collection ‘ ページコレクションを別途保持
Dim i As Long
On Error GoTo ErrorHandler
‘ 既存のVisioインスタンスがあれば利用、なければ新規作成
‘ 通常はバッチ処理なのでNewで新規作成し、プロセス分離を徹底する
Set app = New Visio.Application
app.Visible = False ‘ UIを非表示にすることで、Visioの内部リソース消費を抑える
Set doc = app.Documents.Open(filePath)
‘ Undoスタックをクリアし、メモリ消費を抑える
‘ これにより、誤操作によるリカバリは効かなくなるが、バッチ処理では有効
app.Documents.Item(doc.Name).UndoManager.Clear
‘ ページコレクションを一度別のCollectionオブジェクトにコピーする
‘ これにより、doc.Pagesコレクションの参照を直接操作するのを避ける
Set pagesToProcess = New Collection
For Each page In doc.Pages
pagesToProcess.Add page
Next page
For i = 1 To pagesToProcess.Count
Set page = pagesToProcess.Item(i)
Debug.Print “Processing page: ” & page.Name
‘ PDF出力パラメータの最適化
‘ – visFixedFormatIntentPrint: 印刷品質を優先。ファイルサイズが大きくなる傾向
‘ – visFixedFormatIntentScreen: 画面表示品質を優先。ファイルサイズが小さくなる傾向
‘ – visFixedFormatIncludeHiddenInfo: 非表示情報をPDFに含めるか (通常はFalseでメモリ節約)
‘ – visFixedFormatIncludeComments: コメントを含めるか
‘ – visFixedFormatIncludeDocumentProperties: ドキュメントプロパティを含めるか
‘ 必要に応じて適切なパラメータを選択する
page.ExportAsFixedFormat _
FixedFormatType:=visFixedFormatTypePDF, _
OutputFileName:=outputPath & “_” & page.Name & “.pdf”, _
Intent:=visFixedFormatIntentScreen, _
IncludeHiddenInfo:=False, _
IncludeComments:=False, _
IncludeDocumentProperties:=False
‘ 各ページの処理後、すぐに解放を試みる
Set page = Nothing ‘ 複数回 Nothing を設定する
Set page = Nothing
Next i
‘ コピーしたコレクションも解放
Set pagesToProcess = Nothing
‘ ドキュメントのクローズと解放
If Not doc Is Nothing Then
doc.Close
Set doc = Nothing ‘ 複数回 Nothing を設定
Set doc = Nothing
End If
‘ アプリケーションのクローズと解放
If Not app Is Nothing Then
app.Quit
Set app = Nothing ‘ 複数回 Nothing を設定
Set app = Nothing
End If
Exit Sub
ErrorHandler:
Debug.Print “Error ” & Err.Number & “: ” & Err.Description
‘ エラー時も可能な限りクリーンアップを試みる
On Error Resume Next ‘ クリーンアップ中のエラーは無視
If Not page Is Nothing Then Set page = Nothing
If Not doc Is Nothing Then
doc.Close
Set doc = Nothing
End If
If Not app Is Nothing Then
app.Quit
Set app = Nothing
End If
On Error GoTo 0 ‘ エラーハンドラをリセット
End Sub
このコードでは、以下の点を強化している。
- `pagesToProcess`コレクションによる間接参照: `doc.Pages`コレクションは、`doc`オブジェクトが解放されるまで強く参照を保持しがちだ。一度別の`Collection`オブジェクトにコピーすることで、`doc.Pages`からの参照を切り離し、個々の`page`オブジェクトの解放を促す。
- `app.Visible = False`: VisioのUIは多くのリソースを消費する。バッチ処理では必ず非表示に設定する。
- `app.Documents.Item(doc.Name).UndoManager.Clear`: Undoスタックは大きなメモリを消費する。不要であればクリアすることでメモリを節約できる。
- `page.ExportAsFixedFormat`の最適化: PDF出力時のパラメータを調整し、不要な情報の出力を避けることで、Visio内部での処理負荷とPDFファイルのサイズを抑制する。`Intent`は特に重要で、`visFixedFormatIntentScreen`はファイルサイズを小さくする傾向がある。
- 多重`Set Nothing`: 気休めのように見えるかもしれないが、COM参照カウントの挙動が不透明なVBAにおいては、複数回`Nothing`を設定することで、より確実に参照カウントを減らす効果が期待できる。
3.2. Visioアプリケーションプロセスの強制終了と再起動（最終手段）
上記のような厳格な解放を行っても、長時間のバッチ処理や、極めて複雑な図面を繰り返し処理する場合には、Visioプロセスが徐々にメモリを肥大化させることがある。これはVisioの内部キャッシュや、OSレベルでのリソース解放の遅延、あるいは特定のCOMコンポーネントのバグに起因する場合がある。
このような状況では、もはやVBAの範疇を超え、Visioアプリケーションプロセス自体を強制的に終了させ、再起動するという、荒療治が有効となる。これはシステム全体の安定性を確保するための「最終手段」であり、プロセスが強制終了されることで、未保存のデータが失われたり、OSが一時的に不安定になったりするリスクを伴うため、十分なテストと、適切なエラーハンドリングが必須である。
VBAから直接プロセスを強制終了させるのは困難だが、Windows APIを呼び出すか、外部のスクリプト（PowerShellやVB.NET実行ファイルなど）を呼び出すことで実現できる。
VB.NET (C#) によるVisioプロセスの安全な終了例:
VB.NETやC#で独立したプロセス制御ユーティリティを作成し、VBAから`Shell`関数で呼び出すのが最も堅牢な方法だ。`System.Diagnostics.Process`クラスは、プロセスの検索と終了を安全に行うための強力な機能を提供する。
.net
‘ Visual Basic .NET (.vb)
‘ VisioProcessKiller.vb
Imports System.Diagnostics
Imports System.Runtime.InteropServices
Public Module VisioProcessKiller
Sub Main()
Dim visioProcesses() As Process = Process.GetProcessesByName(“VISIO”)
If visioProcesses.Length = 0 Then
Console.WriteLine(“Visio processes not found.”)
Return
End If
For Each p As Process In visioProcesses
Try
If p.MainWindowHandle <> IntPtr.Zero Then ‘ UIを持つプロセスか確認 (通常は非表示で実行されるため、MainWindowHandleはZeroになることが多い)
Console.WriteLine($”Terminating Visio process (PID: {p.Id}, Title: {p.MainWindowTitle})…”)
Else
Console.WriteLine($”Terminating Visio process (PID: {p.Id}, no window)…”)
End If
p.Kill() ‘ プロセスを強制終了
p.WaitForExit(5000) ‘ 5秒間待機
Console.WriteLine($”Process {p.Id} terminated.”)
Catch ex As Exception
Console.WriteLine($”Error terminating process {p.Id}: {ex.Message}”)
End Try
Next
Console.WriteLine(“Visio process termination complete.”)
End Sub
End Module
このVB.NETコードをコンパイルし、`VisioProcessKiller.exe`として配置する。VBAからは、以下のように呼び出す。
‘ VBA
Public Sub CallVisioProcessKiller()
Dim result As Long
‘ 実行可能ファイルのパスを適切に設定する
Const VISIO_KILLER_PATH As String = “C:\Path\To\Your\VisioProcessKiller.exe”
Debug.Print “Attempting to terminate Visio processes…”
result = Shell(VISIO_KILLER_PATH, vbHide) ‘ vbHideでコマンドプロンプトを非表示にする
If result = 0 Then
Debug.Print “Failed to start VisioProcessKiller.exe. Check path and permissions.”
Else
Debug.Print “VisioProcessKiller.exe started. PID: ” & result
‘ プロセスが終了するまで待機する場合は、Sleepなどを利用するか、
‘ VisioProcessKiller側で終了コードを返すように実装を拡張する
Application.Wait Now + TimeValue(“00:00:05”) ‘ 5秒間待機（簡易的な例）
End If
Debug.Print “Visio processes should be terminated.”
End Sub
このアプローチは、VBAの単一プロセス内での限界を突破し、システムレベルでの制御を可能にする。大規模なバッチ処理で数時間、あるいは数日間にわたってVisioインスタンスを使い回す必要がある場合、一定の処理サイクル（例: 100図面処理後、または1時間経過後）ごとにVisioプロセスを終了させ、再起動する戦略が有効だ。
3.3. Windows APIによるプロセスID取得（VBAから）
VBAから直接`TerminateProcess`を呼び出すのは非常にリスキーであり、COMオブジェクトの整合性を破壊する可能性が高いため推奨しない。しかし、プロセスIDを取得し、その情報をログに残すなどの用途ではAPIを利用するケースがある。
‘ VBA Module
Private Declare PtrSafe Function GetWindowThreadProcessId Lib “user32” (ByVal hwnd As LongPtr, lpdwProcessId As Long) As Long
Private Declare PtrSafe Function FindWindow Lib “user32” Alias “FindWindowA” (ByVal lpClassName As String, ByVal lpWindowName As String) As LongPtr
Public Function GetVisioProcessId(ByVal app As Visio.Application) As Long
Dim hwnd As LongPtr
Dim processId As Long
‘ Visio Applicationオブジェクトのウィンドウハンドルを取得（Visible=Trueの場合に有効）
‘ Visible=Falseの場合、MainWindowHandleがZeroになるため、この方法では取得できないことが多い
‘ その場合は、Task Managerでプロセスを特定するか、GetProcessesByNameを使うしかない
On Error Resume Next
hwnd = app.Window.Parent.hwnd ‘ Application Windowのハンドル
On Error GoTo 0
If hwnd <> 0 Then
Call GetWindowThreadProcessId(hwnd, processId)
GetVisioProcessId = processId
Else
‘ Visioが非表示の場合、この方法は機能しないため、0を返す
GetVisioProcessId = 0
End If
End Function
‘ 使用例
Public Sub TestGetVisioPid()
Dim app As Visio.Application
Dim pid As Long
Set app = New Visio.Application
app.Visible = True ‘ テストのため表示
pid = GetVisioProcessId(app)
If pid <> 0 Then
Debug.Print “Visio Application PID: ” & pid
Else
Debug.Print “Could not get Visio PID (Visio might be hidden or not fully initialized).”
End If
app.Quit
Set app = Nothing
End Sub
このAPIは、VisioがUIを持つ場合にのみ有効な場合が多い。バッチ処理で`app.Visible = False`としている場合は、上記の`VisioProcessKiller.exe`のような外部プロセスからの制御が不可欠となる。
4. レガシー環境とシステム連携の知見
長年稼働しているVisio VBAシステムにおいては、単にコードを修正するだけでなく、システム全体のアーキテクチャや運用を考慮する必要がある。
- COMスレッドモデルの理解: VisioのCOMオブジェクトは通常STA (Single-Threaded Apartment) モデルで動作する。マルチスレッド環境からVisioを操作しようとすると、`CoInitializeEx`の呼び出しやマーシャリングの複雑さに直面する。VBAは基本的にSTAで動作するため問題になりにくいが、VB.NETやC#でマルチスレッドアプリケーションからVisioを制御する場合は注意が必要だ。
- 権限とセキュリティ: サーバーサイドでVisioを自動実行する場合、DCOM設定やサービスアカウントの権限に起因する問題が発生しやすい。VisioプロセスがPDF変換エンジンや一時ファイルへのアクセス権を持たない場合、エラーとなる。
- 外部サービスとの連携: Visio VBAは、ActiveX Data Objects (ADO) を介してデータベースと連携したり、XMLHTTPRequestオブジェクトでWebサービスと連携したりすることがある。これらの外部リソースもまた、適切に解放しなければメモリリークやハンドルリークの原因となる。
- ログと監視: 大規模なバッチ処理システムでは、処理の進捗、メモリ使用量、エラー情報を詳細にログに残すことが不可欠だ。Windowsのイベントログ、カスタムログファイル、またはパフォーマンスモニター（`perfmon`）を定期的にチェックし、異常なメモリ消費パターンを早期に発見する。
5. 結論：完璧な解放は幻想、安定性追求が真髄
Visio VBAにおけるメモリリーク対策は、時に泥臭い戦いとなる。完璧なオブジェクト解放は幻想であり、Visioプロセスそのものが抱え込むリソースの特性を理解し、その上で「いかにしてシステム全体の安定性を維持するか」という視点を持つことが重要だ。
厳格なオブジェクト解放、PDF出力パラメータの最適化、そして最終手段としてのプロセス強制終了と再起動。これらのテクニックを組み合わせることで、大規模なVisio図面処理においても、システムの安定稼なく、かつ効率的なPDF出力を実現できるだろう。
VBAというレガシー技術の最前線に立つ者として、私たちは常にその限界を理解し、必要とあらば外部の強力なツールやWindows APIを躊躇なく活用する知見が求められる。これこそが、長年培ってきた経験から導き出された『極限の知見』である。
