MESのリアーキテクチャにおけるPoC・プロトタイプ・モックアップ開発は、本開発に入る前に技術的な不確実性を小さく検証する工程です。確かめる観点は次の4つです。
- イベントストーミング：ドメインの境界と、業務で共有する用語（ユビキタス言語）の洗い出し
- OPC UA連携：PLC・生産設備との接続の検証
- エッジ基盤：現場データを収集・処理する構成の試行
- 移行判断：パイロットからMVPへ進む条件の見極め
MESのリアーキテクチャは、稼働中のMES（Manufacturing Execution System：製造実行システム）の作り替えのうち、アーキテクチャそのものの再設計に焦点を絞った取り組みです。
同じ「MESを作り替える」というテーマでも、記事ごとに主眼は異なります。「MESのモダナイゼーション」は、5つの技術的アプローチを並べて扱う総論で、リホストからリプレースまでが対象です。
「MES刷新」は経営層の内発的な投資判断を、「MES更改」は保守契約の満了やハードウェアのリース期限、EOS/EOLといった外圧型の期限管理を扱います。「MESのリニューアル」は、現場オペレーターの操作体験（UX/UI）に焦点を当てています。
これに対して本記事群が扱うのは、構造そのものの技術設計に特化したMESのリアーキテクチャです。工程進捗・実績・品質をリアルタイムに収集する「現場の実行制御レイヤー」をドメイン駆動設計（DDD）でどう設計し直すか、PLC・生産設備のデータをOPC UA等やエッジコンピューティングでどう収集・処理するかを扱います。
本記事は、そのなかでも本開発に着手する前の、PoC・プロトタイプ・モックアップ開発に焦点を当てます。各観点の具体的な進め方を、順に見ていきます。
マイクロサービス化やドメイン駆動設計の導入を検討しているものの、いきなり本開発に入ることに不安を抱える情報システム部門・生産技術部門の方に向けた内容です。検証すべきポイントを具体的にイメージできるはずです。
MESのリアーキテクチャ全体の流れは、次の全体ガイドで確認できます。
▼全体ガイドの記事
・MESのリアーキテクチャの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
MESのリアーキテクチャの位置づけ（なぜPoC・技術検証が不可欠なのか）
MESのリアーキテクチャは、現場のPLC・生産設備からクラウドまでが複雑に絡み合う、技術的な不確実性が非常に高いプロジェクトです。
ドメイン境界の引き方を誤ると「分散モノリス」という致命的な失敗パターンに陥ります。さらに、OPC UA連携やエッジ基盤の実現可能性を確かめないまま本開発に入ると、開発の終盤になって「現場のPLCと連携できない」という深刻な事態が発覚しかねません。
だからこそ、本開発に着手する前の3〜6ヶ月を「パイロットフェーズ」と位置づけます。PoC・プロトタイプ・モックアップで不確実性を事前に検証しておくことが、後工程での大規模な手戻りを防ぐ最も確実な方法です。
「モダナイゼーション」「刷新」「更改」「リニューアル」との違い
姉妹記事「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開発への移行判断も進めやすくなります。
まとめ
PoC・プロトタイプ・モックアップ開発は、4つの工程で進みます。最初がイベントストーミング・ワークショップ、次がOPC UA連携のアーキテクチャスパイク、続いてエッジコンピューティング基盤のプロトタイピング、最後がパイロットフェーズからMVP開発への移行判断です。
パイロットフェーズの3〜6ヶ月で、実行ドメインの境界検証、プロトコル変換の技術検証、オフライン耐性の検証を集中して行うと、本開発の失敗リスクを大きく減らせます。
動くものを急いで作るより、「実現できるかどうか」を最短距離で確かめるというPoCの本来の目的を忘れないことが、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を創業。