異種メーカーのロボット接続で共通化できる層・できない層
倉庫や工場に複数メーカーの搬送ロボット（AGV／AMR）を導入すると、メーカーごとに位置表示画面、ステータス形式、ログが分断されます。上位のWMS／WCSへ稼働状態を送るアダプターもメーカー単位で増えます。
ここにクラウドのマネージドMQTTブローカーを導入すると、通信経路と機器認証は共通化できます。しかし、データ形式の正規化、切断復帰時の古い指示の破棄、交差点での優先制御はブローカーの機能には含まれません。本稿では、AWS・Azureのマネージドサービスに委譲できる範囲と、アプリケーション側で実装すべき範囲を国内の公開事例をもとに整理します。
レイヤーごとの責務分担
複数メーカーのロボット統合で発生する課題と、対応する設計レイヤーは以下の通りです。
| 発生する事象 | 必要な実装・設計 |
|---|---|
| 接続台数の増加に伴い、MQTTブローカーの死活監視や証明書管理の負荷が増える | AWS IoT CoreやAzure Event Grid MQTTへの移行、機器単位の証明書・Topic ACL設計 |
| メーカーごとに座標系・バッテリー残量・エラーコードの形式が異なり、同一画面で集計できない | 共通スキーマ（単位・座標系・タイムスタンプ）の定義と、各社APIとの変換アダプター |
| Wi-Fi切断中に送信された搬送指示が、回線復旧後に遅れて届き誤動作する | 指示メッセージへの有効期限（TTL）・シーケンス番号の付与と、期限切れ指示の破棄処理 |
| 全機体の位置が1つの画面で見えているのに、通路や交差点で鉢合わせして停止する | 空間の占有権管理（ミューテックス）、タスク割当、衝突回避経路の計算 |
前提として、各メーカーの機体またはローカル制御盤が位置・状態を取得するAPIやMQTTインターフェースを公開している必要があります。機器側が出力しないデータは、上位の通信基盤を変えても取得できません。
AWS・AzureのMQTT／エッジ基盤の比較
機器またはアダプターがMQTT 3.1.1／5で通信できる場合、クラウド側のエンドポイントとしてAWS IoT CoreとAzure Event Grid MQTTが候補になります。工場内のOPC UA対応設備（PLC等）からデータを収集する場合は、オンプレミスのKubernetes上で動くAzure IoT Operationsも選択肢に入ります（Microsoftの構成ドキュメント）。
| サービス | 実行環境 | 主な役割 |
|---|---|---|
| AWS IoT Core | クラウド | 機器認証、MQTTメッセージのルーティング、シャドウによる状態保持 |
| Azure Event Grid MQTT | クラウド | MQTTクライアント間のPub/Sub配信、Event Hubs等へのイベント転送 |
| Azure IoT Operations | 現場のAzure Arc対応Kubernetes | オンプレミスのOPC UA設備からのデータ収集、ローカルMQTTブローカーとデータフロー処理 |
AWS IoT CoreとEvent GridはどちらもMQTT 3.1.1およびMQTT 5をサポートしますが、クライアント認証方式、セッション保持時間、オフライン時のキュー上限、Topicフィルタの制約が異なります。既存のOSSブローカー（Mosquitto等）からエンドポイントURLを変更するだけでは移行できないケースがあるため、事前の仕様確認が必要です（AWS IoT Core MQTT仕様、Event Grid MQTT仕様、IoT Operations概要）。
国内の公開事例に見る構成パターン
以下は国内の公的実証および日本企業の公開事例です（当社の顧客・協業案件ではありません）。
1. デジタル庁：Event Gridによる位置収集と空間占有APIの分離
デジタル庁のロボット協調実証では、各ロボットからのMQTTメッセージをEvent Gridで受信し、Event Hubs経由で後続処理へ渡す構成が採られています（技術検証報告書 23〜24ページ）。
この実証アーキテクチャで注目すべき点は、テレメトリの収集・表示パイプラインと、エレベーターや狭路などの共有空間を予約する「空間占有管理API」が明確に分離されていることです。MQTTで位置情報を集約しても、どの機体に優先通行権を与えるかは別のサービスとして実装する必要があります。
2. KYB：リアルタイム性が不要な予知保全をクラウドへ集約
KYBの工場設備予知保全システムでは、AWS IoT Coreで設備データを収集しています。初期開発ではAWS IoT Greengrassを用いて工場エッジ側で異常判定を行っていましたが、予知保全の用途ではミリ秒〜秒単位の即時停止が不要であったため、最終的にクラウド側へ判定処理を集約しエッジ運用の負荷を下げています（AWS導入事例）。
安全停止や衝突回避のように低遅延が必須な制御はローカルに残し、傾向分析や稼働集計はクラウドへ寄せるという切り分けの具体例です。
3. 川崎重工業：ロボティクス基盤へのAzure IoT Operations採用（開発中）
2026年9月30日公開のMicrosoft事例では、川崎重工業が開発中のロボティクスプラットフォームにAzure IoT Operations、AKS、Cosmos DBを採用したことが報告されています（Microsoft導入事例）。ただし、同記事はプラットフォームを開発段階としており、IoT Operations単体での接続台数やOPC UA接続の詳細は公開されていません。
MQTTブローカー選定時の技術チェックリスト
マネージドMQTTブローカーを実運用へ入れる際は、単なる疎通確認ではなく異常系の挙動を確認します。
- 証明書更新とTopic権限： 機器ごとのX.509証明書のローテーション手順と、機体Aが機体Bの制御TopicへPublishできないACL設定。
- 回線断とTTL： 無線LANの瞬断時にブローカーが保持するメッセージ数・保持時間の上限。MQTT 5の
Message Expiry Intervalまたはペイロード内のタイムスタンプによる古い移動指示の破棄。 - QoS 1の重複配信と冪等性： QoS 1（At-least-once）はネットワーク再送時に同一メッセージが複数回届く仕様です。また、ブローカーのACKは「メッセージ到達」を意味し、「ロボットの移動完了」を意味しません。指示ID（Command ID）による重複排除と、完了通知Topicの往復設計が必要です（QoSとセッション仕様）。
- 課金体系： 接続台数だけでなく、位置情報の送信周期（例：1Hz vs 10Hz）、ペイロードサイズ、購読クライアント数（Fan-out）掛け算での月額試算。
- オンプレミスKubernetesの保守： Azure IoT Operationsを使う場合、現場サーバー上のArc対応KubernetesクラスタのOS・証明書・バージョン更新を誰が運用するかの責任分界。
メッセージ配信と交通管制（Rovnou）の境界
AWS IoT CoreやEvent Gridは、ロボットと上位システムの間でバイト列を確実に運ぶトランスポート層です。一方、当社が開発するRovnouは、その上のレイヤーで「どのロボットにどの搬送タスクを割り当て、どの経路と順序で交差点を抜けるか」を計算する交通管制ソフトウェアです。
現場の通信基盤を刷新しただけでは、通路での鉢合わせや待機は減りません。既存のMQTT／REST構成や設備制約を前提に、まず実ログから待機原因を切り分け、そのうえで経路計画・優先制御の検証範囲を決めるアプローチを推奨します。
（調査基準日：2026年10月29日）