2026.08.25 Webシステム

製造業のデータ連携｜設備・MES・基幹の階層別インタフェース設計と段階導入

設備の稼働ランプは光っているのに、生産実績は月末に表計算ソフトへ手入力している。製造業のデータ連携で最初に出てくる相談は、たいていこの形です。原因は連携ツールを買っていないことではなく、設備・MES・基幹の3層で何を、どの向きに、どの粒度で渡すかを決めていない点にあります。本記事で扱うのは、層ごとに渡すデータの決め方、現場から信号を取る4方式の選び分け、連携を止める真因である品目コードの不一致、段階導入の順序です。API連携という手段そのものの仕組みはAPI連携の仕組みとデータ連携との違いを整理した解説に譲ります。

まとめ：製造業のデータ連携で先に決める4項目と着手の順序

結論から書きます。製造業のデータ連携で先に決めるのは、ツールでも基盤でもありません。①どの層とどの層をつなぐか、②渡すデータの粒度と頻度、③品目コードと工程コードの正本をどこに置くか、④現場から信号をどの方式で取るか。この4項目です。逆に言えば、この4つが埋まっていない状態で見積もりを取っても、金額は当たりません。

層の考え方は国際規格が下敷きになります。ANSI/ISA-95.00.01（IEC 62264-1 Mod）はレベル0の物理プロセスからレベル4の事業計画まで5段階を定義しており、2025年に改訂版が発行されました。実務ではこれを設備・制御層、MES層、基幹・ERP層の3つに畳めば足ります。3層の境界にどんなデータが何秒おきに流れるかを書き出す作業が、設計の入口です。

取得方式は4つ。PLCへ直接つなぐ、OPC UAで標準化する、IoTゲートウェイを後付けする、ファイル受け渡しや手入力を残す。10年以上前の設備が混ざる工場で1つの方式に全台を揃えようとすると、その時点で予算が跳ねます。方式は設備の世代ごとに分けるのが定石です。

そして、連携が動かない原因の大半は通信ではありません。同じ製品が設計では図番、製造では製番、営業では販売品目コードで呼ばれていて、突き合わせができない。ここを片づけないまま配線を引くと、つながった瞬間に「数が合わない」という報告だけが増えます。拠点が1つ、品目が数十点、基幹システムを2年以内に入れ替える工場は、いま急ぐ必要がありません。

設備・MES・基幹の3層で分かれるデータ連携の向きと粒度の決め方

最初に引く線は3本です。設備・制御層とMES層の境界、MES層と基幹・ERP層の境界、各層の中で完結させる範囲。この線を引かずに発注すると、要件定義の初日に議論が止まります。

設備・制御層から上げる3種類のデータ：稼働信号・実績カウント・アラーム

設備から上へ流れるデータは、実務ではおおむね3種類に収まります。1つ目は稼働信号で、運転中・停止中・段取り中といった状態を表すビット。2つ目は実績カウントで、良品数と不良数のカウンタ値。3つ目はアラームで、異常コードと発生時刻です。

この3種類を先に固定する理由は、取得周期がそれぞれ違うからです。稼働信号は1秒から数秒おきに変化を拾いますが、実績カウントは工程が1つ進むたびで足ります。アラームは発生した瞬間だけ。全部を同じ周期でポーリングすると、PLCの通信負荷と帯域を無駄に食います。センサの設置位置や台数といった現場側の発注仕様は工場IoTを4ブロックで整理した記事に譲り、ここでは上位へ渡す項目の決め方に絞ります。

MES層が受け持つ照合：作業指示と実績の突き合わせで決まる項目

MES層の仕事は、上から降りてきた作業指示と、下から上がってきた実績を突き合わせることです。指示に対して何個できたか、どのロットの材料を使ったか、誰がどの設備で作ったか。この突き合わせが成立するために必要な項目だけが、設備から上げるべきデータになります。

逆に言えば、突き合わせに使わないデータを吸い上げても、MESでは行き場がありません。温度や振動の波形といった連続値は、分析基盤側へ直接流すほうが構成として素直です。MESが持つ機能の内訳とISA-95レベル3としての位置づけは製造実行システムの11機能を実装要件まで分解した記事にまとめています。

基幹・ERP層へ渡す粒度：日次締めと在庫計上に必要な最小の単位

基幹側が欲しいのは、秒単位の生データではありません。品目別・日別の完成数量、消費した材料の数量、工程別の実働時間。この3つがあれば在庫計上と原価計算は回ります。

粒度を細かくしすぎると、月次の締め処理で扱うレコードが桁違いに増え、会計側の処理時間が伸びていきます。判断基準はひとつ。経理が仕訳を切る単位より細かいデータを基幹へ渡さないことです。より細かい分析が要るなら、分析基盤へ別ルートで流します。設備ログと生産実績を集約する構成はBigQueryを製造業で使う構成を連携方式と費用から整理した記事で扱っています。

上りと下りで難易度が変わる理由：指示を現場へ戻す下り連携の制約

実績を吸い上げる「上り」の連携は、失敗しても現場は止まりません。データが欠けるだけです。ところが計画や作業指示を現場へ降ろす「下り」の連携は、失敗すると設備が誤った条件で動きます。

そのため下り方向は、通信が切れたときに何が起きるかを先に決めます。前回の指示値を保持するのか、安全側の初期値に戻すのか、人の確認を挟むのか。多くの工場が導入初期に上りだけで止めるのは、この責任範囲の差があるためです。5階層の構成要素の整理はスマートファクトリーの定義と5階層を投資判断から解説した記事を参照してください。

現場データの取得方式4種：PLC直結・OPC UA・ゲートウェイ・ファイルの線引き

層の境界が決まったら、次は物理的にどう取るかです。この選択が工事費と保守負担を決めます。設備1台あたり数万円で済む場合もあれば、改造を伴って数百万円に届く場合もあり、差を生むのは設備の世代です。

PLCへ直接つなぐ方式：ベンダー固有プロトコルと通信負荷の条件

PLCが持つデバイスメモリを上位から直接読む方式です。三菱電機のMELSECならMCプロトコルやSLMP、オムロンならFINSといったベンダー固有の手順を使い、指定したアドレスの値を周期的に読み取ります。

利点は、設備側にソフトを入れずに済むことと、応答が速いこと。制約は2つあります。ベンダーごとに手順が違うため混在した工場では実装がメーカー数分だけ増えること、読み取り周期を短くすると制御スキャンに影響が出る機種があることです。既設設備のネットワーク側の制約は製造業のエッジコンピューティングを工程別の適用可否から整理した記事で扱っています。

OPC UAで標準化する方式：IEC 62541系の情報モデルと導入の前提

OPC UAは、設備データを機種に依存しない形で公開するための仕様です。IEC TR 62541-1:2020をはじめとするIEC 62541シリーズとして規格化されており、OPC Foundationの公式説明ではPLCやマイコンからクラウドサーバまで同一仕様で動作します。トランスポートにはOPC-binaryとJSON over Websocketsが用意されています。

単なる通信手順ではなく情報モデルを持つ点が、実務上の違いです。「このアドレスの16ビット目が運転中」という設備固有の読み替えを、サーバ側で意味のある名前に整理して公開できます。前提は、設備またはOPC UAサーバソフトが対応していること。対応していない旧設備には、次のゲートウェイ方式を当てます。

IoTゲートウェイの後付け：信号が出ない旧設備で取る3つの回避策

通信インタフェースを持たない設備は、製造業のデータ連携で最も判断が分かれます。取れる手は3つ。

制御盤の接点信号を外部端子から分岐し、ゲートウェイのデジタル入力で拾う。運転・停止とサイクル完了パルスまでは取れます
電流センサをクランプで後付けし、電流波形から稼働と停止を推定する。設備側の改造が不要で、賃借している設備でも使えます
積層信号灯の点灯をセンサで読む。取得できるのは灯色の状態だけですが、工事は最も軽く済みます

3つとも取れるのは状態と回数までで、品番やロットは取れません。そこは作業者が端末で入力する運用を残す前提で設計します。

4方式の比較：設備改造の要否・取得粒度・保守負担で決める使い分け

方式を1つに統一しようとすると、必ずどこかの設備で無理が出ます。世代ごとの使い分けが実務の答えです。

方式	設備改造	取得できる粒度	保守負担
PLC直結	不要（配線と設定のみ）	任意のデバイス値	機種増で実装が増える
OPC UA	対応機か変換機が必要	名前付きの構造データ	サーバ更新の管理が要る
ゲートウェイ後付け	接点分岐かセンサ設置	状態と回数まで	センサの経年劣化に注意
ファイル・手入力	不要	締め単位のまとめ値	入力漏れの検知が必要

見るべきは右端です。初期費用だけで選ぶと、3年目にセンサの故障や証明書の期限切れで止まります。

品目コードと工程コードの不一致が連携を止める理由と名寄せの手順

通信がつながっても数字が合わない。製造業のデータ連携で最も多い詰まり方です。原因はほぼ例外なくコード体系にあります。

品目コードが3系統に割れる場面：図番・製番・販売品目コードの分岐

設計部門は図番で呼び、製造部門は製番や指示番号で呼び、営業部門は販売品目コードで呼ぶ。同じ製品なのに3つの識別子が並走している状態は、部門ごとにシステムを入れてきた工場では標準的な姿です。

ここで起きるのが、実績を基幹へ渡した瞬間の突き合わせ不能です。MESから上がった製番に対応する販売品目が一意に決まらず、在庫が計上できない。派生品や色違いが図番では区別されるのに販売品目では同一、といった非対称も頻出します。着手前に、3系統の対応関係が1対1なのか1対多なのかを実データで数えておいてください。

工程と設備のコード付与：MESと生産管理で粒度が合わない実務

工程コードも同じ問題を抱えます。生産管理システムには「組立」という粒度の工程しか登録されていないのに、現場の設備は「組立1号機」「組立2号機」と分かれている。この場合、設備から上がる実績を工程単位へ丸める処理が要ります。

丸め方は2択です。設備コードと工程コードの対応表を持つか、生産管理側の工程マスタを設備粒度まで細分化するか。前者は既存の帳票を触らずに済み、後者は将来の分析が素直になります。稼働中の工場では前者が多く、対応表の保守担当を決めておけば運用は回るはずです。生産管理システムの機能範囲は生産管理システムの機能とERP・MESとの違いを整理した記事で確認できます。

名寄せ表の置き場所と保守担当：連携の中間層に持たせる判断基準

対応表をどこに置くか。基幹側に持たせると会計監査の対象になり、変更手続きが重くなります。MES側に持たせるとMESの改修が毎回必要になる。実務で扱いやすいのは、連携処理の中間層に読み替えテーブルとして持たせる形です。取引先コードまで含めた読み替え表の置き場は、物流のデータ連携で社内システム間と企業間EDIを二層に分けて設計する解説で扱っています。

置き場所より大事なのが担当です。新製品が立ち上がるたびに行が増える表なので、更新が止まった瞬間に連携も止まります。生産技術か情報システムのどちらが持つかを稼働前に文書で決め、月次で更新漏れを検知する仕組みまで用意しておく。ここが空欄のまま本番へ入った案件は、半年後にほぼ必ず手作業へ戻ります。

リアルタイムと日次バッチの選び分け：秒単位と日次の粒度差の埋め方

ERPが在庫や販売を日次・月次で締めるのに対し、設備は秒単位で状態が変わります。この時間軸の差を埋めずに両者を直結すると、締めのタイミングで在庫が合いません。

秒単位の設備データを日次締めのERPへ渡す前の集約単位の決め方

間に集約の層を挟みます。設備からは秒単位で受け、MESまたは連携基盤側で「作業指示単位」「ロット単位」「日単位」のいずれかへ丸めてから基幹へ渡す。どの単位で丸めるかは、基幹側で在庫を動かす単位に合わせます。

ロット単位で在庫を管理しているのに日単位で丸めると、同じ日に2ロット流れた分が区別できなくなります。逆にロット管理をしていない工場でロット単位まで細かく渡すと、扱いきれないレコードが積み上がるだけ。丸め単位は「基幹の在庫単位と同じかそれより粗く」が原則になります。

リアルタイム連携が要る3場面：出荷判定・トレース・進捗の督促

すべてをリアルタイムにする必要はありません。秒から分の遅延しか許されない場面は、実務では3つに限られます。出荷可否の判定に検査結果が要る工程、不具合発生時に対象ロットを追跡するトレーサビリティ、納期遅れを当日中に検知したい進捗管理です。

この3つに当たらない連携は、1時間おきや日次のバッチで十分に用が足ります。リアルタイム化は監視も再送処理も必要になるため、構築費と運用費の両方が増える選択になります。要否は工程ごとに判定してください。

失敗の型：締め処理とリアルタイム更新が競合して在庫が合わない

典型的な事故を1つ挙げます。基幹側が日次の締め処理を走らせている最中に、MESからリアルタイムの実績更新が飛び込み、締め後の数量に当日分が二重計上される。翌朝、経理と現場で在庫数が食い違う型です。

防ぎ方は難しくありません。締め処理の実行時間帯は連携を止め、キューに溜めてから再送する。これを設計に入れるかどうかは、要件定義で締め処理の時刻を聞いたかどうかで決まります。他業種を含めた連携の型と効果測定の手順はデータ連携の事例を6つの型と効果指標から整理した記事にまとめました。

段階導入の順序：見える化・実績自動化・計画連動の3段と投資の分岐

製造業のデータ連携は、一度に全層をつなぐ計画にすると失敗します。段を分け、各段の到達点で投資を止められる形にしておくのが安全です。

第1段：見える化だけで止める構成と、追加投資を止めてよい到達点

最初の段は、設備の稼働状態と実績カウントを吸い上げて画面に出すところまでです。基幹とはつなぎません。ここまでで得られるのは、設備ごとの停止時間の内訳と、計画に対する進み遅れの可視化。この段階で改善余地が出尽くす工場は実在します。

止めてよい判断基準は明確です。見える化の結果として動いた改善が、3か月で頭打ちになったとき。そこから先の投資は、次の段の効果を試算してから決めれば足ります。

第2段：実績入力の自動化で人が転記に触る回数を減らす順序と基準

次が、現場の手入力を減らす段です。作業日報の転記、検査結果の再入力、月末の集計。この3つのうち、件数が多いものから順に自動化します。

順序を件数で決める理由は、効果が件数に比例するからです。工数の重い作業から手を付けたくなりますが、月に数件しかない作業を自動化しても投資は回収できません。着手前に、1か月の転記件数を作業ごとに数えておいてください。この実測値がないまま進めた案件は、稼働後に効果を説明できなくなります。

第3段：生産計画と現場を双方向でつなぐ前提条件と社内体制の要件

最後が、基幹の生産計画を現場へ降ろし、実績を戻して計画を修正する双方向の連携です。ここまで来ると、計画変更が現場の作業指示に自動で反映されます。

条件は2つ。計画のマスタが実態に合っていること、そして計画変更の権限が誰にあるかが決まっていることです。標準工数が10年前のまま更新されていない工場でここへ進むと、精度の低い計画が自動で現場へ流れ込みます。IoT側と基幹側をつないだ効果の全体像はIoTとERPの連携で何が変わるかを整理した記事が参考になります。

データ連携基盤を製造業で置く条件と、個別実装のままでよい接続本数

連携基盤やデータ連携プラットフォームを製造業で導入するかどうか。判断は接続の本数と変更の頻度で決まります。接続先が3系統以下で、年に数回しか仕様が変わらないなら、個別のインタフェースを書いたほうが安く早く済みます。

基盤を置く価値が出るのは、接続先が5系統を超えるか、拠点が複数あって同じ連携を横展開する場合です。共通の変換ルールと監視を1か所に集められるため、追加拠点あたりの構築コストが下がります。分かれ目は本数であって、工場の規模ではありません。

データ連携を見送ってよい工場の条件と、先に着手すべき業務の順番

ここは言い切ります。すべての工場がいまデータ連携に着手すべきではありません。条件を満たさない工場が投資すると、動く仕組みは残っても使われないシステムになります。

見送ってよい工場の条件：品目数・拠点数・システム入替予定の3つの線

次の3つのいずれかに当たるなら、いま急ぐ必要はありません。1つ目は、拠点が1つで品目が数十点、転記作業が月に数十件以下の規模。手作業のほうが安上がりです。2つ目は、基幹システムまたは生産管理システムを2年以内に入れ替える予定がある場合。入替後にインタフェースを作り直すことになります。

3つ目は、企業間のEDIを含む場合の期限管理です。INSネットのディジタル通信モードは2024年1月から地域ごとに段階的に終了し、切替後のデータ通信を担う補完策も2028年12月31日に提供終了が予定されています。回線側の移行が済んでいない工場は、社内の連携より先にこの期限を押さえるべきです。

連携より先に直すもの：紙の作業日報と工程マスタを整備する順番と範囲

見送ると決めた工場が、その間に手を付ける順番があります。第一に工程マスタの棚卸し。実在しない工程や、10年前の標準工数が残っていないかを確認します。第二に品目コードの整理で、3系統の対応表を紙でもよいので作ること。

第三が、作業日報の記入項目を減らす作業です。転記の手間は、そもそも書いている項目が多いことから生まれます。自動化する前に、要らない項目を消すほうが早い。ここまで済ませておけば、次に連携へ進むときの要件定義は半分の期間で終わります。

外注に出す範囲の切り分け：現場調査と接続部分で引く責任分界点の初期案

実装を外部に依頼する場合、切り分けを間違えると追加費用が出ます。設備の型式調査、制御盤の図面確認、PLCのアドレス表の入手。この3つは工場側にしか手が届かない情報で、外注先が代行すると調査費として上乗せされます。

逆に、上位側の設計と実装は外へ出す価値があります。層をまたぐインタフェースの設計、コード変換の実装、締め処理との排他制御、障害時の再送。工場ごとの事情に合わせて作り込む部分なので、パッケージでは埋まりません。設備から基幹までを一本の流れで設計する体制が要るなら、生産管理システム開発のように工程管理と接続部分を一体で受ける開発会社へ、現場調査の同行から相談するのが近道になります。分界点は「盤の中は工場、盤から上はベンダー」を初期案にすると揉めません。

よくある質問

発注前の相談で繰り返し出てくる質問をまとめました。

製造業のデータ連携にかかる費用はどのくらいですか？

金額は設備の台数と取得方式で決まります。既存のPLCから直接読む構成なら、上位側の連携処理と画面を含めて数百万円台からの検討が現実的です。通信インタフェースを持たない設備にセンサやゲートウェイを後付けする場合は、1台あたりの機器費と設置工事費が積み上がり、台数がそのまま金額に効きます。見積もりの精度を上げるには、設備の型式一覧と通信可否の調査結果を先に用意してください。

OPC UAに対応していない古い設備からデータを取ることはできますか？

取れます。制御盤の接点信号を分岐して外部のゲートウェイで受ける、電流センサをクランプで後付けして波形から稼働を判定する、積層信号灯の点灯をセンサで読む、のいずれかです。ただし取得できるのは運転・停止の状態とサイクル回数までで、品番やロット番号は取れません。その部分は作業者が端末で入力する運用を残します。保守契約に触れる改造もあるため、接点分岐は事前確認が必要です。

MESを入れずに設備と基幹システムを直接つないでも問題ありませんか？

工程が単純で、作業指示と実績の突き合わせが不要な工場なら成立します。該当するのは単工程の加工や、品目が数点しかない生産形態です。複数工程を経てロットが分割・合流する生産では、突き合わせの受け皿がないため基幹側に無理が集まります。判断基準は、工程間で仕掛品を追跡する必要があるかどうか。要るなら、MESに相当する層を置いてください。

データ連携の効果はどのように測ればよいですか？

着手前に3つの数値を測っておきます。1か月あたりの転記件数、実績が基幹へ反映されるまでの時間、棚卸しで見つかる差異の件数です。稼働から1か月後に同じ3つを測り直せば、効果は差分として説明できます。金額換算は削減時間の人件費換算と、差異の調査工数の2本立てで組み立ててください。

データ連携基盤とiPaaSは製造業でも同じように使えますか？

基幹より上の層、つまりERPとSaaSの接続には同じように使えます。設備・制御層は事情が異なり、ベンダー固有プロトコルへの対応やリアルタイム性の要求から、現場側にエッジ側のソフトやOPC UAサーバを別途置く構成が一般的です。実務では「現場から中間層まではFA寄りの仕組み、中間層から上は一般的な連携基盤」という二段構えになります。