工場のデータ連携をどう設計するか｜OPC-UA・MES・ERPをAI活用前のBPR基盤として整理する

製造業でAI活用を進めようとすると、多くの現場が「必要なデータが使える形で揃っていない」という壁に突き当たります。設備データはOTに、製造実績はMESに、受注や在庫はERPにあり、別々のフォーマットと意味づけで管理されているためです。本記事は、製造業のDX推進・生産技術・データ担当に向けて、工場のデータ連携をAI活用の前提となるBPR基盤としてどう設計するかを、3層の整理・接続パターン・ユースケースからの逆算・標準化まで、設計論として整理します。

なぜAI活用の前に「データ連携の設計」でつまずくのか

製造業でAI活用の話を始めると、予知保全・需要予測・品質検査・生産最適化など、やりたいことは次々に挙がります。ところが実際に着手すると、多くの現場が同じ壁に突き当たります。「必要なデータが、使える形で揃っていない」という壁です。設備のデータは制御盤の中に閉じ、製造実績はMESに、受注や在庫はERPにあり、それぞれが別々のフォーマットと意味づけで管理されています。

この状態でAIツールだけを導入しても、成果は出ません。データを集める前処理に膨大な工数がかかり、PoCは動いても本番のデータ供給が続かず、いつの間にか止まってしまう。問題はAIの性能ではなく、その手前にあるデータ連携が設計されていないことにあります。

本記事では、工場のデータ連携を、AI活用の前提となるBPR基盤としてどう設計するかを整理します。OT（現場設備）・MES（製造実行）・ERP（基幹）の3層をどう捉え、OPC-UAなどの標準をどう位置づけ、AI活用のユースケースから逆算して何を標準化するか。ツールの選定ではなく、その前段にある「設計」の話です。

工場データの3層を整理する ― OT・MES・ERP

工場のデータは、大きく3つの層に分かれています。それぞれ扱うデータの性質も、更新の頻度も、管理する部門も異なります。連携設計の出発点は、この3層を分けて捉えることです。

重要なのは、これらが縦に連携して初めて意味を持つという点です。設備の稼働データ（OT）だけを見ても、それがどの製品のどの工程で起きたか（MES）、その製品がどの受注に紐づくか（ERP）が分からなければ、事業の意思決定にはつながりません。AI活用の多くは、この3層をまたいだデータの結合を前提とします。

なお、OT層の接続（PLC/SCADAとの物理的なつなぎ込みや、安全性・可用性・セキュリティの確保）は、それ自体が専門領域です。本記事はその技術的な接続を前提としたうえで、AI活用・BPRを見据えて「何を、どの層で、どう整理・標準化するか」の設計に焦点を当てます。

接続パターンの設計 ― 点のつなぎ込みから、共通の土台へ

3層を連携させる方法は、大きく2つの発想に分かれます。この選択が、後のAI活用のしやすさを大きく左右します。

個別接続（ポイント・トゥ・ポイント）の限界

最も手早いのは、必要になった機器とシステムを、その都度1対1でつなぐやり方です。しかしこの方式は、接続の数が増えるほど組み合わせが増え、どこかを変えると別のどこかが壊れる、保守できない配線図になっていきます。AI活用のように「新しいデータの使い方」を次々に足していく用途とは、根本的に相性が悪い方式です。

共通の土台に一度集める

もう一つの発想は、各層のデータをいったん共通の土台に集約し、そこから必要なシステムやAIが読み取る形にすることです。OPC-UAのような標準化された通信の枠組みや、データを意味づけて一元的に流通させる考え方（Unified Namespaceと呼ばれる設計思想など）が、この土台を支えます。データの出し手と受け手を疎結合にしておくことで、AIのユースケースを追加しても既存の連携を壊さずに済みます。

どちらが正解かは規模と目的によりますが、AI活用を継続的に広げていく前提に立つなら、共通の土台に集約する発想が有利です。目先の1ユースケースだけを見て個別接続を積み重ねると、後で作り直しが発生します。

BPR起点でデータを整理する ― ユースケースから逆算する

データ連携の設計で最もありがちな失敗は、「とりあえず全部のデータを集める」ことから始めてしまうことです。集めること自体が目的化し、使われないデータレイクだけが残ります。設計は、集める側からではなく、使う側（AI活用・業務改善のユースケース）から逆算します。

まず「どの業務課題を、どう変えたいか」を定義し、そのために必要なデータを3層から特定する。この順序が、BPR起点の考え方です。業務プロセスをどう再設計するかが先にあり、データ連携はそれを支える基盤として設計されます。

このように、ユースケースごとに必要なデータは3層をまたいで異なります。逆算して必要なものから連携を整えることで、投資対効果の見える形でデータ基盤を育てられます。すべてを一度に完璧に繋ごうとせず、価値の高いユースケースから段階的に広げるのが現実的です。

標準化とガバナンス ― データの意味を揃える

3層のデータを結合するとき、最大の障害になるのが「意味の不一致」です。同じ『製品コード』でも部門ごとに体系が違い、同じ『稼働中』でも設備ごとに定義が違う。この状態のまま繋いでも、集計や分析は成り立ちません。連携設計と並行して、データの意味を揃える標準化が必要です。

標準化は一度やって終わりではなく、誰が定義を管理し、変更をどう反映するかというガバナンスの仕組みまで含めて設計します。AI活用が広がるほど、データの意味が揃っていることの価値は高まります。ここを後回しにすると、AIの精度以前に「そもそも学習に使えるデータがない」という事態になります。

よくある失敗パターンと回避策

工場のデータ連携でつまずく典型パターンを整理します。多くは技術選定ではなく、設計の順序と目的設定に起因します。

まとめ：データ連携は、AI活用の前提となるBPR基盤

工場のデータ連携を設計する際の要点を整理します。

• 工場データはOT（設備）・MES（製造実行）・ERP（基幹）の3層。縦に連携して初めて事業の意思決定につながる
• 個別接続は拡張で破綻する。共通の土台に集約し、疎結合で設計するとAI活用を継続的に広げられる
• 集める側でなく、AI活用のユースケースから逆算する。BPR起点で必要なデータから段階的に整える
• マスタ・用語・単位・品質の標準化を連携と並行して行う。意味が揃わなければ結合も分析も成り立たない
• データ連携はAI導入の前工程ではなく、AI活用の成否を決める前提基盤として設計する

製造業のAI活用でつまずく原因の多くは、モデルやツールではなく、その手前にあるデータ連携の設計にあります。何をどの層で扱い、どう共通の土台に集め、どのユースケースから逆算して整え、どう意味を揃えるか。この設計をAI活用の前提となるBPR基盤として捉え、業務の再設計と一体で進められるかどうかが、AIを成果に変えられるかの分岐点になります。整えたデータ基盤は、やがてAIが自律的に判断・実行する製造業務の基盤へとつながっていきます。