RCSアラートの嵐：黙らせるべきAMRアラームと、絶対に見逃してはいけないもの

50台のAMRが動く倉庫では、RCSが1日に何千ものアラートを吐き出すのは珍しくない。スマホに20個のアプリを入れて、それぞれが1時間に10件の通知を送ってくるようなものだ——1週間もすれば、管制室のオペレーターは反射的に全部消すことを覚える。そして本物の故障がノイズに埋もれ、誰にも見られないままになる。

これがアラート疲れだ。病院は10年前にこの問題を解決した。次は倉庫自動化の番だ。

RCSアラートが爆発する理由

RCSはフリートの交通整理係でありディスパッチャーだ——ルート、タスク、充電をさばく。こう考えてみよう：AMRは1台ごとに何十ものセンサーを積んでいる——LiDAR、安全バンパー、エンコーダー、バッテリーのBMS、WiFi無線——それぞれが独自のしきい値を持ち、上向きにイベントを発火する。50台のロボット×何十ものセンサー×24時間：これが原材料だ。

洪水はたいてい3つの場所から来る。

1つ目はロボット層。AMR自身が投げるイベント：バッテリー温度のふらつき、単発の障害物減速、再ローカライゼーション、WiFiローミング。量は多いが、大半は自己回復する。

2つ目はフリート層。RCSが投げるイベント：タスクタイムアウト、経路デッドロック、ゾーン混雑、充電キューの待ち。量は少ないが、1つ1つがスループットに直結する。

3つ目——はっきり言おう——インテグレーターの保身本能だ。運用ではなく責任回避のために設定されたアラートルールで出荷されるプロジェクトは多い：「WiFi信号が-70dBmを下回ったらポップアップ」。このアラートは何の役にも立たず、オペレーターを麻痺させる訓練にしかならない。見せかけの要件には我慢がならない：アラートが多いことは勤勉なことではない。誰も読まない1000件のアラートはゼロと同じだ。

トリアージ：AMRアラームは3段階。それ以上は茶番だ

3段階：P0、P1、P2。分けるのは1つの厳しい線だ：このアラートを誰も見なかったら、ラインは30分以内に止まるか？ 止まるならP0。止まらないがスループットが落ちるならP1。どちらでもなければP2、ログに直行。荒っぽいが、効く。

現場からの2つの話。

2024年後半、独身の日のピークを前に、中国東部のあるEC倉庫は60台のAMRをRCSアラートポリシー工場出荷設定のまま運用していた：全部オン、1日4,000件超のアラート。オペレーターは後でこう言った。「ポップアップを視界の端で見て消すことを覚えた」と。そしてあるロボットのBMSがバッテリー過熱をフラグした——本物のP0だ——「WiFiローミング」と「障害物減速」の何千ものエントリの下に埋もれた。40分以上経って、現場巡回がメイン通路で死んでいるロボットを発見し、ピッキングラインの半分が止まっていた。事後検証は1文で済んだ：アラートがなかったのではない。多すぎて、ないのと同じだったのだ。

逆の例は南にある：40台のAMRを持つ3C倉庫は最初の1か月、「再ローカライゼーション成功」——自己回復イベント——のポップアップを出し続けた。1日800件のアラートのうち700件は良い知らせだった。新しいルール：自己回復はログへ。失敗した回復だけエスカレーションする。ポップアップは1日800件から約60件に減り、オペレーターは再び画面を見るようになった。問題は「アラートが足りない」ことではなかったのだ。

ミュートは削除ではない：アラート調整の3つの落とし穴

レベルは決まった。次はルールのミュートとしきい値調整の実作業だ——そして私が1つずつ少なくとも1つのプロジェクトを飲み込んだのを見てきた3つの落とし穴がある。

落とし穴1：ミュートして忘れる。 ミュートはリスク判断だ。変更記録が必要になる：誰が承認したか、なぜか、いつ期限が切れるか。建物管理に告げずに煙感知器の電池を抜くようなものだ——火事が起きたとき、最初の質問は「電池を抜いたのは誰だ」になる。私のルール：すべてのミュートは承認者とレビュー日を添えて台帳に登録する。期限切れのミュートは自動復元され、再評価を強制する。

落とし穴2：よその倉庫のしきい値をコピーする。 床の平坦度、WiFiカバレッジ、ラック密度——2つの現場が同じになることはない。「障害物減速が1分間に10回を超えたらアラート」はサイトAでは完璧でも、サイトBでは誤報製造機になる。正しい順序：最初の2週間はすべてをログに残しつつ何もプッシュせず、それから自分のデータでしきい値を決める。まず観察、次に立法——逆ではない。

落とし穴3：過剰な重複排除。 件数を減らすために「ナビゲーション失敗」と「タスクタイムアウト」を「AMR異常」1つにまとめるチームがいるが、トラブルシュートで泣くことになる。重複排除するのは、同じロボットで、数分以内の、同じ原因の繰り返しだけにしろ。原因の異なるものは絶対にまとめない——ノイズを重複排除するのであって、情報をではない。

1つのアラートをミュートする前に、この判断マトリクスに通せ：

右上のセルに一言：頻繁かつ深刻なアラートは、システム自体が病んでいるということだ。そこでアラートを調整するのは、重篤な患者に鎮痛剤を与えるようなものだ。

技術パートを締める逆説的な見解を1つ：人は「ミュートすればするほどシステムは危険になる」と思いがちだ。逆だ。ミュートは危険ではない。危険なのは、ミュートされていることを誰も知らないことだ。全部P0のシステムと、アラートのないシステムはまったく同じ死に方をする——誰も見ていないのだ。

では投資は報われたか？1つの数字が教えてくれる：P0アラートが発火してから人間が対応を始めるまでの平均時間だ。これを40分から5分に下げられれば、アラートガバナンスの努力は元を取った。動かなければ、それまでのすべて——トリアージも、ミュートも、重複排除も——茶番だったということだ。

Da Liu（自動化エンジニア）著

英語版からの翻訳。内容に相違がある場合は英語版を優先します。