ROS1のEOLに伴うROS2への移行(マイグレーション)とは?必要性やリスク、具体的な手順を解説
この記事では、ROS1のEOLや移行が必要な理由をご紹介したうえで、移行の手順やよくある課題を解説します。

目次
パーソルクロステクノロジーのROS1→ROS2移植支援サービスは、サポートが終了したROS1からROS2への安全なシステム移植を実績豊富な技術者が支援します。
移行リソース不足や最適なシステム構成の設計に不安をお持ちのお客さまは、ぜひお気軽にお問い合わせください。
詳しくはこちら
そもそもROS1のEOLとは?
ROS1(Robot Operating System)は、ロボット開発で使われるオープンソースのロボット制御ソフトウェアと、それを包括するプラットフォーム全体の初期世代のことです。また、EOL(End of Life)は、サポートの終了を意味します。EOLを迎えると、開発元から技術サポートやシステムのアップデート、セキュリティ対応などのサービスが受けられなくなります。
ROS1は2025年5月にEOLを迎え、現在は公式サポートを受けられなくなっています。
EOLについてより詳しく知りたい方は、以下の記事も併せてご覧ください。
EOLとは?放置によるリスクと対策、EOSとの違いも解説
ROS2への移行(マイグレーション)がなぜ必要なのか
2025年5月に迎えたROS1のEOLによってバグ修正やセキュリティパッチが提供されなくなったことで、ROS1のシステム全体で脆弱性が増すリスクが指摘されています。
ロボットの開発現場では、周辺機器やシステムまでネットワークで接続されることが多く、産業利用する際には安全性を担保するためのセキュリティ対策が不可欠です。しかし、EOLで公式サポートが受けられない場合、バグが起きても修正されず、古いセキュリティシステムを使い続けることになるため、リスクに晒され続けることになります。
また、ROS1はロボット研究において重要な役割を担ってきた一方、リアルタイム処理、スケーラビリティ、セキュリティなどの要件で課題を抱えていました。このような未解決の課題を持つ旧式のテクノロジーを使い続けることは、技術的負債として蓄積され、将来的なシステムの更新・改良の足枷になる懸念があります。
このような背景を踏まえると、ROS1の課題を踏まえて安全性と信頼性が高められたROS2への移行は、長期的な運用を考えるうえで欠かせないものといえるでしょう。
マイグレーションについては、以下の記事でより詳しく解説しています。
マイグレーション(システムマイグレーション)とは?基礎知識から種類、具体的な取り組み方法を解説
ROS1とROS2の主な違い
ROS2はROS1の課題を踏まえて再設計されたプラットフォームであり、セキュリティ課題や拡張性など、多くの項目で変化しました。両者の違いは以下のとおりです。
| 項目 | ROS1 | ROS2 |
|---|---|---|
| 導入目的 | 研究、プロトタイピングが中心 | 研究、産業、実運用、マルチロボット、分散システムなど |
| 通信アーキテクチャ | マスターによるノード管理(中央集約的) | DDSベースの分散型アーキテクチャ(マスター不要) |
| リアルタイム性 | 基本的には非対応 | リアルタイム制御を考慮した設計で対応可能 |
| QoS(Quality of Service)設定 | 原則なし | 速度や信頼性などを設定可能 |
| セキュリティの強度 | 標準では低い | 高い(暗号化、認証、アクセス制御など) |
| 対象OS | 主にUbuntu | Ubuntu、Windows、macOSなど |
| ネットワーク品質 | 安定したネットワーク環境を前提 | 低品質・不安定なネットワークでも制御可能(遅延・損失の可能性あり) |
| マルチロボット対応 | 単体での利用が中心 | 分散設計により複数台(マルチロボット対応) |
| 応用範囲 | 研究、教育向け | 産業用途まで幅広く応用可能 |
| 将来性 | 低い(EOL済み) | 高い(継続開発、機能拡張、長期サポート、セキュリティ対策など) |
ROS1からROS2の再設計で何が変わったかを理解することは、プラットフォームを移行する準備段階で重要なプロセスです。正しく理解することで、適切な設計判断が可能となり、無駄を省いた開発計画・移行計画を立てることができます。
また、長期運用を見据えた場合には、安全性や拡張性を確保したアーキテクチャの設計にもつながります。
ROS1をROS2に移行する手順

ROS1からROS2ではアーキテクチャに大きな変更があるため、単純に移行するのではなく、段階的なプロセスを踏み、現場の混乱を防ぐ必要があります。ここでは、ROS1からROS2に移行する手順を6つに分けて解説します。
①パッケージの互換性を確認する
ROS1からROS2に移行する際には、どのパッケージだとROS2に移行でき、どのパッケージでコードの書き直しが必要になるかを確認してください。
ROS1対応のライブラリ・パッケージの多くは、アーキテクチャの違いのため、そのままROS2に移行しても正常に稼働しません。事前確認なしで移行作業を進めると、コードの書き換えや再実装のために想定外の時間やリソースを要する懸念があります。
移行作業を支援するAPIや移行ツール、ブリッジ機能などを活用すれば、段階的に移行でき安心です。まずは既存パッケージでROS2に対応している範囲、改修が必要な場合の対応策を整理することから始めましょう。
②移行計画を立てる
パッケージの互換性を確認したら、移行全体の計画を立ててください。ROS2は段階的な移行を推奨しており、互換性に問題がありそうな箇所を把握したうえで、事前に解決策を用意しておくことが望まれます。
ROS2コミュニティでは、移行ツールや移行ガイドラインなどが提供されています。また、必ずしもすべての移行プロセスが問題なく遂行するとは限らないため、テスト環境を用意し、トライアンドエラーを重ねることを前提とした計画が求められます。
③コードを書き換える
移行計画を立てたら、本格的にROS2への移行作業へと入ります。まずはROS2との互換性の高いライブラリ・パッケージを確認したうえで、必要に応じてROS1のコードをROS2仕様に書き換えてください。
DDSの通信プロトコルを使っているROS2では、ROS1から通信仕様やAPIが変わっているため、多くの場合は改修しなければなりません。コードの書き換えは負担が大きい作業にも思えますが、ROS2ライクなコードに寄せつつ、段階的にコードの置き換えをすることで、負荷を軽減できます。
④テスト環境で動作確認をする
ROS2仕様のコードの書き換えが完了したら、テスト環境でコマンドを実行し、パッケージが正常に稼働するかを確認してください。特にQoS(Quality of Service)設定やリアルタイム性能はROS2の大きな変更ポイントであり、信頼性や有用性を把握するためのテストが不可欠です。
このとき、単にROS1での稼働と比較するだけではなく、新しく搭載されている機能に負荷をかけることで、対応力や不具合の発生リスクなどを適切に把握できます。テスト環境にて一定の負荷条件で検証を行えば、移行後の運用の安全性や安定性を測れるため安心です。
⑤完成したコードをROS2に移行する
テスト環境で不具合がすべて解消されたら、本番環境でROS2への移行を行ってください。ROS1のノードやパッケージをROS2の本番環境に置き換え、再設計にともなうDDSベースへの適応、QoS設定の追加も済ませます。
ROS1からROS2に移行するプロセスは段階的に行うことが推奨されており、併用する期間はブリッジ機能を用いることでトラブルを防ぐことが可能です。プロセスごとに不具合を見落とさないように注意すれば、移行後の安定した運用体制の整備につながります。
⑥最終的な動作確認をする
本番環境への移行が完了したら、コマンドを実行して、パッケージが正常に稼働するかを確認してください。本番環境への移行により、テスト環境では見落としてしまった不具合や負荷への耐久不足などの課題が見つかる場合もあります。
実稼働をしてから不具合やトラブルが発生すると、通常の業務に影響を及ぼす恐れがあるため、最終的な動作確認は重要です。コード、QoS設定、通信仕様などが正常に稼働しているかを個別で確認し、必要に応じて微調整を行って、移行作業は完了となります。
ROS2へのマイグレーションでよくある課題
ROS2に移行することにはセキュリティや機能面で多くのメリットがある一方、移行作業は複雑であり、工数も多く、課題を抱える企業が少なくありません。ここでは、ROS2へのマイグレーション(移行)でよくある課題を4つ解説します。
移行作業そのものに時間を割けない
ROS1からROS2に移行する作業では、互換性の確認、コードの書き換え、再構築、テスト運用など、多くのプロセスが必要です。しかし、既存システムの運用や新規案件の対応などで手一杯で、移行の作業に取り組めないケースは珍しくありません。「移行が必要だと分かっているものの、多くのプロセスに時間をかける余裕がなくて放置している」という企業も多いでしょう。
しかし、すでにサポート終了しているROS1を使い続けて万が一サイバー攻撃を受けてしまったら、復旧作業や補償対応でさらに多くの時間と費用が必要になります。そうした事態を避けるためにも早期の対応が賢明です。
移行を進めたものの構成や品質に不安がある
自社で移行作業を進めても、本当に正しいシステム構成になっているか、十分なセキュリティ対策が施されているのかと不安を感じるケースもあるでしょう。
ROS1とROS2は通信方式やシステム構造に明確な違いがあるため、ROS2に関する専門的な知識がなければ、安全面・運用面で不具合が生じる恐れがあります。QoS設定を調節すれば、拡張性やリアルタイム性を高めたり、信頼性を持続させたりすることが可能です。ROS1においてライブラリや外部システムの追加で補っていた機能がROS2では標準仕様になっている場合もあります。
移行作業にリソースが取られて本来の業務が圧迫される
ROS2への移行作業では、専門知識を持つ人材が拘束されることによって本来の業務に影響を及ぼすケースが多く見られます。一方、専門知識や移行作業の経験がないまま進めてしまうと、互換性の確認やコードの書き換え、テスト運用のトライアンドエラーなどのプロセスで時間がかかりやすくなります。結果として想定外の時間と労力がかかり、移行作業が完了するまで本来注力すべき新規案件や開発業務に割ける時間が足りなくなってしまいます。
また、ROS1からROS2へ段階的な移行作業をするにあたって、ブリッジ機能で2つのシステムを併用することになれば、さらに負荷がかかります。
有用性は理解しているが何から始めるべきか分からない
ROS2に移行することで安全性や利便性が向上することは理解していても、移行作業の進め方が分からず動き出せないケースもあるでしょう。パッケージの互換性を確認する、テスト運用で不具合の有無を検証するなど、やるべきことが分かっていても、やり方が分からなければスムーズに着手できません。
移行作業では、手順を把握しているだけではなく、ROS2特有のDDSやQoS設定などの通信や機能面まで理解することが求められます。
ROS1からROS2への移行を支援するサービスとは?
ここまでご紹介した移行作業の課題が解決できない場合は、外部の専門家に移行を支援してもらう方法もあります。
パーソルクロステクノロジーでは、ROS1→ROS2移植支援サービスを提供しています。具体的なサポート内容は以下のとおりです。
- コードの書き換え作業の代行
- 移行の必要性・手順・計画に関するコンサルティング
- 移行後のメンテナンスとサポート
- ROS2で必要になる機能開発のサポート
- 移行に関する情報をまとめたドキュメンテーションの作成
ROS1のままではセキュリティやリアルタイム性能に課題が残るだけでなく、公式サポートがなくなることで運用の安全性や効率性に不安が生じます。パーソルクロステクノロジーでは、製品や研究開発の分野における豊富な移植実績やROS関連の開発経験を基に、安心してお任せいただけるサービスをご用意しています。ぜひ一度ご相談ください。
サービス:ROS1→ROS2移植支援サービス
ROS2へのマイグレーションを外部委託して新規開発に注力しよう
ROS1はすでにEOLとなり、今後はバグ修正やセキュリティ対策が行われません。そのため、サイバー攻撃の被害リスクが高まる恐れがあります。しかし、「ROS2への移行が必要だと分かっているものの、時間やリソース、知識がなくて放置している......」という企業も珍しくありません。
そんな場合は、ぜひパーソルクロステクノロジーのROS1→ROS2移植支援サービスをご利用ください。「なぜ移行が必要なのか」という基本的な説明から、計画のご提案、コード書き換え業務の代行など、お客さまのご要望に併せて柔軟に支援します。
サービス:ROS1→ROS2移植支援サービス

