コンテキストのない設備データはただのノイズ：停止理由、状態モデル、データ品質
DBR77 Team · 公開日
設備データが役に立つのは、すべての信号が全員の合意した「状態」に変換され、すべての停止に理由が付いたときです。設備の状態モデルと停止理由コードがなければ、「停止」という信号だけでは、材料待ちなのか、段取り替えなのか、故障なのかが分かりません。
生の信号が情報にならない理由
PLCのビットや電流センサーが教えてくれるのは、設備がサイクルを回しているかどうかだけです。計画清掃も、詰まりも、投入側の材料切れも、生データ上はまったく同じに見えます。
コンテキストがなければ、停止のパレート図で一番大きな棒は「不明」になり、誰もそれに対して手を打てません。
ある段ボール包装ラインでは、停止した瞬間に2秒で理由を入力するようにしたことで「不明」がパレート図から消え、設備状態のリアルタイム表示や担当者が決まったアラートと合わせて、停止への平均対応時間を24分から9分に短縮することにつながりました。
シンプルな設備状態モデル
状態モデルとは、すべての設備が取りうる状態を短く固定したリストにし、それぞれに一つの定義を与えたものです。業界標準はさらに踏み込んでいます。OMACのPackMLモデルはISAによってTR88.00.02として採用され、メーカーをまたいで設備の状態を統一しています。既存設備（ブラウンフィールド）のラインを監視する目的なら、通常は7つの状態で十分です。
| 状態 | 定義 | 検知方法 | OEEのロスになるか |
|---|---|---|---|
| 稼働 | 理想速度またはそれに近い速度で生産中 | サイクル信号またはカウント信号が増加 | ならない。ただしサイクルが遅い場合は性能ロス |
| アイドル（チョコ停） | オペレーターがすぐに解消する短い停止 | 数サイクル分以上サイクルがなく、理由入力の閾値未満 | なる。性能ロス |
| 計画外停止 | 閾値を超える故障、詰まり、異常 | 閾値を超えてサイクルがなく、計画イベントも発生していない | なる。可用性ロス |
| 段取り替え | 次の品種・仕様への切り替え | オペレーターがタブレットで開始する、または指図が切り替わる | なる。可用性ロス |
| 計画停止 | 予定時間内の清掃、計画保全、点検 | オペレーターが計画理由から選択、またはスケジュールから取得 | なる。可用性ロス |
| 待ち／詰まり | 設備は準備できているが、前工程から投入がない、または後工程に空きがない | バッファセンサーやPLCフラグ、または理由の選択 | なる。可用性ロス（外部要因としてタグ付け） |
| 計画なし | 生産予定なし：休憩、シフトなし、受注なし | シフトカレンダー | ならない。計画生産時間から除外 |
OEEの列はVorneの定義に従っています。計画生産時間から除外するのは生産する意図がない時間だけで、6大ロスでは段取りを可用性ロス、チョコ停を性能ロスとして扱います。計画保全を除外する工場もありますが、どちらを選んでも、全体で統一して適用すれば問題ありません。
オペレーターが実際に使う停止理由コードの設計
状態は設備が止まったことを示し、その理由を説明するのが停止理由です。良い理由リストは、2秒で選べるほど短く、すぐに手を打てるほど具体的です。
- 設備の種類ごとに10〜15の理由。 リストが長いと、最後は「その他」に行き着きます。プレスとパレタイザーには別のリストが必要です。
- オペレーターの言葉で。 「フィルム破れ」「接着剤ノズル詰まり」のように書きます。ERPからコピーした原価センターのコードは設備の前では機能しません。
- 階層は最大2段階。 カテゴリー（機械、材料、品質、運用）と具体的な理由です。
- 明確な閾値。 Vorneは方針の例として、2分を超える停止にはすべて理由を付けることを挙げています。それより短い停止はチョコ停として数えます。
- 停止したその場で入力。 原因がまだ明らかなうちに、オペレーターが設備横のタブレットで理由を選びます。オペレーターアプリはそのために作られています。
リストは毎月見直してください。「その他」が停止時間の数%を超えて増えているなら、オペレーターは理由が足りないと伝えているのです。
シフト間で定義をそろえる
データの価値が最も早く失われるのは、シフトごとに同じ事象を別の言葉で記録するときです。夜勤は詰まりを「機械」として記録し、朝勤は「材料」として記録する。1か月後、一つの大きな問題がパレート図上では半分の大きさの問題二つとして表れます。
状態モデルと理由リストを文書化し、項目ごとに1文の定義を書いてください。すべてのシフトを同じ版で教育します。定義の変更は決まった日にだけ行い、変更を記録しておけば、変更前後の傾向を比較できます。
これは工場レベルでも同じです。ISA-95の目的の一つは、生産システムと業務システムの共通用語です。一つの工場における実践的な形は、すべてのシフトとシステムが使う一つの辞書です。DBR77 IIoTで状態、理由、アラートがどう組み合わさるかはモジュールのページで紹介しています。
展開前のデータ品質チェック
あるラインの設定を次の5ラインにコピーする前に、データが正しいことを確認してください。1ラインでは小さな誤差も、工場全体では何倍にもなります。
- 欠けている状態。 シフトごとにすべての状態の時間を合計します。シフト全体の時間をカバーしていなければ、信号が途切れているか、定義されていない状態があります。
- 誤った理想サイクルタイム。 Vorneによれば、性能が100%を超える場合、たいていは理想サイクルタイムが長すぎる設定になっています。主力品だけでなく、すべての品目を確認してください。
- 時刻のずれ。 エッジデバイス、PLC、サーバーの時刻が合っていないと、停止が別のシフトに記録され、対応時間も誤ります。たとえばNTPで時刻を同期させます。
- 「不明」と「その他」。 停止時間に占める割合を毎週追跡します。割合が増えているなら、理由リストか習慣のどちらかを直す必要があります。
そもそもどの信号を集めるべきかについては、設備から収集すべきデータをご覧ください。
コンテキストが効果を生む場面
状態と理由が整っていれば、合意された事象から計算されるのでリアルタイムOEEを信頼でき、シフト引き継ぎもデータから組み立てられます。
設備信号がまったくない手作業工程では、カメラが状態を提供できます。IRIS Vision AIレイヤーは、設備に配線することなくサイクルと人の在席を検知します。
よくある質問
設備状態モデルとは何ですか？
稼働、アイドル、計画外停止、段取り替えなど、設備が取りうる状態の固定リストで、それぞれに一つの定義と一つの検知ルールがあります。生の信号を、設備やシフトをまたいで比較できる事象に変換します。
停止理由コードは設備ごとにいくつ必要ですか？
通常は設備の種類ごとに10〜15個で、オペレーターが使う言葉で書きます。リストが長いと「その他」が増えます。毎月見直し、本当に抜けがあるときだけ理由を追加してください。
計画停止はOEEのロスに含まれますか？
Vorneの定義では含まれます。計画生産時間から除外されるのは、休憩のように生産する意図がない時間だけです。段取り替え、清掃、計画保全は可用性を下げます。
他のラインに展開する前に何を確認すべきですか？
状態がシフト全体の時間をカバーしていること、すべての品目で理想サイクルタイムが正しいこと、すべての時計が同期していること、そして「不明」が停止時間のごく一部にとどまっていることを確認してください。
まとめ
実践的な最初の一歩は、1ラインでの「欠けている状態」のチェックです。1シフト分の状態の時間を合計してシフト全体をカバーしているかを確認し、次に停止時間のうちどれだけが「不明」と「その他」に入っているかを見てください。この2つの数字から、設定を次のラインにコピーする前に、状態モデルと理由リストのどちらに手直しが必要かが分かります。
出典
- Vorne, The Six Big Losses, 2026
- Vorne, Calculating OEE, 2026
- OMAC, PackML, 2026
- ISA, ISA-95 standard, 2026
- IETF, RFC 5905: Network Time Protocol Version 4, 2010
- DBR77 IIoTパイロットデータ、段ボール包装ライン（顧客名非公開）、2026