SolidWorks APIの深淵：同軸合致における「実行時エラー」を設計段階で無力化する極限バリデーション
SolidWorks APIを扱う多くのエンジニアが、`AddMate5`メソッドを呼び出した瞬間に発生する「HRESULT E_FAIL」という暗黒の例外に頭を悩ませている。
アセンブリ自動化において、同軸合致（Concentric Mate）は最も頻繁に実行される処理だが、実務レベルでは「半径の不一致」や「非円筒面への合致試行」という初歩的なミスが、巨大なアセンブリ再構築のプロセスを根底から破壊する。
本稿では、VBAというレガシーの皮を被った環境において、いかに堅牢なバリデーション層を構築し、システムを「落ちない」状態に保つか、そのアーキテクチャの真髄を説く。
—
1. 悲劇の発生源：盲目的なAPI呼び出しの罠
多くの初心者は、ユーザーが選択した2つの面に対し、即座に`swAssembly.AddMate5`を叩く。だが、考えてみてほしい。SolidWorksの内部エンジン（Parasolid）は、合致関係の妥当性を常に監視している。半径が0.00001mmでも異なれば、同軸合致は拒絶される。
API呼び出し後に発生するエラーを`Err.Number`で拾うのは、もはや事後処理に過ぎない。我々が目指すべきは、「不可能な合致を定義しない」ための物理的バリデーションだ。
—
2. 「型安全」を実現するジオメトリ検証ロジック
同軸合致において最低限保証すべきは以下の3点である。
1. SelectionType: 両エンティティが「面（Face）」であること。
2. SurfaceType: 面のジオメトリが「円筒面（Cylindrical）」であること。
3. RadiusValidation: 半径が許容誤差内で一致していること（または、同軸として成立する数学的条件を満たしていること）。
以下のコードは、`ISwFace`からジオメトリ情報を抽出する際のベストプラクティスだ。
‘ 伝説的アーキテクトによる、半径検証を含むバリデーション関数
Public Function IsValidConcentricPair(face1 As SldWorks.Face2, face2 As SldWorks.Face2, Optional tolerance As Double = 0.000001) As Boolean
Dim surf1 As SldWorks.Surface, surf2 As SldWorks.Surface
Dim surfType1 As Long, surfType2 As Long
Set surf1 = face1.GetSurface
Set surf2 = face2.GetSurface
‘ 1. 面のタイプを検証 (swSurfaceCylinder = 4)
surfType1 = surf1.GetType
surfType2 = surf2.GetType
If surfType1 <> 4 Or surfType2 <> 4 Then
Debug.Print “非円筒面が含まれています。”
GoTo Cleanup
End If
‘ 2. 半径の一致確認（パラメータ抽出）
Dim params1 As Variant, params2 As Variant
params1 = surf1.Parameterization
params2 = surf2.Parameterization
‘ 円筒の半径差を検証
If Abs(surf1.CylinderParams(0) – surf2.CylinderParams(0)) > tolerance Then
Debug.Print “半径が不一致です。合致不能。”
GoTo Cleanup
End If
IsValidConcentricPair = True
Cleanup:
‘ 明示的な解放 (VBAでは重要)
Set surf1 = Nothing: Set surf2 = Nothing
End Function
—
3. メモリ管理の極意：プロセスの長寿命化
SolidWorks VBAのメモリリークは、多くの場合`Dispatch`ポインタの管理不全に起因する。特にアセンブリの大量生成ループでは、`Set obj = Nothing`を徹底するだけでは不十分だ。
- インターフェースキャッシュの回避: ループ内で`ModelDoc2`や`AssemblyDoc`を繰り返し取得せず、一度取得したルートオブジェクトをモジュールレベル変数で保持せよ。
- イベントの切断: 自動化処理の開始前後に、`App.EnableEvents = False`を挟むことで、合致作成に伴う不要なRebuildイベントの発生を抑制し、パフォーマンスを劇的に向上させる。
—
4. システム間連携の視点
もし君が、ERPやPDMから吐き出されたCSVを元にアセンブリを自動構築するシステムを組んでいるなら、APIのバリデーション結果を「ログテーブル」に書き出す設計を取り入れるべきだ。
‘ エラーハンドリングのアーキテクチャ例
On Error GoTo ErrorHandler
If Not IsValidConcentricPair(f1, f2) Then
LogSystem.Write “Skipped: Invalid Geometry at Component ” & compName
Exit Sub
End If
‘ ここで初めてAddMate5を実行
swAssembly.AddMate5 …
Exit Sub
ErrorHandler:
‘ 致命的例外のキャッチ
Logger.RecordFatalError Err.Description
—
最後に：エンジニアへの提言
SolidWorks VBAは、決して「おもちゃ」ではない。そのAPIの裏側には、何十年と積み上げられたCADカーネルの重厚なロジックが存在する。
APIを呼ぶ前に、「自分は今、何に対してどんな数学的制約を与えようとしているのか」を想像せよ。半径のチェック一つを怠らないその姿勢こそが、君の構築する自動化ツールを「一過性のスクリプト」から「堅牢な生産システム」へと昇華させる唯一の道である。
コードは嘘をつかない。だが、APIは時に沈黙する。その沈黙を読み解く力こそが、我々アーキテクトの矜持だ。
