SolidWorks APIの深淵：再構築エラーを制する「真の」エラーハンドリング設計
SolidWorks APIを扱うエンジニアの多くが、最初の壁に突き当たる瞬間がある。それは、`swApp.Rebuild` を実行した際、裏側でフィーチャが赤く点灯し、無言で停止する「再構築エラー」だ。
「なぜ動かないのか？」――この問いに対して、メッセージボックスで「失敗しました」と表示するだけのコードは、もはやエンジニアの設計とは呼べない。
今回は、プロダクションレベルの自動化ツールにおいて、「何が、なぜ、どこで」破綻したのかを完全に掌握するための、Errオブジェクトと `GetEvaluationErrors` を組み合わせた究極のデバッグ・アーキテクチャを伝授する。
—
1. なぜ「一般的なエラー処理」では足りないのか
VBAの標準的な `On Error GoTo` は、あくまで「プロセスがクラッシュしたか」を監視するに過ぎない。しかし、SolidWorksのフィーチャ再構築における致命的なエラー（スケッチの拘束不足、幾何学的矛盾など）は、APIの戻り値が `False` を返すだけで、VBAのランタイムエラーを発生させないことが多い。
真のエンジニアは、「SolidWorksの内部状態（Evaluation Errors）」を強制的に吐き出させる必要がある。これを怠ると、現場で「たまに失敗する」という、最も始末に負えないバグに悩まされ続けることになる。
—
2. 実装の設計思想：ログ・アーキテクチャ
以下の設計方針を貫く：
1. 分離: 処理ロジックとログ出力ロジックをクラスモジュールで疎結合にする。
2. 可視化: 単なるエラー表示ではなく、タイムスタンプ付きのテキストログを生成する。
3. 網羅性: `ModelDocExtension.GetEvaluationErrors` を使用し、内部のスタック情報を引き出す。
—
3. 実践：高精度リビルド＆ログ出力コード
このコードを標準モジュールに貼り付け、適宜呼び出すことで、堅牢なデバッグ基盤が構築できる。
Option Explicit
‘ 必要な定数の定義
Private Const swRebuildAll = 1
Public Sub RobustRebuild(swModel As SldWorks.ModelDoc2)
Dim swExt As SldWorks.ModelDocExtension
Dim rebuildStatus As Boolean
Set swExt = swModel.Extension
‘ リビルド実行
rebuildStatus = swModel.ForceRebuild3(False)
If Not rebuildStatus Then
‘ エラー発生時は即座に詳細解析へ
Call LogEvaluationErrors(swModel)
Err.Raise vbObjectError + 1001, “RobustRebuild”, “モデルの再構築に失敗しました。詳細はログを確認してください。”
End If
End Sub
Private Sub LogEvaluationErrors(swModel As SldWorks.ModelDoc2)
Dim swExt As SldWorks.ModelDocExtension
Dim errCount As Long
Dim errCodes As Variant
Dim i As Long
Dim logPath As String
Dim fso As Object, ts As Object
Set swExt = swModel.Extension
logPath = Environ(“USERPROFILE”) & “\Desktop\SW_Error_Log.txt”
‘ エラー情報を取得
errCount = swExt.GetEvaluationErrors(errCodes)
If errCount > 0 Then
Set fso = CreateObject(“Scripting.FileSystemObject”)
Set ts = fso.OpenTextFile(logPath, 8, True) ‘ 追記モード
ts.WriteLine “— [” & Now & “] Rebuild Error Detected —”
ts.WriteLine “File: ” & swModel.GetPathName
‘ エラーコードとフィーチャの紐付け
For i = 0 To UBound(errCodes)
ts.WriteLine “ErrorIndex: ” & i & ” | Code: ” & errCodes(i)
Next i
ts.WriteLine “——————————————–”
ts.Close
MsgBox “リビルドエラーを検知しました。ログを出力しました: ” & logPath, vbCritical
End If
End Sub
—
4. 現場で生き残るための「注意点」
ファイルシステムへの負荷を最小限にする
FSO（FileSystemObject）を多用すると、大規模アセンブリのループ処理中にI/Oボトルネックが発生する。ログ出力は必要な時にだけ行うか、メモリ上にバッファリングしてから最後に一括書き出しする設計が望ましい。
データベース連携の罠
もしこのログをDBに送る場合、「ファイルパスの正規化」を徹底せよ。ネットワークドライブのパスは環境によって表記が異なることがあるため、`FileSystemObject.GetAbsolutePathName` を噛ませるのが定石だ。
「サイレントエラー」の排除
`GetEvaluationErrors` は強力だが、全てのエラーを拾えるわけではない。特に、「フィーチャ自体は成功しているが、結果が意図したジオメトリになっていない」という論理エラーは、`swModel.CheckDesignCheck` や `Measure` APIを併用して幾何学的な妥当性を検証する必要がある。
—
まとめ：アーキテクトとしての提言
プロフェッショナルは「なぜ動かないのか」と悩む時間を極限まで削る。今回紹介した「エラーを可視化する仕組み」は、単なるデバッグツールではない。開発の過程で発生する「暗黙のバグ」を、明確な「データ」へと変換するためのインターフェースだ。
この設計を導入すれば、あなたの自動化ツールは、現場のエンジニアから「止まらない、信頼できる相棒」として認められるようになるはずだ。
次は、このログ情報を元に「どのフィーチャを修正すべきか」を自動特定する、メタデータ駆動型の修正エンジンの構築に挑んでほしい。健闘を祈る。
