2026.08.22 アーキテクチャ

ROS（Robot Operating System）とは？ノードとDDS通信の構造・ROS 2世代の選び方を実装者目線で解説【2026年8月時点】

ROS（Robot Operating System）は、名前にOperating Systemと入っていながらWindowsやLinuxのようなOSではなく、Linuxなどの上で動く「ロボット向けの通信基盤とツール群」をまとめた開発プラットフォームです。センサー・制御・認識といった機能をノードという小さなプログラムに分け、その間でデータを流す仕組みを標準化した点が核心です。この記事では、ノード・トピック・サービス・アクションで構成される通信アーキテクチャ、ROS 2がDDSを採用して変わった点とQoS設定、2025年5月に終了したROS 1系と現行ディストリビューションの世代整理、そして産業の現場で採用する条件と見送る場面までを実装者の目線で整理します。生産管理やWMSとつなぐ際の連携方式も、受託開発の視点で扱います。

まとめ：ROSの正体と2026年時点で選ぶべきROS 2世代の結論

ROSの正体は、OSではなく「ロボットのソフトウェアを分割して動かすための通信規約と、その周辺ツール一式」です。カメラ、モーター制御、経路計画といった機能をそれぞれ独立したノードとして書き、トピックという名前付きの通り道でデータを配ります。この構造により、機体が変わってもノード単位で部品を差し替えられ、ソフトウェアを一から書き起こす必要がなくなります。

世代の結論を先に示します。ROS 1系は最終版のNoetic Ninjemysが2025年5月31日に公式サポートを終えており、新規開発で選ぶ理由はありません。ROS 2系では、対応パッケージの揃い方を取るならJazzy Jalisco（2024年5月公開・LTS・支援は2029年5月まで）、これから数年動かす新規案件なら2026年5月22日公開のLyrical Luth（LTS・支援は2031年5月まで）が基準になります。採用可否は「ノード分割で得をする規模か」「機能安全の認証を製品として求められるか」の2点でほぼ決まり、後者に該当する場合はROS本体だけで要件を満たせません。以下で構造と判断基準を掘り下げます。

ROSがロボット開発の共通基盤として担う範囲と提供される資産群

ROSを理解する最初の関門は、名前から受ける印象と実体のずれです。ハードウェアを直接管理するOSではなく、OSの上で動くミドルウェアとして、プロセス間の通信・起動・設定・記録を引き受けます。担う範囲と手に入る資産を分けて押さえます。

OS上のミドルウェアとして動くROSの実体と守備範囲の線引き

ROSの実体は、通信ライブラリ・ビルドの仕組み・コマンド行ツール・そして膨大な公開パッケージの集合体です。メモリ管理やプロセススケジューリングといったOS本来の仕事はしません。実行環境としてはUbuntuが主要な想定で、ROS 2の各世代はTier 1として特定のUbuntuバージョンと組み合わせて検証されています。実際にUbuntu 22.04へHumbleを入れる手順はROS 2の環境構築｜Ubuntu 22.04へのHumbleインストールとcolconビルド手順にまとめています。

守備範囲の線引きは実装で効いてきます。ROSが引き受けるのは「ノード間でデータをどう渡すか」「どのノードをどう起動するか」「設定値をどう配るか」まで。モーターの電流制御のようにハードウェアへ密着した実時間処理は、専用コントローラやマイコン側に置くのが定石です。ROSを入れれば実時間性が手に入るわけではない、という前提を最初に共有しておくと、後工程での設計のやり直しを避けられます。

通信・ビルド・可視化を束ねるROS標準ツール群の内訳と実務での効き目

ROSが開発現場で選ばれる理由の大半は、通信規約そのものより周辺ツールの厚みにあります。主要なものは次のとおりです。

rviz2：センサーデータやロボットの姿勢を三次元で描画する可視化ツール
ros2 bag：走行中の全トピックを記録し、あとから再生して不具合を追える仕組み
tf2：車輪・アーム・カメラなど各部位の座標系を時刻付きで変換し続ける機構
colcon と ament：複数パッケージをまとめてビルドする仕組み
Nav2・MoveIt 2・ros2_control：自律移動、アーム動作計画、ハードウェア抽象の上位パッケージ

実務で効き目が大きいのはros2 bagとtf2です。ロボットは再現性の低い不具合が出やすく、現場で起きた事象を丸ごと記録して机上で再生できるかどうかが、デバッグ工数を大きく左右します。座標変換も自前で書けば符号や時刻同期で必ず躓く領域で、ここが標準化されている価値は小さくありません。

ノード・トピック・サービスで構成するROSの通信アーキテクチャ

ROSの設計思想は「小さなプログラムを疎結合につなぐ」ことに集約されます。ここを理解すると、ROSで書かれたロボットのソースコードが読めるようになるはずです。中心となる概念を順に見ていきます。

機能単位でノードを割り、トピック購読で疎結合にする設計の考え方

ノードは、ROSにおける最小の実行単位です。カメラから画像を取り出すノード、画像から物体を検出するノード、検出結果から進路を決めるノード、モーターへ指令を出すノードといった具合に、機能ごとに独立したプロセスとして走ります。ノード同士は直接呼び合わず、トピックという名前付きの通り道を介してデータをやり取りする構造です。

データを出す側がpublisher、受け取る側がsubscriberで、両者は相手の存在を知りません。同じトピックを複数のノードが同時に購読でき、後から記録用ノードを足しても既存の処理には手を入れずに済みます。この疎結合が、機体やセンサーの差し替えに強い構造を生みます。逆にノードを細かく割りすぎると通信のオーバーヘッドと起動管理の手間が増えるため、粒度は「差し替える単位」で決めるのが実務的です。

トピック・サービス・アクションの3方式を使い分ける2つの基準

ROSの通信方式は3つあり、用途が明確に分かれています。取り違えると、応答待ちで処理が止まる、途中経過が取れないといった設計上の詰まりを生みます。

方式	通信の形	向く用途
トピック	一方向の配信と購読	センサー値や状態の連続配信
サービス	要求と応答の一往復	即座に返る問い合わせや設定変更
アクション	要求と途中経過と結果	移動や把持など時間のかかる指令

判断の基準は「時間がかかるか」「途中でやめられる必要があるか」の2点です。カメラ画像や現在位置のように流し続けるものはトピック、パラメータの読み書きのように一瞬で返るものはサービスを使います。指定座標までの移動のように数十秒かかり、進捗表示と中断が要るものはアクションが該当。サービスで長時間処理を書くと呼び出し側が待たされ、中断もできない構造になります。

ROS 2がDDSを採用して変わった通信の仕組みとQoS設定の要点

ROS 1とROS 2の技術的な分岐点は、通信の土台をDDS（Data Distribution Service）へ置き換えたことにあります。この判断が、可用性・実時間性・設定項目の全てに波及しました。実装者が押さえるべき差分を整理します。

roscoreのマスタ方式から分散ディスカバリへ移った構造の差

ROS 1では、roscoreと呼ばれるマスタープロセスが全ノードの名前解決を一手に引き受ける構造でした。ノードは起動時にマスタへ登録し、通信相手の所在をマスタへ問い合わせます。分かりやすい方式である半面、マスタが落ちると新規の接続が成立しない単一障害点を抱えていました。

ROS 2はDDSの分散ディスカバリを採用し、マスタープロセスそのものを廃しました。ノードは同じネットワーク上で互いを自動的に見つけ、直接つながります。中央の管理役がいないため、一部のノードが落ちても残りの通信は継続する構造です。その代わりノード数が数百規模になるとディスカバリの通信量が無視できなくなり、大規模構成ではディスカバリサーバを別途立てる設計が選択肢に入ります。両者の差分と移行時の判断材料はROS1とROS2の違いと移行判断・ディストリビューション選びの解説で体系的に整理しています。

信頼性・保持・履歴を決めるQoSプロファイル設定の4つの判断軸

DDS採用で増えた設定がQoS（Quality of Service）です。トピックごとに「取りこぼしを許すか」「後から参加したノードへ過去の値を渡すか」といった通信の性質を宣言します。主要な項目は次の4つ。

項目	選択肢	選ぶ基準
信頼性	確実配送か取りこぼし許容	指令値か連続センサー値か
保持	揮発か直近値の保存	後発ノードに初期値が要るか
履歴	直近N件か全件	遅延と欠落のどちらを嫌うか
期限	受信間隔の上限宣言	断線検知が要るか

ここで最も多い落とし穴が、publisherとsubscriberでQoSの組み合わせが噛み合わず、トピックが繋がらないまま無言で終わる事象です。エラーは出ず、ただデータが流れません。カメラ画像のように大量かつ取りこぼしても支障のないデータは取りこぼし許容、停止指令のように1回でも落とせないものは確実配送、地図データのように後から起動したノードへも直近値を渡したいものは保存を選ぶ、という対応づけを最初に決めておくと迷いません。

rmw層の差し替えで選べるFast DDSとZenohの現在の位置

ROS 2はDDS実装を直接呼ばず、rmw（ROS Middleware Interface）という抽象層を挟んでいます。このため実装を差し替えても、アプリケーション側のソースコードは変えずに済む構造です。既定の実装はrmw_fastrtps_cpp（eProsima Fast DDS）で、Jazzy以降の世代でも既定の位置を保っています。

選択肢としてここ数年で存在感を増しているのがZenohベースのrmw_zenoh_cppです。2026年5月のLyrical LuthではTier 1の扱いに入りましたが、既定の実装ではありません。無線区間をまたぐ構成や、ディスカバリの通信量を抑えたい大規模構成で検討対象になります。差し替えは環境変数で切り替えられる作りですが、対応状況は世代ごとに異なるため、導入時点の公式ドキュメントで対応表を確認してください。ROSとは別系統でRust製のデータフロー基盤を検討する場合はdora-rsとRust製ロボットデータフロー基盤のROS比較も判断材料になります。

ROS 1系の終了とROS 2系ディストリビューションの世代整理

ROSはディストリビューションという単位で世代が刻まれ、それぞれに支援期限が設定されています。2026年8月時点の状況は、選定の前提として押さえておく必要があります。

2025年5月31日で終了したROS 1系と延長サポートの選択肢

ROS 1系の最終ディストリビューションであるNoetic Ninjemysは、2025年5月31日に公式のサポートを終了しました。土台となるUbuntu 20.04の標準サポート終了と同じ日に合わせた形です。以降、ROS 1系には公式の不具合修正もセキュリティ更新も提供されません。

既にROS 1系で動く機体を保有している場合、選択肢は3つに絞られます。第一にROS 2系への移行、第二にCanonicalのROS ESMのような有償の延長サポートで当面の安全性を確保する方法、第三に外部ネットワークから切り離した閉じた環境で使い続ける判断です。移行でつまずくのはソースコードの書き換えより、依存する第三者パッケージのROS 2対応状況の調査と、対応版が存在しない場合の自前実装にあたります。

Humble・Jazzy・Kilted・Lyricalの支援期限と選定の基準

ROS 2系は、2年ごとに登場するLTS（長期支援）と、その間の非LTSが交互に並ぶ形で世代が進みます。2026年8月時点の主要な世代は次のとおりです。

世代	公開時期と区分	支援期限
Humble Hawksbill	2022年5月・LTS	2027年5月
Jazzy Jalisco	2024年5月・LTS	2029年5月
Kilted Kaiju	2025年5月・非LTS	2026年11月
Lyrical Luth	2026年5月・LTS	2031年5月

選定の基準は運用期間で決まります。数年動かす産業用途では非LTSを避け、LTSから選ぶのが原則です。Jazzy JaliscoはUbuntu 24.04と組み合わせる世代で、対応パッケージが揃っており現時点の安全牌にあたります。Lyrical LuthはUbuntu 26.04を主要な検証対象とし、実行部のCPU消費を1割前後抑える新しいエグゼキュータやPythonの非同期処理への対応が入った世代。公開から日が浅く第三者パッケージの追随は個別確認が要りますが、これから5年動かす新規案件ならこちらが基準になります。

産業のロボット実装でROSを採用する条件と見送るべき現場の基準

ここが実装者にとっての本題です。ROSは研究と試作では事実上の標準ですが、産業の量産機で常に正解とは限りません。噛み合う条件と、外すべき場面を条件付きで言い切ります。

ROSを採る利点が効く開発体制と要件に共通する4つの前提条件

次の条件が揃うほど、ROSを採る利点が効きます。

自律移動やアーム制御など、既存の上位パッケージ（Nav2やMoveIt 2）が使える領域を含む
センサー構成や機体が今後変わる見込みがあり、部品の差し替えやすさに価値がある
ロボット単体で完結せず、複数台やシミュレーションを含む検証工程が必要になる
Linuxとネットワークを扱える開発者が社内または委託先に確保できる

逆に言えば、単機能のピック機で機体構成が固定され、Nav2のような資産も使わないなら、ROSの通信機構は費用に見合いません。マイコンの制御プログラムで直接書くほうが速く、動作も読めます。発注側の視点から機種ごとの向き不向きを押さえたい場合は産業用ロボットの4種類の違いと導入可否の判断基準を先に確認すると、ROSを載せるべき層が見えてきます。

機能安全と実時間性が要る現場でROSの採用を見送る判断の線引き

見送りの判断が要るのは、機能安全の認証を製品として求められる場面です。ROS 2本体は、ISO 26262やIEC 61508といった規格の認証を取得したソフトウェアとして提供されているわけではありません。人が近接する産業機械で安全カテゴリの要件がかかる場合、ROSで書いた処理を安全機能の根拠にはできない、と考えるのが出発点になります。

現実的な構成は2つです。ひとつは安全機能を分離する設計で、非常停止・速度監視・防護柵の連動といった安全側は安全PLCやセーフティコントローラに持たせ、ROSは認識・計画・上位連携という非安全側だけを担わせます。もうひとつは、ISO 26262のASIL Dまで認証を取得した商用のROS 2派生製品を採る方法です。後者はライセンス費用と供給元への依存が生じるため、車載や公道走行のように規格適合が製品要件そのものである場合に限って検討します。実時間性も同様で、ミリ秒単位の周期保証が要る制御ループは、リアルタイム拡張を入れたカーネルかマイコン側へ降ろす設計が前提です。処理をどの層へ置くかという判断はエッジコンピューティングの仕組みとクラウドとの使い分けの観点が下敷きになります。

ROSのロボットと生産管理・WMSをつなぐ連携方式の選定基準

受託開発で相談が集まるのが、ROSで動くロボットと基幹システムの接続です。ロボット側はROSの枠内で完結していても、実際の業務では生産管理やWMSからの指示で動き、実績を返す必要があります。標準パッケージが薄く、設計判断が要る領域です。

ROS 2と基幹システムを橋渡しする3方式の比較と選定の判断軸

ROSの通信をそのまま社内ネットワークへ流すのは現実的ではありません。DDSはローカルネットワークでの多対多通信を前提としており、基幹システム側が話す言語でもないためです。橋渡しには次の3方式が使われます。

方式	形態	向く場面
WebSocketブリッジ	JSONで双方向に中継	監視画面や操作UIの接続
MQTTブリッジ	トピックを相互変換	複数拠点や多台数の統合
REST APIゲートウェイ	要求応答に変換	既存基幹の同期呼び出し

選定の判断軸は、接続相手が「継続的に状態を見たいのか」「都度の指示と実績だけで足りるのか」です。監視画面のように状態を流し続けたい相手にはWebSocketかMQTT、既存の生産管理から作業指示を投げるだけならREST APIのゲートウェイを1枚挟む構成が素直に噛み合います。いずれの方式でも、ロボット側の全トピックをそのまま外へ出さず、業務に必要な情報だけを選んで変換する設計にしておくと、機体側の改修が業務システムへ波及しません。

VDA 5050準拠のMQTT連携で複数ベンダの機体を束ねる構成

搬送ロボットを複数ベンダから調達する現場では、VDA 5050という業界標準が判断材料になります。ドイツ自動車工業会とVDMAが策定した、無人搬送車と上位の管制システムをつなぐ通信仕様で、MQTTをトランスポートに、JSONでメッセージを定義します。指示・即時動作・状態・可視化・接続・仕様書という区分でやり取りが整理され、メーカーの異なる機体を1つの管制下に置ける構造です。2026年3月には自由経路走行に対応した3.0系が公開されましたが、現場で稼働する機体の多くは2系である点に留意してください。

ROS 2側から見ると、この標準は「機体の内側はROSで作り、外向きの窓口はVDA 5050で開ける」という役割分担として使える標準です。下位のトランスポートとなるMQTTの仕組みはMQTTのPub/Subの仕組みとQoS・実装の解説で押さえられます。自社の機体と既存のWMSをどうつなぐか、変換層をどこに置くかといった設計は個別性が高いため、AI/IoTソリューションによる機器連携基盤の設計・開発支援のように現場の機器と業務システムの両側を見られる体制で組み立てると、後の拡張で詰まりにくくなります。

ROSの導入検討でよく挙がる質問と実装者目線からの実務的な回答

ROSの検討でよく挙がる疑問に、実装者の観点で簡潔に答えます。

ROSは本当にOSなのですか？

OSではありません。名前にOperating Systemと入っていますが、実体はLinuxなどのOS上で動くミドルウェアとツール群の集合です。プロセス間の通信、ノードの起動管理、設定値の配布、記録と可視化を引き受ける一方、メモリ管理やプロセススケジューリングといったOS本来の役割は担いません。実行環境としてはUbuntuが主要な想定になります。

これから学ぶならROS 1とROS 2のどちらですか？

ROS 2一択です。ROS 1系の最終版であるNoetic Ninjemysは2025年5月31日に公式サポートを終えており、以降は不具合修正もセキュリティ更新も提供されません。学習用の教材にはROS 1系のものが残っていますが、通信の土台がDDSへ変わったことで設定項目や起動記述の書き方も異なるため、ROS 2系の資料で学び始めてください。

ROS 2のどのディストリビューションを選ぶべきですか？

数年動かす産業用途なら非LTSを避け、LTSから選びます。対応パッケージの揃い方を優先するならJazzy Jalisco（支援は2029年5月まで）、これから5年動かす新規案件なら2026年5月公開のLyrical Luth（支援は2031年5月まで）が基準です。非LTSのKilted Kaijuは2026年11月で支援が切れるため、長期運用の機体には向きません。依存する第三者パッケージが当該世代に対応しているかは個別に確認してください。

ROSは産業用ロボットの製品開発に使えますか？

使えますが、機能安全の扱いに条件が付きます。ROS 2本体はISO 26262やIEC 61508の認証を取得した製品ではないため、非常停止や速度監視といった安全機能の根拠にはできません。実務では安全機能を安全PLCやセーフティコントローラへ分離し、ROSは認識・経路計画・上位連携という非安全側を担う構成を採ります。規格適合が製品要件そのものになる場合は、認証取得済みの商用派生製品を検討する経路もあります。

ROSとMQTTはどう使い分けますか？

ロボットの内側がROS、外向きの連携がMQTT、という役割分担が基本形です。ROS 2のDDSはローカルネットワークでの多対多通信と実時間性を想定した仕組みで、拠点をまたぐ通信や基幹システムとの接続には向きません。搬送ロボットの管制ではVDA 5050という業界標準がMQTTを前提としており、機体の内部構造をROSで作り、外部との窓口をMQTTで開ける構成が現場でも定着しています。