ロボット犬 ↔ AGV/AMR 協調配車システムソフトウェア・横断参考リスト——仙工以外に誰が参考になるか（オープンソース框組 openTCS / Open-RMF × VDA5050 標準 × 商用ベンチマーク × 国産 RCS × 単機ナビ Nav2・全外部リンク curl 検証）

⚠️ 継続確認中の自社開発参考草案。 戦略前提（社長 2026-06-29 決裁）：ロボット犬と AGV/AMR の協調作業システムソフトウェアは自社開発、仙工 SEER は参考ベンチマークの一つに過ぎない。本稿は仙工以外に、国内外で「ロボット犬 ↔ AGV/AMR 協調 / 多機配車 / フリート管理」システムソフトウェアとして自社開発の参照になり得るものを横断し、各社ごとに「アーキテクチャ / 外部インターフェース / オープンソースか / 参考になるか / 四足を取り込めるか」を提示する。全ての外部リンクは curl 実測済：政府サイトの 000=地域ブロック、商業/ニュースサイトの 403=ブラウザ UA 必須、いずれも有効な公式ページとして扱い、デッドリンクではない；判断のつかないインターフェース/ライセンスの詳細は一律 UNVERIFIED と明記し、捏造しない。姉妹篇：仙工 SEER 框組分解・自社開発参考。

🧭 一言総覧

横断した結果、本当に「自社開発カーネルの青写真」として使えるのは二つのオープンソース框組——openTCS と Open-RMF；VDA5050 は対標する価値のある通信標準（ただし 2D ホイール式のみ対象）；OTTO / MiR / Spot Orbit / ANYmal 等の商用システムは本体クローズドで、アーキテクチャと外部インターフェースの範式のみ借用可能；国産倉庫 RCS（HAI Robotics/Quicktron/Geek+/ForwardX/Hikrobot/Enotek）は概してクローズドで、基本的に自社車のみ配車・四足非対応；宇樹（Unitree）と DEEP Robotics は単機 SDK のみで完成品フリートソフトがない——これがまさに「ロボット犬 × AGV/AMR 異種協調配車レイヤ」が実在する市場の空白であり、自社開発の差別化余地であることを裏付ける。単機ナビゲーションは再発明せず、Nav2 を直接使う。

🔍 オープンソース框組（自社開発の最も直接的な参考）

openTCS（Fraunhofer IML、MIT）— 自社開発配車カーネルの青写真

ドイツのフラウンホーファー物流研究所がオープンソース化したフリート級配車・制御プラットフォームで、AGV/AMR フリートを制御し、「抽象走行モデル + 運搬オーダー管理 + 経路計算」を提供する¹。

アーキテクチャ三点セット：Kernel（カーネル）——中央制御プロセス、工場モデルの保持、運搬オーダー管理、経路計算；Plant Overview——グラフィカルフロントエンド、新版は Model Editor（モデリング） と Operations Desk（運用） に分割；Kernel Control Center——カーネルの管理/監視、車両通信アダプタのマウントと構成¹。
差し替え可能な戦略三点セット：Dispatcher（タスク配車）/ Router（経路計算）/ Scheduler（資源排他） がいずれも置換可能——これこそ自社協調コアが構築すべき三層の能力である。
車両ドライバ機構：車種ごとに一つの communication adapter（通信アダプタ） を持ち、抽象カーネルインターフェースと車両固有プロトコルの間を翻訳；ハードウェアなしのシミュレーション用に loopback adapter を同梱。
外部インターフェース：① Java RMI サービス API；② HTTP/JSON Web API（REST 風、運搬オーダーの作成/取消、車両/オーダー状態の照会、X-Api-Access-Key 認証、OpenAPI 仕様ファイルあり）；③ イベント /events（ロングポーリング）+ 新版 /sse（Server-Sent Events）¹。
オープンソース + ライセンス：完全オープンソース、現行ソースコードは MIT（ドキュメントは CC-BY-4.0）；初期に LGPL/GPL を使っていたかは UNVERIFIED だが、現行 MIT は確認済。
VDA5050：公式が同梱するアダプタ opentcs-commadapter-vda5050（VDA5050 1.1/2.0、JSON over MQTT、MIT を実装）²——「南向きは VDA5050 で AGV に接続」が成熟した工業ルートであることを証明する。
四足を取り込めるか：理論上は可能——車両は「Point/Path/Location トポロジーグラフ上を移動する運搬体」として抽象化され、ホイール式/脚足式に対する仮定がない；ロボット犬用に comm adapter を書き、到達可能空間を点位トポロジーとしてモデル化する必要がある。限界：モデルの本質は「グラフ上の点から点への運搬」であり、ロボット犬の自由地形巡検、越障/階段昇降等の連続運動の意味を離散トポロジーに完全に当てはめるのは難しい。
何を参考にするか：差し替え可能な通信アダプタ（異種ハードのデカップリングの鍵、loopback シミュレーションは必須）+ Dispatcher/Router/Scheduler 戦略抽象 + モデル駆動（モデリング/運用の分離）+ 外部インターフェースの階層テンプレ（内部 RMI + 外部 REST + イベントストリーム + OpenAPI + API Key）。

Open-RMF（Open Robotics、Apache-2.0、ROS 2 上）— 異種協調の最も直接的な範例

ROS 2 の上に構築された再利用可能なライブラリとツール群で、「異種マルチベンダー・多種類ロボットフリートの相互運用」を実現し、ビル設備（ドア、エレベーター、料站）も協調に取り込む；スローガンは "A Common Language for Robot Interoperability"、2024 年以降は OSRA が維持³。

階層アーキテクチャ：RMF Core——rmf_traffic（トラフィック制御：グローバル共有の予約式 schedule + 衝突予測 + マルチフリート negotiation による衝突回避）、rmf_task（タスク割当）、rmf_battery（電量モデリング）；Fleet Adapter 層（フリート/ベンダーごとに一つのアダプタで接続）；インフラ統合層（door/lift/dispenser アダプタ）；rmf-web（ブラウザ dashboard + REST/HTTP API server、デフォルト 8000、Swagger/OpenAPI 付き）⁴。
Fleet Adapter 三段階統合（最も価値ある設計パターン、かつ同一デプロイ内での混在をサポート）⁵：
- Full Control：RMF が経路を指定/中断、リアルタイム衝突回避可能（EasyFullControl 簡易版あり）；
- Traffic Light：RMF は一時停止/再開のみ（EasyTrafficLight）；
- Read-Only：フリートは FleetState を上報するのみ、RMF は予測して回避するのみ；
- Mixed：上記レベルが共存、統一プランニング。
外部インターフェース：rmf-web REST API server（/docs Swagger、軌跡 WebSocket、task API HTTP を含む）；下層コンポーネントは ROS 2 topics/services 経由。
オープンソース + ライセンス：完全オープンソース、Apache-2.0（copyleft 感染なし、コードと設計を直接借用可能）。
異種：コアの売りがまさに multi-fleet/multi-vendor、awesome_adapters は約 18 個の Full Control アダプタを列挙（MiR、Gaussian、Temi、TurtleBot、Clearpath、LionsBot 等）⁷；VDA5050 とはブリッジ可能な関係（コミュニティに実験的な VDA5050 fleet adapter があるが、非公式コアで成熟度は自己評価が必要）。
四足を取り込めるか：可能、かつ RMF が openTCS/VDA5050 に対して持つ決定的優位——RMF は「ナビゲーション可能な任意の移動ロボット」を抽象化し、ロボット犬を一つの fleet として自社開発 adapter 経由で接続（経路を受領/置換でき位姿をリアルタイム上報→Full Control；一時停止/再開のみ→Traffic Light；初期は見られて回避されたいだけ→Read-Only）し、ホイール式 AMR + 第三者車と同一プールで配車、トラフィックスケジュールの共有、ドア/エレベーターの共用が可能。
何を参考にするか：Fleet Adapter 抽象 + 三段階統合（接続側の能力に応じた段階的導入）+ 集中型トラフィック制御と資源 negotiation + タスク割当/電量モデリング框組 + ドア/エレベーター/料站インフラ抽象。テンプレは fleet_adapter_template を参照⁶。

📊 通信標準：VDA5050

ドイツ VDA/VDMA 標準（現 v3.0.0、VDA + VDMA + KIT が策定）で、任意ベンダーの AGV/AMR が同一マスターと統一報文で通信できるようにする——「タスク配車/状態上報」をベンダー非依存のメッセージ契約に抽象化⁸。

プロトコルの本質：MQTT（≥3.1.1）+ JSON；topic 構造は interfaceName/majorVersion/manufacturer/serialNumber/topic；6 つの topic：order（マスター→車、node/edge 路網を含む）、state（車→マスター）、connection（last-will オンライン検知）、instantActions（即時コマンドのバイパス）、factsheet（車両能力の自己記述）、visualization（高頻度位姿）；ナビモデル = node/edge 有向グラフ + base/horizon の漸進的リリース；位姿は x,y,theta,mapId のみ（2D 平面 + 方位）⁹。
ライセンス（二重口径、導入時は区別が必要）：GitHub リポジトリは MIT 表記（schema 等の資産）だが、規範本文は VDA の著作権（出典明記の上で複製可）。
オープンソース実装（個別に確認）：libVDA5050++（車端+マスター両側のミドルウェアライブラリ、C++、主リポは cmraaron、Fraunhofer IML 主導）¹⁰；InOrbit/Ekumen connector（車端 ROS2↔VDA5050 ブリッジ、BSD-3）¹¹；berketunckal/VDA5050-FleetManagement（マスター/フリート側のオープンソース参考、Python+PostgreSQL）¹²；NVIDIA Isaac Mission Dispatch（VDA5050 互換のクラウドタスク配車）¹³。Meili FMS は非オープンソース（有償 license）、オープンソース参考には数えない。
四足：明確に 2D ホイール式向け——歩容/roll-pitch/越障/3D 姿勢/足端フィールドがなく、路網の仮定も非構造化地形に合わない → 四足は VDA5050 を意味骨格として借用（order/state/factsheet/instantAction）すべきで、直接のターゲットプロトコルにはしない。
何を参考にするか：標準化された order/state メッセージモデル（ベンダー非依存、バージョン管理、ホイール式/四足が意味骨格を共用し各自フィールドを拡張）+ MQTT デカップリング + connection last-will による切断検知 + factsheet 能力自己記述（四足は歩容/越障/姿勢の能力スロットを拡張可能）+ instantAction バイパスチャネル（四足の急停止/姿勢切替）+ base/horizon 漸進的リリースによる路権配分の考え方。

🏭 商用フリート管理 / ロボット運用システム（クローズドのベンチマーク）

本体クローズド、アーキテクチャと外部インターフェースの範式を借用し、コードは借りない。

OTTO Motors / Rockwell Automation（OTTO Fleet Manager）：2023 年に Rockwell が買収；トラフィック制御、タスク配車、フリート可視化を担う。コアの Fleet Manager はクローズドだが、VDA5050 connector はオープンソース化；OTTO 全系 AMR は VDA5050 認証済で、第三者マスターに取り込み可能¹⁴。四足：2D ホイール式のみ。参考：「業務システム → フリート管理 → 車（VDA5050+MQTT）」の三層デカップリング + オープンソース connector は VDA5050 ブリッジの参考コードになる。（注：公式に「REST」の文言が逐字で明言されていないため UNVERIFIED と表記。）
MiR Fleet（Teradyne 傘下、2018 買収）：イベント駆動アーキテクチャ、公式は 100+ AMR 対応を謳う；完全な REST API を提供（ERP/MES/WMS 向け）、かつ API ドキュメントに製品画面が埋め込まれ直接試行可能；クローズドだが VDA5050 Adapter（REST→MQTT 翻訳層）はオープンソース¹⁵。四足：2D ホイール式のみ。参考：「内部 REST + 外付け VDA5050 adapter」のデカップリングパターン——「内部は自社プロトコル、外部は VDA5050 で異種（ロボット犬含む）に接続」にまさに適する。（訂正：MiR は Teradyne 傘下で Zebra ではない；Zebra が買収したのは Fetch、後に Skild へ切り離し。）
Boston Dynamics Spot Orbit（旧 Scout）— 四足運用ベンチマーク：Spot 四足ロボット犬のサイト級フリート管理ソフトウェアで、タスク配車、巡検データ archiving、異常検知、自動帰巣、条件トリガーを担う；デプロイ三態（Cloud / オンプレ Site Hub 1U / VM-OVA）。外部インターフェース（逐字確認）：✅ 公式 REST API（/api/v0/ プレフィックス）+ Webhooks（HMAC-SHA256 署名を Orbit-Signature ヘッダに格納）+ Bearer Token¹⁶；ソフトウェア本体はクローズド、Spot SDK（Orbit API のサンプル含む）は GitHub BSD オープンソース。Spot のみ管理、VDA5050 なし。参考：REST + Webhook(HMAC-SHA256) + Token は自社開発の外部インターフェースの黄金テンプレ；「サイト + タスク配車 + 巡検 archiving + 異常検知 + 自動帰巣 + ワークオーダー統合」はそのままロボット犬側の機能の青写真にできる。
ANYbotics ANYmal — 四足ネイティブ：工業巡検四足 + フリート管理スイート、エッジで設備健康データを収集し暗号化アップロード、開発中の Workforce Suite（三ロール権限モデル）；外部は RESTful API（エンドポイント/認証の詳細は非公開、UNVERIFIED と表記）、ドキュメントは実際には Siemens 開発者ポータルにホスト；クローズド、Cognite/Yokogawa 等の資産管理/デジタルツインと統合¹⁷。自社のみ管理、VDA5050 なし。参考：「エッジ収集→暗号化→API で資産管理/デジタルツインにアップロード」のデータプロダクト化ルート + ロール別の階層権限。（注：「D-suite」という独立製品は検索で確認できず、命名は UNVERIFIED。）
DEEP Robotics（絶影）：四足ネイティブ、絶影 Lite3/X20/X30 は電力巡検、変電所、ケーブルトンネル、緊急対応向け；GitHub に単機 SDK あり（robotserver_sdk MIT、明確に「単台の犬のナビタスクを制御・監視」、XML/JSON over TCP）²¹。公開された汎用 fleet/多機配車 API は検索で確認できず（UNVERIFIED）。参考価値はシーン定義にあり、ソフト/API はインターフェースのベンチマークにはしない——国産四足が統一されたオープンなフリートソフトを欠くことをまさに裏付ける。
宇樹（Unitree）：公式の統一フリート/配車ソフトウェアなし、per-robot SDK のみ提供（unitree_sdk2、C++/Python、下層は CycloneDDS、ROS2 互換）、多機協調は自前構築が必要²⁰。（デマ訂正：ネット上の「Unitree fleet プラットフォーム」は第三者カスタム業者のマーケ文で非公式；eai.unitree.com はデータ/トレーニングプラットフォームで配車ではない。）参考：「単機 SDK のみでフリートソフトがない」のが常態であることを裏付ける——自社開発の協調/配車ソフトは実在する空白；宇樹をフリートメンバーに選ぶ場合はその DDS SDK をラップする adapter の自社開発が必要。

🇨🇳 国産倉庫 RCS / WCS（クローズド；コードでなくアーキテクチャ思想を借用）

概してクローズド商用、API 非公開、基本的に自社車のみ配車、四足非対応；オーダープール / タスク割当 / トラフィック制御 / WMS とのデカップリングのインターフェース設計が参考になる。

HAI Robotics（HAIQ）：配車コア HAIQ は WES（業務実行）+ ESS（設備配車 RCS）+ データ/シミュレーション/アルゴリズムプラットフォームを含み、独立稼働も既存 WMS への組込も可能；ESS 標準タスクインターフェース=発行/取消/変更/状態返送；自社 ACR/AMR のみ配車²²。参考：業務実行層 ↔ 設備配車層のデカップリング + 標準タスクインターフェース契約。
Quicktron（RCS）：RCS を「フリートの中枢神経」と位置付け、上流の WMS/ERP/MES/MIS/OMS/TMS とデカップリング、数百台級のトラフィックフロー最適化とデッドロック回避を主軸²³。参考：純 RCS と WMS のデカップリング境界（「自社開発は協調配車のみ」のルートに最も近い）+ 上流非依存の汎用タスクモデル。
Geek+（RMS）— 国産で「異種同一プール」に最も近い：RMS（配車）+ WES（実行）+ IOP（運用）の三層デカップリング；RMS は VDA5050 + Geek+ 自社プロトコルの二重対応を明言、パートナーの第三者ロボットを接続可能、同質/異質混合配車（単一現場 >5000 台）、オープン API + SDK を提供、ロボットモデリング能力で多形態の自社機種を統一配車²⁴。参考：三層デカップリング + VDA5050 二重対応 + ロボットモデリング（四足を新車種として異種配車に取り込むための鍵となる抽象）。
ForwardX（f(x)）：視覚 SLAM マーカーレスナビ（QR/反射板不要）+ クラスタ配車 + 人機協働ピッキング、上位の WMS/MES/ERP 接続に API あり²⁵。参考：QR/磁気テープ不要のナビ + 人機協働のタスク割当 + 上位システムとデカップリングした API 設計。
Hikrobot（RCS-2000）— 国産で標準化が最も進む：RCS-2000(V4.0)+RCS-Lite、多車種混合配車、二次開発四点セット（異種接続ローコードプラットフォーム iDataBus 含む）、国標 GB/T 43047-2023『物流ロボット制御システムインターフェース技術規範』を主導（発行済、原文照会可）²⁷。参考：インターフェース標準化ルート + ローコード業務オーケストレーション、南向きインターフェースは VDA5050 + 国標 GB/T 43047 の整合を両立可能。
Enotek（旧 Eoslift 意欧斯）：WMS/WCS + AGV 配車（ADS）、DBLink/webservice/TCP-IP/OPC に対応；クローズド、自社車のみ、四足非対応²⁸。参考：WMS ↔ 配車のデカップリング + 多プロトコル対応マトリクス。（注意：検索でよく出る ant-robots 蚂蚁配車は別会社で、Enotek とは無関係。）
VDA5050 の国産ローカライズ：業界は「国標 GB/T 43047 + 新松等の団体標準」ルートで自社インターフェース標準化を推進；Geek+ の明言を除き、他社の公式サイトで「VDA5050 + 異種第三者車を商用サポート」と明言したものは見られず、UNVERIFIED と表記、トレンドとしてのみ扱う。

🔧 単機ナビゲーション層 + システム境界（自社開発の位置付け）

ROS 2 Nav2（Navigation2）— 単機ナビ層、再発明しない：単一ロボットの自律ナビゲーションスタック（fleet adapter の下）、ビヘイビアツリーでオーケストレーションされるサーバ群（BT Navigator / Planner / Controller / Costmap / Recovery / Smoother / AMCL）；外部は ROS 2 Action が主（NavigateToPose 等）+ 全プラグイン化；Apache-2.0 が主（一部パッケージは BSD/LGPL、パッケージ単位で確認）；脚足(legged)シャシーを公式サポート³⁰するが、Nav2 は cmd_vel 抽象を出力するのみで、四足の歩容運動学はベンダー運動スタックが受ける。参考結論：単機ナビは Nav2 を直接使い、協調層は配車のみ担う（目標を発行し状態を購読、トラフィック/タスク配車/回避は自社協調層に残す）²⁹。
Fleet Adapter 設計パターン：「ベンダー/フリートごとに一つのアダプタ（腐敗防止層）」——配車カーネルはベンダー非依存、新しい機器の追加=新しい adapter の追加、コアはゼロ改修。自社開発は「ベンダー非依存配車カーネル + 機器種別ごとに一つの adapter」の階層をそのまま写すべき：ロボット犬は Nav2 action 経由の adapter、外部 AGV は VDA5050 経由の adapter を書き、特定ブランドの独自プロトコルを配車ロジックにハードコードしない。
WCS / WES / RCS / FMS / WMS の境界：WMS=業務/在庫（分〜時間）；WES=実行オーケストレーション（秒〜分）；WCS=固定自動化設備の協調（ミリ秒）；RCS/FMS=移動ロボットフリート配車（秒〜ミリ秒）。自社開発の位置付け結論：協調配車は明確に RCS/FMS 層に置く（犬+AGV/AMR の異種タスク配車 + トラフィック制御 + 回避 + 充電 + 監視）、上位は標準インターフェースで顧客既存の WMS/MES に接続（在庫/オーダーは作り直さない）、下位は fleet adapter（VDA5050 client 含む）で各種機器に接続、単機は Nav2 を使う。
WCS/WES 大手の境界（傍証）：Dematic（KION）iQ は WMS/WES/WCS を融合、移動ロボット配車は RCS/FMS で外接³¹；Siemens SIMOVE Fleetmanager は異種フリートの管理を明言（異なるブランドを VDA5050 等のプロトコルで統一管理）³²。共通点：大手は各機の navi/運動制御を書き直さず、WMS/WES/WCS に専念し、フリート配車を RCS/FMS に委ね、異種機器を VDA5050 で統一接続する——RCS/FMS 層がオープンな空白区であることを再び証明する。

🎯 自社開発への総括的アーキテクチャ提言

階層青写真：業務（WMS/MES）→ 自社協調カーネル（RCS/FMS：タスク配車 + トラフィック制御 + 回避 + 充電 + 監視） → Fleet Adapter（機器種別ごとに一つ）→ 単機ナビ（Nav2）→ ベンダー運動スタック/歩容制御。
コア設計パターン：Open-RMF の Fleet Adapter + 三段階統合（Full / Traffic-Light / Read-Only） を写す；openTCS の Dispatcher/Router/Scheduler 戦略抽象 + モデル駆動 + 通信アダプタ + loopback シミュレーション を写す。
外部インターフェース：Spot Orbit の REST + Webhook（HMAC-SHA256）+ Bearer Token を写す；openTCS の OpenAPI + API Key はテンプレになる。
南向きプロトコル：外部 AGV/AMR には VDA5050 を優先（OTTO/MiR のオープンソース connector の REST↔MQTT 翻訳層を参考、Open-RMF へブリッジ可能）；ロボット犬は VDA5050 が 2D ホイール式寄りのため、自社開発 adapter を採るべき（VDA5050 の order/state/factsheet/instantAction の意味を借用し、歩容/姿勢/越障フィールドを拡張）。
市場空白の裏付け：宇樹は SDK のみ、DEEP Robotics は公開汎用 API なし、国産 RCS はいずれも自社車のみ配車——「ロボット犬 × AGV/AMR 異種協調配車レイヤ」は実在する差別化余地。

⚠️ 正直な注記と訂正（執筆/顧客提示前に注意）

openTCS 現行 license = MIT は確認済；初期に LGPL/GPL だったかは UNVERIFIED。
libVDA5050++ の主リポは cmraaron、Fraunhofer IML 主導；Meili FMS は非オープンソース、本当のオープンソースマスター参考は berketunckal/VDA5050-FleetManagement。
VDA5050 ライセンスは二重口径：リポは MIT（schema）、規範本文は VDA の著作権。
MiR は Teradyne 傘下（Zebra ではない；Zebra が買収したのは Fetch）。
OTTO の「REST」の文言、ANYmal のエンドポイント級詳細、DEEP Robotics の汎用 API、多くの国産ベンダーの VDA5050 商用サポートはいずれも UNVERIFIED（ベンダー非公開）、捏造していない。
Open-RMF の VDA5050 fleet adapter はコミュニティの実験的なもので、非公式コア、成熟度は自己評価が必要。