【テクニカル・上級編】【上級】大規模プロジェクトにおけるステンシルキャッシュ管理とメモリ解放 – Visio VBA解析バイブル

限界を突破するVisio自動化：大規模プロジェクトにおけるステンシルキャッシュ管理とメモリ解放の真髄

大規模なインフラ構成図や、数千のコンポーネントを包含するシステムアーキテクチャ図を自動生成するプロジェクトにおいて、エンジニアが直面する最大の壁は「アルゴリズム」ではない。それは、「Visioという巨大なCOMオブジェクトのメモリ管理」である。

数千ものマスターシェイプを含むステンシルを、ループ処理の中で次々と読み込み、操作し、閉じていく。一見、論理的に正しいコードであっても、数分後にはVisioが「応答なし」に陥り、最終的には `Out of Memory` エラーでプロセスが死滅する。これは、VBAのガベージコレクション（参照カウント方式）の限界と、Visio内部のステンシルキャッシュ機構が引き起こす、設計上の欠陥に近い現象だ。

本稿では、単なる「`Set obj = Nothing`」という初歩的な教えを捨て、Windows APIを駆使してプロセスレベルでメモリを掌握する、シニアエンジニアのための極限の知見を共有する。

1. ステンシル・リークの正体：参照カウントの罠

Visioにおけるステンシル（`Stencil`）とマスター（`Master`）は、単なるデータ構造ではない。それらは背後で重厚なC++のオブジェクトツリーを形成している。

多くの開発者が陥るミスは、`Stencil` オブジェクトを解放したつもりで、その配下の `Master` オブジェクトや、あるいは `Master` から派生した `Shape` オブジェクトへの参照を、どこかの変数やコレクション（`Collection` や `Dictionary`）に残してしまうことだ。

COM（Component Object Model）の世界では、たった一つの参照が残っているだけで、そのオブジェクトに関連する膨大なメモリ領域は解放されない。 ステンシルを閉じても、マスターへの参照がメモリ上に残っていれば、Visioは「そのステンシルはまだ使用中である」と判断し、内部キャッシュに保持し続ける。これが、大規模処理におけるメモリ肥大化の正体である。

鉄則：スコープの局所化（Scope Isolation）

メモリ管理の第一原則は、「オブジェクトの寿命を、その用途の最小単位に閉じ込めること」である。

' --- 悪い例：グローバルまたは広範なスコープでの保持 ---
Dim myStencil As Visio.Stencil
' ループ内で何度も開き、使い回そうとするが、参照が残り続ける原因になる

' --- 良い例：プロシージャ単位での完全な局所化 ---
Sub ProcessStencil(stencilPath As String)
    Dim stl As Visio.Stencil
    Dim mst As Visio.Master
    
    On Error GoTo CleanUp
    Set stl = Application.Documents.OpenStencil(stencilPath)
    
    ' マスターを取得し、操作を行う
    Set mst = stl.Masters(1)
    ' ... 何らかの高度な処理 ...

CleanUp:
    ' 明示的な解放順序：子から親へ
    Set mst = Nothing
    Set stl = Nothing ' これにより、ステンシルの参照カウントがゼロに近づく
End Sub

2. Windows APIによる「強制的なメモリ回収」

VBAの `Set obj = Nothing` は、あくまで「参照カウントを減らす」だけであり、Windows OSに対して「今すぐ物理メモリを解放せよ」と命じるものではない。大量のステンシルを処理する場合、OSのワーキングセット（Working Set）が膨れ上がり、スワップが発生してパフォーマンスが劇的に低下する。

ここで、伝説的なアーキテクトが用いる「外科手術」を導入する。`kernel32.dll` の `SetProcessWorkingSetSize` を呼び出し、プロセスが確保している物理メモリを強制的に整理させる手法だ。

実装例：メモリ・フラッシュ・プロシージャ

以下のコードは、メモリ消費が限界に達した際に、Visioプロセスに対してメモリの再編を促すための実装である。

' --- Windows API Declarations ---
If VBA7 Then
    ' 64bit環境（Office 64bit）用
    Declare PtrSafe Function SetProcessWorkingSetSize Lib "kernel32" ( _
        ByVal hProcess As LongPtr, _
        ByVal dwMinimumWorkingSetSize As LongPtr, _
        ByVal dwMaximumWorkingSetSize As LongPtr) As Long
    Declare PtrSafe Function GetCurrentProcess Lib "kernel32" () As LongPtr
Else
    ' 32bit環境用
    Declare Function SetProcessWorkingSetSize Lib "kernel32" ( _
        ByVal hProcess As Long, _
        ByVal dwMinimumWorkingSetSize As Long, _
        ByVal dwMaximumWorkingSetSize As Long) As Long
    Declare Function GetCurrentProcess Lib "kernel32" () As Long
End If

''' <summary>
''' プロセスのワーキングセットを強制的に整理し、メモリ圧迫を緩和する
''' </summary>
Sub ForceMemoryFlush()
    Dim hProcess As LongPtr
    Dim result As Long
    
    On Error Resume Next
    hProcess = GetCurrentProcess()
    
    ' MinimumとMaximumの両方に -1 を指定することで、
    ' OSに対して「現在のワーキングセットを整理せよ」という指示を送る
    ' ※これは「メモリを空にする」のではなく「不要なページを物理メモリから退避させる」動作に近い
    result = SetProcessWorkingSetSize(hProcess, -1, -1)
    
    If Err.Number <> 0 Then
        Debug.Print "Memory Flush Failed: " & Err.Description
    Else
        Debug.Print "Memory Flush Executed Successfully."
    End If
    On Error GoTo 0
End Sub

*注意：この関数は強力だが、頻繁に呼び出しすぎると、次にメモリが必要になった際にOSによるページイン（読み込み）が発生し、逆に低速化する。大量のステンシルを10個処理するごとに1回、といった「戦略的な呼び出し」が肝要だ。*

3. アーキテクチャ設計：Worker Patternの採用

大規模システムにおいて、一つの巨大な `Sub` で全ての処理を行うのは、設計上の自殺行為である。メモリ管理を極限まで高めるには、「Worker Pattern（ワーカー・パターン）」を採用すべきだ。

これは、各ステンシルの処理を独立したプロシージャ（またはクラスモジュール）に分離し、そのプロシージャが終了した瞬間に、その中で生成された全オブジェクトのスタックが破棄される仕組みを利用する。

極限の設計構造

' --- メインコントローラー ---
Sub OrchestrateLargeScaleTask()
    Dim stencilList As Variant
    Dim i As Long
    
    stencilList = Array("C:\Templates\Network.vssx", "C:\Templates\Server.vssx", "C:\Templates\Storage.vssx")
    
    For i = LBound(stencilList) To UBound(stencilList)
        ' 各ステンシルの処理を「隔離された空間」で実行
        ExecuteIsolatedTask stencilList(i)
        
        ' 1ループごとに、メモリの健全性をチェックし、必要に応じてフラッシュ
        If i Mod 5 = 0 Then 
            ForceMemoryFlush
        End If
    Next i
    
    MsgBox "All tasks completed with optimal memory footprint."
End Sub

' --- 隔離されたワーカー ---
Private Sub ExecuteIsolatedTask(path As String)
    ' このプロシージャ内のローカル変数は、終了時に確実に参照カウントが減る
    Dim stl As Visio.Stencil
    Dim master As Visio.Master
    
    On Error GoTo ErrHandler
    
    Set stl = Application.Documents.OpenStencil(path)
    ' ... 高度なロジック ...
    
    ' 明示的な解放
    Set master = Nothing
    Set stl = Nothing
    Exit Sub

ErrHandler:
    ' エラー時も必ず解放を試みる
    Set master = Nothing
    Set stl = Nothing
    Debug.Print "Error in task: " & path & " - " & Err.Description
End Sub

結論：エンジニアリングの真髄

Visio VBAによる大規模自動化は、単なるスクリプト作成ではない。それは、「不完全なCOM環境において、いかにしてリソースの整合性を保ち、予測可能な動作を実現するか」という、極めて高度なシステムプログラミングの領域である。

1. オブジェクトの階層を意識せよ。 親を消す前に、必ず子を、そして孫を明示的に `Nothing` にせよ。
2. スコープを最小化せよ。 長いプロシージャは悪である。処理を細分化し、スタックの破棄を利用せよ。
3. OSの力を借りよ。 VBAの限界を感じたら、Windows APIを用いてプロセスレベルで介入せよ。

これらの知見を血肉とした時、君の書くコードは、単なる「動くツール」から、エンタープライズ環境に耐えうる「堅牢なシステム」へと昇華する。