ロボットは決して嘘をつかない。だが、数週間前に真実でなくなったことを覚えていて、その記憶に基づいて完全な自信で行動する。私は2022年の秋、カリフォルニア州フォンタナ郊外の3PLでそれを目の当たりにした——120,000平方フィート、goods-to-person で稼働する40台のAMR。そのうち1台ががらんとした通路の真ん中で急停止し、その場で2回転してから、何もない場所を大回りして避けた。ログが物語っていた：そのロボットには2か月前に撤去されたラック列が「見えて」いたのだ。RCS マップはまだ過去に生きていた。
RCS（robot control system：ロボット制御システム）は、建物内のすべてのAMRが航行する地図を保持している。充電ドック、立入禁止ゾーン、走行レーン——すべてがこのファイルに収まっている。多くの現場チームはマップを「一度作れば終わり」の資産として扱う。それは私がこれまで訪れたすべてのAMR導入現場における原罪だ。倉庫は生きている。ラックは動く。ピークシーズンには通路が一時パレットで埋まる。誰かが床を塗り直す。マップが追いつかなければ、ロボットは並行世界で働くことになり、現場で見る奇妙な振る舞いは単なる症状に過ぎない。
ダウンになる前に症状を読み取る
古くなったマップは3つの方法で存在を知らせるが、私はそのすべてを現場で見てきた。
1つ目は自己位置の喪失だ。AMRはlidarのスキャンをマップに照合して自分の位置を知る。ラックを動かすとスキャンが合わなくなり、ロボットは本当に自分がどこにいるのか分からなくなる。最良の場合は数秒その場で回転して自己位置を回復する。最悪の場合はアラームを上げて、人が助けに来るのを待つ。フォンタナの現場では、最悪の時期に1日で2桁のアラームが出て、goods-to-person ゾーンはピーク中に30分間停止した。
2つ目は遠回りだ。通路に一時置きされたパレットが壁として記憶される。ピークが終わり、パレットは去るが、壁はマップに残る。ロボットは存在しない壁を毎日毎日避け続けて走る。主要通路1本で数字を追ってみよう：1トリップあたり30メートル余分、1台あたり1日200トリップ、1台あたり1日6キロ余分に走る。40台を掛けてみる。存在しない幽霊を避けるために電気とタイヤを燃やしていることになる。
3つ目——厄介なやつ——は、幽霊の障害物によるアラームの連鎖だ。1台が古いマップのせいでスタックする。後ろのロボットが列を作る。RCSが混雑を宣言して全体の再ルーティングを始め、再ルートがさらに状況を悪化させ、ついにはゾーン全体が停止する。スーパーバイザーの画面ではシステム全体の障害に見える。本当の原因は、先週の工事で引かれた床のペイントラインがマップに入っていなかったことかもしれない。
私の結論は率直だ：AMR運用において、マップ保守はITの仕事ではなく現場運用の仕事だ。これを拒めば、その後のすべてが苦痛になる。
チームがいつも過小評価する変化がもう1つある：床工事だ。エポキシ床の再コーティング、塗りたてのペイント、反射率の異なる新しいフロアマット——いずれもlidarが見えるものを変える。マップは同じマップなのに、ロボットの世界は違って見えるため、自己位置がずれ始める——床では「何も変わっていない」のに、謎の減速や震動が起きる。私のルール：ラックを動かしたかどうかに関わらず、床工事があれば工事完了時に必ず増分マップ更新を行う。
まずトリアージ、次に5ステップのドリル
すべての変更が同じ対応に値するわけではない。私は変更を3段階で評価する。グレードA：2列を超えるラックの移動、主要走行レーンの変更、新しい壁や柱——フルリマップ。グレードB：スロット1～2個の移動、一時ステージングの撤去、小規模な床補修——増分更新。グレードC：スロットのラベル変更、カートン積み高さの変更——マップ変更なし、WMSにメモするだけ。多くの倉庫は、グレードCをグレードAのように扱って一晩中リマップして時間を燃やすか、グレードAをグレードCのように扱って3か月後にそのツケを払う。
更新ドリル自体は5ステップで、この順番、スキップなし。
1つ目、床をフリーズする。更新の2時間前から：ラックの移動禁止、一時ステージング禁止。当たり前に聞こえるが、私が見てきたマップ更新インシデントの半数以上は、更新の最中に床が再び変わったことに起因している。
2つ目、時間帯を選ぶ。40台の建物なら、夜勤の後半を取って2時間をブロックする。120,000平方フィートのフルリマップは人のレビュー込みで約1時間、増分パスは20分。始める前に影響ゾーンをクリアし、RCSで立入禁止にマークする。
3つ目、更新してから手で検証する。スキャンが終わっても公開しない。自分で重要ポイントを歩く：充電ドック、エレベーターホール、防火レーン、フォークリフトとAMRが共存する混在交通ゾーン。この教訓は痛い目に遭って学んだ——ある増分更新の後、充電ドックがマップ上で0.5メートルずれていて、6台が一晩中ドッキングに失敗し、朝のシフトは電池切れのロボットで始まった。
4つ目、空のロボットでドライランする。公開前に、空のロボット2台を新しいマップで影響エリア全体に走らせる。説明のつかない減速、急停止、遠回りを注視する。その後に全フリートへ公開する。
5つ目、最初のシフトは鷹のように見張る。本番化の後は、最初のシフト全体にわたってRCSのアラームログを監視する——特に自己位置喪失とルート再計画の急増だ。どちらかが跳ね上がったらロールバックする。議論はしない。
一時ステージングは別枠で注意すべきだ。ピーク中に通路にパレットをステージングするのは生き物のようなもの——抵抗するのは無意味だ。うまくいくのはこうだ：マップ上に動的ステージングゾーンを指定し、ピーク中は毎日シフト終了時にクリアし、クリア直後に増分更新を回して「壁」を消す。一時パレットは問題ではない。マップから消し忘れることが問題なのだ。
バージョン管理はある夜あなたを救う
すべてのマップにバージョン番号を付ける——私は日付＋連番を使い、例えば20261008-01のようにする。直近5バージョンをRCSに保持し、ロールバックを10分でできる作業にする。私が関わるすべてのプロジェクトでこれは必須要件だ。ロールバックの訓練を四半期ごとに行うこと。本番のインシデント中にバックアップのマップファイルが壊れていることに気づくのは避けたい。
2023年初め、オンタリオのeコマース倉庫が増分更新を公開し、公開の20分後にアラーム量が3倍になった——新しいマップが一時フォークリフトレーンを走行可能と誤分類し、交差点でAMRとフォークリフトが真正面から向かい合っていた。シフトスーパーバイザーは訓練通りに前のバージョンへロールバックした：8分で完了、ピークの受注に影響なし。バージョンと訓練がなければ、その夜は1シフト分のスループットを失っていた。ロールバックは万が一の手段ではなく、本番ツールなのだ。
チームがいつも見落とすことがもう1つある：マップが変われば、WMSのロケーションマスターも一緒に変えなければならない。ラックは移動し、スロットコードは同じでも、新しいマップ上の座標は違う。WMSが古い座標を持ち続けていれば、ロボットが到着してもシステムは「location does not exist」と言い、タスクは死ぬ。私のルール：ラックの移動があれば、RCSマップと同じ変更チケットで、その日のうちにWMSの座標フィールドを更新する。
この記事から1つだけ持ち帰るなら、これにしよう：毎週金曜、シフト終了前に誰かをAMRの主要走行レーンに歩かせ、その週の床変更リストを持たせる。10分だ。マップが現実と合っているか確認し、合っていなければ月曜の朝一番で更新する。
そして、このすべての背後にある気まずい問い：もし明日の朝あなたのロボットが不調を訴え始めたら、チームはマップが無罪だと証明するのにどれくらいかかるだろうか？答えが「推測するしかない」なら、マップはすでに古い——あなたがまだ気づいていないだけだ。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
