Visio VBAを掌握する極限の知見：Shapeの生存文脈を看破せよ――ContainingPageとContainingMasterによる動的コンテキスト制御
VisioのVBA開発において、多くの開発者が陥る最初の、そして最も致命的な罠がある。それは、「すべてのShapeオブジェクトが、常に通常のドキュメントページ上に存在するという暗黙の了解」である。
マスターシェイプの編集ウィンドウ（Master Window）が開かれているとき、あるいはバックグラウンドでマスターシェイプの形状を動的に構築・修正しているとき、そこにあるShapeは「ページ」には属していない。この境界線を無視してコードを書くことは、時限爆弾を抱えたシステムを構築するに等しい。
今回は、`Shape.ContainingPage` および `Shape.ContainingMaster` プロパティを極限まで使いこなし、シェイプの存在コンテキスト（生存文脈）をミリ秒単位で正確に識別し、マスター編集時の誤動作を完全に封殺するセキュアな設計論を授けよう。
—
1. オブジェクトモデルの深層：なぜ「コンテキスト」を見誤るのか？
Visioのオブジェクト階層において、`Shape` オブジェクトはカメレオンのような性質を持つ。
ドキュメントのページ上にドロップされれば、それは `Page.Shapes` コレクションの住人となり、`ContainingPage` は親である `Page` オブジェクトを返す。しかし、同じシェイプIDであっても、それがステンシル内のマスターシェイプ、あるいはマスターの編集画面内にある場合、`Page` には存在しない。代わりに `ContainingMaster` が `Master` オブジェクトを返す。
ここで重大な問題が発生する。
例えば、選択されたシェイプに対して「ページのサイズを取得して座標を計算する」「親ページのレイヤー情報を書き換える」といった処理を行う汎用プロシージャを書いたとする。これをマスターの編集画面で誤って実行した瞬間、`ContainingPage` は `Nothing` を返し、その先にあるプロパティアクセスは容赦なく 実行時エラー ‘-2147352567 (80020009)’: オブジェクトは、その親オブジェクトが指定されているプロパティやメソッドをサポートしていません を引き起こす。
レガシーなVBAコードの多くは、この例外処理を `On Error Resume Next` という名の現実逃避で塗りつぶしている。プロフェッショナルなエンジニアであれば、エラーハンドリングに頼るのではなく、処理の分岐点でオブジェクトの存在文脈を確定させるべきだ。
—
2.ContainingPage と ContainingMaster の厳密な判定ロジック
シェイプが現在「どの文脈に生きているか」を判定するためには、両者のプロパティの排他性を利用する。
Visioの仕様上、通常のページ上のシェイプであっても、グループ化された子シェイプであっても、最終的にはどこかの `Page` に帰結する。しかし、マスターシェイプの直下にあるシェイプは `ContainingPage` が `Nothing` になり、`ContainingMaster` が有効なオブジェクトを返す。
以下のコードは、この文脈を完璧に判定し、誤動作を未然に防ぐための実践的な判定フレームワークである。
‘ ==============================================================================
‘ 担当: チーフアーキテクト
‘ 概要: シェイプの生存文脈（コンテキスト）を判定し、実行環境に応じた処理をディスパッチする
‘ ==============================================================================
Public Sub ProcessShapeByContext(ByVal targetShape As Visio.Shape)
‘ 厳密なNULLチェック（オブジェクトのライフサイクル管理の基本）
If targetShape Is Nothing Then Exit Sub
Dim parentPage As Visio.Page
Dim parentMaster As Visio.Master
‘ オブジェクトの参照を取得
Set parentPage = targetShape.ContainingPage
Set parentMaster = targetShape.ContainingMaster
‘ 文脈の判定
If Not parentPage Is Nothing Then
‘ —【コンテキスト A】通常のページ上のシェイプ —
Call ExecuteForRegularPageShape(targetShape, parentPage)
ElseIf Not parentMaster Is Nothing Then
‘ —【コンテキスト B】マスターシェイプ内のシェイプ —
Call ExecuteForMasterShape(targetShape, parentMaster)
Else
‘ —【異常系】どのコンテキストにも属さない孤立シェイプ（稀だが存在しうる） —
Err.Raise vbObjectError + 1000, “ProcessShapeByContext”, “シェイプの親コンテキストを特定できませんでした。”
End If
‘ メモリ最適化：オブジェクト参照の明示的解放
‘ VBAのCOMラッパー解放漏れを防ぐための極限の作法
Set parentPage = Nothing
Set parentMaster = Nothing
End Sub
—
3. 実装パターン：コンテキストに応じた動的処理の切り替え
では、この判定ロジックを実際の業務自動化にどう組み込むのか。
例えば、「シェイプのテキストやカスタムプロパティ（ShapeData）を動的に書き換え、さらにページ側のレイアウトを自動調整する」というアドイン機能を想定する。
マスター編集画面でこの処理が走った場合、ページレイアウトの変更（例：`ActivePage.PageSheet` の操作）を行ってはならない。なぜなら、マスター編集時にはアクティブページの概念が意図しないものになっている、あるいは存在しない場合があるからだ。
以下に、実業務に耐えうる堅牢なディスパッチ処理の実装を示す。
Private Sub ExecuteForRegularPageShape(ByVal shp As Visio.Shape, ByVal pg As Visio.Page)
‘ ログ出力またはデバッグ
Debug.Print “通常ページ処理: ページ名 = ” & pg.Name & “, シェイプID = ” & shp.ID
‘ ページ上のシェイプに対する安全な操作
‘ 例: ページ座標に基づいた動的リサイズ
shp.CellsU(“Width”).ResultIU = pg.PageSheet.CellsU(“PageWidth”).ResultIU 0.2
‘ ページ固有の処理
Call UpdatePageMetadata(pg)
End Sub
Private Sub ExecuteForMasterShape(ByVal shp As Visio.Shape, ByVal mst As Visio.Master)
‘ ログ出力またはデバッグ
Debug.Print “マスター編集処理: マスター名 = ” & mst.Name & “, シェイプID = ” & shp.ID
‘ マスターシェイプ内の形状変更のみに限定する
‘ ページ依存の処理は一切行わない（誤動作の完全防止）
shp.CellsU(“Width”).ResultIU = 5.0 ‘ 固定のマスター基準サイズを適用
‘ マスター固有のメタデータ更新
Call UpdateMasterMetadata(mst)
End Sub
Private Sub UpdatePageMetadata(ByVal pg As Visio.Page)
‘ ページレベルのカスタムプロパティ操作など
‘ 実装コード…
End Sub
Private Sub UpdateMasterMetadata(ByVal mst As Visio.Master)
‘ マスターレベルのカスタムプロパティ操作など
‘ 実装コード…
End Sub
—
4. エンジニアリングの極み：メモリ管理とCOMインターフェースの解放
Visio VBAにおける最大のパフォーマンス劣化要因、それは COMオブジェクトの解放漏れによるメモリリーク である。
特に `ContainingPage` や `ContainingMaster` を呼び出す際、裏側ではCOMのインターフェースが動的に生成され、VBAのランタイムにポインタが渡される。これらを放置すると、長時間のバッチ処理や、イベント駆動型の複雑なアドインにおいて、Visioのプロセスが徐々に肥大化し、最終的にメモリ不足やフリーズを引き起こす。
極限のパフォーマンスを追求するシステムにおいては、以下の鉄則を遵守せよ。
1. 多重ドット演算子（メンバーチェイン）の排除
`If targetShape.ContainingPage.Name = “Sheet1” ` のようなコードは絶対に書くな。これを行うと、`ContainingPage` が返したオブジェクトの参照が解放できぬままメモリの海に消え、ガベージコレクションのタイミングも制御不能になる。必ずローカル変数（`Dim`）に受け、スコープを抜ける直前に `Set xxx = Nothing` で明示的に解放すること。
2. イベントハンドラ内でのコンテキスト検証
`Visio_DocumentOpened` や `Visio_ShapeAdded` などのグローバルイベント内では、処理対象のシェイプがどのコンテキストで生成されたかをミリ秒単位で判定し、無駄なイベント連鎖（Re-entrancy）を防止するガード節を必ず設けること。
—
総括
Visio VBAのコードの優劣は、「APIを知っているか」ではなく、「オブジェクトのライフサイクルと生存文脈を支配しているか」で決まる。
`ContainingPage` と `ContainingMaster`。この2つのプロパティを羅針盤としてコードに組み込むことで、通常の図面描画エンジンと、マスターシェイプのメタプログラミング領域を完全に分離し、破綻のない頑健なエンタープライズソリューションを構築することが可能となる。
妥協のないコードだけが、現場の信頼を生み出す。明日からの実装で、ぜひこの設計思想を取り入れてほしい。
