SolidWorks APIの黄昏と再興：2010以前のレガシーコードを「2024」で蘇らせる技術
SolidWorksのAPIは、過去15年で劇的な進化を遂げた。しかし、現場の資産は往々にして2010年以前の「負債」に縛られている。かつての`SelectByID`を多用した、不安定で遅いマクロ。これらを2024年現在、安定稼働する現代的な設計資産へと昇華させることは、単なる修正ではない。これは「設計自動化のインフラを再構築する」というエンジニアリングだ。
本稿では、レガシーコードを駆逐し、現代的なAPI作法へとリファクタリングするための極限の知見を授ける。
—
1. 撲滅すべき「負債」の正体：SelectByIDの罠
レガシーコードで最も多いのが、旧式の `swModel.SelectByID “Face1”, “FACE”, …` といった文字列ベースの選択法だ。これは以下の致命的な欠陥を孕んでいる。
- 言語依存: ユーザーの言語設定（日本語、英語など）が変われば、文字列マッチングは即座に破綻する。
- パフォーマンスの欠如: 文字列解析は重い。また、選択状態をUIに反映させるコストは、バックグラウンド処理では無駄でしかない。
リファクタリング指針：IModelDocExtension.SelectByID2
現代の作法では、`IModelDocExtension.SelectByID2` を使用し、且つ可能な限り「Entity（面、エッジ、頂点）」を直接参照するアーキテクチャに移行しなければならない。
—
2. 実践的リファクタリング・パターン
以下は、レガシーな選択処理を、堅牢な現代APIへ書き換えるためのテンプレートである。
‘ 【リファクタリング前】不安定で文字列に依存する旧式コード
‘ swModel.SelectByID “Front Plane”, “PLANE”, 0, 0, 0
‘ 【リファクタリング後】ModelDocExtensionを用いた堅牢な実装
Public Sub SelectPlaneSecure(ByRef swModel As SldWorks.ModelDoc2, ByVal planeName As String)
Dim swExt As SldWorks.ModelDocExtension
Set swExt = swModel.Extension
‘ SelectByID2の戻り値（Boolean）を必ず判定する
‘ Append=False, Mark=0, Callout=Nothing を明示的に指定
Dim status As Boolean
status = swExt.SelectByID2(planeName, “PLANE”, 0, 0, 0, False, 0, Nothing, swSelectOptionDefault)
If Not status Then
Err.Raise vbObjectError + 1001, “Refactor”, “指定された平面が見つかりません: ” & planeName
End If
End Sub
—
3. メモリ管理とCOMの「明示的解放」の真実
VBAはガベージコレクションを自動で行うが、SolidWorksのCOMオブジェクトは別だ。特にループ内で `GetFirstFeature` 等を多用すると、メモリリークが積もり、数時間単位の自動化処理でSolidWorksがクラッシュする。
極限のルール:
1. 参照の解放: `Set swFeature = Nothing` をループの最後で徹底する。
2. 型指定の厳格化: `Object`型は禁止。必ず `SldWorks.Feature` 等の具象型で宣言する。
3. UI更新の抑制: `swApp.Visible = False` や `swModel.GraphicsRedraw2` の制御で描画負荷を減らす。
—
4. 2024環境で生き残るための「疎結合アーキテクチャ」
レガシーコードを保守する際、単にコードを書き換えるだけでなく、「SolidWorksのUI状態に依存しない」設計へ移行することが重要だ。
推奨される実装構造
1. 取得層: `SelectionManager` で要素を取得する際、名前ではなく `IPersistReference` や `EntityID` を活用し、モデル変更に強いコードを書く。
2. 計算層: 行列演算やジオメトリ計算は、SolidWorksのUIを通さず、MathUtility APIを使用して高速化する。
3. エラーハンドリング: `On Error Resume Next` で誤魔化すのは即刻やめる。`Err.Number` を詳細に解析し、どこのAPIで失敗したかをログに吐き出す仕組みを構築せよ。
—
5. チーフアーキテクトからの提言
2010年以前のコードが今も動いているのは、当時のエンジニアが書いたロジックが優秀だったからかもしれない。しかし、それは「今のSolidWorksが寛容であるから」に過ぎない。
- API仕様書の更新: 2024年版のAPI Helpは、廃止予定（Deprecated）のメソッドを明確に示している。`GetFirstFeature` を `GetFeature(n)` に置き換えるような地道な積み重ねが、将来のシステム維持費を劇的に削減する。
- VB.NETへの移行を検討せよ: VBAは限界にきている。COM相互運用性を最大限に活かせるVB.NET（あるいはC#）への移行は、レガシー保守から脱却するための唯一の道だ。
コードは生き物だ。放置すれば腐敗する。今日、あなたが修正したその1行が、明日、誰かの深夜残業を救うことになる。
技術を磨け。APIの向こう側にあるSolidWorksの挙動を、君自身の手で制御せよ。
