Visio VBAの死角：なぜあなたのプロセスは「ゾンビ」化するのか
Visioのオートメーションを開発していると、必ず直面する壁がある。VBAコードの実行は正常に終わったはずなのに、タスクマネージャーを開くと `VISIO.EXE` が居座り続けている。あるいは、2回目の実行時に「サーバーで例外が発生しました」という無慈悲なエラーを突きつけられる。
これは単なるバグではない。Visioのオブジェクトモデルが抱える「参照カウントの呪縛」を無視した結果だ。
本稿では、レガシーシステムを支え続けてきたアーキテクトの視点から、Visioにおけるオブジェクトのライフサイクル管理、そして「Nothing」という名の儀式がいかにシステムの命運を分けるかを説く。
—
1. Visioが終了できない理由：循環参照の罠
Visioのオブジェクトモデル（`Application` -> `Document` -> `Page` -> `Shape`）は、COM（Component Object Model）という古い、しかし強固な構造の上に成り立っている。
VBAで `Set shp = ActivePage.Shapes(1)` と書くとき、内部では「参照カウント」がインクリメントされる。コードが終了しても、この参照が適切に解除されていない場合、COMサーバーは「まだどこかから参照されている」と判断し、メモリからアンロードされない。これがプロセスが死なない原因だ。
特によくあるのが、「ドット演算子の連鎖」による隠れた参照だ。
‘ 【悪しき例】
‘ ActiveDocument.Pages(1).Shapes(1).Text = “Test”
‘ これを実行すると、明示的に取得していないDocumentやPageの参照が
‘ メモリ上に宙ぶらりんで残るリスクがある。
—
2. 鉄則：オブジェクトの「階層的解放」
メモリリークを完璧に防ぐための唯一の道は、「取得した順序とは逆の順序で、明示的にNothingを代入する」ことだ。これを怠る開発者は、どれほどコードが美しくてもプロとは呼べない。
実践：安全なリソース開放パターン
Public Sub SafeVisioOperation()
Dim appVisio As Visio.Application
Dim doc As Visio.Document
Dim pg As Visio.Page
Dim shp As Visio.Shape
‘ Visioインスタンスの取得（CreateObject推奨）
Set appVisio = New Visio.Application
Set doc = appVisio.Documents.Add(“”)
Set pg = doc.Pages(1)
Set shp = pg.DrawRectangle(0, 0, 1, 1)
‘ — ここで業務処理 —
shp.Text = “Architect”
‘ — 【重要】解放処理：生成と逆順にNothingを代入 —
‘ オブジェクトの参照を断ち切り、COMの参照カウントを減らす
Set shp = Nothing
Set pg = Nothing
If Not doc Is Nothing Then
doc.Close
Set doc = Nothing
End If
If Not appVisio Is Nothing Then
appVisio.Quit
Set appVisio = Nothing
End If
End Sub
—
3. シニアエンジニアが意識すべき「Windows API」との連動
大規模なシステム連携を行う際、VBAだけで完結しないケースが出てくる。例えば、外部プロセスからVisioウィンドウを制御したり、メモリ状況を監視する場合だ。
もし複雑な処理でVisioが固まった場合、`TaskKill`コマンドを叩くのは最終手段だ。まずは `FindWindow` APIを使用して、特定のウィンドウハンドルを確実に特定し、メッセージループを強制終了させる手法を検討すべきだ。
If VBA7 Then
Private Declare PtrSafe Function FindWindow Lib “user32” Alias “FindWindowA” (ByVal lpClassName As String, ByVal lpWindowName As String) As LongPtr
Else
Private Declare Function FindWindow Lib “user32” Alias “FindWindowA” (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
End If
このように、VBAの裏側にあるWin32 APIの知識があれば、システム管理者が頭を抱える「ゾンビプロセス」の完全自動駆除も、管理コンソールから制御可能になる。
—
4. アーキテクトからの提言：クリーンなコードは「型」から
初心者は `Object` 型や `Variant` 型を多用しがちだが、それはメモリ管理を放棄するに等しい。Visio VBAでは、必ず具体的なクラス型を宣言せよ。
1. 早期バインディング（Early Binding）を徹底せよ: 参照設定（Microsoft Visio XX.0 Type Library）を行い、型を明確にする。これにより、参照カウントの制御が確実になり、IntelliSenseによる恩恵で開発効率も飛躍的に向上する。
2. エラーハンドリングの徹底: 予期せぬエラーで処理が中断された場合、`Nothing` 代入処理がスキップされる。`On Error GoTo Cleanup` を使用し、必ず `Cleanup` ラベル内で全オブジェクトを `Nothing` にする構造を強制せよ。
結びに代えて
Visio VBAは「古い技術」ではない。「完成された枯れた技術」であり、正しく扱えばこれほど堅牢な業務自動化ツールはない。
「Nothing」を代入する行為は、単なるおまじないではない。それは、あなたが作り上げたシステムが、システムの安定性を尊重し、リソースを適切に管理しているという「エンジニアとしての矜持」の表明だ。
もしあなたのVisioが今もタスクマネージャーに居座っているなら、それはあなたのコードが「別れを告げる方法」を知らないからだ。今すぐそのプロセスを解放せよ。それが、真のプロフェッショナルのコードである。
