「災対」と「平時の可用性」を分けて議論する
可用性の議論が噛み合わないプロジェクトでは、たいてい2つの別の話が混ざっています。ひとつは地震・火災・ランサムウェアといったサイトごと失われる事態への備え（DR：災害復旧）で、これはバックアップ・復旧手順・代替運用の話です。本サイトではMESのバックアップとBCPで扱いました。
もうひとつがこの記事の対象で、日常的に起こる部品単位の故障や、パッチ適用などの計画停止で、生産を止めないための設計（HA：高可用性）です。両者は投資の性質が違います。DRは「めったに起きないが起きたら全損」への保険、HAは「年に数回は必ず起きる」事象への恒常的対策です。故障は確率の問題であり、サーバのハードウェア故障、ディスク障害、NW機器の故障、OSのハングは、数年運用すれば必ずどれかを引きます。
HAの目標値は「稼働率99.9%」のような比率よりも、計画停止の枠（月に何時間、いつ取れるか）と無停止で耐えるべき故障の範囲（サーバ1台の故障か、DBごとか）で合意するほうが設計に落ちます。24時間操業の工場では計画停止の枠がそもそも月数時間しか取れないことがあり、この制約が構成をほぼ決めてしまうからです。
冗長化は層ごとに考える──全部やる必要はない
層別に見ると、投資判断の相場観は次のようになります。
- DB層は冗長化の本丸です。データを失うと単なる停止では済まないため、クラスタまたは同期レプリケーション＋自動フェイルオーバーが標準解です。ただしライセンス費・構築費が最も高い層でもあり、ここだけで冗長化予算の過半を使うことが普通です
- アプリケーション層は複数台＋ロードバランサで比較的安価に冗長化できます。セッションの持ち方（切替時に作業中の画面がどうなるか)を製品仕様で確認しておくと、フェイルオーバー時の現場影響を正しく説明できます
- ネットワーク層は最も見落とされる層です。サーバを完全冗長にしても、工場とサーバ室を結ぶスイッチが1台なら、そこが単一障害点（SPOF）です。特に無線端末主体の現場では、AP1台の故障がエリア単位の業務停止になります
- 端末層は冗長化というより予備と手順の問題です。予備端末を何台置くか、故障時に誰がどう切り替えるかを運用設計として決めます
単一障害点は「構成図にないもの」に潜む
SPOFの洗い出しは構成図のレビューで行いますが、経験上、見つかるSPOFの多くは構成図に描かれていない要素です。典型は次の5つです。
| 見落とされやすいSPOF | 何が起きるか |
|---|---|
| ラベルプリンタ・計量器などの周辺機器 | サーバが無事でもラベルが出ず、出荷工程が止まる |
| ライセンスサーバ・認証サーバ（AD等） | MES自体は正常でも誰もログインできない |
| 連携ミドルウェア（ESB・ファイル転送） | 指図が届かず、朝一の生産開始が遅れる |
| DNS・NTP | 名前解決失敗による接続断、時刻ずれによる証跡の混乱 |
| 「詳しい人」 | 障害対応手順が属人化しており、その人の休暇中に復旧が長引く |
最後の項目は冗談ではなく、可用性設計の一部です。フェイルオーバーが自動でも、その後の縮退運転の判断や切り戻しは人の仕事であり、手順書と訓練がなければ冗長構成は完成していません。訓練の設計はバックアップとBCPで述べた「使わせない訓練」と共通です。
計画停止を減らす──無停止更新はコンテナ化で現実になりつつある
故障よりも累積時間が長いのは、実は計画停止です。パッチ適用、バージョンアップ、証明書更新、DBメンテナンス。月2時間の計画停止でも年24時間で、並のハードウェア故障より長くなります。24時間操業では、この枠の確保自体が生産部門との交渉事です。
設計でできることは3つあります。第一に、停止を伴う作業と伴わない作業を製品仕様で仕分けること。AP層が複数台であれば、1台ずつ切り離して更新するローリング方式で無停止にできる作業は多くあります。第二に、DBメンテナンスの自動化と分割。インデックス再構築やアーカイブを小さな単位に分けて日次の低負荷時間帯に流せば、まとまった停止枠が不要になります。第三に、バージョンアップの方式確認。年次アップグレードのたびに終日停止が必要な製品か、段階更新できる製品かは、10年の運用で大きな差になります（バージョンアップ戦略参照）。
この領域では製品側の世代交代も進んでいます。たとえばSiemensは2026年8月14日リリースのOpcenter MES Medical Device 2607で、Kubernetes＋Linuxコンテナ化アーキテクチャによるゼロダウンタイム更新を打ち出しました。コンテナ化されたMESは、更新時に新旧バージョンを並行稼働させて切り替える方式を取れるため、「アップグレード＝計画停止」という前提そのものが崩れ始めています。製品選定時に「更新時の停止時間」を評価項目に入れる価値は、今後さらに上がるとみてよいでしょう。
よくある質問
どこまで冗長化すべきか、費用対効果はどう考えればよいですか？
起点は「MESが1時間止まったときの損失」の見積りです。ラインが完全停止する工程なら停止1時間あたりの損失は機会損失＋復旧の残業代で具体的に計算でき、冗長化投資の上限が見えます。逆に、紙運用で数時間は回せる工程なら、DB層の冗長化までで止めて端末・手順側に投資するほうが合理的です。全層フル冗長が正解なのは、停止即ライン停止かつ24時間操業の場合に限られます。
冗長構成にしたのに障害で止まりました。よくある原因は何ですか？
多い順に、①フェイルオーバーの発動条件が実際の故障モードと合っていない（サーバダウンには反応するが、ハングや性能劣化には反応しない）、②切替のテストを構築時にしか行っておらず、その後の設定変更で切替が壊れていた、③冗長化の外にあるSPOF（本文の表の項目）が原因だった、の3つです。対策は年1回以上の計画切替訓練で、これは冗長構成の「動作確認」を兼ねた最も費用対効果の高い運用です。
古いMESで冗長化されていません。今から何ができますか？
アーキテクチャを変えずにできる順で、①仮想化基盤への移設（仮想化のHA機能でサーバ故障への耐性を追加。アプリ改修不要）、②DBだけのレプリケーション追加、③予備機のコールドスタンバイ＋復旧手順の整備、が現実的な選択肢です。ただし延命投資である以上、老朽MESの延命か刷新かの判断と合わせて、投資回収期間を刷新時期までの残年数で計算してください。
