【極限の設計】SOLIDWORKS API バージョン差異を抹消する「抽象化ラッパー」アーキテクチャ
製造業の現場において、設計環境は常に「混沌」としている。
最新のSOLIDWORKS 2024を導入している設計部もあれば、安定性を優先して2022を使い続けている生産技術部もある。このバージョン混在環境（Heterogeneous Environment）において、単一のVBAマクロを配布することは、エンジニアリングにおける「自殺行為」に等しい。
あるバージョンでは動作するメソッドが、次のバージョンでは廃止（Deprecated）されている。あるいは、新しいAPIが追加されたことで、古いバージョンの参照設定（Type Library）がコンパイルエラーを吐き出す。
本稿では、単なる「動くコード」を書くレベルを超え、どのようなバージョン差異も吸収し、メモリリークを極限まで抑え込み、保守性を極限まで高めるための「抽象化ラッパー設計」の真髄を解説する。
1. 早期バインディングの罠：なぜ「参照設定」に頼るな
多くの開発者が陥る罠は、VBAの「参照設定（Early Binding）」への過度な依存である。
`Dim swApp As SldWorks.SldWorks`
この一行は、開発中のIntelliSense（入力補完）には極めて有用だ。しかし、これは特定のバージョンのType Library（TLB）にコードを硬直化（Hard-coding）させることを意味する。バージョンの異なる環境にこのファイルを持ち込んだ瞬間、参照不可エラー、あるいは実行時エラーの地獄が幕を開ける。
プロフェッショナルが取るべき戦略は、「インターフェースは早期バインディングで開発し、実行時は動的バインディング（Late Binding）へ委ねる」というハイブリッド・アプローチである。
2. アーキテクチャ設計：Feature Detection（機能検知）パターン
「バージョン番号を確認して処理を分岐させる」という設計は、下策だ。なぜなら、SOLIDWORKSのバージョンアップはAPIの破壊的変更を伴うことがあり、バージョン番号とメソッドの有無が必ずしも一致しないからだ。
真に堅牢なシステムは、バージョンではなく「機能（Capability）の有無」を検知する。これを「Feature Detection」と呼ぶ。
ラッパー・クラスの構造
以下の設計思想に基づき、`DrawingManager` という抽象化クラスを構築する。
1. Core Interface: 共通して使用する基本操作を定義。
2. Dynamic Dispatcher: メソッドの存在を確認してから実行する安全な呼び出し機構。
3. Version-Specific Logic: 特定のバージョンでしか存在しない高度な図面操作（例：新しい注釈機能など）をカプセル化。
3. 実装例：堅牢な Drawing Wrapper クラス
以下に、VBAでの実装例を示す。これは、単なるコードの断片ではなく、一つのアーキテクチャの骨組みである。
Class Module: `CDrawingWrapper`
' ==============================================================================
' Class: CDrawingWrapper
' Description: SOLIDWORKS Drawing操作の抽象化ラッパー
' Purpose: バージョン差異を吸収し、安全なAPI呼び出しとメモリ管理を行う
' ==============================================================================
Option Explicit
Private swApp As Object ' SldWorks.Application (Late Binding)
Private swModel As Object ' SldWorks.ModelDoc2
Private swDraw As Object ' SldWorks.DrawingDoc
' --- プロパティ ---
Public Property Get SwApp() As Object
Set SwApp = swApp
End Property
' --- 初期化メソッド ---
' @description: SOLIDWORKSのインスタンスを確立する
' @return: 成功すればTrue
Public Function Initialize() As Boolean
On Error Resume Next
' 実行中のSOLIDWORKSを取得、なければ新規起動を試みる
Set swApp = GetObject(, "SldWorks.Application")
If swApp Is Nothing Then
Set swApp = CreateObject("SldWorks.Application")
End If
If swApp Is Nothing Then
Initialize = False
Exit Function
End If
Initialize = True
On Error GoTo 0
End Function
' @description: 現在のドキュメントをDrawingDocとしてセットアップする
Public Function SetupDrawing() As Boolean
On Error Resume Next
Set swModel = swApp.ActiveDoc
' ドキュメントが空、または図面でない場合は失敗
If swModel Is Nothing Then
SetupDrawing = False
Exit Function
End If
' ドキュメントタイプを確認 (図面は3)
If swModel.GetType <> 3 Then
SetupDrawing = False
Exit Function
End If
Set swDraw = swModel
SetupDrawing = True
On Error GoTo 0
End Function
' --- 安全なAPI呼び出しエンジン (The Core) ---
' @description: メソッドの存在を確認してから実行する。
' @param method_name: 呼び出したいメソッド名
' @param args: 引数（可変長引数として扱うための工夫が必要）
' @return: 実行結果
' Note: VBAの制約上、完全な可変長引数Dispatchは困難なため、
' 主要なメソッドごとにラップした専用の安全メソッドを定義するのが定石。
Private Function SafeCall(ByRef targetObj As Object, ByVal methodName As String) As Boolean
' 注意: 実運用では、TypeLibの情報を解析するのではなく、
' 実行時エラーのトラップを利用して「存在しないメソッド」を検知する。
On Error Resume Next
Dim dummy As Object
' 存在確認のためのダミー呼び出し（実際にはエラーハンドリングで制御）
' ここでは簡略化のため、エラートラップによる存在確認の概念を示す
On Error GoTo 0
End Function
' @description: 【重要】バージョン依存の注釈操作を安全に行う
' @param annotationType: 注釈の種類
Public Sub SafeAddNote(ByVal x As Double, ByVal y As Double, ByVal text As String)
On Error Resume Next
' 例: SOLIDWORKS 2024で追加された新メソッドを想定
' 旧バージョンではここでエラーが発生するが、Resume Nextによりクラッシュを防ぐ
swDraw.InsertNote text, x, y
If Err.Number <> 0 Then
' エラーが発生した場合、レガシーな手法でフォールバック
Debug.Print "New API Failed. Falling back to Legacy Method. Error: " & Err.Description
' レガシーな注釈挿入ロジックをここに記述
' swModel.InsertNote ...
Err.Clear
End If
On Error GoTo 0
End Sub
' --- メモリ管理（極めて重要） ---
' @description: オブジェクトの参照を完全に解放する
' @details COMオブジェクトの解放漏れは、SolidWorksのプロセス残存とメモリ肥大化の主因。
Public Sub Terminate()
On Error Resume Next
Set swDraw = Nothing
Set swModel = Nothing
Set swApp = Nothing
On Error GoTo 0
End Sub4. メモリ管理の極意：COMオブジェクトのライフサイクル
自動化エンジニアが最も軽視し、かつ最も致命的なミスを犯すのが「オブジェクトの解放」だ。
VBAはガベージコレクション（GC）を持っているが、SOLIDWORKSのような巨大なCOM（Component Object Model）アプリケーションを操作する場合、VBAのGCだけでは不十分である。`Set obj = Nothing` を忘れることは、メモリに「死体」を放置することと同じだ。
伝説的アーキテクトの鉄則：
1. Scope Management: オブジェクトは可能な限り短いスコープ内で生成し、使い終わったら即座に `Nothing` を代入せよ。
2. Explicit Release: ループ内で `DrawingDoc` や `View` を生成する場合、ループの各ステップの終わりに必ず明示的に解放せよ。
3. Process Monitoring: マクロ終了後、タスクマネージャーに `SLDWORKS.exe` が残っていないか、あるいはメモリ使用量が異常に増大していないかを監視するテストを自動化せよ。
5. Windows APIとの連携：安定性の極限へ
高度な自動化、例えば「SOLIDWORKSの動作をバックグラウンドで完全に制御する」あるいは「特定のウィンドウ状態を強制的に制御する」場合、VBAの標準機能では限界がある。
そこで、`Declare PtrSafe Function` を用いたWindows APIの呼び出しが必要となる。
' ウィンドウのフォーカス制御や、プロセスの強制終了などの低レイヤー操作
If VBA7 Then
Declare PtrSafe Function GetForegroundWindow Lib "user32" () As LongPtr
Declare PtrSafe Function SetForegroundWindow Lib "user32" (ByVal hwnd As LongPtr) As Long
Else
Declare Function GetForegroundWindow Lib "user32" () As Long
Declare Function SetForegroundWindow Lib "user32" (ByVal hwnd As Long) As Long
End If
これを用いることで、API呼び出しの失敗時にOSレベルでのリカバリ（例：SOLIDWORKSがハングアップした場合のプロセス検知と安全なクリーンアップ）が可能になる。
結論：アーキテクトとしての思考
優れた自動化エンジニアは、「コードが動くこと」に満足しない。
「コードがどのような環境でも、どのような進化を遂げた後でも、いかにエレガントに沈黙し、あるいは適応するか」を設計する。
今回紹介した「抽象化ラッパー」と「Feature Detection」の概念は、単なるテクニックではない。それは、不確実なソフトウェアの進化に対し、エンジニアリングの秩序をもたらすための「哲学」である。
貴殿の書くコードが、数年後の保守担当者に感謝されるものになることを切に願う。
