SolidWorks VBAを掌握せよ：クラスモジュールで構築する「メンテナンスフリー」な自動化アーキテクチャ
SolidWorks APIを扱う現場で、数百行の「スパゲッティコード」を積み重ねていないだろうか。
「とりあえず動けばいい」と書いたプロシージャは、半年後の設計変更やAPIのマイナーアップデートで必ず負債となる。特にパーツ生成のようなフィーチャ操作を伴う処理において、標準モジュールにコードを詰め込むのは、地雷原を裸足で歩くようなものだ。
本稿では、プロフェッショナルとして生き残るための「オブジェクト指向によるフィーチャ生成の抽象化」を伝授する。
—
なぜ「手続き型」ではいけないのか
多くのエンジニアが陥る罠は、`SelectByID2`や`CreateFeature`を羅列するだけの「命令の羅列」だ。これには以下の欠陥がある。
1. コンテキストの不整合: どのフィーチャがどのスケッチを参照しているか、メモリ上のポインタ管理が曖昧になる。
2. 再利用性の欠如: 「押し出し」や「カット」のロジックが埋め込まれ、他のプロジェクトで使い回せない。
3. デバッグの困難さ: 途中でエラーが発生した際、どの段階でモデルが壊れたのか追跡できない。
これらを解決する唯一の解が、「フィーチャをオブジェクトとして捉え、カプセル化すること」だ。
—
設計思想：フィーチャ生成を「サービス」として切り出す
今回のアーキテクチャでは、フィーチャ生成ロジックを「サービス層」としてクラスモジュールに分離する。
- ModelCoreクラス: SolidWorksのアプリケーションインスタンスを保持し、基盤となる処理を担当。
- FeatureBuilderクラス: 個別のフィーチャ（押し出し、カット等）の生成ロジックを抽象化。
これにより、メインのロジックは「何を作りたいか（What）」を記述するだけで、「どう作るか（How）」はクラス内部に隠蔽される。
—
【実践】プロダクションコード：フィーチャ生成の抽象化
1. サービスの基盤となる `clsPartBuilder` (クラスモジュール)
まずはSolidWorks本体をラップし、安全にフィーチャを操作するための基盤を作る。
‘ clsPartBuilder クラスモジュール
Option Explicit
Private swApp As SldWorks.SldWorks
Private swModel As SldWorks.ModelDoc2
Public Sub Initialize(app As SldWorks.SldWorks, model As SldWorks.ModelDoc2)
Set swApp = app
Set swModel = model
End Sub
‘ フィーチャ生成時のエラーハンドリングを一括管理するラッパー
Public Sub CreateExtrude(depth As Double, sketchName As String)
Dim swFeatMgr As SldWorks.FeatureManager
Set swFeatMgr = swModel.FeatureManager
‘ プロダクションコードでは、ここで詳細なバリデーションを行う
If swModel Is Nothing Then Err.Raise vbObjectError + 1, , “モデルが未定義です”
swModel.SelectByID2 sketchName, “SKETCH”, 0, 0, 0, False, 0, Nothing, 0
swFeatMgr.FeatureExtrusion2 True, False, False, 0, 0, depth, depth, _
False, False, False, False, 0, 0, False, False, False, False, True, True, True
End Sub
2. クライアントコード（メイン処理）
呼び出し元は、極めてシンプルで宣言的になる。
‘ 標準モジュール
Sub Main()
Dim builder As New clsPartBuilder
builder.Initialize Application.SldWorks, Application.SldWorks.ActiveDoc
‘ ここには「何をするか」だけを書く
On Error GoTo ErrorHandler
builder.CreateExtrude 0.05, “Sketch1”
Exit Sub
ErrorHandler:
MsgBox “フィーチャ生成に失敗しました: ” & Err.Description
End Sub
—
堅牢な自動化のための「3つの鉄則」
1. ポインタ管理とメモリの解放
VBAは参照カウンタ方式でメモリを管理している。クラスモジュール内で`Set swModel = Nothing`を明示的に呼ぶ癖をつけよ。巨大なアセンブリを操作する際、メモリリークは致命的なクラッシュを招く。
2. データベース連携時のトランザクション管理
CSVやExcelからパラメータを読み込んでパーツを生成する場合、「読み込み」と「生成」を完全に分断せよ。
データをメモリ上の構造体（UDT: User Defined Type）またはコレクションに格納してから、それをループで処理する。ファイルIOの最中にモデルの操作を行うと、ファイルアクセス権限やロックの問題で高確率でツールが落ちる。
3. 「暗黙の選択」を排除せよ
`SelectByID2`は強力だが危険だ。可能な限り、`Feature`オブジェクトを直接取得し、そのメソッドを叩く設計に移行せよ。SolidWorks APIにおいて「選択」に依存したコードは、画面の再描画タイミングに依存する脆弱なコードの典型である。
—
最後に：エンジニアとしての矜持
自動化とは、単なる「作業の省略」ではない。設計という芸術的な作業の精度を、APIを通じて極限まで高める行為だ。
今回紹介したクラスベースの設計を取り入れることで、あなたのコードは「書き捨て」から「資産」へと昇華する。保守性の高いコードは、未来の自分を救うだけでなく、チーム全体の生産性を劇的に向上させる。
さあ、次のスクリプトを書き始める前に、一度立ち止まって考えてほしい。
「そのコードは、1年後の自分が見ても誇れるものか？」
答えがYESなら、あなたは既に一流の自動化エンジニアだ。
