【SolidWorks API】再構築エラーを制する者は設計を制す：`GetEvaluationErrors`による深層解析術
SolidWorksの自動化において、最も忌むべきは「再構築（Rebuild）エラーによるマクロの停止」だ。
画面上の赤信号（エラーフィーチャ）を見て溜息をつくのはアマチュアの仕事。プロフェッショナルは、APIを通してその「エラーの正体」を数値データとして抽出し、システム側で能動的にハンドリングする。
今日は、`ModelDocExtension.GetEvaluationErrors` を軸に、フィーチャの深淵を覗き込むための「極限のエラーハンドリング」を伝授しよう。
—
1. なぜ「標準のリビルド」だけでは不十分なのか
`IModelDoc2::ForceRebuild3` を叩いて `True` が返ってくれば成功。だが、エンジニアとして知るべきは「何が、どの程度壊れているか」だ。
`GetEvaluationErrors` は、単なる真偽値ではない。フィーチャツリー内の各ノードが保持する「エラーコード」と「警告コード」を配列として引きずり出すための鍵だ。これを使えば、「寸法が解決不能なのか」「幾何拘束が矛盾しているのか」をコードレベルで判別できる。
—
2. 実装の極意：エラー解析エンジン
以下のコードは、単にエラーを拾うだけでなく、どのフィーチャが戦犯かを特定し、メモリを汚染させないためのアーキテクチャだ。
Option Explicit
‘ 伝説的エンジニアの流儀：メモリ管理を怠るな
Public Sub AnalyzeRebuildErrors(ByVal swModel As SldWorks.ModelDoc2)
Dim swExt As SldWorks.ModelDocExtension
Dim errCode As Long
Dim warnCode As Long
Dim featErrors As Variant
Dim featCount As Long
Dim i As Long
Set swExt = swModel.Extension
‘ 1. モデルの全状態を再構築（ForceRebuild）
‘ 成功・失敗に関わらずエラーログを叩く準備をする
swModel.ForceRebuild3 False
‘ 2. エラー解析（GetEvaluationErrors）
‘ 引数に配列を渡すことで、該当フィーチャとエラーコードのペアを取得
errCode = swExt.GetEvaluationErrors(featErrors)
If errCode <> 0 Then
Debug.Print “— エラー検出: ” & errCode & ” —”
‘ featErrorsは 2次元配列 (0, n) = Feature, (1, n) = ErrorCode
featCount = UBound(featErrors, 2)
For i = 0 To featCount
Dim swFeat As SldWorks.Feature
Set swFeat = featErrors(0, i)
Dim errorCode As Long
errorCode = featErrors(1, i)
‘ ここでエラーコードを独自ロジックで解析
‘ 詳細は SolidWorks API Help の swFeatureError_e を参照
Debug.Print “Failed Feature: ” & swFeat.Name & ” | Error Code: ” & errorCode
‘ メモリの明示的解放（VBAでは必須の作法）
Set swFeat = Nothing
Next i
Else
Debug.Print “Rebuild Success: No errors found.”
End If
‘ オブジェクトのクリーンアップ
Set swExt = Nothing
End Sub
—
3. レガシーシステムにおける「安定性」の確保
古いSolidWorks環境や、大規模アセンブリを扱うシステムでは、APIの呼び出し自体が「不安定」になることがある。これを回避するための3つの鉄則を記す。
① Windows APIによる「強制応答」
SolidWorksがモーダルダイアログ（エラー通知）を出してマクロが止まるのを防ぐため、`IModelDocExtension::IgnoreErrors` を活用せよ。これを適切に設定することで、マクロは「人間が閉じるのを待つ」必要がなくなる。
② メモリの断片化対策
`Set Object = Nothing` をループ内で徹底するのは当然だが、もし大量のファイルをバッチ処理するなら、適宜 `DoEvents` を挟みつつ、GC（ガベージコレクション）に近い感覚でオブジェクトを破棄せよ。特に `Feature` オブジェクトを長時間保持し続けるのは禁忌だ。
③ 独自ログDBへの連携
解析したエラーコードを `CSV` や `SQLite` に蓄積し、「どの設計者が、どの設定でエラーを多発させているか」という統計を取れ。これは単なるデバッグではなく、組織の「設計品質管理（QMS）」そのものになる。
—
4. 最後に：エンジニアへの提言
`GetEvaluationErrors` を使いこなすということは、SolidWorksの「計算ロジックそのもの」と対話するということだ。
フィーチャエラーは「不具合」ではない。「設計の矛盾」という名のデータだ。
エラーが出たときに「マクロが止まった」と嘆くのではなく、そのエラーコードをシステムのインプットとして再利用する。そこまで到達して初めて、君は「SolidWorksを操る者」と名乗れる。
現場のコードは、常に美しく、そして冷徹であれ。
次回の記事では、このエラー情報を元に自動的に寸法値を調整する「自動補正アルゴリズム」について深掘りしよう。
—
Stay hungry, stay automated.
