CADとエンジニアリング図面の変換：フォーマット間で精度を保つ

CAD変換が重要な理由

エンジニアリングチーム、製造業者、建築家は、SolidWorks、AutoCAD、CATIA、Inventor など、数少ない高精度 CAD プラットフォームで作成された設計データを日常的にやり取りしています。これらのネイティブファイル（DWG、DXF、SLDPRT、IGES、STEP など）は、正確な幾何形状定義、公差、レイヤ、埋め込みメタデータを保持しており、下流のユーザーはそれらを解析、製造、またはコンプライアンスに利用します。パートナーが同じ作成ツールを使用していない場合、協業の唯一の現実的な手段は変換です。

不適切な変換は以下のような問題を引き起こす可能性があります。

• 部品がアセンブリ内でずれる微小な座標シフト
• 失われた・歪んだレイヤ情報により重要な注釈が消える
• 文字化けにより部品表（BOM）の抽出が不可能になる
• 表面仕上げや材料仕様などの製造情報が欠落する

下流プロセス（有限要素解析、CNC 加工、3‑D プリント）は微小な誤差を増幅させることが多いため、変換ワークフローは設計段階と同等の厳密さで扱う必要があります。以下のセクションでは、ソースファイルの評価、適切なターゲット形式の選択、変換パラメータの設定、結果の検証、そしてプロセスのエンジニアリング全体への統合まで、ライフサイクル全体を順に解説します。

1. ソース‑to‑ターゲット形式のマッピング

最初の意思決定は 「変換したファイルに何をさせたいか」 です。すべての形式がすべての CAD 機能を表現できるわけではないため、マッピング行列を用いて不要なデータ損失を防ぎます。

ターゲットが ビュー専用 形式（PDF、PNG、JPEG）の場合はパラメトリックデータを削っても構いませんが、スケールと線幅は正確に保持する必要があります。ターゲットが 製造向け 形式（STEP、IGES）の場合は、モデルが watertight であること、必要な公差がファイルの PMI（Product Manufacturing Information）にエンコードされていることを確認してください。

2. ソースモデルの準備

最も高度なコンバータでも、既に劣化したモデルを修復することはできません。以下の事前チェックを実施してください。

1. ジオメトリ整合性の監査 – CAD ソフトの「チェック」または「修復」機能を実行し、ギャップの閉鎖、ゼロ長エッジの除去、重複頂点の統合を行います。クリーンなモデルは、コンバータが不要な面を生成し、後のシミュレーション失敗を防ぎます。
2. 単位の統一 – すべての部品・アセンブリ・図面が同一単位系（mm、inch など）であることを確認します。例外がある場合はエクスポート前に変換し、コンバータが暗黙の単位変換係数を適用してスケールがずれる事態を防ぎます。
3. レイヤ・ブロックのロック – 製造指示にレイヤ固有の線幅や色を使用している場合は、レイヤ設定を凍結します。一部コンバータはレイヤを単一カラーに平坦化するため、レイヤ情報のラスタ画像を別途保存しておくと便利です。
4. 不要データの除去 – 大容量の埋め込みラスター画像、廃止されたリビジョンクラウド、シミュレーション結果などはファイルサイズを肥大化させ、コンバータを混乱させます。purge コマンドでジオメトリ以外をすべて削除してください。
5. PMI の文書化 – ターゲット形式が PMI をサポートしない場合は、機能注釈・公差・表面仕上げ記号を外部スプレッドシートにエクスポートしておきます。変換後に情報を再付与できます。

3. 適切な変換エンジンの選択

商用 CAD パッケージには組み込みのエクスポートウィザードが付属していますが、対応できる形式はベンダーがサポートするものに限られます。convertise.app のようなクラウド型サードパーティサービスは 11,000 以上の形式に対応し、フル CAD スイートをインストールせずにヘッドレス・スクリプト実行が可能です。

コンバータ選定時に見るべきポイント：

• サポートされているソース‑ターゲット行列 – DWG ↔ DXF、DWG ↔ STEP などをネイティブに処理できるか。
• 保持フラグ – レイヤ保持、PMI 保持、アセンブリ階層維持 などのオプション。
• 精度制御 – 座標丸めの小数許容誤差を設定できるか（例：0.0001 mm）。許容誤差が小さいほど詳細は保持されますが、ファイルサイズは増大します。
• セキュリティ – エンドツーエンド暗号化と「保存なし」ポリシーは、独自のエンジニアリングデータを扱う際に必須です。
• 自動化 – REST API やコマンドラインインタフェースが提供されていれば、CI パイプライン内でバッチ処理が可能です。

4. 変換パラメータの設定

ほとんどのコンバータは、出力の忠実度に直結するパラメータ群を公開しています。以下は変換スクリプトに組み込めるチェックリストです。

{
  "source": "drawing.dwg",
  "target": "model.step",
  "options": {
    "units": "mm",
    "tolerance": 0.0001,
    "preserveLayers": true,
    "includePMI": true,
    "assemblyStructure": "nested",
    "outputVersion": "AP242"
  }
}

• units（単位） – コンバータに既知の単位系を強制します。DXF のように単位が曖昧になりやすい形式では必須です。
• tolerance（許容誤差） – エンジンが頂点をグリッドにスナップする度合いを決めます。航空宇宙部品のような超高精度が求められる場合は 1 µm（0.001 mm）レベルが必要になることもあります。
• preserveLayers（レイヤ保持） – true にすると、元のレイヤがターゲット側でも named layer として出力されます。色分けレイヤを CNC ツールパスで利用する場合は必須です。
• includePMI（PMI 含める） – GD&T 記号、表面仕上げ指示、寸法公差を STEP の Annotation エンティティにエクスポートします。
• assemblyStructure（アセンブリ構造） – nested を選択すると階層的なアセンブリツリーが保持され、flattened は単一部品エクスポートになります。
• outputVersion（出力バージョン） – 新しい STEP バージョン（AP242）はより複雑な情報をサポートしますが、レガシー CAM ソフトは古いバージョン（AP203）を好むことがあります。

5. 変換の実行

クラウドサービス利用時の典型的なフロー：

1. アップロード – 安全な HTTPS エンドポイントにソースファイルを送信。
2. ジョブ送信 – 上記 JSON ペイロードを含めて変換依頼を投稿。
3. ステータス監視 – 多くの API はジョブ ID と完了通知用 Webhook URL を返します。
4. ダウンロード – 結果ファイルを暗号化されたストレージバケットへ直接取得。

オンプレミスで自動化したい場合は、cad2step や dwg2pdf といったコマンドラインツールを Bash や PowerShell スクリプトでラップし、ディレクトリ内の全ソースファイルを順に処理します。入力と出力の SHA‑256 チェックサムを必ず記録し、後続の整合性検証で使用できるようにします。

6. 変換精度の検証

検証は信頼できるワークフローとリスクの高いショートカットを分ける最重要工程です。以下の 3 つの相補的手法で確実性を担保します。

6.1 幾何比較

ソースとターゲット両モデルから点群をエクスポート（多くの CAD ツールは「N points per face」サンプリングを提供）し、ハウスドルフ距離を算出します。最大偏差が設定許容範囲以下であれば変換成功と判断します。

6.2 レイヤ・属性監査

ターゲットファイルのレイヤテーブル（STEP では Layer エンティティとして現れる）を抽出し、ソースのレイヤリストと比較します。自動スクリプトで欠落や名称変更をフラッグできます。部品番号や材料タグといったメタデータは、STEP にエクスポートされた PMI オブジェクトと元注釈をクロスリファレンスします。

6.3 ビジュアル・スポットチェック

対応ビューア（DWG なら eDrawings、STEP なら FreeCAD）でターゲットファイルを開き、穴、フィレット、対向面など重要機能を目視で確認します。自動指標では捕捉しにくい法線反転やテクスチャ破損といったアーティファクトを見つけるのに有効です。

7. 大規模バッチ変換の管理

エンジニアリング部門では、レガシーファイルのライブラリ全体を移行するケースが頻繁にあります。スケールアウトするためのポイントは次の通りです。

• チャンク化 – プロジェクトや担当分野単位で論理的にバッチ分割し、ジョブサイズを適切に抑えて障害発生時の切り分けを容易にします。
• 冪等スクリプト – バッチが途中で失敗しても再実行してもファイルが重複したり、検証済み結果が上書きされたりしないよう設計します。
• ログ＆監査 – 各ファイルについて CSV 行を作成し、source path, target path, timestamp, input checksum, output checksum, verification status を記録します。
• バージョン管理との統合 – 変換スクリプトとログを Git や SVN で管理し、バッチごとにリリースタグを付与します。万一体系的な問題が後で判明した場合にロールバックが可能です。

8. ベンダー独自 CAD 機能の取扱い

一部の CAD システムは中立形式へは直接マッピングできないベンダー固有データを埋め込んでいます。代表的な例は次の通りです。

• SolidWorks FeatureTree – STEP へエクスポートすると機能階層はソリッドボディに統合されます。機能情報は別途 FeatureManager ツリーを XML で出力して保存します。
• AutoCAD Dynamic Blocks – 動的ブロックは DXF では静的ジオメトリに変換されます。ブロックパラメータは JSON マニフェストとして保存し、下流ツールが対応していれば再適用します。
• Inventor iLogic Rules – スクリプトは変換時に失われます。変換前にルールを仕様書として文書化しておくことが推奨されます。

実務的には、これらの情報は 製造に必須でない と見なして、元のネイティブファイルを将来のリビジョン用にアーカイブしておくのが最も安全です。

9. セキュリティとコンプライアンス

エンジニアリングデータは ITAR、EAR といった輸出管理規則や社内の知的財産ポリシーの対象になることが多いです。クラウドで変換する際の留意点は以下です。

• 転送・保存時の暗号化 – アップロードは TLS 1.3、保存は AES‑256 にて暗号化します。
• ゼロリテンションポリシー – 変換完了後に即座にファイルを削除するプロバイダーを選択。convertise.app は「ログなし・保存なし」モデルを明示しています。
• アクセス制御 – API キーは単一 IP 範囲に限定し、定期的にローテーションします。
• 監査トレイル – すべての変換リクエストについて、タイムスタンプ、ユーザー ID、チェックサムを含む署名付きログを保持します。内部統制・外部監査の両方を満たすことができます。

10. PLM システムへの変換統合

多くの組織はすでに PLM ツール（Teamcenter、ENOVIA、Autodesk Fusion Lifecycle など）で部品改訂や BOM を管理しています。変換を PLM アクティビティとして埋め込むと次の 2 つの大きなメリットがあります。

1. 自動アーカイブ – 新しい改訂がリリースされるたびに、ネイティブ CAD を長期保存向けの中立形式（例：STEP‑AP242）に自動変換し、PLM がソースと派生ファイルを同時に保管。ベンダーがサポート終了しても将来アクセスが保証されます。
2. 部門横断共有 – 営業、マーケティング、法務は軽量な表現（PDF、PNG）が必要です。PLM からの変換により、全ステークホルダーが最新エンジニアリングデータに一致したビジュアルを受け取れるため、古い資料による齟齬を防げます。

実装例：PLM のワークフローエンジンが「Revision Published」イベントを検知すると、Webhook がファイルを変換サービスへ POST、変換結果を受け取って部品レコードに添付します。

11. よくある落とし穴と回避策

12. 変換戦略の将来適応性

CAD エコシステムは常に変化しています。新規フォーマットの登場、標準規格の採用・廃止、クラウド共同設計ツールの普及に備えて、以下を実践してください。

• 標準化団体の動向監視 – ISO・ASME が STEP・IGES の改訂を出すたびに、四半期ごとに対象バージョンをレビュー。
• 変換マトリックスの維持 – サポートするソース‑ターゲット組み合わせ、精度設定、既知の制限をドキュメント化。
• モジュール化スクリプト – アップロード／変換／検証を独立したモジュールに分割し、プロバイダー変更時に全体を書き換える必要がないようにする。
• ネイティブアーカイブの保持 – 変換にどれだけ自信があっても、元のプロプライエタリファイルをアクセス制御されたボールトに安全に保存しておくことが、将来の標準変更時の保険になります。

---

CAD 変換を、前段階の設計と同等の厳密さを持つエンジニアリング活動として扱う ― 入念な事前チェック、パラメータ制御、自動検証、そして高度なセキュリティ管理をすべて備えれば、クライアントへの単一部品レビューから企業規模のライブラリ全体を中立かつ長期保存可能な形式へ移行するまで、設計精度を犠牲にせずに設計情報を共有できます。これらの原則は、1 件の部品を顧客に見せる場合でも、社内ライブラリを永久保存フォーマットへ移行する場合でも同様に有効です。