倉庫を十分な数だけ歩いて回ると、パターンに気づき始めます。ここ2年で、少なくとも5つの建物で見てきました。同じ屋根の下で、2つ、ときには3つのブランドのAMRが稼働しているのです。話はいつも同じ——段階的な購入です。ブランドAがパイロットを勝ち取り、うまく動き、拡張のタイミングになるとブランドBが3〜4割安く入ってきました。CFOが計算し、ブランドBのロボットが転がり込み、ITマネージャーは眠れなくなりました。フリートは別々、マップは別々、ディスパッチは無線とグループチャットでなんとかつなぎ止めている状態です。
結論を先に言います。混成フリートは問題ではありません。統合ディスパッチの不在が問題なのです。ただしRCSは魔法の杖でもありません。20台未満で1ブランドが支配的なら、サードパーティのRCSに飛びつくより、ネイティブのフリートマネージャーを極める方が得られるものは大きいでしょう。
まず、スタックの中でのRCSの位置を正しく押さえましょう。WMSは受注と在庫のオーナーです。WES/WCSは仕事をタスクに切り分け、割り当てます。RCSがオーナーなのは、たった1つ。物理世界でロボットのフリートが衝突したり、立ち往生したり、二重予約したりしないことです。経路計画、交通の調停、充電スケジュール、例外の引き渡し——それがRCSです。どのウェーブから先にピックするかといった業務ロジックは、その仕事ではありません。RCSは業務の頭脳ではなく、ロボット世界の交通整理員だと考えてください。WESの仕事を期待すれば、失望します。
マップは全部できている。なのにロボットが走らないのはなぜか
混成フリートの倉庫なら誰もが抱く疑問です。各ブランドは建物をマッピングしました。各ブランドは単独では正常に動きます。混ぜるとすべてがおかしくなります。
根本原因は、マップと交通ルールに相互運用性がないことです。各ベンダーのSLAM形式、座標原点、立入禁止ゾーンの定義はプロプライエタリです。ブランドAのマップ上の立入禁止ゾーンは、ブランドBには何の意味も持ちません。さらに悪いことに、交通ルールが違います。一方通行の通路、交差点の優先権、狭い通路ですれ違う方法——ベンダーごとにロジックが違うのです。2024年、私は2つのブランドが本線通路の交差点で1日に十数回、向かい合わせで膠着し、どちらも譲らず、無線を持った人間が手で交通整理するまで続くのを見ました。「交通整理係」という新しい仕事を生み出す自動化は、自動化のやり方が間違っています。
混成フリートの最初の教訓はこうです。できたマップは走れる道路ではないのです。統合ディスパッチは、マップファイルではなく優先通行権の統合から始まります。交差点を誰が調停するのか、立入禁止ゾーンを誰が定義するのか、一時閉鎖をどう同期するのか。この3つを決めない限り、ロボットが増えるほどカオスが増すだけです。
タスクは誰のもので、充電は誰のものか
マップの問題は少なくとも目に見えます。タスクと充電の問題は静かです——そして爆発したときはたちが悪い。
最初に来るのは、タスク割り当ての争いです。2つのディスパッチシステムがどちらも自分が仕事を割り当てるべきだと信じているので、同じ搬送タスクが2回発行され、ブランドの違う2台のロボットが同じパレットを取りに建物を空走します。WESに見えるのは「タスク完了」だけです——どのロボットか、どの経路かは見えません。例外の原因分析は完全に当てずっぽうです。やがて現場はシステムをまったく信用しなくなります。画面を見る代わりに電話をかけ合い、ディスパッチシステムは飾りになります。
次に充電です。各ブランドの充電器プロトコルと低バッテリー戻りしきい値は違います。ブランドAのロボットは残量3割で平気ですが、ブランドBはもう立ち往生です。ブランドAのユニットが遅い充電で共用の充電パッドを占有し、ブランドBは通路でバッテリー切れになります。充電は1ブランドなら問題になりませんが、3ブランドだと障害源になります。さらに古い状態情報が重なります。ブランドAは「アイドル」と報告し、ブランドBは「実行中」と報告し、RCSは常に現実より半歩遅れ、古いデータでディスパッチ判断を下します。ディスパッチすればするほど、悪化します。
統合ディスパッチへの3つの道——負担できるものを選ぶ
現実的なアプローチは3つです。銀の弾丸はありません。自社の運用が実際に担えるものを選んでください。
道その1：ベンダーのオープンAPIと、中立なサードパーティRCSを統合レイヤーにする。大規模でブランドが入り乱れたサイトに最適です。利点は中立性です——誰のホームでも勝ちません。代償は長い統合の苦行で、API文書を1つずつ読み解いていく作業になりますし、3つのベンダー相手に机を叩けるプロジェクトマネージャーが必要です。
道その2：支配的なブランドのRCSを核に、副次ブランドをプロトコルでブリッジする。1ブランドがフリートの7割以上を占めるときに最適です。安く、本番投入も速い——ただし副次ブランドは機能が落ちます。高度なディスパッチ機能は期待しないでください。基本的なタスクがきれいに回れば、それで勝ちです。この道を選ぶとは、支配的ブランドが主導権を握ることを認めることなので、副次ブランドの統合の深さは契約書に書き込んでください。
道その3：WESがタスクを直接ディスパッチし、RCSは交通の衝突回避だけを担う。タスクロジックが複雑で、ロボットがただの実行者である場合に最適です。WESが頭脳になり、RCSは純粋な交通整理員に退化し、各ベンダーのフリートマネージャーが充電と保守を担います。この道はWESに最大のものを要求します——WESが弱いなら手を出さないでください。
何かに署名する前に、このチェックリストを回し、1行でも空白があれば署名しないでください。ベンダーはVDA 5050に対応していますか——ドイツのVDAとVDMAが共同で公表した移動ロボット通信インターフェースで、現在、多ブランドフリートで最も現実的な共通言語です。対応していないブランドは1点ビハインドから始まります。マップは整合できますか、立入禁止ゾーンのオーナーは誰ですか。交差点を誰が調停しますか。充電器は共用できますか、低バッテリー方針を決めるのは誰ですか。ネットワークや電源が落ちたとき、誰が引き継ぎますか。これらを契約に入れることは、単価の値引き交渉より10倍重要です。
線引きを明確にした私の結論です。3つ以上のブランド、1つの建物に30台以上、または2年以内にブランド追加の確固たる計画——そんなときこそ独立したRCSを議論する価値があります。その線より下なら、支配的ブランドのフリートマネージャーとWESのタスクオーケストレーションに留まり、お金は効くところに使ってください。RCSはスケールの勝負であり、流行の勝負ではありません。
2つ目のブランドを買う前に、2つのことをしてください。ブランド1号からオープンAPIの文書をもらうことと、ブランド2号にVDA 5050対応か聞くことです。この2つの文書が取れなければ、その先はすべて借り物のトラブルです。
では——今あなたの建物では、いくつのフリート管理システムが稼働していますか？
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
