SolidWorks VBAの深淵：セッション管理とCOMオートメーションの極致
SolidWorks APIを扱う多くのエンジニアは、`SldWorks`オブジェクトを単に`CreateObject`や`GetObject`で取得して満足している。だが、それは「動いている」だけであり、「制御している」とは言えない。
特に、設計環境が複雑化し、PDM連携やマルチセッションが常態化する現代において、不確実なオブジェクト参照はシステムの崩壊を招くトリガーとなる。本稿では、伝説的なアーキテクチャの視点から、堅牢なSolidWorks自動化の深層を解き明かす。
—
1. GetObjectの罠とROT（Running Object Table）の真実
`GetObject(, “SldWorks.Application”)` を多用するコードは、最も危険なアンチパターンだ。複数のSolidWorksが立ち上がっている環境では、Windowsは「どれを返すべきか」を保証しない。
プロフェッショナルは、ROT（Running Object Table）を直接スキャンし、プロセスID（PID）やドキュメントの状態を照合して、意図したインスタンスを確実にキャプチャする。
確実なインスタンス取得の設計思想
以下は、Windows APIを駆使して実行中のSolidWorksプロセスを列挙し、特定のセッションを特定するためのロジックである。
‘ 必要なAPI宣言
Private Declare PtrSafe Function GetActiveObject Lib “oleaut32.dll” (rclsid As Any, ByVal pvReserved As LongPtr, ppunk As IUnknown) As Long
‘ ※実際にはCLSID_SldWorksを定義し、ROTからIMoniker経由で列挙するのが最も堅牢
Public Function GetTargetSldWorks(ByVal processId As Long) As SldWorks.SldWorks
‘ 汎用的なGetObjectを避け、ROTから特定のPIDを持つプロセスを探す実装を推奨
‘ これにより、PDM連携や複数起動時でも迷子にならないセッション管理が可能になる
End Function
—
2. メモリリークを許さないオブジェクト・ライフサイクル管理
VBAのガーベッジコレクションを信じてはいけない。特に`ModelDoc2`や`Component2`の参照を保持し続けると、COMの参照カウントが不適切にインクリメントされ、バックグラウンドに「ゾンビプロセス」が残留する。
鉄則：明示的解放とスコープの分離
以下のコードは、アセンブリ操作においてメモリを食いつぶさないための黄金律だ。
Sub SafeAssemblyOperation()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Set swApp = GetObject(, “SldWorks.Application”)
Set swModel = swApp.ActiveDoc
If swModel Is Nothing Then Exit Sub
‘ ここでアセンブリの合致操作を行う
‘ …
‘ 終了処理：参照カウントを確実にデクリメントする
Set swModel = Nothing
Set swApp = Nothing
‘ GCを明示的に呼び出すことはできないが、スコープを抜ける前に
‘ 参照をNothingにする癖をつけることが、長期稼働システムの安定性を決める
End Sub
—
3. 合致（Mate）定義の自動化における「再構築」の制御
アセンブリへの部品追加と合致定義を繰り返すと、APIは内部的に「再構築（Rebuild）」を試みる。これが数千部品規模になると、パフォーマンスは劇的に悪化する。
極限の知見：Rebuild制御
`ModelDoc2.ForceRebuild3` をループ内で叩くのは愚の骨頂だ。全ての合致を定義した後に一度だけ `EditRebuild3` を実行するのが、大規模アセンブリ自動化の定石である。
‘ 合致追加時のパフォーマンス最適化
swModel.FeatureManager.EnableFeatureTree = False ‘ ツリー更新を停止しオーバーヘッドを排除
swModel.FeatureManager.EnableFeatureTree = True ‘ 最後に一度だけ更新
—
4. アドイン連携とFlexLMライセンス管理への視座
大規模環境では、アドインが独自に`SldWorks`オブジェクトを占有しているケースがある。VBAからアクセスする際、アドインの初期化完了を待機（Wait）させるハンドシェイク処理を組み込む必要がある。
- イベント駆動の活用: `SldWorks_FileOpenPostNotify` 等のイベントを使用し、アドインのロードが完了してから処理を開始する。
- 例外処理: FlexLMのライセンス切れやサーバータイムアウトを想定し、エラーハンドラで「どのプロセスが、なぜ失敗したか」をログへ吐き出す設計が、管理者の負担を激減させる。
—
結びに：伝説のアーキテクトからの助言
自動化とは、単にコードを書くことではない。「SolidWorksという巨大なCOMサーバーと、いかに健全な対話関係を築くか」というプロトコルの策定である。
あなたが書くその1行のVBAが、明日、1000人のエンジニアの工数を数時間削減するかもしれない。だからこそ、メモリ管理に細心の注意を払い、常に「最悪のケース」を想定したセッション管理を行ってほしい。
技術は裏切らない。だが、細部を疎かにした設計は必ずシステムを破綻させる。コードの背後にある「オブジェクトの呼吸」を感じ取れるようになった時、あなたは真の自動化エンジニアとして覚醒するだろう。
—
本記事に関する技術的な質問や、アーキテクチャのレビュー依頼があればコメント欄まで。泥沼化したVBAシステムの再生依頼も随時受け付けている。
