--- title: "ERPとPLMの違い：守備範囲とBOM連携の設計・どちらを先に入れるかの判断" url: "https://www.issoh.co.jp/column/details/16914/" published: 2026-08-24 updated: 2026-08-24 categories: ["ERP"] publisher: "株式会社一創" --- # ERPとPLMの違い：守備範囲とBOM連携の設計・どちらを先に入れるかの判断 ERPとPLMは、どちらも製造業の情報を一元化する器として説明されます。ところが「経営の統合がERP、製品の管理がPLM」という対比だけを持って選定に入ると、要件定義の途中で必ず詰まります。詰まる場所は決まっていて、品目マスタをどちらで採番するか、部品表をどちらが正とするか、設計変更をいつからERPへ効かせるか、という三点です。この記事では、二つの器を「扱うデータの性質」と「時間軸」で切り分けたうえで、機能が重なる領域の特定、BOMを渡すときの設計、そしてどちらを先に導入するかの判断条件までを順に整理します。ERPそのものの機能とモジュール構成は[ERPの定義と導入の進め方を解説した記事](https://www.issoh.co.jp/column/details/12806/)、PDMとPLMの差は[PDM・PLMの守備範囲を扱った記事](https://www.issoh.co.jp/column/details/13533/)で解説しているため、ここでは二つの器の間にある論点だけを扱います。 ## まとめ｜ERPは確定後の取引、PLMは確定前の仕様。分界は情報が固まる時点 ERPとPLMの違いを一行で言い切るなら、情報が確定した後を受け持つのがERP、確定する前を受け持つのがPLMです。ERPが記録するのは、発注した、入庫した、消費した、原価が出た、という起きてしまった事実。PLMが記録するのは、この部品をこの仕様にする、この図面を第3版に改訂する、この変更を次のロットから適用する、という決めごとの過程になります。前者は変えてはいけない記録で、後者は変わることを前提にした記録という点が、システムの作りを根本から分けています。 この分界が分かると、機能が重なって見える領域の正体も見えてきます。両方が持つのは品目マスタ、部品表、購買に関する情報、原価に関する情報の四つ。ただし同じ名前でも中身は違い、PLM側の品目は「まだ図面上の存在」で、ERP側の品目は「発注できる対象」です。部品表も、PLMが持つのは設計構成（E-BOM）、ERPが持つのは製造構成（M-BOM）で、両者は一対一になりません。ここを「どちらでも持てるから、どちらかに寄せよう」と処理すると、寄せた側で本来の役割が壊れます。 導入順序については、条件付きで言い切れます。月次の締めが遅れている、在庫と帳簿が合わない、原価が製品別に出ないという状態ならERPが先。図面の版がずれて旧版で手配が出ている、同じ部品が別品番で並立している、拠点間で図面の受け渡しが手作業という状態ならPLMが先です。そして品目数が1,000点前後まで、設計変更が月に数件、拠点が1か所という条件なら、PLMは見送って命名規則と保管場所のルールで足ります。 ## ERPとPLMの守備範囲の違いを、扱うデータと時間軸の二軸で捉える 比較表を眺める前に、二つの器が何を守っているのかを押さえます。 ### ERPが受け持つのは確定した取引と実績｜受発注・在庫・原価・会計 ERPが束ねているのは、社内で発生した取引の記録です。受注、発注、入出庫、製造指図の実績、経費、会計仕訳。共通するのは、いったん確定したら勝手に書き換えてはいけないという性質になります。過去の在庫数を後から修正すれば、その時点の原価も期末の残高も崩れるためです。 だからERPは、変更を「取り消しと再登録」で表現します。伝票を直すのではなく、赤伝を切って新しい伝票を起こす。数量・金額・日付・勘定科目という単位で厳密に整合を取る設計で、逆に言えば、まだ金額の付いていない検討中の情報を置く場所がありません。 もう一つの特徴は、モジュール間で数字が連鎖することです。購買の入庫が在庫を動かし、在庫の払出が製造原価を作り、原価が売上原価として損益に乗る。導入形態や費用の構造は[ERPの導入形態と費用の見方を扱った記事](https://www.issoh.co.jp/column/details/12806/)で整理しました。 ### PLMが受け持つのは確定前の仕様と履歴｜図面・属性・設計変更の記録 PLMが束ねているのは、製品をどう作るかという決めごとと、それが変わってきた経緯です。図面、3Dモデル、部品の属性、設計変更の要求と承認、版数。共通するのは、変わることが前提という性質になります。しかも旧版は捨てられず、その版で作った製品が市場にある限り参照できる必要があります。 そのためPLMは、変更を「版の積み上げ」で表現します。上書きせず履歴として残し、どの版が有効かをステータスで管理する。承認前の図面は誰にも見えず、承認された瞬間に下流へ公開されるという段階的な可視性も持ちます。ERPが確定した数字を守るために厳密なのに対し、PLMは確定に至る過程を残すために厳密という違いです。 金額の扱いも異なります。PLMが持つ原価情報は設計段階で見積もった目標原価や予定原価で、実際に発生した金額ではない。設計者が部品を選ぶときの判断材料なので、精度より速さが求められます。PLM単体の機能範囲とPDMとの分け方は[PDMとPLMの違いと機能を解説した記事](https://www.issoh.co.jp/column/details/13533/)を参照してください。 ### 分界は情報が固まる時点で引く｜同じBOMでも持ち主が入れ替わる理由 ここまでを一枚の線にまとめると、「情報が確定した瞬間」が分界です。図面が承認され、部品表が確定し、品番が発行される。その瞬間より前はPLM、後はERPという引き方をすると、機能の割り当てで迷わなくなります。 | 比較の軸 | PLM | ERP | | ------ | ---------- | ---------- | | 扱う時間軸 | 確定する前 | 確定した後 | | 情報の性質 | 仕様の決めごと | 取引と実績の記録 | | 変更の表現 | 版を積み上げる | 取消と再登録 | | 部品表の種類 | 設計構成のE-BOM | 製造構成のM-BOM | | 主な利用部門 | 設計・開発・品質 | 調達・製造・経理 | | 原価の意味 | 目標原価と予定原価 | 実際に発生した原価 | | 旧情報の扱い | 履歴として保持 | 締めた期は固定 | 注目してほしいのは「部品表の種類」の行です。BOMという同じ言葉が両方に出てくるのに、指しているものが違う。この一点が二重投資と連携設計の起点になります。 ### 似た名前の仕組みとの位置関係｜PDM・生産管理・MESとの並び順 周辺の仕組みとの並びも押さえておきます。PDMはPLMの一部で、図面とCADデータの版数管理に絞った範囲を指す呼び分けです。生産管理システムはERPの製造領域を切り出して深めたもの、MESはさらに現場側で設備と作業者の実績を拾う層。情報の流れは、PLMで仕様を決め、ERPまたは生産管理で手配と製造を回し、MESで実績を返す、という順序になります。生産管理システムとERPやMESの守備範囲は[生産管理システムの機能とERP・MESとの違いを扱った記事](https://www.issoh.co.jp/column/details/13633/)で整理しました。 ## 機能が重なる四つの領域と、ERPとPLMを両方入れたときの二重投資 両方の製品カタログを並べると、同じ機能名が四か所で重なります。放置したまま導入すると、データの二重管理が始まります。 ### 品目マスタ｜採番の主体と属性の置き場をどちらへ寄せるかの決め方 品目マスタは最も重なる領域です。PLMは設計者が部品を起こした時点で品番を必要とし、ERPは発注する時点で品番を必要とする。同じ部品に対して、別々のタイミングで別々の採番が走る余地があります。 決め方の原則は、発生源で採番することです。新規設計の部品なら設計者が起こす瞬間が最初なので、PLM側で採番してERPへ渡す。設計を伴わず調達が決める購入部品なら、ERP側で採番してPLMへ渡す。この二経路を認めたうえで、どちらで生まれた品番かを識別できるようにしておくと後の突合が軽くなります。 属性の置き場も分けます。図面番号・材質・表面処理・質量・環境規制の適合区分といった設計由来の属性はPLM側、仕入先・標準単価・リードタイム・発注単位・保管場所といった調達由来の属性はERP側。両方に同じ属性を持たせると、更新のたびに同期が必要になり、同期が止まった瞬間に不整合が始まります。 ### BOM｜設計BOMと製造BOMの境目と、変換をどちらで持たせるか 設計BOM（E-BOM）は、製品がどの部品で構成されるかを機能単位で表した構造です。製造BOM（M-BOM）は、それを工程の順序に並べ替え、中間品や副資材や治具を足した構造。ネジやワッシャーが設計上は明細に無くても製造では必要、という差がここに出ます。 両者が一対一にならない以上、どこかで変換が要ります。変換をPLM側で持つなら、製造部門がPLMを触ることになり、設計者以外のユーザーライセンスが増える。ERP側で持つ場合、工程情報はERPにあるので変換は自然ですが、設計変更が来るたびにERP側で組み替え作業が発生します。 判断の目安は、工程の変動幅です。工程が安定していて中間品の定義が固定的ならERP側で持つほうが軽い。同じ製品を複数拠点で違う工程で作る業態ならPLM側で持つ形が合います。CADとPLMの間の受け渡しやキー設計は[PLMとCADの連携方式とBOM整合を扱った記事](https://www.issoh.co.jp/column/details/16910/)で扱っています。 ### 購買情報と原価｜見積段階と実際発生額で持ち主が分かれる線の引き方 購買に関する情報も両方に現れます。PLMが持つのはサプライヤ候補と参考見積、ERPが持つのは契約単価と発注実績。設計段階では「この部品はA社から1個300円で買える見込み」を使い、調達段階で「実際にA社と285円で契約した」という記録を残す役割分担です。 原価も同じ構図で、PLMは目標原価と予定原価、ERPは標準原価と実際原価を持ちます。混ぜてはいけないのは、設計段階の予定値をERPの標準原価としてそのまま登録してしまうケースです。歩留まりや段取り時間が入っていない数字が原価計算の基準になり、差異分析が意味を失います。 線引きの原則は、契約が発生する前後です。契約前の見込み値はPLM、契約後の確定値はERP。設計者が原価を見たい場合は、ERPの確定単価をPLM側へ参照表示する形にすると、二重に持たずに済みます。 ### 重複を残したまま両方を入れた現場で起きることと、費用の膨らみ方 四領域の重なりを整理しないまま両方を導入すると、症状が順番に出ます。最初は同じ部品が両方に別の品番で登録される事態。次に部品表の版がずれ、設計では第3版なのに手配は第2版で走る。最後に、どちらが正かを確かめる突合表がExcelで作られ、その更新が誰かの月次業務として固定化されます。 費用の膨らみ方は三段階です。両製品でライセンスを重複購入する分、重複機能を使わないよう設定するためのカスタマイズ費用、そして突合作業に消える人件費が毎月積み上がる分。三つ目は見積書に現れないため、導入後に効いてきます。導入が止まる要因の全体像は[PLM導入の課題を組織・データ・移行・変更管理に分解した記事](https://www.issoh.co.jp/column/details/16912/)で扱いました。 ## PLMからERPへBOMを渡す連携の設計｜粒度・有効日付・キーの決め方 守備範囲を分けたら、次は境目をどう渡すかです。製品選定より前に決まっているべき四点を挙げます。 ### 渡す単位と頻度｜構成の全量送信と差分送信を分けるときの判断の目安 渡し方には、製品構成を丸ごと送る全量方式と、変わった部分だけを送る差分方式があります。全量方式は実装が単純な反面、構成が数千行になると送信のたびに負荷がかかる。差分方式は軽い一方、送信の取りこぼしが起きると受け側が壊れたまま気付けません。 目安として、一製品あたりの構成行数が数百行までで変更頻度が週に数件なら全量方式で足ります。数千行、あるいは変更が日次なら差分方式へ切り替え、週次で全量突合を回して取りこぼしを検知する形が現実的です。差分だけを信じる設計は避けてください。 ### 有効日付とリビジョン｜設計変更をいつから効かせるかを決める手順 設計変更をERPへ反映するとき、いちばん揉めるのが「いつから効かせるか」です。日付で切る方式、ロット番号で切る方式、製造指図番号で切る方式、在庫を使い切ってから切る方式の四つがあり、どれを採るかで実装量が変わります。 日付方式は実装が最も軽く、多くのERPが標準で持っています。ただし在庫が残っている状態で日付が来ると、旧部品が使えなくなって現場が止まる。在庫消化方式は現場に優しい代わりに、切替時期が読めず変更管理の追跡が難しくなります。安全性に関わる変更は日付方式で即時、コストダウン目的の変更は在庫消化方式、という使い分けを変更区分ごとに定義しておくと運用が回ります。 手順としては、変更区分を三つか四つに分類し、区分ごとに切替方式を決め、その決定をPLMの変更票の必須項目にします。担当者判断に委ねると、同じ種類の変更で毎回違う切り方になり、後から追えなくなります。 ### キー設計の三点｜品番と改訂記号と数量単位を突き合わせるための決め事 連携が壊れる原因の大半は、キーの不一致です。押さえるべきは三点あります。 一点目は品番の桁数と文字種。PLM側が英数字混在の20桁を許し、ERP側が15桁までという組み合わせだと、渡した瞬間に切り捨てられます。二点目は改訂記号の扱いで、PLMは品番と版数を別項目で持つのに対し、ERPは版数の概念を持たないことが多い。互換性のある改訂なら同一品番、互換性が無いなら別品番、という基準で決めておくと扱いやすくなります。 三点目は数量単位です。設計は「個」で数え、調達は「メートル」や「キログラム」で買う部品があります。単位換算をどちらで持つか、換算率が変わったときに過去分をどうするかまで決めておかないと、発注数量がずれます。 ### 連携方式の選び分け｜手作業・定期取込・API連携を分ける三つの条件 接続の作り方は、手作業での再入力、CSVによる定期取込、APIによる連携の三段階です。手作業で足りるのは月あたりの新規品目が数十件まで、設計変更が月に数件という規模。この規模で連携を作り込むと、開発費が入力工数の削減額を回収できません。CSV定期取込へ切り替える合図は、新規品目が月100件を超えたとき、または転記ミスが月に複数回発生し始めたとき。API連携が要るのは、変更を当日中にERPへ反映しないと手配が止まる業態です。 標準のコネクタで届かないのは、独自の品番体系の読み替え、変換ルールを伴うE-BOMからM-BOMへの展開、拠点ごとに異なる工程マスタの割り当てといった領域です。ここに該当する要件が三つ以上あるなら、パッケージの設定で押し切るより、連携部分を[基幹システム開発](https://www.issoh.co.jp/service/business%5Fsystem/core%5Fbusiness/)として個別に作るほうが、結果として総額が下がる場面があります。標準機能に業務を合わせられるかを先に判定してください。 ## ERPとPLMのどちらを先に入れるかを業態と数字で決める判断基準 両方を同時に入れると決め事の量が一度に膨れ上がり、成功率が下がります。順序を付ける条件を症状の側から整理します。 ### ERPを先に入れる条件｜月次の締めが崩れている会社で効く順序と理由 ERPを先にすべきなのは、数字が出ていない会社です。症状は三つ。月次決算が翌月の中旬以降にずれ込んでいる、実地棚卸と帳簿在庫の差異が毎回発生する、製品別の原価が計算できず全社の粗利しか見えていない。いずれかに当てはまるなら、ERPが先になります。 理由は、PLMを先に入れても効果が測れないためです。PLMの効果は「設計の手戻りが減った」「旧版での手配が消えた」という形で現れますが、それが金額としていくらなのかは原価が製品別に出ていないと分かりません。投資判断の土台が無い状態で次の投資へ進むと、二本目の稟議が通らなくなります。 加えて、ERP側の品目マスタが整うと、PLM導入時の移行対象が絞り込めます。直近数年に取引のある品番が特定できれば、それを軸に図面の棚卸し範囲を決められるためです。 ### PLMを先に入れる条件｜図面と部品表の版がずれている会社の順序 PLMを先にすべきなのは、上流で情報が壊れている会社です。症状は、旧版の図面で製造や手配が出て年に複数回の作り直しが起きている、同じ部品が別品番で複数登録されている、拠点や外注先への図面の受け渡しがメール添付で属人化している、の三つ。 この状態でERPを先に入れると、壊れた品目データがそのままERPへ流れ込みます。ERPは入ってきた品番を疑わないので、重複品番のまま在庫が分散し、発注が分割され、原価が正しく積み上がりません。上流が汚れているなら上流から直すのが原則になります。 設計変更が多い業態も該当します。個別受注生産や顧客仕様への作り込みが常態化している製造業では、変更の追跡ができないこと自体が納期遅延の主因になっている場合があり、そこを先に押さえたほうが改善が早く出ます。 ### どちらも見送ってよい条件｜品目数・設計変更頻度・拠点数で引く線 導入しないほうが得な条件も明示しておきます。品目数が1,000点前後まで、設計変更が月に数件、拠点が1か所、設計者が数名という規模なら、PLMは見送って構いません。命名規則と保管場所のルールを決め、改訂時の周知を定型化するだけで、事故の多くは防げます。 ERPについても、部門が三つ以内で受注から出荷までの経路が単純、会計ソフトと販売管理ソフトの連携で数字が出ているなら、統合の効果は限定的です。検討へ入る合図は共通していて、同じ情報を二人以上が別々の場所で更新し始めたとき、拠点や外注先が増えて受け渡しが発生し始めたとき、人が代わると業務が止まるようになったときの三つになります。 ### 二重投資を避ける進め方｜先に入れる側で先に決めておく四つの項目 順序を決めたら、先に入れる側のプロジェクトの中で、後から入れる側のための決め事を先に済ませます。一つ目は品番体系で、桁数・文字種・採番の主体・既存型番からの読み替えルールを決める。二つ目は部品表の階層の持ち方で、どこまでを構成として持ち、どこからを工程情報とするかの境目を定義する。三つ目は変更の有効日付の方式を変更区分ごとに決めること。四つ目は、将来の連携でどちらを正とするかのマスタ管理方針を文書に残すことになります。 この四点を先行プロジェクトの成果物に含めておくと、二本目の導入で前提から決め直す事態が避けられます。逆にここを飛ばすと、二本目でマスタ設計をやり直すことになり、一本目のカスタマイズも手直しが要る。二重投資の実体は、ライセンスの重複よりむしろこの設計のやり直しにあります。 ## ERPとPLMの違いの検討で多く挙がるよくある質問と実務目線の回答 選定の初期に相談の多い5点について、実務での扱い方をまとめます。 ### ERPとPLMの一番の違いは何ですか？ 扱う情報が確定した後か前か、という点です。ERPは発注や入庫や原価といった起きてしまった取引を守る器で、いったん確定した数字は取消と再登録でしか変えられません。PLMは図面や仕様や設計変更といった、これから決まる情報を扱う器で、版を積み上げて履歴を残す作りです。この差があるため、部品表という同じ名前の機能でも、PLMは設計構成、ERPは製造構成という別のものを持ちます。「経営と製品」という対比より、時間軸の差で捉えるほうが機能の割り当てで迷いません。 ### ERPだけでPLMの役割を兼ねることはできますか？ 部分的には可能ですが、版数管理と承認ワークフローで限界が来ます。多くのERPは品目マスタに図面番号を持たせられる一方、図面ファイルそのものの版を管理し、承認前は下流に見せず承認と同時に公開するという段階的な可視性は標準では持ちません。判断の目安は、設計変更が月に十件を超えるかどうか。それ以下で図面が数百枚の規模なら、ERPの文書管理機能とファイルサーバーの運用ルールで足りる場面があります。 ### 設計BOMと製造BOMはどちらのシステムで管理すべきですか？ 設計BOMはPLM、製造BOMはERPまたは生産管理システムに置くのが基本形です。分けるのは、更新の主体が違うためになります。設計BOMを変えるのは設計者、製造BOMを変えるのは生産技術や製造部門で、承認の経路も別。変換をどちらで行うかは、工程が安定している業態ならERP側で組み替え、工程設計が製品開発の一部になっている業態ならPLM側で製造構成まで作って渡す形が合います。判断できないうちは設計BOMの側だけを正として固め、変換は手運用で回して作業量を測ってください。 ### ERPとPLMの連携にはどのくらいの費用と期間がかかりますか？ 連携の作り方で桁が変わるため、幅で捉えてください。CSVの定期取込で品目マスタと部品表を渡すだけなら、数か月と数百万円の規模で収まる場合があります。品番体系の読み替え、設計BOMから製造BOMへの変換ルール、有効日付による切替制御まで含めると、期間は半年から1年、費用も数倍の規模。期間を左右するのは開発そのものより、変換ルールを業務側で決める工程です。見積りの前に、対象の品目数、月あたりの設計変更件数、変換の例外パターンの数を実数で数えておいてください。 ### 中小規模の製造業でもERPとPLMの両方が必要ですか？ 両方は必要ない場合がほとんどです。品目数が1,000点前後まで、設計変更が月に数件、拠点が1か所という規模なら、PLMは見送って命名規則と保管場所のルールで運用したほうが費用対効果は上がります。逆に、部門をまたいだ数字が出ていない状態ならERP側を先に整える。両方を検討するのは、品目数が数千点を超え、設計変更が週次で発生し、拠点や外注先が複数ある段階からです。 ## 関連記事 - [ERPとは？基幹システム・CRMとの違いと主な機能・導入の進め方を解説](https://www.issoh.co.jp/column/details/12806/)：ERP単体の定義とモジュール構成、導入形態と費用の見方を扱っています。 - [PDM・PLMとは？製品情報管理と製品ライフサイクル管理の違い・機能・導入判断を解説](https://www.issoh.co.jp/column/details/13533/)：PDMとPLMの分界とPLM側の機能範囲が分かります。 - [PLM CAD連携の3方式｜直接連携・中間DB・APIの選び分けとBOM整合の実務](https://www.issoh.co.jp/column/details/16910/)：CAD側の接続方式とキー設計を解説しています。 - [PLM導入の課題を4つに分解｜BOM多重管理・部門分断・データ移行・設計変更追従の解き方](https://www.issoh.co.jp/column/details/16912/)：導入が止まる組織・移行・変更管理の要因を整理しています。 - [生産管理システムとは？機能・ERP／MESとの違いから種類・選び方と内製化の判断まで解説](https://www.issoh.co.jp/column/details/13633/)：下流側の生産管理とMESの守備範囲を扱っています。 --- 出典: [ERPとPLMの違い：守備範囲とBOM連携の設計・どちらを先に入れるかの判断]()（株式会社一創）