Visio VBAの死角：なぜあなたのコードは「重く」なり、やがてVisioを殺すのか
Visio VBAで業務自動化ツールを組んでいると、必ず直面する壁がある。開発当初はサクサク動いていたはずのツールが、なぜか数日間稼働させ続けるとVisioの挙動が重くなり、最終的には「メモリ不足」や「予期せぬクラッシュ」を引き起こす現象だ。
多くの初学者は「コードが悪い」と考えるが、真の問題は「オブジェクトのライフサイクルに対する無頓着さ」にある。Visioのオブジェクトモデルは非常に強力だが、同時にリソース消費に対して非常にシビアだ。
今日は、伝説的なアーキテクトの視点から、Visio VBAを「堅牢なシステム」へと昇華させるためのメモリ管理作法を伝授する。
—
1. なぜ「Nothing」を代入しなければならないのか
VBAにおけるオブジェクト変数は、実体（インスタンス）への「ポインタ」に過ぎない。`Set shp = ActivePage.Shapes(1)` と書いたとき、変数`shp`はメモリ上の特定の領域を指し示す。
プロシージャが終了すればローカル変数は解放される……というのは理想論だ。実際には、VisioのCOMオブジェクトは強力な循環参照やプロセス間の紐付けを持っており、明示的に`Set = Nothing`を行わない限り、バックグラウンドでインスタンスが残り続ける。
これが積み重なると、Visioは「見えないゴミ」で溢れかえり、パフォーマンスが急落する。「使い終わったオブジェクトは、その場で手放す」。これがプロの鉄則だ。
—
2. 現場で使える堅牢なパターン：Clean & Safe Code
以下に、実務でそのままテンプレートとして使える「メモリリークを防ぐための構造」を示す。ポイントは「エラーハンドリング」と「確実に解放する終了処理」のセットだ。
Public Sub ProcessVisioShapes()
‘ オブジェクト変数の宣言
Dim vsoApp As Visio.Application
Dim vsoDoc As Visio.Document
Dim vsoPage As Visio.Page
Dim vsoShp As Visio.Shape
‘ エラーハンドリングの要
On Error GoTo ErrorHandler
‘ アプリケーションの取得（新しいインスタンスを生成せず既存を掴む）
Set vsoApp = Application
Set vsoDoc = vsoApp.ActiveDocument
Set vsoPage = vsoDoc.Pages(1)
‘ ここでメインの処理を行う
For Each vsoShp In vsoPage.Shapes
‘ 例えば、特定のシェイプを加工するロジック
Debug.Print vsoShp.Name
Next vsoShp
CleanExit:
‘ 【重要】生成した順序と逆順で解放する
‘ Nothingを代入することで、COM参照カウントを確実にデクリメントする
Set vsoShp = Nothing
Set vsoPage = Nothing
Set vsoDoc = Nothing
Set vsoApp = Nothing
Exit Sub
ErrorHandler:
MsgBox “エラー発生: ” & Err.Description, vbCritical
Resume CleanExit
End Sub
このコードの「設計思想」
1. `CleanExit` ラベルの活用: 正常終了時も異常終了時も、必ずこのラベルを経由して解放処理を通す。これにより、エラーが起きてもメモリリークが起きない。
2. 階層構造の意識: Application → Document → Page → Shape の順で参照を辿る場合、解放は逆順で行うのが最も安全である。
—
3. 実務で見落とされがちな「罠」
A. グローバル変数の乱用を避ける
`Public` なオブジェクト変数は、モジュールを跨いでメモリに居座り続ける。どうしても必要な場合を除き、スコープは可能な限りプロシージャ内に閉じ込めるべきだ。
B. データベースや外部ファイルとの連携
VisioからExcelやSQL Serverへデータを吐き出す際、`Excel.Application` 等を生成することがあるだろう。ここでVisioのオブジェクトと外部のオブジェクトを混在させると、プロセスがゾンビ化しやすい。外部リソースも必ず個別に `Nothing` を代入せよ。
C. Shapeのループ処理における注意点
`For Each` ループ内でオブジェクト変数を再利用する場合、ループの最後に `Set vsoShp = Nothing` を書く必要はないが、ループを抜けた後に `vsoShp` を他の処理で使い回すなら、一度リセットする意識を持つこと。
—
4. チーフアーキテクトからの提言
「コードが動く」ことと「コードが死なない」ことは全く別次元の話だ。
あなたが書くVBAコードは、その場限りのスクリプトではなく、業務を支える「インフラ」であるべきだ。メモリ管理を怠る開発者は、爆弾を抱えた爆撃機を飛ばしているのと同じである。
今回紹介した「エラーハンドリングと連動した解放処理」を徹底するだけで、あなたのツールは劇的に安定し、Visioのクラッシュ頻度は限りなくゼロに近づくはずだ。
さあ、今すぐ既存のコードを確認しろ。`Nothing` の代入を忘れている箇所はないか？ その小さな一行が、あなたのエンジニアとしての信頼を決定づけるのだ。
