VBAの限界を超えろ：SolidWorksアドイン開発における「アーキテクチャの真髄」
VBAで書かれたマクロが、数千行のスパゲッティコードと化し、実行のたびにメモリリークの影に怯える日々を送っていないか？
SolidWorksの業務自動化において、VBAは「プロトタイピングの王」だが、システムの拡張性と堅牢性を求めるならば、いつかはCOMアドインという「本丸」へ移行しなければならない。本稿では、VBAからVB.NET（Visual Studio）へ舵を切る際、多くのエンジニアが陥る罠と、システムを極限まで安定させるための設計思想を伝授する。
—
1. アドインの基本構造：VBAとの決別
VBAはプロセス内で実行されるスクリプトに過ぎないが、VB.NETによるアドインはSolidWorksプロセスのメモリ空間に直接介入する「動的ライブラリ（DLL）」だ。
アドインの生命線は `ISwAddin` インターフェースである。SolidWorksが起動する際、レジストリを介してこのDLLをロードし、以下の3点を初期化する。
- ConnectToSW: SolidWorksのポインタ (`SldWorks`) を取得し、自らのアイデンティティを確立する。
- DisconnectFromSW: 安全な解放処理を行う。
- UIの構築: `ICommandManager` を用いて、リボンタブやボタンを動的に生成する。
実装の要諦：COMラッパーのハンドリング
VBAでは意識しなかった「COMオブジェクトの生存期間」を設計せねばならない。`.NET` のガベージコレクション（GC）は賢いが、SolidWorksのようなCOMサーバーは、参照カウントがゼロにならなければメモリを解放しない。
—
2. メモリ最適化とオブジェクト解放の極意
VBAで `Set swApp = Nothing` を叩いて満足しているなら、それは甘い。VB.NETでは、`Marshal.ReleaseComObject` を使いこなすことが「呼吸をするのと同じくらい当然」でなければならない。
‘ メモリリークを防ぐための定石：COMオブジェクトの明示的解放
Public Sub ReleaseObject(ByVal obj As Object)
Try
If obj IsNot Nothing AndAlso System.Runtime.InteropServices.Marshal.IsComObject(obj) Then
System.Runtime.InteropServices.Marshal.ReleaseComObject(obj)
End If
Catch ex As Exception
‘ ログ出力: 致命的なエラーはここでキャッチする
Finally
obj = Nothing
End Try
End Sub
シニアエンジニアの知見:
ループ内で `ModelDoc2` や `Feature` を取得する際、都度オブジェクトが生成される。これを放置すれば、大規模アセンブリを操作するだけでメモリは枯渇する。「取得したオブジェクトは、使い終わったら即座に解放する」。これがアドイン開発における唯一の鉄則だ。
—
3. リボンUIへの「架け橋」
VBAのマクロボタンは、ユーザーが個別にマクロファイルを指定する必要がある。一方、アドインはSolidWorks起動時に自動的にリボンUIを構築する。
‘ ICommandGroupを用いたリボンボタンの動的登録
Dim cmdGroup As ICommandGroup = iCmdMgr.CreateCommandGroup(1, “自動化ツール”, “自動化ツール”, “tooltip”, -1)
cmdGroup.LargeIconList = “icon_large.bmp”
cmdGroup.SmallIconList = “icon_small.bmp”
‘ コマンドの追加
Dim cmdId As Integer = cmdGroup.AddCommandItem2(“自動図面作成”, 0, “図面を自動生成します”, “自動生成”, 0, “RunDrawingMacro”, “EnableDrawingMacro”, 1, 0)
cmdGroup.Activate()
このコードにより、ユーザーは「マクロファイルの場所」を意識することなく、SolidWorksの一部として機能を利用できる。
—
4. デバッグの技術：プロセスを制御下に置く
VBAの「デバッグ実行」に慣れた層が最も苦労するのが、アドインのデバッグだ。Visual Studioのプロジェクトプロパティで以下を設定せよ。
1. 開始アクション: 「外部プログラムの開始」を選択し、`sldworks.exe` のパスを指定する。
2. コマンド引数: `/e` (SolidWorksを空の状態で起動) を付与する。
3. レジストリ: アドインを開発環境で登録するために、`regasm` コマンドを用いる（またはプロジェクト設定で「COM相互運用機能の登録」を有効にする）。
これにより、F5キーを押すだけでSolidWorksが立ち上がり、ブレークポイントでコードが停止する。「VBAの即時実行ウィンドウ」の代わりに「Visual Studioのイミディエイトウィンドウ」を使いこなす。 これが次のステージへの鍵だ。
—
結びに：なぜ「今」移行すべきか
VBAは、個人の生産性を上げる道具としては優秀だ。しかし、組織の標準化、保守性、そして将来のAI駆動型エンジニアリングへの適応を考えたとき、VBAは明らかにボトルネックとなる。
VB.NETへの移行は、単なる言語の乗り換えではない。「SolidWorksのプロセスを完全に制御下に置く」という、エンジニアとしてのスタンスの転換である。
もしあなたが、明日誰が触っても壊れない堅牢な自動化システムを構築したいと願うなら、今すぐVisual Studioを開き、`ISwAddin` の実装から始めてほしい。その先には、VBAでは決して到達できなかった、自動化の「深淵」が待っている。
—
本稿が、貴殿の設計自動化におけるアーキテクチャの羅針盤となれば幸いである。
