RCSのタスク優先度は、小規模フリートの時代には問題ではなかった。十数台のロボットなら先着順で十分だった：バッテリー残量が低ければ充電に行き、緊急注文は手動で割り込ませても何も壊れなかった。だがフリートがある閾値を超えると、スケジューリングはディスパッチではなくなり、真のトレードオフになる。ウェーブタスクにはスループットが、緊急注文にはリードタイムが、充電にはフリートの稼働継続が必要で——そして三者すべてが同じロボットを奪い合う。WMSとフリートの間に立つロボット制御システムであるRCSは、日々この三種類のタスク間でキャパシティを配分している。
フリートが拡大すると、RCSタスク優先度は現実の問題になる
まずデータから。Interact Analysisによると、モバイルロボットの累積出荷台数は2025年末までに2.1 million台に迫り、売上は約$18 billionに相当し、一方モバイルロボットを導入する顧客拠点数は2020年の9,000強から53,000超へと成長した。過去5年間の業界の物語は、「パイロットで数十台」から「運用単位としてのフリート」への移行だった。
だが同社は2025年央のアップデートで見通しを下方修正した：その年のAMR予測を$800 million引き下げ、5年間の年平均成長率を26%から21%に縮小し、関税の混乱と顧客の設備投資の様子見ムードを理由に、2030年の売上予測を$15.6 billionに下げた。この下方修正は立ち止まって考える価値がある。スケジューリング問題が小さくなっているわけでは決してない——むしろ逆だ。拡張が鈍化する年には、オペレーターは既存フリートからより高い稼働率を搾り出そうとし、稼働率が高いほどタスク種別間の対立は鋭くなる。
もう一つのシグナルはAmazonから。June 2025、同社は300超の拠点に広がる one-millionth robot の導入を発表し、ロボットの移動を調整するために作られた生成AIモデルDeepFleetも発表した。同社によればロボットの移動効率を10%改善できるという。この数字はベンダーの主張であり、独立に検証された測定値ではなく、この区別は重要だ。だが方向性は明確だ：調整対象が数十台から a million に成長したとき、スケジューリングはもう「石に刻まれたルール」ではあり得ない。システムが学ぶものにならねばならない。
現実のジレンマ：緊急注文がウェーブのロボットを奪うとき
2024年のピークシーズンを前に、米国南西部のeコマースフルフィルメント倉庫が教科書どおりのケースに直面した。大規模プロモーションの夜、緊急注文が殺到し、RCSはプリエンプティブ優先度をオンにした：高優先度の緊急タスクが進行中の低優先度ウェーブタスクを中断し、ロボットを引き抜くことができた。
締め切りは守られ、その夜の緊急注文はほぼ定時に出荷された。代償は夜の後半に現れた。中断されたウェーブタスクは先送りされ続け、後続のウェーブはすべてずれ、ある時点ではピッキングステーションが遊び、届いていない商品をロボットが待っていた——車両が仕事を待っていたのであり、その逆ではなかった。
このケースは見落としやすい事実を示している：プリエンプションは無料ではない。遅延を消すのではなく、移動させるのだ。コストを緊急注文から、別の形でウェーブタスクへ移す。優先度ポリシーは本質的に、システムの混雑コストを誰が負担するかの決定だ。
RCSタスク優先度の三つの戦略：スケジューリング・トレードオフの枠組み
実際には、三者の対立に対する業界のアプローチは、コストの異なる三つの大戦略に大別される：
| 戦略 | ロジック | 向いている場合 | コスト |
|---|---|---|---|
| 静的優先度 | 固定の順位付け、例：緊急 > ウェーブ > 充電 | 小規模フリート、均一なタスク構成 | 緊急注文が頻繁だとウェーブが飢餓状態に；充電は体系的に軽視される |
| 加重スコアリング | 各タスク種別を待ち時間、納期圧力、車両状態で動的に採点；最高点が先 | 混合タスク、変動する負荷 | 重みの継続的な再調整が必要；チューニングは高コストで、ドリフトが性能を劣化させる |
| セーフガード付きプリエンプション | 緊急注文は割り込めるが、ウェーブタスクは最低保証シェアを確保；充電は時間枠で予約 | 大規模フリート、ピークシーズン | 実装が最も複雑；フリート状態とタスク到着の予測が必要 |
どれも標準的な答えではない。私の観察では、成熟したフリートの多くは三つ目の変形を運用している：プリエンプションは許されるが、割り込まれた側には飢餓からの保護が付く——たとえばウェーブタスクは一定回数先送りされた後、自動的に優先度が上がる。重要なのはどの戦略を選ぶかではなく、どんな静的ルールもある負荷では破綻するという前提をオペレーションが受け入れるかどうか、そしてポリシー自体にフィードバックが必要かどうかだ。
意外な真実：充電は隠れたスループットの変数
三つのタスク種別のうち、充電は最も過小評価されやすい。直感は言う、充電は注文を生まないから最後でいい、と。ある倉庫はその直感に従い、充電優先度を最低に設定し、バッテリー閾値を下回ったロボットだけを充電に向かわせた。
するとピークシーズンのある夜、フリートの大半がほぼ同時に閾値に達した。充電ステーションに行列ができ、早朝にフリート稼働率が崖から落ち、その拠点のスループットも一緒に落ちた。エンジニアの修正は意外だった：充電タスクの優先度を上げ、断片的な機会充電——ロボットがたまたま充電器の前を通るたびにタスク間で継ぎ足し充電する——に移行し、オフピーク時間帯の集中充電ウィンドウと組み合わせた。稼働率カーブは平らになり、システムはより安定した。低下するどころではなかった。
このトレードオフは掘り下げる価値がある。充電タスクの真のコストは電気代ではない。間違ったタイミングに、一斉にオフラインになる車両だ。高稼働率のフリートでは、充電はスループットの前提条件であり、後回しの思いつきではない。「時間があるときに」という低優先度タスク扱いは、スケジュールに時限爆弾を仕掛けることだ。
三つのタスク種別が設計上対立する理由
この対立は構造的なもので、管理的ではない。三つのタスク種別は三つの異なる時間スケールに生きている：ウェーブタスクは時間単位で計画され、極めて予測可能；緊急注文は分単位で到着し、本質的に予測不能；充電はバッテリー曲線と充電器の物理的台数に支配され、本質的には制約充足問題だ。
もう一層深く見ると、目的関数が最初から一致していなかった。ウェーブタスクはスループットを最大化したい、緊急注文はレイテンシを最小化したい、充電はフリート稼働率を最大化したい。RCSは毎日、この三つの目的のオンライン・トレードオフを実行し、一つだけを最適化するルール——たとえば「常に緊急注文を優先」——は他の二つの次元で代償を払う。これこそ、フリートが大きくなるほど手書きルールが行き詰まるのが早い理由でもある。
トレンド判断：RCSタスク優先度はルールエンジンから学習ベース最適化へ移行する
データとケースを総合すると、私の判断はこうだ：今後3〜5年、主流のRCSスケジューリングは「人間がルールを書き、パラメータを調整する」から「シミュレーションで訓練し、オンラインで推論する」学習ベース最適化へ移行する。理由は三つ：第一にフリート規模——53,000拠点に2.1 million台の累積——がすでに手動調整を持続不能にしている；第二に、AmazonのDeepFleetのような実践は、フリートレベルの調整でリーディングオペレーターがルールをモデルに置き換えつつあることを示す；第三に、成熟したデジタルツイン・シミュレーションにより、ポリシーは実機に触れる前に仮想フリートで何千ものピークシーズンをリハーサルできる。
ただしこの判断には前提条件がある。学習ベースのスケジューリングには燃料として高品質な運用データが必要で、多くの倉庫のデータガバナンスはまだ「まあ十分」レベルだ。ボトルネックはアルゴリズムではない。データだ。
すると未解決の問いが残る。スケジューリングポリシー自体が学ぶシステムになったとき、倉庫のオペレーションチームは手動の優先度オーバーライドにまだ手を置いておく必要があるのか？もしそうなら、どの粒度で——いくつかの重みパラメータを調整するのか、それとも緊急時に個々のロボットの制御を奪うのか？まだ標準的な答えはないが、その答えは次世代RCS製品がどうなるかを形作る可能性が高い。
Dr. Chen（サプライチェーン研究者）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
