結論から言うと：AMRがおかしな動きをし始めたら、無実が証明されるまでWiFiが犯人です。 タスク消失、突然の非常停止、理由もなく減速するフリート。AMRベンダーにクレームの電話をする前に、ノートPCを持って問題が起きた通路でpingを打ってみてください。
この罠は3回見ました。毎回、現場は配車アルゴリズムを疑い、次にLiDAR、そしてファームウェアを疑いました。2週間の責任の押し付け合いの末、誰かがようやくネットワークを調べると、ラック列の間の電波デッドゾーン、あるいはローミングハンドオーバーが遅すぎてロボットがタイムアウトを繰り返している。ネットワークを直せば、ロボットの「病気」は一晩で消えます。
二つの実話
2024年3月、中国東部の3PL倉庫、20,000平方メートル強、導入から2週間のAMRが6台。「タスク消失」が1日20回以上。ベンダーのエンジニアが2日間現場に張り付き、配車ログを掘り返し、「おそらく断続的なタスク割り当てロジックの問題」と結論付けました。私はノートPCを持って問題の通路を歩き、pingを打ちました。ラック列の2箇所がAPの電波デッドゾーンで、パケットロスが40パーセントを超えていました。AMRが進入するとハートビートパケットが外に出られず、配車側はロボットが消えたと判断してタスクを引き戻して再割り当てしていた。それが「タスク消失」の正体です。
修正は拍子抜けするほど簡単でした。APを3台移設し、AMRのWiFiカードのローミング積極性を1段階上げる。1週間でクレームはゼロに。去り際のベンダーエンジニアの顔は今でも覚えています。
2025年6月、大手ECフルフィルメントセンター。618セールの直後にAMRを導入。セール前にラックを2段高くしていた。頑丈な金属棚が5 GHzの信号を完全に遮断し、APは以前の高さのまま取り付けられていた。結果：高ラックゾーンに入ったAMRは全台「知能が下がった」ように、減速、停止、時々非常停止。ゾーンを出た瞬間に復活しました。無線ヒートマップ調査をやり直し、APの取付高さをラックの梁より下げ、チャンネルを再計画。ベンダーを巻き込まずに修正できました。
なぜWiFiハンドオーバーがAMRを止めるのか
仕組みは単純です。AMRが移動すると、そのWiFiクライアントはAP間をホップしなければなりません。ターゲットAPを選び、再認証し、再アソシエーションして、データストリームを再開する。調整されていないネットワークでは、このハンドオーバーに数百ミリ秒かかります。802.11r高速ローミングを有効にしていなければ、ハンドオーバーで接続が1分以上切れることも珍しくありません。
そしてAMRベンダーは安全側に倒します。通信タイムアウトが非常停止を引き起こす。つまり目に見えるのは「ロボットの不具合」ですが、病巣はネットワークにあります。さらに悪いことに、倉庫は最悪の無線環境です。金属ラック、フォークリフト充電ベイ、金属シャッターはすべてWiFiキラーであり、倉庫はその3つでいっぱいです。
現場チェックリスト：5つのステップ
これは私がすべてのAMRプロジェクトで導入前夜に使うチェックリストのネットワーク部分の全体です。順に潰していってください。
ステップ1：導入前に現場を調査する。図面を信用しない。
調査ソフト（スマホアプリ級のツールでも可）を持って現場を歩き、電波ヒートマップを生成する。3つを確認する：すべてのAMR走行経路の電波強度、AP間の十分なオーバーラップ（クリーンなハンドオーバー用）、金属ラック裏のデッドゾーンなし。図面のAP位置と現場の現実は10回中8回食い違います。ラックは動いている、APはフォークリフトにぶつけられている、図面にない間仕切り壁が立っている。
ステップ2：3つの鉄則でAP配置を計画する。
取付高さ：信号がAMRのアンテナに見通せるよう、APはラックの梁より低く取り付ける。天井付けはきれいに見えるが、金属ラックは信号を朝食のように食い尽くす。密度：APは多めに。AP1台の追加コストは、AMRライン1時間停止よりはるかに安い。チャンネル計画：隣接APはチャンネルを共有しない、2.4 GHzと5 GHzは別々に計画し、AMRは干渉の少ない5 GHzに置く。
ステップ3：ローミングを調整する。これが核心です。
APで802.11r高速ローミングを有効にし、ハンドオーバーレイテンシを150ミリ秒未満に抑える。次にAMRのWiFiカードのローミング積極性を調整する。「忠実」すぎると死にかけのAPにしがみつく。「浮気」すぎると2台のAP間を行ったり来たりする。私の出発点は中間設定、ハンドオーバー成功率を測って上下1段階ずつ試し、最も安定したものを残す。WiFiカードは機種ごとに挙動が違う。万能設定は存在しない。測定された設定だけがある。
ステップ4：切断が許されない経路には冗長化を。
AMRが幹線を走る、階をまたぐ、ドックドアで働くなど、切断が許されない場所では、デュアルWiFiカードやWiFi＋セルラー フェイルオーバーを検討する。コストはかかる。フリート全体の非常停止1回よりは安い。冗長化は重要経路用、全ロボット用ではない。
ステップ5：導入前夜のチェックリスト＋受入テスト。
導入前夜、このリストを持って現場を歩く：すべてのAMR経路を端から端まで3回ずつ走行し、各APハンドオーバーのタイムスタンプとパケットロスを記録する。次に最悪ケースをシミュレーションする。フォークリフト充電器全台ON、シャッター全閉、シフト開始時の全ハンドセットがWiFi接続。この状態でもう一度全部走らせる。ハンドオーバーレイテンシが150ミリ秒を超える箇所はフラグを立て、翌日再調整して再テストする。受入基準は契約に書く：ネットワーク原因のタスク消失ゼロで72時間連続、その後にネットワークを検収する。
よくある失敗パターン（すべて血で代償を払った）
| 見た目 | これから始めない | 代わりにこれから始める |
|---|---|---|
| AMRが同じ場所でタスクを失う | ベンダーに配車ログの読み解きを依頼する | その通路にpingを打ち、APカバレッジを確認する |
| ゾーン全体が一緒に減速する | ロボットを増やす、タスク優先度を上げる | そのゾーンのAP負荷とチャンネル干渉を確認する |
| 朝は快調、午後は不安定 | AMRを再起動する、ファームウェアを更新する | 時間帯パターンの干渉を探す：充電ベイ、シャッター |
| 1週目は快調、2週目に劣化 | AMRハードウェアの経年劣化を疑う | 新しいラック、新しい間仕切り、ぶつけられたAPを確認する |
一つの逆説的な見解
ほとんどのプロジェクトは手順が逆です。AMRベンダーが2週間かけて解体し、その後にようやく誰かがネットワークを調べる。正しい順番は常に pingが先、電話は後 です。ネットワークチェックはノートPC1台と半日のコスト。ベンダーの現地訪問は旅費＋2週間の言い争いのコスト。そして見落とされがちな点：ネットワークを調整すれば、多くの「AMR性能問題」は勝手に治ります。フリート速度が上がり、タスク成功率が上がり、追加のロボットは不要でした。
AMRは誠実な働き者です。指示されたことしかしない。指示が届かなければ、安全のために非常停止するしかない。働き者を責めないで。まずWiFiを調べてください。
Lin Xiao（倉庫管理システム導入コンサルタント）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
