—
はじめに:なぜ今、Data Scientist がロボットをやるのか
「自分が作ってきたモデルは、本当に”動く世界”に繋がっているのか?」
この問いを持ったのは、データサイエンティストとして複数の業界でモデルを作ってきた経験からだ。
製造業では異常検知モデルを構築し、HRではデータドリブンな採用モデルを設計し、小売ではPOSデータを用いたダッシュボードを作ってきた。
しかし気づいた。
センサーデータを分析することと、センサーを持つロボットを動かすことはまったく別の世界だ。
ダッシュボードの上で完結する知識を、物理世界に接続したい——その衝動から、このブログはスタートした。
この記事では、データサイエンティスト(DS) 出身者が「AIロボット実装」に踏み出す際に直面する最初の問い——何を買い、何を使い、どこから始めるか——に対して、私が2026年時点で下した判断とその根拠を記録する。
この記事で分かること
・ハードウェア選定とその理由
・環境構築最大の壁は依存関係エラーである
・DataScienceの経験は、AIロボット実装にそのまま活きる
1. 技術スタックの全体像
まず大局から整理する。AIロボットは以下の4層構造で考えると理解しやすい。
| 層 | 役割 | 主要技術 |
|---|---|---|
| ① 知覚層 | データ取得 | OpenCV / Whisper |
| ② 認識層 | 認識・理解 | YOLOv9 / GPT-4o |
| ③ 判断層 | 意思決定 | ChatGPT API / LangChain |
| ④ 実行層 | 物理制御 | ROS2 / MoveIt2 |
DS出身者にとって親しみやすいのは②〜③の認識・判断層だ。モデルの訓練・推論、APIの活用——これらはすでにスキルセットとして持っている。未知なのは①の「センサーからの入力」と④の「物理的な出力」の部分になる。①・④のいずれも、AIの世界からは少し外れた、「リアルワールド」のデータ・デバイスをどう扱うか?というところに関する技術である。
この構造を理解した上で、私は「既存のDS知識を最大限に活用しながら、①・④を学ぶ」という方針を定めた。特に④については、物理制御をするためのハードウェアやソフトフェア(ROS2等)の理解が必要であるため、④をファーストステップとして学ぶこととした。
—
2. なぜ Raspberry Pi 5 を選んだか:5つの判断基準
ハードウェア選定で最初にぶつかる問いが「Pi5 か、Jetson か」だ。
結論から言う。2026年時点の個人実装では、Raspberry Pi 5 (8GB)を選ぶのが合理的だ。
判断基準①:コストと入手性
| 判断基準 | Raspberry Pi 5(8GB) | Jetson Nano |
|---|---|---|
| 価格 | 約32,900円(TRASKITセット) | 約15,000〜20,000円(本体のみ) |
| 入手性 | Amazonで翌日配送可 | 在庫不安定・個人輸入が必要なことも |
| セット内容 | ケース・ファン・電源・microSDケース含む | 別途調達が多い |
実務での意思決定と同じだ。「最適解」よりも「今すぐ動かせる構成」の方が価値が高い局面がある。学習フェーズにおいては特にそうだ。
判断基準②:ROS2との親和性
ROS2(Robot Operating System 2)の推奨環境はUbuntu 24.04 LTSであり、Raspberry Pi 5は対応している。Jetson NanoはNVIDIA JetPackに依存しており、ROS2のセットアップに追加の手順が必要になるケースが多い。
環境構築に時間を取られることは、学習の最大の障壁になる。Pi5の方が「ROS2入門」という文脈では摩擦が少ない。
判断基準③:DS知識との接続しやすさ
PythonでROS2ノードを書くことができる。これはDS出身者にとって大きなアドバンテージだ。
– scikit-learnで作った推論モデル → ROS2ノードに移植可能
– pandasで処理してきたデータ → ROSbagでもpandasに変換可能
– API呼び出し(ChatGPT等) → ROS2ノードから非同期で呼び出せる
判断基準④:将来の拡張性
Hailo AI HAT+というAIアクセラレータをRaspberry Pi 5に追加できる(今後検証予定)。これによりエッジでのYOLO推論をGPUなしで高速化できる。
3. Raspberry Pi 環境構築
Pi5本体だけでなく、周辺機器のセット品として「TRASKIT 8GB スターターキット(8GB RAM / 64GB microSD付き)」を選んだ。理由は3つある。
-
① 金属ケース付き
発熱対策として必須。CPUに負荷をかけるAI推論では、素のケースでは冷却性能が不十分。 -
② 8GBモデル
LLM推論やROS2+カメラ処理を同時実行すると、4GB以下では頻繁にスワップが発生する。 -
③ セット内容の安心感
電源・HDMIケーブル・冷却ファンが揃っており、到着日からすぐに作業を開始できる。
実際に使用したキットはこちら:
👉 TRASKIT Raspberry Pi 5 スターターキット(Amazon)
ROS 2の通信において最も基本となるのが、「ノード(Node)」間で行われる「Pub/Sub(パブリッシュ/サブスクライブ)通信」という仕組みである。詳細については今後記事でまとめる予定。(作成次第、この記事にもリンク掲載予定です)
環境構築の手順については、以下の記事でまとめたので、是非一読いただきたい。初心者向けに書いた記事だが、約2時間で最低限の環境を作成することが可能。

4. ROS2のPub/Sub通信のデモ
ROS2では、Pub/Sub通信という概念を用いてデータのやり取りが行われる。
サンプルプログラムを回し、実際にPub/Sub通信を体感してみる。
以下は、上記環境構築が一通り完了し、Raspberry Pi上でROSが使えることが前提であるので、まだ環境構築が終わってない方は、上記で貼付したリンクの記事を見てほしい。
1.デモノードパッケージをインストール
以下を実行。
sudo apt install -y ros-jazzy-demo-nodes-cpp ros-jazzy-demo-nodes-py
環境の読み込みも実行。
source /opt/ros/jazzy/setup.bash
2.Talkerノードの実行
以下で、Talkerノードの実行。
ros2 run demo_nodes_cpp talker
成功時の出力例
以下のように、Talkerからメッセージが毎秒出力される。
[INFO] [1776092898.021003769] [talker]: Publishing: 'Hello World: 1'
[INFO] [1776092899.020978638] [talker]: Publishing: 'Hello World: 2'
[INFO] [1776092900.020963891] [talker]: Publishing: 'Hello World: 3'
```
3.Listenerノードの実行
Talkerノードを実行しているPowerShellとは別で、PowerShellを起動し、SSH接続。
ssh (ユーザー名)@(ホスト名).local
Listenerノードを実行する。
ros2 run demo_nodes_py listener
talkerノードを実行したPowerShellに表示されるメッセージが、listenerノードを実行したPowerShellでも出力ができていれば、ROS2が正常にインストールされ、ROS2のPub/Sub通信が正常に動作している証拠だ。
ROS2のトピック通信についての記事は今後執筆予定のため、乞うご期待!
5. DS知識との対応関係:気づいたこと
DS実務経験者として、ROS2の設計思想に触れたときに感じた「あ、これ知ってる」という感覚を記録しておく。
Pub/Sub通信 → Kafkaと同じ構造
ROS2のトピック通信は、Kafkaと同じPublish/Subscribe(Pub/Sub)パターンを採用している。
| 概念 | Kafka | ROS2 |
|---|---|---|
| データを送る側 | Producer | Publisher |
| データを受け取る側 | Consumer | Subscriber |
| データの経路 | Topic | Topic |
| 処理単位 | Consumer Group | Node |
DS実務でKafkaを使ったことがある人は、ROS2のトピック通信を直感的に理解できるはずだ。今回の動作確認で`ros2 run demo_nodes_cpp talker`(Publisher)と`ros2 run demo_nodes_py listener`(Subscriber)が/chatterトピックを通じて通信する様子を確認したが、これはまさにKafkaのProducer-Consumerパターンそのものだと感じた。(まだB-002の記事を確認していない方は、是非一読していただきたい)
DAG設計 → ノードグラフとの共通点
Airflowで有向非巡回グラフ(DAG)を設計したことがある人にとって、ROS2のノード構成は比較的イメージしやすいだろう。
「どの処理がどのデータを受け取り、どこへ渡すか」を設計するという点では、発想は共通している。
ただし、Airflowがバッチ処理であるのに対し、ROS2はリアルタイムかつ非同期にデータが流れ続ける点が大きく異なる。そのため、「順序を制御する設計」から「流れを維持する設計」へのシフトが求められる。
リアルタイム推論 → バッチ処理との最大の違い
DS実務での推論はほとんどがバッチ処理だった。一方ロボットの場合、カメラ映像をリアルタイムで処理し続ける必要がある。これが最も大きな設計上のシフトだ。
– バッチ:「100件のデータをまとめて処理して結果を返す」
– リアルタイム:「毎フレーム(30fps=33ms以内)に推論結果を返し続ける」
レイテンシへの意識、非同期処理の設計、メモリ管理——これらがロボティクスAI実装における新しい学習領域だ。
—
まとめ
今回の記事では、DS出身者がロボティクスに踏み出すうえで、必要な知識の全体像を洗い出したうえで。どの分野を重点的に学んでいくのかを整理した。そのうえで、物理制御の役割を担うハードウェアや、環境構築について調査し、複数の記事でまとめた。DS出身者から見ると、一見触ったことのない知識でもイメージが付きやすい知識が多く、想定以上に学びやすそうだという印象を受けた一方、リアルタイム推論を行う上での実装や知識が新しい学習領域になるように感じた。
-
■ ハードウェア
Raspberry Pi 5(8GB)+ TRASKITセットが2026年時点の最適解 -
■ 環境構築セットアップ時間
総計約2時間でベーシックな開発環境が構築可能 -
■ 最大の学習コスト
依存関係エラーの解決(特にliblz4-dev、libzstd-dev周り) -
■ DS知識の活用度
Pub/Sub(Kafka)、DAG設計(Airflow)の経験がそのまま活かせる -
■ 次のボトルネック
リアルタイム推論とバッチ処理のパラダイム差
—

