【SolidWorks VBA極意】マクロ記録の呪縛を断て：`NewDocument`による純粋パーツ生成とメモリ統御の極意
世に蔓延るSolidWorks VBAの解説書のほとんどは、「マクロ記録ボタンを押し、図形を描いて、出力された冗長なコードをコピペせよ」と説く。だが、現場で数万点規模の アセンブリや、外部ERPと連動する自動設計システムを構築するエンジニアにとって、あの「マクロ記録のゴミコード」は百害あって一利なしだ。
特に、テンプレートファイル（`.prt`や`.asprt`）の存在に依存した設計は、環境移行時のパス切れや、社内標準改定時の同期漏れという致命的なバグの温床となる。
今回は、SolidWorks APIの根幹である `SldWorks.Application.NewDocument` メソッドを用い、完全にクリーンな状態からテンプレートなしで、論理的に正しいパーツファイル（`.sldprt`）を生成・初期化するプロフェッショナルな手法を伝授する。
—
1. 現場の現実：なぜ「マクロ記録」と「テンプレート依存」が破滅を招くのか
実務において、以下のようなトラブルに直面したことはないだろうか？
- テンプレートのパス依存問題: 開発者のPCローカルにある `C:\templates\part.prt` を参照しているため、別担当者のPCで実行するとファイルが見つからずエラーになる。
- 単位系のサイレント・ミスマッチ: 図面テンプレート側で「インチ（Inch）」がデフォルトに設定されていたため、ミリ単位で数値を流し込んだ瞬間に巨大な（あるいはミクロな）ジオメトリが生成される。
- ゾンビプロセスの蓄積: オブジェクトの解放（`Set swApp = Nothing` 等）を怠り、VBA終了後も背後でSolidWorksのプロセスがメモリを食い潰し続ける。
これらを根絶するには、APIのライフサイクルを完全に掌握し、コード側で初期状態を強制的にコントロールするアプローチが必要不可欠である。
—
2. `NewDocument` の核心とパラメータの罠
`SldWorks::NewDocument` は強力だが、その引数仕様は極めてスパルタンである。公式ドキュメントの表面だけをなぞっても、実務で使えるコードは書けない。
Function NewDocument(
FileName As String,
PaperSize As Long,
TemplateWidth As Double,
Template Height As Double
) As Object
ここで多くの初学者が躓くのが、第1引数の `FileName` だ。「テンプレートを使わない」と言いながら、なぜファイル名が必要なのか？
SolidWorksの内部仕様として、ドキュメント生成時には必ず「ベースとなるシステム定義のデフォルト設定ファイル名（または空文字列によるフォールバック）」を要求される。完全に無から有を生み出すことはできない。そのため、「ファイルパスを指定せず、システム内部のデフォルト規格名のみを渡す」というテクニックを用いる。
—
3. 【実装コード】完全自律型・純粋パーツ生成モジュール
以下のコードは、外部のテンプレートファイルに一切依存せず、API直叩きでパーツドキュメントを生成し、単位系（mmGS）と寸法精度をコード側で強制的に初期化するプロダクション品質のVBAモジュールである。
Option Explicit
‘ ==============================================================================
‘ 担当: チーフアーキテクト
‘ 概要: テンプレートファイルに依存せず、純粋なパーツドキュメントを生成・初期化する
‘ ==============================================================================
Public Sub CreatePurePartDocument()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim lErrors As Long
Dim lWarnings As Long
‘ 1. 堅牢なSolidWorksアプリケーションインスタンスの取得（早期バインディング）
On Error Resume Next
Set swApp = GetObject(, “SldWorks.Application”)
If swApp Is Nothing Then
Set swApp = New SldWorks.SldWorks
End If
On Error GoTo 0
If swApp Is Nothing Then
MsgBox “SolidWorksの起動に失敗しました。”, vbCritical, “致命的エラー”
Exit Sub
End If
‘ 2. ユーザーインターフェースのフリーズ（描画負荷の極限削減と処理高速化）
swApp.Visible = True
Call swApp.SetUserPreferenceToggle(swUserPreferenceToggle_e.swUserPreferenceToggle_eDocNoRebuildOnLoad, True)
‘ 3. NewDocumentによるパーツドキュメントの強制生成
‘ 第1引数には空文字列、またはシステム標準のパーツテンプレート名を渡す
‘ ここでは完全ブランク起動を実現するため、空文字列を指定
Dim templatePath As String
templatePath = “” ‘ 空文字によりSolidWorks内部のデフォルト規格を使用
Set swModel = swApp.NewDocument(templatePath, swDwgPaperSizes_e.swDwgPaperA4size, 0#, 0#)
If swModel Is Nothing Then
MsgBox “パーツドキュメントの生成に失敗しました。”, vbCritical, “API Error”
GoTo CleanUp
End If
‘ 4. 起動直後の初期設定（ミリグラム秒単位系: mmGS の強制適用）
‘ 外部テンプレートの設定違いによるバグをここで完全にシャットアウトする
Dim setUnitResult As Boolean
setUnitResult = swModel.SetUnits(swLengthUnit_e.swMM, swMassUnit_e.swGram, swTimeUnit_e.swSecond, swRadTimeUnit_e.swDegree)
If Not setUnitResult Then
Debug.Print “[警告] 単位系の強制設定に失敗しました。”
End If
‘ 5. グリッドスナップやドキュメントプロパティの最適化
‘ 例：寸法精度を小数点以下3桁に固定
Call swModel.SetUserPreferenceIntegerValue(swUserPreferenceIntegerValue_e.swUnitDimensionPrecision, 3)
MsgBox “純粋なパーツドキュメントの生成と初期化が完了しました。”, vbInformation, “システム通知”
CleanUp:
‘ 6. メモリリーク防止のためのオブジェクト解放
Set swModel = Nothing
Set swApp = Nothing
End Sub
—
4. チーフアーキテクトが教える「メモリ統御とパフォーマンスの極意」
上記のコードには、単なる「動くコード」を超えた、大規模システム開発を見据えた設計思想が組み込まれている。
① 早期バインディング（Early Binding）の徹底
`Dim swApp As Object`（遅延バインディング）ではなく、参照設定に `SolidWorks x.x Type Library` を追加した上で `Dim swApp As SldWorks.SldWorks`（早期バインディング）を使用している。これにより、VBAの内部ディスパッチオーバーヘッドが消滅し、実行速度が最大で数十パーセント向上するだけでなく、IntelliSenseによるAPI補完が完全に効くようになるため、コーディングミスを物理的に根絶できる。
② ゾンビプロセスの完全排除とメモリ管理
VBAにおけるCOMオブジェクトの解放は宗教論争になりがちだが、実務の現場では「参照の連鎖を断ち切る順番」がすべてである。
`swModel` を解放してから `swApp` を解放する。この順序を誤ると、裏で `SLDWORKS.exe` がメモリ上に残り続け、次にマクロを実行した際にハングアップや不正終了を引き起こす原因となる。
③ 外部システム（ERP/PDM）連携への拡張性
この `NewDocument` アプローチの最大のメリットは、「完全に無菌状態のパーツに対し、外部データベースから読み込んだパラメータをインメモリで即座に流し込める」点にある。既存の汚染されたテンプレートを引きずらないため、バッチ処理による深夜の無人自動パーツ生成システム（ナレッジベースエンジニアリングの基盤）へとシームレスにスケールさせることが可能だ。
—
総括
マクロ記録のボタンを押して生成されたコードをありがたく使うフェーズは、今日で終わりにするべきだ。
APIの本質を理解し、ドキュメントのライフサイクルとメモリを完全にコントロール下に置くこと。それこそが、レガシーなVBAを「信頼性の高いエンタープライズ・エンジニアリング・ツール」へと昇華させる唯一の道である。
