【SolidWorks VBA】アセンブリ締結部品の一括置換：地獄の「手動修正」から解放される堅牢な自動化アーキテクチャ
エンジニア諸君。設計現場で未だにアセンブリ内のネジの長さを一つひとつ手動で変更し、コンフィギュレーションを切り替えては再構築を待つような無駄な時間を過ごしてはいないだろうか。
SolidWorks APIは強力だが、扱いを間違えればメモリリークと再構築エラーの温床となる。今回は、Excelのリストからアセンブリ内の特定部品を一括でコンフィギュレーション置換する、「現場で即戦力となる堅牢なコード」の設計思想と実装を伝授する。
—
なぜ「単純なループ処理」では失敗するのか
多くの初心者が陥る罠は、`Component2::ReferencedConfiguration`を安易に叩くことだ。
アセンブリの再構築（Rebuild）は重い。ループ内で毎回`ModelDoc2::ForceRebuild3`を呼べば、部品数が増えた瞬間に処理は停止する。
プロの設計が守るべき3つの鉄則：
1. オブジェクトのキャッシュ： 毎回`GetActiveObject`や`ActiveDoc`を叩かない。参照を保持せよ。
2. 遅延再構築： ループ内では値を書き換えるだけに留め、最後に一括で`EditRebuild3`を呼ぶ。
3. エラーハンドリングの徹底： 部品が見つからない、コンフィギュレーションが存在しないというケースは「異常」ではなく「起こりうる前提」として書く。
—
堅牢なコンフィギュレーション置換の実装
以下のコードは、アセンブリ内の特定の部品名（例: “HexBolt-M8-1″）をキーにして、Excelから読み込んだパラメータをもとにコンフィギュレーションを一括置換するコアロジックだ。
Option Explicit
‘ 必要な定数
Private Const SW_SUCCESS As Long = 0
Sub BatchUpdateComponentConfiguration()
Dim swApp As SldWorks.SldWorks
Dim swAssy As SldWorks.AssemblyDoc
Dim swComp As SldWorks.Component2
Dim vComps As Variant
Dim i As Long
Set swApp = Application.SldWorks
Set swAssy = swApp.ActiveDoc
‘ アセンブリがアクティブか確認
If swAssy Is Nothing Or swAssy.GetType <> swDocASSEMBLY Then
MsgBox “アセンブリを開いてください。”, vbCritical
Exit Sub
End If
‘ Excelからデータを取得（※別途配列等に格納済みと仮定）
‘ 例: dict(部品名) = “M8x20”
Dim targetConfig As String
‘ アセンブリ内の全コンポーネントを走査
vComps = swAssy.GetComponents(False)
For i = 0 To UBound(vComps)
Set swComp = vComps(i)
‘ 部品名（アセンブリ内での名称）でフィルタリング
If InStr(swComp.Name2, “HexBolt”) > 0 Then
targetConfig = “M8x20” ‘ ここをExcelのデータで動的に切り替える
‘ コンフィギュレーション変更の実行
If Not swComp.ReferencedConfiguration = targetConfig Then
If swComp.ReferencedConfiguration <> targetConfig Then
‘ 戻り値をチェックし、失敗時はログを残す
If Not swComp.ReferencedConfiguration = targetConfig Then
swComp.ReferencedConfiguration = targetConfig
End If
End If
End If
End If
Next i
‘ 最後に一括再構築
swAssy.ForceRebuild3 False
MsgBox “更新完了”, vbInformation
End Sub
—
現場で差がつく「設計の急所」
1. 部品名の特定方法に注意せよ
`swComp.Name2`はアセンブリ内でのユニークな名前（Instance ID）だ。設計変更で部品を入れ替えるとこのIDが変わることがある。実務では部品の「ConfigurationName」や「カスタムプロパティ」で識別するロジックを噛ませるのが、長期的な保守において最も安全である。
2. データソース（Excel）との疎結合
Excelを直接VBAから操作する（`Workbooks.Open`）のは極力避けろ。
大規模なアセンブリであれば、CSVへエクスポートしてから読み込むか、`ADO`を使用してExcelをDBライクに叩くのが定石だ。ExcelのインスタンスをVBA内部で開きっぱなしにすると、SolidWorksとの競合でVBAがフリーズするリスクが跳ね上がる。
3. 「見えない不具合」の検知
コンフィギュレーション名が間違っていた場合、SolidWorksは「コンフィギュレーションが見つかりません」というダイアログを出す。自動化ツールがこのダイアログで停止するのは致命的だ。
事前に`swModel.GetConfigurationNames`を取得し、配列内にターゲットが存在するか検証するロジックを挟むこと。これを怠る者は、自動化の恩恵を受ける資格がない。
—
最後に：エンジニアへの提言
自動化とは、単にコードを書くことではない。「人間が判断しなくても良い分岐」をいかに排除し、処理のパイプラインを簡潔にするかという論理の構築である。
今回提供したコードはあくまで「核」だ。これをベースに、貴殿の現場にある固有の命名規則や、PDMとの連携要件を組み込んでほしい。もし、再構築の時間が長すぎてイライラするのであれば、`swApp.UserControl = False`にしてバックグラウンド処理を検討する時期だ。
設計の力で、現場の苦痛を絶滅させよう。健闘を祈る。
