最初に決めるのは「MESなしで何時間流せるか」
MESのBCPを、システム復旧計画として設計すると失敗します。復旧に4時間かかると分かっても、その4時間で現場が何をするかが決まっていなければ、ラインは止まるからです。
出発点は次の問いです。MESが停止したとき、生産を継続してよいのか。継続するなら、何を紙で代替し、復旧後にどうデータへ戻すのか。
この判断は工程ごとに違います。
| 工程の性格 | MES停止時の判断 | 代替手段 |
|---|---|---|
| 連続プロセス（化学・製紙・鉄鋼など） | 止められない。制御層は独立して動くため生産は継続 | 工程パラメータはヒストリアン側に残る。実績はあとで突合 |
| 規制産業の最終工程（医薬・医療機器） | 止める判断が妥当な場合が多い | 電子記録の連続性が切れると、事後の是正で吸収しきれない |
| 一般の組立・加工 | 短時間なら紙で継続 | あらかじめ印刷した作業指示書と実績記録票を各ラインに常備 |
| 出荷判定・ラベル発行 | 止める | 誤出荷リスクが復旧待ちのコストを上回る |
「一律に止める」「一律に流す」のどちらも現実的ではありません。工程ごとに判断を決め、紙の様式まで用意しておくのが縮退運転（degraded mode）の設計です。
RPOとRTOはデータの種類ごとに分ける
MESが持つデータは性格が大きく異なるため、単一のRPO（目標復旧時点）とRTO（目標復旧時間）を全体にかけると、過剰投資か過小投資のどちらかになります。
図の右側、復旧後の遡及入力が見落とされがちな領域です。縮退運転中に紙で取った実績を誰がいつシステムへ戻すのか、その転記に対して二重確認が必要か、監査証跡にどう記録するか。規制産業ではここが査察の指摘対象になります（監査証跡の設計）。
データ種別ごとの目安は次のとおりです。
- マスタ（品目・工程・設備・作業者・レシピ） — 変更頻度は低いが、失うと復旧不能。RPOは日次で足りるが、変更のたびに世代を残す運用が確実
- 仕掛・進捗（WIP） — 失うと現物とシステムが食い違い、棚卸しが必要になる。RPOは分単位が望ましい
- 工程実績・品質記録 — トレーサビリティの根拠。RPOは分単位。かつ改ざん不能な形で保管
- 設備収集データ — ヒストリアン側に一次データが残るなら、MES側のRPOは緩めてよい
ランサムウェア対策としてのバックアップ設計
バックアップ設計の前提は、この5年で変わりました。ハードウェア故障ではなく、バックアップごと暗号化されることを想定する必要があります。IPAの「情報セキュリティ10大脅威 2026」でも、組織向けの1位はランサム攻撃で、11年連続の選出です。
満たすべき条件は3つです。
- オフラインまたは変更不可（イミュータブル）な世代を持つ — 本番から到達できる場所にだけ置かない
- 世代数を「気づくまでの日数」で決める — 侵入から発覚まで数週間かかる例があるため、日次7世代では足りない場合がある
- 復元テストを定期実施する — 取れていることと戻せることは別です
冗長化はどこまでやるか：製品側の前提も変わっている
可用性の設計は、製品アーキテクチャの進化を織り込んだほうが安く済みます。
- Rockwell FactoryTalk ResilientEdge（2026年6月18日発表）は、エッジでのリアルタイム実行とクラウド側の分析を分離し、ネットワーク断でも操業を継続できる設計を掲げています（エッジMESの設計思想）
- Siemens Opcenter MES Medical Device 2607（2026年8月14日リリース）は、Kubernetes＋Linuxコンテナ化によりゼロダウンタイム更新を実現したと公表しています
- Proficy 2026は「クラウドネイティブなオンプレミス展開」という表現を採用し、高可用性構成を改善したと公表しています
つまり、「アプリケーションサーバを二重化する」という従来型の冗長化だけでなく、エッジ側に実行機能を残して中央が落ちても止まらない構成が選択肢に入ってきました。ただしこれは製品選定時に決まる話で、稼働後に後付けするのは困難です。
訓練は「システムを止める」のではなく「使わせない」
BCP訓練でサーバを実際に停止させるのはリスクが高く、たいてい実施されないまま形骸化します。代わりに有効なのは、1シフトだけMESの端末をログインさせない運用訓練です。
- 紙の作業指示書は最新版が印刷できるか
- 実績記録票の様式は現在の工程と一致しているか
- ロット番号の採番を人が行えるか（採番ルールを知っている人が現場にいるか）
- 出荷を止める判断を誰が下すか
この4点だけで、たいていの工場は課題が2桁見つかります。システムの復旧手順より先に、こちらを固めるほうが投資対効果は高くなります。
よくある質問
クラウド型MESならBCPを考えなくてよいのですか？
いいえ。クラウド事業者がインフラの可用性を担保しても、回線障害と、自社側の端末・ネットワークの障害は残ります。むしろクラウド型では「回線が切れたら現場が何もできない」というリスクが集中するため、オフライン時の縮退運転設計はオンプレミス型より重要になります。契約時にSLA上の稼働率とサービスクレジットを確認しつつ、それとは別に自社側の縮退手順を持ってください。
バックアップからの復元で、ERPとの整合はどうなりますか？
ここが最も厄介な部分です。MESを障害前の時点へ戻すと、その後にERPへ送信済みの実績・出来高・在庫移動が二重計上または欠落します。設計時に、連携メッセージに冪等性（同じメッセージを再送しても結果が変わらない性質）を持たせるか、再送区間を特定できるようにIDと送信ログを残しておく必要があります。これは復旧時ではなくMES-ERP連携の設計の段階で決める論点です。
どのくらいの頻度でバックアップを取るべきですか？
データ種別で分けてください。マスタは変更時＋日次、実績・仕掛はトランザクションログを継続的に退避（分単位のRPO）、設備収集データはヒストリアン側の保持期間を確認したうえで判断、が基本形です。全体を一律で「日次フル」にすると、仕掛データのRPOが24時間になり、障害時に現物との突合が事実上不可能になります。
