MESリプレイスのPoC（概念実証）は、既製のMESパッケージを複数社で比べ、自社の生産方式に合うかを見極める検証です。その見極めは、業務の流れ、標準機能、データと設備連携の3つの面から行います。
- 業務フロー：現場の工程と製品要件の照合
- Fit&Gap：候補製品の標準機能との差
- 実データ・PLC連携：実際のデータと設備連携による検証
経営層や情シス部門、生産技術部門の方が、どの製品に乗り換えるかを判断する拠り所になる内容です。詳しくは、次の全体ガイドをご覧ください。
▼全体ガイドの記事
・MESリプレイスの完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
MESリプレイスにおけるPoCの位置づけ（既製品比較評価という文脈）
MESリプレイスのPoCを正しく理解するには、「何を検証するのか」という対象の違いを押さえることが出発点になります。
自社でゼロからMESを開発する場合のPoCは、独自の工程管理・実績収集ロジックを技術的に実現できるかを確かめるものです。一方、リプレイスのPoCは、既製のMESパッケージが自社の生産方式に合うかを確かめるもので、性質がまったく異なります。
自社ゼロ試作ではなく複数パッケージ・ベンダーを比較評価するPoC
MESリプレイスのPoCは、フルスクラッチ開発のように「動くものを作れるか」を確かめる技術検証とは違います。複数のMESパッケージ候補のうち、どれが自社の生産方式・実績収集ロジック・PLC連携に最も合うかを見極める比較評価です。
そのため、見る対象は、パッケージの標準機能が自社の業務要件にどこまで適合するか（Fit&Gap）、実際の工程進捗・実績データを投入したときの挙動、現場のPLC・設備との連携可否の3点です。この違いを押さえずに「PoC＝試作品を自社で作ること」と捉えると、本来は要らない開発コストをかけてしまうおそれがあります。
「モダナイゼーション」「刷新」「更改」「リニューアル」「リアーキテクチャ」との違い
姉妹記事は、それぞれ別の観点に焦点を当てています。「MESのモダナイゼーション」は5R（技術的アプローチ）の使い分け、「MES刷新」は経営層の投資判断プロセスを扱います。「MES更改」は契約満了・EOS/EOLという期限管理、「MESのリニューアル」は実績入力画面のUI/UXプロトタイピングが対象です。
「MESのリアーキテクチャ」は、イベント駆動アーキテクチャやPLC・OPC UAエッジ処理の技術的なパイロットフェーズが中心です。一方、本記事が扱うMESリプレイスのPoCは、自社で何かを作る検証ではありません。FactoryTalkやAsprovaといった既製のMESパッケージを複数社で比較し、自社にとって最良の1社を選び抜くための検証に焦点を絞ります。
RFI・RFPによる一次選定からデモ評価までの流れ
本格的なPoCに入る前に、まず候補となるMESパッケージ・ベンダーを絞り込む必要があります。この段階を丁寧に進めるほど、後続のPoCの精度が高まります。
RFIによる10社程度から3〜5社への絞り込み
要件を固めきる前の初期段階では、市場にあるMESパッケージのベンダーを10社程度ピックアップし、RFI（情報提供依頼書）を送付します。
RFIでは、会社情報や導入実績、概算費用などを広く浅く集めます。さらに、工程管理・実績収集・品質判定・トレーサビリティ照会といった基本機能の対応範囲も集めます。その回答をもとに、自社の生産方式に明らかに合わない製品を除外し、候補を3〜5社程度に絞り込みます。
この段階は、書面やカタログ情報による一次スクリーニングにとどめます。無駄な工数をかけずに候補を絞れるため、効率的な進め方です。
デモ評価・プレゼンで現場オペレーターを参加させる重要性
絞り込んだ候補には、自社の生産方式や課題、機能・非機能要件、スケジュールを明記したRFP（提案依頼書）を提示します。そのうえで、精度の高い提案書と見積もりを依頼します。
提出された提案書をもとに最終候補のデモンストレーションを行う際は、経営層や情報システム部門だけでなく、実際に工程進捗・実績入力を行う現場のオペレーターの参加が欠かせません。その際、現場の目線で「操作感」「入力の負担」「今の運用とどれだけ乖離するか」を審査してもらうと、机上の機能比較では見えない導入後の定着リスクを事前に洗い出せます。
あわせて、ベンダーのプロジェクトマネージャーが製造現場の課題を理解し、専門用語を使わずに説明できるかも見ておきます。この点は、その後のプロジェクトを進める力を占う重要な評価軸になります。
Fit&Gap検証というトライアル環境でのPoC
カタログの比較やデモで見きれない部分を確かめるのが、ベンダーが提供するトライアル環境を使ったPoC（実機検証）です。既製品は自社の実データ・実業務シナリオに当てはめて評価します。
標準機能適合度の実機確認とピーク負荷の実測
Fit&Gap検証では、洗い出した自社の工程管理・実績収集・品質判定の業務プロセスが、パッケージ製品の標準機能にどこまで適合するかを実機で確かめます。ここで主眼になるのは、現場の熟練者の勘や例外的な運用ルールを無理にシステムへ組み込むことではありません。逆に、運用をパッケージ側の標準機能に合わせられるかを検証することです。
あわせて、手袋着用時のタッチ操作性や、月末の生産計画確定処理といった負荷が集中する場面を、トライアル環境で意図的に再現します。そのうえで、処理性能やレスポンスタイムが実運用に耐えられるかを「実測」で確かめます。カタログのスペックからは分からない、パッケージの実力を見極めるPoCの中核となる工程です。
評価マトリックスによる客観的スコアリング
複数のMESパッケージ候補を公平に比べるには、担当者の主観に頼らない評価マトリックスを使うことが欠かせません。
「要件適合度」「導入・運用コスト」「セキュリティ」「サポート体制・事業継続性」「PLC・現場設備との連携実績」といった評価軸をあらかじめ設け、各候補をスコアリングします。そうすると、経営層への説明責任を果たしやすくなります。
発注側は、自社の生産プロセスをシナリオ単位に分けます。そのうえで、「標準機能で対応可能」「運用変更で吸収可能」「追加開発が必要」の3ラベルに分類するフィット&ギャップ分析を行っておくと、過度なカスタマイズを避けるための判断材料になります。
実績データ・BOM等の実データを用いた検証の3段階
データ移行はシステムリプレイスにおける最大の難所です。そのため、PoCの段階から生産実績・トレーサビリティ・BOMという実データを使った検証を組み込むことが、後工程の手戻りを防ぐ最も確実な方法です。
データモデル定義とサンプル移行テスト
実データ検証の第1段階では、新しいパッケージを前提に、品目・BOM・在庫階層の構成やルールを定義します。あわせて、旧システムに蓄積された表記ゆれ・重複・欠損を解消するためのデータクレンジング計画を立てます。
続く第2段階では、旧システムから一部の代表的な生産実績・ロット履歴・BOMデータを抽出し、新パッケージへ実際に投入するサンプル移行テストを行います。データ変換ロジックや項目マッピングが論理的に正しく機能するかを、ここで確認します。
この段階で、自社独自の複雑な実績収集ロジックを標準パッケージの構造に変換できるかが、早期に分かります。
本番相当の全量データによるシステム統合テスト（SIT）
サンプル移行テストで論理的な正しさを確認したあとの第3段階では、本番相当の全量データを使ったシステム統合テスト（SIT）を行います。大量のデータを投入したときに、データ品質が崩れないか、処理パフォーマンスに問題が生じないかを検証します。
ただし、PoCの段階で全量データの検証をすべての候補に行うのは現実的ではありません。そのため通常は、最終候補1〜2社に絞り込んだ段階でこのSIT相当の検証を行います。契約締結前に「本当にこのパッケージでデータ移行がやり切れるか」を最終確認するのが、実務上の進め方です。
PLC・現場設備との連携実証（周辺機器・異常系テスト）
MESパッケージは単独では完結せず、工場現場の他システムや機器と連動して初めて価値を発揮します。そのため、PoCの最終段階では、この周辺領域を含めた統合的な実証まで行うことが欠かせません。
ハンディターミナル・バーコードリーダー等の周辺機器連携確認
実績入力に使うハンディターミナルやバーコードリーダー、RFIDスキャナーといった周辺機器が、新たに採用するMESパッケージのもとで正常に使えるかを検証します。
あわせて、PLC・生産設備や上位ERPとのインターフェース要件（API連携、ファイル連携、通信コードのマッピング等）を定義します。そのうえで、システムを連携させた統合状態で稼働を確認します。
カタログ上は「連携可能」とうたわれていても、自社が使う設備・機種との組み合わせで正しく動くかは、実機を使ったPoCでしか確認できません。
短サイクルのスプリントでの先行検証と異常系テスト
影響範囲が大きく不確実性の高いPLC・外部設備連携には、2〜4週間程度の短いスプリントを設けます。小さく素早くPoCを繰り返す進め方が効果的です。
あわせて、通信エラーやネットワーク異常が起きたときに、アラート通知・ログ出力・再送処理（リカバリ）が運用ルールどおりに機能するかを見ておきます。「異常系」の動作確認は、この段階で行っておくべき重要な検証項目です。
正常時の連携確認だけで済ませず、現場で実際に起こりうるトラブルを想定した検証まで行っておくことが大切です。そうすれば、契約後に「実はこの設備とはうまく連携できなかった」という致命的な事態を防げます。
まとめ
本記事では、MESリプレイスにおけるPoC・プロトタイプ・モックアップ開発を、既製品の比較評価という文脈で位置づけました。そのうえで、RFI・RFPによる一次選定からデモ評価までの流れを解説しました。さらに、Fit&Gap検証から、3段階の実データ検証、PLC・現場設備との連携実証までを取り上げました。
MESリプレイスにおけるPoCの本質は、自社で新しく作ることではありません。FactoryTalkやAsprovaといった既製のMESパッケージが、自社の生産方式・実績収集ロジック・PLC連携という実データ・実環境にどこまで合うかを、複数ベンダーで公平に比べる点にあります。
RFI・RFPによる絞り込みに始まり、標準機能適合度の実機確認と、3段階の移行検証、連携実証まで丁寧に積み重ねることが、契約後の「こんなはずではなかった」という失敗を防ぐうえで最も大切です。
開発期間・スケジュールや保守・運用費用の詳細は、姉妹記事もあわせてご参照ください。
▼全体ガイドの記事
・MESリプレイスの完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。