SolidWorks VBAの深淵：Rebuild Errorを完全掌握する「評価エラー解析」の極意
SolidWorks APIを扱うエンジニアにとって、「再構築エラー（Rebuild Error）」は最大の敵であり、同時にシステムの健全性を測る唯一の指標である。
多くの開発者は、`ModelDoc2.ForceRebuild3` を呼び出した後の「モデルの赤字（FeatureManagerの警告）」を画面越しに眺めて溜息をつくだけだ。しかし、真の自動化エンジニアは、APIを通じてその「苦痛の源泉」を数値化し、ログへと吐き出させる。
本稿では、`ModelDocExtension.GetEvaluationErrors` を軸とした、エラーの完全自動解析アーキテクチャを伝授する。これは単なるデバッグ手法ではない。堅牢な自動化パイプラインを構築するための「生命線」である。
—
1. GetEvaluationErrorsの本質的理解
`ModelDocExtension.GetEvaluationErrors` は、現在のドキュメントにおいて再構築時に発生したすべてのエラー情報を配列として返す。このメソッドが返すのは単なる文字列ではない。フィーチャの特定、エラーコード、そしてその背景にある数学的破綻の兆候だ。
なぜこれが重要なのか？
通常の `Rebuild` メソッドは成功したかどうかをBooleanで返すだけだが、それでは「なぜ失敗したか」が不明である。大規模アセンブリや複雑な曲面を含むパーツにおいて、修正コストを最小化するためには、「どのフィーチャが、なぜ（ジオメトリ欠損か、依存関係の切断か）」をプログラムが瞬時に判断しなければならない。
—
2. 堅牢な解析エンジンの実装（VBAコード）
以下は、パーツの再構築を試み、エラーが発生した瞬間にその詳細をキャプチャし、外部テキストログへ書き出す堅牢なモジュールである。
Option Explicit
‘ 伝説的なエンジニアは、エラーハンドリングを「事後」ではなく「予兆」で管理する
Public Sub ExecuteRobustRebuild(swModel As SldWorks.ModelDoc2)
Dim swExt As SldWorks.ModelDocExtension
Set swExt = swModel.Extension
Dim errors As Long, warnings As Long
Dim evalErrors As Variant
‘ 1. 再構築の実行
If Not swModel.ForceRebuild3(False) Then
‘ 2. 再構築失敗時にエラー情報を取得
evalErrors = swExt.GetEvaluationErrors
If Not IsEmpty(evalErrors) Then
Call WriteToSystemLog(swModel.GetTitle, evalErrors)
Else
Debug.Print “再構築は失敗したが、詳細エラーが特定できない。”
End If
End If
End Sub
Private Sub WriteToSystemLog(modelName As String, errData As Variant)
Dim fso As Object: Set fso = CreateObject(“Scripting.FileSystemObject”)
Dim logFile As Object
Dim i As Long
‘ ログファイルパス（環境変数を利用してセキュアに配置）
Dim path As String: path = Environ(“USERPROFILE”) & “\Desktop\SW_Rebuild_Log.txt”
Set logFile = fso.OpenTextFile(path, 8, True) ‘ 追記モード
logFile.WriteLine “— [” & Now & “] Rebuild Error Report for: ” & modelName & ” —”
‘ エラー配列を走査。GetEvaluationErrorsの戻り値はフィーチャ名とエラーコードのペア
‘ ※実務ではここでFeatureManagerとの突合を行うのが定石
For i = LBound(errData) To UBound(errData)
logFile.WriteLine “Feature Index/Name: ” & errData(i)
Next i
logFile.Close
‘ オブジェクトの明示的解放（メモリリークは許されない）
Set logFile = Nothing
Set fso = Nothing
End Sub
—
3. レガシー環境とメモリ最適化の極意
オブジェクト解放の作法
VBAはCOMラッパーであり、`Set obj = Nothing` を怠ることは、大規模なバッチ処理においてプロセスを肥大化させる。特に `GetEvaluationErrors` を繰り返し呼び出すループ処理では、各反復ごとにVariant型をクリアし、メモリ上のポインタが正しく整理されることを保証しなければならない。
Windows APIによる「強制終了」の検知
もしSolidWorksが再構築中にハングアップ（無限ループ）した場合、上記VBAは停止する。これを防ぐには、Windows APIの `EnumWindows` や `GetWindowThreadProcessId` を活用し、SolidWorksプロセスの応答状況をウォッチドッグとして別プロセス（VB.NETで書かれた軽量な監視エージェント）で監視するのがプロの流儀だ。
—
4. チーフアーキテクトからの提言
この仕組みを導入する際、最も重要なのは「エラーコードの解釈」である。
`GetEvaluationErrors` で取得したフィーチャ名から、`swModel.FeatureByName(name)` でオブジェクトを特定し、その `GetTypeName2` が何を返しているかを確認すること。
- スケッチ破綻（Sketch Error）: 拘束条件の不足か、重複か。
- フィーチャ失敗（Feature Failure）: 面の結合失敗か、オフセット距離の計算不能か。
これらをログに蓄積し、数千回の再構築データから「どの設計者が作成したパーツがエラーを起こしやすいか」という傾向分析（メタ分析）まで踏み込めば、それは単なるマクロではなく、「設計品質向上システム」へと進化する。
道具に使われるな。道具を飼い慣らせ。
コードの先にあるのは、常に「止まらない自動化」という理想郷である。健闘を祈る。
