"「RCS vs WMS：あなたのAMRフリートを本当に指揮しているのは誰か」"

一つのタスクから辿る：RCS vs WMS の連鎖

RCS vs WMS の議論は、一つの搬送タスクから始めて、その流れを追ってみよう。

ライドヘイリングを想像してみてほしい。WMS は乗客、RCS は配車アルゴリズム、AMR はドライバーだ。乗客が言うのは「パレットをAからBへ運んで」だけ——どの車が来るか、どのルートか、交差点で誰が譲るか、乗客は一切触れない。

倉庫も同じだ。WMS は業務ドキュメントの持ち主——出庫オーダーでスロットAから 20 個ピッキングして梱包ステーションへ届ける必要がある。WMS は「搬送タスク」を生成する：起点、終点、貨物情報、優先度、時間ウィンドウ。それを RCS に渡す。RCS はフリートディスパッチャーの仕事をする：どの AMR が十分なバッテリーを持ち、起点に一番近く、空いているか。ルートを計画する。二台のロボットが一つの交差点を取り合おうとしたら、RCS が交通整理をして、片方に譲るよう指示する。AMR は与えられた経路をただ走り、障害物で止まり、バッテリーが減ったら充電器に戻る。

三層構造、きれいな連鎖だ：WMS がタスクを発行 → RCS がロボットを配車しルートを管理 → AMR が実行。これを正しく押さえれば、責任のなすりつけ合いの 90% は起きない。

責任分担マトリクス：誰の仕事かを曖昧にしない

RCS vs WMS の分担を一つの表にまとめた。プロジェクトのキックオフで壁に貼っておこう——少なくとも三ヶ月分の言い争いを節約できる：

鉄則は一つ：WMS が個々の AMR に直接指示を出すことは絶対にない。WMS が言うのは「A から B へ物を運びたい」。RCS が「ロボット7号は通路3を行け」と決める。かつて、WMS ベンダーが「軽量ディスパッチャー」を作ってロボットに直接コマンドを送り、RCS も同じフリートを配車していたのを見たことがある。一台のロボットが矛盾する二つの命令を受け取り、その場で 40 分間回り続けた。二人の上司、一台の混乱したロボット。

選定の分岐点：独立型 RCS に値する規模とは

これが一番よく聞かれる質問であり、最大の「見せかけ需要」ゾーンだ。まず一発：AMR が 5 台以下なら独立型 RCS はいらない。以上。

小さな倉庫の 5 台のロボットでは、交通の衝突はほぼ起きない。ベンダー内蔵のフリートマネージャで十分だ。そこに六桁の金額を払って独立型 RCS を入れるのは、五人のスタートアップに人事部を雇うようなもの——金は使い、何も増えない。

分岐点は三つの線で引く——フリート規模とシナリオの複雑さだ。

**第一の線：フリート規模。**5 台未満ならベンダー内蔵の配車で十分。5〜20 台ならシナリオの複雑さ次第。20 台超なら独立型 RCS はほぼ必須。次の二つの線の方が重要だ。

**第二の線：マルチブランドのフリート。**一つの倉庫に二つ以上の AMR ブランドが混在したら、独立型 RCS は交渉の余地なし。各ベンダーのディスパッチャは自社のロボットにしか話しかけない——ベンダーAのシステムはベンダーBのロボットの交通整理ができない。VDA 5050 のような標準インターフェースで各フリートと話す、中立な RCS をマスターディスパッチャとして置く必要がある。単一ブランド？ベンダー純正のディスパッチャの方がサードパーティの RCS より大概スムーズに動く——独自プロトコル、カスタムチューニングだ。

**第三の線：タスクの複雑さ。**純粋なポイント間移動ならシンプルな配車で足りる。だがマルチロボット協調（二台のリレーで一つの特大貨物を運ぶ）、動的優先度の割り込み、充電とタスクの統合スケジューリング——ここで内蔵ディスパッチャは天井にぶつかる。良い RCS はアルゴリズムで元を取る：チューニングが良ければフリート稼働率は 95% 以上を維持する。チューニングが悪ければ、20 台のロボットが 10 台分のスループットしか出さない。

三つの線を引いた、一つのフレームワーク：単一ブランド + 20 台未満 + ポイント間移動 = 独立型 RCS は不要。三つの線のうち二つに当てはまったら、買え。

実録その一：インターフェースの責任が曖昧で、双方がなすりつけ合い

2023 年、中国東部の eコマース倉庫：AMR 12 台、WMS と RCS は二つのベンダー。ゴーライブから三週間、出庫タスクが次々タイムアウトした。WMS ベンダー：「タスクはとっくに発行している——RCS が遅い」。RCS ベンダー：「五分遅れで受け取っている——WMS が遅い」。

二週間の言い争い。私は二つのシステムの間にログ層を追加し、「タスク発行」と「RCS 受信」のタイムスタンプを記録した。データが真実を語った：タスクが WMS から RCS に届くまで平均 4 分 37 秒かかっていた。犯人はミドルウェアのメッセージキュー——WMS ベンダーが「負荷平準化」のために配信をバッチ化し、RCS 側のインターフェースには配信確認がなかった。どちらも嘘をついていない。どちらにも落ち度があった。

教訓：**WMS-RCS 間のインターフェース契約は三つを定義しなければならない——タスク発行のリアルタイム要件（たとえば 3 秒以内）、RCS の配信確認、タイムアウトとリトライの仕組みだ。**この三つを技術付録に書き込めば、次の揉め事はログで一分で決着する。

実録その二：「交通整理は誰がやる」の正面衝突

2024 年、中国南部の 3PL 倉庫：6,000 平米に AMR 18 台、一番狭い通路は 2.2 メートル。ある朝、積載した二台の AMR が狭い通路で正面衝突し、両方とも緊急停止、誰かが手で一台を動かすまで 20 分間デッドロックした。その日、約 300 件のオーダーがカットオフに間に合わなかった。

事後分析で見つかった：RCS の交通ロジックでは狭い通路が双方向に設定されていた。実装時に誰かが広い通路のテンプレートをコピペしたせいだ。WMS の方は？通路が狭いことなど知らなかった——WMS の世界にはマップが存在しないのだ。

直感に反する結論：**RCS vs WMS の最大の地雷は「誰が配車するか」ではなく「誰がマップを保守するか」だ。**マップ——通路幅、一方通行か双方向か、立入禁止ゾーン、充電器の位置——は RCS の中核資産だ。だがマップの変化（どこかに置かれたパレット、メンテナンス中の通路）に最初に気づくのは現場の人だ。連鎖はこうあるべきだ：現場スタッフ → WMS（オペレーションが毎日使うシステム）→ RCS に同期。あまりに多くのプロジェクトで WMS と RCS がそれぞれマップを持ち、三ヶ月もすれば二つは一致しなくなる。

対策：RCS のマップを唯一の真実の源とする。WMS はタスクを発行し、マップには絶対に触れない。現場の変化は標準プロセスで 24 時間以内に同期する。マップが乖離した日が、ロボットがデッドロックする日だ。

保守の落とし穴：ゴーライブはスタートラインに過ぎない

RCS の最大の落とし穴は選定ではなく、運用にある：

**第一に、充電戦略をチューニングする人がいない。**RCS のデフォルトは大抵「20% を下回ったら充電」だが、20 台が同時にバッテリー切れになったら、充電器の行列が納期を吹き飛ばす。正しいアプローチは波動ベースの充電だ：ウェーブの合間にまとめ充電し、ピーク中はロボットを 30% 以上に保つ。実際のウェーブデータでチューニングすること。

**第二に、MTBF の数字を読む人がいない。**ベンダーのデータシートの MTBF はラボデータだ。あなたの現場の実 MTBF は自分のフロアで測るものだ。RCS は各ロボットの故障履歴をすべてログしている——毎月引っ張って見よう。MTBF が一番速く落ちているロボットは、そろそろホイールか LiDAR の交換が必要だ。壊れるまで待つと、予防保守の五倍のダウンタイムコストがかかる——三つのプロジェクトの修理請求書から割り出した。

**第三に、RCS と WMS のアップグレードがずれる。**WMS がアップグレードしてタスクインターフェースのフィールドを変える。RCS は追随しない。タスク発行がエラーを吐き始める。二つのベンダーなら、アップグレードのたびに合同インテグレーションテストが必要だ——運用 SOP に書き込め。「後方互換性」の約束を絶対に信じるな。現場での失敗率は 100% だ。

その金は価値があるか？この一つの数字を見よ

最初の問いに戻ろう——RCS vs WMS、AMR を指揮するのは誰か？階層型コマンドだ：WMS はビジネスの持ち主、RCS はフリートの持ち主。一文で：WMS が「何を運ぶか」を決め、RCS が「どう運ぶか」を決める。

独立型 RCS が金の価値があるかは、一つの数字に帰着する：フリート効率 = 実際の完了タスク数 ÷（ロボット台数 × 一台あたりの理論最大タスク数）。前後一ヶ月ずつ測れ。15% 以上上がれば——金は正しく使われた。10% 未満なら——独立型 RCS など要らなかった。ベンダー内蔵のディスパッチャで十分だったし、その予算でロボットを二台買えたはずだ。

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

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