「削除」という名の破壊を防ぐ：Visio VBAにおけるメタデータ駆動型ガードレールの構築
エンジニアリングの現場において、「削除」という操作は常に死と隣り合わせだ。
特に、数千のシェイプと複雑なレイヤー構造を持つ大規模なVisioドキュメントを自動操作する場合、たった一行の `Page.Delete` の誤用が、数日間に及ぶ設計業務を無に帰す。初心者は「確認ダイアログを出せばいい」と考える。しかし、我々プロフェッショナルが構築すべきは、単なるUIによる警告ではない。システムの本質的な設計思想に組み込まれた「不可侵領域（Immutable Zone）」の定義である。
本稿では、単なる `MsgBox` の使い方を超え、メタデータを利用した堅牢なガードレール、およびCOMオブジェクトのライフサイクルを制御する極限の知見について解説する。
1. 脆弱な設計：名前ベースの条件分岐という罠
初心者が書くコードは、往々にして以下のようなロジックに基づいている。
' --- 典型的なアンチパターン ---
If ActivePage.Name <> "MasterPage" Then
If MsgBox("削除しますか？", vbYesNo) = vbYes Then
ActivePage.Delete
End If
End Ifこれは極めて脆弱だ。なぜか？
1. 名前の変更に弱い: ユーザーが「MasterPage」を「マスター」に変更した瞬間、ガードレールは崩壊する。
2. マジックストリングの乱用: コード内に直接文字列を埋め込むことは、保守性の観点から「悪」である。
3. UIのブロッキング: 大量ページをループで処理している際、`MsgBox` が割り込むことでスループットが劇的に低下し、非同期的なプロセス管理を妨げる。
2. 堅牢な設計：メタデータによる「不可侵属性」の付与
真のアーキテクトは、オブジェクトそのものに「属性」を持たせる。Visioにおいては、`Page` オブジェクトの `CustomProperties`（ユーザー定義セル）を利用するのが定石だ。
ページ自体に `IsProtected` というプロパティを持たせ、その値が `1` であれば、いかなるコードからも削除を拒否するロジックを組む。これにより、ページ名が何であろうと、その「性質」に基づいて保護が可能になる。
3. 実装：極限のガードレール・エンジン
以下に、Windows APIの思想を取り入れ、メモリ管理までを考慮した実戦的な実装例を示す。
Option Explicit
' 戻り値の定義（可読性と保守性のためのEnum）
Public Enum DeletionResult
drCancelled = 0
drConfirmed = 1
drProtected = 2 ' 保護されているため削除不可
End Enum
''' <summary>
''' ページ削除の安全性を担保するガードレール関数
''' </summary>
''' <param name="pg">対象のPageオブジェクト</param>
''' <returns>削除の可否を示すDeletionResult</returns>
Public Function ValidatePageDeletion(ByRef pg As Visio.Page) As DeletionResult
On Error GoTo ErrorHandler
' 1. メタデータによる保護判定 (CustomPropertiesを利用)
' ページに "SystemProtected" というプロパティが存在し、値が 1 ならば保護対象とする
Dim protectProp As Visio.Cell
On Error Resume Next
Set protectProp = pg.CustomProperties("SystemProtected")
On Error GoTo ErrorHandler
If Not protectProp Is Nothing Then
If protectProp.Result As Integer = 1 Then
ValidatePageDeletion = drProtected
Exit Function
End If
End If
' 2. ユーザーへの確認ダイアログ (MsgBox)
' 注: 大規模バッチ処理時は、引数でダイアログ表示の有無を制御する設計にすべきである
Dim msg As String
msg = "ページ [" & pg.Name & "] を削除してもよろしいですか？" & vbCrLf & _
"この操作は取り消せません。"
If MsgBox(msg, vbQuestion + vbYesNo + vbDefaultButton2, "重要：削除確認") = vbYes Then
ValidatePageDeletion = drConfirmed
Else
ValidatePageDeletion = drCancelled
End If
Exit Function
ErrorHandler:
' エラー発生時は安全側に倒す（削除させない）
ValidatePageDeletion = drCancelled
End Function
''' <summary>
''' メインプロセス：安全なページ削除ルーチン
''' </summary>
Public Sub ExecuteSafePageDeletion()
Dim vsoDoc As Visio.Document
Dim vsoPage As Visio.Page
Dim i As Integer
Dim result As DeletionResult
Set vsoDoc = ActiveDocument
' ページ削除はインデックスが変動するため、後ろのページから逆順にループするのが鉄則
For i = vsoDoc.Pages.Count To 1 Step -1
Set vsoPage = vsoDoc.Pages(i)
' ガードレールの実行
result = ValidatePageDeletion(vsoPage)
Select Case result
Case drConfirmed
vsoPage.Delete
Debug.Print "Deleted: " & vsoPage.Name
Case drProtected
Debug.Print "Skipped (Protected): " & vsoPage.Name
Case drCancelled
Debug.Print "Skipped (User Cancelled): " & vsoPage.Name
End Select
' --- 極限の知見：オブジェクトの明示的な解放 ---
' ループ内で大量のページを扱う場合、COMオブジェクトの参照カウントを
' 適切に管理しないと、メモリリークやVisioのプロセス残存を招く。
Set vsoPage = Nothing
Next i
' 文末のクリーンアップ
Set vsoDoc = Nothing
MsgBox "プロセス完了", vbInformation
End Sub4. 深層解説：エンジニアが留意すべき3つの要諦
① オブジェクトのライフサイクルとメモリ管理
VBAはCOM（Component Object Model）の上で動作している。`Set vsoPage = Nothing` を明示的に記述することは、単なる作法ではない。特に、Visioの自動化をサーバーサイド（Visio Server等）で行う場合、オブジェクトの解放漏れはメモリ消費の増大を招き、最終的にシステムのハングアップを引き起こす。ループ内での `Set … = Nothing` は、プロフェッショナルの最低限の規律である。
② 逆順ループ（Backward Iteration）の必然性
コレクション（`Pages`）から要素を削除する際、前から順に（`1 To Count`）処理を行うと、削除した瞬間にインデックスが詰められ、次に参照すべき要素をスキップしてしまう。これは初歩的だが、致命的なバグを生む。必ず `Step -1` による逆順処理を選択せよ。
③ メタデータ駆動型の設計思想
コード内に `If pg.Name = “Sheet1″` と書くのは、設計の放棄である。
「このページはシステムが管理するものか？」という問いに対する答えを、コードではなくデータ（CustomProperties）に持たせる。これにより、ロジック（VBA）とポリシー（Visioドキュメントの設定）を分離でき、システムの柔軟性と堅牢性が劇的に向上する。
結言
「確認ダイアログを表示する」という単純なタスクの裏側には、例外処理、メモリ管理、そしてデータ構造の設計という、エンジニアリングの真髄が隠されている。
初心者は「動くコード」を書く。
シニアエンジニアは「壊れないコード」を書く。
そしてアーキテクトは「運用に耐えうる、設計に基づいたシステム」を構築する。
貴殿が次に書くコードは、どちらの領域に属しているだろうか。
