Visio VBAを掌握する極限の知見：`Document.VBProject` によるメタプログラミングの要諦
Visio VBAの領域において、多くの開発者は `Shape` の走査や `Master` の操作、あるいは `Page` のレイアウト自動化といった「図面内の操作」で思考を停止させる。しかし、シニアアーキテクトが直面する真の課題――例えば、数百の拠点に配布する図面テンプレートの動的更新、スタンドアロンでの自己拡張型インストーラーの構築、あるいは図面ファイル自体をコードのコンテナとして扱うアーキテクチャの設計において、避けて通れない領域が存在する。
それが、`Document.VBProject` を用いたメタプログラミング（VBAコードによるVBAコードの動的生成・改変）である。
本稿では、VBAプロジェクトへのプログラム的アクセス（Extensibility）の深層を暴き、メモリ管理の罠、セキュリティの壁、そして現場のシステム運用で生きる実戦的なコードベースを提示する。
—
1. 開発の前提：セキュリティの「見えない壁」を突破する
`Document.VBProject` を操作する際、最初に遭遇する壁は、COMコンポーネントとしての厳しいセキュリティ制約である。デフォルトの状態では、VBAからVBE（Visual Basic Environment）のオブジェクトモデルへのアクセスはオペレーティングシステムレベルで遮断されている。
これをプログラムから操作可能にするためには、ExcelやWordと同様に、Visio側での明示的な設定変更が必要となる。
必須の事前設定
1. 「信頼済みの場所」への登録: 実行する `.vsd` / `.vsdm` ファイルの保存先を、Visioの「トラストセンター」で信頼済みに追加する。
2. 「VBA プロジェクト オブジェクト モデルへのアクセスを信頼する」の有効化:
- `ファイル` > `オプション` > `トラストセンター` > `トラストセンターの設定` > `マクロの設定`
- 「Visual Basic プロジェクトへのアクセスを信頼する」 にチェックを入れる。
※この設定がされていない状態で `Document.VBProject` にアクセスしようとすると、容赦なく 実行時エラー ‘1004’: アプリケーション定義またはオブジェクト定義のエラーです が発生する。エラーハンドリングの前に、環境の前提条件をクリアしていることがシニアエンジニアの第一歩である。
—
2. アーキテクチャの核心：標準モジュールの動的生成とコードインジェクション
以下のコードは、現在アクティブなVisioドキュメントに対して、プログラム側から新規に標準モジュール (`bas_AutoGenerated`) を動的に追加し、そこにイベントハンドラを含む実用的なVBAコードを自動注入（インジェクション）する完全なプロシージャである。
ここで重要なのは、「参照設定（References）の動的追加」と「メモリの明示的な解放」のライフサイクル管理だ。
Option Explicit
‘ =========================================================================
‘ 処理名: InjectCodeToVisioDocument
‘ 概要 : アクティブなVisioドキュメントのVBProjectに新規モジュールを動的生成し、
コードを書き込むメタプログラミングの実装例。
‘ =========================================================================
Public Sub InjectCodeToVisioDocument()
Dim targetDoc As Visio.Document
Dim vbProj As Object VBIDE.VBProject
Dim vbComp As Object VBIDE.VBComponent
Dim codeModule As Object VBIDE.CodeModule
Dim lineNum As Long
‘ 1. ターゲットドキュメントの特定（マクロ有効図面 .vsdm である必要がある）
Set targetDoc = Visio.ActiveDocument
If Not IsMacroEnabledFormat(targetDoc) Then
MsgBox “対象の図面はマクロ有効形式 (.vsdm)ではありません。”, vbCritical
Exit Sub
End If
On Error GoTo ErrorHandler
‘ 2. VBProjectオブジェクトの取得
‘ ※要事前設定: 「VBA プロジェクト オブジェクト モデルへのアクセスを信頼する」
Set vbProj = targetDoc.VBProject
‘ 3. 既存の同名モジュールが存在する場合は一旦削除（クリーンアップ）
On Error Resume Next
Set vbComp = vbProj.VBComponents(“bas_AutoGenerated”)
If Not vbComp Is Nothing Then
vbProj.VBComponents.Remove vbComp
End If
On Error GoTo ErrorHandler
‘ 4. 新規標準モジュールの追加 (1 = vbext_ct_StdModule)
Set vbComp = vbProj.VBComponents.Add(1)
vbComp.Name = “bas_AutoGenerated”
‘ 5. コードモジュールの取得とコードの注入
Set codeModule = vbComp.CodeModule
lineNum = 1
With codeModule
.InsertLines lineNum, “Option Explicit”
lineNum = lineNum + 1
.InsertLines lineNum, “‘ ————————————————–”
lineNum = lineNum + 1
.InsertLines lineNum, “‘ [自動生成されたモジュール] 実行日時: ” & Now()
lineNum = lineNum + 1
.InsertLines lineNum, “‘ ————————————————–”
lineNum = lineNum + 1
.InsertLines lineNum, “Public Sub DynamicEntryPoint()”
lineNum = lineNum + 1
.InsertLines lineNum, ” MsgBox “”このコードはメタプログラミングによって動的生成されました。””, vbInformation, “”Auto-Generated”””
lineNum = lineNum + 1
.InsertLines lineNum, “End Sub”
End With
MsgBox “VBAコードの動的インジェクションが正常に完了しました。”, vbInformation, “成功”
CleanUp:
‘ 6. COMオブジェクトの明示的な解放（メモリリーク・VBEクラッシュの防止）
Set codeModule = Nothing
Set vbComp = Nothing
Set vbProj = Nothing
Set targetDoc = Nothing
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “致命的エラー”
Resume CleanUp
End Sub
‘ ————————————————————————-
‘ 補助関数: ドキュメントがマクロ有効形式 (.vsdm) かどうかを判定
‘ ————————————————————————-
Private Function IsMacroEnabledFormat(doc As Visio.Document) As Boolean
Dim ext As String
ext = LCase(Mid(doc.Name, InStrRev(doc.Name, “.”) + 1))
‘ vsdm または古い形式の vsd のみマクロを保持可能
If ext = “vsdm” Or ext = “vsd” Then
IsMacroEnabledFormat = True
Else
IsMacroEnabledFormat = False
End If
End Function
—
3. チーフアーキテクトが警告する「VBEメモリリーク」とクラッシュの罠
VBAで `VBProject` や `VBComponents` を操作する際、開発者が最も陥りやすい罠が 「COMオブジェクトの参照解放漏れによるVBEのメモリリークと突然のVisio強制終了（クラッシュ）」 である。
VBEオブジェクトモデルの特殊性
ExcelやVisioのドキュメントオブジェクトと異なり、`VBIDE` (Visual Basic For Applications Extensibility) のオブジェクト群は、裏で動いているVBEのCOMサーバーと密に結合している。
プロシージャの終了時にこれらの参照がメモリ上に残ったままになると、VBEのインスタンスがゴーストプロセスとして残り、次回のコード書き換え時や図面の保存時にメモリ違反エラー（Access Violation）を引き起こす。
鉄則：オブジェクト変数はスコープを狭め、必ず `Nothing` を代入せよ
先ほどのコードでも示したが、`VBProject`、`VBComponents`、`CodeModule` を操作した後は、例外発生時（`Error Handler`）であっても必ず以下のように逆順で解放しなくてはならない。
Set codeModule = Nothing
Set vbComp = Nothing
Set vbProj = Nothing
この規これを怠ると、数回コードの動的生成・削除を繰り返しただけで、Visioが前触れもなくクラッシュする悪夢に直面することになる。
—
4. 実戦的ユースケース：自己拡張型テンプレート（Self-Extensible Template）の設計思想
では、このメタプログラミング技術を実際の業務システムでどう活かすのか。
一つの究極的な解が 「自己拡張型テンプレート（セルフ・パッチング・図面）」 の構築である。
シナリオ
全社に配布するVisio図面テンプレートに最新のビジネスロジック（図形検証ロジックや外部DB連携ロジック）を強制的にアップデートさせたい場合、インストーラーを別途配布するのは情シス部門にとって負荷が大きい。
代わりに、マスター図面を開いた瞬間、または特定のボタンを押した瞬間に、中央サーバー（または共有フォルダ）から最新のVBAソースコード文字列を取得し、自身の `VBProject` を自動的に上書き・更新する仕組み を実装する。
‘ 概念コード：中央リポジトリからのコード同期ロジック
Public Sub SynchronizeMacroFromRepository()
Dim remoteCode As String
remoteCode = FetchCodeFromServer(“https://internal.company.com/visio/scripts/latest_logic.vbs”)
If remoteCode <> “” Then
‘ 既存モジュールを消去し、最新コードをインジェクション
Call OverwriteModule(“bas_BusinessLogic”, remoteCode)
MsgBox “ビジネスロジックが最新版にアップデートされました。”, vbInformation
End If
End Sub
このアプローチにより、配布物は単なる「静的な図面ファイル」ではなく、「自己のコードベースを環境に合わせて最適化・進化させるスマート・ドキュメント」へと昇華する。
—
5. 総括
`Document.VBProject` を操作するメタプログラミングは、一歩誤ればセキュリティリスクや安定性の低下を招く諸刃の剣である。しかし、そのライフサイクルとCOMの挙動を完全に支配下置いたエンジニアにとって、それはVisio VBAの表現力を無限大に拡張する最強の武器となる。
レガシーな枠組みにとらわれず、コードがコードを書き換えるメタな領域に踏み込むことこそが、真の「Visio自動化の極限」である。
