League of Robot Runners (LoRR) 2026 の Combined Track に1人チーム「Rovnou」として参加し、68チーム中8位(スコア 5.55、完了タスク 134,905件)という結果でした。会社としての発表は BreakAI のニュースに出しましたが、この記事では技術的な中身を個人の記録として残します。
LoRR とはどんな競技か
Amazon Robotics が協賛する、倉庫・製造現場を想定したマルチロボット制御のコンテストです。2026年は4月14日から7月22日まで約3ヶ月開催され、69チームから計3,361件の提出がありました。
問題は Lifelong Multi-Agent Path Finding (L-MAPF) と呼ばれるものです。グリッドマップ上の数百〜数千台のロボットに、次々と発生する運搬タスクを割り当て、衝突なく動かし続け、制限時間内のタスク完了数を競います。
- ロボットの動作は「前進・右回転・左回転・待機」の4種類だけです。ただし各動作の完了に複数ティックかかるため、交差点の譲り合いを1ティック単位では調整できません
- 2026年の新要素として動作遅延が入りました。ロボットは確率的に立ち往生し、計画どおりには動いてくれません
- Combined Track では、タスク割り当て(スケジューラ)・経路計画(プランナー)・実行制御(エグゼキュータ)のすべてを参加者が実装します
評価は fulfill(倉庫)・iron・maze・room など性格の異なる11インスタンスの合計です。狭い迷路と広い倉庫では効く手法がまったく違うため、単一のアルゴリズムを磨くだけでは伸びない構造になっています。
作ったもの — タイムスケール階層のプランナースタック
提出したスタックは、問題設定から新規に設計したもので、時間スケールごとに層を分ける構成にしました。
静的層 (前処理) : マップ解析・回廊と容量の抽出・全対距離オラクル
遅い層 (~100tick) : 容量制約つき多品種流を解き、持続的な方向場を維持
中間層 (~10tick) : 需要整形(地域ごとのタスク量調整)・誘導経路の供給
速い層 (毎tick) : 反復版 PIBT の1手 + 時間窓つき予約発想としては、「どの道を混ませないか」という交通管制を遅い層で決めておき、毎ティックの衝突回避(PIBT)はその指示に従って軽く済ませる、という分業です。混雑は数百ティック単位でしか動かないので、毎ティックすべてを考え直すのは計算の無駄になります。
実装面では、実測で痛い目を見るたびに、それを設計原則に昇格させていきました。いくつか例を挙げます。
- 設定は起動時に凍結する。 ホットパスに
getenvが紛れ込む事故が2回あり、ひどいものは24スレッドから叩かれて iron のスコアが52%落ちました。以後、環境変数は起動時に一度だけ解決する構造にしています - 再帰は使わない。 PIBT の優先度継承を素朴に再帰で書くとスタックオーバーフローの芽になるため、明示スタックによる反復実装に統一しました
- 並列化は「同じ問題を競争させる」のではなく「層ごとに分ける」。 複数解を並列に走らせて良い方を選ぶ方式は、試した範囲では選択のオーバーヘッドで頭打ちになりました
1位との差 — 内訳を見る
順位そのものより学びが多かったのは、1位チーム(No Man's Sky、スコア 10.629)との差の内訳です。インスタンス別に完了タスク数を比べると、差は一様ではありませんでした。
| インスタンス | Rovnou | 1位 | 倍率 |
|---|---|---|---|
| orz | 4,895 | 21,348 | 4.36 |
| rand-A | 6,642 | 19,964 | 3.01 |
| iron | 57,045 | 132,694 | 2.33 |
| fulfill-B | 32,065 | 71,560 | 2.23 |
| maze-B | 208 | 237 | 1.14 |
迷路系(maze)ではほぼ並んでいるのに、広くて混雑が支配的なマップほど差が開いています。毎ティックの衝突回避ではそれほど負けておらず、混雑をどれだけ先読みして捌くかという上位の層で差がついた、と読んでいます。
優勝チームの解法から学んだこと
優勝した No Man's Sky チームは解法を公開しており、大会後に読み込みました。印象に残った点を挙げます。
- メインスレッドはディスパッチャに徹し、重い探索はすべてバックグラウンドで並列実行する
- シミュレータを忠実に再現した World モデルで未来を予測し、通信間隔の合間に計画を前倒しで作っておく
- EPIBT の拡張(EPIBTX)で初期解を作り、並列 LNS/ALNS で改善し続ける
- 開発プロセスとして、**「一度に一つの変更だけを入れ、マップごとに計測して採否を決める」**を徹底している
最後の一点は、ちょうど同じ時期に isutools を作って private-isu をチューニングしていたときの結論と同じでした。分野が違っても、上位に行くほど「推測ではなく計測で決める」に収束するようです。
ふりかえり
1人チームで3ヶ月、上位と競り合えたこと自体は素直に良かったと思っています。一方で、8位と1位のあいだにある約2倍の差は、アルゴリズムの知識だけで埋まるものではありませんでした。予測・並列化・マップ別チューニングを支える計測基盤と開発プロセスの差、と言うほうが実感に近いです。
このコンテストで作った交通管制のスタックは、Rovnou として倉庫ロボティクスの実環境に向けて発展させていく予定です。競技のスコアが実環境の安全性を証明するわけではないので、そこは分けて考えつつ、知見は引き継いでいきます。
リンク
- 公式サイト: leagueofrobotrunners.org
- 会社発表: League of Robot Runners 2026 参加結果(BreakAI)
- 同時期の計測駆動の話: private-isu で50万点を超えるまで with isutools