MESのリアーキテクチャとは、稼働中のMES（Manufacturing Execution System：製造実行システム）の「作り替え」の中でも、アーキテクチャそのものの再設計に焦点を絞った取り組みです。同じ「MESを作り替える」というテーマでも、「MESのモダナイゼーション」がリホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチを並列に扱う総論であり、「MES刷新」が経営層の内発的な投資判断（WHY/WHEN）に、「MES更改」が保守契約満了やPLC等ハードウェアのリース期限・EOS/EOLという外圧型の期限管理に、「MESのリニューアル」が現場オペレーターの操作体験（UX/UI）に、それぞれ重心を置くのに対し、本記事群が扱うMESのリアーキテクチャは、そのいずれとも異なり、工程進捗・実績・品質をリアルタイムに収集する「現場の実行制御レイヤー」をどう構造として設計し直すか（ドメイン駆動設計・DDD）、そしてPLC・生産設備からのリアルタイムデータをOPC UA等の産業用プロトコルでどう収集・処理するか（エッジコンピューティング）という「構造そのものの技術設計」に特化した技術専門記事です。本記事はその中でも、いきなり本開発に着手せず、技術的な不確実性を事前に潰しておくPoC・プロトタイプ・モックアップ開発というプロセスに焦点を当てます。
本記事では、MESのリアーキテクチャにおけるPoC・プロトタイプ・モックアップ開発について、ドメイン駆動設計のイベントストーミング・ワークショップの進め方、PLC・生産設備とのOPC UA連携を検証するアーキテクチャスパイク、エッジコンピューティング基盤のプロトタイピング、そしてパイロットフェーズからMVP開発への移行判断までを、具体的な進め方とともに体系的に解説します。マイクロサービス化やドメイン駆動設計の導入を検討しているものの、いきなり本開発に入ることへの不安を抱えている情報システム部門・生産技術部門の方にとって、検証すべきポイントが具体的にイメージできる内容です。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・MESのリアーキテクチャの完全ガイド
MESのリアーキテクチャの位置づけ（なぜPoC・技術検証が不可欠なのか）
MESのリアーキテクチャは、現場のPLC・生産設備からクラウドまでが複雑に絡み合う、技術的な不確実性が非常に高いプロジェクトです。ドメイン境界の引き方を誤れば「分散モノリス」という致命的な失敗パターンに陥り、OPC UA連携やエッジコンピューティング基盤の実現可能性を確かめないまま本開発に入れば、開発終盤になって「現場のPLCと連携できない」という深刻な事態が発覚しかねません。だからこそ、本開発に着手する前の3〜6ヶ月間を「パイロットフェーズ」と位置づけ、PoC・プロトタイプ・モックアップという形で技術的な不確実性を事前に検証しておくことが、後工程での大規模な手戻りを防ぐ最も確実な方法です。
「モダナイゼーション」「刷新」「更改」「リニューアル」との違い
姉妹記事「MESのモダナイゼーション」「MES刷新」「MES更改」「MESのリニューアル」は、それぞれ技術手法の総論、経営判断、期限管理、体験価値という異なる軸でMESの作り替えを扱っており、いずれの記事でも「検証」に相当する工程はプロトタイプでの操作性確認や現状アセスメントといった限定的な扱いにとどまります。これに対し本記事が扱うMESのリアーキテクチャにおけるPoC・プロトタイプ・モックアップ開発は、ドメイン境界の妥当性やOPC UA連携の技術的実現可能性そのものを検証対象とする、アーキテクチャ設計に固有のプロセスです。この違いは、本開発前にどれだけの技術的不確実性を抱えているかという、プロジェクトの性質そのものの差から生まれています。
「システムリアーキテクチャ」総論・「生産管理システムのリアーキテクチャ」との違い
姉妹記事「システムリアーキテクチャ」はアーキテクチャスパイクやイベントストーミングの一般的な進め方を対象システムを問わず解説し、「生産管理システムのリアーキテクチャ」は生産計画・MRP・製番管理という計画側の司令塔レイヤーを対象にPoCの進め方を扱います。本記事はこれらの枠組みを引き継ぎつつ、MESという現場直結の実行レイヤーに対象を絞り込みます。MESのPoCでは、工程実行・実績収集・品質トレーサビリティという実行ドメインの境界検証に加え、PLCとOPC UAで直接やり取りするアーキテクチャスパイクという、計画レイヤーの検証よりも一段深い現場設備連携の技術検証が求められる点が特徴です。
ドメイン駆動設計のイベントストーミング・ワークショップ
コードを書き始める前に、ビジネスと技術の境界を定義するのがPoCの最初のステップです。ここで境界を誤ると、後から変更が困難になります。
ワークショップの進め方とユビキタス言語の定義
イベントストーミングは、ドメイン専門家（工場長・生産技術担当者・品質管理担当者など）、プロダクトマネージャー、エンジニアが一堂に会し、付箋などを用いて生産現場で発生するあらゆるビジネスイベント（例えば「検査完了」「異常検知」「生産開始」）を時系列にマッピングするワークショップです。参加者全員で共有する業務語彙（ユビキタス言語）をこの場で定義し、開発者と現場担当者の間の認識のズレをなくします。最初からすべてを細かく分割するのではなく、まずは「工程実行」「実績収集」「品質トレーサビリティ」といった3〜5つのコアなビジネスドメインを特定し、境界づけられたコンテキスト（Bounded Contexts）の自然な「継ぎ目」を見つけ出すことが、このワークショップの最大の目的です。
品質トレーサビリティドメインの境界検証
イベントストーミングで定義した境界が、ソフトウェアアーキテクチャとして妥当かを検証する工程です。APIの仕様（コントラクト）を先行して定義し、「工程実行サービス」と「品質トレーサビリティサービス」がどのように通信するかをモックアップで検証します。明確な境界を持たずにすべてを一度に分割しようとすると、独立したデプロイが不可能で運用オーバーヘッドだけが高い「分散モノリス」に陥るという致命的な失敗パターンが存在します。これを防ぐため、品質トレーサビリティドメインが独自のデータベースを持ち、他のサービス（工程実行など）に変更を加えても、品質トレーサビリティ側のコード修正や同時デプロイが不要であるかをPoC環境で検証しておくことが、このフェーズの核心です。
PLC・生産設備とのOPC UA連携のアーキテクチャスパイク（技術検証）
MESにおいて技術的難易度が最も高く、プロジェクトのボトルネックになりやすいのが設備連携です。アーキテクチャスパイク（技術的な不確実性を排除するための局所的なコード実装・検証）を実施し、本開発前にこの不確実性を潰しておく必要があります。
プロトコル変換とデータクレンジングの検証
古いPLC（プログラマブルロジックコントローラ）や多様な設備から送られてくるデータを、OPC UAなどの標準プロトコルを介して収集し、統一フォーマットに変換する仕組みを構築するのが、このスパイクの中心的な作業です。設備によって出力データの形式や粒度がバラバラであることが多く、実機を用いた接続検証を行わない限り、この変換ロジックが実際にどこまで通用するかは分かりません。過去の事例が示す通り、この「データ準備・基盤整備」の工程には非常に時間がかかるため、プロジェクト初期にリソースを集中させ、データストリーミング基盤（Kafkaなど）へ確実にメッセージが送信されるかを技術検証しておくことが、後工程のリスクを大幅に減らします。
データ基盤整備への工数の先行投資
アーキテクチャスパイクの目的は、動くコードを完成させることではなく、「実現できるかどうか」を最短距離で確かめることにあります。プロジェクト全体の期間・予算の40〜60%をこのデータ準備・エッジ基盤整備の先行投資に充てることが推奨されるのは、この検証が不十分なまま本開発の見積もりを確定させると、後から発覚する技術的な壁によって当初9ヶ月と見積もっていた開発フェーズが大幅に延びるリスクがあるためです。逆に、この段階で基盤の安定性を確認できていれば、後続の各マイクロサービス開発フェーズの工数を大きく圧縮できる可能性もあり、アーキテクチャスパイクへの投資はプロジェクト全体のリスクヘッジとして機能します。
エッジコンピューティング基盤のプロトタイピング
生産現場のリアルタイム要件を満たしつつ、クラウドのインフラコストを最適化するためのプロトタイピングです。ここではハイブリッド処理の検証と、通信障害時の耐障害性検証という2つの観点が重要になります。
ハイブリッド処理・レイテンシの検証
センサーやPLCからミリ秒単位で発生する膨大なデータをすべてクラウドに送信すると、ネットワーク遅延や帯域幅のコストが爆発します。そのため、データの発生源である現場のサーバー（エッジ）でデータのフィルタリングや一次解析（例えば明らかな異常値の即時検知）を行い、結果だけをクラウドに送るハイブリッドアーキテクチャを構築し、応答速度を検証するのがこのプロトタイピングの目的です。実際のPLCから取得できるデータの発生頻度を前提に、エッジ側での処理がどこまで現場のリアルタイム性を担保できるかを、机上の計算ではなく実測値で確認しておく必要があります。
オフライン稼働（フォールバック）とカオスエンジニアリング
工場のネットワークが一時的に切断された場合でも、エッジ側のローカル処理によって生産ラインを止めずに稼働を継続できるか（耐障害性）をテストすることも欠かせません。意図的にネットワーク遅延や通信障害を注入することで、クラウドへの同期が回復した後にデータが欠損なく再送されるかを検証するカオスエンジニアリングの手法が有効です。生産ラインの停止は部品調達や出荷の遅延に直結するため、「クラウドと繋がっていることを前提にしたアーキテクチャ」のまま本番稼働させることは避けなければならず、このオフライン耐性の検証をプロトタイプ段階で済ませておくことが、稼働後の重大インシデントを未然に防ぐ最大の備えになります。
パイロットフェーズからMVP開発への移行判断
4つの検証を通過した後、いつ・どのような基準で本格的なMVP開発へ移行するかを判断する必要があります。この移行判断の質が、プロジェクト全体の成否を左右します。
早期成功シグナルの定義
ドメイン境界の妥当性・OPC UA連携の実現可能性・エッジコンピューティング基盤の耐障害性という3つの検証結果を統合し、CI/CDパイプライン上で最初のモジュールが安定稼働するといった「早期成功シグナル」が確認できた段階で、本格的なMVP開発へと進むのが最も確実なロードマップです。逆に、いずれかの検証で致命的な課題が見つかった場合は、本開発のスケジュールに入る前にドメイン境界の引き直しやプロトコル変換方式の再検討を行うべきであり、PoC段階での「見切り発車」を避けることが、プロジェクト全体の納期と予算を守る最大の防波堤になります。
PoCフェーズを任せるパートナー選定のポイント
PoC・プロトタイプ・モックアップ開発は、単に「動くものを作る」工程ではなく、「作らない判断」も含めた技術的な意思決定のプロセスです。依頼先を選ぶ際は、イベントストーミングのようなワークショップ形式のドメインモデリングを製造業の業務知識を持つアーキテクトが主導できるか、PLC・OPC UA連携の実機検証経験があるか、そしてカオスエンジニアリングのような耐障害性検証の手法を実践できるかを確認することが重要です。PoCフェーズの成果物として、検証結果を踏まえたアーキテクチャ設計書と本開発の見積もり根拠を明示できるパートナーであれば、パイロットフェーズからMVP開発への移行判断もスムーズに進みます。
まとめ
本記事では、MESのリアーキテクチャにおけるPoC・プロトタイプ・モックアップ開発について、ドメイン駆動設計のイベントストーミング・ワークショップ、PLC・生産設備とのOPC UA連携のアーキテクチャスパイク、エッジコンピューティング基盤のプロトタイピング、そしてパイロットフェーズからMVP開発への移行判断を体系的に解説しました。工程実行・実績収集・品質トレーサビリティという実行ドメインの境界検証、古いPLCとの接続可否を確かめるプロトコル変換の技術検証、そして通信障害時にも生産ラインを止めないオフライン耐性の検証という3つの柱を、最初の3〜6ヶ月のパイロットフェーズで集中的に行うことが、本開発の失敗リスクを大きく減らします。動くものを作ることを急ぐのではなく、「実現できるかどうか」を最短距離で確かめるというPoCの本来の目的を見失わず、製造業の業務知識と現場設備連携の実績を併せ持つパートナーとともに、確実なロードマップを描くことが、MESのリアーキテクチャを成功に導く鍵となります。
▼全体ガイドの記事
・MESのリアーキテクチャの完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。