SolidWorks自動化の深淵：リビルド失敗を「可視化」し、エラーハンドリングを極める
SolidWorksの自動化において、最もエンジニアを疲弊させるもの。それは「再構築（Rebuild）エラー」である。
UI上で「フィーチャの編集」を促す真っ赤なダイアログが出るたび、スクリプトは沈黙し、メモリはリークし、無人の自動化タスクは虚しく停止する。多くの初学者は`On Error Resume Next`で思考を放棄するが、真の自動化エンジニアは、「エラーを予期し、その断末魔をログに刻む」。
今日は、APIが握っている「失敗の真実」を余すことなく抽出し、システムを堅牢にするための設計論を授ける。
—
1. なぜ「Errオブジェクト」だけでは不十分なのか
VBAの`Err`オブジェクトは、実行時エラー（例外）を捉えるためのものだ。しかし、SolidWorksのフィーチャ再構築失敗は、APIから見れば「成功した（戻り値が正常）」と判定されることが多々ある。モデルが破綻していても、APIは黙って次の行へ進む。
ここで重要になるのが、`ModelDocExtension.GetEvaluationErrors`だ。これは、再構築後に発生したエラー情報を構造的に取得する唯一の手段である。
2. 実装の核心：エラーログ生成のアーキテクチャ
以下のコードは、単なるエラーハンドリングではない。再構築プロセスをラッパー関数で囲い、失敗したフィーチャを特定してFSO（FileSystemObject）でログに書き出す、実戦的な設計である。
‘ 必要な参照設定: Microsoft Scripting Runtime
Option Explicit
Public Sub RobustRebuild(swModel As SldWorks.ModelDoc2)
Dim swExt As SldWorks.ModelDocExtension
Dim errors As Long, warnings As Long
Dim evalErrors As Variant
Dim i As Long
Set swExt = swModel.Extension
‘ 1. 再構築の実行
‘ ForceRebuildAllを使うことで、隠れた依存関係の破綻を炙り出す
swModel.ForceRebuild3 False
‘ 2. 評価エラーの取得
evalErrors = swExt.GetEvaluationErrors
If Not IsEmpty(evalErrors) Then
‘ エラーが検知された場合、ログ出力関数へ
WriteDebugLog “Rebuild Error Detected in: ” & swModel.GetPathName
For i = LBound(evalErrors) To UBound(evalErrors)
‘ エラーの詳細を解析（フィーチャ名とエラーコード）
WriteDebugLog “Feature: ” & evalErrors(i).Name & ” | Code: ” & evalErrors(i).ErrorCode
Next i
End If
‘ メモリ最適化: 明示的な解放
Set swExt = Nothing
End Sub
Private Sub WriteDebugLog(message As String)
Dim fso As Object
Dim ts As Object
Dim logPath As String
logPath = Environ(“USERPROFILE”) & “\Desktop\SW_Automation_Log.txt”
Set fso = CreateObject(“Scripting.FileSystemObject”)
‘ ファイル追記モードで開く
Set ts = fso.OpenTextFile(logPath, 8, True)
ts.WriteLine “[” & Now & “] ” & message
ts.Close
‘ オブジェクト解放
Set ts = Nothing
Set fso = Nothing
End Sub
—
3. シニアエンジニアが意識すべき「メモリと安定性」の極意
このスクリプトを運用する上で、以下の3点を遵守せよ。
① オブジェクトの明示的破棄（Garbage Collectionの補完）
VBAの参照カウンタに頼るな。`Set swExt = Nothing`は儀式ではない。特にループ処理内でモデルを次々と開閉する場合、オブジェクトを解放しないと、SolidWorksプロセスは確実にメモリリークを起こし、数時間後にはクラッシュする。
② Windows APIとの連携による「監視」
もし自動化対象が極めて巨大なアセンブリであれば、`GetEvaluationErrors`の前に、Windows API (`User32.dll`) を用いて、SolidWorksのプロセス負荷を監視し、CPUがアイドル状態になってから処理を再開させる「待機ルーチン」を実装すること。APIコールを急ぎすぎると、非同期の再構築プロセスが追いつかず、誤ったエラー判定を出す原因になる。
③ レガシー環境の保守
古いSolidWorksバージョンでは、`GetEvaluationErrors`が期待通りに動作しない、あるいは戻り値の型が異なるケースがある。その際は、`IF swApp.VersionNumber < "..."`といった条件分岐を設け、バージョンごとの挙動を抽象化したクラスモジュール（インターフェース）に切り出すのが、長期運用における「伝説」への第一歩だ。
最後に：自動化とは「エラーとの対話」である
自動化において最も愚かなのは、コードがエラーを無視することだ。エラーは、SolidWorksが「ここが物理的に無理だ」と叫んでいる声そのものである。
`GetEvaluationErrors`を使いこなし、なぜ失敗したのかという「文脈」をログに残せ。それが溜まったとき、君のログファイルは単なるテキストではなく、「設計の弱点を指摘するデバッグガイド」へと昇華する。
システム管理者や上司が驚くのは、コードが速く動く時ではない。システムが止まったとき、その原因が秒単位で正確にログされているときだ。それこそが、プロの仕事である。
