Visio VBAの深淵：Shapeを「確実に」捕獲する唯一の作法
Visioの自動化において、最も初歩的でありながら、多くの開発者が墓穴を掘るのが`Shape`オブジェクトの識別だ。
`Name`と`ID`。この二つのプロパティを混同し、あるいはその脆弱性を無視したままコードを書くことは、時限爆弾を抱えてシステムを運用するに等しい。本稿では、レガシー環境から大規模システム連携までを生き抜いてきた者だけが知る、Shape捕獲の「極限の作法」を伝授する。
—
1. ID vs Name：非対称な識別子の正体
Visioの`Shape`を特定する際、私たちは二つの異なる識別子に直面する。
- `ID` (Integer): ページ内における物理的な通し番号。ページが保持する「Shapeコレクション」のインデックスに近い。
- `Name` (String): Visioが内部的に生成する名前（例: `Sheet.1`）や、ユーザーがUI上で設定できる表示名。
決定的な「落とし穴」
多くのエンジニアが「`Name`で検索すれば確実だ」と錯覚するが、これは大いなる誤解である。`Name`は一意性を保証しない。グループ化、複製（Ctrl+D）、あるいはオートメーションによる図形生成を繰り返せば、`Name`は容易に重複し、あるいはVisioの内部処理によって動的に書き換わる。
結論：ロジックの主軸に`Name`を据えてはならない。
—
2. セキュアなShape取得のアーキテクチャ
システム間連携や大規模な自動作図を行う際、我々は「不変のキー」を保持する必要がある。VisioのネイティブIDはページ内では不変だが、ページをまたぐと無効化される。
ここで推奨されるのが、`User-Defined Cells`（ユーザー定義セル）を用いたメタデータ付与である。特定のShapeに`User.SystemID`といったカスタムセルを埋め込み、そこをキーとして走査する手法だ。
実践：堅牢なShape取得コード
以下のコードは、単なるID指定ではなく、オブジェクトのライフサイクルを意識したメモリ管理とエラーハンドリングを包含している。
‘ —————————————————————————–
‘ @Description: 指定された名前(カスタムセル)を持つShapeを確実に取得する
‘ @Author: Chief Architect
‘ —————————————————————————–
Public Function GetShapeByCustomID(ByVal targetPage As Visio.Page, ByVal key As String) As Visio.Shape
Dim shp As Visio.Shape
‘ オブジェクトの明示的走査（パフォーマンスを考慮し、最低限の範囲で）
For Each shp In targetPage.Shapes
‘ セクションの存在確認（エラーハンドリングを最小化するため）
If shp.CellExists(“User.SystemID”, 0) <> 0 Then
If shp.Cells(“User.SystemID”).ResultStr(0) = key Then
Set GetShapeByCustomID = shp
Exit Function
End If
End If
Next shp
‘ 該当なしの場合はNothingを返し、呼び出し元で制御
Set GetShapeByCustomID = Nothing
End Function
—
3. メモリ解放とガベージコレクションの現実
VBAは参照カウンタ方式でメモリを管理する。特にVisioの`Shapes`コレクションをループさせる際、暗黙的に作成されるShapeオブジェクトの参照が、大規模なドキュメント処理においてメモリリークの温床となることはあまり知られていない。
シニアエンジニアの心得：明示的破棄
ループを抜けた後、あるいは関数から戻る前に、必ずオブジェクトを解放する習慣を身につけること。
‘ 処理終了後のクリーンアップの例
Public Sub CleanupProcess(ByRef shpTarget As Visio.Shape)
‘ 参照を明示的にクリア
If Not shpTarget Is Nothing Then
Set shpTarget = Nothing
End If
‘ 大規模な処理であれば、Application.DoEventsを挟み
‘ メッセージキューをクリアすることで、Visioのフリーズを防ぐ
DoEvents
End Sub
—
4. 極限の視点：Windows APIとの連携
Visioが保持する`ID`や`Name`といった論理的なレイヤーを超え、さらに深い操作が必要な場合がある（例：特定のハンドルを持つWindowを探す、あるいはプロセスを監視する）。
もし、VBAの限界を超えた制御を要求されたなら、迷わず`kernel32`や`user32`を呼び出す設計に切り替えるべきだ。ただし、これを行う際は「Visioの内部オブジェクトモデルをバイパスして直接メモリを叩く」というリスクを常に背負うことを忘れてはならない。
—
最後に：なぜ「基礎」に固執するのか
Visio VBAの現場で障害が発生する原因の8割は、複雑なアルゴリズムではなく、「どの図形を操作しているか」という単純な識別ミスにある。
`Name`を信じるな。`ID`を過信するな。
システムを構築する際は、「外部システムから渡されたキー」と「Visio内のメタデータ」を紐付ける層（レイヤー）を独立させよ。
これが、何十年と続く保守性の高いVisioシステムを設計するための、唯一の「正解」である。あなたの書くコードが、次の世代のエンジニアに「壊れない」と信頼されることを願っている。
