製造オペレーション管理システム(MOM)開発の発注/外注/依頼/委託方法について

MOMの発注は、現場課題とKPIを定め、要件と委託範囲を整理したうえで、1ラインで検証してから展開する順に進めます。この順で進めると、段階的な定着につながります。

▼全体ガイドの記事
・製造オペレーション管理システム(MOM)開発の完全ガイド

製造オペレーション管理システム(MOM)の発注・外注の意味

MOMの上位概念に含まれるMES、QMS、APS、製造インテリジェンスを4層で示した図。
製造実行から製造インテリジェンスまでを一つの範囲として捉えます。

MOMの発注・外注では、製造現場の業務を委託先と要件に落とし込みます。対象は、製造計画の実行、品質、設備・保全です。在庫・物流やトレーサビリティも含まれます。

委託範囲は、パッケージやクラウドサービス、個別開発、SI支援を組み合わせて決めます。MOMは単一の製品ではなく上位概念で、MESやQMS、APSなどに加えて、製造インテリジェンスも含みます。

MOMの範囲は広いため、最初にどの業務を含めるかを決めます。範囲によって、必要なデータ連携と運用設計が変わります。

製造実行を超えた業務横断の管理範囲

生産指示に対する出来高や進捗の記録が中心であれば、MESで目的を満たせる場合があります。品質や追跡まで扱うかどうかで、必要な範囲が変わります。

原材料ロットと製品シリアルを結び、検査結果や設備条件を追う場合は、品質管理とトレーサビリティを設計します。作業者や時刻、手直し履歴も、追跡の対象になります。

設備の停止理由やOEEを分析して、計画・在庫・出荷までつなぐ場合は、MOM全体のデータモデルを先に設計します。そうすると、後から機能を広げやすくなります。

外注で求める定着までの成果

製造現場には、IT部門だけでは把握しにくい例外処理や、設備ごとの入力方法があります。そのため、外注先にはプログラム作成に加えて、現場観察や業務標準化も依頼します。

委託範囲には、設備メーカーとの調整やテストに加えて、教育と稼働後の改善も含めます。発注時には、改善するKPIと期限をあらかじめ定めておきます。

稼働後にマスタとデータを誰が管理するかも、成果物として決めておきます。特に、開発後の運用責任が曖昧だと、管理が途切れかねません。

MOM開発の発注形態の選び方

発注形態は次の4種類に分けて比べると、考えを整理しやすくなります。各方式が合うかどうかは、現場の条件と将来計画から判断します。

  • クラウド・SaaS:小さく導入し、利用範囲を後から広げやすい方式です。
  • パッケージ:標準機能を生かして典型業務を整える方式です。
  • オンプレミス・ハイブリッド:現場側の処理や保存条件を踏まえて選ぶ方式です。
  • スクラッチ開発:独自の工程や複雑な接続に合わせて作る方式です。

通信断時の製造継続や設備データの収集頻度を、会社の規模とあわせて確かめます。さらに、既存ERPとの連携、独自の工程、将来の拠点展開も、同じ条件で比べます。

小さく始めたい企業向けのクラウド・SaaS

クラウド・SaaSを選ぶときは、導入のしやすさと設備条件を確かめます。

  • 小さく導入:サーバーの調達や初期インフラの運用を抑えられ、1ラインや1拠点から始められます。
  • 設備条件:低遅延の処理や通信断時の入力、データ保存場所に制約がある場合は、エッジやオンプレミスとの組み合わせを確認します。

たとえば、SiemensのOpcenter Xのように、MOMの機能をモジュール単位で拡張できるSaaSもあります。

そのため、全機能を一度に導入せず、段階的に導入する考え方が現実的です(出典:Siemens「Opcenter」公式情報、2026年確認)。

パッケージの標準機能と独自要件の線引き

パッケージは、典型的な業務を短期間で整備しやすい方式です。生産実行や品質、在庫、設備保全などが対象になります。さらに、導入実績やアップデートの知見も活用できます。

標準機能に合わない業務をすべてアドオンすると、導入費用も将来のバージョンアップ費用も膨らみます。そのため、法規制や製品競争力に直結する処理を優先して独自化します。

帳票の見た目や承認順序などは、標準業務に寄せる判断が有効です。なお、Fit to Standardの検討では、独自化する要件を絞り込みます。

スクラッチは独自性が大きい場合に限定した検討範囲

スクラッチ開発では、特殊な製造工程や独自の品質判定、複雑な設備接続を柔軟に実装できます。一方で、要件定義から保守まで、自社と開発会社が長く責任を持つことになります。

既存の帳票を画面にするだけなら、SaaSやパッケージのほうが費用と納期を抑えられることがあります。また、新規開発では、納品物を契約時に定めておきます。

納品物には、API仕様、データ辞書、テストコードを含めます。設計書や運用手順も、納品物に加えます。知識が特定の担当者や会社だけに偏らないよう、これらを残します。

ポイント

発注形態は、現場の条件と将来計画から判断します。通信断時の製造継続や設備データの収集頻度を、会社の規模とあわせて確かめると、候補を絞り込めます。

RFPと要件整理の準備範囲

RFPに記載する現状と目標KPI、対象ライン、設備・既存システム、現場運用とセキュリティの4項目を示す図。
同じ条件を各候補会社へ伝えると、提案内容を比べやすくなります。

発注前に、詳細仕様書まで完成させておく必要はありません。まずは、解決したい課題と対象範囲を社内で合意しておきます。

RFPは、現状と目標KPI、対象ライン、接続対象を伝える文書です。品質・監査要件、導入時期、予算の考え方も書き添えます。また、提案に求める成果物も記載します。

候補会社が同じ条件で提案できるため、見積金額と提案内容を比べやすくなります。課題と条件をそろえることが、発注準備の出発点になります。

目的とKPIの数値化

提案会社が必要な機能を判断するには、「現場を見える化する」という目標だけでは足りません。そこで、改善したい業務は現状値と目標値で示します。

たとえば、ロット追跡時間を半日から30分以内にする例があります。停止理由の入力率や一次合格率、OEEも改善対象になります。さらに、帳票作成時間も対象に含まれます。

目標値を決められない場合は、最初の2週間を現状の測定期間にします。そのうえで、提案会社とMVPのKPIを定めます。

設備・既存システム・データの接続条件

RFPには、ERPや販売・購買システム、WMSを連携候補として記載します。さらに、QMS、SCADA、PLCも候補として挙げ、バーコードリーダーやRFID、計量器も一覧にして示します。

製品名だけでは接続の前提が分からないため、通信方式とデータ取得頻度、時刻の基準まで書きます。欠損時の扱いも添えます。さらに、通信断時の保存・再送とマスタの管理元も明記します。

設備仕様が分からない場合は、現地調査を提案範囲に含めます。そのため、接続できるかどうかを想定だけで見積もらずに済みます。

現場運用とセキュリティの要件の扱い

RFPでは、現場での使い方と、情報・制御系の保護要件を並べて整理します。

  • 現場運用:交代勤務、手袋操作、端末設置、オフライン入力の使い方を記載します。加えて、多言語表示や権限承認、教育、障害時の紙運用も盛り込みます。
  • セキュリティ:OT・IT分離やアカウント、操作ログを確認します。バックアップや脆弱性対応、復旧手順も含めます。

経済産業省は2025年4月、中小規模の製造事業者向けに、工場セキュリティの重要性と始め方を示し、サプライチェーンを含む対策を求めました(出典:経済産業省「工場セキュリティの重要性と始め方」、2025年公表情報)。

ポイント

候補会社が同じ条件で提案できるよう、RFPには課題と条件をそろえて書きます。目標値が決まらないときは、最初の2週間を現状の測定期間にできます。

MOMの外注契約の選び方(請負と準委任)

準委任契約を要件整理・現地調査・PoCに、請負契約を仕様と受入条件が固まった開発に対応させて左右で比べた図。
契約を工程ごとに分けると、不確実な調査と確定した開発を扱いやすくなります。

契約形態は、要件の確定度と成果物の定義しやすさで選びます。要件整理や現地調査、PoCは準委任とし、仕様と受入条件が固まった開発は請負とする段階分けが扱いやすい方法です。

設備連携や現場業務に未知の点が多い段階で、初期から完成責任を請負側に負わせると、前提が合わないことがあります。その食い違いが、追加費用や納期の遅れにつながりやすくなります。

請負契約を使う工程と受入基準

請負契約では、合意した成果物を完成させ、発注者が検査して受け入れる流れを設計します。受入の対象は、契約時に明記しておきます。

画面と帳票に加え、データ連携や権限、操作ログ、エラー処理を確認します。そのうえで、通信断からの復旧や性能、バックアップも対象になります。さらに、設計書、テスト結果、教育資料を対象に含めるかを決めます。

納品は稼働した時点ではなく、代表ラインで想定シナリオを実行した後とします。受入テストに合格した状態を、契約時に定義しておきます。

準委任契約が向く調査・伴走・改善の工程

準委任契約では、時間や役務に対して報酬を支払います。方針が変わりうる調査や設備確認では、成果物を無理に固定しません。

作業時間だけでは成果が見えにくいため、次の内容を契約書や個別発注書で合意しておきます。

  • 役務:調査、設計支援、プロジェクト管理、現場改善、ベンダー調整
  • 月次の記録:作業計画、報告書、課題一覧、意思決定記録
  • 進行条件:KPI、会議体、判断期限、次工程へ進む条件

保守契約と追加変更のルール

MOMは稼働後も、マスタや工程、設備、品質基準が変わります。そのため、保守契約には問い合わせ窓口や障害の重要度、一次回答と復旧の目標時間を含めます。

リリース前の検証環境やアップデート通知、バックアップ、脆弱性対応も、あらかじめ定めておきます。追加変更は、仕様変更、瑕疵修正、法令対応、運用支援に分けて扱います。

変更は、見積の承認と影響範囲の確認を経てから行います。要望をそのまま有償の作業にしない、という運用ルールです。

ポイント

契約は工程ごとに分け、要件が固まらない調査や伴走は準委任、仕様と受入条件が定まった開発は請負にします。保守と追加変更の扱いも、契約前に決めておきます。

MOM開発の費用相場の目安

MOMは公開価格が少なく、費用は工場数やライン数で大きく変わります。接続設備数や利用者数によっても変わり、既存システムやデータ移行、規制、カスタマイズも影響します。

ここで示す数字は、MOMの確定価格ではなく、公開MES価格と製造系システムの相場情報から作った予算の仮説です。

ITreviewの2026年のMES価格情報では、クラウド型の初期費用は数十万円から300万円程度です。また、同じ情報では、クラウド型の月額は5万円から30万円前後です。一方、オンプレミス型は初期500万円から数千万円、保守は月10万円からが目安とされています(出典:ITreview「MESのおすすめ製品比較」、2026年掲載情報)。

導入規模別の初期費用と期間

導入規模ごとの費用は、公開価格と企画時の予算仮説を分けて見ます。

  • 1ラインのクラウド型:電子作業指示や実績収集が目的なら、初期30万円から300万円、月額5万円から30万円前後が公開MESの目安です。
  • 1工場の標準導入:パッケージの企画予算は、300万円から1,500万円程度が仮説です。
  • 複数ラインなどの連携:ERP・QMS・WMS連携を含む場合は、1,000万円から5,000万円程度が仮説です。
  • 多拠点・高度な個別開発:規制業種の高度な個別開発では、5,000万円から1億円以上の可能性もあります。

設備接続や現地調査が加わると、クラウド型でも費用は上振れします。端末や初期マスタ、教育も、上振れの要因になります。SaaSの利用料だけで、費用の全体像をつかむことはできません。

金額は、要件定義の後に調整する前提です。なお、多拠点統合や規制業種の高度な個別開発の金額は、対象範囲を広く取った推定です。特定の企業の価格ではありません。

見積の内訳と周辺費用

見積書では、要件定義と現地調査、基本設計、画面・帳票開発を別明細にします。設備・ERP連携やデータ移行、インフラ、セキュリティ設定も、分けて記載します。

テストや教育、切替、並行稼働、保守も明記します。特に設備連携では、見積に隠れやすい項目があります。通信仕様の確認やゲートウェイ、ライセンス、夜間作業、通信断時の再送設計がそれにあたります。

移行や教育、追加ユーザーが別料金になっていないか、データ転送量や保守外の改修も確かめます。初期費用が安くても、後から別料金が重なることがあります。このため、初期費用の安さだけで判断しないようにします。

ランニングコストの内訳と運用担当の工数

保守費用を初期費用の年15%から25%程度に置いた見積例もあります。ただし、製品や契約範囲によって異なるため、相場として固定はできません。

  • 継続費用:月額または年額のライセンスやクラウド利用料、保守、監視、バックアップ、端末、通信、サポートの費用
  • 運用工数:現場でマスタ更新を担う担当者の工数
  • 比較条件:5年間の総保有コスト、拠点・ライン・ユーザー・接続設備の追加単価、契約終了時のデータ返却方法

ポイント

費用は工場数やライン数などで大きく変わるため、公開価格は予算の仮説として扱います。見積は、周辺費用と継続費用まで分けて比べます。

MOMの委託先選定と見積比較の着眼点

委託先は、製品の知名度に加えて、製造業務と設備接続を評価します。さらに、品質・監査、プロジェクト管理、稼働後支援も見ます。提案書と見積書は、同じ軸で比べます。

製品ベンダーと実装SI会社が別々の場合は、要件責任者や、設備メーカー・既存ERPとの調整担当、障害時の一次窓口を明らかにします。また、RFPで回答形式を指定する方法も有効です。

製造業の類似実績の確認項目

「製造業への導入実績がある」という答えの中身は、対象業種や工場規模、ライン数まで聞くと分かります。設備接続数や導入範囲も、あわせて聞きます。稼働までの期間、現場利用率、稼働後の支援も確認します。

可能であれば、似た工程の顧客に照会し、実際の画面でデモを依頼します。原材料ロット不足や検査不合格、設備通信断、手直し品の再投入も、デモで確かめます。

体制と役割の確認項目

営業担当に加えて、要件定義責任者と製造業務のコンサルタントを確認します。設備連携担当や品質担当、テスト責任者、導入後のサポート担当も、あわせて確かめます。

主要メンバーの稼働率や交代時の引継ぎ、再委託範囲、海外拠点や夜勤への対応可否も、契約前に聞いておきます。発注側にも、意思決定チームを置きます。

チームには、工場責任者や品質保証、情報システムを入れます。設備保全や現場リーダーも加えます。要件の優先順位は、まとめて管理します。

見積比較の前提と除外項目

見積は、金額と期間、機能数を、対象ラインや利用者数の条件をそろえたうえで比べます。さらに、接続設備や移行対象、データ保持期間もそろえます。テストケース数や教育回数、稼働立会いも確認します。

保守時間と追加変更の単価も、同じ表にそろえます。「標準機能」「要件定義後に確定」「対象外」の項目を見て、曖昧な点は質問し、回答を残します。

現地調査や設備接続が対象外になっていると、見積が安くても、発注後に追加費用や納期延長が生じる可能性があります。

ポイント

委託先は、製造業務や設備接続、品質、稼働後の支援を軸に評価します。提案書と見積書を同じ軸で比べると、条件の違いが見えてきます。

外注したMOMを失敗させない進め方

まず、1ラインまたは1工程でMVPを実施し、KPIと使いやすさを確かめてから展開します。現状の帳票を全工場へそのまま移すと、不要な入力や重複マスタまで持ち込むことになります。そこで、先に整理しておきます。

標準化できる業務と、拠点固有の業務を分けておきます。そのうえで、PoCでは実際のPLCやハンディ端末、タブレット、検査機器を使います。さらに、通信断や権限エラーも試しておくと、机上デモと現場稼働の差を小さくできます。

PoCと本番導入の判定基準

PoCの成功条件は、「画面が動いた」ではなく業務結果で定めます。確認する動作を先に決めておくと、本番導入の判断に使えます。

  • 追跡:指定ロットの原材料、設備、作業者、検査記録の検索
  • 登録:定めた時間内での停止理由の入力
  • 再送:通信復旧後の、重複のないデータ再送
  • 確認:現場リーダーによる日次KPIの自力確認

未達のときに、追加開発と対象範囲の縮小、導入中止のどれを選ぶかは、発注時点で合意しておきます。判断の基準があると、投資の判断がしやすくなります。

教育・並行稼働・切戻しの計画

製造を止められない工場では、稼働日に新システムへ切り替えるだけの計画は危険です。このため、各シフトにスーパーユーザーを置き、実データに近い訓練を行います。

一定期間は旧帳票と並行稼働させ、差異を確かめます。切替の前には、バックアップと初期マスタの凍結を済ませます。加えて、問い合わせ先、手入力への切戻し条件、復旧責任者を決めておきます。

新機能の追加よりも、障害時に安全に製造を続けられることを優先します。切戻しの手順も含めて、導入計画を立てます。

OTセキュリティのリスク分析

MOMが設備や制御系につながる場合は、事業への影響からリスクを評価します。

  • 想定する影響:情報漏えいに加えて、停止や品質不良、安全上の問題も含めて考えます。
  • RFPの対策範囲:設備・データや境界、外部接続、アカウントを定めます。さらに、パッチやログ、バックアップ、復旧訓練、委託先アクセスも対象にします。
  • 評価体制:IT部門に加えて、設備・生産・品質の担当者の参加も必要です。

IPAは、2026年4月版の「制御システムのセキュリティリスク分析ガイド 第2版」で、資産ベースと事業被害ベースの分析を紹介しています(出典:IPA「制御システムのセキュリティリスク分析ガイド 第2版」、2026年4月版)。

製造オペレーション管理システム(MOM)の発注でよくある質問

MOMの外注では、価格に加えて、範囲や責任分界、現場との適合性、稼働後の運用を確かめることが欠かせません。

MOMとMESのどちらを発注すればよいですか?

製造実行の進捗や実績収集が中心なら、MESから始められる場合があります。品質や設備保全、在庫・物流、分析に加えて複数拠点の標準化まで扱うなら、MOMとして全体のデータ連携を設計します。

そのうえで、最初にMOM全体の将来像を描き、初期の発注は優先KPIに必要なモジュールに絞る方法が現実的です。段階導入の範囲も、あらかじめ明確にしておきます。

MOM開発の予算は最初から1億円で考える必要がありますか?

1ラインのクラウド型なら、公開MES価格の初期費用数十万円から300万円程度、月額5万円から30万円前後が参考になります。設備接続や現地調査、端末が加わると費用は変わります。移行や教育、保守も、変動の要因になります。

多拠点や複雑な統合では、数千万円以上になることもあります。一度に全社で見積を取るより、MVP、効果測定、拡張の三段階に分けると、投資判断を説明しやすくなります。

RFPが作れない状態でも開発会社へ相談できますか?

RFPがまだなくても、相談できます。現場課題や対象工場、現在の帳票、設備・既存システムの一覧、改善したいKPIを共有すれば、現地調査と要件整理を準委任で依頼できます。

相談段階の提案と本開発の見積は、混同しないよう注意します。要件定義の成果物や期間、費用、次工程へ進む条件は、契約前に確かめます。

委託先を選ぶときに最も重視する実績は何ですか?

業種が同じであることに加えて、工程や設備、品質要件、工場規模、既存システム連携が近い実績を重視します。導入後の現場利用率や成果を測った事例も、確認します。

トレーサビリティの検索時間や停止時間、一次合格率などの成果を見ます。また、提案時の体制が本番でも保たれるかどうか、障害時の窓口と保守範囲も確かめます。

製品の機能に加えて、実装と定着支援の両方を評価します。そのうえで、類似実績と運用体制を合わせて選定します。

製造オペレーション管理システム(MOM)の発注・外注方法まとめ

外注時は、納期や品質、稼働率、トレーサビリティの観点から改善の目的を決めます。そのうえで、必要なモジュールと接続対象を整理し、1ラインでのMVPで検証できる範囲を切り出します。

クラウドやパッケージ、ハイブリッド、スクラッチを比べます。RFPには、現状とKPI、設備・ERP連携を記載します。加えて、現場運用やセキュリティ、受入条件も書きます。

複数社から同じ前提で提案を受けると、範囲と費用を比べやすくなります。見積の条件をそろえてから、契約形態を決めます。

契約と見積の比較による責任分界の確認

要件が固まらない調査やPoCは準委任、成果物と受入基準を定められる開発は請負とする段階契約が、不確実な設備連携を扱いやすい方法です。

見積は、現地調査や連携、移行、テストを分けてもらいます。教育や切替、保守、追加変更も、別々の項目にしてもらいます。対象外の項目と将来費用も、明示してもらいます。

選定は、金額の安さに加えて、5年間の総保有コストと稼働後に自社で運用できる体制を見て行います。責任分界と継続費用も、判断材料にします。

最初の一歩は現場課題と対象ラインの洗い出し

最初の準備は、現場の洗い出しから提案依頼まで、順に進めます。

  1. 帳票や設備一覧、既存システム、ロット・品質記録、停止理由を洗い出し、1ラインで測れるKPIを決めます。
  2. MOM導入と設備連携の実績がある会社へ、要件整理やPoCの提案を依頼します。

AI活用や高度な分析を急ぐ前に、マスタの統一や時刻の同期、欠損データの扱い、権限、バックアップを整えておきます。これらが整うと、長く使えるシステムにつながります。

▼全体ガイドの記事
・製造オペレーション管理システム(MOM)開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。