RCSタスク優先度：急ぎ注文を割り込ませても波を壊さない方法

RCSのタスクスケジューリングは、病院の救急トリアージ受付のようなものだと考えてください。患者（タスク）が次々と到着し、トリアージ看護師（スケジューラ）が重症度（優先度）によって誰を先に外傷室（ロボット）へ入れるか決めます。緊急レーンは本物の緊急事態のために存在します。しかし、どの家族も「うちが急ぎだ」と叫べば、トリアージは崩壊します。RCSタスク優先度の設定はまさにこの仕事をします。誰が先に乗り、誰が待つかを決めるのです。

仕組み：キュー、重み、ディスパッチサイクル

RCSはロボットフリートの頭脳です。100 msから約1秒ごとにディスパッチサイクルを実行します。待機中のすべてのタスクにスコアを付け、並べ替え、最高スコアのものを空きロボットに割り当てます。タスクのスコアはおおよそ次のようになります。

task score = priority weight × f(wait time, distance, battery, task type)

急ぎ注文のプリエンプションとは、文字通り「奪う」ことです。何を奪うのかに注意してください。列の中の場所ではなく、キャパシティです。ロボットの時間は固定されています。急ぎ注文が使う1分は、通常タスクが待つ1分です。

高速道路の料金所にたとえることもできます。ETCレーン（高優先度）が先に進み、現金レーン（通常タスク）が並びます。しかし、ETCレーンを増やし続けることはできません。すべてのレーンをETCにすれば、誰も列を抜かせなくなります。それでも料金所は渋滞します。優先度は、希少であるときにのみ意味を持つのです。

式のf()をもう少し詳しく見てみましょう。待機時間は「永遠に待つ」ことを防ぎ、距離は最も近いロボットを選び、バッテリーは充電量の少ない機体を除外し、タスク種別は搬送・昇降・充電の作業を区別します。10分待ったP2タスクは、エージングが働き始めれば、到着したばかりのP1を上回ることがあります。それこそがエージングの存在意義であり、多くの人が何気なく無効化し、後で最も後悔する設定でもあります。

プリエンプション設定の3つの方法と、それぞれのコスト

設定A：優先度重み付け。 急ぎ注文の優先度重みを上げるのです。たとえば通常タスクを5、急ぎ注文を50にします。パラメータは1つだけで、至って簡単です。コストは、上げすぎる（たとえば100）と低優先度タスクが決して処理されなくなることです。それがスタベーション（飢餓状態）であり、通常の波を死に追いやります。

設定B：プリエンプティブな再割り当て。 急ぎ注文が到着したら、低優先度タスクに取り組んでいるロボットを徴用します。中断されたタスクはロールバックして再びキューに入ります。最も速い応答です。コストは空走（デッドヘッド）です。中断された走行は無駄な走行距離であり、今度はもう一度走らなければなりません。

設定C：予備キャパシティ。 フリートの10–20%を通常の波から外し、急ぎ注文専用に確保します。最も安定した選択肢です。コストは閑散期の遊休キャパシティです。千日のために兵士を養い、一日の戦いに備えるようなものです。

私が2025年に調整したプロジェクトの話です。中国東部のEコマース倉庫、180台のAMRです。急ぎ重みを50に設定しました。通常の急ぎ比率3%ではすべて順調でした。しかし、618ショッピングフェスティバルの当日、急ぎ注文は15%に急増し、通常タスクの平均待ち時間は50秒から4分に跳ね上がり、波の定時率は12ポイント低下しました。ログを見ると、低優先度タスクが47分待っていました。まさに教科書通りのスタベーションです。根本原因は、欠けていた部品が1つだけでした。重み付けは設定されていたが、エージングの仕組みがなかったのです。

3つの中からどう選ぶか。急ぎ比率を見てください。安定的に5%未満ならAを使います。安くて十分です。まれだが第二レベルの対応が必要な場合（生産ラインが止まりそうな場合）はBを使います。ピークが明確な変動型（大型セールイベント、四半期末）ならCを使います。ほとんどの倉庫は最終的にA+Cのハイブリッドに落ち着きます。通常日は重み付け、ピークの2週間前から予備キャパシティをオンにします。分かれ目は技術ではなく、ビジネスのリズムです。だからこそ、他の倉庫のパラメータをコピーした10人のうち9人は、結局ロールバックすることになるのです。

現場で検証済みのRCSタスク優先度設定：ティア、エージング、予備キャパシティ

ティア。 P0は本物の急ぎ（量の5%未満に抑える）／P1は優先波／P2は通常／P3は延期可能（補充、サイクルカウント）。何が「急ぎ」に当たるかの鉄則は、営業が急ぎだと言うことではなく、SLA期限がX時間以内に迫っていることです。営業が「このロットは急ぎだ」と言ったら、まず2つの質問をしてください。「SLAペナルティはいくらで、顧客を失いますか？」答えられなければP2行きです。ここで偽の要件が生まれます。私はそれを指摘することを決して遠慮しません。

エージング。 長く待ったタスクは自動的に昇格します。スタベーションを防ぐ下限です。

effective priority = base weight + factor × wait time / threshold

エージングがなければ、いくら美しく調整された重みでも時限爆弾です。通常日は静かでも、ピーク時には必ず爆発します。

予備キャパシティ。 ピークシーズンは15–20%、オフピークは5–10%で、急ぎ比率に応じて動的に調整します。ハードコードは決してしません。覚えておいてください。重みはキューの順序を変えるだけです。キャパシティを生み出すわけではありません。急ぎ比率が10%を超えても重みの調整だけを続けているなら、間違った道具を使っています。

メンテナンスの罠：一度設定して、永遠に苦しむ

罠1：一度調整して1年間運用する。 ピークシーズンになるとSKUミックスも波のリズムも変わるのに、重みは昨年のままです。優先度設定は波の計画に合わせるべきです。少なくとも四半期ごとにレビューし、ピーク前には必ず再調整します。

罠2：負荷なしでテストするので、スタベーションが決して現れない。 テストでは平均待ち時間しか見ません。平均は最も不誠実な指標です。重要な数字は、低優先度タスクの最大待ち時間です。それが上昇し始めたら、スタベーションが近づいています。

罠3：上限を超えた急ぎ比率に備えて構える。 急ぎ注文が長期的に量の10%を超え続けるなら、それはスケジューリングの問題ではなく、キャパシティの問題です。ロボットを増やすか、一部の「急ぎ」注文をP2に格下げしてください。スケジューラのパラメータでキャパシティの不足を補うことはできません。

罠4：誰でもP0を付けられるようにする。 優先度の最大の敵はパラメータではなく、人です。P0のマーキング権限は制限しなければなりません。誰が付けられるか、承認が必要か、そして真のP0比率の月次監査です。マーキングを開放したままにすれば、P0は3か月以内に20%を超えます。その後はいかなる調整もあなたを救いません。

では、優先度設定はやる価値があるのでしょうか。1組の数字を見てください。急ぎ注文の定時率が目標に達し、かつ通常タスクの平均待ち時間が横ばいであることです。両方とも真なら、設定は正しいです。片方だけ真なら、自分を騙していることになります。

Da Liu（自動化エンジニア）著

英語版からの翻訳。内容に相違がある場合は英語版を優先します。