ROS 2通信設計の基本：Topic・Service・Actionをどう使い分けるか

Sun, 18 Jan 2026 08:02:39 +0900

Topic・Service・Actionは、名前を覚えるより通信契約の違いから考えると整理しやすいテーマです。

先に結論

ROS 2の通信方式は、処理時間だけでなく、クライアントが何を必要とするかで選びます。基本的な判断は次のとおりです。

Topic：センサー値や状態など、継続的に流れるデータ
Service：短時間で完了する単発の要求と応答
Action：進捗・結果・キャンセルを扱う長時間の処理

「何秒以上ならAction」というROS 2共通の時間閾値はありません。完了通知、途中経過、キャンセル、再実行、複数Goalの扱いまで含むインターフェース契約で判断するのが基本です。

なぜ使い分けが必要なのか

ロボットでは、カメラ画像やオドメトリのように継続的に届く情報と、リセットやモード変更のような一度きりの操作が同時に存在します。さらに、ナビゲーションや軌道実行では、開始後も処理が続き、状態を確認したり途中で中断したりする必要があります。

これらを一つの通信方式で表すと、通信の意味と実装が合わなくなります。長時間処理をServiceにすると進捗やキャンセルを表現しにくくなり、単純な状態配信をActionにすると構成が過剰になります。

前提となる3つの用語

Topic：継続的なデータ配信

Topicは、ノード間でメッセージを交換する名前付きの通信チャネルです。Publisherが発行し、Subscriberが受け取るPublish/Subscribeモデルで、複数のPublisherとSubscriberを疎結合に接続できます。

センサー値、画像、関節状態、自己位置、オドメトリなど、継続的に更新されるデータが代表例です。通常は、個々のメッセージに対する完了応答ではなく、到着したデータを継続的に利用します。

ただし、Topicを選んだだけで通信品質が決まるわけではありません。Reliability、Durability、History、DepthなどのQoSをデータの性質に合わせて設定し、PublisherとSubscriberの互換性も確認する必要があります。

Service：短時間の要求と応答

Serviceは、クライアントがRequestを送り、サーバーがResponseを返す通信です。基本的に一つの要求に対して一つの応答を返すため、短時間で完了する単発処理に向いています。ROS 2の公式ドキュメントも、長時間実行される処理ではなく、短時間で完了する計算にServiceを使うよう説明しています。

移動ロボットのリセットやモード切替、マニピュレータの設定変更、即時に返せる状態照会などが適用例です。

なお、「Serviceは同期通信」という説明では、通信モデルとクライアントの待機方法を区別しなければなりません。通信契約はRequest/Responseですが、rclpyには応答をFutureで受け取るcall_async APIもあります。呼び出し側が非同期APIを使っても、Serviceの契約自体は変わりません。

Action：長時間タスクの実行管理

Actionは、長時間実行される処理を対象とします。クライアントはGoalを送り、実行中にFeedbackを受け取り、最後にResultを取得できます。Goalのキャンセル要求も扱えます。

ROS 2のActionプロトコルは、Goal送信、Result取得、キャンセル要求の3つのServiceと、FeedbackおよびStatusの2つのTopicで構成されます。利用者はAction ClientとAction Serverを通じて、タスクのライフサイクルを扱います。

flowchart TD
  A["通信対象を確認"] --> B{"継続的にデータを配信するか"}
  B -->|"Yes"| C["Topicを選ぶ"]
  C --> D["QoS設定と通信相手との互換性を確認"]
  B -->|"No"| E{"短時間で一つの応答を返す単発処理か"}
  E -->|"Yes"| F["Serviceを選ぶ"]
  E -->|"No"| G{"長時間タスクで進捗・結果・キャンセルのいずれかを扱うか"}
  G -->|"Yes"| H["Actionを検討する"]
  H --> I["キャンセル、複数Goal、Goal切替のポリシーを確認"]
  G -->|"No"| J["必要な通信契約を再整理"]

処理時間だけでなく、継続配信、応答、進捗、結果、キャンセルといった通信契約を基準に方式を選択する。

3方式の比較

観点	Topic	Service	Action
通信モデル	Publish/Subscribe	Request/Response	Goal/Feedback/Result
主な対象	継続的なデータ、状態	短時間の単発要求	長時間のタスク
完了応答	標準的には持たない	一つのResponse	Resultを取得
進捗通知	標準機能として持たない	標準機能として持たない	Feedbackを扱える
キャンセル	契約に含まれない	契約に含まれない	キャンセル要求を扱える
移動ロボットの例	センサー、オドメトリ	リセット、モード切替	ナビゲーション、ドッキング
マニピュレータの例	関節・センサー状態	設定変更、状態照会	把持、搬送、軌道実行
主な注意点	QoS互換性	長時間処理に不向き	停止やGoal管理は実装依存

ロボット機能への適用

移動ロボットでは、センサーノードから認識・制御ノードへ送るセンサー情報、オドメトリ、関節状態などをTopicにします。操作画面からのリセットやモード切替は、短時間で結果を返せるならServiceが候補です。目的地までのナビゲーション、ドッキング、経路追従は、実行中の状態や中断を扱うためActionが適しています。

通信設計 on Physical AI Hub