CAD間データ変換の落とし穴——ネイティブと中間ファイルの使い分け

客先常駐で複数のメーカーの案件を掛け持ちしていると、CADの種類が案件ごとに違うという場面に何度も出会う。ある月はCATIA、翌月はNX、その次はSolidWorksという具合だ。データを別のCADへ渡す、あるいは受け取る機会は年々増えており、変換の仕組みを理解していないと、気づかぬうちに形状や公差の情報が欠落したまま図面が進んでしまう。今回は20年の実務で痛感してきた変換の落とし穴について整理する。

なぜCAD間のデータ変換で問題が起きるのか

CADソフトはそれぞれ独自の内部構造でモデルを保持している。フィーチャーの履歴、パラメトリックな拘束関係、アセンブリの参照方式などはソフトごとに設計思想が異なり、同じ「3Dモデル」といっても中身はまったく別物だ。ネイティブファイルをそのまま別CADで開こうとすれば、変換エンジンがフィーチャーツリーを解釈し直す必要があり、この過程で丸め誤差や解釈違いが発生する。

私が担当した案件では、協力会社から届いたモデルをそのまま自社CADにインポートしたところ、面と面の境界にわずかな隙間ができてしまい、後工程の解析ソフトでエラーが出たことがあった。原因を追うと、変換時にスプライン曲面の近似精度が粗く設定されており、見た目では判別できないレベルの誤差が蓄積していた。数値だけを信じず、変換後は必ず形状の整合性を確認する癖をつけるようになったのは、この経験がきっかけだった。当時は変換設定の意味すら十分に理解していなかったため、まずは変換エンジンの設定画面を一つずつ確認し、近似精度・許容誤差・単位系といった項目がそれぞれ何を意味するのかを調べ直すところから始めた。この基礎知識があるかないかで、トラブルの原因を切り分けるスピードが大きく変わることを、後になって実感している。

さらに厄介なのは、変換エラーが必ずしもエラーメッセージとして表示されるわけではない点だ。変換自体は正常終了したように見えても、内部では一部の面が欠落していたり、ソリッドがサーフェスの集合体に置き換わっていたりすることがある。私はこうした「静かな不具合」に何度か泣かされてきたため、重要な案件では変換直後に必ずソリッドチェック(閉じたボリュームになっているか)を実行し、モデルの健全性を確認するようにしている。この一手間を惜しんだために、後工程の加工データ作成の段階で不具合が発覚し、原因調査に丸一日を費やしたこともあった。

別の案件では、海外メーカー製の購入部品の3DモデルをSTEP経由で受け取った際、モデル自体はインチ単位で作成されていたにもかかわらず、変換設定でミリメートル単位として読み込んでしまい、寸法が実寸の25.4倍近いスケールで表示されるという初歩的なミスを犯しかけたことがある。幸い図面化の直前に全体寸法の桁が明らかにおかしいことに気づき事なきを得たが、単位系の食い違いは変換エラーとして表示されないことが多く、見た目のプロポーションだけでは気づきにくい。それ以降、海外由来のモデルを扱う際は、変換直後に必ず単位系の表記を確認し、代表寸法を一箇所実測してスケールが正しいかを裏付けるようにしている。

ネイティブファイルを使うべき場面

同一CAD同士でデータをやり取りできるなら、基本的にはネイティブファイルを使うのが最も安全だ。フィーチャー履歴がそのまま引き継がれるため、寸法変更や形状修正を相手側でも同じ操作感で行える。特に量産前の設計変更が頻発する段階では、ネイティブでのやり取りが必須といっていい。目安として、設計変更が週に何度も発生するような立ち上げ期の案件では、ネイティブ以外の選択肢はまず考えない。逆に、形状が固まった後の参考共有程度であれば、中間ファイルでも実用上は問題にならないことが多い。

私が常駐していた現場では、社内の設計チームと外注先が同じCADライセンスを使っていたため、基本はネイティブ形式で図面データを共有していた。ただしバージョンの違いには注意が必要で、上位バージョンで保存したファイルを下位バージョンで開けないというトラブルは何度も経験している。案件に着手する前に相手のCADバージョンを確認し、必要であれば旧バージョン形式で保存し直すという工程をルーチンに組み込んでおくと、後の手戻りを防げる。

バージョン差の許容範囲についても、私は自分なりの目安を持つようにしている。多くのCADは2世代前後までであれば下位互換の保存形式を用意しているが、それを超える差があると、フィーチャーの一部が正しく認識されずソリッドが分解してしまうことがある。別の案件では、5世代近く古いバージョンへ強引に保存し直したところ、パターン機能で作成していた穴群がすべて個別フィーチャーに分解され、後から1箇所だけ穴径を変更する際に、全ての穴を一つずつ手作業で修正する羽目になった。この経験以降、バージョン差が大きいと分かった時点で、無理にネイティブでのやり取りにこだわらず、素直にSTEPへ切り替える判断をするようにしている。

STEP・IGESなど中間ファイルの特性と限界

異なるCAD間でやり取りする場合は、STEPやIGESといった中間フォーマットを使うのが一般的だ。STEPは形状データを比較的忠実に再現でき、近年のCADではAP242など属性情報(PMIやGD&T)まで引き継げる規格も普及してきている。IGESは古くからある規格で互換性は高いものの、曲面の表現方式がCADによって解釈違いを起こしやすく、私の経験では薄板部品の微妙な曲率が変換後に段差状になってしまったことがあった。

中間ファイルはあくまで「近似」であるという前提を忘れてはいけない。フィーチャー履歴は失われ、単なるサーフェスやソリッドの塊としてしか渡らない。相手先で寸法を変更したい場合、パラメトリックな編集はできず、面を切り貼りするような力技の修正が必要になる。これを知らずに「STEPで送ればどうにかなる」と考えていると、受け取った側が想定外の手間を強いられることになる。

変換時の許容誤差設定も、思っている以上に結果を左右する。私が扱ってきた現場では、STEP変換時の公差設定を0.01mm程度と粗めに設定してしまい、微小なR形状を持つ部品で面のつながりが滑らかにならず、後工程の強度解析でエラーが多発したことがあった。それ以降、精密な形状を含むモデルを変換する際は、許容誤差を0.001mm前後まで細かく設定し、多少ファイルサイズが大きくなっても精度を優先するようにしている。逆に、大まかな検討用のモデルであればあえて粗い設定でファイルを軽くするなど、用途に応じて設定値を使い分ける判断も必要だと感じている。

実際に遭遇した変換トラブルの事例

もっとも印象に残っているのは、板金部品のモデルをSTEP変換して協力会社に渡した際に、展開図が正しく生成されなかった案件だ。ネイティブモデルでは板金フィーチャーとして厚み・曲げ半径・展開係数の情報を持っていたが、STEPに変換した時点でそれらの情報が単純なソリッド形状に置き換わってしまい、相手側のCADが「板金部品」として認識できなくなっていた。結果として展開図を手作業で描き直す羽目になり、納期に響きかけたことがある。

この経験から、板金や溶接構造など特殊なフィーチャーを含むモデルを渡す際は、変換前に相手先のCAD対応フォーマットを確認し、可能であればネイティブか、板金情報を保持できる専用の変換パスを使うようにしている。単純に「3D形状さえ合っていればいい」という考え方は、後工程の作業内容によっては通用しないことを、身をもって学んだ。

別の案件では、購入部品メーカーから受け取ったSTEPモデルにねじ穴の呼び寸法情報が含まれておらず、単なる円筒穴としてしか認識できなかったことがあった。ネイティブモデルであればねじ規格の属性情報を持っていたはずだが、変換の過程でその属性情報が落ちてしまい、図面上でねじ穴と単純な下穴の区別がつかなくなっていたのだ。結局、メーカーの仕様書を別途取り寄せてねじ規格を確認し、図面に手作業で注記を追加する対応を取った。属性情報は形状データと違って目視では欠落に気づきにくいため、購入部品を扱う際は形状だけでなく、ねじや表面処理などの付帯情報が正しく引き継がれているかも必ず確認するようにしている。

変換後の検図で必ず確認するポイント

変換したデータを図面化する前には、必ず元モデルとの照合作業を行う。具体的には、全体寸法・穴位置・主要な公差箇所を代表点として抜き出し、変換前後で数値がずれていないかをチェックする。特に注意しているのは、曲面の連続性(接線連続かどうか)、薄肉部の厚み、そしてアセンブリでの部品同士の干渉有無だ。

私が現場で使っている簡易チェックリストは次のようなものだ。

質量や重心を比較するのは、意外と見落とされがちだが有効な方法だ。形状に欠損があると質量特性の数値が明らかにずれるため、細かい形状差異を見つける手がかりになる。

このチェックリストを使うようになったきっかけも、実際のトラブルからだった。あるアセンブリで、変換後のモデルを見た目だけで確認して図面化したところ、量産試作の段階で部品同士がわずかに干渉していることが発覚した。原因を調べると、変換時にごくわずかな面のずれが生じており、目視では気づけないレベルの隙間が実際には負のクリアランスになっていた。それ以降、干渉チェックだけは変換の都度、例外なく実施するルールにしている。地味な作業だが、試作の手戻りコストを考えれば、検図にかける数十分は決して無駄にならない。

数値の目安としては、全体寸法のずれは0.05mm以内、質量差は1%以内を私の中の基準にしている。これを超える差異が見つかった場合は、たとえ図面化の締め切りが迫っていても、必ず変換設定を見直すか、原因が分かるまで先に進めないようにしている。別の案件では、質量差が3%近くあることに気づかないまま図面化を進めてしまい、量産試作の重量測定で設計値との乖離が発覚し、原因を遡ったところ変換時に一部のリブ形状が欠落していたことが判明した。この経験から、質量特性の比較は「余裕があればやる」作業ではなく、検図の必須項目として位置づけるようになった。

客先・協力会社とのCAD環境差への対応

常駐先が変わるたびにCAD環境そのものが変わることも珍しくない。客先によってはPDMやPLMのシステムと連携した独自の出図ルールがあり、変換フォーマットの指定やファイル命名規則が細かく決められている場合もある。私はまず案件に入る初日に、データの受け渡しルールと使用フォーマットを確認するようにしている。ここを曖昧にしたまま作業を進めると、納品直前になって「そのフォーマットでは受け取れない」と指摘され、変換作業をやり直す事態になりかねない。確認する項目は、使用フォーマットだけでなく、圧縮の可否、1ファイルあたりの容量上限、アセンブリ構造の分割単位など、細部にまで及ぶ。こうした項目を初日にまとめてヒアリングしておくと、案件の途中で「実はこういう制約があった」と後出しで判明する事態を大きく減らせる。

また、社外に協力会社がいる場合は、相手先のCADバージョンやライセンス状況が変わることもあるため、案件の節目ごとに確認を取り直すようにしている。一度確認したから安心ではなく、継続的な案件では定期的な確認が欠かせないというのが実感だ。

別の常駐先では、ファイル名に使用できる文字数や記号に細かい制限があり、私が普段使っていた命名規則のままデータを納品しようとしたところ、PDMシステムへの取り込み時にエラーが発生し、受け取りを拒否されたことがあった。原因は、案件コードの区切りに使っていたアンダースコアが、先方のシステムでは別の意味を持つ予約文字として扱われていたためだった。この一件以降、新しい現場に入った初日には、データの受け渡しルールに加えて、ファイル命名規則やフォルダ構成のサンプルも必ず入手し、最初の1件を提出する前に先方の担当者に形式チェックをお願いするようにしている。小さな確認だが、これを怠ると案件の立ち上がりでつまずくことになる。

変換ルールをチームで統一する

個人の判断で変換フォーマットや設定を都度変えていると、チーム内でデータの品質にばらつきが出てしまう。私が関わったプロジェクトでは、変換時の許容誤差設定やフォーマットの選定基準を簡単な社内基準としてまとめ、誰が作業しても同じ手順を踏めるようにした。基準を文書化したことで、新しく入ったメンバーへの引き継ぎもスムーズになり、変換トラブルの再発率が明らかに減った。

基準には、使用するフォーマットの優先順位(ネイティブ>STEP AP242>STEP AP203>IGES)、許容誤差の目安値、板金や溶接構造など特殊フィーチャーを含む場合の対応方法などを盛り込んでいる。細かいことのようだが、こうした地味なルール整備が、後々の大きな手戻りを防ぐ最も確実な方法だと感じている。

具体的な数値基準としては、一般部品は変換許容誤差0.01mm、精密な位置決めや嵌合部を含む部品は0.001mm、検討段階の参考モデルは0.05mmというように、部品の重要度に応じて3段階の目安を設けている。この基準を作る前は、担当者ごとに感覚で設定値を決めていたため、同じ案件内でも部品によって精度がまちまちになり、後から「なぜこの部品だけ精度が粗いのか」と客先から指摘を受けたこともあった。数値の目安を明文化してからは、こうした精度のばらつきに関する指摘はほぼなくなった。

クラウド型CAD連携が広げる可能性と注意点

近年は、クラウド上でモデルを共有し、ブラウザ経由で複数の関係者が同時に閲覧・コメントできる仕組みを採用する現場も増えてきた。私が最近携わった案件でも、客先とのモデルレビューをクラウドビューアで行い、その場で修正指示をマーキングしてもらうスタイルに切り替わった。従来のようにファイルをメールでやり取りして版数を追いかける手間が減り、レビューのスピードは明らかに上がったと感じている。

ただし、クラウドビューア上で表示されるモデルも、内部的には軽量化のための変換処理を経ていることが多い。表示上は問題なく見えても、実際の加工用データとしてダウンロードすると、精度設定の違いによって微妙な形状差が生じる場合がある。私はクラウド経由でやり取りしたモデルについても、最終的に図面へ反映する前には、元のネイティブデータかSTEPデータでの再確認を欠かさないようにしている。便利なツールが増えるほど、どの段階のデータが正でどの段階のデータが確認用なのかを明確に区別しておくことが重要になる。

実際に、あるクラウドビューア経由でレビューを行った案件では、表示上は綺麗に見えていた曲面が、実際にダウンロードしたSTEPデータでは軽量化のためのメッシュ近似精度が粗く、0.1mm程度の面の凹凸が生じていたことがあった。レビューの場では誰も気づかず承認が進んでしまい、後工程で干渉チェックを行った際に初めて問題が発覚した。それ以降、クラウドビューアでのレビューはあくまで形状と配置の大枠を確認する場と割り切り、最終的な数値の確認は必ずネイティブかSTEPの実データで行うという役割分担を、チーム内でも明確にするようにしている。

CAD間のデータ変換は、便利な反面、見えないところで情報が失われるリスクを常に抱えている。ネイティブと中間ファイルそれぞれの特性を理解し、案件の性質に応じて使い分けること、そして変換後には必ず検図を行うことが、結局は一番の近道になる。20年の実務を通じて感じるのは、変換トラブルの多くは「知っていれば防げた」種類のものだという点だ。派手な技術力よりも、地道な確認作業を積み重ねる姿勢の方が、結果として案件全体の信頼性を支えている。