異なるメーカーのロボットを同じ現場で動かすために、全機を一つの中央AIで直接操縦する必要はない。上位システムはタスク、経路、扉、エレベーター、充電器といった共有資源を調整し、各メーカーの制御器は走行、衝突回避、非常停止を受け持つ。この分担を成立させるには、共通APIの接続だけでなく、座標・状態・エラーの意味、最小権限、データ利用規則、障害の封じ込めまでそろえる必要がある。
同じ監視画面に並ぶだけでは統合フリートにならない
管制画面にA社のAMRとB社のサービスロボットが同時に表示されても、タスクを引き継げず、同じエレベーターを安全に予約できなければ、実態は監視の一本化に近い。マルチベンダー運用では、各ロボットの能力を記述し、上位オーケストレーターがタスクを割り当て、実行状態と失敗理由を共通の意味で受け取れるところまで接続する。
Open-RMF公式サイトは、Open Robotics Middleware Frameworkを、複数のロボットフリートと扉・エレベーター・ビル管理システムの共有・相互運用を支える、無料でオープンソースのモジュール型システムと説明する。病院向けに始まり、オフィス、空港、港湾、商業施設、工場、物流センターにも適用できるとしている。接続点を提供するフレームワークであることと、個別現場でプラグ・アンド・プレイ互換が保証されることは別である。
| レイヤー | 共通化する項目 | メーカー・現場側に残す項目 |
|---|---|---|
| 業務 | タスク種別、優先度、完了・取消の意味 | ロボットごとの実行可能作業と制約 |
| 移動・資源 | 地図基準、経路競合、扉・エレベーター・充電の予約 | ローカル障害物回避とリアルタイム安全制御 |
| 状態・エラー | 待機・実行・中断・復旧状態とエラー等級 | メーカー固有の診断・保守手順 |
| 統制 | 認証、権限、監査、データポリシー | 機器鍵、安全認証、現場の非常停止 |
上位タスクとリアルタイム安全制御を切り分ける
中央オーケストレーターは「3階の薬品保管庫から検査室へ搬送」のようなタスクを適切なフリートへ割り当て、移動経路と共有資源の利用順序を決める。一方、車輪を何rpmで回すか、人を検知してから何ms以内に停止するかは、ロボット内の制御器と独立した安全装置が担う。
この境界を守れば、ネットワークが一時的に途切れても、ロボットは人を避けて安全に停止できる。中央サーバーが関節や車輪をリアルタイムで直接制御すると、通信遅延やサーバー障害がそのまま現場の危険へつながる。メーカー固有の安全機能を上位ソフトウェアが迂回できないよう権限を制限する。
上位命令には有効期限も要る。10秒前に受けた「通路へ進入」という命令を通信復旧後にそのまま実行すると、すでに別の機器が入った通路で衝突しかねない。ロボットは現在状態を改めて報告し、新しい承認を得てから動く。
座標・状態・エラーの意味をアダプターでそろえる
二台のロボットが同じ地図を使っていても、原点、階高、通過可能な扉幅の定義は異なり得る。A社は目標点から半径20cm以内を「到着」、B社は1m以内を「到着」と判定するかもしれない。座標変換、許容誤差、ロボット外形、速度制限を共通スキーマで定めなければ、画面では到着済みなのに作業台へ手が届かない事態が起きる。
状態名にも意味の変換が必要だ。「paused」が安全停止なのか、オペレーター待ちなのか、「failed」が自動再試行できるエラーなのか、現場回収が必要な故障なのかはメーカーごとに違う。フリートアダプターはメッセージ形式を変えるだけでなく、状態遷移と復旧可能性を共通の定義へ対応付ける。未知の新しいエラーコードを「正常」にせず、隔離状態へ送る。
バージョン管理もアダプター設計に含める。ロボットのファームウェアやAPIが変われば、従来の状態コードや経路応答が変化する可能性がある。対応バージョン、互換性試験、ロールバック可能なアダプターパッケージをロボット別に保管し、夜間更新後にフリート全体が止まる事態を防ぐ。
タスク送信前には能力ネゴシエーションも行う。同じ「搬送」ロボットでも、最大積載量、通過幅、利用可能階、ドッキング装置、冷蔵ボックス対応が違う。上位システムは固定されたモデル名ではなく、その時点でロボットが報告する能力と状態を基に割り当てる。情報が古い、または必須能力が欠けていれば送信しない。能力記述が変わった際は、アダプターと配車ルールを一緒に試験する。
扉・エレベーター・充電器のデッドロックを解く
マルチベンダー現場で難しいのは、ロボット同士の会話より、数の限られた設備を分け合うことだ。別々のフリートが異なる階から同じエレベーターを予約したり、低残量のロボットが一斉に充電器へ向かったりすると、資源のデッドロックと長い待ち時間が生じる。通路、扉、リフト、作業台を予約可能な資源としてモデル化する。
予約には開始・失効時刻、所有者、失敗時の解放規則を設定する。ロボットがエレベーター内で通信を失い、予約が永久に残れば他フリートも止まる。反対に失効が早すぎれば移動中に利用権を失う。実移動時間の分布と最悪条件を基に期限を設計する。
優先度ポリシーも現場業務に合わせる。病院で緊急検体搬送と廃棄物運搬を同じ順序で待たせてはならない。ただし高優先度タスクが続き、通常作業が永久に後回しにならないよう、最大待ち時間と手動調整手順を設ける。
デッドロック試験は、狭い通路の両端で二台が互いの譲歩を待つ場面から始める。どちらが後退するか決められない場合、中央オーケストレーターが安全な待機地点と迂回経路を指定する。エレベーターと充電器の予約を同時に持つロボットのように複数資源が絡む場合は、取得順序を固定するか、一部予約を解放する規則が要る。処理量を多少落としても、現場全体を止めないことを優先する。
オープンAPIは最小権限と署名で守る
オープンであることは、誰もが任意の命令を送れることを意味しない。受注システムにはタスク作成だけ、ビルシステムには扉・エレベーター状態だけ、保守アカウントには指定ロボットの診断だけを許可する。運転命令と非常停止の解除には、より強い認証と承認手順を求める。
機器とサービスごとに固有IDを発行し、相互認証した通信を使う。命令へ送信者、対象、時刻、失効、署名を付け、再送や改ざんを検知する。鍵の流出やベンダーアカウントの侵害時は、そのフリートだけを遮断し、他のロボットは運用を継続できるようにする。
アダプターやプラグイン自体もサプライチェーン攻撃の経路になり得る。配布パッケージの出所と署名を検証し、必要なネットワーク・ファイル権限を一覧管理し、新版は隔離した試験フリートで先に動かす。脆弱性が見つかった際、該当バージョンを導入したロボットとサーバーをすぐ特定できるよう、ソフトウェア資産と配布系譜を維持する。
Fujitsuによる日本のPhysical AI協業に関する公式発表は、2026年7月16日、FANUC、Yaskawa Electric、Kawasaki Heavy IndustriesとNVIDIAの技術を統合する協調制御プラットフォームの事業機会を検討し始めたと伝えた。適用範囲の拡大に伴い、サイバー攻撃、システム全体の停止・誤動作、機密情報流出のリスクが増えるとも明記する。開発・標準化の方向を示した段階であり、完成済み汎用プラットフォームの商用性能を発表したものではない。
データ主権はサーバー所在地だけで決まらない
データ主権は、データをどの国へ保存するかだけを決める概念より広い。センサー原本を誰が閲覧できるか、ベンダーが障害解析やモデル学習へ使えるか、派生特徴量とモデルを国外へ移せるか、契約終了後にどう削除するかまで管理できる能力を指す。
Fujitsuは、デジタル世界と物理世界をつなぎながら主権を確保する協調制御基盤を、オープンプラットフォームとして発展させる方針を示した。製造、物流、医療では、それぞれ工程上の秘密、販売・在庫、患者の移動といった機微情報を扱う。ロボット座標だけでも生産量や施設構造を推定できるため、映像ファイルだけを保護しても足りない。
| データ項目 | 契約・技術統制で定める内容 | 確認する証拠 |
|---|---|---|
| リアルタイム位置・状態 | アクセス主体、保存期間、外部転送範囲 | 権限表とアクセス監査ログ |
| 映像・センサー原本 | 最小限の収集、マスキング、学習利用への同意 | データ系譜と削除試験 |
| エラー・保守ログ | ベンダーごとの閲覧範囲と事故共有 | 事案別の閲覧・持出し記録 |
| 派生データ・モデル | 所有権、再利用、国外移転、契約終了時の扱い | バージョン別の出所と廃棄確認書 |
SEER RoboticsによるWRC 2026戦略発表も、ロボットモデル、制御・フリート層、データネットワークをつなぐ方向を示す。ベンダーの統合構想は参考になるが、データ権利とエクスポート可能性は、顧客契約と実際のAPIで別途確認する必要がある。
一台の障害を他フリートへ波及させない
統合システムの失敗は、全ロボットが同時に停止する形で現れ得る。中央スケジューラー停止時に進行中タスクを安全に完了させるか停止させるか、扉サーバー障害時にどの区域を閉鎖するか、特定ベンダーのAPIが遅い時に全キューを塞がないかを先に決める。
サーキットブレーカーとタイムアウトはフリート単位で設定する。応答しないロボットは隔離しても、他フリートにはタスクを割り当て続ける。中央システムの復旧後は、ロボットの実位置とタスク状態を再照会し、サーバーに残る古い状態で上書きしない。最後に正常だったデータより現場観測を優先する。
オフライン運用の範囲も限定する。通信がなくてもローカル制御で避けられる障害物と、上位予約なしでは進入させないエレベーター・狭路を分ける。非常停止はネットワークと無関係に作動させ、解除は現場を確認した担当者だけが行う。
異なる二台から始め、意味と復旧を先に検証する
最初のパイロットには、異なるメーカーのロボットを一台ずつと共有設備を一つだけ入れる。同じピックアップ・ドロップオフのタスクを50回以上繰り返し、座標誤差、状態遷移、資源待ち、遠隔介入を記録する。成功後は通信断、扉の無応答、バッテリー不足、未知のエラーコードを意図的に起こし、隔離と復旧を確認する。
Open-RMFによる複数ロボット連携、VDA 5050 3.0規格ガイド、VIOとSLAMの比較を併読すると、設備連携、メッセージ規格、位置推定の違いを具体的に点検できる。
拡張前には、新しいロボット一台を接続するためのアダプター開発時間、互換性試験、セキュリティ審査、障害復旧訓練を費用へ含める。「規格対応」というチェック欄より、実際のメッセージ版、オプション機能、メーカー固有エラーの対応付けを見る。複数ベンダーの価格、サポート、データ条件が契約書上で衝突していないかも確認する。
拡張後は処理量と障害分離能力を並べて見る。フリート全体の処理量だけでは、特定ロボットの長時間待機や優先度による飢餓が隠れかねない。メーカー別のタスク成功率、待ち時間、アダプターエラー、設備予約競合、手動復旧を個別に集計し、全体指標と並べる。更新後は旧版からの退行をフリート別に調べる。
セキュリティ指標には、遮断した命令、失効した証明書、過剰権限、異常なデータ持出しを含める。データ主権ポリシーは文書確認だけで終えず、削除と持出し遮断を実行して検証する。障害訓練では、中央サーバー、特定ベンダーのクラウド、ビルシステムを順に切り離し、安全状態とサービス継続範囲を測る。
マルチベンダー運用の成熟度は、一画面に並べたロゴの数では決まらない。新しいベンダーを加えても共通の意味を維持でき、一箇所の失敗を隔離し、現場所有者が命令とデータの統制権を持ち続けられるかが判断基準となる。
よくある質問
A社のAMRとB社のサービスロボットが同じ管制画面に出れば運用統合は完了か
監視は一本化できても、それだけでは足りない。タスク割当て、状態・エラーの定義統一、扉・エレベーター・充電器の予約、失敗後の復旧までベンダーをまたいで連携して初めて、実運用の統合に近づく。
Open-RMFやVDA 5050へ対応したロボット同士はそのまま接続できるか
そのまま互換とは限らない。規格のバージョンとオプション機能、座標系、状態遷移、メーカー固有エラーコード、安全責任を実メッセージで試験する。同じ規格名でも実装範囲は異なり得る。
複数メーカーへ開くロボットAPIを安全に運用する条件は何か
機器別の固有ID、相互認証、最小権限、署名と失効期限付き命令、監査ログ、フリート単位の遮断を組み合わせる。オープンかどうかより、誰がどの命令をどの条件で送れるかを制御できることが重要だ。
確認した公式資料
最終確認：2026年8月23日