ROS1とROS2の違いを徹底比較|2026年の移行判断とディストリ選び方
ROS1とROS2はどちらもロボット開発のミドルウェアですが、通信の仕組みから対応OS、ビルドツールまで設計が大きく異なります。とりわけ2026年は状況が変わりました。最後のROS1ディストリである「Noetic」が2025年5月31日にサポート終了(EOL)を迎え、現行のROS1に公式サポートは残っていません。この記事では両者の違いを通信・プラットフォーム・ビルド・セキュリティの観点で整理し、いま新規開発や移行でどちらをどう選ぶべきかまで示します。
まとめ:ROS1とROS2の違いと2026年の結論
ROS1とROS2の中核的な違いは通信アーキテクチャです。ROS1は中央のROSマスターがノードを仲介する方式で、マスターが単一障害点になります。ROS2はマスターを廃してDDS(Data Distribution Service)による分散ディスカバリへ移行し、単一障害点をなくすとともにQoS(通信品質設定)やセキュリティを標準機能に取り込みました。対応OSもUbuntu専用(ROS1)からLinux/Windows/macOS対応(ROS2)へ広がり、ビルドはcatkinからcolcon+amentへ、マイコン向けにはmicro-ROSが加わっています。
結論として、2026年に新規で始めるならROS2一択です。ROS1(Noetic)は2025年5月にEOL済みで、セキュリティ修正もパッケージ更新も止まっています。既存のROS1資産はros1_bridgeで共存させながら段階的にROS2へ移す前提で計画するのが現実的です。以降で各差分と、ROS2のどのディストリを選ぶかを具体的に解説します。
ROS(Robot Operating System)とROS1・ROS2の位置づけ
ROSはOSという名前ですが実体はミドルウェアで、センサー・制御・認識といった機能を「ノード」という小さなプログラムに分割し、それらをメッセージ通信でつなぐ仕組みを提供します。ノード間通信、パッケージ管理、可視化・記録ツール(rviz、rosbag)、豊富な既製パッケージ群が価値の中心です。
ROS1は2007年から研究・試作の現場で普及しましたが、中央集権的なマスター方式やリアルタイム性・セキュリティの弱さが産業用途では壁になりました。この設計上の限界を根本から作り直したのがROS2で、2017年の初版以降は産業・商用導入を前提に開発されています。両者はソースレベルの互換性がなく、別系統の実装と考えるのが正確です。
ROS1とROS2の違いを一覧で比較
| 観点 | ROS1 | ROS2 |
|---|---|---|
| 通信基盤 | TCPROS/UDPROS(独自) | DDS(RTPS/UDP) |
| ノード管理 | ROSマスターが仲介 | マスター無し・分散ディスカバリ |
| 単一障害点 | あり(マスター) | なし |
| QoS設定 | なし | あり(信頼性・保持等) |
| 対応OS | Ubuntu中心 | Linux/Windows/macOS |
| ビルド | catkin | colcon+ament |
| Python | 初期2系→Noeticで3系 | Python3前提 |
| マイコン対応 | 非対応 | micro-ROS |
| セキュリティ | ネイティブ機構なし | SROS2/DDS-Security |
| 2026年の状態 | Noetic EOL(2025-05) | Lyrical Luth等が現行 |
表の各行は設計思想の違いから来ています。以降でとくに影響の大きい通信・プラットフォーム・セキュリティを掘り下げます。
通信アーキテクチャの違い:マスター方式とDDS
ROS1のROSマスターと単一障害点
ROS1ではroscoreが起動するROSマスターが、どのノードがどのトピックを発行・購読しているかを管理し、ノード同士を引き合わせます。実データはノード間のTCPROS(TCP)またはUDPROSで直接やり取りされますが、相手を見つける名前解決はマスターに依存します。したがってマスターが落ちると新しい接続を確立できず、ネットワーク全体が機能不全に陥ります。これがROS1最大の弱点である単一障害点です。
ROS2のDDSと分散ディスカバリ
ROS2はマスターを廃止し、産業実績のある通信規格DDSを採用しました。各ノードはDDSのディスカバリ機構で互いを自動発見するため、中央のプロセスが不要になり単一障害点が消えます。既定の実装(RMW)はeProsimaのFast DDSですが、Eclipse Cyclone DDSなどへ差し替え可能な抽象化(rmw)になっており、用途に応じてDDSベンダーを選べます。
QoSで変わる通信の信頼性
ROS2はDDSのQoS(Quality of Service)を取り込み、トピックごとに「確実に届ける(Reliable)か、最新優先で取りこぼしを許す(Best Effort)か」「過去メッセージをどれだけ保持するか」などを宣言的に設定できます。無線が不安定な移動ロボットや、遅延に敏感な制御ループなど、ROS1では作り込みが必要だった要件を通信レイヤーの設定で吸収できる点が実務上の大きな差です。
対応プラットフォーム・言語・ビルドの違い
OS対応の広がり
ROS1は事実上Ubuntuでの利用が前提で、他OSは非公式でした。ROS2はマルチプラットフォームを前提に設計され、Ubuntu(Linux)を最優先の完全サポート対象(Tier1)とし、WindowsとmacOSも公式に対象へ含みます(多くのディストリではベストエフォートのTier3)。開発マシンや製品の実行環境の幅が広がった一方、本番の推奨環境はディストリごとに紐づくLinuxが基本で、最新のROS2はUbuntu 26.04 LTS(Resolute Raccoon)を対象にしています。
ビルドシステムの刷新
ROS1はcatkin(catkin_make/catkin build)でワークスペースをビルドしました。ROS2はビルド定義を担うamentと、それを横断的に実行するcolcon(colcon build)へ刷新され、複数パッケージの並列ビルドや非ROSパッケージの取り込みが扱いやすくなっています。クライアントライブラリもrclcpp(C++)・rclpy(Python)として再設計され、共通のrcl層を介してDDSに接続します。
組み込み・マイコンへの対応
ROS1はLinux上のプロセスが前提で、RAMやOSを持たないマイコンでは動きませんでした。ROS2はこの領域をmicro-ROSで埋め、FreeRTOSやZephyrといった組み込みRTOS上の小型マイコンからROS2ネットワークへ直接参加できます。センサーノードやアクチュエータ制御をマイコン側に置いたまま、上位のLinuxノードと同じ通信で統合できる点は、産業機器やフィジカルAIを支えるロボットの構成で効いてきます。
セキュリティの違い:SROS2とDDS-Security
ROS1にはノード認証や通信暗号化の標準機構がなく、閉じたネットワーク内で使う前提でした。ROS2はDDS-Securityを土台にしたSROS2を備え、ノードの認証、通信の暗号化、トピック単位のアクセス制御を設定で有効化できます。工場ラインや公共空間で動くロボットのように、盗聴やなりすましが実害につながる用途では、この標準セキュリティの有無が採用可否を分けます。逆に、外部と隔離された研究用途では設定を省いて軽く動かすこともできます。
【2026年最新】ROS1はEOL、どのバージョンを選ぶべきか
ROS1最終版Noeticのサポート終了(2025年5月)と実務影響
最後のROS1ディストリであるNoetic Ninjemys(Ubuntu 20.04向け)は、2025年5月31日にEOLを迎えました。これでROS1は全ディストリがサポート外となり、公式のバグ修正・セキュリティパッチ・パッケージ更新は提供されません。動いているROS1システムをそのまま使い続けることは可能ですが、脆弱性が見つかっても公式対応はなく、OS側のUbuntu 20.04も同時期にサポートが切れています。新規にROS1を選ぶ理由は、2026年時点では実質的に存在しません。
LTS優先で決めるROS2ディストリの選定基準
ROS2は毎年5月23日にリリースされ、偶数年がLTS(5年サポート)、奇数年が通常版(1.5年サポート)です。長期運用する製品や量産機はLTSを軸に選ぶのが定石です。2026年時点の主な選択肢は次のとおりです。
| ディストリ | 対応Ubuntu | 種別 | EOL |
|---|---|---|---|
| Humble Hawksbill | 22.04 | LTS | 2027-05 |
| Jazzy Jalisco | 24.04 | LTS | 2029-05 |
| Kilted Kaiju | 24.04 | 非LTS | 2026-11 |
| Lyrical Luth | 26.04 | LTS | 2031-05 |
既存パッケージやロボットの動作実績が豊富で無難なのはHumbleとJazzyです。長く使う新規プロジェクトなら、サポートが2031年まで続く最新LTSのLyrical Luth、または実績の厚いJazzyを推奨します。非LTSのKiltedはサポートが2026年11月で切れるため、検証や最新機能の追随以外では避けるのが安全です。
ROS1からROS2への移行手順と注意点
ros1_bridgeによる段階移行
ROS1とROS2は互換性がないため一括置換は現実的でなく、両者を並走させながら少しずつ移すのが基本です。その要になるのがros1_bridgeで、ROS1のトピックとROS2のトピックを相互に橋渡しします。周辺のセンサーノードやドライバから先にROS2化し、まだ移していないROS1ノードとはブリッジ越しに通信させることで、システムを止めずに部分的な移行を進められます。
移行で頻出するQoS不整合とビルド差
移行時は通信の作り替えが最大の作業になります。ROS1のコードをそのまま持ち込むのではなく、トピックごとにQoS(信頼性・履歴保持)を設計し直す必要があり、ここを既定値のまま進めると発行側と購読側のQoSが噛み合わず「つながらない」トラブルが起きます。ビルドもcatkinからcolconへの移し替え、launchファイルもXMLからPython形式への書き換えが発生します。カスタムメッセージ定義(.msg/.srv)は多くが流用できますが、依存パッケージがROS2で提供されているかを事前に棚卸ししておくと手戻りを防げます。座標変換ライブラリもROS1のtfからROS2のtf2へ移っているため、ロボットの姿勢や座標系を扱う既存コードは呼び出しの書き換えが必要になります。
よくある質問(FAQ)
ROS2とは何ですか?
ROS2はロボット開発向けのオープンソースミドルウェアで、ROS1の設計を根本から作り直した後継です。通信にDDSを採用してマスターを廃し、リアルタイム性・セキュリティ・マルチOS対応・組み込み対応を標準で備えています。2017年の初版以降、産業・商用導入を前提に毎年更新されています。
ROS1とROS2はどちらを使うべきですか?
2026年に新規で始めるならROS2です。ROS1(Noetic)は2025年5月にEOLを迎え、公式のサポートが残っていません。既存のROS1システムを運用中の場合も、セキュリティ面からros1_bridgeを使った段階的なROS2移行を計画するのが妥当です。
ros1_bridgeとは何ですか。ROS1とROS2は共存できますか?
ros1_bridgeはROS1とROS2のトピックを相互変換して橋渡しするパッケージです。これを使えば移行の途中でROS1ノードとROS2ノードを共存させられるため、システム全体を一度に置き換えずに部分ごとの移行が可能です。
ros2 doctorは何に使いますか?
ros2 doctorはROS2環境の健全性を点検する診断コマンドで、DDSの設定やネットワーク、パッケージ構成に問題がないかをチェックし、通信がつながらないときの切り分けに役立ちます。ROS2ではこのほかros2 topicやrqt_graphなど、コマンド体系とツール群がROS1から整理し直されています。
ROS2でドローンは開発できますか?
できます。ROS2のマイコン対応(micro-ROS)やQoS設定は、無線通信が不安定になりやすく機体制御にリアルタイム性が求められるドローンと相性が良い領域です。PX4などの飛行制御スタックともROS2で連携でき、自律飛行やSLAMによる自己位置推定と地図生成を組み合わせた開発が進んでいます。