2026.08.23 11 人が閲覧（直近 30 日）開発

ROS 2の環境構築｜Ubuntu 22.04へのHumbleインストールとcolconビルド手順【2026年8月時点】

ROS 2 Humble Hawksbillの環境構築は、コマンドを順に打てば終わる作業に見えて、実際は「どのUbuntuを使うか」「aptのリポジトリをどう登録するか」の2点で最初につまずきます。とくにリポジトリの登録方法は2025年に公式手順が置き換わっており、検索で見つかる手順の多くは古い書き方のままです。この記事では、Ubuntu 22.04へHumbleを導入する現行の手順を、ディストリとOS版の対応関係、aptによる本体導入、colconワークスペースの作成、環境変数の設定、talkerとlistenerによる動作確認、そしてDockerでの再現まで、実装者が手を動かす順番どおりに整理します。

まとめ：2026年8月時点でHumbleを選ぶ判断と構築手順の全体像

先に結論を示します。ROS 2 Humble HawksbillはUbuntu 22.04（Jammy）をTier 1として検証されたディストリビューションで、amd64とarm64の両方でDebianパッケージが提供されます。公式のサポート終了は2027年5月で、残る期間は1年半ほどです。2026年5月22日にLTSのLyrical Luthが公開され、Ubuntu 26.04（Resolute）向けに2031年5月まで支援されるため、白紙から始める新規案件でHumbleを選ぶ理由はほぼありません。既存の社内資産や取引先の機体がHumble前提である場合に限って選ぶ、というのが現時点の妥当な線引きになります。

手順そのものは5工程です。UTF-8ロケールとuniverseリポジトリを整え、ros2-apt-sourceパッケージでリポジトリ定義を入れ、ros-humble-desktopとros-dev-toolsをaptで導入し、colconワークスペースを作ってビルドを通し、talkerとlistenerで通信を確認する。この流れで動かない場合、原因の大半はリポジトリ登録の古い手順、Ubuntu版の不一致、ROS_DOMAIN_IDの衝突の3つに集約されます。

Ubuntu 22.04とHumbleの対応関係から確かめる構築前の前提条件

ROS 2は、ディストリビューションごとに前提となるUbuntuのバージョンが固定されています。ここを外すとaptに候補パッケージが現れず、以降の手順が丸ごと空振りします。着手前に対応表で自分の環境を確かめてください。

ディストリビューションごとの標準Ubuntu版とサポート期限の対応

REP 2000と各リリースノートで公開されている、現行世代の対応関係は次のとおりです。いずれも2026年8月時点の値になります。

ディストリ	公開	標準Ubuntu	支援終了
Humble Hawksbill	2022年5月	22.04 Jammy	2027年5月
Jazzy Jalisco	2024年5月	24.04 Noble	2029年5月
Kilted Kaiju	2025年5月	24.04 Noble	2026年11月
Lyrical Luth	2026年5月	26.04 Resolute	2031年5月

Humbleの場合、Tier 1はUbuntu 22.04のamd64とarm64、Tier 2がRHEL 8のamd64です。Ubuntu 20.04やDebian 11はTier 3で、ソースからのビルドのみが想定されています。つまりRaspberry Piなどのarm64ボードでも、22.04さえ載っていればaptでの導入が可能です。逆に24.04へHumbleを入れる道は用意されていないため、その組み合わせを選ぶならDockerで22.04環境を用意する形になります。ディストリ選定そのものの判断軸はROS1とROS2の違いを徹底比較｜移行判断とディストリ選びで扱っています。

実機とWSL2と仮想マシンのどれで組むかを決める前提条件の整理

構築先の選択肢は実機のUbuntu、WSL2、仮想マシンの3つです。学習と単体のノード開発までならWSL2でも足りますが、複数台のPCやロボットと通信させる段になると事情が変わります。ROS 2はDDSによる自動探索でノードを見つける仕組みのため、ネットワークの境界をまたぐ構成では探索パケットが届かず、相手が見えないという症状になりやすいからです。

実機に22.04を入れる場合の手順はUbuntuとは｜インストール手順・推奨スペック・日本語化と文字化け対策に、Windows側でWSL2を用意する場合はWSL2とは｜WSL1との違い・仕組み・インストール方法に手順があります。文法とパッケージ構造を覚える段階はWSL2、機体をつないで検証する段階は実機と切り替える前提で組むと手戻りが出ません。

aptでROS 2 Humbleを導入する2026年時点の正式なインストール手順

ここからが本体の導入です。公式ドキュメントに沿った現行手順を、実行順に並べます。なお、まっさらな22.04ではsystemdとudev関連のパッケージを先に更新しないと、依存解決の過程で必要な構成要素が外れる場合があると公式が注意を出しています。最初にシステム全体を更新しておいてください。

UTF-8ロケールを整えてuniverseリポジトリを有効化する下準備

ROS 2はUTF-8対応のロケールを前提にしています。Dockerの最小イメージなどではPOSIXのままのことがあるため、次のコマンドで揃えます。

locale
sudo apt update && sudo apt install locales
sudo locale-gen en_US en_US.UTF-8
sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8
export LANG=en_US.UTF-8

続いてuniverseリポジトリを有効にします。ROS 2のパッケージ自体は独自リポジトリから来ますが、その依存パッケージがuniverse側に入っているためです。

sudo apt install software-properties-common
sudo add-apt-repository universe

ros2-apt-sourceパッケージでリポジトリ定義を導入する現行方式

ここが古い記事と最も食い違う箇所です。以前はGPG鍵をcurlで取得してキーリングへ置き、sources.list.d配下にリポジトリ行を書き込む手順でした。現在は鍵とリポジトリ定義をまとめたros2-apt-sourceというDebianパッケージが配布されており、これを入れるだけで設定が完了します。鍵が更新されてもパッケージ側の更新で追随するため、失効に伴うNO_PUBKEYのエラーを避けられる作りです。

sudo apt update && sudo apt install curl -y
export ROS_APT_SOURCE_VERSION=$(curl -s https://api.github.com/repos/ros-infrastructure/ros-apt-source/releases/latest | grep -F "tag_name" | awk -F'"' '{print $4}')
curl -L -o /tmp/ros2-apt-source.deb "https://github.com/ros-infrastructure/ros-apt-source/releases/download/${ROS_APT_SOURCE_VERSION}/ros2-apt-source_${ROS_APT_SOURCE_VERSION}.$(. /etc/os-release && echo ${UBUNTU_CODENAME:-${VERSION_CODENAME}})_all.deb"
sudo dpkg -i /tmp/ros2-apt-source.deb

3行目でOSのコードネームをos-releaseから読み取り、jammy向けのパッケージを取りに行く構造になっています。手打ちで置き換えるなら、22.04ではjammyの文字列が入る、と理解しておけば足ります。

ros-humble-desktopとros-dev-toolsを入れて構成を確定させる

リポジトリが登録できたら、キャッシュを更新して本体を入れます。あわせて既存パッケージの更新も済ませておきます。

sudo apt update
sudo apt upgrade
sudo apt install ros-humble-desktop
sudo apt install ros-dev-tools

導入する構成には段階があります。ros-humble-desktopはROS本体に加えてrviz2やデモ用ノード、チュートリアル一式まで含む構成で、開発機ではこちらを選びます。ros-dev-toolsはビルドツールのcolcon、依存解決のrosdep、リポジトリ取得のvcstoolなどをまとめた開発者向けの一式で、自分でパッケージを書くなら必須です。

導入後、シェルに環境を読み込ませれば、ros2コマンドが使えるようになります。読み込み先は/opt/ros/humble/setup.bashです。

source /opt/ros/humble/setup.bash
ros2 --help

colconワークスペースを作成しビルドを通すまでの実装手順と構成

ROS 2で自分のパッケージを書く場合、作業の単位はワークスペースというディレクトリになります。ここでcolconによるビルドを通せるようにしておくのが、構築作業の実質的なゴールです。

ワークスペース作成からrosdepとcolcon buildを通すまでの流れ

ワークスペースはsrcディレクトリを持つ普通のフォルダで、その中にパッケージを並べます。rosdepは初回だけ初期化が要ります。

sudo rosdep init
rosdep update
mkdir -p ~/ros2_ws/src
cd ~/ros2_ws
rosdep install -i --from-path src --rosdistro humble -y
colcon build --symlink-install

rosdep installは、srcに置かれた各パッケージのpackage.xmlを読み、宣言された依存をaptから補う仕組みです。他所から持ち込んだソースを最初にビルドする際、足りないライブラリをここでまとめて解消できます。colcon buildの生成先はbuild、install、logの3ディレクトリです。付けている–symlink-installは、生成物を実体コピーではなくシンボリックリンクで置く指定で、Pythonスクリプトを書き換えるたびにビルドし直す手間を省けます。

underlayとoverlayの重なりを壊さないビルド運用の勘所

ROS 2の環境は二層構造です。aptで入れた/opt/ros/humble側がunderlay、自分のワークスペースのinstall側がoverlayにあたります。overlayを読み込むと、同名パッケージはoverlay側が優先されます。

ここで踏みやすい地雷が2つあります。1つ目は、overlayを読み込んだシェルでcolcon buildを実行してしまうケース。ビルド時に自分の生成物を参照する形になり、意図しない解決結果を招きます。ビルド用のシェルではunderlayだけを読み込む、という運用に統一してください。2つ目は、パッケージを削除したのにinstallディレクトリへ古い生成物が残るケースで、この場合はbuildとinstallを消してから組み直すのが早道になります。

source /opt/ros/humble/setup.bash
colcon build --symlink-install
source install/setup.bash

環境変数のsourceとROS_DOMAIN_IDで通信範囲を仕切る設定

ROS 2は環境変数で挙動が変わる場面が多く、設定の意味を押さえてから.bashrcへ書くかどうかを決めるのが順序になります。

setup.bashを.bashrcへ書き込む場合に生じる副作用と切り分け

毎回sourceするのが煩わしいため、シェルの起動スクリプトへ書き込む方法が公式にも案内されています。

echo "source /opt/ros/humble/setup.bash" >> ~/.bashrc

単一ディストリしか使わない開発機なら、この設定で問題ありません。一方、HumbleとJazzyを1台で行き来する場合や、複数のワークスペースを切り替える場合は、書き込まずに用途ごとの読み込み関数を用意したほうが安全です。両方のsetup.bashを同一シェルで読み込むと、環境変数のパスが混ざって原因の見えにくい不具合を生みます。切り分けの初手として、printenvでROS_DISTROとAMENT_PREFIX_PATHを確認する癖をつけておくと迷いません。

ROS_DOMAIN_IDとRMW_IMPLEMENTATIONで通信の範囲と実装を選ぶ

ROS 2のノードは既定でドメインID 0に所属し、同じドメインのノード同士が自動で見つけ合います。同一ネットワークに複数の開発者や複数の機体がいると、他人のノードが自分のトピック一覧に現れ、思わぬ挙動の原因です。公式は0から101の範囲で番号を割り当てることを推奨しています。

export ROS_DOMAIN_ID=42
export ROS_LOCALHOST_ONLY=1
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp

ROS_LOCALHOST_ONLYを1にすると通信が同一ホスト内に限定され、教室や共有オフィスのような環境で他機と混ざる事故を防げます。RMW_IMPLEMENTATIONはDDSの実装を選ぶ変数で、Humbleの既定はFast DDS（rmw_fastrtps_cpp）です。Cyclone DDSへ切り替えるにはros-humble-rmw-cyclonedds-cppを別途aptで入れる必要があります。実装を変えると探索やQoSの振る舞いに差が出るため、検証環境と実機で同じ実装に揃えるのが原則です。

talkerとlistenerで導入結果を検証する動作確認の進め方

導入が終わったら、デモノードで通信が成立するかを確かめます。ここまで通れば環境構築は完了と判断してよい工程です。

2つの端末でtalkerとlistenerを走らせて通信成立を確かめる

端末を2つ開き、それぞれで環境を読み込んでからデモノードを起動します。1つ目はC++実装の送信側です。

source /opt/ros/humble/setup.bash
ros2 run demo_nodes_cpp talker

2つ目の端末ではPython実装の受信側を走らせます。

source /opt/ros/humble/setup.bash
ros2 run demo_nodes_py listener

送信側にPublishingの行、受信側にI heardの行が交互に流れれば成立です。この確認はC++とPythonの双方のクライアントライブラリが動いていることを同時に示します。

ros2コマンド群で通信状態を可視化して原因を絞り込む手順と判断軸

通信が成立しないときは、いきなり設定を触らず、状態を見るコマンドで範囲を狭めます。

確認内容	コマンド	読み取り方
ノードの検出	ros2 node list	相手が出るか
トピックの有無	ros2 topic list	chatterが出るか
実データの流れ	ros2 topic echo	値が届くか
環境の健全性	ros2 doctor	警告の内容

ros2 node listに相手が出ないなら探索の段階で止まっており、ドメインIDかネットワーク側を疑います。ノードは見えるのに値が流れてこない場合は、QoSの組み合わせが噛み合っていない可能性が高い領域です。ros2 doctorは環境変数やネットワーク設定の不整合をまとめて報告するため、切り分けの初手として便利に使えます。

Dockerで構築済みのROS 2環境を再現し配布する構成と注意点

チームで同じ環境を配りたい場合や、Ubuntu 24.04の母艦でHumbleを動かしたい場合は、コンテナで固めるのが現実的です。コンテナ隔離の原理そのものはDockerの仕組みを図解で理解｜コンテナ隔離の原理とVMとの違いで解説しています。

公式イメージを土台に開発用コンテナを組む最小構成の書き方と手順

ROS 2にはDocker Official Imagesとして公開されたイメージがあり、ros:humbleを指定すればros-base相当の環境がそのまま手に入ります。rviz2まで含む構成が要るならosrf/ros:humble-desktopを土台にします。

FROM ros:humble
RUN apt-get update && apt-get install -y ros-dev-tools
WORKDIR /ros2_ws
COPY src src
RUN . /opt/ros/humble/setup.bash && colcon build --symlink-install

RUNの中でsetup.bashを読み込んでいるのは、Dockerの各RUNが別シェルで実行され、環境変数が引き継がれないためです。この作法を外すとcolconがROS本体を見つけられず、ビルドが落ちます。Dockerfileの記法そのものはDockerfileとは｜書き方・主要命令・ベストプラクティスにまとめてあります。

コンテナ間とホストをまたぐDDS通信で設定を合わせる注意点と対策

コンテナ化で最も詰まるのは通信です。DDSの探索はマルチキャストとUDPの動的ポートを使うため、既定のブリッジネットワークではコンテナ内外のノードが互いを見つけられません。開発中はホストのネットワークをそのまま使う指定にし、ドメインIDを合わせるのが手早い解決策になります。

docker run -it --rm --net=host -e ROS_DOMAIN_ID=42 ros:humble

本番でホストネットワークを使いたくない場合は、DDSの探索設定でピアを静的に指定する構成へ寄せます。またROS_LOCALHOST_ONLYを1にしたままコンテナを起動すると、ホスト側のノードから見えなくなるため、コンテナに渡す環境変数は毎回確認してください。

ROS 2の環境構築で詰まりやすい箇所と原因を切り分ける実務手順

ここからは環境構築が止まる典型的な症状と原因の見分け方をまとめます。断片的な対処を試す前に、どの層で失敗しているかを決めるほうが早く抜けられます。

症状から原因の層を切り分ける対応表と初手の確認コマンドの使い方

症状	疑う原因	初手の対処
候補パッケージが無い	Ubuntu版の不一致	lsb_release で確認
鍵エラーで更新失敗	旧方式の鍵が残存	apt-sourceを入れ直す
colconが見つからない	dev-tools未導入	ros-dev-toolsを導入
rosdep初期化が失敗	設定ファイルの残存	既存定義を消して再実行
listenerが受信しない	ドメインIDの不一致	両端末の変数を照合

とくに多いのが1行目と2行目です。24.04や20.04でaptを叩いてもros-humble-desktopは出てきません。Ubuntu版を確認せずにリポジトリ設定を疑い始めると、無関係な作業に時間を溶かします。2行目は、古い記事の手順でキーリングを置いたあとに現行方式を重ねた場合に起きやすく、旧来のsources.list.d配下の定義を消してからros2-apt-sourceを入れ直すと解消します。

環境構築を自前で抱えるか外に出すかを分ける採用条件の線引き基準

ここは判断を言い切ります。自前で構築する運用を採るのは、開発者が3名以下、機体構成が1種類、かつ検証と実機が同じUbuntu 22.04で揃っている場合です。この範囲なら手順書1枚で回り、環境差による事故はほとんど起きません。

逆に、次のいずれかに当てはまるなら、コンテナイメージの配布か構築の外注へ切り替えたほうが総コストは下がります。第一に、開発者が5名を超えて参加と離脱が続く場合。手順書の追随が間に合わず、各人の環境差がバグ報告の再現性を落とします。第二に、Humbleと新しいディストリを並行して扱う必要がある場合。1台に両方を同居させる運用は、変数の混線という形で必ず跳ね返ります。第三に、実機がarm64ボードでクロス環境を伴う場合。この構成は依存解決の癖が強く、片手間で維持できる範囲を超えます。

見送るべき場面も明確です。単発の技術検証で1〜2週間しか使わない環境に、コンテナ配布の基盤まで整えるのは過剰な投資になります。その場合はros:humbleの公式イメージをそのまま使い、成果物だけを残す判断で十分です。機体を動かしたあとに生産管理やWMSといった基幹側とつなぐ構想があるなら、構築の段階から連携の口を想定しておくと後の作り直しを避けられます。この領域の設計と実装はAI/IoTソリューションの受託対象です。ROSで動く機体と業務システムをつなぐ構成の相談にも対応しています。ROS自体の位置づけを整理したい場合はROS（Robot Operating System）とは？ノードとDDS通信の構造から読むと前提が揃います。

ROS 2の環境構築でよく挙がる質問と実装者目線から見た回答

ROS 2 HumbleはUbuntu 24.04にインストールできますか？

aptによる公式の導入手順は用意されていません。HumbleのTier 1はUbuntu 22.04（Jammy）で、24.04向けのDebianパッケージは配布されていないためです。24.04の母艦でHumbleを動かす必要がある場合は、ros:humbleのコンテナで22.04環境を包むか、ソースからのビルドを選ぶことになります。運用の手間を考えると、前者が現実的な選択です。

Windowsだけの環境でROS 2 Humbleを試すことはできますか？

可能です。HumbleはWindows 10（Visual Studio 2019）をTier 1として扱っており、公式のインストール手順も用意されています。ただし公開パッケージの検証はUbuntu前提のものが多く、Nav2などの上位パッケージまで含めて動かすならWSL2かUbuntu実機のほうが情報が揃っています。

ros-humble-desktopとros-humble-ros-baseはどちらを選ぶべきですか？

開発機はdesktop、実機に載せる側はros-baseが基本形です。desktopにはrviz2やデモノード、チュートリアル一式が含まれ、可視化しながら開発するには便利な構成です。機体側に可視化ツールは不要で、容量と依存を削れる分ros-baseが向きます。同じノードを両者で動かす限り、通信の互換性に差は出ません。

Humbleのサポート終了までにどのディストリへ移るべきですか？

2026年8月時点で残っているLTSはJazzy Jalisco（2029年5月まで）とLyrical Luth（2031年5月まで）です。数年動かす前提の案件ならLyrical Luthが基準になりますが、依存する上位パッケージの対応状況が移行時期を左右します。Nav2やMoveIt 2など主要パッケージの対応版が出ているかを確認したうえで、Humbleの終了する2027年5月の半年前には移行検証を始めておくのが安全です。

colcon buildが途中で止まる場合は何を疑えばよいですか？

まず依存の欠落を疑い、rosdep installを再実行してください。次に多いのがメモリ不足で、大規模パッケージのC++ビルドは並列度を上げると数GB単位を消費します。–parallel-workers 1のように並列度を落とすと通る場合があります。overlayを読み込んだシェルでビルドしていないかも確認してください。