ROS 2 & ロボティクススタック 2026 完全ガイド — Jazzy · Kilted Kaiju · Gazebo · MoveIt 2 · NVIDIA Isaac · Drake · Foxglove · Nav2 徹底解説

プロローグ — ロボットが「実用的になった」最初の年

2026年の上半期はロボティクス業界に独特の空気が流れている。一年前まではヒューマノイドロボットといえば「デモは凄いが量産は遠い」というのが定説だった。だがFigure 03がBMW生産ラインで24/7稼働に入り、1X Neoが家庭用ベータの配送を開始し、Unitree G1が約170万円台で出荷されるようになり、「もう実用的だ」と言う声が増えた。NVIDIA GR00T・Physical Intelligence pi-0.5・Google DeepMind RT-XのようなVLA(Vision-Language-Action)ファウンデーションモデルの登場で、ロボットは「一つのタスクのために最初から書く機械」から「汎用モデルをファインチューニングする機械」へと変わりつつある。

しかしその下のインフラ層は依然としてROS 2である。本稿は2026年5月時点のROS 2エコシステム全体を地図として描く — ディストロ(Humble · Jazzy · Kilted Kaiju · Lyrical Luth)、ミドルウェア(Fast DDS · Cyclone DDS · Zenoh)、モーションプランニング(MoveIt 2)、ナビゲーション(Nav2)、シミュレーション(Gazebo Harmonic · Isaac Sim 4 · Drake)、可視化(Foxglove Studio · RViz2 · PlotJuggler)、そしてその上で動くヒューマノイドのファウンデーションモデルまで。

1章 · ROS 2 ディストロ — 2026年の現在地

まず大局から。2026年5月現在の各ディストロの状況。

ディストロ	リリース	EOL	種別	備考
ROS 2 Foxy	2020-06	2023-06	LTS	終了
ROS 2 Galactic	2021-05	2022-12	non-LTS	終了
ROS 2 Humble Hawksbill	2022-05	2027-05	LTS	産業現場の事実上の標準
ROS 2 Iron Irwini	2023-05	2024-11	non-LTS	終了
ROS 2 Jazzy Jalisco	2024-05	2029-05	LTS	新規プロジェクトの既定
ROS 2 Kilted Kaiju	2025-05	2026-11	non-LTS	実験的機能の検証用
ROS 2 Lyrical Luth	2026-05	2031-05(予定)	LTS	リリース直後、移行開始

要点: 2026年の新規プロジェクトはJazzyまたは出たてのLyrical、稼働中の産業システムは依然としてHumbleが圧倒的。ROS 1 Noeticは2025年5月にEOLを迎え新規導入は不可能で、ros1_bridgeで段階的に移行している現場が今でも多い。

2章 · ROS 1からROS 2へ — 移行の現実

2025年5月のROS 1 Noetic EOLは業界最大級の節目だった。産業オートメーション・研究所・海洋/水中ロボティクスでは依然として数百万行のROS 1コードが稼働していた。

移行戦略は大きく三つ。

ros1_bridgeによる段階移行 — ROS 1とROS 2をトピックレベルで双方向変換する。最も一般的だが、独自メッセージ型は手動マッピングが要る。
ノード単位のリライト — 主要ノードをrclcpp/rclpyで書き直す。最も綺麗な結果だがコストが大きい。
レガシー凍結 + 新規はROS 2 — Noeticはセキュリティパッチを自前バックポート、新規開発はROS 2へ。保守的な産業オートメーション現場の典型解。

よくある落とし穴。

rospyコードをrclpyに1:1変換しようとする試み。コールバックモデル・QoS・ライフサイクルの設計が違う。
tf → tf2/tf2_ros。ROS 2のtf2は微妙に挙動が異なる。
launchファイルがXMLからPython(launch.py)へ。慣れると強力だが入口の障壁は実在する。
ビルドがcatkinからcolcon + ament_cmake/ament_pythonへ。

3章 · DDS ミドルウェア — Fast DDS · Cyclone DDS · Zenoh

ROS 2の根幹設計の一つはDDS(Data Distribution Service)を通信バックボーンに採用したことだ。RMW(ROS Middleware)抽象層を介して実装を差し替えられる。

2026年の主要RMW実装。

rmw_fastrtps — eProsima Fast DDS。Jazzyの既定。最も広く使われている。
rmw_cyclonedds — Eclipse Cyclone DDS。Foxyの既定だった。メモリ効率の良さで根強い人気。
rmw_connext — RTI Connext DDS。商用。自動車・航空・防衛で安全認証付きで使用。
rmw_zenoh — Eclipse Zenohベース。コミュニティ内でDDSの後継として位置づけられつつある。広域分散・低帯域に強み。Kilted以降ファーストクラスRMW候補に。

Zenohがなぜ重要か。クラウド-エッジ分散・5G/衛星アップリンク・マルチロボット艦隊といった、DDSのマルチキャスト前提が崩れる場面で強い。マルチロボット協調・遠隔テレオペレーションで採用が伸びている。

RMWを切り替える時は環境変数RMW_IMPLEMENTATION=rmw_cyclonedds_cpp等を明示。QoS互換性とディスカバリ挙動が微妙に異なるため、無条件の差し替えは避ける。

4章 · ノード · トピック · サービス · アクション · パラメータ — 中核5要素

ROS 2の抽象は五つに要約される。

概念	通信モデル	用途
トピック	publish/subscribe	センサデータ・状態ストリーミング
サービス	request/response	短い同期呼び出し(設定変更等)
アクション	goal/feedback/result	長時間タスク(モーション・移動)
パラメータ	同期setter/getter	ノード設定・チューニング
ライフサイクルイベント	状態遷移通知	ノード状態管理

定番の失敗は「全部トピック」。アクションは進捗・キャンセル・結果のためのモデル、サービスは短い呼び出し用。トピックでアクションを真似ると、キャンセル・タイムアウトのロジックが散らかる。

5章 · Composition — 単一プロセスでノードを束ねる

ROS 2の最大の性能改善の一つがComposition(Component Nodes)だ。同一プロセス内で複数ノードをロードすると、プロセス内通信ではメッセージを直列化せずポインタで渡せる。

どんな時に効くか。

カメラ → 画像処理 → 物体検出 → トラッカといったパイプラインで毎段メガバイト級画像を直列化すれば、CPU・メモリ・遅延が爆発する。Compositionで束ねると10倍以上速くなることが多い。
rclcpp::Nodeを継承せず、コンポーネントとして実装してcomponent_container_mtにロード。composable_node_descriptionsベースのlaunchが基本。

トレードオフ: 同一プロセス内の複数ノードがログを共有するため、デバッグはやや複雑になる。ノードごとのログ規約が必要。

6章 · ライフサイクルノード — 管理された状態機械

rclcpp_lifecycle::LifecycleNodeはノードを明示的状態機械として管理する。状態は Unconfigured · Inactive · Active · Finalized。

なぜ重要か。自律走行・産業オートメーションで「センサが起動済みか」「キャリブが終わったか」「モータが励磁されたか」を標準的に把握できる必要がある。ライフサイクルはそれをトピックの外で表現する仕組み。Nav2の主要ノードはほぼ全てライフサイクルノードだ。

典型フロー: configure → activate → (実行) → deactivate → cleanup。

7章 · QoS — Quality of Service ポリシー

QoSはROS 2初心者が最もつまずく箇所。重要なのは四つ。

Reliability — RELIABLE vs BEST_EFFORT。センサrawはbest-effort、コマンドはreliable。
Durability — VOLATILE vs TRANSIENT_LOCAL。ROS 1のlatched topicに相当するのが transient_local。
Deadline — メッセージが一定周期で来ることを宣言。違反でコールバック。
Liveliness — publisherの生存保証。

定番の落とし穴: pub/subのQoSプロファイルが非互換だと接続が成立しない(エラーも出ず沈黙)。RViz・Foxgloveでトピックが見えない時、90%はQoS不一致が原因。

推奨プロファイル: rclcpp::SensorDataQoS()(センサraw)、rclcpp::ServicesQoS()(サービス)、rclcpp::ReliableQoS()(コマンド)。

8章 · rclcpp · rclpy — クライアントライブラリ

ROS 2の二大言語。

rclcpp(C++) — 性能クリティカルなノード。Composition・ライフサイクル・プロセス内通信をフル活用可能。リアルタイム保証が要る場所。
rclpy(Python) — 高速プロトタイプ・研究・高位ロジック。GILで処理量は頭打ちだが使い勝手は抜群。
rclrs(Rust) — コミュニティ主導、実験的。安全性と並行性の観点で関心が高まっている。
rclnodejs / ros2-web-bridge — Web・Node.js統合。

典型的な分業: 低レベルドライバ・フィルタ・SLAMはC++、ビヘイビアツリー・UI・外部システム連携はPython。

9章 · MoveIt 2 — モーションプランニングの標準

ROS 1時代から標準モーションプランナーであったMoveItはROS 2でも引き続き標準の座を保つ。

2026年の主な事実。

MoveIt 2 — Humble/Jazzyベース。マニピュレーションの事実上の標準。
MoveIt Pro — PickNik Roboticsの商用版。ビヘイビアツリーベースのマニピュレーション・シミュレーション・認証等の企業向け機能。
プランナ: OMPL(サンプリングベース、既定)、CHOMP(軌道最適化)、STOMP(確率的軌道最適化)、Pilz Industrial(LIN/CIRC/PTP — 産業の基本動作)。
IKソルバ: KDL(既定、汎用)、TRAC-IK(速くて正確)、bio_ik(パラメータ豊富)、IKFast(特定ロボット用解析的・コンパイル済)。
Servo — リアルタイムテレオペ・直交ジョギング。

定番の落とし穴: 衝突モデルが実機と違うと、シミュレーションでは通るのに実機で衝突する。URDF/SRDF整備に十分な時間を割くこと。

10章 · Nav2 — 自律走行・移動の標準

navigation2(Nav2)はROS 2のナビゲーションスタック。ROS 1のnavigationの後継で、ビヘイビアツリー中心であることが最大の違い。

主要プラグインのカテゴリ。

Planner — グローバル経路: NavfnPlanner(既定)、SmacPlanner2D/Hybrid、ThetaStar。
Controller — ローカル制御: DWB、RPP(Regulated Pure Pursuit)、MPPI(Model Predictive Path Integral)。
Costmap — レイヤ式: static_layer、obstacle_layer、inflation_layer、voxel_layer。
Recovery / Behaviors — Spin、Wait、BackUp、AssistedTeleop。
Localization — amcl、slam_toolbox(SLAMモード)。
ビヘイビアツリー — navigate_to_pose.xml等のBTが本当のメインロジック。プランナ・コントローラはBTノードとして呼ばれる。

2026年の事実上の定番組合せ: SLAM Toolbox + AMCL + Nav2 + RPP/MPPI + ビヘイビアツリー。

「なぜこんなに複雑なのか」と最初は感じる。だが復旧動作がN個・条件動作がM個の規模になるとBTはコードよりずっと整然とする。最初の数ヶ月はBT Designerでビジュアルに作り、慣れたらyaml直編集へ。

11章 · Gazebo — Classic終焉、Harmonicの時代

2025年1月、Gazebo Classic 11がEOLを迎えた。15年近くROSの標準シミュレータだったGazebo Classicが公式に終焉した出来事だ。

後継ライン(かつての「Ignition Gazebo」、2022年に名称をシンプルに「Gazebo」へ統一):

Gazebo Garden — 2023、Humble/Ironペア。
Gazebo Harmonic — 2023後半のLTS、Jazzyの既定シミュレータ。
Gazebo Ionic — 2024後半、Kiltedペア。非LTS。
Gazebo Jetty — 2026リリース予定、Lyricalペア。

Classicとの主な違い。

モジュラ構成: gz-sim、gz-physics、gz-rendering、gz-transportに分離。
物理エンジン多様化: ODEに加えてDART、Bullet、TPE。
レンダリング: 既定ogre2、将来的にVulkan。
SDFモデル v1.10/1.11。
ROS 2連携: ros_gz_bridge、ros_gz_sim(ランチャ)。

移行の罠: Classicモデル・プラグインの約9割が非互換。URDFは互換だが、Classicプラグイン(gazebo_ros_*)は新プラグイン(gz_ros2_control等)へ書き直しが必要。

12章 · NVIDIA Isaac Sim 4.x + Isaac Lab 2.x — GPU加速シミュレーション

2026年のシミュレーションで最大の潮流はOmniverse Isaac Simとその上のIsaac Labだ。

Isaac Sim 4.xの強み。

PhysXのGPU加速 — 数千環境を並列シミュレーション。強化学習の学習時間が日単位から時間単位へ。
物理忠実度 — 剛体・変形体・布・ロープ・接触を広範に再現。
フォトリアル描画 — RTXレイトレで合成データ生成に最適。
USDベース — Pixar Universal Scene Descriptionが産業標準のワークフロー基盤。

Isaac Lab 2.x(旧Isaac Gym + ORBITの統合後継):

強化学習・模倣学習ワークフローの統合環境。
主要ライブラリ: rl_games、rsl_rl、skrl、stable-baselines3。
ANYmal、Spot、Cassie、H1、G1、UR10など標準アセット。

2026年の新登場: NVIDIA Cosmos — 動画基盤モデルでロボット学習用の合成データをプロンプトから生成。「濡れたコンクリート床で箱を持ち上げる」といったシナリオを数万件合成。

典型パターン: 事前学習はIsaac Labで大規模に、ファインチューニングは実環境の小データで、本番展開はROS 2のNav2/MoveIt上で。

13章 · NVIDIA Isaac ROS — CUDA加速パッケージ

Isaac ROSはROS 2パッケージ群で、主要な知覚と計算をCUDAで加速する。

isaac_ros_visual_slam — GPU加速のVSLAM(cuVSLAMベース)。
isaac_ros_nvblox — 3D占有マッピング。
isaac_ros_dnn_inference — TensorRT連動の検出・分割。
isaac_ros_image_pipeline — 画像変換・歪み補正のGPU加速。
isaac_ros_apriltag — AprilTag検出をGPU加速。
isaac_ros_argus_camera — Jetsonカメラインタフェース。
isaac_ros_object_detection — DetectNet/YOLO推論。

対象ハードウェア: Jetson Orin Nano/NX/AGX、IGX Orin、x86 + RTX。Jetson Orin AGXは事実上モバイルロボットの標準ブレインの一つ。

14章 · Drake — TRIの精密動力学エンジン

Drake(Toyota Research Institute主導のMITライセンスプロジェクト)は精密な多体動力学と最適化ベースのモーションプランニングに特化したライブラリだ。

特徴。

Multibody Plant — 厳密な剛体動力学、自動微分対応。
数理最適化連携 — Mathematical Programming(MOSEK、Gurobi、IPOPT、SNOPT等)とのインタフェース。
軌道最適化 — Direct collocation、KKTベース。
システム図 — ブロック線図的にコントローラを組合せ。
Pythonバインディング — pydrakeで高速プロトタイプ。

位置付け: 学術・研究中心 + 一部産業(特にToyota TRI内部)で使用。Gazebo/Isaacが「グラフィカルシミュレータ」ならDrakeは「数学的解析エンジン」。ROS 2との直接統合は薄いが、drake_ros等のブリッジパッケージがある。

15章 · Foxglove Studio — RVizを超える可視化

Foxglove(元Cruise可視化チームが創業した企業)はROS可視化ツールの新標準を作りつつある。

機能比較。

ツール	強み	限界
RViz2	ROSネイティブ、3D可視化が強力	UIが古い、コラボ困難
Foxglove Studio	デスクトップ・Web・埋込、豊富なパネル	一部RVizプラグインの不在
PlotJuggler	時系列プロット最強	3Dは弱い
rqt	多様な診断プラグイン	UIが老朽化

Foxgloveの差別化点。

MCAPファイルフォーマット — rosbag2の既定バックエンドに採用。圧縮・ランダムアクセス・多言語デコード。
Foxglove Data Platform — クラウド上でログ保管・検索・共有。
デスクトップとWebで同UX — 遠隔テレオペコンソールとしても使える。
WebSocket / Rosbridge接続。

2026年のパターン: 産業・研究現場でRVizを完全代替するには至らないが、データ分析・デバッグ・遠隔監視ではFoxgloveが事実上の標準になりつつある。

16章 · rosbag2 + MCAP — ログの新標準

rosbag2はROS 2のロギングツール。既定ストレージはSQLite3だが、2024年以降はMCAP(Foxglove謹製)が推奨に。

MCAPの利点。

言語独立のデコード — Python、C++、Rust、JSのSDKあり。
圧縮(LZ4、Zstd)対応。
ランダムアクセス — 時間インデックスで高速ジャンプ。
メッセージ定義の埋込み — IDL/schemaがファイル内にあり、将来も独立してデコード可能。
ROS外への展開 — 自動運転・ドローン企業が独自データパイプラインに採用。

CLI: ros2 bag record -s mcap /topic。分析はFoxglove Studioかmcap-cliで。

17章 · ヒューマノイド・ファウンデーションモデル — VLAの年

2026年ロボット業界最大の話題はVLA(Vision-Language-Action)ファウンデーションモデルである。自然言語指示に対してロボットが視覚入力を見ながら動作を直接出力する。

代表モデル/プレイヤー。

NVIDIA GR00T(Generalist Robot 00 Technology) — ヒューマノイド汎用基盤モデル。GR00T N1・N1.5公開、2026年にGR00T N2へ。Isaac Sim/Labと統合。
Physical Intelligence pi-0 / pi-0.5 — Pi(πbot)社のVLAモデル。pi-0.5は一般化能力を強調し、家庭・倉庫など多様な環境で学習。
Figure 02 / Figure 03 + Helix — Figure社のヒューマノイド。HelixはFigure独自のVLA。Figure 03はBMW生産ラインで実配備。
1X Neo + Redwood — 1X社の家庭用ヒューマノイド。Redwoodは音声・視覚入力モデル。
Apptronik Apollo — 産業用ヒューマノイド。Mercedes・NASAと協業。
Unitree G1 / H1 — 低価格帯。研究室への大量普及。
OpenAI + Microsoft + 現代(Boston Dynamics)パートナーシップ — 2025年後半に発表されたヒューマノイド協業。
Google DeepMind RT-1, RT-2, RT-X — インターネットテキスト事前学習に動作トークンを足すモデル群。Open X-Embodimentデータで一般化。
Boston Dynamics Atlas + Spot — 電動新Atlas + Spot SDK。Spotは産業点検の事実上の標準。

中核的観察: 2024年までの「1タスク1モデル」から、2026年は「1モデルで複数タスク」へとパラダイムが移行中。ただし「1モデルで全てのタスク」はまだ遠い。

18章 · オープン・ロボットデータセット — 学習の燃料

VLA時代の中核資源は大規模ロボット実演データだ。2026年の主要公開データセット。

Open X-Embodiment — Google + 22機関連合。22のロボット具現、100万エピソード超。RT-X・OpenVLA・Octoの学習に使用。
DROID — Stanford・Berkeley・CMU。Franka腕を基準とした大規模実演。多様な家庭・オフィス環境。
BridgeData v2 — 物体操作の一般化評価のベンチマーク標準。
RoboMind / RoboCasa — UC Berkeley・NYU。合成と実測を混合したデータ。
ALOHA / Mobile ALOHA — Stanfordの両手テレオペ模倣学習標準。
HumanoidBench — ヒューマノイドベンチマークの統合。

各データセットでトークン化と具現化が異なるのが課題。OpenVLA・Octoのような具現非依存モデルがそのギャップをどう吸収するかが中核研究テーマ。

19章 · 標準ハードウェアプラットフォーム — 出発点

2026年に「ROS 2ロボットを作る」を始めるとき、どのハードを選ぶか。

TurtleBot 4 — iRobot Create 3ベースのROS 2標準教育用移動ロボット。
Clearpath Husky / Jackal / Warthog — 屋外・不整地研究用。ClearpathはROS標準提携企業。
Universal Robots UR3/5/10/16/20 — 協働マニピュレータ。ROS 2ドライバが安定。
Franka Emika Panda — 7軸マニピュレータ、トルクセンシング。学界標準。
Robotiqグリッパ — 協働ロボとペアのエンドエフェクタ標準。
Boston Dynamics Spot — 四足 + Spot SDK + ROS 2インタフェース。
Unitree Go2 / G1 / H1 — コスパに優れた四足・ヒューマノイド。
OAK-D / Intel RealSense / ZED — RGB-Dカメラ三強。
Velodyne / Ouster / Livox / Hesai — LiDARラインナップ。

選択基準: コミュニティ支援 → ドライバ成熟度 → 予算。TurtleBot 4 + UR + Spotが最も典型的な「学校三点セット」。

20章 · 韓国ロボティクス風景 — 2026年

韓国ロボット業界の流れ。

HD現代ロボティクス(HD Hyundai Robotics) — 産業用マニピュレータ世界4位圏。ROS 2公式ドライバあり。
斗山ロボティクス(Doosan Robotics) — 協働ロボラインナップ(M・H・Eシリーズ)。Dart Suite + ROS 2インタフェース。
レインボー・ロボティクス(Rainbow Robotics) — KAIST Hubo出身者が創業。RB協働ロボ・ヒューマノイド。2024年Samsung Electronicsが買収参画。
ROBOTIS — DYNAMIXELサーボ・OP3ヒューマノイド。教育市場の絶対王者。ROS 2公式サポート。
NAVER Labs — HORIZON自律走行、MINIROサービスロボ、ARCクラウドロボティクス基盤。
KAIST Hubo Lab — HUBOシリーズ。世界のヒューマノイド研究の一極。DARPA Robotics Challenge優勝。
現代車グループ + Boston Dynamics — 2021年買収以降、新型電動Atlasを公開。車両組立ラインに適用。

2026年の流れ: ヒューマノイド + 協働ロボ + 自律走行の三軸に政府投資が集中。産業クラスタとしては仁川松島(現代)、大田(KAIST・ROBOTIS)、始興(Rainbow)が目立つ。

21章 · 日本ロボティクス風景 — 2026年

日本は伝統的に産業ロボの強国。ヒューマノイド・サービスロボの動きも活発。

Toyota Research Institute(TRI) — Drake主導。T-HSR(Human Support Robot)は家庭支援研究プラットフォームの標準。
Honda Asimo(レガシー) — 2022年に公式引退。Hondaはモビリティに注力。
Preferred Networks(PFN) — Toyota・Fanucと協業。産業オートメーションへのディープラーニング応用の先頭。
Sony Aibo — 家庭向けコンパニオンロボ。AI強化モデルを継続投入。
OMRON — 産業オートメーション・AGV・協働ロボの統合ソリューション。
ファナック / 安川電機 / 川崎重工 — 産業用ロボの世界ビッグスリー。
Cyberdyne HAL — 医療・リハビリ用外骨格。
Mujin — 物流自動化 + Mujin Controllerの独自統合コントローラ。
GROOVE X LOVOT — 情感コンパニオンロボ。

日本特有の流れ: 産業ロボは圧倒的に強いがROS採用は保守的。自社コントローラ(Fanuc、Yaskawa)が支配的で、ROSはR&Dや新分野中心。

22章 · 学習リソース・コミュニティ・カンファレンス

ROS 2を学ぶ2026年の標準ルート。

公式チュートリアル — docs.ros.orgのJazzyチュートリアルが最新。
The Construct — オンラインROSスクール。実習環境付き。
Open Robotics教材 — discourse.ros.orgで講師資料を共有。
ROS Industrial Consortium — 産業オートメーション導入の標準コミュニティ。米州・欧州・アジア支部。
ROSCon — 毎年秋の本会議。2026はシンガポール予定。
ROS Developer's Day — 年1〜2回オンライン。
IROS、ICRA、RSS — 学術カンファレンスのビッグスリー。
Humble Bundle形式のロボティクス書籍束 — 頻繁に登場。

推薦書: Steven MacenskiのNav2論文群、MoveIt公式チュートリアル、"Modern Robotics"(Lynch & Park)、"Probabilistic Robotics"(Thrun et al.) — 後者は古典だが今も必読。

23章 · よくある落とし穴10選

ROS 2導入で頻発する失敗パターン。

QoS不一致でトピックが見えない — 初日から明示的にプロファイルを宣言。
CycloneDDSとFastDDSを混用してディスカバリが壊れる — 1システム内では1つのRMWに統一。
rclpyだけで1kHz制御 — GIL/オーバーヘッドで不可能。低レベルはC++で。
launch.pyに全部ハードコード — パラメータ・include・環境変数で分離。
シミュレーションでは動くが実機で壊れる — sim-to-realギャップ。URDF摩擦・慣性・キャリブを検証。
TFツリーが壊れる — static_transform_publisherと動的TFの時刻同期ミス。
Compositionを使わず画像パイプラインを運用 — CPU・メモリ爆発。
rosbag記録なし — 事故再現が不可能。常にMCAPで記録。
tf2時刻補正のミス — use_sim_timeを全ノードで一貫適用。
全ノードがライフサイクル無視 — Nav2/システム統合で状態追跡不能。

24章 · スタックを選ぶ7基準

要するに七つの観点で決める。

ディストロ — 新規はJazzyまたはLyrical、本番はHumble。
ミドルウェア — 既定はFast DDS、マルチロボ・広域はZenoh候補。
シミュレータ — 精度ならGazebo Harmonic、GPU学習はIsaac Sim/Lab、精密動力学はDrake。
モーションプランニング — マニピュレーションはMoveIt 2、移動はNav2。
可視化・デバッグ — RViz2 + Foxglove + PlotJugglerの三点セット。
学習スタック — 強化学習はIsaac Lab、模倣学習はLeRobot/HuggingFace・OpenVLA。
ハードウェア — TurtleBot 4(教育) → UR/Franka(マニピュレーション) → Spot/Husky(移動)の段階。

選択の本質: 「どのツールが最良か」ではなく「私達の制約下でどの組合せが妥当か」。そしてその組合せは1〜2年ごとに再評価する必要がある — ヒューマノイドのファウンデーションモデルが年単位で盤面を作り直しているからだ。

25章 · これからの10年 — 何が来るか

長期的潮流を整理する。

VLAモデルの日常化 — 小さな具現調整だけで多様なタスクをこなすベースモデルが標準に。
sim-to-realギャップの縮小 — Isaac Sim/Cosmos・Drake・Gazeboが物理忠実度を一段引き上げる。
データインフラの爆発 — Open X-Embodimentに続く新データセットが四半期単位で登場。データラベリング・キュレーションが主要職種に。
ヒューマノイドの普及 — 家庭・倉庫・飲食までレンタル型ヒューマノイドが浸透。
安全認証 — ISO 10218(産業ロボ)、ISO 13482(サービスロボ)、新たなヒューマノイド安全規格の整備。
ROS 2以外のミドルウェアの可能性 — Zenoh・新RMW・あるいはROS 2自体を置換えるものまで真剣に議論される。
エッジ-クラウド分散 — 推論はクラウド、制御はエッジのハイブリッド。

エピローグ — ロボットは「コード × データ × 物理」の交差点だ

本稿の一文要約: 2026年のロボットはROS 2の上でVLAが回る機械である。

10年前のロボットはPIDと状態機械と手書き動作シーケンスの集合だった。2026年のロボットはその上に巨大モデル・合成データ・シミュ学習がもう一層重なっている。だが最下層は今も変わらずROS 2のトピック・サービス・アクション・TFツリーで、その上にNav2とMoveItがあり、その上にGazebo/Isaacがあり、最上層にVLAモデルが乗る。

次の10年、ロボットエンジニアの仕事はPIDゲイン調整ではなく、モデル・データ・ミドルウェアのインタフェース設計になる。とはいえPID・運動学・TFが消えるわけではない。多層抽象の時代に最強のエンジニアは上から下まで満遍なく分かる人である。

12項目チェックリスト

ROS 2ディストロがEOL期間内か?
RMWを1システム内で一貫させているか?
QoSプロファイルを意識的に選んでいるか?
すべての主要ノードがライフサイクル管理されているか?
Compositionでプロセス内通信を活用しているか?
URDF/SRDFが実機と一致しているか?
sim-realギャップを計測・管理しているか?
rosbag/MCAPで全運行を記録しているか?
CI/CDにシミュレーションテストが含まれるか?
マルチロボ・広域通信を考慮したミドルウェア選択か?
データ・モデル・コードのバージョン管理が統一されているか?
安全・認証・法令レビューの手順があるか?

アンチパターン10選

ROS 1コードを1:1変換しようとする — モデルが違う。
RMWをむやみに混ぜる — ディスカバリ断絶の定番。
rclpyで1kHz制御 — C++に降りる。
URDFを雑に書く — sim-to-realギャップの起点。
全部トピックで実装 — アクション・サービス・パラメータを適切に。
Compositionを使わない — 大データでは必須。
rosbagなしで運用 — 事故解析不能。
シミュレーションだけ検証して展開 — 現場で壊れる。
第1世代データで永遠に学習 — データ鮮度の管理が要る。
安全認証を事後に — 設計から組み込め。

次回予告

候補: Isaac Lab実践 — 強化学習で四足歩行を教える、MoveIt Pro vs OSS MoveIt 2 — 産業導入ガイド、VLAモデルのファインチューニング — Open X-Embodimentから自社ロボへ。

"ロボットはコードとデータと物理の交差点に居る。どれか一つだけ強くてもダメだ。"

— ROS 2 & Robotics Stack 2026、了。