ある倉庫のWCSは1日に4,000件以上のアラームを発報した。保全技術者はそのまま音をミュートした。
それは2019年、シカゴ郊外の300,000平方フィートの自動化施設で、新しいソートラインを立ち上げたばかりの頃だった。WCS（倉庫制御システム）はコンベヤ、スキャン、インダクト合流、仕分けを制御していた——数百個の光電センサー、数十台のモーター、100を超える通信ノードがあり、それぞれが状態変化のたびに管制室へアラームを送ってくる。粉塵で目が潰れた光電センサー：アラーム1件。モーター電流のちらつき：アラーム1件。200ミリ秒遅れて到着したPLCのハートビート：アラーム1件。1日に4,000件以上、どんな画面でもスクロールしきれない量だ。
アラームが多すぎると、人は無視することを覚える。危険なのは誤報ではない——4,000件の中に埋もれて誰も気づかない本物のアラームだ。その倉庫では後にソーターが詰まった。アラームは15分前に発報していた。管制室の誰も気づかず、ラインの半分が40分間停止して逆流した。私はたまたまその日現場にいて、保全リーダーにこう言われた：「見ていないわけじゃない。見ても意味がないんだ。」
これがアラームフラッディングだ。人を増やしても解決しない。解決するのは優先順位付けと根本原因への集約だ。
5段階は忘れろ。3段階で十分だ。
多くのWCSベンダーは4段階か5段階の深刻度レベルを出荷時に搭載している：クリティカル、メジャー、マイナー、ワーニング、インフォ。精密に聞こえる。しかし実際には、シフト中の誰も5段階の違いを覚えていないので、すべてがひとまとめに扱われる。
私は3つ使う：
**Fatal（致命的）：ラインを止めるか、安全に関わる。**モーター過負荷トリップ、非常停止の押下、安全ライトカーテンの遮断、メインPLC通信の喪失。これらには音、大画面ポップアップ、そして15分以内に誰も確認しなければ自動電話発信が付く。私のルール：1日に3件を超えるfatalアラームは、アラームシステムではなく設備に問題があるということだ。
**生産影響（Production-impacting）：ラインは動くが遅い。**シュート満杯で自動再ルート、スキャン率が95%を下回る、コンベヤセクションの定格低下運転。これらは管制室の画面と当直の電話に送られる——サイレンは鳴らさない。シフトは1時間以内に対応か記録をしなければならない。
**Advisory（参考情報）：ログのみ、誰の邪魔もしない。**光電センサーの単発誤動作1回、通信ノードの再接続成功1回、モーター電流の短いふらつき。この層は総量の90%以上を占める。その価値は事後分析だけだ。誰の画面にも表示されてはならない。
深刻度の私のテストは一つだけ：このアラームを誰も見なかったら、2時間以内に金銭的な問題になるか？Yesなら上位2層、Noならadvisoryだ。
シカゴのその施設では、2週間かけて4,000件以上のアラームをその基準で再格付けした。結果：fatal 11件、生産影響 87件、advisory 3,900件以上。技術者は音を再びオンにした——今や音を立てるアラームはどれも、立ち上がる価値があったからだ。
5件のアラーム、1個の曲がった光電センサー
優先順位付けは「全部読めない」を解決する。集約は「全部直せない」を解決する。
ある夜勤で、管制室は1時間に200件以上のアラームで点灯した：ゾーンAのスキャン失敗、ゾーンBの合流タイムアウト、ゾーンCのモーター過負荷、ゾーンDの通信ジッター、ゾーンEの荷物滞留。2人の技術者が一晩中走り回った。ラインは足を引きずり続けた。夜明けにフロアを歩き、5種類のアラームがすべて1か所を指しているのを見つけた：合流ポイント3の光電センサーが、パレットにぶつかって3ミリメートル曲がっていた。曲がった目、狂ったスキャンタイミング；狂ったタイミング、混乱した合流；混乱した合流、唸るモーター；唸るモーター、不安定な通信。緩んだネジ1本、200件のアラーム。
これがWCSアラームに関する最もよくある真実だ：**アラームはデバイスごとに発報するが、故障は因果の連鎖に沿って伝播する。**1件のアラームは1台のデバイスに対応するが、1つの故障は連鎖の下流でアラームの連なりを爆発させる。
私の集約手法は荒っぽいが効く：毎日シフト終了前に、その日のアラームを設備の場所と時間ウィンドウでクラスタリングする。10分以内に同じエリアで3種類以上の異なるアラーム——1件ずつ直すな。そのエリアを見に行け。おそらく根本原因は1つだ。保全には「アラーム家系図」も作ってもらった：どの光電センサーが曲がるとどの下流アラームが出るか。3か月後には、シフトのクルーはアラームの組み合わせだけで根本原因を推測できるようになった。平均特定時間は40分から10分未満に短縮された。
そして厳しいルールが一つ：**同じデバイスが24時間で20件以上のadvisoryアラームを発報したら、自動的に生産影響へエスカレーションする。**光電センサーの単発誤動作は粉塵だ。毎日誤動作するのは緩みか寿命だ。「advisory」を慢性化させてはならない。
MTTRが意味を持つのは優先順位付けの後だけだ
MTTR（平均修復時間）は多くの倉庫でKPIになっているが、アラームの優先順位付けの前は、その数字は虚構だ。4,000件のアラームに3,900件のadvisoryが混ざっていれば、MTTRは素晴らしく見える——advisoryは「解決」が速い（一瞥して却下）からだ。本物が壊れたとき、MTTRは何も教えてくれない。
優先順位付けの後は、MTTRを分けて追跡する：fatalは単独で、生産影響は単独で、advisoryは追跡しない。シカゴの現場では、優先順位付け前のブレンドMTTRは22分——見た目は良かった。分けてみると、fatalアラームの真のMTTRは55分だった。そもそも誰もそれらのアラームを迅速に見ていなかったからだ。優先順位付けから3か月後、fatalのMTTRは15分未満になった。クルーが速くなったのではない。アラームがついに正しい人々に届くようになったのだ。
アラームとMTTRの連携のために私は3つのことだけやる：fatalアラームは自動で作業指示書を作成してタイマーを開始する；生産影響アラームは対応期限を過ぎて未処理なら自動エスカレーションする；そして毎週月曜に3層の件数とMTTRを並べて比較する——件数が上がるのにMTTRが横ばいなら、深刻度の閾値が甘くなっている可能性が高い。
スターターチェックリスト：第1週の5つのこと
あなたのWCSがアラームに溺れているなら、大規模プロジェクトは飛ばそう。まずこの5つをやる：
- **直近7日間のアラームを件数順でエクスポートする。**上位20の発生源が通常は全体の80%を占める。まずそこを潰すのが最速の勝利だ。
- **「advisoryはログのみ」を最初に定着させる。**最もROIの高い一手だ——画面を片付けるのに1日。注意：ミュートするのはプッシュであって記録ではない。すべてのログを残せ。
- **fatalアラームに本物のエスカレーションパスを与える。**音＋大画面＋未確認15分後の自動電話。エスカレーションのない優先順位付けは飾りだ。
- **アラーム家系図を始める。**最も多い5つのアラーム組み合わせから始め、1か月で20まで広げる。保全チームが持つ最も価値のある知識資産になる。
- **上位10の発生源を毎週レビューする。**2週連続でリストに載る同じ光電センサーは「誤報」ではない——交換時期だ。15分、トップ10だけ、アクションだけ。
最後に一つの判断：WCSのアラームフラッディングは、決して技術の問題ではない。マネジメントの問題だ。4,000件のアラームのうち、3,900件はシステムの独り言で、100件が真実を語っている。あなたの仕事はシステムを黙らせることではない——真実を聞こえるようにすることだ。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
