SolidWorks APIの真髄：数万フィーチャを「秒殺」する再構築制御の極意
SolidWorksのマクロを組む際、多くの開発者が突き当たる壁がある。「フィーチャを100個追加したら、処理時間が指数関数的に増大する」という現象だ。
なぜ、あなたのコードは遅いのか？ 理由は単純だ。SolidWorksが律儀に一回一回、画面を描画し、ジオメトリの整合性を計算し直しているからだ。
私はこれまで数多くの自動化プロジェクトを指揮してきたが、非効率なコードの共通点は「APIの呼び出し回数」ではなく「再構築（Rebuild）のタイミング制御」にある。今日は、大規模パーツ生成における「爆速化」の技術的解法を、現場レベルの知見と共に伝授する。
—
1. なぜ「再構築」がボトルネックになるのか
SolidWorksのAPIを叩くたびに、内部的には以下の処理が走っている。
1. ジオメトリ計算: 新しいフィーチャの評価。
2. グラフィック更新: 画面描画の再生成。
3. ツリー更新: FeatureManagerの表示更新。
これらを毎回実行するのは、例えるなら「一行書くごとに教科書を最初から読み直す」ようなものだ。これを止めるのが、エンジニアの最初の仕事である。
2. 爆速化の二大巨頭：EnableRebuildとEnableFeatureUpdate
パフォーマンスを極限まで高めるには、以下の2つのAPIを適切に制御する必要がある。
- `ModelDoc2.EnableRebuild`: モデルの自動再構築を抑制する。
- `FeatureManager.EnableFeatureUpdate`: フィーチャツリーの更新と描画をサスペンドする。
これらを組み合わせることで、SolidWorksの「思考プロセス」を一時停止させ、一気にデータを流し込むことが可能になる。
—
3. 実践：保守性と堅牢性を備えたプロダクションコード
単に停止させるだけでは、エラー発生時に「画面がフリーズしたまま戻らない」という最悪の事態を招く。必ずエラーハンドリングとセットで実装するのがプロの流儀だ。
Option Explicit
‘ メイン処理：大規模なフィーチャ生成を爆速化するテンプレート
Public Sub CreateMassiveFeatures_Optimized()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swFeatMgr As SldWorks.FeatureManager
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
If swModel Is Nothing Then Exit Sub
‘ 1. プロセス開始時の状態保存と最適化設定
Set swFeatMgr = swModel.FeatureManager
On Error GoTo ErrorHandler
‘ 再構築と描画を無効化
swModel.EnableRebuild = False
swFeatMgr.EnableFeatureUpdate = False
‘ — ここに重いフィーチャ作成ロジックを記述 —
Call ExecuteHeavyLogic(swModel)
‘ ——————————————
‘ 正常終了時：設定を戻す前に一括で再構築を行う
swModel.EnableRebuild = True
swFeatMgr.EnableFeatureUpdate = True
swModel.ForceRebuild3 True ‘ 最後に一回だけ強制再構築
MsgBox “処理が完了しました。”, vbInformation
Exit Sub
ErrorHandler:
‘ エラー発生時でも状態を戻さないとSolidWorksが死ぬ
swModel.EnableRebuild = True
swFeatMgr.EnableFeatureUpdate = True
MsgBox “エラー発生: ” & Err.Description, vbCritical
End Sub
Private Sub ExecuteHeavyLogic(swModel As SldWorks.ModelDoc2)
‘ ここでループ処理を行い、数千のフィーチャを追加する
‘ API呼び出しを最小限に留める設計を意識すること
End Sub
—
4. 現場のアーキテクトが教える「注意点」
① 「中間状態」での依存関係に注意せよ
`EnableFeatureUpdate = False` にしている間、APIは「前のフィーチャが存在すること」を前提とした計算ができない場合がある。もしフィーチャ生成の途中で「前のフィーチャの面」を参照しなければならない場合、この手法は使えない。その場合は、ロジックを分割するか、参照を回避する設計（座標指定等）に切り替える必要がある。
② データベース連携時のボトルネック
CSVやDBから形状データを読み込む場合、I/O処理（読み込み）とAPI処理（生成）を明確に分離せよ。データをメモリ上の配列（`Variant`型の二次元配列など）にすべて展開してから一気にループを回すのが、キャッシュ効率を最大化するコツだ。
③ なぜ `ForceRebuild3` なのか
最後に `EnableRebuild = True` に戻すだけでは、SolidWorksが「どこが変更されたか」を誤認することがある。`ForceRebuild3 True` を叩くことで、確実に全ツリーを再評価させ、整合性を担保する。
—
結論：コードは「対話」である
SolidWorksという巨大なシステムに対して、我々エンジニアは「いかに負荷をかけず、かつ正確に要求を伝えるか」を考えなければならない。
今回紹介した制御手法は、単なる小手先のテクニックではない。SolidWorksというエンジンの挙動を理解し、そのリソースを制御下に置くための「作法」である。
あなたのコードが、次に大規模なパーツを生成する時、この設計があなたの時間を劇的に節約してくれることを約束する。もし実装で詰まったら、もう一度このコードの `On Error GoTo` を見返してほしい。堅牢性こそが、真の速さを生むのだから。
