アンドンが生む本当の資産は「応答時間」
アンドンをMESに載せる目的を「異常を早く知らせること」だと説明すると、ほぼ確実に通知機能の設計になり、ほぼ確実に定着しません。パトライトと構内放送で足りていた工場に、スマートフォンの通知が増えるだけだからです。
MES上のアンドンが紙やランプに対して持つ唯一の優位は、呼び出しから到着までの時間、到着から復旧までの時間が、事象単位で自動的に残ることです。この2つの時間が蓄積されると、次のような議論が初めてデータでできるようになります。
- 保全の応答が遅いのか、そもそも呼ぶのが遅いのか
- 夜勤帯だけ応答時間が3倍になっているのはなぜか
- 応答が速い班と遅い班で、停止時間の差はどれだけ出ているか
- 「人が足りない」という主張は、待ち時間の分布で裏づけられるか
つまりアンドンは通知機能ではなく計測機能です。この理解でスタートすると、設計の優先順位が変わります。まず決めるべきは通知先ではなく、「何をもって呼び出し完了・到着・復旧とするか」という状態の定義です。
標準的な機能構成：イベントからクローズまでの5段
MESのアンドン／通知機能は、製品が違っても次の5つの要素で構成されます。
- イベント発生：作業者の呼び出しボタン、設備アラーム、MESの判定（規格外測定値、資材残量、工程遅延）
- ルール評価：イベント種別・設備・製品・時間帯・重大度から、通知対象と経路を決める
- 通知配信：現場表示（大型モニタ・パトライト）、端末プッシュ、メール、チャット、構内放送、外部システム
- エスカレーション：一定時間内に応答・到着・復旧がない場合、上位へ段階的に広げる
- クローズ：対応者・対処内容・原因コードを記録して終了。停止イベントと突合する
このうち日本の工場で設計が甘くなりがちなのは 2 と 4 です。1と3は製品標準機能で動きますが、2と4は自社の組織と勤務体制を反映しなければならず、標準では決まりません。
設計で決めること
重大度は3段までにする
重大度（Severity）を5段階以上にすると、現場は真ん中しか使わなくなります。実務で機能するのは3段です。
| 重大度 | 定義の軸 | エスカレーション | 応答目標 |
|---|---|---|---|
| S1 | ラインが止まる／安全・品質に即時影響 | 3段まで自動で上がる | 即時 |
| S2 | 稼働は続くが放置すると止まる | 2段まで | シフト内 |
| S3 | 情報共有・改善提案 | 上げない（一覧に溜める） | 翌営業日 |
重要なのは重大度を作業者に選ばせないことです。呼び出しボタンは「材料が来ない」「機械が動かない」「品質がおかしい」という現象で分け、重大度はイベント種別と設備クラスからシステムが決めます。作業者に判断負荷を載せると、全部S1になるか全部S2になります。
宛先はロールで持ち、個人で持たない
通知先を個人アカウントで設定すると、異動・休暇・シフト交代のたびに設定変更が必要になり、半年で実態と乖離します。「第2ライン夜勤の保全当番」というロールに対して通知し、そのロールに誰が入っているかは勤務シフトのマスタが解決する、という二段構えにします。
これができていない工場では、退職した人のスマートフォンに通知が飛び続ける、という状態が普通に発生します。
抑制（デバウンス／サプレッション）を最初から入れる
同一設備・同一コードの連続イベントをどう束ねるかを決めていないと、1つの故障で数十件の通知が飛びます。最低限、次の3つを実装します。
- 同一キーの再通知抑制：同じ設備×同じコードは、未クローズのあいだ再通知しない
- 上位イベントによる下位抑制：ライン停止が発生したら、下流工程の材料待ち通知は抑制する
- 計画停止中の全抑制：段取り替え・保全作業中は通知を止める
よくある実装の失敗
失敗1：全員に通知して「見た人が対応する」運用にした。 責任の所在が消え、誰も動かなくなります（傍観者効果はシステム設計でも起きます）。1つのイベントに対して、第1段の一次責任者は必ず1ロールに絞ってください。
失敗2：応答を「既読」で判定した。 端末の通知を開いただけで階段が止まる設計にすると、時間指標が意味を失います。止められるのは「向かう」または「到着」の明示的な操作だけにします。
失敗3：夜勤・休日のエスカレーション先を決めていない。 平日日勤で設計されたルールが、そのまま夜勤に適用されて第2段の宛先が不在になります。時間帯別の宛先表は、ルール設計の最初に作る成果物です。
失敗4：通知系だけ別ツールに置いた。 チャットツールの通知連携は簡単に作れるので、そこだけ外に出す判断がよく行われます。しかしそうすると呼び出しから到着までの時間がMES側に戻らず、アンドンを入れた本来の目的である応答時間の計測が消えます。通知の送信は外に出してよいが、応答の受信はMESに戻す設計にします。
失敗5：クローズ時の原因入力とダウンタイム分類が二重になった。 呼び出し1件に対して停止イベントが1件対応するなら、原因コードは同じ体系を使い、入力は1回にします。ダウンタイムの記録と分析で設計する停止コード階層をそのまま流用するのが自然です。
製品による実装差と、確認すべき2点
アンドン機能の実装は大きく3つに分かれます。
- 設備監視系の延長として持つ製品：設備アラームからの自動起票が強く、パトライトやスタックライトとの物理連携も標準で持つ。一方で、時間帯別・ロール別のエスカレーションルールは簡素なことが多い。
- MOM統合系の製品（DELMIA Apriso、Opcenter Execution、AVEVA MES など）：呼び出しから保全作業指図の起票、不適合の起票までを同一プロセス上でつなげられる。ルールエンジンの自由度も高いが、設定量が多く実装工数がかかる。
- コネクテッドワーカー系（Tulip、Redzone、L2L、Poka など）：エスカレーションと応答時間の可視化そのものが製品の主機能で、通知UXの完成度が高い。ただし設備側の自動起票は別途接続が必要。
製品選定で確認すべきは次の2点です。第一に、エスカレーションルールを設定画面で変更できるか、開発を伴うか。ルールは運用開始後3か月で必ず変わります。第二に、ネットワーク断や上位サーバ停止時に通知がどうなるか。Rockwellが2026年6月18日に発表したFactoryTalk ResilientEdgeのように、ネットワーク断でも操業継続を明示的に設計要件に掲げる製品も出てきています。工場のWi-Fiが不安定な環境では、この点が実際の稼働率に直結します。
よくある質問
アンドンの呼び出しボタンは、端末とハード押しボタンのどちらがよいですか？
安全・品質に関わるS1相当の呼び出しは、物理ボタンを残すべきです。手袋をしたまま、視線を設備から外さずに押せることが重要だからです。端末アプリは、S2・S3の呼び出しや、呼び出し後の詳細入力（現象の選択、写真添付）に向いています。両方を用意し、どちらから起票しても同じイベントとして扱えるようにするのが実務的な解です。
エスカレーションの時間設定は、どうやって決めればよいですか？
最初は現状の実測から決めます。導入前の1〜2か月、呼び出しと到着の時刻を紙で記録すれば、中央値と第3四分位が出ます。第1段の時間は現状の中央値、第2段は第3四分位あたりに置くのが出発点として妥当です。いきなり理想値（「3分以内に必ず到着」など）を設定すると、ほぼ全件が第2段まで上がり、上位者の通知が飽和して制度が崩壊します。
通知はメールとチャットのどちらを使うべきですか？
S1にメールを使うのは避けてください。到達時間が保証されず、既読管理もできません。S1は現場表示（大型モニタ・パトライト）＋端末プッシュを主経路とし、メールはS3の日次サマリや管理者向けレポートに限定するのが妥当な分担です。チャットツールは到達速度の点では優れていますが、前述のとおり応答の記録がMESに戻る経路を確保します。端末側の要件はモバイル・ハンディ端末対応で扱います。
