SolidWorks APIの深淵：再構築エラーを「黙らせる」のではなく「制圧」せよ
現場でマクロを走らせていて、一番恐ろしいのは何か？
それは「再構築エラー」のダイアログが画面を覆い、スクリプトが停止することではない。「何が原因で破綻したのか分からないまま、モデルがゴミの山になること」だ。
一般的な中級エンジニアは、`On Error Resume Next`でエラーを握りつぶす。しかし、真の自動化エンジニアは違う。我々は、SolidWorksの内部エンジンである`ModelDocExtension`に直接問いかけ、発生したエラーの「傷跡」を解析してログに叩き込む。
今日は、再構築エラーをただの例外として処理せず、完全なデバッグ情報として抽出する「極限の設計」を伝授する。
—
なぜ、一般的なエラーハンドリングでは足りないのか？
`Rebuild`メソッドを実行した際、戻り値が`False`であっても、SolidWorksは「何が起きたか」を詳しくは教えてくれない。GUI上の「フィーチャ編集」画面に出てくる赤い警告アイコン。あれをプログラムで読み取る必要がある。
ここで活躍するのが `ModelDocExtension.GetEvaluationErrors` だ。
これを使うことで、モデルツリー上のどのフィーチャが、どのようなステータス（警告・エラー）で止まっているかを、構造化データとして抽出できる。
—
プロダクションコード：Robust Rebuild Engine
以下のコードは、単に再構築を行うだけでなく、エラーを検知した瞬間にフィーチャ名とエラー内容をログファイルへ書き出す堅牢な設計だ。
Option Explicit
‘ エラー解析を実行し、結果をログに出力するメインプロシージャ
Public Sub RobustRebuildWithLogging()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swModelExt As SldWorks.ModelDocExtension
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
If swModel Is Nothing Then Exit Sub
Set swModelExt = swModel.Extension
‘ 1. 強制再構築を実行
Dim rebuildResult As Boolean
rebuildResult = swModelExt.Rebuild(swRebuildOptions_e.swForceRebuildAll)
‘ 2. エラーが発生した場合のみ解析へ移行
If Not rebuildResult Then
Call AnalyzeAndLogErrors(swModelExt, swModel.GetPathName)
Else
Debug.Print “再構築成功: ” & swModel.GetTitle
End If
End Sub
Private Sub AnalyzeAndLogErrors(swModelExt As SldWorks.ModelDocExtension, filePath As String)
Dim errorCount As Long
Dim errors As Variant
Dim i As Long
Dim logPath As String
Dim fso As Object, ts As Object
‘ ログファイルパス（実行フォルダ内）
logPath = Left(filePath, InStrRev(filePath, “\”)) & “Rebuild_Error_Log.txt”
Set fso = CreateObject(“Scripting.FileSystemObject”)
Set ts = fso.OpenTextFile(logPath, 8, True) ‘ 8: ForAppending
‘ 3. GetEvaluationErrorsでエラー情報を取得
errorCount = swModelExt.GetEvaluationErrors(errors)
ts.WriteLine “— ” & Now & ” 実行エラーログ —”
ts.WriteLine “対象ファイル: ” & filePath
If errorCount > 0 Then
For i = 0 To UBound(errors)
Dim swFeat As SldWorks.Feature
Set swFeat = errors(i)
‘ フィーチャ名とエラー内容を記録
ts.WriteLine “フィーチャ名: ” & swFeat.Name
ts.WriteLine “詳細: ” & swFeat.GetErrorMessage
ts.WriteLine “————————–”
Next i
End If
ts.Close
MsgBox “再構築に失敗しました。詳細はログを確認してください。” & vbCrLf & logPath, vbCritical
End Sub
—
アーキテクトの視点：この実装の「急所」
1. `GetEvaluationErrors`の挙動を理解する
このメソッドが返す`errors`配列の中身は、単なる文字列ではない。`Feature`オブジェクトそのものだ。つまり、エラーが発生したフィーチャに対して、`GetTypeName2`で種類を特定したり、親フィーチャを辿ったりする「二次解析」が可能になる。
2. ログファイルの排他制御
大規模な開発環境では、複数のマクロが同時にログを叩く可能性がある。今回はシンプルに`ForAppending`（追記モード）を使用したが、本番運用では`FileSystemObject`の排他制御や、DB（SQLite等）へのセッション管理を検討すべきだ。
3. UIを凍結させるな
再構築処理は重い。もしUIを更新する必要がなければ、`swApp.Visible = False`や`swModel.FeatureManager.EnableFeatureTree = False`を活用し、リソースを再構築計算に全振りさせること。
次のステップ：自動修復への道
ここから先は、あなたの設計思想次第だ。「エラーを記録して人間が直す」のは最初のステップに過ぎない。
次に目指すべきは、「ログを解析し、特定のフィーチャタイプ（例：スケッチの外部参照切れ）であれば、自動的に抑制（Suppress）して再構築を完遂させる」という自律型エンジンの構築である。
SolidWorks APIは、あなたが思うよりも遥かに饒舌だ。
「動かない」と嘆くのではなく、そのエラーコードの中に眠る「設計の破綻」を読み解いてほしい。それこそが、自動化エンジニアとしての真の価値である。
健闘を祈る。
