--- title: "ROS1とROS2の違いを徹底比較｜2026年の移行判断とディストリ選び方" url: "https://www.issoh.co.jp/tech/details/3812/" published: 2024-10-10 updated: 2026-08-23 categories: ["アーキテクチャ"] publisher: "株式会社一創" --- # 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）、豊富な既製パッケージ群が価値の中心です。ROSそのものの定義と通信アーキテクチャ、産業実装での採用判断は[ROS（Robot Operating System）とは何かを整理した解説](https://www.issoh.co.jp/tech/details/16824/)にまとめています。 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）](/tech/details/10901/)を対象にしています。 ### ビルドシステムの刷新 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を支えるロボット](/tech/details/10441/)の構成で効いてきます。 ## セキュリティの違い：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形式への書き換えが発生します。colconを使うワークスペースの作り方とビルドの通し方は[ROS 2の環境構築｜Humbleインストールとcolconビルド手順](https://www.issoh.co.jp/tech/details/16826/)で扱っています。カスタムメッセージ定義（`.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による自己位置推定と地図生成](/tech/details/10478/)を組み合わせた開発が進んでいます。 ## 関連記事 - [SLAMとは？Simultaneous Localization and Mappingの基本概念と仕組みを徹底解説](/tech/details/10478/) - [フィジカルAIとは？自動運転を変える仕組みと生成AIとの違い・活用事例【2026年】](/tech/details/10441/) - [Ubuntu 26.04 LTS（Resolute Raccoon）とは｜リリース日・新機能・24.04からのアップグレード](/tech/details/10901/) - [アルパマヨ（Alpamayo）とは｜NVIDIA自動運転AIの仕組み・読み方とAlpamayo 2 Superまで解説【2026】](/tech/details/10509/) - [エンボディドAI（Embodied AI）とは｜意味・読み方から生成AI・フィジカルAIとの違い、活用事例までわかりやすく解説](/tech/details/8207/) --- 出典: [ROS1とROS2の違いを徹底比較｜2026年の移行判断とディストリ選び方]()（株式会社一創）