【板金設計の自動化】SolidWorks APIで挑む、規格違反を許さない「品質保証ゲートキーパー」の構築
エンジニア諸君、日々SolidWorksのAPIと格闘していることと思う。
特に「板金（Sheet Metal）」領域の自動化は、設計の初期段階でミスを潰せるかどうかが、後の製造工程での手戻りを左右する極めて重要な防波堤だ。
今回は、単に「値を取得する」だけのスクリプトではない。「設計の品質を担保し、規格外のパーツを自動で弾く」という、実務レベルの堅牢性を備えたコードを伝授する。
1. なぜ「力技の探索」が失敗するのか
多くの者が陥る罠は、`FeatureManager`を先頭からループさせ、力技でフィーチャを探そうとすることだ。これは、アセンブリや複雑な履歴を持つパーツにおいて、処理速度を著しく低下させる。
我々が狙うべきは、`SheetMetalFolder`に直接アクセスするか、`ISheetMetalFeatureData2`オブジェクトを正確にハンドリングすることだ。ここで重要なのは、「フィーチャの定義（Definition）を正しくロードし、処理後にメモリを解放する」というオブジェクトのライフサイクル管理である。
2. 規格違反を検知するエンジニアリングの要諦
板金パラメータの検証において、以下の3点を意識せよ。
- 単一のフィーチャに依存しない: `SheetMetal`フィーチャは複数存在しうる。ベースとなるフィーチャからパラメータを抽出するロジックを組むこと。
- 単位の罠（Unit Consistency）: SolidWorks APIは内部的にメートル法（メートル・ラジアン）で値を返す。定数との比較時は、必ず単位換算を噛ませるか、`ISldWorks::FormatDouble`等を活用して規格値と合わせること。
- 例外処理: `GetThickness`が失敗するケース（フィーチャが抑制されている、あるいは無効な状態）を想定し、エラーハンドリングを怠らないこと。
3. 実践：規格検証ツール（プロダクションコード）
以下は、アクティブなパーツから板金パラメータを抽出し、社内規定値と比較する堅牢な実装サンプルだ。
Option Explicit
‘ 規格定義（定数化して一元管理せよ）
Private Const TARGET_THICKNESS As Double = 0.0016 ‘ 1.6mm
Private Const TOLERANCE As Double = 0.00001 ‘ 誤差許容範囲
Public Sub ValidateSheetMetalParameters()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swFeat As SldWorks.Feature
Dim swSheetMetal As SldWorks.SheetMetalFeatureData2
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
If swModel Is Nothing Or swModel.GetType <> swDocPART Then
MsgBox “パーツファイルを開いてください。”, vbCritical
Exit Sub
End If
‘ フィーチャツリーからSheetMetalFolderを探索
Set swFeat = swModel.FirstFeature
Do While Not swFeat Is Nothing
If swFeat.GetTypeName2 = “SheetMetal” Then
Set swSheetMetal = swFeat.GetDefinition
‘ メモリ安全のために定義をロード
If swSheetMetal.AccessSelections(swModel, Nothing) Then
‘ 検証ロジック
Dim currentThickness As Double
currentThickness = swSheetMetal.Thickness
If Abs(currentThickness – TARGET_THICKNESS) > TOLERANCE Then
Debug.Print “警告: 厚みが規格外です。現在の厚み: ” & (currentThickness 1000) & “mm”
‘ ここで色を変える、あるいはログを吐き出す処理を実装する
End If
‘ 変更を加えていないためReleaseして閉じる
swSheetMetal.ReleaseSelectionAccess
End If
End If
Set swFeat = swFeat.GetNextFeature
Loop
MsgBox “検証完了：ログを確認してください。”
End Sub
4. 運用のためのアーキテクチャ設計
このコードを「ツール」として完成させるために、以下の拡張を推奨する。
1. データベース連携: `TARGET_THICKNESS`をハードコーディングせず、JSONや設定ファイル、あるいは社内のPDM上の設定ファイルから読み込むようにせよ。これにより、設計規格変更時にコードを再コンパイルする必要がなくなる。
2. 自動検知機能: ユーザーがマクロを手動実行するのではなく、`PartDoc`の`FileSavePostNotify`イベントをフックし、保存時に強制的にチェックを走らせる設計にすれば、ヒューマンエラーは限りなくゼロに近づく。
3. UI/UX: 検証に失敗した場合、単にポップアップを出すのではなく、該当のフィーチャを色付け（`SetSelectionColor`）して強調表示させることが、設計者のストレスを軽減する。
最後に：エンジニアとしての誇りを持て
「動けばいい」コードは、半年後に負債となる。
今回示したコードは、オブジェクトのライフサイクルを意識し、メモリを適切に解放する「プロの作法」に基づいている。これをベースに、貴殿の現場のルールを組み込んでほしい。
自動化の本質は、ルーチンワークを消し去ることではない。「ミスが発生しえないシステムを構築し、設計者が本質的な創造性に集中できる環境を作ること」にある。
次回の記事では、このデータを基にした「図面自動作成の自動バリデーション」について深掘りしよう。健闘を祈る。
