Visio自動化の陥穽：Page.NameUこそが、グローバル・エンタープライズの唯一の聖域である
Visio自動化の世界で、多くのエンジニアが「最初の数ヶ月」で直面し、そして「一生のトラウマ」として抱え続ける問題がある。それが「言語設定に依存したページ参照の破綻」だ。
画面上のタブに表示される「ページ-1」という文字列を頼りにコードを書くのは、地雷原を裸足で歩くのと同じ行為である。本稿では、レガシーシステムからグローバル展開の基幹システムまでを支えてきた知見に基づき、Visioオブジェクトモデルの深層と、堅牢な国際化対応設計について論じる。
—
1. なぜ `Page.Name` を使ってはいけないのか
Visioにおける `Name` プロパティは、ユーザーインターフェース（UI）上の表示名だ。これは現在のシステムロケールに強く依存する。
- 日本語版: 「ページ-1」
- 英語版: 「Page-1」
このプロパティをキーにして `ActiveDocument.Pages.Item(“ページ-1”)` などと記述すれば、多言語環境で動作させた瞬間に `Run-time error ‘-2032465916’: 指定された名前の項目が見つかりません。` という悲劇が幕を開ける。
対して `NameU` (Universal Name) は、Visioが内部的に保持する不変の識別子だ。これは言語設定に関わらず一定である。「UI上のラベルと、プログラム上のキーを分離する」。これこそが、堅牢なVisio自動化における鉄則である。
2. 極限の設計：NameUを用いた安全なページ特定アルゴリズム
実務レベルでは、単に `NameU` を使うだけでなく、「存在しない場合のフォールバック（代替）」と「オブジェクトの明示的解放」をセットで行う必要がある。
以下のコードは、大規模な自動化システムでも通用する、型安全かつメモリ効率を意識したページ取得ルーチンだ。
Option Explicit
‘ @brief ユニバーサル名からPageオブジェクトを安全に取得する
‘ @param targetDoc 対象のDocumentオブジェクト
‘ @param pageNameU 内部ユニバーサル名（例: “Page-1″）
‘ @return 見つかった場合はPageオブジェクト、存在しない場合はNothing
Public Function GetPageByUniversalName(ByRef targetDoc As Visio.Document, ByVal pageNameU As String) As Visio.Page
Dim pg As Visio.Page
‘ エラーハンドリングを局所化し、予期せぬクラッシュを防ぐ
On Error Resume Next
Set pg = targetDoc.Pages.ItemU(pageNameU)
On Error GoTo 0
If pg Is Nothing Then
‘ ログ出力等の処理をここに挟む
Debug.Print “Critical: Page ‘” & pageNameU & “‘ not found in ” & targetDoc.Name
End If
Set GetPageByUniversalName = pg
End Function
‘ @usage 利用例
Public Sub ExecuteBusinessLogic()
Dim doc As Visio.Document
Dim targetPage As Visio.Page
Set doc = ActiveDocument
‘ NameではなくNameUを使用することで、どの言語環境でも確実に特定
Set targetPage = GetPageByUniversalName(doc, “Page-1”)
If Not targetPage Is Nothing Then
‘ — ここにビジネスロジックを記述 —
Debug.Print “Processing: ” & targetPage.NameU
End If
‘ 明示的なオブジェクト解放（VBAのGCを待たず即時破棄）
Set targetPage = Nothing
Set doc = Nothing
End Sub
3. チーフアーキテクトからの助言：アーキテクチャの極意
オブジェクトの明示的解放とメモリ管理
VBAは参照カウンタ方式でメモリを管理しているが、Visioのような重厚なCOMオブジェクトを扱う場合、`Set obj = Nothing` を怠ると、バックグラウンドプロセスが残り続け、数千回単位のループ処理でメモリリークを引き起こす。特に外部システムと連携する常駐型VBAでは、「スコープを抜ける前に必ず Nothing を代入する」習慣を規律として課すべきだ。
Windows APIによるロケール判定の罠
時折、Windows API (`GetUserDefaultUILanguage` 等) を使って動的にパスを切り替える手法を見かけるが、これは推奨しない。Visio内部の `NameU` を使う手法は、APIのオーバーヘッドを発生させず、Visio自身のメタデータ管理に準拠しているため、最もオーバーヘッドが少なく、かつ保守性が高い。
レガシー環境との共存
もし既存のシステムが `Name` に依存しており、今すぐ書き換えられない場合は、「ページ名変更禁止フラグ」をShapeSheet上で強制することを検討せよ。`User.msvNoNameChange` プロパティを `TRUE` に設定することで、ユーザーが勝手にページ名を変更してマクロを破壊するリスクを物理的に遮断できる。
結び：コードは言葉よりも雄弁である
グローバル環境におけるVisio自動化において、`Name` プロパティをコードに埋め込むことは、「将来の自分」と「次期保守担当者」に対する背信行為である。
真のエンジニアは、変化を前提にシステムを構築する。`NameU` を使いこなし、言語の壁を超えた安定稼働を実現せよ。それが、Visioという「図面」を「データ」として扱う、我々自動化スペシャリストの矜持である。
