【Visio VBA極限チューニング】Document.OpenStencilとvisOpenROが描く、メモリ爆食いを防ぐステンシル検索エンジン
こんにちは。チーフアーキテクトの私だ。
大規模な組織図、ネットワーク図、あるいはプラント設計図……。社内で標準化されたシェイプを使おうと、無数のステンシルファイルを漁る開発現場の情景が目に浮かぶ。
君はこれまで、ステンシル内のマスターシェイプを探すために、ファイルを普通に開いて、メモリを圧迫させ、挙句の果てに「メモリ不足 (Out of Memory)」のエラーに泣かされたことはないか？
あるいは、開いたステンシルが勝手にロックされ、他の開発者からクレームを受けたことは？
Visio VBAにおいて、オブジェクトのライフサイクルとメモリ管理を理解していないコードは、システムをジワジワと蝕む「見えない爆弾」だ。
今回は、`Document.OpenStencil` を 読み取り専用（`visOpenRO`） かつ 非表示 でドライヴし、極限までメモリ消費を抑えながら高速にマスターシェイプを検索・抽出する「プロダクション品質の検索エンジン」の実装手法を授けよう。
—
1. なぜ「普通のオープン」では現場で破綻するのか？
多くの初学者は、ステンシル内のマスターシェイプにアクセスする際、次のような安易なコードを書く。
‘ 【アンチパターン】絶対にやってはいけない実装
Dim visDoc As Visio.Document
Set visDoc = Documents.Open(“C:\Stencils\CompanyStandards.vssx”)
‘ 処理…
visDoc.Close ‘ 気休めのクローズ
このアプローチには、実務において致命的な3つの欠陥がある。
1. 排他制御の罠（書き込み権限の占有）
デフォルトでファイルを開くと、Visioは編集権限（ロック）を保持しようとする。共有サーバー上にある社内標準ステンシルでこれをやられると、他のユーザーが保存できなくなる。
2. UI描画コストの無駄撃ち
Visioのウィンドウとして画面上にロードされるため、不要なGUI描画処理とイベントハンドリングのオーバーヘッドが発生する。
3. メモリリークとガベージコレクションの遅延
ドキュメントオブジェクトが参照を持ち続けたままスコープを抜けると、Visioの内部VBAエンジンがメモリを即座に解放しきれないケースがある。
プロフェッショナルの解：`visOpenRO` と `Invisible` の組み合わせ
VisioのC++コアエンジンを熟知していれば答えは明白だ。
ステンシルを開く際は、明示的に `visOpenRO`（Read Only） を指定し、ウィンドウを表示させない（非表示）。これにより、OSのファイルハンドルは共有モードで開かれ、Visioの描画エンジンはメモリ上の最小限の構造体（メタデータとマスターシェイプのインデックス）だけをメモリに展開する。
—
2. 【実践】メモリ節約型ステンシル検索エンジン
それでは、現場のプロダクション環境にそのまま投入できる堅牢なコードを公開しよう。
このコードは、指定されたフォルダ内の全ステンシル（`.vss` / `.vssx`）を走査し、メモリを極限まで節約しながら、指定したキーワードに合致するマスターシェイプの名前とIDを効率的に釣り上げるエンジンだ。
Option Explicit
‘ ==============================================================================
‘ 模块名: clsStencilSearchEngine
‘ 概要: メモリ消費を最小限に抑えた高速ステンシル検索エンジン
‘ ==============================================================================
Public Sub RunStencilSearch()
Dim targetFolder As String
Dim searchKeyword As String
Dim startTime As Double
startTime = Timer
‘ 検索条件の設定（実際のパスに書き換えてくれ）
targetFolder = “C:\CompanyStencils\”
searchKeyword = “ルータ” ‘ 検索したいマスター名の一部
If Dir(targetFolder, vbDirectory) = “” Then
MsgBox “指定されたステンシルフォルダが存在しません: ” & targetFolder, vbCritical
Exit Sub
End If
‘ 画面描画とイベントを完全停止（爆速化の基本）
Application.ScreenUpdating = False
Application.EventEnabled = False
On Error GoTo ErrorHandler
Debug.Print “=== ステンシル検索開始 ===”
Call SearchStencilsInFolder(targetFolder, searchKeyword)
Debug.Print “=== 検索完了 (実行時間: ” & Format(Timer – startTime, “0.00秒”) & ” ===”
CleanUp:
‘ 確実に環境を復元
Application.ScreenUpdating = True
Application.EventEnabled = True
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical
Resume CleanUp
End Sub
Private Sub SearchStencilsInFolder(ByVal folderPath As String, ByVal keyword As String)
FSOオブジェクトを使わず、軽量なDir関数で高速走査
Dim fileName As String
Dim fullPath As String
Dim stencilDoc As Visio.Document
‘ 拡張子 vss および vssx を対象とする
fileName = Dir(folderPath & “.vss”)
Do While fileName <> “”
fullPath = folderPath & fileName
Set stencilDoc = Nothing
On Error Resume Next
‘ 【核心】visOpenRO (読み取り専用) と visOpenHidden (非表示) で開く
‘ これにより、メモリフットプリントを最小化し、ファイルロックを回避する
Set stencilDoc = Application.Documents.OpenEx(fullPath, visOpenRO + visOpenHidden)
On Error GoTo 0
If Not stencilDoc Is Nothing Then
‘ マスターシェイプの走査
Call ExtractMatchingMasters(stencilDoc, fileName, keyword)
‘ 即座に閉じる（オブジェクトのライフサイクルを極限まで短くする）
stencilDoc.Close
Set stencilDoc = Nothing
End If
fileName = Dir() ‘ 次のファイルへ
Loop
End Sub
Private Sub ExtractMatchingMasters(ByVal doc As Visio.Document, ByVal docName As String, ByVal keyword As String)
Dim mst As Visio.Master
Dim i As Long
‘ Masterコレクションを高速イテレート
For i = 1 To doc.Masters.Count
Set mst = doc.Masters(i)
‘ 部分一致検索（必要に応じて正規表現や完全一致に変更可）
If InStr(1, mst.Name, keyword, vbTextCompare) > 0 Then
Debug.Print “発見! [ファイル: ” & docName & “] -> マスター名: ” & mst.Name & ” (ID: ” & mst.ID & “)”
End If
Set mst = Nothing
Next i
End Sub
—
3. アーキテクトが解説するコードの急所（Whyの追求）
このコードが「なぜプロ仕様なのか」、その設計思想をいくつかのポイントに分けてロジカルに解説しよう。
① `Documents.OpenEx` のフラグ選択の妙
通常の `Documents.Open` はレガシーなラッパーに過ぎない。我々プロは `OpenEx` を使う。
- `visOpenRO`: ファイルシステムレベルで排他制御を行わないため、複数人が同時に同じステンシルを参照してもエラーにならない。
- `visOpenHidden`: Visioのウィンドウマネージャーにドキュメントを登録させない。これにより、不要なウィンドウのインスタンス生成コストとメモリ消費をカットする。
② オブジェクトの「即時解放（Dispose）」パターン
VBAには明示的な `Dispose` メソッドはないが、「用事が済んだら即座に `Nothing` を代入する」という規律が、VBAの貧弱な参照カウント型ガベージコレクタを助ける。
ループのたびに `stencilDoc.Close` を呼び、ポインタを `Nothing` にクリアすることで、メモリ上のメモリリークの芽を完全に摘み取っている。
③ `ScreenUpdating` と `EventEnabled` の遮断
たとえ非表示（`visOpenHidden`）で開いていたとしても、Visioの内部イベントやUIスレッドがわずかにCPUサイクルを奪う可能性がある。
これを完全にシャットアウトすることで、数千個のシェイプを持つ巨大なステンシル群であっても、数秒単位での爆速検索を実現している。
—
4. さらなる高みへ：データベース（SQLite / JSON）との連携
もし社内ステンシルが数百ファイル、マスターの総数が数万個に及ぶのであれば、毎回VBAでファイル群を総なめするアプローチ自体がナンセンスだ。
真にスケーラブルなシステムを構築する場合、上記のVBAエンジンを「インデクサー（バッチプログラム）」として活用し、抽出したマスター名、ID、およびファイルパスのメタデータを SQLite や JSONファイル に一度キャッシュ（吐き出し）させる。
そして、実際の図面作成ツール（UI側）は、その軽量なインデックスDBを参照するアーキテクト構造を採用すべきだ。
[社内ステンシル群 (.vssx)]
↓ (今回のVBA検索エンジンで夜間バッチ等でスキャン)
[軽量インデックス (JSON / SQLite)]
↓ (高速ルックアップ)
[実務用 Visio自動化アドイン]
この設計を取り入れることで、ユーザーは待たされることなく、一瞬で目的のシェイプをカンバスにドロップできるようになる。
—
総括
Visio VBAにおけるパフォーマンスチューニングの肝は、「Visioのエンジンに無駄な仕事をさせないこと」に尽きる。
今回紹介した `Document.OpenStencil`（`OpenEx`による `visOpenRO` + `visOpenHidden`）のテクニックは、単なる小技ではなく、大規模なEnterprise環境でVisio自動化を安定稼働させるための必須の教養である。
君のプロジェクトでも今すぐこの設計を取り入れ、無駄なメモリ消費とファイルロックエラーを過去のものにしてほしい。
健闘を祈る。
