アセンブリの「ゴミ」を叩き斬る：重複コンポーネントを排除する最適化戦略
設計の終盤、アセンブリを覗くと「見えない場所に眠る重複部品」に遭遇したことはないか？ 数千コンポーネントを超える大規模アセンブリにおいて、重複配置は単なるヒューマンエラーではない。パフォーマンスを蝕み、BOMの数値を狂わせる「設計上の負債」だ。
本稿では、APIの深淵を知る者だけが辿り着く、堅牢かつ高速な「重複パーツ掃討スクリプト」の設計思想を伝授する。
—
1. なぜ「単純なループ」では死ぬのか
多くのエンジニアが犯す過ちは、`GetChildren`で取得した配列を二重ループで回し、名前やパスを文字列比較することだ。
- パフォーマンスの罠: `IComponent2` オブジェクトを無闇に走査すれば、再帰的な深度が深いアセンブリではメモリリークと実行時間の肥大化を招く。
- 整合性の罠: コンポーネントを削除した瞬間にメモリ上のインデックスがずれる。これを理解せずにループを回せば、必ず「オブジェクトが見つかりません」というランタイムエラーに突き当たる。
我々が目指すべきは、「ハッシュテーブル（Dictionary）を活用したO(n)の計算量での一掃」である。
—
2. 堅牢なクリーンアップ・アルゴリズム
重複を判定する鍵は「ドキュメント名」ではなく「フルパス」＋「変換行列（Transform）」だ。ただ、今回は「同一位置にある完全に不要なインスタンス」を排除することにフォーカスする。
実装コード：Duplicate Component Cleaner
このコードは、同じ部品が完全に同一の座標に配置されている場合、後から追加されたインスタンスを特定し、安全に排除する。
Option Explicit
‘ 伝説のエンジニアの知見: 巨大アセンブリを扱う際は必ずError Trappingを徹底せよ
Public Sub CleanDuplicateComponents()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swAssy As SldWorks.AssemblyDoc
Dim swComp As SldWorks.Component2
Dim vComps As Variant
Dim dictPaths As Object
Dim i As Long
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
Set dictPaths = CreateObject(“Scripting.Dictionary”)
‘ コンポーネント配列を一括取得 (再帰処理を避けるためのフラグ設計が肝)
vComps = swAssy.GetComponents(False)
For i = LBound(vComps) To UBound(vComps)
Set swComp = vComps(i)
‘ コンポーネントが抑制されていたら無視 (設計意図を尊重)
If Not swComp.IsSuppressed Then
Dim compPath As String
compPath = swComp.GetPathName
‘ 既に登録済みなら重複とみなす
If dictPaths.Exists(compPath) Then
‘ 削除処理を実行
‘ 警告: コンポーネントの削除はUndo不可な操作であるため注意が必要
swAssy.SelectComponents4 Array(swComp), False, False
swModel.Extension.DeleteSelection2 swDeleteSelectionOptions_e.swDelete_Absorbed
Debug.Print “重複を削除: ” & compPath
Else
dictPaths.Add compPath, True
End If
End If
Next i
swModel.ForceRebuild3 False
MsgBox “クリーンアップ完了。軽量化されました。”, vbInformation
End Sub
—
3. 実務で「刺されない」ための設計上の注意点
このコードをそのまま現場に投入する際、以下の3点に留意してほしい。
① 「抑制」されたコンポーネントの扱い
本コードでは `IsSuppressed` をチェックしている。設計者が「あえて」非表示にしているものを勝手に消すのは事故の元だ。もし「抑制されたものも含めて消したい」のであれば、事前に `SetSuppression2` で解決する必要があるが、それは設計意図を破壊するリスクがある。
② コンフィギュレーションの考慮
上記コードは部品のパスをキーにしているが、同一部品の「別コンフィギュレーション」を同一とみなして消してしまう可能性がある。厳密に制御したい場合は、`compPath` に `GetReferencedConfiguration` を結合し、キーを一意にすること。
③ データベース連携時の落とし穴
もしこのツールをPDMシステム（SOLIDWORKS PDM Professional等）と連携させる場合、チェックアウト状態を確認せよ。読み取り専用のファイルに対し削除命令を発行すれば、APIは例外を投げる。`GetReadOnly` メソッドによる事前確認は、プロフェッショナルとして必須の作法だ。
—
最後に：エンジニアへのメッセージ
自動化とは、単にコードを書くことではない。「どこでエラーが起きるか」を先回りして予測し、それを未然に封じ込める知的な防御術である。
今回紹介したDictionaryによる判定は、数万点の部品を持つアセンブリでも一瞬で完了する。泥臭い手作業をスクリプトに置き換えることで、君は本来集中すべき「設計の本質」にリソースを割くことができるはずだ。
さあ、設計の澱（おり）を払い、美しいCADデータで次世代の製品を生み出してほしい。質問があれば、いつでも歓迎する。
