検知する機能と、防止する機能は別物である
工程条件をすべて記録している工場でも、不良は出ます。記録は事後に原因を追うためのもので、その場で作業を止める機能ではないからです。
MESA-11モデルが「プロセス管理（Process Management）」を独立した機能として立てているのは、記録とは別に「成立させない」仕組みが要るからです。ISA-95が2025年4月に発行した Part 1 の改訂版（ANSI/ISA-95.00.01-2025）でも、エンタープライズ領域と製造／制御領域の境界の明確化が改訂の柱に挙げられています。どの判断をどの層で行うのかを曖昧にしたままでは、この機能は設計できません。
現場から見た違いはこうです。検知型は「異常が出たら記録して通知する」。防止型は「条件を満たさなければ、そもそも次のボタンが押せない」。後者が実装できているかどうかが、MESが品質に効いているかどうかの実質的な分かれ目になります。
「止める」条件は4種類に整理できる
止める理由は無数にあるように見えて、対象で分ければ4つです。要件定義では、この4分類ごとに条件を洗い出すと漏れが出にくくなります。
| 分類 | 止める条件の例 | 判定に必要な情報 | よくある未実装 |
|---|---|---|---|
| 材料 | 指定外の品番、期限切れ、未検査ロット、他オーダーへの引当済み | ロット状態、有効期限、検査結果 | 副資材・補修材が対象外になっている |
| 設備 | 保全期限超過、段取り未完了、前回異常の未解除、校正切れ測定器 | 設備状態、保全予定、校正期限 | 測定器が設備として登録されていない |
| 作業者 | 資格なし、教育未完了、改訂版の未読 | 力量マスタ、教育履歴、文書の版 | 応援者・派遣に判定が効かない |
| 条件・順序 | 前工程未完了、規格外の設定値、工程飛ばし、重複着手 | 工程順序、設定値の規格、実績状態 | 「戻り工程」が想定されていない |
このうち4番目の「順序」が最も設計が甘くなります。工程飛ばしを止めるのは容易ですが、手直しのための戻り、検査のための一時的な工程外への持ち出し、並行工程の合流といった正当な例外を許しつつ不正な順序だけを止めるには、工程モデルそのものの表現力が要ります。「工程は一直線に進む」という前提で設計すると、稼働後に必ず例外運用が発生します。
どの層で止めるかは、必要な応答時間で決まる
同じ「止める」でも、MESで止められるものと、制御層でなければ止められないものがあります。判断基準は応答時間です。
MESが得意なのは「作業の切れ目」で止めることです。着手前、工程完了時、次工程への引き渡し時。この瞬間に条件を照合して可否を返すのは、ネットワークを経由しても十分に間に合います。
一方、加工中の圧力が上限を超えた瞬間に設備を止めるような判断は、MESの守備範囲ではありません。ネットワーク遅延とアプリケーション処理を挟む以上、確定的な応答時間を保証できないからです。
オーバーライドの設計こそが本体である
止める仕組みを作ったあと、必ず現場から出てくるのが「どうしても進めなければならない場面がある」という声です。これは正しい指摘です。止める機能の価値は、例外をどう扱うかで決まります。
設計すべき項目は5つです。
- 誰が解除できるか：作業者本人か、班長か、品質責任者か。条件の種類ごとに権限者を変えるべきです。材料の期限切れは品質責任者、順序の変更は班長、というように分けます
- どこまで解除できるか：1回だけの解除か、そのロット全体か、そのシフト全体か。範囲を広く取れる解除は、事実上その条件を無効化します
- 理由の記録：自由記述ではなく、選択式の理由コードを用意します。集計できなければ、解除が多発している条件を見つけられません
- 有効期限：解除の効果がいつ切れるか。「一時解除」が半年続いている状態を防ぎます
- 通知：解除が発生したことを、誰にリアルタイムで知らせるか（アンドンと通知・エスカレーション）
権限設計を怠ると、現場は必ず抜け道を作ります。他人のIDで操作する、条件判定のない別画面から進める、いったん工程を取り消して入れ直す。抜け道が使われている状態は、記録が実態と乖離しているという意味で、統制がないより悪い状態です。
実装の失敗と、製品による違い
失敗1：条件を全部「エラーで止める」にする。 稼働直後に大量の停止が発生し、現場が業務を回せなくなります。条件ごとに「停止」「承認を求める」「警告のみ」の3段階を割り当て、稼働初期は警告中心で始めて段階的に強めるのが安全です。
失敗2：止まった理由が画面に表示されない。 「この作業は開始できません」だけを表示するシステムは、現場に無力感を与えます。どの条件を満たしていないか、どうすれば解決するか、誰に連絡すべきかまでを画面に出します。
失敗3：条件のマスタ変更にIT作業が必要な設計にする。 品質条件は現場と品質部門が日常的に見直すものです。設定変更のたびに開発依頼が必要な構造にすると、条件は更新されなくなります。ただし変更履歴と承認は必須です。
失敗4：バッチ・連続プロセスの特性を無視する。 材料が混ざり、区切りが曖昧なプロセス製造では、ディスクリート前提の「ロット単位で止める」モデルが通用しません。Critical Manufacturingがロットマッチングに対応したバッチ管理を追加しているように、製品側もこの差を意識した機能を持ちます。プロセス系の統制はISA-88のレシピ管理と組み合わせて設計する領域です。
製品差として現れやすいのは、条件のルールをどこまでノーコードで書けるかです。標準機能の設定画面で条件を組み立てられる製品と、スクリプトやカスタム開発が必要な製品では、稼働後の変更速度が大きく変わります。統計的な変動監視を条件に組み込みたい場合は、SPC（統計的工程管理）をMESで回すで扱う管理限界の考え方と接続することになります。Plex／FactoryTalkのようにエッジ実行を前面に出す製品では、条件判定の一部をエッジ側へ寄せられるかどうかも比較軸になります。
よくある質問
稼働直後から厳格に止める設定にすべきですか。
おすすめしません。マスタの整備が不完全な状態で厳格な条件を有効にすると、実態としては問題のない作業まで止まり、初期の混乱がそのまま「使えないシステム」という評価に固定されます。実務では、稼働から1〜2か月は警告表示に留め、その間に発生した警告の内容を精査して、①条件が正しく現場が誤っているもの、②条件のほうが現実に合っていないもの、を仕分けます。そのうえで①に該当する条件から順に停止へ切り替えます。
止める条件は何個くらいが適切ですか。
個数に正解はありませんが、「その条件が守られなかったときに何が起きるか」を1文で書けない条件は入れないでください。実務でよく見るのは、条件が数百個あって誰も全体を把握していない状態です。この状態になると、条件同士の矛盾（Aを満たすとBが満たせない）が発生し、現場は解除を常用するようになります。まずは品質影響と法令要求から逆算して10〜30個程度で始め、運用しながら足していくほうが健全です。
オーバーライドの記録は、どのくらいの期間保存すべきですか。
製品の保証期間や規制の記録保存期間に合わせるのが原則です。医薬品や医療機器では法令で保存期間が定められており、自動車部品では顧客との取り決めが基準になります。重要なのは、オーバーライドの記録を工程実績本体と同じ期間・同じ方法で保存することです。実績は10年残るのに解除記録は1年で消える、という設計にすると、後年の調査で「なぜこのロットが規格外のまま進んだのか」を説明できなくなります。
