MESのリアーキテクチャとは？｜考え方/特徴/仕組み/目的を解説

MESを長年運用していると、新しい設備を1台追加するだけで、関係しそうな画面や処理を広く洗い出さなければ安心してリリースできない、という状態に心当たりがある方も多いのではないでしょうか。MESのリアーキテクチャとは、工程実行・実績収集・品質トレーサビリティという現場執行の業務境界に沿ってモノリス構造を分解し、PLCや生産設備から届くデータの流れまで含めて内部構造を組み替える技術的な再設計を指します。

本記事では、MESのリアーキテクチャの基本的な考え方、工程実行・実績収集・品質トレーサビリティのドメイン境界設計(DDD)の仕組み、OPC UA連携とエッジコンピューティングというMES固有の技術要素、導入によって得られる特徴と目的、そして刷新・更改・リニューアル・モダナイゼーションといった関連する取り組みとの違いを順に解説します。情報システム部門やアーキテクト、エンジニアの方が、自社のMESにこの考え方を当てはめられるかどうかを判断できるよう、実務の流れに沿って整理します。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・MESのリアーキテクチャの完全ガイド

MESのリアーキテクチャとは何か？実行制御レイヤーとしての位置づけ

「MESを作り替える」といっても、何を起点にするかで取り組みの中身は大きく異なります。MESのリアーキテクチャは、その中でもアーキテクチャそのものの構造を起点にした技術専門の取り組みであり、対象システム種別を問わないシステムリアーキテクチャという総論の考え方を、MES固有のドメインに特化させて深掘りしたものです。

モノリスからマイクロサービスへの分解、ドメイン駆動設計、API-first設計、クラウドネイティブパターンという構造設計の考え方自体は、対象システムの種類を問わないシステムリアーキテクチャの総論と共通です。MESのリアーキテクチャがこれと異なるのは、分解の対象となる業務境界が「工程実行」「実績収集」「品質トレーサビリティ」というMES固有の概念で構成される点と、OPC UAという産業用プロトコルを介したPLC・生産設備からのリアルタイムデータ収集基盤という、他の業務システムのリアーキテクチャにはない技術要素が加わる点です。

生産管理システムが計画・管理を担う司令塔レイヤーであるのに対し、MESはPLCや生産設備と直結し、工程の進捗・実績・品質をリアルタイムに収集する現場の実行制御レイヤーです。両者のリアーキテクチャはドメイン駆動設計やクラウドネイティブパターンという設計思想は共通しますが、MESのリアーキテクチャは工程実行・実績収集・品質トレーサビリティという実行レイヤー固有の境界設計と、OPC UAという産業用プロトコルを明示したエッジコンピューティング基盤の構築に踏み込む点が異なります。

MESは、生産計画を受け取って現場に指示を出し、進捗・実績・品質を刻々と記録し続けるレイヤーです。長年の改修でこの役割がすべて一枚岩のモノリスに詰め込まれていると、設備を1台増設するだけでも影響範囲の調査が広がり、開発スピードが目に見えて落ちていきます。

工程実行は、生産計画に沿って設備へ作業指示を出し、段取りや切替を制御する領域です。実績収集は、稼働時間や生産数量、設備の稼働状態をPLCから吸い上げる領域、品質トレーサビリティは、検査結果やロット・シリアル単位の履歴を、原材料の受け入れから出荷まで追跡できる状態に保つ領域です。この3つはいずれもPLC・生産設備という現場のハードウェアと直接向き合うという点で、計画・管理を扱う生産管理システムの業務境界とは性質が異なります。

工程実行・実績収集・品質トレーサビリティの処理が一枚岩のコードベースに混在していると、品質トレーサビリティの仕様変更が実績収集側のコードにまで影響し、両方をまとめてテスト・リリースする必要が生じます。新しい設備やラインを追加するたびにこの調査範囲が広がり、リリースサイクルが長期化していくことが、リアーキテクチャに着手する最も直接的な動機になります。

工程実行・実績収集・品質トレーサビリティのドメイン境界設計(DDD)の仕組み

マイクロサービス化の成否を分けるのは、技術選定そのものよりも「どこで業務を区切るか」という境界設計です。MESでは、この境界を現場の業務イベントから導き出すドメイン駆動設計(DDD)が、リアーキテクチャの初期工程で中心的な役割を果たします。

ドメイン専門家である工場長や生産技術担当者、品質管理担当者に、プロジェクトマネージャーとエンジニアが加わり、「生産開始」「検査完了」「異常検知」といった業務イベントを時系列でマッピングするイベントストーミングを行います。この作業を通じて、部署ごとに呼び方が異なっていた概念を一つのユビキタス言語に統一し、最初から細分化せず工程実行・実績収集・品質トレーサビリティなど3〜5のコアドメインに絞り込むことが、境界づけられたコンテキストの自然な継ぎ目を見つける近道になります。

工程実行・実績収集・品質トレーサビリティの境界が曖昧なまま分割を進めると、見た目はサービスごとに分かれていても実際には密結合のままという「分散モノリス」に陥ります。この状態では修正のたびに他サービスとの同時デプロイが必要になり、開発スピードが劇的に低下して大幅な納期遅延を招くため、境界設計の段階から数週間から1.5ヶ月程度をかけて丁寧に検証することが実装複雑度の高いこの工程を乗り切るうえで欠かせません。

OPC UA連携とエッジコンピューティング基盤の仕組み

MESのリアーキテクチャが他の業務システムのリアーキテクチャと大きく異なるのは、PLCや多様な生産設備から届くデータをリアルタイムに収集・処理する基盤の構築がプロジェクトの技術的最難関になる点です。この検証には、本開発に入る前のパイロットフェーズを計画に組み込むことが強く推奨されています。

工場には年代もメーカーも異なるPLCや設備が混在していることが少なくありません。OPC UAは、こうした多様な機器から出てくる信号を標準的な形式に変換し、上位のシステムが共通の方法でデータを読み書きできるようにする産業用の通信規格です。MESのリアーキテクチャでは、この標準プロトコルによるデータ収集の仕組みを構築し、Kafkaなどのデータストリーミング基盤へ確実にメッセージを送り届けられるかを検証することが、初期工程における重要な技術検証の一つになります。

センサーやPLCからミリ秒単位で発生する膨大なデータをすべてクラウドへ送信すると、レイテンシと帯域幅コストが膨らみます。そのため現場サーバー側でフィルタリング・一次解析を行うエッジコンピューティングを組み合わせ、必要な情報だけをクラウドへ送るハイブリッドな構成が不可欠です。あわせて、工場ネットワークが一時的に切断された場合でもエッジ側のローカル処理で生産ラインを止めずに稼働を継続できるかを、意図的な通信障害を注入するカオスエンジニアリングの手法で検証しておく必要があります。

リアーキテクチャがもたらす主な特徴・技術要素

境界設計とデータ連携基盤が定まったリアーキテクチャは、単に構造を変えるだけでなく、開発・運用のあり方そのものに複数の特徴をもたらします。

工程実行・実績収集・品質トレーサビリティをそれぞれ独立したサービスとして分割すれば、担当チームは自分たちのサービスの範囲内で変更を完結させやすくなり、他チームの作業を待つ時間や全体テストにかかる時間を減らせます。実績収集のように特定の工程だけ負荷が集中しやすい領域だけを個別にスケールできることも、MESならではの柔軟な運用につながります。

マイクロサービス化により、機能ごとに最適な技術を選択するPolyglotな構成が可能になります。たとえば品質判定にAI・機械学習モデルを使うモジュールはPythonで、生産設備からの高並行・高スループットなメッセージング処理はJavaやGoで実装するといった適材適所の構成が考えられます。ただし技術の分散しすぎはエンジニアの採用・学習コストの増加につながるため、標準化のガードレールをあわせて整備することが実務上重要です。

導入目的と得られる効果・トレードオフ

MESのリアーキテクチャの目的は、見た目や機能を変えることではなく、工程追加・設備更新に強い構造を手に入れることにあります。ただし、その効果は無条件に得られるものではなく、相応の代償を伴う判断であることも理解しておく必要があります。

密結合のモノリスでは、新しい工程や設備を追加するたびに関係しそうな箇所を広く調査し、影響範囲を確認してからでないと安心してリリースできません。境界が整理されたマイクロサービスであれば、工程実行チームは実績収集や品質トレーサビリティの実装を意識せずに自分たちの範囲内で変更を完結させやすくなります。高負荷工程だけを独立してスケールできるようになれば、システム全体のTCOは中長期で20〜45%削減できるという効果も期待されています。

サービスの数が増えれば、分散システム特有のインフラ・運用コストである「マイクロサービス税」が発生します。監視・オブザーバビリティのスタック導入は必須になり、モノリス時代と比べて監視の複雑さは40〜50%ほど増加するとされています。OPC UA連携やエッジコンピューティング基盤についても、全国の工場に分散するエッジデバイスの死活監視や継続的なアップデート展開という、クラウド側だけでは完結しない物理拠点寄りの運用コストが新たに発生します。専任のプラットフォームチームを維持できる体制がなければ、運用コストが導入メリットを上回る「運用破綻」に陥るリスクがある点は、着手前に理解しておく必要があります。

刷新・更改・リニューアル・モダナイゼーションとの違い

MESを作り替える取り組みには複数の呼び方があり、混同されがちです。起点となる問題意識と、検討の中心にいる関係者を整理すると、それぞれの違いが明確になります。

MESの刷新は経営層・部門長による予算確保や稟議が起点で、更改は保守契約の満了やEOS・EOLという外圧が起点、リニューアルは現場オペレーターの操作体験(UX・UI)が起点です。これらはいずれも画面や契約、経営判断といった目に見えやすい要素を起点にしますが、MESのリアーキテクチャは画面の見た目には言及せず、画面の裏側にある構造の疎結合化・API化に特化した技術専門の取り組みである点が異なります。

MESのモダナイゼーションは、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5手法を並列に扱う総論であり、対象はMES全般です。MESのリアーキテクチャは、このうちリファクタリングとリビルドをさらに掘り下げ、工程実行・実績収集・品質トレーサビリティのドメイン境界設計とOPC UA連携基盤という構造設計一つに絞った取り組みです。実務では刷新プロジェクトの一環としてリアーキテクチャが技術タスクに組み込まれることもあるため、プロジェクトの目的をどちらに置くかを最初に明確にしておくと議論が噛み合わなくなる事態を避けやすくなります。

MESのリアーキテクチャ導入前に確認しておきたいポイント

マイクロサービス化を伴うリアーキテクチャは、すべてのMESに一律に向いているわけではありません。着手する前に、組織規模や体制、検証フェーズの要否を確認しておくと、過剰投資や中途半端な分散を避けやすくなります。

マイクロサービス化が確実にメリットをもたらすのは、1日のリクエスト数が100万回を超え、かつ開発エンジニアが50名以上いる大規模環境とされています。開発チームが15〜20名に満たない小規模組織で分散インフラを導入すると、監視・サービスメッシュ・APIゲートウェイなどの運用・維持コストが導入メリットを上回り、機能開発よりインフラの維持管理に時間を奪われるリスクが高まります。この条件を満たさない場合は、単一のコードベース内でドメイン境界だけを厳密に分ける「モジュラーモノリス」から始め、OPC UA連携やエッジ処理など本当に独立スケーリングが必要な機能だけを段階的に切り出す進め方が安全です。

OPC UA連携・エッジコンピューティング基盤の構築は技術的難易度が最も高いため、本開発にいきなり入らず、実現可能性を検証するパイロットフェーズを3〜6ヶ月ほど事前に計画することが強く推奨されます。プロジェクト全体の期間・予算のうち40〜60%をこのデータ準備とエッジ・インフラ基盤の整備に先行投資しておくと、後続の各マイクロサービス開発フェーズの工数を大幅に圧縮でき、結果的にトータルの納期を守りやすくなります。より詳しい選定の進め方は、MESのリアーキテクチャの選定ポイント・選び方・種類で整理していますので、着手前の判断材料としてあわせてご確認ください。

まとめ

MESのリアーキテクチャは、工程実行・実績収集・品質トレーサビリティというMES固有の実行レイヤーの業務境界に沿ってモノリス構造を分解し、OPC UAを介したPLC・生産設備からのリアルタイムデータ収集基盤まで含めて内部構造を組み替える技術専門の取り組みです。ドメイン駆動設計による境界設計、OPC UA連携とエッジコンピューティングによる現場データの取り扱い、そしてPolyglotな技術選定という一連の要素が組み合わさって初めて成立します。

マイクロサービス化は開発速度と柔軟性を高める一方で、監視・運用・人材確保という新たなコストセンターを生み出します。目的は「分散させること」ではなく「工程追加・設備更新に強い構造を手に入れること」であるという原点に立ち返り、パイロットフェーズでの技術検証とモジュラーモノリスという中間形態も含めて、自社の規模と体制に見合った着地点を見極めることが重要です。

まずは、現在のMESのどこに変更しにくい密結合が存在し、工程実行・実績収集・品質トレーサビリティのどれを最初の境界として切り出せそうかを可視化することから始めてください。境界設計、OPC UA連携基盤の技術選定、段階移行の計画は、既存システムや生産ラインの事情を踏まえたオーダーメイドの判断が求められる領域です。riplaはフルスクラッチ開発の立場から、既存MESの構造分析、境界設計、OPC UA連携・エッジコンピューティング基盤の構築から段階的な移行計画の策定・実装までを一貫して支援しています。

▼全体ガイドの記事
・MESのリアーキテクチャの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。