保全をMESに入れるかどうかは、機能ではなく境界の問題
MES製品の多くは保全モジュールを持ち、CMMS／EAM製品の多くは稼働データの取り込み機能を持ちます。両者の機能一覧を並べると重複領域が広く、比較しても結論が出ません。
議論を前に進めるには、保全業務を3つに分けて、それぞれの置き場所を決めるのが確実です。
- 保全の計画と実行管理：予防保全のスケジュール、作業指示、作業報告、部品の払い出し、コスト集計
- 設備の状態把握：稼働／停止、停止理由、累積稼働時間、ショット数、異常イベント
- 作業の可否判定：保全期限を超えた設備で生産させない、異常未解除の設備を使わせない
このうち「状態把握」と「作業の可否判定」は、本質的にMESの領域です。前者は生産実績と同じソースから生まれ、後者は着手可否の判定に組み込まれます。一方、「計画と実行管理」はCMMS／EAMの領域で、部品在庫・保全要員の工数・設備台帳といった、生産実行とは別の業務データを必要とします。
この切り分けを先に共有しておくと、以降の製品選定が「どちらの製品にするか」ではなく「境界をどこに引くか」の議論になります。
3つのアーキテクチャ案を比較する
| A：MES内包型 | B：CMMS分離型 | C：ハイブリッド型 | |
|---|---|---|---|
| 保全計画・作業指示 | MES | CMMS | CMMS |
| 稼働・停止データ | MES | MESから連携 | MES |
| 保全トリガーの判定 | MES | CMMS（連携データを使う） | MES（判定）→ CMMSへ起票 |
| 作業可否判定 | MES | 実装が難しい | MES |
| 部品在庫 | 持たない／簡易 | CMMS | CMMS |
| 向いている規模 | 単一拠点・設備数が少ない | 保全部門が独立して大きい | 中〜大規模・多拠点 |
| 主なリスク | 保全業務が本格化すると機能不足 | 作業可否判定が実装できず、統制が効かない | 連携の設計と運用が必要 |
最も多く選ばれるのはCですが、最も失敗が多いのもBです。Bは組織構造（生産部門と保全部門が別）をそのままシステムに写した構成で、一見合理的に見えます。しかしこの構成では、「保全期限を超えた設備で生産を始めさせない」という統制が実装しづらくなります。MESが保全状態を知らないためです。
Bを選ぶ場合でも、保全ステータスだけはMESへ連携し、着手判定に使う設計にします。ここを省くと、保全管理は「記録は残るが生産は止まらない」仕組みになります。責任分界の詳細はMESと設備保全システム（CMMS／EAM）で扱います。
境界を越えるデータは4種類しかない
MESとCMMSの連携は、複雑に見えて実際にやり取りする情報は限られています。この4つを定義できれば、連携仕様はほぼ固まります。
このうち③の即時性が最も重要です。保全が完了して設備が使用可になったことがMESに届くのが翌朝のバッチだと、その間の生産が止まります。逆に④は日次で十分です。連携の頻度を一律に決めず、データごとに必要な鮮度で設計します。
①の累積稼働量は、MESの停止理由分類がそのまま保全トリガーの精度を決めるという点で注意が要ります。段取り替え中や材料待ちの時間を稼働時間に含めてしまうと、実際の稼働より早く保全期限が来ます。稼働の定義はISO 22400のような標準に沿って整理しておくのが安全です（ISO 22400、MESのKPIを標準で定義する）。停止イベントの分類設計そのものはダウンタイムの記録と分析で扱います。
予知保全に手を出す前に決めること
保全のデジタル化の議論は、しばしば予知保全へ一足飛びに進みます。しかし予知保全は、次の3つが揃って初めて成立します。
- 故障の記録が構造化されている：いつ、どの設備の、どの部位が、どう壊れたか。自由記述の作業報告しかない状態では、学習させる教師データが作れません
- 正常時のデータが十分にある：異常検知は正常のパターンを知ることから始まります。1年分の連続データがない設備では、季節変動すら分離できません
- 予兆が出たときの行動が決まっている：「3日以内に故障する確率が高い」と示されたとき、誰が生産計画を止め、誰が部品を手配するのか。この意思決定経路がなければ、予測は画面上の数字で終わります
3番目が最も軽視されます
予知保全の実証実験が本番化しない理由の大半は、モデルの精度ではなく、予兆に対して組織が動けないことにあります。
実装例としては、Siemensが2026年6月4日に発表したHighByteとの提携で、ブラジルのVivix Vidros Planosが1.2億ドル規模のガラス炉に対する予知保全を構築した事例が挙げられています。この規模の設備であれば、停止1回のコストがモデル構築の投資を大きく上回るため、投資判断が明快です。逆に言えば、汎用設備に横並びで予知保全を導入する判断は、費用対効果の面で成立しにくいということでもあります。
実装の失敗と、製品側の動き
失敗1：設備マスタを3か所に持つ。 ERP（固定資産）、CMMS（保全対象）、MES（実行時の資源）。識別子の正を1つに決めないと、集計時に名寄せができません。実務ではCMMSまたはERPを正とし、MESは同じ識別子を参照する構成が一般的です。
失敗2：停止理由コードを保全部門と生産部門で別々に作る。 生産側は「設備故障」の一言で済ませ、保全側は詳細な故障モードで記録する。この状態では両者のデータが突合できず、停止時間の合計すら一致しません。理由コード体系は、導入時に両部門で合意して1本にします。
失敗3：保全作業そのものをMESの工程として管理しようとする。 保全作業は生産工程とは所要時間の見積もり方も、担当者の割り当て方も違います。生産工程のモデルに無理に載せると、どちらの運用も歪みます。
失敗4：計画停止をスケジューリングの制約に入れていない。 保全予定が生産計画に反映されないと、保全当日に生産計画が入っていて保全が延期される、という事態が繰り返されます。前掲の図の④が、この問題への対策にあたります。
製品側では、MESが保全領域へ機能を伸ばす動きが続いています。Siemens Opcenterは2026年8月14日リリースのMES Medical Device 2607で設備ログブックを追加し、設備に紐づく事象の記録をMES側に持たせる方向を示しました。ただしこれは前述の「状態把握」の強化であり、保全計画と部品在庫の管理をCMMSから置き換えるものではありません。製品の機能追加を見るときは、それが状態把握側なのか計画・実行管理側なのかを区別して評価します。
よくある質問
CMMSを導入せず、MESの保全モジュールだけで運用できますか。
設備台数が数十台規模で、保全要員が専任1〜2名、部品在庫の管理が簡易でよい、という条件なら十分に成立します。判断の目安は「保全部門が独立した予算とKPIを持っているか」です。持っているなら、保全業務は生産実行とは別のライフサイクルで回っており、専用システムが必要になる可能性が高くなります。持っていない（生産部門の中で保全も見ている）なら、MES内包型で始めて、必要になった時点で切り出すほうが立ち上がりは早くなります。
保全期限を超えた設備で、本当に生産を止めてよいのでしょうか。
条件を分けてください。法定点検や顧客要求にもとづく点検を超過した設備は、止めるべきです。一方、社内基準の予防保全については、期限超過で即停止にすると生産計画が頻繁に崩れます。実務では、法定・顧客要求は強制停止、社内基準は警告と承認、という二段構えが一般的です。重要なのは、どちらに分類するかを設備・点検項目ごとに定義し、その根拠を記録しておくことです。
保全のKPIは何を見ればよいですか。
MTBF（平均故障間隔）とMTTR（平均修復時間）を基本とし、そこに計画保全遵守率を加えるのが出発点です。ただしこの3つは、停止イベントの分類が正しく設計されていなければ計算できません。特にMTBFは「故障」と「その他の停止」を区別できるかどうかで数値が大きく変わります。KPIを決めてから停止理由コードを設計するという順序を守ってください。逆にすると、集計したい単位でデータが取れていないことに後から気づくことになります。
