IoTプラットフォームを入れても、MESの検討は消えない
設備にセンサーを付け、稼働データをクラウドに集め、ダッシュボードで可視化する──ここまでを実現した工場が「次に何をすべきか」で止まるケースを、私たちは繰り返し見てきました。止まる理由は明快で、IoTプラットフォームが答えるのは「何が起きたか」であって、「この作業を進めてよいか」ではないからです。
具体的に言うと、IoTプラットフォームは温度が規格を外れたことをグラフで示し、通知を飛ばすことはできます。しかし「規格を外れた時間帯に作られたロットを特定し、そのロットの次工程投入を止め、品質管理者の判断があるまで解除させない」ことはできません。後者は業務トランザクション（指図・実績・ロット）と業務ルールを持つシステム、つまりMESの仕事です。
この線引きはシステムの優劣ではなく責任の分担です。逆方向も同じで、MESに1秒周期のセンサー時系列を貯めさせるのは設計として誤りです。時系列データの置き場所についてはヒストリアンとMESの役割分担で扱ったとおり、そちらの仕事です。
責任の違いを7つの観点で押さえる
| 観点 | IoTプラットフォーム | MES |
|---|---|---|
| 主目的 | データの収集・蓄積・可視化・分析 | 製造業務の実行統制と記録 |
| 扱うデータ | 時系列データ（センサー値・稼働状態） | 業務トランザクション（指図・実績・ロット・検査） |
| データの受け入れ方 | 来たものを来たまま貯める | 業務ルールで検証してから受け付ける |
| 「止める」機能 | 原則ない（通知・アラートまで） | 条件を満たさない作業を成立させない |
| 中心となるマスタ | 機器・タグ・階層モデル | 品目・工程・BOM・作業者・設備 |
| 監査証跡 | 通常はスコープ外 | 規制産業では中核要件 |
| 障害時の影響 | グラフが欠ける・分析が遅れる | 生産が止まる、または記録の完全性が壊れる |
最も本質的な違いは3行目です。IoTプラットフォームは「事実の写像」を作る装置なので、異常値もそのまま貯めます。MESは「業務の成立条件」を守る装置なので、資格のない作業者のログイン、期限切れ材料の投入、未校正設備での作業を入口で拒否します。この検証ロジックと、拒否・解除の権限設計こそがMES導入の工数の大半であり、IoTプラットフォームをどれだけ拡張しても自然には手に入りません。
どちらから入るか──判断は「止める要件」の有無で分かれる
導入順序の相談に対して、私たちは次の順で確認しています。
- 不良流出・誤投入・記録不備など「起こしてはいけないこと」が投資の動機か？ → Yesなら統制が目的であり、MESから入るべきです。IoTプラットフォームを先行させても動機は解消されません。
- 動機が設備稼働率の改善・エネルギー削減・予知保全か？ → まず対象設備を絞ったデータ収集と可視化で十分な場合が多く、IoTプラットフォーム（あるいはヒストリアン＋BI）から入るのが安価です。設備接続の技術的な選択肢は設備接続の現実を参照してください。
- 両方が動機の場合 → 領域を分けて並行させます。このとき「同じデータを二重に集めない」ことが唯一の設計原則です。
併用時のアーキテクチャ──上下関係ではなく分業にする
両方を持つ場合、「IoTプラットフォームの上にMESを載せる」「MESの下にIoTを敷く」という上下のメタファーで設計すると混乱します。実務で機能する分業は次の形です。
- 設備からの時系列データはIoTプラットフォーム（またはヒストリアン）へ直接流す。MESを経由させない
- 業務イベント（工程開始・完了、投入、検査判定）はMESが正とする。IoTプラットフォームが分析に使う場合はMESから配信を受ける
- 両者の突合キー（設備ID・ロット番号・時刻基準）を最初に統一する。ここを揃えないと「この温度逸脱はどのロットに影響したか」という、併用の価値そのものである問いに答えられなくなります
なお、この分業をブローカー経由の発行購読モデルで整理する考え方がUnified Namespaceです。UNSがMESを置き換えるという言説の検証はUnified NamespaceはMESを置き換えるのかに譲りますが、結論だけ言えば、UNSが置き換えるのはデータの流通経路であって、業務を統制する責任ではありません。また、ERP・SCADAとの階層上の位置づけはMESとERP・SCADA・PLC・PLMの違いで整理しています。
よくある質問
IoTプラットフォームのワークフロー機能でMESの代わりになりませんか？
簡易な承認フローや通知程度なら組めますが、MESの統制は「ワークフロー」ではなく「業務データモデル＋ルール」で成立しています。ロット・BOM・工程・作業者資格のマスタと、それらを横断する検証ロジックをIoTプラットフォーム上に自作すると、結局MESをスクラッチ開発しているのと同じことになり、保守できなくなるのが典型的な失敗です。要件が可視化中心で、統制要件が「警告を出す」程度に収まるなら代替は成立します。「止める」「証跡を残す」が入った時点でMESの領域です。
すでにIoTプラットフォームがあります。MES導入時に無駄になりますか？
設備接続・ネットワーク・タグ設計・時刻同期の整備は、そのままMESの前提インフラとして活きます。無駄になりやすいのは、IoTプラットフォーム上に作り込んだ「業務っぽい画面」（実績入力フォームや簡易指示画面）です。これらはMESの標準機能と重複し、二重入力の温床になるため、MES稼働時に廃止する計画をあらかじめ立てておくことを推奨します。
ベンダーの提案書に「IoT機能を含むMES」とあります。何を確認すべきですか？
確認点は2つです。第一に、時系列データの保存先と保持期間──MESのトランザクションDBに時系列を貯める設計なら、数年でDBが肥大化し性能問題になります（MESが持つべきデータ参照）。第二に、「止める」機能の実装方法──収集したデータを条件に工程を止められるのか、通知までなのかで、提案の実体がMESなのかIoTプラットフォームなのかが判別できます。
