【テクニカル・上級編】Shape.ItemFromIDExistsによる安全なID参照：実行時エラーを激減させる設計パターン – Visio VBA解析バイブル

Visio VBAを掌握する極限の知見：Shape.ItemFromIDExistsによる安全なID参照設計

VisioのVBA開発において、最も頻発し、かつ開発者を絶望の淵に追いやる実行時エラーの筆頭格は何か。それは間違いなく「存在しない図形ID（Shape ID）へのアクセス」だ。

ユーザーがキャンバス上で何気なく図形を削除した、あるいは非同期のプロセスやイベントハンドラ内で図形が破棄された。その事実を知る由もないVBAコードが、古い `Shape.ID` を頼りにオブジェクトを再取得しようとした瞬間、容赦なく 実行時エラー `-2147352567 (80020009)` や `(104) オブジェクトが見つかりません` が飛ぶ。

この泥沼から抜け出すための決定打が、`Page.ItemFromIDExists` メソッドである。

本稿では、レガシーな `On Error Resume Next` によるガバナンスの欠如したエラー潰しを根絶し、オブジェクトのライフサイクルを完全に掌握するための堅牢な設計パターンを、アーキテクトの視点から解説する。

—

1. Visioオブジェクトモデルの暗黒面：IDの永続性と揮発性

まず、Visioの描画エンジン（`Drawing Control` および Visio本体）における図形識別子の本質を理解しなければならない。

• `Shape.ID` のスコープ: ページ（`Page`）内において一意。ドキュメント全体でのグローバル一意ではない。
• IDの再利用性: 図形が削除されると、そのIDが空き番となり、後から作成された新しい図形に再割り当て（リサイクル）されることは原則としてないが、ドキュメントの修復やXML（VSDX）レベルの操作、あるいはサードパーティ製アドインによる不正な操作によって、IDの整合性が崩壊するリスクは常に存在する。
• ポインタの無効化: 変数に格納された `Visio.Shape` オブジェクトの参照は、背後でC++のCOMポインタ（`IDispatch`）に直結している。図形が削除された瞬間、そのポインタは宙ぶらりん（Dangling Pointer）となり、プロパティやメソッドへのアクセスは即座に致命的なクラッシュを引き起こす。

従来、多くのプログラマは以下のような「愚行」を犯してきた。

‘ 【アンチパターン】エラーフックによる隠蔽
On Error Resume Next
Set shp = vsoPage.Shapes.ItemFromID(targetID)
If Err.Number = 0 Then
‘ 処理
End If
On Error GoTo 0

これはVBAの実行コンテキストにおいて極めて重い処理であり、何より「例外を制御フローの代わりに使う」というアーキテクチャ上の悪臭（Bad Smell）を放つ。さらに、予期せぬ別のエラーまで握りつぶしてしまう危険性がある。

—

2. 救世主：`Page.ItemFromIDExists` の全貌

Visio 2010以降（実質的には近年のすべてのモダンなVisio環境）で利用可能な `Page.ItemFromIDExists` は、例外を発生させずに、指定したIDの図形がページ上に生存しているかをO(1)に近い効率で判定し、同時にオブジェクトを取得するための洗練されたメソッドである。

シグネチャの理解

Dim isValid As Boolean
Dim shp As Visio.Shape

isValid = vsoPage.ItemFromIDExists(targetID, shp)

• 戻り値 (`Boolean`): 指定したIDの図形が存在すれば `True`、存在しなければ `False`。
• 第二引数 (`Outパラメータ / Visio.Shape`): 存在した場合、その図形オブジェクトへの参照が安全に格納される。存在しない場合は `Nothing` が返る。

このメソッドの美しさは、「存在確認」と「オブジェクトのバインド」をアトミック（不可分）に実行できる点にある。これにより、競合状態やポインタの不整合を完全に排除できる。

—

3. 【実践】実行時エラーを激減させる安全な参照設計パターン

実際のエンタープライズ環境（外部データベースと連携するプラント図自動生成システムや、ネットワーク構成図の差分同期エンジンなど）を想定した、実用的なクラスモジュールおよび標準モジュールの設計パターンを提示する。

堅牢な図形操作ラッパーの例

Option Explicit

”
‘ @class SafeShapeAccessor
‘ @brief Visio図形の安全な参照とライフサイクル管理を行うモジュール
‘
Public Sub ProcessTargetShape(ByVal targetPage As Visio.Page, ByVal targetShapeID As Long)

Dim targetShp As Visio.Shape

‘ 1. ItemFromIDExistsによるアトミックな生存確認と取得
If targetPage.ItemFromIDExists(targetShapeID, targetShp) Then

‘ 2. オブジェクトの有効性追加チェック（念のための防御的プログラミング）
If Not targetShp Is Nothing Then

‘ メモリ最適化とスコープ管理を意識した処理の実行
ExecuteBusinessLogic targetShp

End If

Else
‘ ログ記録またはフォールバック処理
Debug.Print “Warning: Shape ID [” & targetShapeID & “] は既に削除されているか、存在しません。”
HandleMissingShape targetShapeID

End If

‘ 3. COMオブジェクトの明示的解放（VBAにおけるメモリリーク・参照カウンタ対策）
Set targetShp = Nothing

End Sub

Private Sub ExecuteBusinessLogic(ByRef shp As Visio.Shape)
‘ 実際の図形操作（プロパティ変更やシェイプシート操作）
‘ 例: セルの安全な書き換え
Dim cellObj As Visio.Cell

‘ セルアクセスの前にもエラーハンドリングを挟むのがプロの作法
If shp.CellExists(“Prop.Status”, Visio.visExistsLocally) Then
Set cellObj = shp.Cells(“Prop.Status”)
cellObj.FormulaU = “””Active”””
End If

‘ COMオブジェクトの局所的解放
Set cellObj = Nothing
End Sub

Private Sub HandleMissingShape(ByVal missingID As Long)
‘ 削除されていた場合のリカバリ処理（例: 内部管理テーブルの状態更新など）
End Sub

—

4. チーフアーキテクトが教える：パフォーマンスとメモリ管理の極意

VBAはガベージコレクション言語ではなく、COMの参照カウント（Reference Counting）に依存している。そのため、オブジェクト変数を適切に `Nothing` に解放しないと、Visioのプロセス内にメモリリークが蓄積し、長時間のバッチ処理や大規模図形の処理において「Out of Memory」やフリーズを引き起こす。

メモリ最適化の鉄則

1. ループ内でのオブジェクト生成・破棄の禁止:
大量の図形IDをリストから順引きするようなケースでは、ループ内で `Set` を繰り返すことによるメモリフラグメンテーションに注意せよ。
2. `ItemFromIDExists` の戻り値の評価を最短に:
条件分岐の中で直接オブジェクトを受け取ることで、不要な一時変数の生成を抑える。

‘ 最適化されたバッチ処理の例
Dim i As Long
Dim shp As Visio.Shape
Dim ids() As Long
‘ ids配列に大量のIDが格納されていると仮定

For i = LBound(ids) to UBound(ids)
‘ 毎ループ同じ変数を使わず、スコープを意識する
If targetPage.ItemFromIDExists(ids(i), shp) Then
‘ 処理
Set shp = Nothing ‘ すぐに解放
End If
Next i

—

5. レガシー環境・システム間連携における応用

VisioをC# (.NET) や外部のPythonプロセスなどからCOM Interop経由で操作する場合でも、この思想はそのまま通用する。.NET側であれば `try-catch` が使えるが、VBAをホストとする社内ニッチシステムや、Visioマクロ単体で完結させなければならないレガシー環境においては、`ItemFromIDExists` こそが唯一にして最強の防壁となる。

外部システムからJSON等で渡された「図形IDのリスト」を元にVisio図形を一括同期するようなシステム間連携アーキテクチャでは、「外部データの正当性を絶対に信じない（Zero Trust Architecture）」ことが求められる。

外部からのID群を処理する際、事前に `ItemFromIDExists` でフィルタリングを行うプレ処理を挟むことで、自動化スクリプト全体の堅牢性は劇的に向上する。

—

総括

VBAコードの品質は、「正常系の美しさ」ではなく、「異常系・境界条件のハンドリングの緻密さ」によってのみ測られる。

`On Error Resume Next` という甘美な毒を断ち切り、`Page.ItemFromIDExists` を駆使した予測可能で堅牢なコードベースを構築すること。それこそが、レガシーとモダンが混在する現場において、真に信頼されるシステムを組み上げる唯一の道である。