SolidWorks APIの深淵：IMassProperty2による慣性主軸の自動抽出と設計検証の極意
SolidWorksのGUI上で「質量特性」ボタンをクリックして得られる結果に満足しているエンジニアは、まだAPIの表層しか見ていない。真の自動化エンジニアにとって、質量特性は単なる数値の羅列ではなく、「構造の幾何学的重心と慣性テンソルの数学的解」そのものである。
本稿では、`IMassProperty2` インターフェースを駆使し、慣性モーメントから主軸ベクトルまでを抽出し、Excel設計計算書へと直結させるアーキテクチャについて語る。
—
1. オブジェクトモデルの罠とライフサイクル管理
多くの初学者が陥る罠は、`SldWorks`や`ModelDoc2`を無造作にグローバル変数として使い回し、メモリリークを放置することだ。SolidWorksのCOMオブジェクトは、参照カウンタの解放が明示的でない場合、大規模アセンブリの解析において致命的なメモリ肥大化を招く。
究極のメモリ管理術
VBA（およびVB.NET）において、`IMassProperty2`は`IModelDoc2.Extension.CreateMassProperty`から生成される。この際、以下のルールを鉄則とせよ。
1. スコープの最小化: `MassProperty`オブジェクトは、計算が終わるごとに即座に `Nothing` を代入して参照を解放せよ。
2. 型指定の厳格化: `Object`型を使わず、必ず `IMassProperty2` を明示してバインディングを行うこと。Late Binding（遅延バインディング）はデバッグの敵であり、パフォーマンスを著しく低下させる。
—
2. 実装：慣性テンソルと主軸の抽出
慣性テンソル（慣性モーメントの行列）は、そのままでは設計検証には使いにくい。我々が真に求めるのは、「主軸（Principal Axes）」の方向ベクトルである。これは、製品が回転する際に最も安定する軸を意味する。
以下に、計算精度を担保しつつ、Excelへ転送する直前のスニペットを示す。
‘ 伝説的なチーフアーキテクトによる実装例
Public Sub ExportMassPropertiesToExcel()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swMassProp As SldWorks.MassProperty2
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
‘ MassPropertyオブジェクトの生成
Set swMassProp = swModel.Extension.CreateMassProperty
‘ 計算の精度を最大化（システムオプションに依存しない設定）
swMassProp.UseSystemUnits = False
‘ 慣性モーメント行列を取得 (戻り値はバリアント配列)
Dim vInertia As Variant
vInertia = swMassProp.GetMomentOfInertia(swMassPropertyMomentOfInertia_PrincipalAxes)
‘ 主軸ベクトルの取得 (X, Y, Zの各方向)
Dim vPrincipalAxes As Variant
vPrincipalAxes = swMassProp.GetPrincipalAxes
‘ — ここでExcelのセルへ値を転送 —
‘ vInertia(0) to (5) には慣性モーメントが含まれる
‘ vPrincipalAxes(0) to (8) には各軸のベクトルが格納される
‘ オブジェクトの明示的解放（メモリ管理の鉄則）
Set swMassProp = Nothing
Set swModel = Nothing
End Sub
—
3. シニアエンジニアが意識すべき「座標系の罠」
このAPIで最も落とし穴となるのが、「座標系（Coordinate System）の不一致」だ。
`GetMomentOfInertia`は、デフォルトでは「モデルの原点（アセンブリならアセンブリ原点）」を基準とする。しかし、設計検証では「重心（Center of Mass）」を基準とした慣性モーメントが求められることが多い。
- 対策: `IMassProperty2.CoordSysName` プロパティを使い、事前に定義した座標系を指定するか、重心座標をオフセットとして補正計算を行う必要がある。これを行わない慣性計算は、動解析においては「ゴミ」に等しい。
—
4. レガシー環境とシステム連携の極限
大規模な企業内システムにおいて、このVBAプログラムは単体で動くべきではない。Excelをフロントエンドとした場合、以下の構成を推奨する。
- Windows APIの併用: `Sleep`関数等でプロセスを待機させるのではなく、`GetMessage`やイベント駆動による非同期処理を組み込み、SolidWorksが解析を終えるまでExcelをフリーズさせない工夫を施すこと。
- バイナリ保存の回避: 頻繁に計算を行う場合は、SolidWorksのファイルをオープンしたままメモリ内で解析を完結させること。ディスクI/Oはシステム全体のボトルネックとなる。
—
結論：技術は「道具」ではなく「思想」である
SolidWorks APIを使いこなすということは、CADソフトを操作することではない。「3Dモデルというデータ構造から、物理学的な真実をAPIを通じて抽出する」というプロセスそのものである。
慣性主軸の傾きが設計の意図から逸脱していることを、Excelの計算書が自動的に赤字で警告する――そんなシステムこそが、我々エンジニアが目指すべき「自動化」の到達点だ。
コードは単に動けばいいというものではない。メモリを食いつぶさず、他のモジュールと干渉せず、数年後のメンテナンス担当者が「なぜこう書いたのか」を即座に理解できる構造を持つこと。それこそが、伝説たる所以である。
健闘を祈る。貴殿のコードが、設計の可能性を拡げる一助とならんことを。
