LOG102R2R2R2026/3/17

ロボットアーム（mechArm 270）購入前に事業仮説を立て直した｜Pixels to Motorsの設計転換

シミュレーションフェーズが大方終わった。success=True × 12。4アプローチ × 3速度、全12パターンが通った。30日かけて構築した第一フェーズを、正式に閉じた。

今日は実機を買う日のはずだった。スイッチサイエンスのページを開いて、mechArm 270 M5のカートボタンに指を乗せようとしたとき、一度止まった。

「最短ルートで進む」という言葉が、自分の中で引っかかっていた。最短ルートで進んだら、どこに着くのか。

mechArm 270 M5を買って、接続して、シミュレーションのCSVを流して、カップが台座に乗る。それで終わりだ。デモが完成する。「成功した」と言える。でもそれは、何の成功か。

その問いに答えるまで、買わないことにした。

まず「実機がなければ先に進めないのか」を確認した

最初に問うべきことは単純だった。シミュレーションフェーズが終わって、実機がないとゴールまで行けないのか。行けないなら買う。それだけのことだ。

答えは明確だった。

R2R2Rのコアメッセージはこうだ。iPhoneとUnityだけで、ロボットが物を掴む動作を個人が作れる。これが成立した瞬間、ロボット開発はエンジニアだけのものではないという概念が証明される。

成立した瞬間は実機が動いた瞬間を指す。シミュレーションの中でカップが台座に乗っても、それは証明ではない。現実の空間で、現実のロボットアームが、現実のカップを掴んで置いた瞬間に、初めてパイプラインが繋がったことになる。

実機なしではゴールに着けない。買う。

それは決まった。では何を買うか、という問いが始まった。

慣性で決めると戦略で決めるは違う

プロジェクト開始からLOG101まで、シミュレーションはmechArm 270 M5のURDFを使って構築してきた。Joint可動域もティーチング値も、すべてmechArmの仕様に合わせて設計されている。「だから実機もmechArmで継続する」という判断は、自然に見える。

しかし慣性で決めると戦略で決めるは違う。シミュレーションのURDFが完成していることは、実機選定の理由にはならない。あくまでそれは移行コストが低いという一つの要因に過ぎない。

一度フラットに見直すことにした。比較した候補は3つだった。

mechArm 270 M5（Elephant Robotics）：6軸、ペイロード250g、作業半径270mm、精度±0.5mm、重量1kg。M5Stack Basic搭載。pymycobotによるPython制御。中心対称構造（産業型）。国内ではスイッチサイエンスで取り扱いがあり、PSE対応ACアダプタ同梱。価格は約10万円。

myCobot 280 M5（Elephant Robotics）：同じメーカー・同価格帯の兄弟機。6軸、ペイロード250g、作業半径280mm、精度±0.5mm。UR型構造（コボット型）。mechArmと同じpymycobotで制御できる。構造の違いが最大の差で、UR型は可動域が広く柔軟性が高いが、モーターで姿勢を維持する分だけ安定性が劣る。pick & placeのような産業動作には中心対称構造のmechArmの方が適合する。

DOBOT Magician E6：6軸、ペイロード500g（2倍）、作業半径440mm（1.6倍）。TCP/IP通信対応のSDK。本体重量7.2kgと重く、価格は30万円以上。性能は高いが、「個人が低コストで作れる」というR2R2Rのコンセプトと合わない。

比較した結論：mechArm 270 M5で正しかった。ただし理由が変わった。

URDFが完成済みだから継続する（最短ルート）」ではなく、「pick & placeという産業動作には中心対称構造の安定性が適合しており、かつフェーズ3以降のハードウェア拡張戦略の中で最初の検証機として価格・性能・エコシステムのバランスが最適だから買うという理由に変わった。

理由が変わると、機材の意味が変わる。

グリッパーという盲点

ロボットアーム本体を選んでから気づいた盲点があった。グリッパーだ。

シミュレーションではFixedJointでカップをグラスプしていた。物理的な「手」がなかった。実機では当然、物理的なグリッパーが必要になる。本体だけ届いても、カップを掴めない。

Elephant Roboticsのmecharm 270 M5対応グリッパーには主に3種類ある。

Adaptive Gripper（アダプティブグリッパー）。2フィンガーで対象物の形状に適応する。平行グリップと包み込みグリップの両方が可能。pymycobotから開閉・力・速度を制御できる。「掴めたか」の検出がコードで取れる。

Suction Pump（吸着パンプ）。真空吸着でON/OFF制御。最大45kPaの吸引力。ただしカップのような円筒形の側面からは吸着できない。カップの口は開いているため上面からの吸着も不安定だ。このターゲットには合わない。

Parallel Gripper（パラレルグリッパー）。固定幅の平行2フィンガー。シンプルだが幅の調整ができない。

結論：Adaptive Gripper一択。 理由はシミュレーションのFixedJointに最も近い把持動作ができることと、コードから把持確認ができることの2点だ。本体と同時に注文する。

SO-ARM100/101

mechArmとAdaptive Gripperの購入先を調べているとき、全く別のロボットアームが視界に入ってきた。

SO-ARM100 / SO-101。 Hugging FaceとThe Robot Studioが共同開発した、オープンソースのロボットアームだ。

スペックを見た瞬間に手が止まった。シングルアームが$115。デュアルアームセット（リーダー + フォロワー）が$220〜$240。3Dプリントで自作可能。Seeed StudioやWowRoboなど複数のベンダーから購入可能。LeRobot（Hugging Faceのオープンソースロボティクスフレームワーク）にネイティブ統合されている。GitHubのコミュニティには1,000人以上のビルダーがいる。

これはロボットアームの話ではなかった。

AIロボティクス民主化のプラットフォームだった。

SO-101の動画を見た。テレオペレーション——リーダーアームを人間が操作し、フォロワーアームがそれをリアルタイムで模倣する。グリッパーに搭載したリストカメラと外部の固定カメラ、2つのカメラで環境を認識しながら動作の精度をAIが補正する。20〜30回デモンストレーションを繰り返すと、フォロワーアームが自律的に同じタスクを実行できるようになる。

これ、R2R2Rの思想に近いと感じた。

R2R2Rが解こうとしていること：人間の意図をロボットの動きに変換する。入力はiPhoneのスキャンで、媒介はUnityのデジタルツインで、出力はロボットアームの動作だ。

SO-101が解こうとしていること：人間のデモンストレーションからAIが動作を学習する。入力は人間の手の動きで、媒介は模倣学習モデルで、出力はロボットアームの自律動作だ。

手段は違う。しかし「人間の動作意図をロボットに橋渡しする」という方向性は同じだった。

R2R2RとSO-101の「決定的な違い」

思想が近いと感じながら、一方で決定的な違いも見えた。それを整理することで、R2R2Rの独自性が明確になった。

SO-101が解いている問い：どうやってロボットに動きを覚えさせるか

R2R2Rが解いている問い：どうやってロボットの動きを設計するか

覚えさせると設計するは、似ているようで全く別の行為だ。

SO-101のアプローチは「実演→学習」だ。人間が実際にやって見せると、AIがその動作パターンを抽象化して汎化する。カメラが精度の代わりを担う。環境が変わっても、学習済みモデルが適応する。

R2R2Rのアプローチは「設計→検証→展開」だ。iPhoneで現実をスキャンして、Unityで動作の意図をシミュレーション上で設計して、検証済みの動作を実機に移す。設計の意図がコードとデータとして残る。再現性が高い。

この違いは、使い手の違いでもある。SO-101は動かしたい人のためのツールだ。R2R2Rは動作を設計したい人のためのツールだ。

そしてSIerが必要としているのは後者だ。

将来も踏まえた上で考える：事業として何を証明すべきか

問いの立て方を変えた。

今すぐ動かすための最短ルートではなく、R2R2Rが事業として成立するために、今何を選ぶべきか。

R2R2Rは最終的に事業として成立することを目指している。研究・開発止まりでは意味がない。誰が買うのか。何に困っている人が、いくら払うのか。そのためにmechArmのデモは何を証明しなければならないのか。

2つのパスを整理した。

パス①：ロボットメーカー・SIerへのFlip

SIerが現場で使うのはFANUC、安川、KUKA、UR——mechArmとは別の世界だ。SIerがR2R2Rに払うのは「動作設計ノウハウ」ではない。「このパイプラインを使えば自社の現場導入コストが下がる」という実績に対して払う。

問題はここだ。mechArm 270 M5で動いたデモを持っていったとき、SIerの担当者は「面白い研究ですね。で、FANUCに移植できますか？」と聞く。mechArmはSIerが使っているハードウェアとは別の世界だ。機種の壁を越えられないなら、SIerには刺さらない。

パス②：Hugging Face / AI系スタートアップへのFlip

LeRobotのエコシステムには「シミュレーションで動作を設計する」部分が弱い。R2R2RにはAIで学習させる部分がない。この2つは補完関係にある。

組み合わせると一つの完全なパイプラインになる。iPhoneでスキャン→Unityで設計→LeRobotで学習→実機で実行。このパイプラインを作った人は、まだいない。SO-101への対応がこのパスへの接続になる。

どちらのパスも、mechArmだけでは完結しない。そしてどちらも、1機種のデモでは売れない。

ターゲットが定まった：SIerのエンジニア

町工場のおじさんがiPhoneで撮るだけでロボットに動作を教えられるというビジョンは魅力的に聞こえる。しかし現時点では時期尚早だと判断した。

理由はシンプルだ。「ロボットに何をさせるか」という問いが育っていない市場に入っても意味がない。

町工場でロボットを導入するには、まず「何をさせるか」が決まっていなければならない。どの工程を自動化するか、どのくらいの精度が必要か、どんな形状のワークを扱うか。これらが決まっていない状態で「iPhoneで撮って動かせます」と言っても、誰も動かない。

SIerはすでにその問いを顧客と一緒に解いている。困っているのはその次の工程——動作をどう設計し、どう実機に実装するかという工数だ。

現状のSIerの動作設計フローを具体的に想像すると、こうなる。

まず現場調査（半日〜1日）。ワークの形状・重量・配置を計測し、設置環境を確認する。次に動作仕様書の作成（数日）。どの関節をどう動かすかを紙に起こす。続いてオフラインティーチング（数日）。専用ソフトウェアで動作プログラムを書く。そして実機での調整（数日〜数週間）。シミュレーションと現実のズレを一つ一つ潰していく。最後に納品。1案件で数週間〜数ヶ月かかる。エンジニアの工数が事業のボトルネックになっている。

R2R2Rが入るとどうなるか。現場をiPhoneでスキャン（数時間）。Unityで動作設計・検証（1日）。実機展開（数時間）。納品。

現場調査から動作設計までを1日で終わらせる —— これがR2R2Rのバリュープロポジションだ。

ただし、このバリュープロポジションを成立させるためには一つの前提がある。SIerが実際に使っているロボットで動くこと、だ。mechArmで動いても、SIerのロボットで動かなければ意味がない。

ここで「動作のポータビリティ」という問いが浮かび上がる。

ロボット業界の未解決問題：動作のポータビリティ

ロボット業界には長年解けていない問題がある。

FANUCで作った動作プログラム → 安川では動かない
安川で作った動作プログラム → URでは動かない
URで作った動作プログラム   → FANUCでは動かない

ロボットメーカーごとに制御言語・通信プロトコル・座標系の定義が異なる。あるメーカーで作った動作プログラムは、別のメーカーの機種では使えない。これがSIerの工数の正体だ。ロボットを変えるたびに、動作設計をゼロからやり直す。

ロボット業界はこの問題をROSで技術的に解こうとしてきた。共通のメッセージフォーマット、標準化されたドライバ、ハードウェア非依存のプランニングフレームワーク。ROSは確かに有効な解だが、ROSを使いこなすにはエンジニアリングの深い知識が必要だ。「ロボット開発をエンジニア以外にも開く」というゴールとは方向が逆だ。

R2R2Rが違うのは、UXデザインから解くことだ。

「共通プロトコルを作れば統一できる」というエンジニアリングのアプローチではなく、「人間が設計した動作の意図を、どのハードウェアでも再現できる構造にする」というUXデザインのアプローチ。

iPhoneで撮ってUnityで設計した動作CSVが、mechArmでも動く。SO-101でも動く。UFACTORY Lite 6でも動く。そしてLite 6で動いたコードが、同じSDKを使う産業用xArm 6でも最小限の変更で動く。

設計した動作がハードを選ばない——これを動作のポータビリティと呼ぶことにした。

これはロボット業界の問題を、UXデザインの観点から解く試みだ。Unityというゲームエンジンが「動作設計のDAW」になり、iPhoneが「現場スキャナー」になり、HALが「プロトコル変換レイヤー」になる。使い手は制御プロトコルを意識しなくていい。

3機種戦略：なぜ異なるアーキテクチャが必要か

動作のポータビリティを証明するためには、複数の異なるアーキテクチャのロボットで同じパイプラインが動くことを実際に示さなければならない。1機種では「機種固有のデモ」だ。2機種では「2機種での動作確認」だ。3機種になったとき、それはパイプラインの汎用性の証明になる。

重要なのは3機種がそれぞれ異なる制御アーキテクチャを持っていることだ。

機種	制御方式	接続	精度	価格帯	戦略的役割
mechArm 270 M5	pymycobot	USB-C シリアル	±0.5mm	〜10万円	最初の証明・検証機
SO-101	FEETECH サーボ + 模倣学習	UART	非公表（AI補正）	〜3万円	民主化の証明・LeRobot接続
UFACTORY Lite 6	xArm Python SDK	TCP/IP（Ethernet）	±0.1mm	〜75万円	産業グレード証明・SIer橋渡し

3機種の制御方式がすべて異なる。シリアル・UART・TCP/IP。プロトコルが違う。価格が40倍くらい違う。設計思想が違う（完成品・DIY・産業用）。それでも同じCSVと同じコード構造で動いたとき、R2R2Rは次のことを言える：

約1万8,000円（$115）のDIYアームでも、75万円の産業グレードアームでも、同じコードで動く。iPhoneで撮ってUnityで設計したら、あとはアームを選ぶだけ。

この言葉がSIerへの提案の核心になる。

mechArm 270 M5：最初の検証機

今すぐ買う。フェーズ2のターゲットはパイプラインを初めて実機で動かすことだ。CSVをpymycobotに流す。関節が動く。カップを掴む。台座に置く。その一連が現実の空間で起きた瞬間に、シミュレーションと実機が繋がる。

SO-101：民主化の証明とLeRobotへの接続

フェーズ3で追加する。約1万8,000円（$115）でも同じパイプラインが動くというメッセージは、R2R2Rのコアメッセージ個人でも作れるをさらに強化する。

加えて、LeRobotエコシステムへの接続点になる。現状、LeRobotにはシミュレーションで動作を設計してから実機へ（sim-to-real）という方向のパイプラインが整備されていない。R2R2RがそのパイプラインをSO-101向けに構築すれば、Hugging Faceの開発者コミュニティに直接リーチできる。

ただし注意点がある。SO-101のURDFはUnityへのインポートで問題が報告されている（関節制限未定義・一部軸反転）。フェーズ3ではURDFの修正作業が必要になる。

UFACTORY Lite 6：産業グレードへのスケールパス

フェーズ4で追加する。精度±0.1mmはmechArmの5倍だ。

最も重要なのは、Lite 6で動いたコードが産業用xArm 6に最小限の変更で移植できることだ。Lite 6とxArm 6は同じxArm Python SDKを使う。SIerがすでに知っているアーキテクチャに繋がる。

Lite 6は研究用の小型アームではなく、産業用xArmへの入り口として機能する。

3層アーキテクチャ：設計の核心

3機種を統一して制御するために、動作を3つのレイヤーに分解した。

レイヤー1：動作の意味（What）

カップを掴んで台座に置く。タスク定義。ハードウェアに依存しない。mechArmでもSO-101でも、カップを掴むという意味は変わらない。

レイヤー2：動作の軌跡（How）

関節角度のシーケンスをCSVで表現する。Unityのシミュレーションが生成する。ハードウェアに近いが抽象化できる。6軸の角度値というフォーマットは、異なるアームでも（ゼロ点キャリブレーション後は）共通して使える。

レイヤー3：動作の実行（Execute）

各ハードのSDKへの変換。HAL（Hardware Abstraction Layer）がここを担う。ここだけがハード依存だ。

この3層構造の意味は、レイヤー1とレイヤー2を変えずに、レイヤー3だけを差し替えることで別のアームに対応できることだ。

HALの設計と実装：今日の技術的成果

3機種対応を最初から見越して、今日HALを設計・実装した。

コードの構造はシンプルだ：

# 抽象基底クラス（全アダプター共通）
class RobotInterface(ABC):
    @abstractmethod
    def connect(self) -> bool: ...

    @abstractmethod
    def send_angles(self, angles: List[float], speed: int) -> bool: ...

    @abstractmethod
    def get_angles(self) -> List[float]: ...

    @abstractmethod
    def is_moving(self) -> bool: ...

    @abstractmethod
    def go_home(self) -> bool: ...

    # 共通の安全チェック（abstractmethodではない）
    def check_angles_safe(self, angles: List[float]) -> bool:
        # 全関節が±170度以内かを確認
        # 範囲外ならWarningログを出してFalseを返す

各アームのアダプターはこのインターフェースを実装する：

class MechArmAdapter(RobotInterface):   # pymycobot（シリアル） ← 実装済み
class SO101Adapter(RobotInterface):     # FEETECH UART ← フェーズ3スタブ
class Lite6Adapter(RobotInterface):     # xArm SDK・TCP/IP ← フェーズ4スタブ

factory.pyを使えばロボットの切り替えは1行で済む：

robot = create_robot("mecharm", port="/dev/cu.usbserial-XXXX")
robot = create_robot("so101",   port="/dev/ttyUSB0")      # フェーズ3
robot = create_robot("lite6",   ip="192.168.1.100")       # フェーズ4

# どのアームでも同じインターフェース
robot.connect()
robot.send_angles([38.51, 79.01, -34.54, 0, -48.13, 0], speed=30)
angles = robot.get_angles()
robot.go_home()

安全設計：check_angles_safe()

HALの設計で一つ重要な判断をした。send_angles()の中で必ずcheck_angles_safe()を呼ぶ構造にした。

def send_angles(self, angles, speed):
    if not self.check_angles_safe(angles):
        logger.warning("安全チェック失敗。送信をスキップします。")
        return False
    self._robot.send_angles(angles, speed)
    return True

シミュレーションでは関節が壁を突き抜けても再起動すれば済む。実機では実機が破損する。送信前の安全チェックはHALレベルで強制する設計にした。

SO-101とLite 6はスタブで実装

実装したのはmechArmアダプターと共通基底クラスだ。SO-101とLite 6は接続不可のWarningログを出してFalse/空リストを返すスタブとして実装した。

なぜスタブをわざわざ実装するか。理由は2つある。

1つ目は、実機が届いたらアダプターを差し替えるだけで動く構造にしておくためだ。コードの骨格が最初から3機種を想定して書かれていれば、フェーズ3でSO-101を追加するときにアーキテクチャを変える必要がない。

2つ目は、将来の自分へのドキュメントとして機能するためだ。スタブのコメントに「フェーズ3で実装予定。FEETECH UART + LeRobot SDK使用」と書いておけば、数ヶ月後に戻ってきたときに何をすればいいかが明確だ。

実機到着前にできること

mechArmが届くまでの間にも進められることがある。

CSVウェイポイント変換スクリプト。シミュレーションが生成した全フレームのCSVをそのまま実機に流すのは危険だ（シリアル通信の速度限界で詰まる）。GRASPやLIFTなど5点のキーフレームを抽出するスクリプトをmechArm到着前に完成させておく。

ゼロ点キャリブレーションの設計。シミュレーションのゼロ点（全関節0度）と実機のゼロ点が一致しているか確認するスクリプト。これが合っていないと、CSVの角度値が実機では全く別の位置を示す。実機破損リスクがある最重要確認項目だ。

iPhoneによるBefore/After比較の手動検証。カップが台座に乗ったかどうかをiPhoneのカメラで確認する仕組みの設計。LiDARの有効距離（0.5m以上）に対して台座までの距離（約25cm）が近すぎる可能性があるため、RGBカメラでの差分比較も選択肢に入れる。

SIerへの提案時に必要なもの

3フェーズが完了したとき、SIerに持ち込める状態になる。その時点で揃っているものを整理しておく。

① デモ動画（3機種）。「mechArmで動いた」「SO-101でも動いた」「Lite 6でも動いた」。3機種の動画が並ぶとき、パイプラインの汎用性が視覚的に証明される。

② 工数比較データ。従来手法（数週間）vs R2R2Rパイプライン（1日）。日数・ステップ数・必要スキルの差を数値で示す。

③ パイプライン仕様書。iPhone → Unity → HAL → 任意のロボット。各ステップの入力・出力・所要時間・必要スキルを仕様として文書化する。

④ 対応機種リスト。「現在3機種対応。URDFとPython SDKがあれば拡張可能」。SIerが使っているロボットのURDFがあれば、新しいアダプターを書くだけで対応できることを示す。

この4点が揃ったとき、R2R2Rは「面白い研究」ではなく「使えるツール」としてSIerに提案できる。

フェーズロードマップ

フェーズ2（今すぐ〜）：mechArm 270 M5
  購入：スイッチサイエンス + Adaptive Gripper
  目標：シミュレーションのCSVが実機で動く
  完了条件：pick & placeが1回成功 + ログが記録される

フェーズ3（mechArm完了後）：SO-101追加
  LeRobotエコシステムへの接続
  URDFのUnity対応修正（既知の問題あり）
  「$115でも動く」民主化の証明
  完了条件：mechArmと同じCSVでpick & placeが動く

フェーズ4（SO-101完了後）：UFACTORY Lite 6追加
  産業グレードへのスケールパス
  Lite 6 → xArm 6への移植確認
  完了条件：3機種で同一CSVが動く + 工数比較データが揃う

事業展開：SIerへの提案
  デモ動画3機種 + 工数比較データ + パイプライン仕様書

決まったこと

mechArm 270 M5とAdaptive Gripperを注文する。

ただし、最短ルートだからではなく、3機種戦略の最初の検証機として、動作のポータビリティを証明するパイプラインを構築するために買う。

HALの設計は完了した。mechArmが届いた日に繋いで動かすための準備ができている。SO-101とLite 6のスタブも実装済みで、フェーズ3・4でアダプターを差し替えるだけの構造になっている。

シミュレーションフェーズの間は、パイプラインの設計だった。これからの実機フェーズは、その設計が本当にポータブルかどうかの証明だ。

iPhoneで始まったパイプラインが、約1万8,000円（$115）のDIYアームでも、75万円の産業グレードアームでも動く。その瞬間が、R2R2Rの本当のゴールだ。

HTML図解

※ プロジェクト名「R2R2R」は、UC Berkeley・Toyota Research Instituteの研究「Real2Render2Real」（Yu, Fu et al., 2025）の概念に触発されています。現実空間をデジタルツイン化し、仮想空間での試行から得た知見を実世界のモーター駆動へ還元する——その設計と実装過程を毎日記録しています。技術アプローチおよび目的は独自のものです。