SolidWorksアセンブリの「沈黙の破壊」を未然に防ぐ：参照整合性診断エンジンの設計論
SolidWorksの業務自動化において、最もエンジニアの胃を痛めるのは「共有サーバーのパス変更による参照切れ」だ。アセンブリを開いた瞬間に現れる、あの忌まわしき「構成部品が見つかりません」のダイアログ。これを一つずつ手作業で修復するのは、エンジニアの仕事ではない。
今日は、アセンブリの深層構造を走査し、参照パスを高速に診断する「健全性診断エンジン」の設計思想と実装を伝授する。
1. なぜ「力任せの走査」では失敗するのか
多くの開発者が陥る罠は、`GetComponents`を単純にループで回し、`GetPathName`を叩くというアプローチだ。だが、SolidWorksのAPIはそんなに甘くない。
- コンテキストの重さ: `GetComponent`で取得した`IComponent2`オブジェクトを闇雲に操作すれば、メモリリークとパフォーマンス低下は免れない。
- 非表示構成部品: サプレッション状態や、そもそもロードされていない構成部品をどう扱うかで診断の精度が決まる。
- 仮想コンポーネント: 実体ファイルを持たない仮想コンポーネントを「リンク切れ」と誤判定するミスが多発する。
これらを解決するためには、「オブジェクトのライフサイクルを意識した再帰処理」と「IComponent2のプロパティを賢く使い分ける」技術が不可欠だ。
2. 堅牢な診断エンジンの実装コード
以下のコードは、アセンブリ内の全コンポーネントを走査し、ファイルパスの生存確認を行うプロダクション・グレードの基幹コードだ。
Option Explicit
‘ 診断結果を格納するためのUDT（ユーザー定義型）
Private Type ComponentStatus
Name As String
Path As String
IsMissing As Boolean
End Type
Public Sub RunAssemblyDiagnostic()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swAssy As SldWorks.AssemblyDoc
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
If swModel Is Nothing Or swModel.GetType <> swDocASSEMBLY Then
MsgBox “アセンブリを開いてから実行してください。”, vbCritical
Exit Sub
End If
Set swAssy = swModel
‘ 再帰的にコンポーネントを探索
TraverseComponents swAssy.GetComponents(False)
End Sub
Private Sub TraverseComponents(vComps As Variant)
Dim i As Long
Dim swComp As SldWorks.Component2
Dim sPath As String
If IsEmpty(vComps) Then Exit Sub
For i = LBound(vComps) To UBound(vComps)
Set swComp = vComps(i)
‘ 仮想コンポーネントは診断対象外（パスを持たないため）
If Not swComp.IsVirtual Then
sPath = swComp.GetPathName
‘ ファイル存在確認のロジック
If Not FileExists(sPath) Then
Debug.Print “【警告】リンク切れ検出: ” & swComp.Name2 & ” -> ” & sPath
End If
End If
‘ 子要素があれば再帰的に掘り下げる
If swComp.GetChildrenCount > 0 Then
TraverseComponents swComp.GetChildren
End If
Next i
End Sub
‘ VBA標準機能で高速なファイル存在チェック
Private Function FileExists(path As String) As Boolean
If path = “” Then FileExists = False: Exit Function
FileExists = (Dir(path) <> “”)
End Function
3. 実務で勝つための設計の極意
このツールを「単なるスクリプト」から「業務システム」へと昇華させるためには、以下の3点を意識せよ。
A. パフォーマンスの最適化：`GetChildren`の罠
`GetComponents(False)`でアセンブリの直下を取得し、その後、再帰的に`GetChildren`を呼び出すのが鉄則だ。`True`オプション（トップレベルのみ）を使ってしまうと、深いサブアセンブリの構造を見落とす。また、コンポーネント数が多い場合は、`swComp.GetModelDoc2`を呼び出さず、`GetPathName`で済ませるのが鉄則だ。モデルドキュメントをいちいちメモリにロードさせると、診断だけで数分かかる羽目になる。
B. 外部データとの連携（ログ出力）
コンソール（イミディエイトウィンドウ）に垂れ流すだけでは、現場の運用には耐えられない。診断結果をCSVに出力するか、あるいはデータベースに「いつ、誰が、どのアセンブリで、どの部品を見失ったか」を記録するロジックを追加せよ。これが蓄積されると、「よくリンクが切れるファイルパスの傾向」が見えてくる。
C. 保守性のためのインターフェース分離
上記の `FileExists` 関数のように、機能単位でモジュールを分割しておくこと。将来的に「サーバーパスの置換ツール」へ拡張する際、診断ロジックをそのまま流用できるようにしておくのが、中級者から上級者への分かれ道だ。
最後に：なぜ我々がこれをやるのか
設計の整合性は、設計者の誇りそのものだ。マシンがやるべき単純作業を自動化し、人間は「なぜそのリンクが切れたのか」という構造的な問題解決に集中する。
このコードを叩き台に、君たちの現場の「参照地獄」を終わらせてほしい。何かあればまた問え。SolidWorks APIの深淵には、いつでも答えを用意している。
