Visio VBAの「墓穴」を埋める：Shape.CellExistsUによる堅牢なデータ連携術
Visioを用いた自動化ツールを開発していると、必ず突き当たる壁がある。それは、「ステンシルが混在する図形群に対するデータ操作」だ。
「この図形には『Prop.Department』があるはずだ」と信じてコードを書いた瞬間、別のステンシルから持ち込まれた図形が混ざり、`Run-time error ‘-2032465818’ (80041a06): セルは存在しません` という無慈悲な警告と共にツールは停止する。
これを防ぐために `On Error Resume Next` を乱用しているなら、今すぐその習慣を捨ててほしい。それは「エラーを見ないふりをする」という、エンジニアとして最も避けるべき怠慢だ。今回は、Visioの深淵であるオブジェクトモデルを掌握し、プロフェッショナルなレベルでエラーを「未然に防ぐ」ための `CellExistsU` 戦略を伝授する。
—
なぜ「直接アクセス」が死を招くのか
Visioの `Shape.Cells(“Prop.xxx”)` への直接アクセスは、その図形にそのプロパティが定義されていることが「前提条件」となっている。しかし、現実の業務で扱う図形は、作成者が異なれば、プロパティの定義も揺らぐ。
特に、外部システムやデータベースからデータを流し込む際、この「不安定さ」が致命的なボトルネックとなる。堅牢なシステムを作るためには、「操作前にそのインターフェース（セル）が存在するかを確認する」という防衛的プログラミングが不可欠だ。
—
CellExistsU：エラーをブロックする唯一の正解
`Shape.CellExistsU` メソッドは、指定したセルの名前がその図形の `Sheet` に存在するかを真偽値で返す。これを用いることで、エラーハンドリングを「事後対応」から「事前チェック」へと昇華できる。
実践的なプロダクションコード例
以下は、安全かつ高速にシェイプのプロパティを読み書きするための設計パターンだ。
‘ @brief 指定したセルの値を安全に取得するユーティリティ関数
‘ @param shp 操作対象のVisio Shapeオブジェクト
‘ @param cellName 取得したいセル名（例: “Prop.Cost”）
‘ @return セル値（存在しない場合は空文字）
Public Function GetShapeCellValue(ByRef shp As Visio.Shape, ByVal cellName As String) As String
‘ CellExistsUの引数2: 0を指定すると、ローカルのCell定義をチェックする
If shp.CellExistsU(cellName, 0) Then
GetShapeCellValue = shp.CellsU(cellName).ResultStr(“”)
Else
‘ ここでログを出力する設計にすると、デバッグが劇的に楽になる
Debug.Print “Warning: Property ‘” & cellName & “‘ not found in ” & shp.Name
GetShapeCellValue = “”
End If
End Function
‘ @brief 指定したセルに安全に値を書き込むユーティリティ関数
Public Sub SetShapeCellValue(ByRef shp As Visio.Shape, ByVal cellName As String, ByVal val As String)
‘ 存在しないセルへの書き込みはクラッシュの元。
‘ 必要に応じて、ここでCellを動的に作成するロジックを組むことも可能。
If shp.CellExistsU(cellName, 0) Then
shp.CellsU(cellName).FormulaU = Chr(34) & val & Chr(34)
Else
‘ プロパティが未定義の場合は、AddNamedRowで動的生成する判断も重要
Debug.Print “Error: Cannot write to non-existent property ‘” & cellName & “‘”
End If
End Sub
—
プロフェッショナルな設計へのヒント
1. 「暗黙の前提」を排除する
データベース連携を行う際、`Shape.CellExistsU` を単なるチェック関数として使うだけでなく、「データ定義リストとの突合」に利用してほしい。図形が持つべきプロパティが欠落している場合、その時点で警告を出す、あるいは不足分を動的に追加するクラスを構築する。これが「堅牢なシステム」の境界線だ。
2. インターフェースの抽象化
`CellsU` を直接コードに散りばめないこと。上記のように `Get/Set` メソッドをラップし、ロジック層とVisioの物理層を分離させる。これにより、将来的にセルの名前が変更されても、修正箇所はユーティリティ関数内の一箇所で済む。
3. パフォーマンスの罠
`CellExistsU` は高速だが、数万個の図形に対してループ内で呼び出し続けると、重なり合うオーバーヘッドが目立ち始める。大量処理を行う場合は、一度取得したシェイプのプロパティリストを `Collection` や `Dictionary` にキャッシュするなどの工夫が、伝説級のエンジニアへの近道だ。
—
結論：コードの品格を上げろ
Visio VBAは古い言語だが、そのオブジェクトモデルは極めて緻密だ。`CellExistsU` を使いこなすということは、図形の「構造」を理解しているという証に他ならない。
「動けばいい」というコードは、数ヶ月後の自分や運用担当者にとっての負債になる。「存在しないものに触れない」。この極めてシンプルな原則を徹底するだけで、あなたの作成するツールは、エラー知らずの真に堅牢なプロダクトへと進化する。
さあ、今すぐあなたのコードから `On Error Resume Next` を排除し、正しく、美しく、強い自動化を実装してほしい。
