「何分止まったか」ではなく「どの状態にいたか」を残す
ダウンタイム記録機能を「停止時間を集計する機能」と理解していると、設計を必ず間違えます。MESが残すべきなのは停止時間という量ではなく、設備が時間軸上でどの状態にいたかという連続した履歴です。
停止時間は状態履歴から後で計算できますが、逆はできません。「先月のライン3は合計47時間停止」という数字だけが残っていると、その47時間のうち何時間が段取り替えで、何時間が材料待ちで、何時間が本当の故障だったかを後から復元する手段がありません。そして改善の議論に使えるのは、常に後者の内訳のほうです。
状態履歴として持つべき最小の属性は次の5つです。
- 開始時刻と終了時刻（ミリ秒でなくてよいが、秒精度は必要）
- 状態区分（稼働／計画停止／非計画停止／段取り／空転／未通電）
- 停止コード（後述の階層構造を持つ）
- 原因の帰属先（設備／材料／人／品質／上流工程／外部要因）
- 確定者と確定時刻（自動検知のままか、人が分類し直したか）
最後の1つを設計から落とす例が非常に多いのですが、これがないと「センサが自動で付けた分類」と「班長が後から直した分類」が混ざり、データの信頼度を後から評価できなくなります。
停止が記録されないのは3つの経路のどれか
停止データが実態と合わない工場を調べると、原因はほぼ次の3つに収束します。
| 経路 | 起きていること | 対処の方向 |
|---|---|---|
| 未検知 | 設備信号が取れず、そもそも停止イベントが発生しない | 稼働信号の取得点を見直す。旧式機はサイクル信号や電流値から間接検知する |
| 未分類 | 停止は検知されたが、コードが「その他」に落ちている | コード体系の粒度と入力導線の問題。しきい値と選択UIを見直す |
| 遅延入力 | 翌日や週末にまとめて入力され、記憶で埋められている | 分類の締め時間をシフト単位で強制し、未分類件数を管理指標にする |
このうち改善効果がいちばん大きいのは未分類です。稼働率が悪いラインほど「その他」の比率が高く、そして「その他」が3割を超えたデータは改善のインプットになりません。
設計で決めること：しきい値・階層・帰属
最小停止時間しきい値（マイクロストップの扱い）
何秒以上の停止を「停止イベント」として記録するか。この1つの数字が、データ量・現場の入力負荷・OEEの数値のすべてを左右します。
しきい値を5秒に設定すれば実態に近づきますが、高速ラインでは1シフトあたり数百件の停止イベントが発生し、そのすべてに分類を求めると現場は入力を放棄します。逆に180秒にすると、チョコ停の累積という高速ラインで最も重い損失が丸ごと不可視になります。
現実的な設計は、しきい値を2段構えにすることです。第1しきい値（例：10秒）を超えたら停止イベントとして自動記録し、第2しきい値（例：120秒）を超えたものだけ人による分類入力を必須にする。10〜120秒の帯はコード未入力のまま「短時間停止」として量だけ集計し、頻度の高い設備を別途掘り下げます。
停止コードの階層
停止コードは必ず3階層で設計します。第1階層は大分類（設備／材料／人／品質／上流／外部）で、これは後から変えられません。第2階層は機構・工程単位、第3階層は現象です。
第3階層は運用しながら増えていく前提で作ります。逆に第1階層に「その他」を置くと、そこにすべてが流れ込んで体系が死にます。第1階層は必ず選ばせ、「その他」は第3階層にだけ許すのが定石です。この考え方は不良コード体系の設計と同じで、後から変えられない層をどこに置くかという判断です。
帰属先とOEEの関係
同じ「材料待ち20分」でも、それを設備の損失に数えるか、上流工程の損失に数えるかで、ラインのOEEは変わります。ISO 22400-2:2014（Automation systems and integration — Key performance indicators for manufacturing operations management — Part 2）は、稼働時間・計画停止時間・実績生産時間といった時間要素の定義を与えていますが、どの停止を計画停止に含めるかという運用上の線引きまでは決めてくれません。
したがって「計画停止に何を入れるか」は、導入プロジェクトが決めて文書化する事項です。ここを曖昧にしたまま複数拠点に展開すると、拠点間のOEE比較が原理的に成立しなくなります。詳しくはOEEの算出ロジックで扱います。
よくある実装の失敗
失敗1：停止コードを部門ごとに作らせた。 保全部と製造部が別々にコード表を作り、同じ現象に別のコードが存在する状態になります。コード表の所有者は1人（1部門）に限定します。
失敗2：停止の「終了」を記録していない。 開始だけを押させて、復旧はサイクル再開で自動判定する設計にすると、試運転や空打ちの分だけ停止時間が短く出ます。復旧の判定条件は、良品カウントの再開に紐づけるのが安全です。
失敗3：1つの停止に原因が1つしか付けられない。 実際の長時間停止は「故障で止まり、部品がなく、応援者も来ない」という複合構造をとります。主原因1つ＋副次要因を複数持てるデータモデルにしておくと、後年の分析の幅が大きく変わります。
失敗4：停止データの修正が痕跡なく行われる。 班長が分類を変えたことが残らないと、データの信頼度が測れません。規制産業でなくても、停止データの変更履歴は残す価値があります（監査証跡の考え方をそのまま適用できます）。
製品による実装差
停止管理はどのMESにもありますが、実装の思想はかなり分かれます。
- 設備稼働監視系の出自を持つ製品（Proficy Smart Factory MES、Epicor Advanced MES、Shoplogix、Evocon など）は、設備信号からの自動状態遷移と短時間停止の扱いが作り込まれています。しきい値の段構えも標準機能として持っていることが多い。
- MOM統合系の製品（DELMIA Apriso、Opcenter Execution、AVEVA MES など）は、停止を「工程実績のイベント」として扱い、保全モジュールの作業指図や品質の不適合と同じデータモデル上でつなぎます。停止からそのまま保全依頼を起票する導線が作りやすい。
- コネクテッドワーカー系（Tulip、Redzone、L2L など）は、停止の記録より「停止時に誰が何をしたか」の記録に寄っています。
選定時に確認すべきは機能の有無ではなく、しきい値と停止コード階層が設定で変更できるか、コードの追加に開発が必要かです。ここがハードコードされている製品は、運用開始から半年後に必ず問題になります。
よくある質問
停止コードは何個くらいが適正ですか？
第3階層まで含めて、1ライン種別あたり40〜80個が実務的な上限です。それ以上になると現場が選べなくなり、上位のよく使うコードに集中します。逆に20個を切ると、分析時に「設備故障」の中身が分からず掘り下げられません。運用開始後6か月で使用実績ゼロのコードを削る棚卸しを予定に入れておくのが有効です。
チョコ停（短時間停止）はOEEのどの損失に入れるべきですか？
一般的な区分では、短時間停止と空転は「性能稼働率」の損失として扱い、可用性（時間稼働率）の損失には入れません。ただしこれは設定したしきい値と表裏一体です。しきい値を10秒にすればチョコ停の多くは性能損失側に残り、しきい値を5分にすれば停止イベントとして可用性損失に計上されます。どちらが正しいかではなく、拠点間で同じにすることが重要です。
古い設備で稼働信号が取れない場合、どこから始めればよいですか？
まず「稼働している／していない」の2値だけを取ることから始めます。主軸モータの電流値、油圧ポンプの動作、パトライトの点灯状態、光電センサによるワーク通過など、外付けで取れる代替信号は複数あります。停止理由の分類はしばらく手入力で構いません。分類コード体系の運用を先に固めておけば、後から信号取得を追加したときにデータが連続します。詳しくは設備接続の現実で扱います。
