SolidWorks APIの深淵：フィーチャ走査の作法を極める
SolidWorksの自動化に足を踏み入れた諸君、歓迎する。
「とりあえず動くコード」で満足しているうちは、まだエンジニアとは呼べない。SolidWorks APIは、メモリ管理とオブジェクトの参照関係において、極めて繊細な作法を要求するシステムだ。
今回は、業務自動化の第一歩であり、かつ最も奥が深い「フィーチャ走査」について伝授する。ただ名前を出すだけなら誰でもできる。現場で戦える、堅牢で再利用性の高いコードを書くための思考をインストールせよ。
—
なぜ「単なるループ」ではいけないのか
多くの初心者が陥る罠は、`GetFirstFeature` から `GetNextFeature` を繰り返すだけの「浅いループ」だ。これでは、アセンブリや複雑なマルチボディパーツにおいて、階層構造（サブフィーチャ）を見落とす。
実務レベルでは、以下の3点を意識しなければならない。
1. 再帰構造の理解: フィーチャはツリー状に枝分かれしている。単一ループで全走査は不可能だ。
2. オブジェクトの解放: VBAは参照カウント方式だ。特にAPIオブジェクトはメモリを食う。不要な参照は即座に開放する意識が、大規模アセンブリを扱う際の安定性に直結する。
3. エラーハンドリング: ファイルが開いていない、あるいはフィーチャが壊れている（抑圧状態など）ケースを想定せよ。
—
【プロダクションコード】堅牢なフィーチャ走査の実装例
このコードは、メインのループと、再帰的な処理を分離している。これが保守性を高める唯一の解だ。
Option Explicit
‘ ———————————————————
‘ メイン処理：現在のパーツからフィーチャを走査する
‘ ———————————————————
Public Sub ExportFeatureList()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swPart As SldWorks.PartDoc
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
‘ ドキュメントが開かれているか厳格にチェック
If swModel Is Nothing Then
MsgBox “対象のドキュメントが開かれていません。”, vbCritical
Exit Sub
End If
Debug.Print “— フィーチャ走査開始: ” & swModel.GetTitle & ” —”
‘ ルートフィーチャを取得して再帰処理へ
Dim swFeat As SldWorks.Feature
Set swFeat = swModel.FirstFeature
TraverseFeatures swFeat, 0
Debug.Print “— 走査完了 —”
End Sub
‘ ———————————————————
‘ 再帰処理：フィーチャツリーを深く潜り込む
‘ ———————————————————
Private Sub TraverseFeatures(ByRef swFeat As SldWorks.Feature, ByVal level As Integer)
Dim currentFeat As SldWorks.Feature
Set currentFeat = swFeat
Do While Not currentFeat Is Nothing
‘ イミディエイトウィンドウに詳細を出力
Debug.Print String(level 2, ” “) & “Name: ” & currentFeat.Name & ” | Type: ” & currentFeat.GetTypeName2
‘ サブフィーチャがある場合は再帰的に呼び出す
Dim swSubFeat As SldWorks.Feature
Set swSubFeat = currentFeat.GetFirstSubFeature
If Not swSubFeat Is Nothing Then
TraverseFeatures swSubFeat, level + 1
End If
‘ 次の兄弟フィーチャへ進む
Set currentFeat = currentFeat.GetNextFeature
Loop
End Sub
—
コードの解説と「設計の哲学」
1. 再帰的アプローチ（Recursive Approach）
`TraverseFeatures` メソッドの中で自分自身を呼び出している点に注目してほしい。これにより、フォルダ階層や、特定のフィーチャ内にネストされたサブフィーチャを漏らさず捕捉できる。これが「プロのコード」と「素人のコード」の分岐点だ。
2. オブジェクトのライフサイクル
このコードでは明示的に `Set = Nothing` を行わない部分があるが、VBAのスコープ設計上、関数を抜ければ参照は消える。ただし、非常に巨大なアセンブリを走査する場合は、ループ内で明示的に `Set currentFeat = Nothing` を行うことで、メモリリークを確実に防ぐことができる。
3. 実務への応用に向けたアドバイス
このリストを出力するだけでは自己満足だ。次はここから一歩進み、「特定のフィーチャタイプ（例: `Extrusion`）だけを抽出し、そのパラメータをCSVやDBに書き出す」という処理に発展させるべきだ。
- データベース連携: `ADODB`ライブラリを使い、AccessやSQL Serverにフィーチャ情報をログとして蓄積せよ。これにより、「どのパーツでどのフィーチャが頻出しているか」という設計の傾向分析が可能になる。
- 保守性の極意: フィーチャ名はユーザーが変更する可能性がある。コード側では「名前」ではなく、「`GetTypeName2`」でタイプを判定し、処理を分岐させるのが堅牢な設計だ。
最後に
SolidWorks APIを使いこなすということは、ソフトウェアの裏側にある「ツリー構造」を支配するということだ。このコードをベースに、君自身の「武器」となるツールを組み上げてほしい。
もしコードが期待通りに動かないなら、それはSolidWorksのせいではない。君のオブジェクト参照の設計が、まだ甘いだけだ。精進せよ。
