3つの方式の全体像
MESとAI（またはAIが使うデータ基盤）の間でデータをやり取りする方式は、大きく3つに分かれます。
| 観点 | ① DB直接参照 | ② API | ③ イベント配信（UNS） |
|---|---|---|---|
| 始めやすさ | 最も早い。SQLが書ければ取れる | API仕様の確認と開発が要る | ブローカーの構築と配信設計が要る |
| 過去データの一括取得 | 得意 | 件数が多いと遅い | 不得意（過去分は別途） |
| リアルタイム性 | 定期的に読みに行く（ポーリング） | 要求したときだけ | 発生時に届く |
| バージョンアップの影響 | 大きい。内部のテーブル構造に依存 | 小さい。API仕様が互換なら影響なし | 小さい。配信の形式を固定できる |
| MES本番への負荷 | 重いクエリで画面が遅くなる | MES側で制御できる | 配信時だけ |
| 結果を戻す（書込み） | 不可（DBへの直接書込みは厳禁） | 可能 | 可能（MES側が購読して処理） |
| 複数システムでの再利用 | 個別に作り込みが必要 | 可能 | 得意（1回の配信を多数が購読） |
① DB直接参照：PoCには向くが、本番に持ち込まない
DB直接参照は、MESのデータベースにSQLで問い合わせてデータを取る方式です。過去数年分のデータをまとめて取れるため、AIのPoCで学習データを作るには最も効率的です。
一方で、本番運用でこの方式を続けると、次の問題が起きやすくなります。
- MESのテーブル構造は製品の内部仕様で、バージョンアップで変わることがある。連携が予告なく壊れる
- テーブルや項目の意味が文書化されていないことが多く、作った人しかクエリを直せない
- 重い集計クエリが本番DBの性能を落とし、現場の画面が遅くなる
- 書込みはMESの業務ロジック（整合性チェック、履歴の記録）を迂回するため、絶対に行ってはいけない
PoCで使う場合も、本番DBではなく複製（レプリカ）やバックアップから復元したDBを読むことを勧めます。
② API：本番の基本形
APIは、MESが公開するインターフェース（RESTやWebサービスなど）を通じて、決められた形式でデータを受け渡す方式です。MES側がデータの形式と権限を管理するため、バージョンアップの影響を受けにくく、書込み（ホールドや作業指示の登録）もMESの業務ロジックを通して行えます。
APIで注意する点は2つです。1つ目は、AIに必要な項目がAPIで取れるとは限らないことです。標準のAPIで足りない項目は、MES側で追加開発が要ります。2つ目は、大量のデータを繰り返し取ると遅く、MESに負荷をかけることです。過去データの一括取得はDBの複製やエクスポートで行い、日々の差分をAPIで取る、という使い分けが現実的です。
③ イベント配信：複数のAIやシステムで共有するなら
イベント配信は、作業の開始・完了、検査結果の確定、設備の停止、ホールドの登録などが起きたときに、MESがメッセージをブローカー（MQTTなど）に送り、必要なシステムが購読する方式です。工場全体のデータを1つの名前空間で共有するUnified Namespace（UNS）の考え方と組み合わせると、AIの推論結果も同じ名前空間に書き戻し、MESやアンドンが購読する、という形にできます。UNSについてはUnified Namespace（UNS）とはで扱っています。
イベント配信の注意点は、メッセージの欠落と重複です。MQTTのQoS（配信品質）は3段階あり、QoS 0は「最大1回」（失われることがある）、QoS 1は「最低1回」（重複の可能性あり）、QoS 2は「正確に1回」と定義されています（OASIS MQTT 5.0）。品質記録のように欠落が許されないイベントは、QoS 1以上で配信し、受け側で重複を除く設計にします。また、UNSは履歴の保存場所ではありません。過去データは別に蓄積します。
どの方式でも決める「受け渡し規約」
方式より重要なのは、受け渡すデータの規約を固定することです。次の項目を文書にし、MES側とAI側の双方の担当が合意しておきます。
5の更新・取消は見落とされがちです。MESでは、入力ミスの訂正や実績の取消が日常的に起きます。AI側が最初の値だけを持っていると、訂正前の誤った値で学習することになります。
用途ごとの使い分けとしては、学習用の過去データはDBの複製から、日々の推論の入力はAPIかイベントで、結果の戻しはAPIかイベントで、という組合せが多くの工場で現実的です。MES選定時にこれらの機能を確認する方法はAIを見据えたMES選定、AIの結果を業務につなぐ設計はAIの推論結果をMESに書き戻すで扱っています。
よくある質問
MESにAPIがない場合はどうすればよいですか？
過去データはDBの複製から取り、日々のデータは、MESが出力するファイル（CSVなど）を定期的に取り込む方法があります。結果の戻しは、MES側に取込み機能を追加するか、作業者が画面で確認して手で登録する運用から始めます。DBへの直接書込みは避けます。
イベント配信を始めるには何が必要ですか？
MQTTブローカーなどのメッセージ基盤と、MES側でイベントを送る仕組み（標準機能、または追加開発）が必要です。最初は「作業完了」「検査結果確定」「設備停止」など、AIの用途に必要な少数のイベントから始めます。
PoCでDB直接参照を使い、そのまま本番に移すのはだめですか？
PoCの期間が短く、対象が1ラインで、MESのバージョンアップ予定がないなら、一時的に使うことはあり得ます。ただし、本番化の計画には、API化またはイベント化の工数を必ず入れておきます。DB直接参照のまま横展開すると、工場ごとの差とバージョンの差で保守が回らなくなります。
この記事に出てくる用語
AIは「データ基盤」で決まる
PoCは成功したのに本番で止まる。原因の多くはモデルではなく、MESと設備データの側にある 全130本
- MESとAIの関係：ロット・作業指示・品質判定がAIの精度を決める理由
- 製造業AIが本番で止まる7つの理由：PoCは成功したのにラインに載らない構造
- 製造業のAI-OCR：紙の検査記録・点検表・ミルシートをデータ化する手順
- データ基盤の段階的導入ロードマップ：ユースケースから逆算する8ステップ
この記事を書いた人
DELMIA Apriso を中核とした MES / 製造DX の導入・運用・人材育成と、製造業向けAIの調査・開発・教育を手がけるITコンサルティング企業。ISO 9001:2015 / ISO 27001:2022 認証取得。 日本・中国・米国で製造業のMES・データ基盤・AI導入を手がけた実務者が、欧米・中国の一次情報にあたって書いています。
