複数台AMRの群制御とフリート管理

エグゼクティブ・サマリー

• AMRの導入で最も多い誤算は、1台のスループットに台数を掛け算して計画してしまうことである。実際には台数の増加とともに1台あたりの生産性は逓減し、ある台数を超えると総搬送量そのものが伸びなくなる。
• 逓減の原因は機体側にはほとんどない。通路幅・退避スペース・充電器の位置・エレベーターや自動ドアの待ち行列・上位システムとの通信頻度という、現場側とシステム側の制約が先に飽和する。
• 群制御は一枚岩ではなく、①経路計画（どの道を通るか）②交通調停（誰が先に行くか）③タスク割付（誰がその仕事を取るか）の3レイヤーに分けて設計する。トラブルの切り分けはこの3層のどこで起きたかを言えるかどうかで決まる。
• 充電は「余った時間に行う作業」ではなく搬送計画と同格のスケジュール対象である。充電計画を後回しにしたフリートは、繁忙ピークの直前に一斉に充電へ向かうという最悪の挙動を示す。
• 異機種・異メーカーのAMRを混在させる場合、調停の主権をどこに置くかを契約前に決める。ここが曖昧なまま複数社を並べると、障害時に責任の所在が定まらず、現場が人手で交通整理する運用に戻る。

複数台のAMR（自律走行搬送ロボット）を運用する現場は、この数年で確実に増えた。1台や2台の実証は各所で成功しており、機体そのものの走行性能・安全性能はすでに実用水準にある。にもかかわらず「10台入れたのに期待した搬送量にならない」「時間帯によって極端に遅くなる」という相談が絶えない。原因はほぼ共通していて、機体を選ぶ検討には時間をかけた一方で、複数台が同時に動いたときに何が起きるかを設計していないという点にある。

本稿は、AMRの群制御とフリート管理を、ロボットを売らない中立の立場から実務手順として整理したものである。特定のメーカーやフリート管理ソフトウェアを推奨するものではなく、どの製品を選ぶにせよ発注側が自ら決めておくべき論点を扱う。

1. 台数が増えると何が非線形に効いてくるのか

複数台化の計画で最初にやるべきは、線形の前提を捨てることである。1台で1時間あたり12往復できたとしても、10台で120往復にはならない。ここで効いてくる要素は次の5つに整理できる。

この表の右列は現場によって変わるが、重要なのはボトルネックが機体ではなく「共有資源」にあるという構造である。通路も、交差点も、エレベーターも、充電器も、ステーションも、すべて複数台で奪い合う資源である。フリート管理とは突き詰めれば、この共有資源をどう配分するかという問題に他ならない。

したがって台数計画は、機体のカタログ性能からではなく、共有資源の容量から逆算する。単路の本数、交差点の数、エレベーターの基数と1回あたりの所要時間、充電器の数と充電時間。これらを先に数え、「この現場で無理なく回るのは何台までか」を出してから機種選定に入る。順序を逆にすると、買った台数を現場に押し込むための無理な運用ルールが生まれる。

2. 群制御を3つのレイヤーに分けて理解する

「群制御」という言葉は便利だが、そのままでは設計にも障害切り分けにも使えない。実務では次の3層に分けて考える。

レイヤー1：経路計画（Path Planning） 出発地から目的地までどの経路を通るかを決める層である。固定ルート方式（あらかじめ定めた経路網の上だけを走る）と自由走行方式（地図上で都度最短経路を探索する）に大別される。自由走行のほうが柔軟に見えるが、複数台環境では経路が予測できないぶん交通調停の負荷が上がる。台数が多い現場ではむしろ、主要動線を一方通行として設計した固定ルート寄りの運用のほうが安定することが多い。

レイヤー2：交通調停（Traffic Control） 同じ空間を複数台が使おうとしたとき、誰を先に通すかを決める層である。区画（ゾーン）を単位に排他制御をかける方式が一般的で、1つの区画には1台しか入れないという制約で衝突とデッドロックを防ぐ。ここで設計すべきは、区画の切り方の粒度と、優先度のルールである。区画を大きく取れば安全側だが待ちが増え、細かく取れば流れるが制御は複雑になる。

レイヤー3：タスク割付（Task Allocation） 発生した搬送要求を、どの機体に割り当てるかを決める層である。最も近い機体に割り当てる単純な方式から、充電残量・現在のタスク・予測混雑度まで見て割り当てる方式まで幅がある。ここが弱いと、「空いている機体が遠くにいるのに近くの機体が別作業で埋まっている」という無駄が常態化する。

現場でスループットが出ないとき、この3層のどこが原因かを言えるかどうかが、改善速度を決める。待ち時間のログを層別に取れる製品かどうかは、機種選定時に必ず確認すべき要件である。「なんとなく遅い」から抜け出せない現場は、たいていこのログを持っていない。要件定義の進め方は要件定義書のつくり方も併せて参照されたい。

3. 通路とトラフィックの設計——現場側でやるべきこと

群制御ソフトウェアがどれだけ賢くても、通れない場所は通れない。フリートの性能を決める要因のうち、かなりの部分は現場レイアウト側にある。

設計時に確認すべき項目を挙げる。

• すれ違い可能幅の確保：機体幅×2＋余裕。主要動線のうち何％がすれ違い可能かを図面上で色分けし、単路区間を可視化する。単路が長いほど待ちは指数的に増える。
• 一方通行の設定：全域を双方向にすると調停が難しくなる。ループ状の一方通行を主動線に敷き、支線だけ双方向とする設計が扱いやすい。
• 退避スペース：単路の途中に待避所を設けるだけで、正面衝突による相互待ちが大きく減る。数メートルのくぼみで効果が出る。
• 交差点の数を減らす：動線が交わる箇所は待ちの発生源である。レイアウト変更の余地があるなら、交差を減らす配置を優先する。
• 人との共有区間の明示：人が頻繁に横切る区間では、AMRは減速する。減速区間が主動線上に多いと計画所要時間が崩れる。人の動線とロボット動線を分離できるところは分離する。
• 段差・スロープ・床面：床の継ぎ目、グレーチング、水濡れ区間は走行安定性と位置推定に影響する。実測で洗い出す。

これらは新設拠点なら設計段階で織り込める。既存拠点への導入では、レイアウト側を1ミリも変えない前提で計画を立てないことが重要である。棚を1列動かす、通路を30センチ広げる、といった現場側の小さな改修が、ソフトウェアのチューニングより効くことは珍しくない。倉庫での具体的な進め方は今後の別稿で扱う。

4. 充電計画をスケジュールの一部として設計する

複数台運用で最も軽視され、最も痛い目を見るのが充電である。1台なら「休憩時間に充電する」で済むが、10台になると充電は完全にスケジューリング問題になる。

設計すべき論点は次のとおりである。

特に重要なのが充電開始しきい値の一律設定を避けることである。全機体を同じ残量で充電に向かわせると、稼働開始時刻が揃っている以上、消費もほぼ同じペースで進み、結果として同じタイミングで一斉に充電へ向かう。これが繁忙ピークと重なると搬送能力が突然半減する。機体ごとにしきい値をずらす、あるいはタスク量から予測して前倒しで充電させるといった平準化を、運用設計の段階で決めておく。

バッテリーは消耗品であり、容量は年単位で落ちる。導入時にちょうど回る充電計画は、2年後には回らない。計画時点で1〜2割の余裕を織り込むことと、劣化状況を定期点検の項目に入れることを、保守契約とセットで設計する。保守設計の考え方はロボットの保守と稼働率を参照されたい。

5. 異機種・複数メーカー混在をどう扱うか

現場が拡張していくと、必ず異機種混在の局面が来る。用途が違えば最適な機体は違うし、複数年にわたる導入では同一機種を買い続けられるとも限らない。ここで問題になるのが、誰が交通を調停するのかである。

取りうる構えは大きく3つある。

A. 単一ベンダーで統一する 最も単純で、初期は最も安定する。ただし将来の選択肢を狭め、価格交渉力も落ちる。「今後5年、この現場の搬送はこのメーカーで固定する」という経営判断として明示的に選ぶなら妥当だが、なんとなくそうなっている状態は避けたい。

A’. 空間で分離する エリアやフロアごとにベンダーを分け、境界のステーションで荷を受け渡す。調停の主権を分けてしまう方式で、実務的な折衷案として機能する。境界での受け渡し設計が要になる。

B. 上位のフリート管理層を立てる 複数メーカーのAMRを1つの上位システムが束ねる構成である。近年、AMRの相互運用に関する標準的なインターフェースを採用する製品が増えており、この構成は現実味を増している。ただし「標準に対応している」と言っても対応範囲は製品ごとに異なるため、どのコマンドが送れて、どの状態が取れるのかを機能単位で確認する必要がある。カタログの一行だけで判断してはいけない。

どの構えを取るにせよ、契約前に決めておくべきことは共通している。障害発生時の一次切り分けを誰が行うか、複数社にまたがる不具合の調査費用は誰が持つか、上位システムの改修が必要になったときの費用負担はどうするか。この3点を書面にしないまま複数社構成に進むと、現場が人手で交通整理する運用に戻る。マルチベンダー体制の組み方はマルチベンダー統合で詳しく扱っている。

6. 上位システムとの接続——WMS/MESとの責務分界

AMRのフリートは単体では価値を生まない。何をどこへ運ぶかという指示は、倉庫管理システムや生産管理システムなど上位から来る。ここで設計すべきは責務の分界点である。

分界の基本形は、上位が「何を・どこからどこへ・いつまでに」を出し、フリート管理が「どの機体が・どの経路で」を決めるという分担である。上位が機体を名指しで指定する設計にすると、フリート側の最適化余地が消え、群制御の意味がなくなる。逆にフリート側に業務優先度の判断まで持たせると、業務ルールの変更のたびにロボット側の設定変更が必要になる。

接続時に必ず決めるべき項目：

• タスクの優先度の表現方法（数値か、締切時刻か）
• タスクのキャンセル・変更が可能なタイミングと、その挙動
• 異常時のふるまい（搬送中に上位が落ちたらどうするか、逆はどうか）
• 実績の返し方（いつ「完了」とみなすか。荷を置いた時点か、確認が取れた時点か）
• 通信断が起きたときの再同期手順

特に「完了」の定義は現場と情報システムで認識がずれやすい。在庫数の不整合はここから生まれる。データ連携の全体設計はロボットデータ基盤を参照されたい。

7. フリート運用のKPIと当直体制

複数台運用は「入れて終わり」にならない。運用が始まってからの管理指標を先に決めておく。

このうち現場で最も軽視されるのが手動介入回数である。ロボットが動いていても、人が頻繁に荷姿を直したり退避させたりしているなら、省人効果は帳消しになっている。日次で数えて、介入理由を分類する運用を最初から入れる。KPI設計の考え方はロボット導入のKPI設計で体系的に扱っている。

体制面では、一次対応者を現場に置くことが複数台運用の前提になる。1台なら止まってからメーカーを呼んでも間に合うが、10台の現場で1台の停止が動線を塞ぐと、他の9台まで止まる。よくある停止事象（荷崩れ、障害物、位置推定のずれ、通信断）の一次対応手順を現場が持ち、それ以上はメーカーへ、という二段構えを設計する。この体制づくりは定着化と運用設計の考え方がそのまま適用できる。

8. 導入プロセスのどこで何を決めるか

RobiZyが整理している導入7工程に、本稿の論点を配置すると次のようになる。

とりわけ②の段階で「実機1台のPoC」だけで判断しないことを強調しておきたい。1台のPoCで確かめられるのは走行性能と安全性であって、フリートとしての性能ではない。可能なら複数台での検証を、それが難しければ少なくともシミュレーションでの検証を、選定条件に入れる。PoCの設計方法はPoCの設計に詳しい。

9. よくある失敗と、その手前で打てる手

• 台数をカタログ性能の掛け算で決めた：共有資源の容量から逆算し直す。台数を減らして稼働を上げるほうが総搬送量が伸びる場合がある。
• 充電器を主動線上に置いた：充電中の機体が通路を塞ぐ。設置場所は動線から外す。
• 全機体の充電しきい値が同じ：一斉充電が起きる。しきい値をずらすか、予測型の充電計画に変える。
• 待ち時間のログが取れない：層別のログ取得を選定要件に入れておく。後付けは難しい。
• 上位システムが機体を名指しで指定している：フリート最適化の余地が消える。責務分界を引き直す。
• 一次対応者がいない：1台の停止が全体を止める。現場の一次対応手順を整備する。
• 拡張の前提を決めずに1社目を入れた：将来の混在時に調停の主権で揉める。構想段階で拡張シナリオを言語化しておく。

これらはいずれも、機体を選ぶ前の構想・要件定義の段階で手が打てるものである。導入が失敗する典型パターンはロボット導入が失敗する理由にも整理している。

まとめ

複数台AMRの成否は、機体の性能ではなく共有資源の設計で決まる。通路・交差点・昇降設備・充電器・ステーションという有限の資源を、経路計画・交通調停・タスク割付という3つの層でどう配分するか。この設計を発注側が理解して要件に落とせているかどうかが、10台入れて期待どおり動く現場と、動かない現場を分ける。

そして重要なのは、これらの論点の多くが機種選定より前に決まっているという点である。台数、レイアウト、拡張の前提、責務分界。ここを曖昧にしたまま製品比較を始めると、比較軸そのものがずれる。

RobiZyはロボットを販売しないNPO法人であり、特定のメーカーや製品の利害を持たない中立のコーディネーターとして、構想策定から要件定義、選定、定着化までを伴走している。台数計画の妥当性を第三者の目で確認したい、複数社の提案をどう比較すればよいか分からない、既に導入したフリートが思ったように動かない——そのいずれの段階でも、まだ構想の入り口であっても、無料のご相談を歓迎している。何を決めるべきかを整理するところから、一緒に始めていただきたい。