異種ロボットを同じ現場で動かすフリート連携：タスクAPI・交通管制・設備接続の分離

Mon, 12 Oct 2026 14:44:01 +0900

異なるメーカーのロボットを同じ現場で動かすとき、標準プロトコルだけで全てが解決するのかが設計上の焦点になります。

先に結論

複数メーカーのAMRや搬送ロボットを同じ現場で運用するには、単一の巨大なAPIへ機能を集約するのではなく、業務タスク、フリート・交通管制、ロボット固有の実行、設備接続を別レイヤーに分けることが基本です。VDA 5050などの標準は、上位の制御システムとロボットを接続するアダプターの境界で使い、メーカー差分をアダプター内に閉じ込めます。

ドア、エレベーター、コンベヤーなどは、タスク層からPLCやメーカー固有コマンドを直接呼び出さず、設備アダプターを介して共通リソースとして公開します。通路や交差点を複数フリートが共有する場合は、予約と交通管制の権限を一つの調停主体へ集約する構成を有力な候補として検討します。

なぜインターフェースを分けるのか

WMSやMESなどの業務システムが扱うのは、搬送、ピッキング、充電といった業務要求です。ロボットの走行には、機体の能力、地図、経路、状態、手動介入などの情報が必要になります。さらに複数フリートが同じ空間を共有する場合は、通路、交差点、ステーション、エレベーターの予約と交通協調が必要です。

設備も単純な「開ける」「呼び出す」コマンドではありません。利用要求、予約またはリース、使用開始、完了、解放、タイムアウト、異常という状態を持つ共有資源です。業務アプリケーションと機器を直結すると、メーカー変更や設備更新の影響が上位の業務ロジックまで及びます。

標準技術の役割

VDA 5050は、上位のMaster ControlとAGV・AMRの間の通信インターフェースを定義し、MQTTを介してJSON形式のメッセージを交換します。2.0.0相当の仕様では、NodeとEdgeによる経路表現やAction、注文識別子を含むOrder、State、InstantActions、Visualization、Factsheetなどを扱います。ただし、現場全体で誰が最終的な交通管制権限を持つかまでは一律に決めません。

Open-RMFは、複数のロボットフリートや建物設備を協調させる枠組みです。ベンダーごとのFleet ManagerをFleet Adapterで接続し、RMF側の要求や交通協調の情報を各フリート固有APIへ変換するとともに、ロボットの状態や進捗をRMFへ戻します。

MassRobotics AMR Interoperability Standardは、AMRの位置、状態、バッテリーなどを、他のAMRや周辺システムと共通形式で共有することを主な対象とします。注文を送り実行させるVDA 5050と、完全に同じ範囲ではありません。

MQTTは軽量なPublish/Subscribe型プロトコルで、トピックやQoSなどの配送機能を定義しますが、ロボットタスクや設備占有の意味論は定義しません。OPC UAは情報モデル、サービス、クライアント・サーバー通信、PubSubなどを定義するため、設備側の共通インターフェースを構築する基盤候補です。ただし、設備が必要な情報モデルや仕様を実装しているかは個別確認が必要です。

推奨アーキテクチャ

最上位にWMS、MES、または業務オーケストレーターを置き、その下にタスク正規化層を設けます。ここではタスク識別子、搬送元・搬送先、必要な能力、優先度などを扱います。

次に交通・リソース調停層を配置します。共有通路、交差点、ステーション、エレベーターの予約を管理し、各フリートへ利用許可や交通上の要求を伝えます。ローカル制御だけで共有資源を扱う場合は、競合解決の方法と責任境界を明示します。

その下にメーカー別Fleet Adapterを置き、共通タスクや交通上の要求をVDA 5050、ベンダー独自API、または対象フリートの実装へ変換します。ロボット固有の走行制御、状態、Action、手動介入の差は、この境界で吸収します。

設備側には設備リソースAPIと設備アダプターを置きます。設備リソースAPIは、ドアやエレベーターを共有資源として公開し、その下でOPC UA、MQTT、PLC接続、メーカー独自インターフェースを設備ごとに扱います。

flowchart TB
  subgraph business["業務層"]
    WMS["WMS・MES・業務オーケストレーター"]
  end

  subgraph common["共通制御・正規化層"]
    TASK["タスク正規化層\nタスクID・搬送元/先・能力・優先度・期限"]
    TRAFFIC["交通・リソース調停層\n共有通路・交差点・ステーション・エレベーター"]
    RESOURCE["設備リソースAPI\n要求・予約・占有・完了・解放・異常"]
  end

  subgraph fleet["ロボット連携層"]
    FA1["メーカー別Fleet Adapter A"]
    FA2["メーカー別Fleet Adapter B"]
    VDA["VDA 5050またはベンダー独自API"]
    ROBOT1["ロボットフリート A"]
    ROBOT2["ロボットフリート B"]
  end

  subgraph equipment["設備接続層"]
    EA["設備アダプター"]
    CONNECT["OPC UA・MQTT・PLC接続・設備固有インターフェース"]
    DEV["ドア・エレベーター・コンベヤーなど"]
  end

  WMS --> TASK
  TASK --> TRAFFIC
  TASK --> FA1
  TASK --> FA2
  TRAFFIC --> FA1
  TRAFFIC --> FA2
  FA1 --> VDA
  FA2 --> VDA
  VDA --> ROBOT1
  VDA --> ROBOT2
  TRAFFIC --> RESOURCE
  TASK --> RESOURCE
  RESOURCE --> EA
  EA --> CONNECT
  CONNECT --> DEV

業務タスク、共有空間の交通・リソース調停、メーカー別ロボット実行、設備接続を別レイヤーに分離した推奨構成。

設備利用の流れは、要求、予約またはリースの取得、ロボットの到着、使用開始、完了、解放です。到着できない、設備が応答しない、通信が切れるといった場合は、タイムアウトや異常として通知し、占有をいつ解放するかを定義します。

VDA 5050 on Physical AI Hub

異種ロボットを同じ現場で動かすフリート連携：タスクAPI・交通管制・設備接続の分離

先に結論

なぜインターフェースを分けるのか

標準技術の役割

推奨アーキテクチャ