2026.08.24 ERP

PLM CAD連携の3方式｜直接連携・中間DB・APIの選び分けとBOM整合の実務

PLMとCADの連携は、CADで描いた形状と属性を、品番・版数・変更履歴という管理情報に結びつける作業です。方式はCADアドインによる直接連携、中間データベースやファイル取込、REST APIとイベント通知の3つに大別され、どれを選ぶかで初期費用よりも先に「CADを更改したときに壊れるかどうか」が変わります。ところが不整合の多くは方式の選択ミスではなく、品番を誰が採番するのか、版数をどの承認で確定させるのかを決めないまま接続した結果です。この記事では、PLMとCADが受け渡す情報の実体、3方式の適合条件と比較、設計BOMから製造BOMへ展開するときのキー設計、図面版数と部品表がずれる仕組み、そして連携を作り込む前に切る判断軸までを順に整理します。

まとめ：連携方式より先に決める品番採番と版数の主体、作り込みを切る線

先に結論を示します。PLMとCADの連携で最初に決めるのは方式ではなく、品番の採番をCAD側とPLM側のどちらで行うか、そして版数を「承認済」に確定させる操作をどこに置くかの2点です。この2点が曖昧なまま接続すると、直接連携でもAPI連携でも同じ不整合、つまり図面は改訂されているのに部品表が旧版のまま、という状態に行き着きます。

方式は3つに分かれます。CADアドインの直接連携は設計者の操作がそのままPLMへ届く代わりに、CADのメジャー更改に追従する手間を抱える構造です。中間データベースやファイル取込は2D・3D・エレキが混在する現場に向き、反映が翌営業日でも困らないなら費用対効果で優位に立ちます。REST APIとイベント通知は、PLMとCADに加えて生産管理やERPまで3者以上をつなぐときに中核となる方式です。

そして、作り込まない判断も現実的な選択肢に入ります。品目数が数百規模、設計変更が月に数件、使うCADが1本という条件がそろうなら、PDM標準機能と取り決めた手順で足ります。この規模でAPI連携を設計するのは過剰です。

PLMとCADが受け渡す情報の実体と、図面・設計BOM・属性が流れる順序

連携の設計は、両者が何を持っているかの切り分けから始まります。ここを曖昧にしたまま「CADとPLMをつなぐ」と表現すると、要件が形状データの受け渡しなのか、管理情報の同期なのかが混ざります。

CADが持つ形状・属性とPLMが持つ品番・版数・変更履歴の分界点

CADが持つのは、形状そのもの、部品とアセンブリの親子構成、そして図面の表題欄に書かれた部品番号・名称・員数・材質といった属性です。対してPLM（PDM）が持つのは、その図面ファイルを一意に指す品番、リビジョン、状態（作業中・承認待ち・承認済・廃止）、変更履歴、そして「この部品を変えると影響する製品はどれか」を引くwhere usedの関係です。

分界点は単純に引けます。ファイルの中身はCADの領分、ファイルを識別する番号と状態はPLMの領分。この線を引いておくと、どちらのマスタを正とするかで揉めなくなります。実際、Teamcenter Integration for NXはCADの画面からチェックイン・チェックアウト、リビジョン、where usedを扱わせる作りで、設計者がCADを離れずにPLM側の状態を動かせる設計です。PDMとPLMの守備範囲そのものはPDM・PLMとは何かを整理した記事で扱っているため、ここでは連携の観点に絞ります。

表題欄の部品番号から設計BOMが生成される流れと採番主体の決め方

設計BOM（EBOM）は、CADのアセンブリ構成と表題欄の属性から組み立てられます。どの部品が何個、どの子部品を持つか、という情報はCADの構成に既にあるため、連携インターフェースがそれを読み取ってPLMの品目と構成に写す仕組みです。手入力の転記を挟まないぶん、員数の写し間違いが消えます。

ここで決めるのが採番の主体です。CAD側で設計者が品番を手入力する運用は、着手が速い代わりに重複と体系崩れを招きます。PLM側で自動採番して、その番号をCADの表題欄へ書き戻す運用にすると重複は原理的に消えますが、設計者の端末からPLMへ接続できる状態が前提になります。キヤノンITSのPLM CAD連携インターフェースが品番自動採番・3D情報登録支援・文書一括自動登録の3機能で構成されているのは、この採番と登録が連携の中心だからです。迷ったらPLM側採番を選び、CADはその番号を受け取る側に回すのが後戻りの少ない形になります。

STEP AP242やJTなど中間フォーマットが担う受け渡しの役割

ネイティブCADファイルをそのまま渡せない相手、たとえば別のCADを使う取引先や、閲覧だけの製造・品質部門には中間フォーマットを使います。ISO 10303-242（STEP AP242）は2014年の初版でAP203とAP214を統合し、2020年の版で電気設計領域まで対象を広げた規格で、寸法公差などの製品製造情報を意味を保ったまま持ち運べます。軽量の可視化用にはJTがあり、ISO 14306:2017が発行済み、Version 3を定めるISO 14306-4が置き換え側にあたります（2026年8月時点）。

切り分けで注意したいのは役割です。中間フォーマットは「見る・渡す」ための形式であって、版と構成の正本ではありません。JTやXVLを製造現場へ配りながら、リビジョンの正はPLMに置く。この原則を崩して中間ファイルを配布物の正本にすると、旧版のJTが現場に残り続ける事故が起きます。

直接連携・中間DB・API連携の3方式で分かれるCAD統合の作り方と適合条件

方式選定は、費用よりも「変化にどれだけ追従できるか」で見ます。CADは数年おきにメジャー更改があり、PLM側も保守で版が上がるためです。

CADアドイン型の直接連携が持つ即時性と、CAD更改時に生じる制約

CADのメニューにPLMの操作を埋め込む方式です。設計者がチェックインした瞬間に構成と属性がPLMへ渡り、承認ワークフローも同じ画面から回せます。PTCのWindchill Workgroup ManagerはCATIA・NX・SOLIDWORKSといった他社CADに対応し、利用する端末それぞれへインストールして使います。

制約は2つあります。第一に、CADのメジャー更改時は、対応する連携モジュールが提供されるまで更改を待つか、設計部門とPLMの版を分けて運用する判断が要ること。第二に、端末台数分の配布と動作確認が保守作業として毎回発生することです。設計者が10名なら軽い作業ですが、拠点をまたいで100名規模になると、更改のたびに数週間の展開計画を組む前提で費用を見ておきます。

中間DB・ファイル取込型が向く多CAD混在環境と遅延の許容条件

CADからCSVやXMLで構成と属性を書き出し、中間データベースを経由してPLMへ取り込む方式です。2D CAD、3D CAD、電気系CADが混在し、それぞれにアドインを用意すると費用が積み上がる現場で効きます。CAD側の更改に強いのも利点で、出力フォーマットさえ維持されれば連携部分は作り直しになりません。

成立条件は反映の遅延を許容できることです。夜間バッチで日次反映なら、朝の時点で前日の設計変更が部品表に載ります。この1営業日の遅れが欠品や手戻りにつながらない業態か、を先に確認します。取込失敗時の再実行と、差分だけを入れるか全件を入れ替えるかの設計も、運用開始前に決めておく箇所です。

REST APIとイベント通知で組む方式の適合条件と見積りの観点

PLMが公開するAPIを呼んで品番を採番し、BOMを登録し、状態変更のイベントを受けて生産管理やERPへ流す方式です。つなぐ先が2つで終わらず、調達・原価・製造実行まで広がるときに中核となります。API連携の仕組みとデータ連携との違いは一般論として整理しているため、ここでは見積りに効く要素だけ挙げます。

費用を決めるのは接続点の数ではなく、写像する項目の数と例外処理です。品番・構成・改訂記号・数量単位・状態という5要素の写像規則、認証方式、失敗時のリトライと二重登録を防ぐ冪等性、そして「途中まで登録して落ちた」ときの復旧手順。この4点の詰め方で工数は倍近く変わります。

3方式を初期費用・変更追従・多CAD対応・運用負荷で並べた比較

同じ「連携」でも、費用の出方と壊れ方が違います。判断の材料として6つの観点で並べます。

観点	直接連携（アドイン）	中間DB・ファイル取込	API・イベント連携
初期費用	製品ライセンス中心	低め・出力設計が主	高め・設計工数が主
反映の速さ	チェックイン時に即時	日次バッチが基本	即時と定期を選べる
CAD更改の影響	大きい・対応版待ち	小さい・出力維持で可	中程度・出力側次第
多CAD混在	CADごとに追加費用	得意・出力を揃える	得意・写像を集約
つなぐ先の広がり	PLMとCADの2者向き	3者以上は組みにくい	3者以上に向く
運用負荷	端末配布と検証	取込失敗の再実行	監視とエラー通知

CADが1本で設計者が同じ拠点に集まっているなら直接連携が素直に収まります。CADが複数あって出力を揃えられるなら中間DBが費用面で優位です。そして下流の生産管理やERPまで巻き込むなら、最初からAPIを前提に設計したほうが、後から作り直すより安く済みます。

設計BOMから製造BOMへ展開するときに整合が崩れる箇所とキー設計

連携が動き始めてから問題になるのは、渡す仕組みではなく渡した後の構造です。

設計BOMと製造BOMが1対1にならない理由と工程で増える構成

設計BOM（EBOM）は機能単位で製品を分解した構成、製造BOM（MBOM）は作る順序で分解した構成です。両者がずれるのは、製造の都合で構成要素が増減するためです。

工程を分けた結果、EBOMに存在しない中間品・半製品が立つ
治具・副資材・接着剤・梱包材など、設計図面に現れない品目が加わる
調達の都合で代替部品が併記され、1つの設計品番に複数の調達品番が紐づく
同じ部品でも、内製する拠点と外注する拠点で構成の切れ目が変わる

この非対称を「連携で自動的に解ける問題」と考えると失敗します。EBOMからMBOMへの展開は、写像規則を人が定義してPLM側に持たせる作業です。まず自社のEBOMとMBOMを1製品ぶん並べ、増える品目と切れ目の違いを数えるところから始めます。

品番・改訂記号・数量単位という3つのキーで整合を保つマスタ設計

不整合の実態を分解すると、ほぼこの3つのキーに帰着します。品番は、意味を持たせない連番にするか、分類を埋め込んだ体系にするか。連番は改廃に強く、体系は人が読んで分かる代わりに分類変更で破綻します。両システムをつなぐなら、少なくとも連携キーは意味を持たない値にしておくと後が楽になります。

改訂記号は、CAD側の図面リビジョンとPLM側の品目リビジョンを同じ体系にするか、別体系にして対応表を持つかを決めます。A・B・Cの英字と01・02の数字が混在したまま連携を組むと、突合のたびに変換規則の確認が必要です。数量単位も同様で、個・セット・メートルの換算をどちら側で持つかを決めておかないと、部品表の員数が1桁ずれます。3つとも、連携の実装より前に紙の上で決まる話です。

設計変更をPLMから生産管理・ERPへ反映する経路と有効日付の扱い

設計変更は、変更要求から変更指示（ECR・ECO・ECN）へ進み、承認されて初めて下流へ流れます。連携で作り込むのは、この承認済イベントを起点に製造BOMの改訂を生産管理側へ渡す経路です。受け側の機能範囲は生産管理システムの機能とERP・MESとの違いで整理しているとおりで、所要量計算の基準になるBOMがここで書き換わります。

経路と同じくらい効くのが有効日付（エフェクティビティ）の扱いです。「いつから新しい構成で作るか」を日付で持つか、製造ロットやシリアル番号で持つかで、切り替え時の在庫の食い潰し方が変わります。日付基準は運用が単純ですが、旧部品の在庫が残ると廃棄が生じる要因です。シリアル基準は在庫を使い切れる代わりに、生産管理側がシリアル単位の構成を扱えることが前提になります。ここを連携の後回しにすると、切り替え日に現場が混乱します。

図面版数と部品表の不一致が生まれる仕組みと、承認で止める運用設計

「図面は最新なのに部品表が古い」という状態は、連携が壊れて起きるより、正常に動いた結果として起きるほうが多いものです。仕組みを分解します。

チェックイン前の図面と確定BOMがずれる承認タイミングの非同期

不一致の起点は、CAD側の作業単位とPLM側の承認単位が一致しないところにあります。設計者は部品を1つ直してチェックインしますが、製品としての改訂は関連する複数図面がそろって初めて確定する流れです。1点だけ先にPLMへ入った状態で下流へ流すと、部品表は新しい部品番号を指し、組み合わせる相手の図面は旧版のまま、という食い違いが生まれます。

設計としての答えは、状態が「承認済」になった構成だけを下流へ配信することです。チェックイン即配信にしない。作業中のリビジョンは設計部門の内側に留め、承認ワークフローを通過した版だけが生産管理と調達から見える。この一段を挟むだけで、不一致の大半は起きなくなります。

旧版図面での製造や誤発注が起きる典型パターンと突合で検知する手順

それでも抜けは出ます。現場に印刷図が残っていた、外注先へメールで送った旧版がそのまま使われた、といった経路は連携の外側にあるためです。定期的な突合で検知します。

PLM側で、状態が承認済の品目とリビジョンの一覧を抽出する
生産管理側で、有効な製造BOMの品目とリビジョンを同じ粒度で抽出する
品番をキーに突き合わせ、リビジョンが異なる行と、片側にしか存在しない行を洗い出す
差分について、有効日付の前後かどうかで正当な差か不整合かを切り分ける
不整合と判定した行を、変更指示の番号までさかのぼって原因を特定する

この突合は月次で回せば十分に機能します。差分が毎回同じ品目群で出るなら、原因は連携ではなく運用側、たとえば外注先への配布経路です。図面の配布と版管理そのものの整え方はCAD図面の版管理・検索・配布を扱う図面管理システムの記事で扱っています。

連携で止める範囲と運用で止める範囲の線引きと、版数の粒度の決め方

すべてを連携で防ごうとすると費用が跳ね上がります。線引きの原則は、システムをまたぐ齟齬は連携で止め、人と紙が介在する齟齬は運用で止める、です。承認済以外を下流へ出さないのは連携の仕事。印刷図に有効期限を書いて回収するのは運用の仕事。この振り分けを最初に合意しておくと、要件が際限なく膨らみません。

連携の前段でつまずくケースも同じくらい多く、部品表の多重管理や登録責任の空白がそのまま日程の遅れに変わります。導入プロジェクトが止まる要因の切り分けはPLM導入の課題を4つに分解｜BOM多重管理・部門分断・データ移行・設計変更追従の解き方で扱っています。

版数の粒度も同じ考え方で決めます。誤記の訂正まで製品リビジョンを上げると、下流への配信が頻発して現場が慣れてしまいます。形状や員数が変わる改訂と、注記の修正にとどまる改訂を分け、下流へ配信するのは前者だけにする。粒度を分けずに一律運用した現場ほど、通知が無視されるようになります。

連携を作り込む前に切る判断軸｜手運用・定期取込・本格連携の分かれ目

ここは判断を言い切ります。PLMとCADの連携は、作れば効果が出る類の投資ではありません。作らない選択が正解になる条件が実在します。

品目数・設計変更頻度・CAD本数で見る、連携を作らない判断の条件

次の3条件がそろう現場では、連携の作り込みは見送ってかまいません。管理品目が数百点の規模にとどまること、設計変更が月に数件で担当者が全件を把握できること、そして使うCADが1本で外注先も同じCADを使っていること。この状態なら、PDM製品の標準機能と、図番・改訂の取り決めを文書化した手順で回ります。

この条件下でAPI連携を設計するのは過剰です。初期の設計工数と、その後の監視・エラー対応の運用負荷が、削減できる転記工数を上回ります。投資すべきは連携ではなく、品番体系と改訂ルールの整理のほうです。逆に言えば、ルールが定まっていない状態で連携を作ると、不整合を高速に量産する仕組みが完成します。

CSVの定期取込で足りる場面と、本格連携へ切り替える具体的な閾値

手運用の次の段は、CADからCSVを書き出して夜間にPLMや生産管理へ取り込む形です。設計変更の反映が翌営業日でよく、1回の取込が数百行に収まり、CADが1本なら、この形で数年は持ちます。実装は出力テンプレートと取込ジョブだけで済み、費用も一桁小さくなります。

当日中に反映しないと欠品や手戻りが出る品目が、月に数回以上発生する
CADが2本以上になり、出力項目の写像をCADごとに書き分ける必要が出た
取込エラーの手直しに月10時間以上かかっている
PLMとCADに加えて、生産管理・原価・調達など3つ目以降の接続先が確定した

このうち2つ以上に当てはまったら、本格連携へ切り替える時期です。1つだけなら、まず運用側の是正で片づかないかを先に確認します。取込エラーが多いだけなら、原因は出力側の項目定義であることが大半で、連携方式を変えても解決しません。

標準コネクタで届かない要件と、受託開発に切り替える線引きの条件

PLM製品が用意する標準コネクタで足りるかどうかは、次の4点で判定できます。品番体系が製品の想定と違う独自ルールになっていないか、承認の多段構成が製品のワークフロー機能で表現できるか、接続先の生産管理が自社開発でAPIが限られていないか、代替品や暫定出図といった自社固有の運用が構成データとして表現できるか。すべて標準の範囲に収まるなら、コネクタ設定と運用設計だけで完了します。

1つでも標準から外れるなら、外れた部分だけを個別開発でつなぐ形にします。全面スクラッチではなく、標準コネクタで届く範囲は製品に任せ、写像規則と例外処理だけを作る切り分けが費用面で有利です。既存の基幹側にAPIが無い場合の接続層の設計まで含めて相談したい段階なら、API開発・システム連携の受託で扱う領域に入ります。判断を先送りして標準コネクタに無理な設定を積むと、製品のバージョンアップで設定が壊れ、結局作り直しになります。

PLMとCADの連携検討で多く挙がるよくある質問と実務目線の回答

連携の設計段階で繰り返し出る質問と、実務での答え方をまとめます。

PLMとCADはどのように連携するのですか？

CADのアセンブリ構成と表題欄の属性を読み取り、PLM側の品目・構成・リビジョンとして登録する流れが基本です。手段はCADに組み込むアドイン、CSVやXMLを介した取込、PLMのAPI呼び出しの3つ。どの手段でも、品番を採番する側と、版数を確定させる承認の置き場所を先に決めることが前提になります。ここが決まっていれば手段は後から差し替えられますが、決めずに接続すると方式を変えても不整合は残ります。

PDMとPLMのどちらでCAD連携すればよいですか？

設計部門の内側で図面と設計BOMを整えたい段階ならPDMで足ります。CAD連携の機能はPDM製品にも備わっており、チェックイン・チェックアウトと版管理がここで完結する構成です。一方、設計変更を調達・製造・保守まで届けたい、原価や品質情報と結びつけたいという要求が出ているならPLMを選びます。多くのPLM製品はPDM機能を内包するため、PDMから入って段階的に広げる経路も取れます。

CADを複数使っている場合でもPLM連携できますか？

できます。PTCのWindchill Workgroup ManagerがCATIA・NX・SOLIDWORKSなどに対応しているように、主要PLMは他社CAD向けのコネクタを揃える構成です。ただしCADごとにライセンスと保守が積み上がるため、3本以上になるとCSVやXMLの出力形式を揃えて中間データベース経由で取り込む方式のほうが、費用と保守の両面で軽くなる場面が多くなります。判断材料は本数と、各CADの利用者数です。

PLMとCADの連携にはどのくらいの費用と期間がかかりますか？

接続の本数より、写像する項目数と例外処理の量で決まります。標準コネクタの設定と運用設計だけなら短期で立ち上がり、費用も製品ライセンスの範囲に収まります。独自の品番体系や多段承認、自社開発の生産管理との接続が絡むと、写像規則の定義と失敗時の復旧設計に工数が寄り、期間が伸びる要因です。見積り依頼の前に、連携対象の項目一覧と、想定する例外（重複品番・登録途中の失敗・代替品）を書き出しておくと精度が上がります（2026年時点の一般的な傾向で、製品と範囲により幅があります）。

設計BOMと製造BOMはPLMとERPのどちらで管理すべきですか？

設計BOMはPLM、製造BOMは展開規則をPLMに置き、確定した構成をERPや生産管理へ渡す形が扱いやすい分担です。ERP側で製造BOMを直接編集する運用にすると、設計変更との対応関係が切れ、どの改訂に基づく構成なのかを追えなくなります。PLMが「何をどう作るか」の定義を持ち、ERPが「実際にいくつ作りいくらかかったか」の実績を持つ。この線を守ると、突合の手順も単純になります。ERP側から見た守備範囲の線引きと導入順序の判断はERPとPLMの違いを扱った記事で解説しています。