Visio VBAを掌握する極限の知見：`ActivePage`の幻想と、複数図面時代を生き抜く「脱・アクティブ依存」の設計哲学
レガシーシステムの最前線でVBAと格闘するエンジニア諸君。日々のオートメーション開発ご苦労様。
今日はVisio VBAにおける「最も静かに、そして確実にシステムを崩壊させるアンチパターン」について話をしよう。
テーマは `Application.ActivePage` の安全な切り替えと、複数図面オープン時におけるヌル参照・コンテキスト迷子の完全防御 だ。
GUIのフォーカスに依存したコードを書いているうちは、アマチュアの域を出ない。バックグラウンド処理、マルチドキュメント環境、そして非同期に近いイベント処理が絡む現場において、`ActivePage` や `ActiveDocument` を安易に呼び出す行為は、地雷原を目隠しで歩くようなものだ。
プロフェッショナルが知るべき、Visioオブジェクトモデルの真の姿と、極限まで堅牢なコードの書き方を授けよう。
—
1. なぜ `ActivePage` は「悪魔のプロパティ」なのか？
VisioのVBA初学者、あるいは我流でコードを覚えてきたプログラマが真っ先に書くコードがこれだ。
‘ 【アンチパターン】絶対に真似してはいけないコード
Application.ActiveDocument.Pages.Item(1).Shapes.Item(1).Text = “Hello”
Application.ActivePage.DrawRectangle 0, 0, 5, 5
一見、動くように見える。単一の図面を手動で開き、F5キーでマクロを走らせる分には何の問題もない。
しかし、以下の条件が揃った瞬間、このコードは神出鬼没のNullReferenceException（実行時エラー 91: オブジェクト変数または With ブロック変数が見つかりません）を引き起こす。
1. 複数のVisio図面（`.vsd` / `.vsdx`）がバックグラウンドで開かれている。
2. マクロ実行中に、ユーザーが別のVisioウィンドウをクリックしてフォーカスを奪った。
3. アドインやタイマーイベント（`OnTime`）によって、UIスレッドのコンテキストが切り替わった。
`ActivePage` や `ActiveDocument` は、「今、ユーザーの目に映っている（アクティブな）ウィンドウのコンテキスト」に完全に依存している。コードが実行された瞬間にユーザーが別のウィンドウを触っていれば、意図しない図面の、意図しないページに対して破壊的な処理を実行してしまうか、最悪の場合はオブジェクトが取得できずに即死する。
シニアエンジニアたる者、GUIの状態に依存したロジックを書いてはならない。
—
2. オブジェクトモデルの階層を直接辿れ：ドキュメント駆動設計
この問題を根本から解決するアプローチは一つしかない。「Activeに頼らず、Documentオブジェクトから直接ターゲットを指し示す」ことだ。
Visioのオブジェクトモデルを思い出してほしい。
`Application` の下には `Documents` コレクションがあり、その下に個別の `Document` がある。さらにその中に `Pages` と `Page` が存在している。
Application
├── Documents (Collection)
│ └── Document (Target)
│ └── Pages (Collection)
│ └── Page (Target)
ウィンドウのフォーカス（Active）を一切介在させず、メモリ上のオブジェクトツリーを直接手繰り寄せるコードこそが、真に堅牢なVBAコードである。
実装例：完全防御されたページ操作のボイラープレート
以下に、複数図面がオープンしている環境であっても、指定したドキュメントとページを確実に対象に取る安全な実装を示す。
Option Explicit
Public Sub SafePageOperationSample()
Dim targetDoc As Visio.Document
Dim targetPage As Visio.Page
Dim targetShape As Visio.Shape
‘ 1. 操作対象のドキュメントを明示的に取得（例：ファイル名で特定、または新規作成）
Set targetDoc = GetOrOpenTargetDocument(“SystemArchitecture.vsdx”)
If targetDoc Is Nothing Then
MsgBox “対象のドキュメントが見つかりません。”, vbCritical
Exit Sub
End If
‘ 2. ActivePageを使わず、Documentオブジェクトから直接Pageを取得
‘ ※ここでは図面内の1番目のページを指定（必要に応じて名前検索に変更可能）
Set targetPage = GetPageByName(targetDoc, “基本設計図”)
If targetPage Is Nothing Then
MsgBox “指定されたページが存在しません。”, vbCritical
GoTo CleanUp
End If
‘ 3. ページコンテキストが確約された状態で安全に処理を実行
Set targetShape = targetPage.DrawRectangle(1, 1, 5, 3)
targetShape.Text = “Architectural Component”
MsgBox “処理が正常に完了しました。”, vbInformation
CleanUp:
‘ 4. メモリリーク防衛のためのオブジェクト解放
Set targetShape = Nothing
Set targetPage = Nothing
Set targetDoc = Nothing
End Sub
‘ — ヘルパー関数群 —
Private Function GetOrOpenTargetDocument(ByVal docName As String) As Visio.Document
Dim doc As Visio.Document
On Error Resume Next
‘ 既に開いているドキュメントコレクションから探索
Set doc = Application.Documents(docName)
On Error GoTo 0
If doc Is Nothing Then
‘ 開いていない場合は新規作成、あるいはパスを指定して開く
‘ Set doc = Application.Documents.Add(“”)
‘ または Set doc = Application.Documents.Open(“C:\Path\To\” & docName)
End If
Set GetOrOpenTargetDocument = doc
End Function
Private Function GetPageByName(ByVal doc As Visio.Document, ByVal pageName As String) As Visio.Page
Dim pg As Visio.Page
For Each pg In doc.Pages
If pg.NameU = pageName Or pg.Name = pageName Then
Set GetPageByName = pg
Exit Function
End If
Next pg
Set GetPageByName = Nothing
End Function
—
3. シニアのための深層知見：メモリ最適化とVBAのライフサイクル
ここで、VBAの裏側（COMコンポーネントの参照カウンタ）に踏み込んだ話をしよう。
多くのVBAプログラマは、`Set obj = Nothing` を「なんとなくのおまじない」程度に考えている。しかし、Visioのような重厚長大なCOMオブジェクトを扱うアプリケーションにおいて、オブジェクト変数の解放を怠ることは、VBAランタイムのメモリリークおよびVisioプロセス（visio.exe）のゾンビ化を意味する。
参照カウントの罠
`Application.ActivePage` のようなプロパティを頻繁に呼び出すと、その都度COMラッパーオブジェクトが裏側で生成され、参照カウンタがインクリメントされる。
バックグラウンド処理で何千回もループを回すようなコードのなかで `ActivePage.Shapes…` を連発すると、ガベージコレクションやスコープ抜けのタイミングが追いつかず、メモリ空間が断片化する。
確実な参照断ち切り（CleanUpパターン）
先ほどのコードでも示した通り、プロシージャの最後には必ず、生成した順とは逆の順序（あるいは一括）で `Set xxx = Nothing` を明示的に記述し、COMサーバーへの参照を即座に解放せよ。
特に `For Each` で `Page` や `Shape` を走査する際は注意が必要だ。
Dim shp As Visio.Shape
For Each shp in targetPage.Shapes
‘ 処理
Next shp
‘ ループ脱出後も shp は最後のシェイプを指し示してメモリに残存している
Set shp = Nothing ‘ ここで必ず解放する
この一手間が、数日間に及ぶバッチ処理や、大規模な図面自動生成タスクを安定稼働させるための絶対条件となる。
—
4. レガシー環境・システム間連携における実戦的防衛策
社内システムや外部のC# / PowerShellプログラムからVisioをCOMオートメーションで操作するアーキテクチャでは、さらにシビアな視点が求められる。
外部プロセスからVisioを起動・操作する場合、VisioのGUIは「非表示（`Visible = False`）」で動かすことが大半だ。
画面が見えていない状態なのだから、`ActivePage` や `ActiveWindow` といった概念はそもそも存在しない（取得しようとすればエラーかNothingが返る）。
外部連携やバッチ処理を書くときは、初めからGUIコンテキストを完全に捨て去る設計にしなければならない。
- ×NG設計: 外部アプリからVisioを起動し、アクティブウィンドウをフックしてページを切り替えようとする。
- ○正解設計: 外部から `Documents.Add` または `Documents.Open` で取得した `Document` オブジェクトの参照を保持し、すべての描画・データ流し込みをオブジェクト経由で完結させる。
// 【参考】C# (COM Interop) からの操作イメージでも思想は同じ
Visio.Application app = new Visio.Application();
Visio.Document doc = app.Documents.Add(“”);
Visio.Page page = doc.Pages[1]; // ActivePageは絶対に使わない
// データの書き込み…
VBAであってもC#であっても、本質は同じだ。「環境の状態（Active）」に依存するコードは脆弱であり、「自ら構築したオブジェクトの階層（Document -> Page）」に依拠するコードこそが強靭である。
—
5. 結び：コードの品格は「コンテキストの支配」に宿る
プログラミングとは、混沌とした実行環境から不確定要素を排除し、完全な制御下に置く作業に他ならない。
`ActivePage` を安易に使うコードは、風が吹けば桶屋が儲かるような、他力本願で不安定なシステムを産み落とす。
今日からあなたのコードでは `ActivePage` の使用を禁止せよ。常に `Document` を起点とし、ターゲットを静的かつ明確に指し示せ。
その徹底こそが、君を真のVisio VBAマエストロへと押し上げる唯一の道である。
