【上級プロ】巨大アセンブリ構築時におけるメモリリークを完全防止するための、COMオブジェクトの厳格な参照解放パターン
数千点規模のコンポーネントをループ処理で動的にアセンブリへ組み込み、数手先を見越した複雑な合致（Mate）を自動定義する――。この領域に踏み込んだ瞬間、開発者はVBAという言語が持つ「隠れた魔物」の牙城に直面する。
VBAのガベージコレクションは、一見すると自動でメモリを回収してくれる頼もしい機能に見える。だが、相手がSolidWorksのような重厚長大なCOMサーバーである場合、それは完全な幻想に変わる。
ループ内で`Set swComponent = swAssembly.AddComponents3(…)`や`swModel.AddMate5(…)`を無造作に叩き、変数のスコープアウトだけに頼ったコードを書いた瞬間、数分後にはメモリ使用量が右肩上がりに高騰し、沈黙とともにSolidWorksごとプロセスが強制終了する。
本稿では、VBAランタイムとSolidWorks COMレイヤーの境界線で何が起きているのかを解剖し、数千点規模の巨大アセンブリ構築をノーエラーで完遂するための「極限のメモリ管理パターン」を提示する。
—
1. なぜVBAは巨大アセンブリでクラッシュするのか？
COMラッパーと参照カウンタの闇
VBAからSolidWorks APIを叩くとき、裏側ではCOM（Component Object Model）のインターフェースがやり取りされている。
VBAのコード内でオブジェクト変数に代入（`Set`）を行うたび、SolidWorks側のCOMオブジェクトの参照カウンタ（Reference Counter）がインクリメントされる。
問題は、VBAが自動で行う解放のタイミングの曖昧さだ。
特に以下のようなループ構造において、VBAランタイムは即座にメモリを解放せず、プロシージャが完全に終了するまで古いCOM参照のラッパーをメモリ上に保持し続けることがある。
‘ 【アンチパターン】これでは確実にメモリリークを起こす
Dim i As Long
For i = 1 to 5000
Dim swComp As ModelDoc2
Set swComp = swAssembly.AddComponents3(…)
‘ 毎回新しいCOMラッパーが生成され、参照カウンタが積み重なるが、
‘ ループ内では前の参照が適切にデクリメントされないケースが生じる
Next i
この結果、メモリリーク（正確にはCOMインターフェースの解放遅延およびリソース枯渇）が発生し、SolidWorksのヒープ領域が破綻する。
—
2. 巨大アセンブリ構築におけるメモリ管理の鉄則
メモリリークを完全に根絶するためには、以下の3つの鉄則をコードに厳格に強制しなければならない。
1. 明示的な変数の初期化（`Nothing`代入）
使い終わったCOMオブジェクトは、ループの1イテレーション毎に必ず `Set xxx = Nothing` を明示する。
2. `Variant` 型の排除と強型付け
配列や戻り値に `Variant` を使うと、COMオブジェクトのライフサイクル管理がVBAの曖昧な内部処理に委ねられてしまう。必ず具体的な型（`Component2`, `Mate2` 等）を宣言する。
3. API呼び出し単位のスコープ分離（ローカルプロシージャ化）
巨大な処理を一つのプロシージャに記述せず、コンポーネントの配置や合致の定義といった単位でプライベートプロシージャに分割し、スコープを抜けた瞬間にローカル変数の参照が確実に落ちる構造を作る。
—
3. 【実装コード】完全解放パターンによるアセンブリ自動構築エンジン
以下に、数千点規模のコンポーネント配置と合致定義に耐えうる、実戦投入仕様のVBAコードを示す。各オブジェクトのライフサイクルがどのように制御されているかに注目してほしい。
Option Explicit
‘ —————————————————————–
‘ 巨大アセンブリ自動構築メインプロシージャ
‘ —————————————————————–
Sub ExecuteMassAssemblyGeneration()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swAssy As SldWorks.AssemblyDoc
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
If swModel Is Nothing Then
MsgBox “アクティブなアセンブリが開かれていません。”, vbCritical
Exit Sub
End If
If swModel.GetType() <> swDocumentASSEMBLY Then
MsgBox “対象ドキュメントはアセンブリではありません。”, vbCritical
Exit Sub
End If
Set swAssy = swModel
‘ 処理開始前のパフォーマンス最適化（画面描画・再計算の停止）
swApp.CommandInProgress = True
swModel.EditRebuild3
Dim i As Long
Dim targetPath As String
targetPath = “C:\MyComponents\Standard_Bolt.sldprt”
On Error GoTo ErrorHandler
‘ 例として1000回ループ（数千点規模を想定）
For i = 1 to 1000
‘ ループ内の処理を別プロシージャに逃がし、スコープ単位でCOM参照を完全に焼却する
Call InsertAndMateSingleComponent(swApp, swAssy, targetPath, i 0.01, 0, 0)
‘ 100回ごとに強制ガベージコレクションを促す（VBAの限界を補う）
If i Mod 100 = 0 Then
DoEvents
End If
Next i
CleanUp:
‘ 最終的なルートオブジェクトの解放
Set swAssy = Nothing
Set swModel = Nothing
Set swApp.CommandInProgress = False
Set swApp = Nothing
MsgBox “アセンブリの自動構築が正常に完了しました。”, vbInformation
Exit Sub
ErrorHandler:
MsgBox “エラーが発生しました: ” & Err.Description, vbCritical
Resume CleanUp
End Sub
‘ —————————————————————–
‘ 単一コンポーネントの配置と合致定義（スコープ分離によるメモリ防衛）
‘ —————————————————————–
Private Sub InsertAndMateSingleComponent(ByRef swApp As SldWorks.SldWorks, _
ByRef swAssy As SldWorks.AssemblyDoc, _
ByVal compPath As String, _
ByVal x As Double, _
ByVal y As Double, _
ByVal z As Double)
Dim swModelDoc As SldWorks.ModelDoc2
Dim swComp As SldWorks.Component2
Dim swMateFeat As SldWorks.Feature
‘ 1. コンポーネントの挿入
‘ AddComponents3 は Variant 型の配列を返すため、取り扱いに注意が必要
Dim vComps As Variant
vComps = swAssy.AddComponents3(compPath, x, y, z)
If IsEmpty(vComps) Then Exit Sub
‘ 配列の先頭からComponent2インターフェースを取得
Set swComp = vComps(0)
If Not swComp Is Nothing Then
‘ ここで合致（Mate）の追加処理を行う場合も同様にオブジェクトを局所化する
‘ 例: 参照面同士の合致など（省略形）
‘ Dim swMateData As SldWorks.Mate2
‘ Set swMateData = swAssy.CreateMateData(…)
‘ Set swMateFeat = swAssy.CreateMate(swMateData)
End If
‘ =================================================================
‘ 【極限の知見】ローカル変数の明示的解放（Destruction）
‘ =================================================================
‘ オブジェクト変数を Nothing に明示することで、COM参照カウンタを即座にデクリメントする
Set swMateFeat = Nothing
Set swComp = Nothing
‘ 配列自体のメモリ解放
Erase vComps
‘ 注意: 挿入したドキュメント自体のハンドルがメモリに残るのを防ぐため、
‘ 不要なドキュメントが開いたままになっていないか適宜確認する
End Sub
—
4. チーフアーキテクトからの実務的提言
上記のコードを見て、「ここまで厳格に `Set = Nothing` を書く必要があるのか？」と疑問に思うかもしれない。
答えは 「ノーコードツールや単純なマクロであれば不要だが、実務で数千パーツを扱う自動化においては、これを行わないシステムは確実に破綻する」 だ。
さらに踏み込んだ実運用上のベストプラクティスを以下に挙げる。
- `DoEvents` の諸刃の剣
長大なループ内で `DoEvents` を挟むことでUIのフリーズを防げるが、ユーザーが意図しないタイミングでSolidWorksの画面を触ってしまい、COMコンテキストがロストする危険性がある。巨大アセンブリ構築中は `swApp.CommandInProgress = True` を必ず設定し、ユーザー入力を完全にロックすること。
- VBAの限界を見極めたV.NETへの移行判断
もし対象のアセンブリが5,000点を超え、複雑なマトリクス計算や外部DB連携が絡む場合、VBAというサンドボックス環境のメモリ管理能力は限界を迎える。その際は、本稿で解説したオブジェクトライフサイクルの概念をそのままスライドさせ、VB.NET（COM Interop / SolidWorks API）へのリプレイスを強く推奨する。VB.NETであれば `Marshal.ReleaseComObject()` を用いた厳密な参照解放の制御が可能となる。
メモリリークとの戦いは、アーキテクトの技量が最も色濃く反映される領域である。
細部に宿る神を信じ、確実なリソース管理のコードを組み上げることで初めて、真に安定した超大規模設計自動化システムが完成する。
