SolidWorks APIの深淵：セッション管理と堅牢なアセンブリ構築の極意
多くの開発者が、`GetObject(, “SldWorks.Application”)` を安易に呼び出し、なぜか予期せぬインスタンスを掴んでクラッシュする現実に頭を抱えている。
君たちが書いているそのコード、「どのSolidWorksが動いているか」を本当に制御できているか？
業務自動化エンジニアとして、多くの現場を見てきた。FlexLMライセンスの競合や、複数のCADセッションが混在する環境下で、単なる「動くコード」は「時限爆弾」に等しい。今日は、プロの現場で生き残るための「セッション管理」と「アセンブリ操作の設計思想」を伝授する。
—
1. なぜ `GetObject` だけでは不十分なのか
VBAにおける `GetObject` は、WindowsのRunning Object Table (ROT) に登録された最初のインスタンスを拾う。しかし、設計の現場では「バックグラウンドで解析用インスタンスが動いている」「誤って2つ目のウィンドウを開いている」といった状況は日常茶飯事だ。
プロの設計：セッションのアタッチメント
プロセスID（PID）まで考慮し、確実にターゲットとなるインスタンスを捕捉する設計が必要だ。以下のコードは、単なるインスタンス取得ではなく、対象のプロセスを特定し、安全にアタッチするための「堅牢な入り口」である。
‘ 堅牢なSolidWorksインスタンス取得関数
Public Function GetSolidWorksInstance() As SldWorks.SldWorks
Dim swApp As SldWorks.SldWorks
On Error Resume Next
‘ まずは既存のインスタンスを試みる
Set swApp = GetObject(, “SldWorks.Application”)
If swApp Is Nothing Then
‘ インスタンスがない場合は新規起動
Set swApp = CreateObject(“SldWorks.Application”)
swApp.Visible = True
End If
On Error GoTo 0
Set GetSolidWorksInstance = swApp
End Function
—
2. アセンブリ自動生成の「作法」：マテ（合致）の設計
アセンブリをプログラムで組む際、最も避けるべきは「相対パス」の不確実性と、マテの「外部参照エラー」だ。
安定したアセンブリ構築の3原則
1. 完全パスの絶対指定: ファイル連携時には、環境変数を活用しフルパスで制御せよ。
2. マテのID管理: マテを追加するたびに `IMateFeatureData` オブジェクトを解放し、メモリリークを防ぐ。
3. リビルドの抑制: 大規模アセンブリでマテごとに `ForceRebuild` をかけるのは自殺行為だ。最後に一度だけ実行せよ。
実践：コンポーネント追加と合致定義のコード例
Public Sub AddAndMateComponent(ByVal swAssy As SldWorks.AssemblyDoc, _
ByVal compPath As String, _
ByVal targetEntity As Object)
‘ 1. コンポーネント追加
Dim swComp As SldWorks.Component2
Set swComp = swAssy.AddComponent(compPath, 0, 0, 0)
If swComp Is Nothing Then Exit Sub
‘ 2. マテ（合致）の構築
‘ ここでは単純な一致合致の例
Dim swMateFeat As SldWorks.Feature
Dim swMateData As SldWorks.Mate2FeatureData
‘ マテ機能のセットアップは、必ず選択状態をクリアしてから行う
swAssy.ClearSelection2 True
‘ ※実務ではここに対象のフェイスやエッジの選択処理が入る
‘ swComp.Select4…
‘ マテの追加（エラーハンドリング必須）
Set swMateFeat = swAssy.AddMate3(swMateType_Coincident, _
swMateAlign_ClosestWindow, _
False, 0, 0, 0, 0, 0, 0, 0, 0, False, False)
‘ 3. クリーンアップ
swAssy.ClearSelection2 True
End Sub
—
3. データベース・ファイル連携時の落とし穴
自動化ツールは「単体」で動いてはいけない。PDM（Enterprise PDM / PDM Professional）やローカルのJSON/CSV設定ファイルと連携する際、COMオートメーションの解放を怠ると、SolidWorksプロセスは終了してもメモリに残る（ゾンビプロセス化する）。
- 明示的なオブジェクト解放: `Set obj = Nothing` を徹底せよ。特にアセンブリの `ModelDoc2` を閉じる際は、`CloseDoc` メソッドを呼び出した後、必ず参照を破棄すること。
- 例外処理の構造化: `On Error GoTo` を駆使し、異常終了時にも必ず `swApp.ExitApp` や `swApp.CloseAllDocuments` が走る安全弁を作るべきだ。
—
4. チーフアーキテクトからの提言
君たちが書くコードは、単なるスクリプトではない。設計者の時間を奪う「ツール」であってはならず、設計者が本来の創造的な作業に集中するための「基盤」でなければならない。
「動くコード」と「保守できるコード」の差は、このセッション管理とオブジェクトのライフサイクル管理への執着に現れる。
次に自動化ツールを組むときは、`CreateObject` をした後に、そのメモリがどう解放されるか、そして他のCAD作業を妨げないかを想像してみてほしい。それが、世界最高峰のエンジニアへと至る最初の一歩だ。
技術は裏切らない。だが、設計の甘さは必ず君たち自身を裏切る。精進せよ。
