去年の秋、天津郊外の3PL倉庫を訪ねた。42台のAMR、2つのブランド、それぞれが独自のフリートソフトで動いている。オペレーション責任者は中央の交差点を指さして言った——「毎日午後4時、交差点で渋滞、時間通りに起きるんだ」。両ブランドのロボットが互いに譲り合い、誰も進まない。デッドロックだ。オーナーはロボットに大金を投じたのに、たった一つの問題に負けた。3つのドライバー集団、3つの頭脳、誰も他を聞いていない。RCS vs WCSの倉庫構成——固定設備を誰が指揮し、フリートを誰が指揮し、本当に統合ロボット頭脳が必要になるのはいつか——が混乱しているなら、この記事が整理する。三つのレイヤー、一つの表、私が見た二つの失敗、そして明日から使える購入ライン。
RCS vs WCS vs WMS：三つのレイヤー、一つではない
これらの頭文字を混同する人が多い。してはいけない。三つのレイヤーであり、階層が重要だ。
WMSは頂点に立ち、会計をする。在庫は正しいか、どの受注を先に出荷するか、タスクはどこから来るか。出すのは指示だけだ——「パレットAをスロット1からドック3へ移動」。ルートをどう走るか、どのロボットが行くかには関心がない。
WCS——倉庫制御システム——は床にボルト止めされた設備を動かす。コンベア、ソーター、リフト、シャトル。PLCとミリ秒単位で話し、リアルタイム制御の仕事をする。ベルトがいつ回るか、ソーターがどのシュートに落とすか。固定ラインの生産監督と思えばいい、タクトを見守る。
RCS——ロボット制御システム——は動くものを動かす。AMR/AGVフリートだ。四つの仕事：タスク割当（どのタスクをどのロボットに）、交通管制（交差点で誰が先に行くか）、充電スケジューリング（どのロボットがいつ充電するか）、マップ管理。アナロジーはこうだ。WMSはゼネラルマネージャー、WCSはライン監督、RCSはフリートのキャプテン。GMが気にするのは貨物が届くことだけ。トラック同士がぶつからないようにするのがキャプテンの仕事だ。
これが倉庫における本当のRCS vs WCSの違いだ。一つは固定設備を指揮し、もう一つは動くフリートを指揮する。設備は動かないからタクトの問題。ロボットは動くから優先権の問題。
RCS vs WCS vs ベンダーのフリートソフト：一つの表
| WCS | RCS | ベンダー独自のフリートソフト | |
|---|---|---|---|
| 制御対象 | コンベア、ソーター、リフト——固定設備 | AMR/AGVフリート、ブランドを跨げる | 自社ブランドのロボットのみ |
| 中核業務 | PLCリアルタイム制御、タクト同期、インターロック | タスク割当、交通管制、充電スケジューリング、経路計画 | ロボット単位のステータス、基本ディスパッチ |
| 指令元 | WMS、設備レベルのタスク | WMS、輸送タスク | WMSまたはRCSの引き渡し |
| 典型的な失敗 | 自分の設備しか知らない | ブランド横断で統合されなければ無用 | 交差点で各ブランドが勝手に振る舞う |
ベンダーのソフトは、各分隊が自分の軍曹を連れてきたようなものだ——自分の分隊には十分だが、隣の分隊には無用だ。10台未満、単一ブランドなら軍曹で十分だ。ブランドが混ざった瞬間、全軍曹を束ねるキャプテンが必要になる。そこに独立RCSが位置する。
マルチブランドフリートになぜ統合RCSが要るのか
まず直感に反する話から。統合RCSなしで3ブランドのAMRを買うのは、互いに言葉の通じない3つのドライバー集団を雇うようなものだ。各集団は自分のキャプテンの言うことしか聞かない。交差点で会えば互いを責め合い、塞がれるのはあなたの通路だ。
2024年の天津の倉庫の根本原因はこれだった。2ブランド、各20数台、それぞれ独自のディスパッチソフト、独自のマップ、独自の交通ルール。ブランドAのロボットは自分に優先権があると信じ、ブランドBも同じことを信じていた。毎日の出荷ピーク時：20〜30分のデッドロック。繁忙期に8台追加したら悪化した——ロボットが増えれば増えるほど渋滞はひどくなった。直感に反する核心はここだ。RCSの問題を解決するまで、ロボットを増やしてもスループットは増えない。混雑が増えるだけだ。
解決策はVDA 5050だ。簡単に言えば、ドイツ自動車工業会が推進するオープンなインターフェース標準で、異なるブランドのロボットが一つのRCSから指令を受けられるようにする。一つのタスク形式、一つの交通管制ロジック。異なる国のドライバーに同じ交通法規を渡すようなものだ——車がどこで造られたかは関係なく、赤は止まれだ。天津の現場は後にVDA 5050対応の統合RCSを導入し、両ブランドが同じ交通管制に入り、交差点のデッドロックは基本的に消えた。ロボット1台あたり1シフトの搬送回数はおよそ20パーセント上がり、繁忙期に追加した8台はようやくコストを稼げるようになった。（ロボットの仕様はベンダーによって異なる——メーカー公表のパラメータで確認すること。）
胡散臭さ検知タイム：8台の単一ブランドロボットでベンダーソフトが問題なく動いているのに、誰かが「統合RCSプラットフォーム」を売り込んできたら——ドアを示せばいい。それは蚊を撃つ大砲だ。
購入ライン：独立RCSが値する時
そのまま使える意思決定フレームワーク：
- 10台未満、単一ブランド：ベンダーソフトで十分だ。独立RCSは金の無駄だ。
- 10〜30台、または2ブランド混合：交差点の複雑さを見ろ。主通路の交差、充電ボトルネック、複数階の搬送——RCSが元を取り始める。交差しない単純ルートなら？待ってよい。
- 30台以上、または3ブランド混合：独立RCSはほぼ必須だ。抜きにすると毎日の渋滞が確定する。
- 固定設備＋フリート引き渡し（コンベアがAMRに供給）：ロボットの台数に関係なく、WCS/RCSのインターフェース境界は入札書類に明記しなければならない——誰がタスクを主張し、誰が完了を報告するか、一字一句。次に書く災害ゾーンだ。
もう一つ皆が見落とすこと：充電スケジューリング。RCSの充電管理は「空になったら充電に行け」ではない——どのロボットがいつ、どれだけ充電し、ピーク能力を維持するために何台が稼働を保つかを計算する。ベンダーソフトは普通その計算ができない。
二つの頭脳、一つの倉庫：私が見た失敗
2023年、広東のEC倉庫：コンベアとソーターはWCS、30台超のAMRはRCS、頂点にWMS。本稼働後最初の週、出荷エリアは大混乱だった。WMSが一つの搬送タスクをWCSとRCSの両方に送り、両方が主張した——コンベアが荷物を運び、AMRも取りに来て、荷物は二重に「納品」され、書類が合わなくなった。根本原因：インターフェース境界が定義されていなかった。WMSはWCSが設備だけ扱うと思い込み、WCSは搬送タスクも取るべきだと思い込んだ。繁忙期前夜に2時間のダウン。オペレーション責任者の顔がすべてを物語っていた。
教訓は一言：タスクは一つ、主張する頭脳も一つ。WMSがディスパッチするとき、ルーティングルールは明示的でなければならない——固定設備の区間はWCSへ、移動搬送の区間はRCSへ、引き渡し点（例えばコンベアの終端）はWCSの仕事がどこで終わりRCSがどこで始まるかを正確に定義する。
もう二つ、じわじわ効く失敗。一つ：マップを誰も保守しない。棚が動いた、パレットが一時置きされたのに、RCSのマップは3か月前のまま——ロボットは古いマップで新しい棚に真っ直ぐ突っ込んだ。RCSのマップはレイアウト変更のたびに動かさなければならない。レイアウトを変えたら、まずマップを変える。鉄則だ。二つ：Wi-Fiのローミング。ロボットが一つのアクセスポイントから別のものに切り替わると数秒切断され、RCSはそれを「ロスト」と宣言し、そのルート上の全ロボットが待機で停止する。倉庫の無線カバレッジとローミング切り替えは、ロボットの連続稼働に対して試験しろ——オフィスWi-Fiの基準で採点するな。
投資に見合うか？この一つの数字を見ろ
RCSが投資に見合うかどうか——ベンダーの話は聞くな。一つの数字を見ろ。ロボット1台あたり1シフトの実効搬送回数だ。
統合RCSを入れる前に、1週間分のディスパッチログを抜き、ロボットが待機に費やす時間の割合を計算しろ——人を待つ、優先権を待つ、充電器を待つ。その数字が20%を超えたら、フリートの時間の大半は相互待機に食われている。それこそRCSが取り戻せるものだ。本稼働後に再測定しろ。搬送回数が15%以上上がれば、その金は正解だった。変化なしなら、問題はディスパッチではなかった——タスクプール自体が薄かったのかもしれない。
持ち帰りの一問：あなたの倉庫で、AMRは1日のうちどれだけの時間を単に……待っているのか？その数字は通常、ディスパッチ画面にそのまま出ている。誰も見ていない。
Da Liu（自動化エンジニア）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
