SO-101 失敗から学ぶアームを作る Log#1 | 精度を上げることと、失敗から学ぶことは違う ― 単腕から双腕へ、ハードを選び直す

この回には、コードも実機ログもない。あるのは対話だけだ。FKテーブルを濃くすると何が手に入るのか、という技術的な問いから始まって、最後には「次に何を作るのか」「どのハードでそれを作るのか」というシリーズの転換にたどり着いた。その往復を、要約せずそのまま残す。途中で何度か考えを外し、そのたびに引き戻された。買おうとして、やめた。一区切りつけたつもりが、まだ足りないと気づいた。その外した過程、迷った過程こそが、何を作ろうとしているのかを浮かび上がらせたからだ。だから訂正されたところも、捨てた議論も、買わないと決めた高価なロボットのことも、消さずに記録する。読み返したときに価値があるのは、きれいに整理された結論よりも、結論にたどり着くまでに何を考えて何を捨てたか、のほうだ。

濃くすると、どれだけ時間がかかるのか

動的追従のシリーズで追ってきたのは、「カメラで対象を追従しながら、PICKとPLACEを行えるか」だった。動いているものをカメラで捉えながら、掴み、置く。そのために、FKテーブル――関節角の組と、そのときエンドエフェクタが来る先端位置を並べた表――を引いて、行きたい座標に一番近い姿勢を選んで送る、という仕組みを積み上げてきた。前回はそのテーブルに穴があって、補正後の狙いへ降りられず、Unityのデジタルツインで作り直して点を足した。その続きで、こういう問いが出た。

FKテーブルの範囲と密度をもっと濃くすると、どのくらいデジタルツイン学習に時間がかかるのか。

まず時間の話から答えた。正確に答えるには、今のスキャン構造の数字を押さえる必要がある。前回の実測が出発点になる。6つの基準姿勢に各関節を振った格子をかけて約10万点、それを20体並列で約42分。ここから1点あたりを逆算すると、42分=2520秒を100,842点で割って、約25ミリ秒/点。これが基準値だ。

時間はほぼ総点数に比例する。範囲を広げても密度を上げても、最終的に効くのは「総点数が何点になるか」だけ。だから「範囲」と「密度」を分けて考える必要がある。この二つは、増え方がまるで違う。

スキャンは、各基準姿勢から関節を振って到達姿勢を一つずつ計算し、そのときのグリッパー先端位置を記録していく。だから1点を計算・記録する時間がほぼ一定で、総点数が決まれば総時間が決まる。20体を並列で回しているので、その20倍の速さで埋まっていく。前回の42分は、この並列込みの実測だ。

密度を上げる――同じ範囲をもっと細かくする――場合。今は1つの基準姿勢に対して各関節を一定の刻みで振った格子を作っている。格子の刻みを細かくすると点数は急激に増える。ここが落とし穴で、6軸の格子は次元の掛け算になる。仮に各軸の刻みを半分(倍の解像度)にすると、単純には2の6乗＝64倍。10万点が640万点になり、時間も42分×64でおよそ45時間に化ける。密度を上げるのは、軸数が効いて爆発的に重くなる。実際には今の格子が6軸すべてをフルに振っているわけではない(j5は固定、範囲の狭い軸もある)ので64倍は最悪ケースだが、それでも「密度を2倍」は時間が桁で増える、という感覚は持っておくべきだと答えた。

範囲を広げる――もっと広いエリアをカバーする――場合は、点数に対して線形だ。今はj0プラス側の左奥が薄かったので6基準を足した。アーム全体の作業範囲をまんべんなくカバーしようと基準姿勢を増やすと、たとえば6を60(10倍)にして約100万点で7時間ほど、と読める。範囲拡張は密度ほど怖くない。線形だから見積もれる。点数と時間の関係はこうだ。

現行テーブル全体(約710万点)を一から回したら約2日かかる計算だが、実際は既存点を再利用して差分だけ足す。前回が42分×2回で済んだのはそのためだ。全部を作り直さず、穴の領域だけ足す。これが差分スキャンの効きどころになる。つまりテーブルを濃くすることは、やろうと思えばできる。範囲を広げるなら時間は読めるし、密度を上げるなら桁で重くなるが不可能ではない。問題は時間ではなく、それをやる意味があるのか、だった。ここから先の対話は、その意味を問う方向に向かっていく。

数字は出た。だが、答えながら引っかかっていた。なぜ濃くしたいのか。そこが分からないと、濃くすることが効くのかを判断できない。範囲の問題なのか、密度の問題なのか、それとも濃さの問題ではないのか。問いの背景を聞いた。

「意思があるように動く」とは何か

返ってきたのは、時間やテーブルの話ではなかった。

最終的に目指したいのは、安価なアームを使いながら、自分で意思があるかのように動きタスクをこなすロボットアーム。そのためのアプローチの一つとして、単にFKテーブルの範囲と密度を増やすことでどんな結果が得られそうか知っておきたい。

「意思があるように動く」。この言葉で、話の階層が変わった。

ここで一度、大きく読み違えた。「意思があるように見える」を、動きの見た目の質――滑らかさ、予備動作、タメ――の話だと受け取ったのだ。

そのときの考えはこうだった。同じ終点に着くロボットでも、等速でガクガク動けば機械的に見える。掴む前にわずかに対象へ向き直る予備動作があり、出だしはゆっくり、触れる直前にさらに減速する、そういう加減速のプロファイルがあれば「狙っている」「迷っている」ように見える。人が意思を感じるのは、ほぼこの過程の側だ――と。これは以前から温めていた「Motion Uncanny Valley」の議論ともつながっていた。完全に機械的な動きを超えても、完全に自然には遠い谷がある。機械的だが優雅な動き(Direction B)は未開拓だ、という話だ。だから僕は、終点をいくら精密にしても過程が点間移動なら意思は宿らない、軌道に経由点を置き、速度プロファイルを設計し、タメを入れる層が要る、と答えた。FKテーブルを濃くするより、まず「どう動くか」を一箇所変えてみよう、descendの速度を等速から「ゆっくり入って触れる直前に減速」に変えてみては、と具体案まで出した。

だが、それは違った。訂正が入った。

「意思があるように動く」について補足する。動きの精度やスピードが非常に速く動く、または人の腕のように滑らかに動く、ということを指しているわけではない。PICKやPLACEの失敗があったとして、その失敗から学び、次には成功するための一筋を自らで考えて達成することができる。これを「意思があるように動く」という意味で言っている。伝わるか。

——伝わりました。そして、さっきの答えは的外れでした。 見せかけの動きの話ではなく、中身の知能の話だった。失敗から自分で原因を考えて、次の一手を立て直して、最終的にタスクを達成する。その自律的な問題解決そのものを「意思」と呼んでいる。滑らかさでも速さでもない。僕が長々と述べた予備動作やタメや速度プロファイルは、全部「見た目」の話で、言われていたのは「中身」だった。ここがズレたまま設計に入れば、また見当違いのものを作る。すり合わせて、ようやく同じものを見はじめた。

捨てた議論を残しておくのは、これが「精度や見た目を上げる話ではない」という、このシリーズの輪郭を、裏側から定義しているからだ。意思とは、滑らかさではない。速さではない。予備動作の優雅さでもない。失敗から立て直すことだ。

言い換えると、こうだ。上手いアームと、学ぶアームは違う。上手いアームは、最初から正確に掴んで、正確に置く。学ぶアームは、最初は外すかもしれないが、外したことに気づいて、次は外さないように自分で直す。目指すのは後者だ。極端に言えば、下手でも学ぶアームのほうが、上手いが学ばないアームより、このシリーズの価値観では上にくる。

濃くしても、そこには届かない

定義が定まったところで、最初の問いに戻れる。FKテーブルを濃くすると、この「意思」に近づくのか。

近づかない。理由は、テーブルが担っているものにある。FKテーブルが担っているのは「この座標に行きたい→どの関節角にすればいいか」の逆引きだけだ。つまり「行き先の点」を返す表。範囲を広げれば行ける場所が増え、密度を上げれば終点の精度が上がる。テーブルが返すのは終点(ゴールの姿勢)であって、そこへどう動いていくか、ましてや失敗したらどうするかは、一切持っていない。

範囲を広げれば届く場所が増える。密度を上げれば終点の精度が上がる。どちらも「失敗しにくくする」方向の改善であって、「失敗した後に立て直す」能力ではない。精度が上がること自体は良いことだが、それは「正確に動く」であって「意思があるように動く」ではない。そして皮肉なことに、テーブルを濃くして失敗を減らすほど、立て直しを学ぶ機会は減る。失敗しなければ、失敗から学べない。精度を上げることと、失敗から学ぶことは、別の軸にある。

これは、このプロジェクトでずっと言ってきた設計哲学とも符合する。精度より体験の成立を優先する。精度はあとからお金で解決できる。テーブルを濃くするのは精度側への投資で、いま欲しい体験側の投資ではない。

濃くしたい理由によっても、答えは変わる。対話の中で、その場合分けもした。もし「次にまた別の白箱位置で穴に当たるのが嫌だから、先回りして全域を濃くしておきたい」なら――それはこのプロジェクトのセンシング方針(具体的な失敗に当たってから対処し、先回りで作り込まない)と逆向きだ。全域を均一に濃くするのは時間が重いわりに、使わない領域まで埋めることになる。約2日かけて、使うか分からないデータを作ることになりかねない。もし「特定の作業領域だけ最近傍の精度を上げたい」なら、その領域に絞って差分で足すのが効率的で、時間も読める。もし「最近傍距離が大きいのを縮めたい」なら、そもそも今の精度で実機が通るかを確かめてからの話で、足りているなら濃くする必要はない。

どの理由であっても、結論は「今は濃くするタイミングではない」だった。検算上は最近傍が十分に近い値で出ていて、それで実機が通るなら密度は足りている。通らない地点が出て初めて、その領域を差分で足せばいい。先に全域を濃くするのは、使わないかもしれないデータに二日かける賭けになる。

そして何より――どれだけ濃くしても、それは精度の話で、意思の話ではない。問いの出発点だった「濃くすれば意思に近づくか」への答えは、はっきり「近づかない」だった。

「失敗から学んで達成する」を分解すると、必要なのは四つになる。

1. 失敗を検知する――掴めたか/置けたかを、自分で判定できる。これは以前から構想にある「VLM-as-Reward」(実行→iPhoneで撮影→画像モデルで成否判定)がまさにこれにあたる。「失敗した」と気づく目

2. なぜ失敗したか推定する――掴めなかったのは浅かったからか、ズレていたからか、落としたからか。原因の仮説を立てる

3. 次の一手を立て直す――原因に応じて「もう少し低く」「右に5mm」「掴み直す」と、次の試行のパラメータや手順を変える

4. それを実行して、また1に戻る――達成するまでループする

今の構成のどこに何があるかを並べると、こうなる。

FKテーブルは、この四つのうちどれも担っていない。「3で右に5mmと決まった後、その座標の関節角を引く」道具にすぎない。意思の本体は、検知・推定・立て直しのループの側にある。テーブルは、その下で姿勢を引く実行層として、もう十分に働いている。だから投資先はテーブルの拡充ではない。

ループは、もう回っている

ではゼロから自律ループを作るのか。そうではなかった。

このループは、今は自分が補助する形でやっている。例えば白箱にブロックが入ったのを y/n で判定する。FKテーブルに穴があったと分かったら、Unityで追加のデジタルツイン学習をする。アームの動きや精度向上のためのループ経路自体はすでにあって、ただAIとロボットだけでは回らないので、自分が補助しながら進めている。これをもっと推し進めるためのアイデアや実装が欲しい。

ここが、この日いちばん大きな整理だった。失敗から立て直すループは、もう存在している。試行があり、成否を見て、原因を切り分け、手を打ち、また試す。ただしその輪の何箇所かを、人間が肩代わりして回している。ゼロから作る話ではなく、既にあるループから人間の肩代わりを移していく話だ。

今、肩代わりしている判断を棚卸しすると、難易度の違う三層に分かれる。

• A. 試行ごとの即時判定(速いループ・毎回起きる)――白箱にブロックが入ったか y/n、掴めたか落としたか、ABORTしたか到達したか

• B. 原因の切り分け(中速ループ・失敗時に起きる)――入らなかったのは落下点がズレたからか掴み位置がズレたからか、ABORTしたのはテーブルの穴か関節制限か

• C. 構造的な手当て(遅いループ・たまに起きる)――穴があると分かったらUnityで追加スキャン、補正値を変える

この三つは、機械に移せる難易度がまるで違う。Aは移しやすい。Cは(Unityのエディタ操作が要るので)当面は人が要る。だから「全部いっぺんに」ではなく、Aから外して、B、Cへと外側に広げるのが順序として正しい――と、最初は組み立てた。

Aが移しやすいのは、判定が毎試行起きて、しかも答えが単純(入った/入らない、掴めた/落とした)だからだ。撮って見れば分かる種類の判断で、人がやっていることと機械にやらせることのギャップが小さい。10回試せば10回の手入力が消える。費用対効果がいちばん高い。

Bは中間だ。「右下に60mmズレた」という観測を、確定済みの寸法(箱の大きさ、到達公差)と突き合わせれば、補正で詰められるズレか、掴み位置そのものの問題かを、ある程度は機械で切り分けられる。ただし観測の質に依存する。

Cがいちばん遠い。テーブルの穴を埋めるにはUnityのエディタを操作して再スキャンする必要があり、これは当面、人の手が要る。ただし「ABORTが続く、これは穴の兆候だ」と気づいて報告するところまでは機械に寄せられる。検知は機械、実行は人、という分担にできる。

具体案も出した。ステップ1として、PLACEのrelease直後に上カメラで1枚撮り、「白箱の中にブロックが入っているか、入っていないなら中心からどちらにどれだけズレているか」を画像モデルに聞いて、返ってきた判定をログに自動で書く。これで目視のy/n入力が消える。ステップ2で、その「右下に60mmズレた」を確定済みの箱寸法と突き合わせて、補正で詰められるズレか掴み位置の問題かを切り分ける。ステップ3で、ABORTが続いたとき周辺のテーブル密度を自動チェックして「穴の兆候あり、追加スキャン候補」と報告させる。こうやって人間の関与を一段ずつ減らしていく――そういう絵を描いた。

だが、これも半分ずれていた。

急ぐな、と止められた

「失敗検知を最初に機械へ移す」という具体案を出したあと、こちらはそのまま実装の話へ進もうとした。release後に撮って画像モデルに成否を聞く、その返り値をどうログに書く、既存のどのスクリプトのどこに挟む――手段の設計に入りかけた。だが、ここでも止められた。

成否の自動判定を最小で実装する、には賛同する。ただ、進め方がこれで良いかはまだはっきり分からない。結論を急がなくていい。プロジェクト全体の話からしておく。

そして、もっと上の層の整理が共有された。今やっているのは「デジタルツイン学習」の動的追従シリーズ――カメラで追従しながらPICK/PLACEを行えるかを追ってきた一連――で、それが一区切り見えてきた。プロジェクトを進めるために次のテーマ設定が必要で、そのテーマが「失敗から立て直すループを自律的に行うロボットアーム設計」になる。現状を整理し、問題点を認識し、新しいアイデアや設計をもとにアームの動きやシステムそのものを設計する。精度や滑らかさを上げることではなく、ループ設計の筋の良さが大事。極論、動きがめちゃくちゃでも、ループが存在してアームが失敗から学んでいく設計が作れることを目指す。ここでも精度より体験が先。今のシステムの骨子は残しつつ新しい設計を考えてよく、ハードの追加は基本的にない。

ここで、自分が二度目に先走っていたことに気づいた。一度目は「意思」を見た目だと決めつけて、二度目は実装の手段(撮って判定する仕組み)に飛びついて。テーマがまだ言葉になっていない段階で、手を動かす話に行こうとしていた。テーマ設定を飛ばして実装に入るのは、地図を引く前に歩き出すようなものだ。まずは新シリーズの骨格――何を「ループ」と呼び、何をもって「筋が良い」とし、何を残して何を変えるか――を言葉にするのが先だった。

この「急ぐな」は、この日の対話で三度目の引き戻しだった。意思の定義で引き戻され、目的の定義で引き戻され、進め方でも引き戻された。三度とも、こちらが先に構図や手段を決め打ちして、それを現実に当てにいこうとして外した。共通しているのは、まだ固まっていないものを固まったことにして前に進もうとする癖だ。早く形にしたい、という力が働くと、定義が曖昧なまま手段に飛ぶ。構想の段階では、それをやらない。決め打ちせず、輪郭だけを引く。固めるのは、手を動かしてからでいい。

減らすことが、目的ではない

人の関与を減らす方向で進めよう、と組み立てたところで、止められた。

「試行→成否判定→原因推定→次手の決定→再試行」、これを完全自律にする必要はない。システム全体の中で人が介在するのは当面避けられないので、人の関与が減る＝良いループ、ではない。あくまでも、ロボットアームが電源が入って動いている間は、アームの動きが失敗を学んで良くなっていく、を目指すでいい。

——なるほど。介入の有無は指標ではない。 僕はまた一つ外していた。「人間を一つずつ抜く」を軸に据えたが、抜くこと自体は目的ではなかった。人が介在するのは当面の前提で、減らすことがゴールではない。

軸は「電源が入って動いている間、アームが失敗を学んで良くなっていく」ことだ。極端に言えば、人がそばで補助し続けていても、アームが試行のたびに前より良くなっていくなら、それは目指すものに近い。逆に、全自律でも同じ失敗を繰り返すだけなら、近くない。

これで評価の軸が定まった。動的追従シリーズでは、追従しながら掴めたか・置けたか、そのときの最近傍距離が何mmか、といった「できたか/どれだけ正確か」が指標だった。新しいシリーズの指標は、できたかどうかでも精度でもない。「同じ失敗を繰り返さないか」「試行を重ねるごとに良くなるか」だ。介入回数ではない。アーム自身の改善だ。

ここまでで、作りたいものの輪郭は引けた。失敗から立て直すループを、アーム自身が回していく。精度ではなく改善を指標にする。人の補助は前提でいい。実行層は残し、判断層をその上に乗せていく。ここまでが、この日の前半だった。だが、輪郭が引けたところで、別の引っかかりが出てきた。それを回すのに、今のハードでいいのか、という問いだ。

それは、今のアームでやることなのか

ここまでは、何を作るかの話だった。ここからは、それをどのハードで作るかの話になる。

新シリーズの骨格を「今のシステムの骨子は残す、ハードは足さない」で組んだ。mechArmのまま、その上に判断層を乗せていく、と。だが、組んだそばから自分で疑った。失敗から学ぶループの主役は、失敗の量と、失敗をデータとして残せる仕組みだ。そこを軸にすると、今の構成にいくつか足りないものが見えてくる。

ひとつは、失敗を記録する目がないこと。mechArmには手首のカメラがない。上から見る固定カメラはあるが、掴む瞬間に爪先と対象がどう触れたか――浅かったのか、ズレたのか、滑ったのか――を見るには、手首から見た映像が要る。失敗の原因を推定するには、失敗の瞬間が映っている必要がある。

もうひとつは、失敗を量産する入口がないこと。今のmechArmは、teachして、replayして、評価する。人がドラッグして教えた軌道を再生する。これは綺麗な一本の正解をなぞる仕組みで、失敗を大量に生む仕組みではない。失敗から学ぶには、まず失敗が要る。たくさん要る。それを人が手早く入れられる手段――テレオペレーション、人がコントローラやVRで直接アームを操って、成功も失敗も含めてデータを残す入口――が、今は無い。

ここで、手首カメラを付けるという案が具体的に動き出した。そして調べていくうちに、話が「カメラを一個足す」では収まらなくなっていった。

120万円のロボットを、買おうとして、やめた

手首カメラとテレオペでデータを残す、という方向で調べていたら、ちょうどその思想を最初から形にした双腕ロボットが目に入った。Almond Roboticsの「Axol」。Physical AI／Embodied AI向けに設計されたオープンソースのデュアルアームで、LeRobot系のデータ収集とVRテレオペレーションを強く意識した製品だった。

スペックを並べるとこうなる。

調べるほど、今やっていることの延長線上にあるロボットだった。データ収集、模倣学習、Physical AI、VLA/VLMロボット、実世界タスク実験――最初からそこを狙ったプラットフォーム。今このプロジェクトでやっているteach & replay、LeRobot形式のデータ収集、VLMによる評価、実機検証は、まさにその手前にある。

mechArmと並べると、差は歴然だった。

特に効いたのは制御周期だ。前シリーズの実機ログで、単発のsend_anglesが無視される、fresh_modeの扱い、ストリーミング送信のキュー処理――低レベル制御の更新頻度とキューの問題に、ずっと手を焼いてきた。Axolは最初からCAN制御・500Hzループ・連続ストリーミングを前提に設計されているので、そういう「単発コマンドが飲まれる」問題はかなり起きにくい構造になっている、と読めた。痛いところを最初から潰してある。

正直に言えば、買おうかと思った。今のプロジェクトの進み方を「Teach→JSON保存→Replay→評価」だとすると、Axolが目指しているのは「Teleop→Dataset→Policy Learning→Autonomous Replay→評価」で、その次の段階の「学習ループ」まで含めたプラットフォームだ。120万円で、半年ぶんの回り道を買えるかもしれない、と。

それでも、やめた。

理由は、このプロジェクトのコアメッセージにある。iPhoneと安価なアームだけで、個人がロボットの動きを作れることを証明する。エンジニア以外の人でも使える入り口を作る。120万円の完成されたプラットフォームを買って動かすのは、その証明の逆を行く。「お金で解決した」になる。それは精度をお金で解決するのと同じで、このプロジェクトが先に置いているもの――体験の成立、誰でも始められる入口――ではない。

それに、調べる中で見えたのは、今ぶつかっているボトルネックが実はハードではない、ということだった。「データ収集基盤が足りない」のではなく、「データ収集基盤を今まさに作っている途中」だった。teach→939姿勢保存→フェーズ抽出→replay→評価までは、もう動いている。普通のロボット趣味勢はここまで来ていない。足りないのは120万円のアームではなく、手首から見る目と、失敗を量産して残す入口と、それを溜める場所だった。

Axolを買わない、と決めたとき、問いが反転した。「次に買うべき高価なロボットは何か」ではなく、「安価なまま、失敗から学ぶループを回すには、何を選べばいいか」へ。その答えが、SO-101だった。

なぜ、SO-101なのか

SO-101は、Hugging FaceのLeRobotエコシステムに乗る、オープンソースの安価なロボットアームだ。FEETECHのサーボを使い、組み立て式で、テレオペレーションと模倣学習を最初から想定している。価格はAxolの二桁下、数万円の世界。mechArmと同じ「安価なアーム」の側にいながら、Axolが標準で持っていたもの――テレオペでデータを入れる入口、LeRobot形式での記録、手首カメラ前提の設計――を、エコシステムごと持っている。

三つのハードを並べると、立ち位置がはっきりする。

mechArmは、最初の一台として「iPhoneとUnityで実機が動く」を証明してくれた。その役割は終わっていない。だが、失敗から学ぶループ――テレオペで失敗を量産し、手首カメラで失敗の瞬間を記録し、LeRobot形式で溜める――を回す入口としては、自作で全部を埋めるより、それを最初から持っているSO-101に乗るほうが筋がいい。同じ安価な側にいるのだから、民主化の旗は下ろさない。むしろ「$130級でも動く」は、その旗をさらに前に進める。

手首カメラを付けるなら、SO-101で始める。これが、この日の到達点だった。手首カメラはmechArmにも付けられる。Arducamの小型USBカメラをグリッパー下面に3Dプリントブラケットで載せる、という具体案まで前に出していた。だが、手首カメラを付けてテレオペで失敗データを残し、それをLeRobot形式に変換して学習に回す――という流れ全体を見ると、その流れを最初から想定して作られたSO-101で組むほうが、自作の継ぎ接ぎより遠くまで行ける。カメラ一個の話が、ハードを選び直す話になった。

単腕から、双腕へ

ではいきなり双腕のSO-101を二本買って組むのか。そうではない。ここでも、急がない。前半でさんざん学んだことだ。

進め方は段階的にする。まず単腕のSO-101から始める。一本で、手首カメラのテストをする。グリッパー下面〜前方中央にカメラを載せ、掴む瞬間に対象と爪先がどう映るかを確認する。視野、映り込み、ケーブルの取り回し。ここはmechArmで手首カメラを検討したときに調べたことがそのまま効く。指の間や指先に付けると開閉で視野が変わり把持対象を隠すので、本体の前方に少しオフセットして、指の中央を20〜30度の下向きで見る配置がいい。この検証を、まず単腕でやる。

次に、テレオペレーションの性能を確認する。人がSO-101を操作して、成功も失敗も含めた軌道を入れられるか。操作の遅延、追従、思った位置に持っていけるか。テレオペがちゃんと回って、人が失敗データを手早く量産できる状態になって初めて、「失敗から学ぶループ」の入口が開く。ここが回らなければ、双腕に進んでも意味がない。

テレオペ性能が確認できたら、双腕にしていく。二本目を足し、二本のアームが協調する構成へ広げる。片手で押さえて片手で操作する、受け渡す、両手でないとできないタスクに踏み込む。双腕は、単腕で入口（カメラ・テレオペ）が固まってからの拡張であって、最初の一歩ではない。

この段階を踏む理由は、前半の三度の引き戻しと同じだ。構図を先に固めて現実を合わせにいくと外す。双腕という完成形を先に置いて、そこへ一足飛びに行こうとすると、単腕で潰せたはずの問題を双腕の複雑さの中で潰すことになる。単腕で手首カメラとテレオペという土台を固め、それが回ることを確認してから、双腕という複雑さを足す。順序として、これが正しい。

失敗を、公開しながら進む

そして、この移行そのものが、シリーズの主題と重なる。

新しいハードに移ると、失敗が大量に出る。SO-101の組み立てでつまずく。サーボの設定で詰まる。手首カメラのブラケットが合わない。テレオペの遅延に悩む。LeRobot形式への変換でエラーが出る。単腕では動いたものが双腕で噛み合わない。mechArmで二年積み上げた勘が、別のアームでは通じない場面が必ず出てくる。

その失敗を、隠さずに公開しながら進める。サイトに書き、YouTubeに上げる。うまくいった瞬間だけでなく、つまずいた過程、買おうとしてやめた判断、選び直した理由、組み立てで何度も失敗したところ。それらを記録として残す。

ここで「失敗から学ぶ」が二重になる。ひとつは、アーム自身が失敗から学ぶループ――このシリーズが設計しようとしている本体。もうひとつは、新しいハードへ移る過程で、作っている側の人間が失敗から学ぶ過程――それを公開する営み。シリーズ名「失敗から学ぶアームを作る」は、その両方だ。アームの自律ループを設計しながら、自分自身も新しいハードで泥臭く失敗する。そのプロセスを全部、外に見せる。

次は、何を作ろうとしているのか

そういうわけで、シリーズが変わる。ハードも変わる。

最初は、mechArmのまま失敗から学ぶループを作ろうとしていた。ハードは足さない、実行層は残す、その上に判断層を乗せる――そう組んだ。だが組んでみて、それだけではシリーズとして弱いと感じた。失敗から学ぶループの主役は、失敗を量産する入口と、失敗を記録する目だ。それがmechArmには無い。自作で埋めることもできるが、手首カメラとテレオペとLeRobot形式の記録を最初から持っているアームが、安価な側に存在する。それがSO-101だった。

だから、ここで一気にハードを選び直す。mechArmは最初の証明を果たした一台として残しつつ、失敗から学ぶループは、SO-101で組む。単腕から始めて、手首カメラのテストをして、テレオペ性能を確認できたら、双腕に育てていく。その過程で出る大量の失敗を、サイトとYouTubeで公開しながら進む。

新シリーズの輪郭を、この日の対話から拾えるだけ拾って言葉にしておく。

何を「ループ」と呼ぶか。試行→成否判定→原因推定→次手決定→再試行、の輪。今はこの輪が、機械(両端の実行)と人間(真ん中の判定・原因・次手)で分担されて回っている。このループの真ん中を、少しずつ機械に寄せていく――ただし「寄せること」自体が目的ではない。

何をもって「筋が良い」とするか。これが新シリーズの主指標になる。精度ではない。「アームが稼働の中で、失敗を糧にして良くなっていくか」だ。同じ失敗を二度繰り返すなら、たとえ全自律でも悪いループ。試行のたびに良くなるなら、人が補助していても良いループ。

何を残し、何を変えるか。残すのは、このプロジェクトの思想――精度より体験、安価なまま民主化を証明する、失敗を隠さず公開する。変えるのは、ハードだ。mechArmからSO-101へ。単腕から双腕へ。実行層を自作で積み上げる方針から、LeRobotエコシステムに乗る方針へ。前シリーズで積んだ知見――手首カメラの配置、テレオペでデータを残す発想、失敗を記録に残す習慣――は、別のアームの上でちゃんと効いてくる。だから一区切りであって、断絶ではない。

このシリーズが始まる地点を、もう一度確認しておく。出発は「FKテーブルを濃くすると何が手に入るか」という、前シリーズの延長線上の技術的な問いだった。その問いに答えていく途中で、濃くしても手に入るのは精度だけで、欲しいのはそれではない、と分かった。欲しいのは、失敗から立て直す力だった。そして、その力を回すには、今のアームでは足りないと分かった。買おうとした120万円のロボットは、思想に反するからやめた。残ったのは、安価なまま失敗から学べる入口――SO-101だった。問いが、答えの途中で別の問いに変わり、最後にはハードまで変えた。それが、シリーズが変わるということなのだと思う。

実装はまだ何もない。SO-101も、まだ手元にない。この回は、何を作ろうとしているのか、それをどのハードで作るのかを言葉にするための記録だ。

それでも、最初に手をつける順番だけは見えている。

1. 単腕のSO-101を組み立てる

2. 手首カメラを付けて、掴む瞬間の視野を確認する

3. テレオペレーションの操作感を評価する

この三つから始める。双腕も、自律ループも、その先だ。一気に作ろうとして外す癖は、この回でさんざん見た。まず単腕で土台を固める。輪郭は引けた。あとは、失敗しながら、形にしていく。

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