想像してみてください。40台の自律移動ロボットが一つの倉庫フロアを共有しています。交差点では互いに譲り合い、狭い通路を傷一つつけずにすれ違います。正直なところ、ラッシュアワーの人間ドライバーよりよっぽど規律正しいのです。アリゾナの物流センターでメザニンから初めてそれを眺めたとき、私は頭の中に一つの疑問を抱えたまま、かれこれ20分ほど立ち尽くしました。「このオーケストラを指揮しているのは誰だ？」 その午後、彼らのエンジニアたちと過ごしたあと、答えがわかりました。すべての動きを指示する単一の「スーパー頭脳」など存在しないのです。そこにはマルチエージェント・スケジューリングと呼ばれるシステムがありました。この記事ではそれを三つの要素に分解します——仕事の割り当て方、ロボットの進路の決め方、そして二台が同じ床面を取り合ったときに何が起きるか。そして最後に、どの程度の台数からその手間に見合うのかをお話しします。
規模感をつかむための数字を二つ。2012年、AmazonはKiva Systemsを775,000,000ドルで買収し、棚運搬ロボットをフルフィルメントセンターに導入しました。2023年までに、Amazonは倉庫全体で750,000台以上のロボットを配備したと発表しています。10年余りで、移動ロボットは実証実験から大規模施設の標準装備になりました。そして750,000台という数字の裏側で、難しかったのは決して「一台のロボットを走らせること」ではありませんでした。数十台、数百台のロボットに、衝突もデッドロックも半分の遊休もなく一つの屋根の下を共有させることです。それこそがマルチエージェント・スケジューリングが解くべき課題です。
誰が仕事を引き受けるのか
スケジューラの第一の仕事はタスク割り当てです。「ラックAでトートをピックアップし、梱包ステーションBに届ける」といった仕事を適切なロボットに渡すこと。説明するのは簡単ですが、実務ではトレードオフの連続です。
主流のアプローチは二つあります。一つはオークション方式。仕事が発生するたび、待機中の全ロボットが、ラックまでの距離、残りバッテリー、近くに他の用件があるかどうかをもとに「入札」します。最も安い入札が勝ちます。もう一つは中央集権型の最適化。中央サーバが全ての仕事と全ロボットの状態を集め、一発で全体最適な割り当てを計算します。
オークションは高速で、単一障害点にも強い。一台がオフラインになっても、他のロボットが仕事を取り続けることを止めません。その代償は局所最適です。フリート全体の走行距離は理論上の最適値を上回ります。中央集権型最適化は美しい計画を出しますが、数十台のロボットと秒間数百件の新規ジョブでは、ソルバーがリアルタイムのペースについていけず、サーバがつまずけばフロア全体が一緒につまずきます。
私の率直な見解はこうです。50台未満のフリートなら、オークションにいくつかのシンプルなルールを足せば十分です。初日から全体最適を追いかけるのはやめましょう。節約できる走行距離は、その複雑さとデバッグにかかる時間の元を取れません。かつて、30,000平方フィートのEC倉庫で、12台のロボットが全体最適化のフルスケジューラで動いているのを見たことがあります。エンジニアが三か月かけて調整しましたが、ピークシーズンを救ったのはタブレットで手動割り当てを叩く人間でした。アルゴリズム選びでは「十分に良い」が金に値します。
どうやって進路を見つけるのか
仕事が割り当てられたら、ロボットはルートを必要とします。AMRは人間のように標識を読みません。地図を読みます。
倉庫フロアは目に見えないグリッドに分割されます。各セルは走行可能か障害物か。スケジューラはA*系の経路探索アルゴリズムを実行し、各ロボットの始点から終点までのルートを計算します。スマホのナビのように聞こえますが、倉庫版には交通法規が一層追加されます。幹線通路は一方通行、交差点には譲り合いポイント、充電ゾーンと人手作業エリアは徐行ゾーン、そして積載ロボットと空荷ロボットは別々の仮想レーンを走ります。
ここで私が自ら踏んだ落とし穴を共有します。皆さんが踏まなくて済むように。一角でロボットが非常停止を繰り返し、ログは障害物アラートでいっぱいでした。lidarを交換し、パラメータを三回も再調整しましたが、何も変わりません。その角の上部に新設の高出力アクセスポイントがあり、電波のバーストが数ミリ秒ずつ自己位置推定パケットを叩き落としていたのです。ロボットは自己位置を見失ったと思い、ブレーキをかけて指示を待ったのです。教訓：経路計画がおかしいときは、アルゴリズムを責める前にWi-Fiのカバレッジと床面の平坦さを確認してください。アルゴリズムは物理環境を直せません。この文はもう一度出てきます。
交差点では何が起きるのか
数十台のロボットが一つの道路網を共有するのですから、交差点での遭遇は日常茶飯事です。コンフリクト解決が決めるのは、先に行くのは誰か、譲るのは誰か、そして何より——一台分の幅しかない通路で二台が正面から向き合い、どちらも下がろうとしない事態をどうやって絶対に防ぐかです。
主力の手法は予約テーブルです。各ロボットは自分のルートを計画するだけでなく、今後数秒間に占有する道路区画を「予約」します。時間と空間の両方でスペースを押さえるのです。次のロボットがルートを計画し、ある時間帯にその区画が既に予約済みとわかれば、迂回するか一呼吸待ちます。優先ルールは通常、先着順、積載ロボット優先、そして充電に急ぐロボットがすべてに勝ります。ロボットが死ぬのは渋滞よりコストが高いからです。
デッドロックは悪夢のシナリオです。二台のロボットが狭い通路で正面衝突し、双方の予約テーブルが「自分に優先権がある」と言っている。停止。デッドロックは路上交渉では防げません。道路網の設計で防ぐのです。幹線通路をループ状に、狭い通路を厳密に一方通行にすれば、正面衝突は構造的に起きなくなります。私がスケジューリングシステムを評価するとき、デッドロック件数は必須の指標です。一週間ぶっ通しで回してみてください。デッドロックが二桁に達したら、道路網の設計が間違っています。「稀なエッジケース」でなだめる人は相手にしてはいけません。
いつ導入する価値があるのか
最後に、最もよく聞かれる質問。私たちの台数で、マルチエージェント・スケジューリングは必要ですか？
私の分岐点はこうです。10台未満なら、中央集権型スケジューリングは考えなくて結構です。ロボット単体の知能と固定の交通ルール、そして手動介入用のタブレットで十分です。その規模の中央集権型スケジューリングは、釘を打つのに大ハンマーを持ち出すようなもので、しかも扱いにくい大ハンマーです。20台から50台なら、中央集権型のタスク割り当てと道路網の交通ルールがはっきりと元を取り始めます。ここがマルチエージェント・スケジューリングのスイートスポットです。100台を超えたら、ゾーンと階層が必要です。中央システムはゾーン間のジョブフローだけを扱い、各ゾーンは自律運営する。そうしないと、中央サーバの計算力と通信遅延が先に音を上げます。
私が「触るな」と言う二つのシナリオがあります。一つ目は、床面が不整でラック間隔が不規則な古い倉庫で、自己位置推定が一日中ドリフトするケースです。その物理環境では、スケジューリングアルゴリズムは火消しに追われるだけです。二つ目は、需要の潮汐が極端な倉庫です。例えばピークシーズンの物量が通常の10倍で、閑散期は20台で足りるのに12月には80台必要になるケース。スケジューリングが解くのは「どう回すか」です。「ロボットが足りない」は解けません。まず弾力的なキャパシティを確保してから、知能の話をしましょう。
明日から動ける三つの推奨事項です。
一つ目、AMRを一台も買う前に、WMSから一週間分のタスクデータを引っ張り、仕事がどこに・いつ集中するかのヒートマップを作ってください。そしてフリートの規模とスケジューリング方式を選ぶのです。自分のワークロードがどんな姿かわからなければ、アルゴリズムを選ぶ準備はできていません。
二つ目、まず道路網を設計してください。一方通行通路、ループ、充電ゾーンの配置。紙に描いて、最悪のケースを通してみるのです。最狭の通路で満載の二台が正面衝突する、ピーク時に五台が同時に充電を必要とする。紙の上で回らなければ、フロアでも回りません。
三つ目、「ロボットが動いている」を成功と認めないでください。三つの数字を見てください。平均ジョブ待ち時間、週間デッドロック件数、充電待ち時間。この三つが健全なら、スケジューリングシステムは本当に健全です。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
