MESのリアーキテクチャ製品は、MES/SCADA基盤やエッジ処理、データ連携などの役割に分けて選びます。役割ごとに見ると、自社の課題に合う構成を組み立てられます。
製品の比べ方、主要6製品の役割、課題別の選び方の順に説明します。
▼全体ガイドの記事
・MESのリアーキテクチャの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
パッケージ型とクラウド型MESリアーキテクチャ基盤の違い
リアーキテクチャでは、買い切りのパッケージソフトを自社サーバーに入れてMESの構造を作り替える発想は、一般的ではありません。一方で、機能や料金を確認しやすいのは、クラウドベンダーや専業ベンダーが提供するクラウド型の技術基盤です。そのため、この記事ではクラウド型の技術基盤を取り上げます。
パッケージ型は自社構築と継続保守の負担
自社データセンター内にコンテナ基盤やOPC UA連携基盤を個別に構築し、すべて自社で保守する形も、理論上は可能です。
自社保守では、Kubernetesやエッジデバイスのファームウェア更新、セキュリティパッチの適用を、自前で続ける体制が前提になります。
学習や運用のコストが高いため、多くの企業はマネージドサービスとしてクラウド型を選んでいます。
クラウド型が中心になっている理由
クラウド型のMES/SCADA基盤やコンテナ実行基盤では、クラスター管理やパッチ適用をベンダー側に任せられます。
工程実行・実績収集・品質トレーサビリティを段階的に分解すると、対象範囲が広がるほど運用するサービスも増えます。基盤の運用をマネージドサービスに委ねられるかが、プロジェクト全体の負荷を左右します。
製品を比較するときの共通の観点
製品を比べるときは、製品紹介ページの機能一覧だけでは判断できません。自社の境界設計や現場設備との適合性も、あわせて確かめる必要があります。そこで、3つの観点で製品を並べて見ていきます。
- 分割方針との適合性：必要なサービスの境界を支えられるか
- OPC UA・エッジ対応：PLCや生産設備と接続できるか
- 運用性と既存連携：現在の基盤へ監視や認証を統合できるか
自社の分割方針とOPC UA・エッジ対応力
必要な製品の組み合わせは、DDDやイベントストーミングで見極めた境界づけられたコンテキストの数と、境界をまたぐ分散トランザクションの有無によって変わります。
PLCや生産設備との接続実績も見ておきます。実行基盤だけでなく、OPC UA対応のMES基盤やエッジ処理基盤まで含めて、分割方針全体を支えられるかが問われます。
運用性・既存基盤との連携
AWS・Azure・Google Cloudのいずれかを主に利用している場合は、その基盤にネイティブ統合された製品を優先します。認証やネットワーク設定の重複を避けられるためです。
監視やログ収集を既存の運用基盤へどこまで統合できるかは、稼働後の負荷に直結します。詳しい評価手順は、MESのリアーキテクチャの選定ポイント・選び方・種類で整理しています。
MESのリアーキテクチャを支える主要クラウド製品6選
2026年7月時点で現行の公式ページと対応内容を確認できた6製品を、役割ごとに紹介します。掲載順は、優劣を示すものではありません。
対象となる役割は6つあり、MES/SCADA基盤、エッジコンピューティング、ストリーム処理、コンテナ実行基盤、サービスメッシュ、ワークフローオーケストレーションです。次の6製品がそれぞれの役割を担います。
Ignition by Inductive Automation
Ignitionは、SCADA・IIoT・MESを1つのプラットフォームで扱えるモジュール型の産業用ソフトウェアです。
- 標準技術：公式サイトはSQL・Python・OPC UA・MQTTなどの利用を明記しています。
- 柔軟な構成：用途に応じてモジュールを追加・入れ替えられます。
- 導入候補：工程実行や品質トレーサビリティをモジュール単位で分解したい企業が候補になります。
料金は具体的に記載されていないため、Pricingページでエディションごとの見積もりを確認する必要があります。
AWS IoT Greengrass
AWS IoT Greengrassは、クラウドの処理・ロジックをエッジデバイスへ持ち込めるAWSサービスです。
- 現場データ処理：収集・集約・フィルタリングを行い、必要な情報だけをクラウドへ送れます。
- 接続不安定時の稼働：公式サイトは接続が不安定な環境でも稼働を続けられると説明しています。
- 遠隔管理：公式サイトは、デバイスソフトウェアや設定を大規模に離れた場所から扱えると明記しています。
- 導入候補：PLC・センサーが分散する工場で、帯域幅コストとレイテンシを抑えたい企業が候補になります。
料金の具体的な記載はありませんが、無料利用枠と無料トライアルが案内されています。利用規模に応じた見積もりが必要です。
Confluent Cloud
Confluent Cloudは、Apache Kafkaをフルマネージドで利用できるデータストリーミングプラットフォームです。
- 公式情報：公式サイトはフルマネージド基盤とサーバーレスKafkaエンジンを明記しています。
- 利用場面：実績収集や品質トレーサビリティをまたぐイベント駆動の連携に使えます。
- 導入候補：自社でKafkaクラスターを運用する体制がない企業が候補です。
課金は消費量ベースで、年間コミットメント割引もあります。なお、具体的な金額は記載がないため、コスト見積もりツールで確認します。
Amazon EKS(Elastic Kubernetes Service)
Amazon EKSはAWSのマネージドKubernetesサービスで、クラスター管理をAWSに任せられます。
- アプリケーション実行：公式サイトは本番環境向けアプリを任意の環境で構築・実行・スケールできるとしています。
- クラスター管理：公式サイトは管理の自動化にも対応すると明記しています。
- MESの実行基盤：工程実行・実績収集・品質トレーサビリティをコンテナ化したサービス単位で動かせます。
- 導入候補：既にAWS上で基幹システムを稼働させている企業に適しています。
料金の具体的な記載はありません。利用量に応じた課金のため、見積もりの際に確認が必要です。
Cilium
Ciliumは、eBPFを基盤にしたオープンソースのクラウドネイティブ・ネットワーキング製品です。
- 通信の保護：公式サイトはDocker・Kubernetesなどのコンテナ管理基盤上にあるサービス間の通信を、透過的に守ると説明しています。
- 負荷分散：効率的なハッシュテーブルにより、高いサービス密度と低レイテンシを実現すると説明されています。
- 導入候補：サービス数が増え、通信経路の可視化や認可制御が複雑になった段階で候補になります。サイドカー方式のサービスメッシュより軽量な選択肢です。
- 料金・サポート：製品利用料はありませんが、商用サポートは提供元への確認が必要です。
Temporal
Temporalは、マイクロサービス間のワークフローをコードで記述・実行できるオーケストレーション製品です。
- Sagaの補償処理：公式サイトは「Compensating Patterns (Saga)」を紹介しています。
- 失敗時の対応：途中で失敗した場合の補償処理を、複雑な自前実装なしに組み込めます。
- 導入候補：実績収集から品質トレーサビリティをまたぐ分散処理の整合性が課題の企業が候補です。
提供形態は、セルフホスト（オープンソース）とTemporal Cloudの2つです。
Temporal Cloudを使う場合は、1,000米ドル分の無料クレジットが案内されていますが、料金プランはPricingページで確認が必要です。
自社の課題別に候補を絞る方法
6製品を細部まで一度に比べるより、自社が今つまずいている層を一つ決めるほうが効率的です。
モノリスMESをモジュール単位で分解したい場合
工程実行や品質トレーサビリティの機能を、既存のOPC UAベースの現場環境を活かしながらモジュール単位で分解する場合は、Ignitionが候補になります。
- 資産との親和性：既存のPLC・SCADA資産と接続できるかを確かめます。
- ライセンスと移行：モジュール単位のライセンス体系と既存システムからの移行手順を、デモで確かめます。
現場データ収集と整合性確保のボトルネックを解消したい場合
課題に応じて、現場のデータ収集やサービス間連携を担う製品を組み合わせます。PLC・センサーから情報を集める部分でレイテンシや帯域幅コストの課題があれば、データ収集の製品を優先して検討します。
- データ収集・連携：GreengrassとConfluent Cloudの組み合わせが候補です。
- 通信経路・認可制御：サービス数が増え、経路の可視化や権限の制御が課題なら、Ciliumが選択肢に入ります。
- 分散処理の整合性：実績収集から品質トレーサビリティをまたぐ処理が課題なら、Saga対応のTemporalが選択肢になります。
- 実行基盤の刷新：実行環境そのものを作り替える必要がある場合は、Amazon EKSが中心になります。
料金・契約前に確認すべきこと
紹介した6製品のうち、Ciliumを除く5製品は、公式ページに具体的な金額がありません。
従量課金や個別見積もりが前提になるため、利用規模を伝えたうえで、総保有コストを確認します。
課金の単位
MES/SCADA基盤やストリーム処理基盤の多くは、複数の指標で課金される場合があります。指標には、モジュール数やクラスター数のほか、データ転送量やメッセージ処理量などがあります。
見積もりを取るときは、現在の工程数やPLC・生産設備の台数に加えて、1年後・3年後に想定する規模も伝えます。
サポート体制と契約形態
オープンソース起源の製品には、無償のコミュニティ版とサポート付きの商用版が並んで提供されているものもあります。
現場設備を止められない生産ラインでは、障害時に自社だけで解決できない場面もあると想定しておきます。そこで、対応時間や問い合わせ窓口、契約範囲を事前に確かめておくと、本番稼働後の不安を減らせます。
デモとPoCで最終候補へ絞る進め方
資料比較で2〜3製品まで絞ったら、分割を予定している1工程を使って動作を検証します。その際は、アーキテクトに加えて、実装担当のエンジニアや現場の設備担当者にも参加してもらうと、運用イメージのずれを減らせます。
1工程のフルパス検証
既存のモノリスの前面に振り分けの仕組みを置き、影響の小さい1工程を新しいサービスとして切り出します。
OPC UA経由のデータ収集から実行基盤へのデプロイまでを動かします。必要に応じて、ワークフローオーケストレーションによる補償処理も検証します。
通信レイテンシ、障害時の切り分け時間、監視画面での可視性を記録しておくと、本格展開の判断材料になります。
移行効果の実測と稟議
PoC前に、対象工程の変更にかかる確認工数やリリースの所要時間を記録しておき、PoC後の数値と比べます。
効果の数字は、一般的な目安ではなく、自社の開発チームの実績値で算出します。そうすると、経営層への説明に根拠を持たせられます。
MESのリアーキテクチャ製品比較で押さえておきたいポイント
買い切り型の有無やおすすめ順位よりも、自社の設計と運用体制に合うかを同じ条件で比べます。
判断が分かれやすい点は、次のとおりです。
パッケージ型が必要な場合の個別構築
機能や料金を確認しやすいMESのリアーキテクチャ関連製品は、現在クラウド型が中心です。
自社データセンター内での完全な自社構築が必須の場合は、オープンソース製品の組み合わせや外部ベンダーとのハイブリッド構成も候補に入ります。
最優先課題ごとの製品選び
全企業に共通する1位の製品はありません。最優先課題には、モノリスMESの分解、現場データ収集の刷新、実行基盤の刷新があります。整合性確保の強化も含め、その課題に合う製品を選びます。
対象範囲と課題を明確にし、必要な製品の組み合わせで2〜3案に絞ってからPoCへ進みます。
複数年の総保有コストで見る料金
各社に同じ工程数、データ量、サポート条件を提示し、数年単位の総保有コストで比べます。利用料に加えて、学習・統合作業・商用サポートの費用も含めて判断します。
まとめ
MESのリアーキテクチャでは、買い切りのパッケージ製品を探すより、役割ごとに現行のクラウド製品を組み合わせる方法が現実的です。
6製品には、それぞれ異なる特徴があります。たとえば、OPC UA対応のモジュール構成、現場データ収集、AWS基盤との統合などがあり、Sagaパターン対応も含まれます。
課題診断から2〜3案への絞り込み
最優先課題は、モノリスMESの分解、現場データ収集のボトルネック、境界をまたぐ処理の整合性から決めます。分割方針との適合性、OPC UA・エッジ対応、運用性と既存連携の3観点で比べると、話題性に流されずに絞り込めます。
実工程のPoCによる最終確認
最終的な判断は、自社の工程を使ったPoCの結果を見てから行います。
- 実工程でのPoC：分割する工程を使い、レイテンシや障害対応にかかる時間まで検証します。
- 個別設計の要否：既製品で独自の境界設計やPLC・生産ラインとの連携を吸収しきれない場合、設計の作り込みや実装支援が必要なこともあります。
riplaはフルスクラッチ開発の立場から、製品比較で見えた不足部分を整理します。さらに、生産ラインに合わせたMESのシステムリアーキテクチャの実装も支援しています。
▼全体ガイドの記事
・MESのリアーキテクチャの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。