結論から言えば、RCSのタスク割当は「一番近いロボットに送る」ことではない。割当の質を実際に決めるのは、距離、バッテリー、タスク種別、混雑という4つの変数を一緒に重み付けしたものだ。私はベンダーのデフォルトである最近傍優先が失敗するのを3回見てきたが、その脚本はいつも同じだった。割当ロジックさえ正しければ、20台のAMRフリートは空走率を約40%から25%未満まで下げられ、ピーク時の通路のグリッドロックもほぼ消える。
最近傍優先の割当が失敗し続ける理由
2023年9月、中国東部の3PLアパレル倉庫で、リフト型AMR 18台が稼働開始した。RCSはベンダーのデフォルト方針、すなわち純粋な最近傍優先で動いていた。稼働初日のプロモーションで、入庫タスク6件が一度に発生した。RCSは最も近い6台を派遣したが、その6台はすべて同じメイン通路に集中した。前のロボットは後ろのロボットが譲るのを待ち、後ろのロボットは前のロボットに塞がれていた。11分間の完全停止。その間、遠端の出庫タスク4件は使えるロボットがなく放置された。最も近いロボットはすべて渋滞に巻き込まれていたからだ。私はこの失敗をちょうど3回見ている。
最近傍優先は1回の派遣の空走距離だけを最適化し、派遣後のフリートの姿を無視する。6台を一度に同じ方向へ送ることは、自ら交通渋滞を作り出すことだ。
RCSの割当が実際に使う4つの変数
私の稼働前夜チェックリストでは、タスク割当に4項目があり、1つずつ確認する。
- 距離：直線距離ではなく、空走経路長、つまりロボットからタスクまでの実際の走行距離で、一方通行の通路や迂回も含む。直線で30メートルでも、実際の走行は120メートルになるタスクはざらにある。
- バッテリー：充電率30%未満のロボットは自動的に短距離のみに格下げし、20%未満なら新規タスクからロックアウトして充電へ送る。私はかつて、RCSが12%のロボットにゾーン横断の長距離輸送を割り当てたプロジェクトを見た。通路の真ん中で力尽き、誰かが手で押し出すまで幹線通路を塞いだ。
- タスク種別：すべてのロボットがすべての仕事をこなせるわけではない。リフト型とフォーク型は混ぜられず、重いパレット（たとえば1トン超）は大型モデルにしか行かない。RCSのタスクプールは、割当の前に車両能力タグでフィルタしなければならない。
- 混雑：今後2分以内に別のロボットが対象通路に入るか。RCSは予約制で割り当てるべきだ。派遣時に経路を予約し、通路あたりの同方向進入を（通路幅に応じて通常2〜3台に）制限する。
私の推奨する優先順位は、タスク種別（まずハードフィルター）→バッテリー（ハード制約）→混雑（動的ペナルティ）→距離（タイブレーカー）だ。ほとんどのRCSデフォルトは距離を最優先にする。それが失敗の根本原因だ。
ロボットタスク割当戦略の比較：4つのうち1つを選ぶ
| 戦略 | ロジック | 強み | 弱み | 最適な用途 |
|---|---|---|---|---|
| 最近傍優先 | 最短の空走が勝つ | シンプルで応答が速い | 渋滞、バッテリーを無視 | 10台未満のフリート、オフピーク |
| ゾーン割当 | 倉庫をゾーンに分割し、ゾーンごとに固定ロボット | ゾーン間空走ゼロ、理解しやすい | 負荷の偏り。ホットゾーンが崩壊する | タスク分布が安定した倉庫 |
| オークション方式 | タスクをブロードキャストし、各ロボットがコストを入札。最低入札が勝つ | ほぼ全体最適、バッテリーと距離を自然に考慮 | 複雑で、RCSの本格的な計算能力が必要 | 30台超のフリート |
| 事前割当＋動的再計画 | 5分先まで計画し、混雑に応じてライブで再計画 | ピーク時最も安定、グリッドロック最少 | WCSからの受注予測が必要 | ピークが鋭いEC倉庫 |
選び方はどうするか。3つの問いがある。① フリートは20台より大きいか。そうなら最近傍優先は捨てる。② 明らかなピークはあるか。そうなら事前割当を使う。③ RCSハードウェアはオークションを回せるか。回せないなら手動調整付きのゾーンに fallback する。最も派手なアルゴリズムを崇拝してはいけない。安定して動くものが勝つ。
稼働前夜チェックリスト：RCSタスク割当編
- 低バッテリーのロックアウト閾値は設定済みか。私は20%でロックアウト、30%で格下げを使う。
- 車両能力タグはタスク種別と一致しているか。ネガティブテストを1回行う。わざと不適合なタスクを発行し、RCSが拒否することを確認する。
- 通路あたりの同時進入上限は設定済みか。幹線通路と分岐通路は別々に設定する。
- 空走のベースラインは測定済みか。初週は、空走距離を総走行距離で割った値を毎日追跡する。35%を超えたら再調整する。
- RCSとWCSの責任分担は文書化済みか。誰がタスクを分割し、誰がロボットを割り当て、インターフェースがタイムアウトしたときのフォールバックを誰が担うか、すべて書面で残す。
高くつく3つの失敗モード
失敗1：1つの通路でのロボットの渋滞。 2024年5月、中国南部の美容EC倉庫で、24台のAMR。深夜のプロモーションで、40件の出庫タスクが10秒以内に発生した。最近傍優先は14台を同じメイン通路に出庫ドック方向へ送った。完全なグリッドロックだ。修正策は、RCSに通路予約を追加すること。同方向の進入が3件を超えたら、後のタスクは自動的に迂回するか、派遣を30秒遅らせる。変更後、同じ規模の波におけるメイン通路の通過時間は、平均9分から3分未満に下がった。
失敗2：RCS、WCS、PLCの境界の曖昧さ。 失敗が約束されたプロジェクトの最も一般的な根本原因だ。役割分担はこうあるべきだ。WCSは受注を移動タスクに分解する（何をAからBへ動かすか）。RCSはタスクを特定のロボットに割り当て、経路を計画し、交通を管理し、充電をスケジュールする。PLCは低レベルのハードウェア（ローラー、リフト）のみを扱う。私はかつて、WCSもRCSも経路を計画し、2つの経路計画が互いに競合して、ロボットが交差点でその場で回転し続けるプロジェクトを見た。処方箋は、インターフェース契約を不動のものとして書くことだ。WCSはタスクを発行し、決して経路を引かない。経路は100% RCSの領分だ。
失敗3：バッテリーを確認せずに派遣すること。 上で述べたとおり、低バッテリーのロボットによる長距離輸送は時限爆弾だ。もう1つ付け加えると、充電器の位置は割当モデルに含めるべきだ。派遣時には、低バッテリーのロボットに充電器の近くで終わるタスクを与え、仕事を終えたらそのまま充電に入れるようにする。一石二鳥だ。
直感に反する判断：フリートをフル稼働させないこと
多くの倉庫オーナーは、遊んでいるロボットは金の無駄だと思っている。間違いだ。私のルールは、フリートの15–20%を常にフレックス容量として確保することだ。タスクは波状にやってくる。フル稼働のフリートが波に襲われれば、派遣できるロボットがなく、すべてがキューに溜まり、待ち行列がすべてのタスクをまとめて遅らせる。20%を予備に持てば、波は吸収され、平均タスク待ち時間は実際に下がる。あの美容倉庫では、24台中4台をフレックス（緊急タスク専用）として確保したところ、プロモーション中の平均タスク待ち時間は、24台すべてを動かす場合と比べておよそ3分の1減った。トレードオフは、4台が局所的には遊んでいるように見えることだが、システム全体では速く回る。これがRCSタスク割当で最も難しい教訓だ。最適な割当とは、すべてのロボットを忙しくさせるものではなく、システムを詰まらせないものだ。
Lin Xiao（WMS導入コンサルタント）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
