【テクニカル・上級編】【初心者】ステンシルを開かずにマスターシェイプの数だけを高速カウントする方法 – Visio VBA解析バイブル

Visio VBA

2026.11.14

抽象化という名の代償：ステンシル・メタデータ取得における「真の軽量化」への考察

抽象化という名の代償：ステンシル・メタデータ取得における「真の軽量化」への考察

エンジニアリングの現場において、「動くコード」を書くことは容易だ。しかし、数千、数万の資産を扱うエンタープライズ・スケールのシステムにおいて、「動く」ことと「正しく、効率的に動く」ことの間には、深淵な断絶が存在する。

多くの開発者が、Visioのステンシル（.vssx）からマスターシェイプの数を数えようとする際、あまりにも無防備なアプローチを取る。`Application.Documents.Open` を呼び出し、UIスレッドを占有させ、メモリ上に巨大なオブジェクトグラフを構築する――。これは、単なる「数えたい」という要求に対して、重火器を持ち出してアリを射殺するような、極めて非効率な振る舞いだ。

本稿では、ステンシルを「開く」という重いプロセスを回避、あるいは極限まで軽量化し、メタデータのみを高速に抽出するための、アーキテクト視点の知見を共有する。

1. 怠慢な実装が招く「リソースの枯渇」

まず、避けるべき「典型的な失敗例」を確認しておこう。

' ❌ 非効率な実装：アンチパターン
Sub NaiveCountMasters()
    Dim vsoStencil As Visio.Document
    Dim masterCount As Long
    
    ' ステンシルをフルロードし、UIに表示させてしまう
    Set vsoStencil = Application.Documents.Open("C:\Path\To\MyStencil.vssx")
    
    ' マスターの数を取得
    masterCount = vsoStencil.Masters.Count
    
    Debug.Print "Master Count: " & masterCount
    
    ' Closeを忘れる、あるいはCloseしてもメモリに残り続けるリスク
    vsoStencil.Close
End Sub

このコードの問題点は、単なる「速度」ではない。
`Documents.Open` を実行した瞬間、Visioのメインスレッドは、ファイル内のすべてのシェイプ、接続点、値、そして複雑なXML構造を解析し、メモリ上のCOMオブジェクトとして展開し始める。これがループ内で繰り返された場合、メモリ使用量は指数関数的に増大し、最終的には `Out of Memory` またはアプリケーションのハングアップを招く。

シニアエンジニアなら、「オブジェクトの生成コスト」と「ライフサイクル」を常に意識しなければならない。

2. アーキテクトの戦略：OpenExによる制御とメモリ解放の徹底

Visio VBAにおいて、どうしても `Document` オブジェクトを介さざるを得ない場合、我々に許された唯一の武器は `OpenEx` メソッドである。これに適切なフラグを渡すことで、UIへの描画コストを削ぎ落とし、バックグラウンドでの処理を可能にする。

また、COMオブジェクトのライフサイクルを制御するため、明示的な `Nothing` 代入による参照カウントの減算は、もはや作法ではなく「義務」である。

高速化されたCOMアクセス・パターン

' ✅ 最適化された実装：COMオブジェクトの制御
Sub OptimizedMasterCount()
    Dim vsoStencil As Visio.Document
    Dim masterCount As Long
    Dim stencilPath As String
    
    stencilPath = "C:\Path\To\MyStencil.vssx"
    
    On Error GoTo ErrorHandler

    ' visOpenDocked (または visOpenNoUI) を検討し、UI描画を抑制する
    ' ここでは、ユーザーの視界に入らないよう、かつ最小限のロードで開く
    ' 実際には、OpenEx の引数に visOpenDocked を指定することで、
    ' 画面への描画負荷を大幅に軽減できる。
    Set vsoStencil = Application.Documents.OpenEx(stencilPath, visOpenDocked)

    ' マスターのカウント取得（メタデータへのアクセスは比較的軽量）
    masterCount = vsoStencil.Masters.Count
    
    Debug.Print "Optimized Master Count: " & masterCount

CleanUp:
    ' 1. 文書を閉じる
    If Not vsoStencil Is Nothing Then
        vsoStencil.Close
        ' 2. オブジェクト参照を明示的に解除（重要：メモリリーク防止）
        Set vsoStencil = Nothing
    End If
    Exit Sub

ErrorHandler:
    MsgBox "Error: " & Err.Description, vbCritical
    Resume CleanUp
End Sub

3. 極限の知見：OOXML（Zip構造）への直接アプローチ

もし、君が「Visioアプリケーションすら起動させたくない」「数千のステンシルを数秒でスキャンしたい」と考えているなら、VBAの限界を超えなければならない。

現代のVisioファイル（.vssx）の正体は、XMLファイルを圧縮したOpen XML形式（OOXML）のZipアーカイブである。

真のシステム管理者やインフラエンジニアが構築する「メタデータ・スキャナー」は、VisioのCOMインターフェースを一切叩かない。代わりに、以下のプロセスを踏む。

1. `.vssx` ファイルを Zip ライブラリ（Windows APIの `Shell.Application` や、VB.NETの `System.IO.Compression`）を用いて展開する。
2. 展開された内部構造から、`masters.xml` もしくは `content_types.xml` に相当するXMLパートを特定する。
3. XMLパーサーを用いて、`` タグの数をカウントする。

これならば、Visioのプロセスを立ち上げるオーバーヘッドはゼロであり、メモリ消費はXMLのテキスト解析分のみとなる。

概念設計：外部プロセスによる高速スキャン（VB.NET/C# 思想）

VBA単体ではZip展開は重い作業だが、もしシステム間連携（Integration）を設計するなら、以下のようなアーキテクチャを提案する。

Data Layer: `.vssx` をバイナリとして読み込み、Zipストリームとして処理。
Parsing Layer: `System.Xml.Linq` 等を用い、`visio/masters.xml` 内の要素数をカウント。
Interface Layer: カウント結果のみを軽量なJSONまたはCSVでVBA側に返す。

結論：エンジニアに求められる「視座」

「ステンシルのマスター数を数える」という一見単純なタスク。
これに対して、

初級者は、ただ `Open` する。
中級者は、`OpenEx` と `Set Nothing` を使い、エラーハンドリングを実装する。
シニアエンジニアは、計算量とメモリのライフサイクルを計算し、`OpenEx` のフラグを最適化する。
伝説的なアーキテクトは、そもそもVisioを起動すること自体が非効率であることを見抜き、ファイル構造（OOXML）を直接操作する設計を提示する。

君が今書いているそのコードは、1,000回、10,000回と実行されたときに、システムを支える礎となるか、それとも崩壊の引き金となるか。

常に、オブジェクトの背後にある「重み」を感じろ。