アンドン応答のクローズドループ：異常呼び出しから振り返りと改善へ

アンドンは信号灯ではなく、イベントの状態遷移チェーンである

従来の信号灯は異常を素早く知らせるのに有効ですが、その後の受付、処置、完了の記録がなければ、「誰かが見た可能性がある」ことしか示せません。クローズドループ型のアンドンは呼び出しごとに一意のイベントを生成し、発生場所、設備、作業指示または製品のコンテキスト、呼び出し種別、現在の責任者を関連付けます。

状態設計は状態数を増やすことではなく、実際の現場作業を反映すべきです。未受付、受付済み、処置中、連携待ち、復旧済み、完了などの状態には明確な遷移条件が必要です。暫定復旧と根本原因の解消を区別しなければ、イベントの完了が単なる計時停止になってしまいます。

異常分類はコードの積み増しではなく、責任者に対応させる

異常分類では、設備、品質、資材、工程、人員、安全に関する呼び出しなど、現場で実際に頻発する場面を優先的にカバーすべきです。各分類には、既定の応答グループ、必要に応じた連携グループ、エスカレーション条件を設定しなければならず、色分けだけでは不十分です。

設備の自動アラームと人手によるアンドン呼び出しも区別する必要があります。PLCの故障コードはイベントを起動できますが、業務上の原因は現場で確認する必要があります。1つの根本原因から複数の設備信号が出ることもあるため、分析段階で関連付けて集約すべきです。複数の通知で別々の担当者に重複出動させてはいけません。

応答速度を論じる前に、計時の意味を定義する

一般的な計時には、呼び出しから受付まで、呼び出しから到着まで、到着から復旧まで、呼び出しから完了までがあります。それぞれ、引き受け、応答、処置、根本原因管理を表します。合計時間だけを残しても、ボトルネックが人員の手配、部品待ち、技術的処置、承認のどこにあるか判断できません。

計時の一時停止には厳格なルールが必要です。部品や品質判定の待ちは独立した状態にできますが、応答指標を見栄えよくするために恣意的に使うべきではありません。シフトをまたぐ場合、夜間、無人時間帯の責任移転も明確にする必要があります。状態を修正しても元のタイムスタンプを上書きしてはいけません。

• 発生時刻：可能な限り設備またはシステムのイベント時刻を使い、手動呼び出しでは入力時刻を保持する。
• 受付時刻：メッセージの一斉送信ではなく、特定の責任者が引き受けを確認した時刻とする。
• 到着時刻：現場作業または承認された遠隔応答を実際に開始した時刻とし、定義を統一する。
• 復旧時刻：ラインまたは設備が規定機能を回復したと確認した時刻であり、恒久修理を意味しない。
• 完了時刻：処置記録と必要な原因確認が終わった時刻とし、その後の改善は別タスクにできる。

エスカレーションは催促ではなく、リスクと資源を扱う仕組み

エスカレーション条件には、イベント等級、経過時間、影響範囲、再発状況を組み合わせられます。条件に達したら、イベントと既存の処置コンテキストを一緒に引き継ぎ、新しい責任者がすべての情報を聞き直す事態を防ぐべきです。エスカレーションしても、元の責任者が直ちに免責されるわけではありません。

通知チャネルは工場のネットワークと端末環境に合わせ、現場の音・光信号、LED、Web画面、承認されたモバイルメッセージなどを採用できます。重要なのはチャネル数ではなく、到達、引き受け、失敗時の代替手段を検証できることです。メッセージの送信成功は、担当者が応答したことを意味しません。

SCADA、OEE、保全プロセスとの連携方法

SCADAは設備状態と生のアラームを提供し、アンドンは異常を担当者の応答プロセスへ送り、OEEは一貫した停止イベントを使って効率損失を分析します。保全プロセスは、さらなる修理や改善が必要なタスクを引き受けます。4者はイベント識別子を共有できますが、それぞれの主責と完了条件は異なります。

インターフェースでは双方向の上書きを避ける必要があります。設備をリセットしてもアンドンの処置記録を自動削除すべきではなく、アンドンを完了してもOEEの元状態を自動的に書き換えるべきではありません。既存の保全システムがある場合、アンドンは独立したTPM製品を新たに構築するのではなく、ルールに基づいてタスクを作成または関連付けます。

• 設備イベントは事実を示し、業務上の原因は権限を持つ担当者が補足する。
• アンドンとOEEは開始・終了・原因の対応関係を共有しつつ、それぞれの分析定義を保持する。
• 修理が必要なイベントには、設備、故障モード、処置、部品などの情報を関連付ける。
• 繰り返しの異常を改善リストへ入れ、対策を検証してから標準としきい値を更新する。

実際の異常を使った訓練で段階的に導入する

導入時は、まず1つのエリアと頻度の高い少数の異常を選び、呼び出しから復旧までの全過程を検証してから、自動起動、モバイル通知、分析へ拡大します。運用開始前には、正常稼働、未受付、連携待ち、シフト交代、ネットワーク切断、アラーム反復の各シナリオを個別に訓練すべきです。

振り返り指標には、件数、応答チェーン、再発、改善の実行を含め、平均時間だけで評価することを避けます。平均値は極端なイベントを隠し、早すぎる完了を誘発します。実際のイベント分布と主な損失原因まで確認して初めて、有効な改善につながります。

• 異常の棚卸し：同義の種別を統合し、種類ごとの責任者と既定の処置入り口を明確にする。
• 状態の定義：受付、到着、復旧、完了について観察可能な判断基準を記述する。
• シナリオの合同検証：設備、人員、ネットワーク、既存システムに異常が起きた際の挙動を確認する。
• 班での試行：呼び出しやすさ、通知の正確さ、記録が無駄な負担を増やしていないかを確認する。
• 定期振り返り：順位を伝えるだけでなく、繰り返しの問題を解決し、振り分けと標準を調整する。