AMR–WMS連携：タスクはどこで生まれ、ステータスはどこに返るか——3つのパターンを比較

結論を先に：AMR–WMS連携では、APIを書く作業は全体の約20%にすぎません。残りの80%は、搬送タスクを誰が生成し、車両のステータスをどの層が受け取るかを決めることです。

私は30件以上のWMS本稼働をリードし、そのうち9件はAMR案件でした。そのまま使える選定ルールをお渡しします。単一ベンダーのロボットが10台未満なら、WMSから直接駆動させましょう。10～50台、単一ベンダーなら、ベンダーのRCS（ロボット制御システム）を中間に置きます。50台超、または混在ベンダーのフリートなら、タスクプール層を構築します。現場の経験則であり、標準ではありません。

なぜ「誰がタスクを作り、誰がステータスを受け取るか」に帰着するのか。WMSはビジネスの言葉を話します——どの受注、どのロケーション、どの商品か。RCSは車両の言葉を話します——どのロボットが空いているか、どの通路が塞がっているか、どのバッテリーが切れかけか。連携とは、この二つの間の翻訳です。誤訳すれば、貨物は間違った場所へ行きます。

AMR–WMS連携の3パターンを横並びで比較

パターン1：WMS直接駆動——インターフェースは最少、台数が増えると破綻する

仕組み：WMSが搬送タスク（AからBへ）を各ロボットに直接割り当て、ロボットが「完了」を返します。

向いている場面：10台未満の固定ルートのパイロット——例えば、受入れから保管へ、2レーンでフルパレットを運ぶような案件です。

破綻する場面：WMSはロボットがどこにいるか、バッテリー残量、前方の通路が塞がっているかを知りません。2023年、蘇州の3Cアクセサリー倉庫——12,000平方メートル、リフト型AMR18台をレガシーWMSに直結。稼働2週目、WMSが40件超のタスクを一気に投下し、6台のロボットが通路の入口で詰まり、スタッフが手でほぐすのに30分かかりました。もっと厄介なバグ：WMSのタスクにタスク種別フィールドがなく、ロボットが入庫と補充を区別できなかった——補充パレットが出荷ドックへ行ってしまいました。

対策：間に薄いタスクキューサービスを挟みました——WMSはタスクを投げ入れ、サービスがロボットの空き状況・バッテリー・位置で割り振ります。代償：本稼働が6週間遅れました。

この失敗は3回見ました。直接駆動が間違いなのではなく——フリートが小さく、ルートが単純で、タスクの種類が均一なときにだけ安全なのです。

パターン2：RCSを中間に——AMR–WMS連携の現在の主流

仕組み：WMSは業務タスクのみを発行します（「パレットP123をロケーションA-01-02からドックD3へ移動」）。RCSがそれを車両移動に分解し、ロボットを割り当て、経路を計画し、充電を管理します。ステータスは合意した契約に沿ってRCSからWMSへ返ります。

10～50台、単一ベンダーなら、現時点で最も安定した選択肢です。WMSは車両を理解する必要がなく、RCSは業務を理解する必要がありません。

ただ、ほぼ全員がはまる落とし穴があります。ステータスマッピングです。2024年、広州・南沙の越境EC倉庫——フォーク型AMR32台が2ベンダー、RCSが2インスタンス、その上にWMSが1つ。ベンダーAのRCSはタスク状態を3つしか報告せず（実行中、完了、エラー）、ベンダーBは9つありました。ベンダーAの「一時停止」が「完了」と翻訳され——パレットがまだ建物の真ん中にいるのに、WMSはすでに入庫済みとして計上してしまいました。60パレット超の差異、棚卸しで1日がかりの突き合わせになりました。

対策：統一ステータスマッピング表です。ベンダーのRCSが出す状態が何であれ、WMSに届く前に8つの標準状態——待機中、実行中、一時停止、エラー、完了、キャンセル、タイムアウト、手動介入——に集約しなければなりません。表の所有者はWMSチーム、RCSベンダーは遵守、契約の付属書として入れます。この失敗は3回見ました。3回目で、ようやく契約前に書き込みました。

パターン3：タスクプール——大規模・混在フリート向けの重装備

仕組み：独立したタスクオーケストレーションサービス（タスクプール）がWMSと各ベンダーのRCSの間に座ります。WMSは業務タスクを投げ入れ、プールがベンダーをまたいで割り当てて全体最適の配車を行い、ステータスはプールが集約してからWMSへ返ります。

向いている場面：50台超、または混在ベンダーのフリートに踏み切った倉庫です。見返り：後でAMRベンダーを切り替える際、WMSに触らずプールのドライバーを変えるだけで済みます。

代償：タスクプール自体が誰かが保守すべき新しいシステムであり、単一障害点でもあります。落ちればフロア全体が止まるので、高可用性が必要です。連携＋テストは、私の経験では3～6か月かかります。

反直感的な真実：開発は決して高くつく部分ではない

反直感的な結論です。AMR連携プロジェクトでは、API開発は通常、総工数の5分の1程度です。予算を燃やすのは、結合テストで業務ロジックが噛み合っていないと分かることです。例：WMSは「タスク完了」を「貨物が到着した」と定義し、RCSは「ロボットが到着した」と定義する。ロボットが到着して完了を報告し、貨物はまだ背中に乗ったまま。帳簿が狂います。

こうした問題は、要件定義のときに質問を一つ増やすだけで死にます。結合テストの段階で見つかれば、WMSチーム・RCSベンダー・現場チームの三者三様の言い分が数週間続く泥仕合になります。私の流儀：契約を結ぶ前に「完了」の定義を付属書に入れ、両者が署名します。前倒しの気まずい会話は、本稼働前夜の怒鳴り合いよりましです。

もう一つ、忘れられがちなこと。充電タスクは誰が出すのか。RCSであり、WMSではありません——WMSはどの充電器が埋まっているかを知りません。あるプロジェクトでは、WMSが電池残量の少ないロボットをスケジュールで充電に向かわせ——8台のロボットが4台の充電器に並び、タスクがタイムアウトしました。充電はRCSに任せ、WMSはタイムアウト通知だけ受け取ればよいのです。

本稼働前夜のチェックリスト：すべてにチェックを

タスク配送：

1. すべてのタスクにグローバル一意IDを持たせ、同じIDの再配送は冪等（正確に1回だけ実行）にすること。
2. すべてのタスクにタスク種別（入庫／補充／出庫／移庫）を持たせること。RCSの推測は禁止。
3. タスクのタイムアウト値は双方で合意すること。タイムアウト時、WMSはキャンセルでき、RCSはそれに従わなければならない。
4. ロボットが貨物を載せたままタスクがキャンセルされた場合、貨物の扱いを明示したルールが必要。

ステータス返却： 5. 8状態マッピング表は双方が署名し、契約に添付すること。 6. RCSはWMSにハートビートを送ること（約1秒に1回、または同等）。ハートビートが約30秒超止まったら、WMSはアラームを上げること。 7. 失敗したステータス報告はローカルにキャッシュして再送すること——ステータスの取りこぼしなし。 8. 「手動介入」は必ず報告すること——人間がそのロボットを運転していることをWMSが知る必要がある。

例外とフロア： 9. 充電タスクはRCSが出すこと。WMSが直接充電を命令することはない。 10. 緊急停止、荷崩れ、落下物などのイベントは、合意した時間内にWMS（または当番の電話）に届けること。 11. 手動介入の後、タスクを再開するか無効にするかは、事前に書いたルールで決める。 12. ネットワーク喪失時のロボットのデフォルト動作（その場待機か充電器へ戻るか）は事前に決める。

データ整合： 13. ロケーションコードはWMSとRCSで完全一致——大文字小文字、ハイフン、一文字たりとも。 14. パレットバーコードのルールを一致させること。RCSがスキャンするコードはWMSが認識できなければならない。 15. ドック、充電器、ステージングエリアは両システムで一対一に対応した名称にすること。

負荷テスト： 16. ピークシーズンのタスク量の1.5倍を4時間連続で回し、渋滞とタイムアウト率を監視すること。 17. 3つの障害——RCSダウン、WMSダウン、単体ロボット故障——をシミュレーションし、それぞれの復旧手順を歩くこと。 18. 帳簿と現場を突き合わせること。テスト中に50パレットをランダムに選び、WMSの帳簿上のロケーションと物理的なロケーションが一致しなければならない。

チェックリストは飾りではありません——本稼働前夜、一つひとつにチェックを入れ、所有者に署名してもらいましょう。貴社サイト特有のケースは上に追加してください。

Lin Xiao（WMS導入コンサルタント）著

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