213,312点のデータより、人間の目1回。AIが3回スキャンを回しても気づけなかったこと

Unityデジタルツインのスキャンデータを拡張する日のはずだった。213,312点の統合テーブルに新しいPLACE領域のデータを加えるため、スキャンを3回回した。そして3回とも、AIだけでは気づけない問題で躓いた。最終的に救ったのは、Playモードでグリッパを手動で動かして白箱の上に運んだ、たった一度の人間の作業だった。

💡 Key Takeaway
スキャンデータは213,312点まで積み上がったが、その精度を上げる最後の1歩は人間の目と手だった。「BaseAnglesの姿勢が白箱に向いているか」「リーチが足りないのか、スキャン範囲が足りないのか」「Inspectorに表示された120°が本当に正しい値か」——AIは数値を扱えてもシーンを見られない。軍師（Claude）は3回判断を外し、エイイチの手動確認が3回とも真実を引き当てた。精度より体験の成立を優先するという哲学は、こういう人間の手作業を前提にしてこそ成立する。

PLACE領域のスキャン拡張

LOG155までで、Unity上のFKスキャンデータは 213,312点 まで積み上がっていた。

このテーブルは、Unityの20体並列ロボットアームが関節角度の組み合わせを総当たりで試し、それぞれのエンドエフェクタ（EE）位置を記録したものだ。実機で赤ブロックをカメラ検出した後、そのロボット座標に最も近いEE位置をこのテーブルから引いて、対応する関節角度を実機に送る。これが「lookup動的追従」の仕組みで、LOG154でPICK動作は実機実証済みだった。

今日やる予定だったのは、PLACE領域——つまり白箱が置かれる領域——のスキャン密度を上げることだった。Piは今日手元になかったが、Unityスキャンなら一人でできる。簡単な作業のはずだった。

1回目のスキャン：左右逆のデータが取れた

ClineにPlaceRightFKScanner.csを作らせた。仕様は単純：j0を-75〜-30の10値に固定し、j1〜j4を±20°/5°刻みでスキャン。PLACE用のee_yフィルタは0.050〜0.080m（白箱43mm + マージン22mm = 65mm中心）。

28分待って出来たCSVを確認した。

点数: 18,438
ee_x: +0.032 〜 +0.188（全部正）

問題：Unityの白箱は x = -0.2208。つまり負のx座標側にあるのに、スキャンは正側だけ。

原因は座標系の認識ミスだった。Unityのx軸で「右」と思っていた方向が、実機座標系に対応づけると「左」だった。j0=-75〜-30は白箱と逆側を向く姿勢だった。

ただし、シミュデータと実機データが揃っていないと他でデータを使う場合混乱のもとになるから修正はして揃えるよ。

エイイチのこの一言で、「Piの座標変換で辻褄を合わせる」という楽な逃げ道を塞いだ。データの正確性は、下流のAI連携を考えると最初から揃えるべきだ。

Clineに1行だけ変更させる：

変更前: J0Values = { -75f, ..., -30f };
変更後: J0Values = { +30f, ..., +75f };

2回目のスキャン：76mm届かない

また28分待った。CSV確認：

点数: 18,484
ee_x: -0.187 〜 -0.030（正しく負側になった）
白箱中心(-0.2208, 0.153)への最近傍: 76.2mm離れている
白箱周辺領域内の点数: 0点

符号は直った。しかし白箱まで 76mm離れている。

軍師（Claude）はここで誤判断した。「mechArm 270のリーチ限界かもしれない」と言った。最近傍点の関節値がオフセットの端っこを使っていたから、腕を伸ばしきっても届かないのだろうと推測した。

そしてエイイチに提案した選択肢：

1. 白箱をロボットに近づける

2. スキャン範囲を±30°に拡大して再試行

3. 76mm離れを許容してPLACEする

どれも根本原因を外していた。

エイイチの返答：

アームのリーチが270mmでも、グリッパーつけてるから実際はもっと遠い場所の物を掴めるよ。

その通りだった。グリッパ分を含めれば届くはずだった。「リーチ限界」ではなく、単にスキャンで試した姿勢のバリエーションが足りていないだけだった。

手動確認で問題が全部見えた

エイイチの提案：Playモードでスクリプトを全部無効にして、link1〜link6のX Drive > Targetに手動で値を入れる。

入力した結果、アームは白箱の手前にはいなかった。奥にいた。つまりj0=75°では白箱を通り越していた。

j0を徐々に下げる：75 → 70 → 65 → 60 → 55。j0=55でグリッパが白箱の真上に来た。

しかしもう一つ問題があった。グリッパが水平ではなかった。斜めに傾いていた。

link6のTargetを試行錯誤：120、0、-60、180、-90。

j5=0 でグリッパが水平・下向きになった。

Inspectorの「j5=120」は誤表示だった

ここに3つ目の落とし穴があった。

最初にグリッパが白箱の上に来た画像を撮ったとき、link6のInspectorに「Target: 120」と表示されていた。軍師（Claude）はこれを信じて、新しいBaseAnglesの第6成分を120°として採用しようとした。

しかし確認用スクリプトPlacePosePreview.csでj5=120を送って再現すると、グリッパがまったく違う向きになった。画像比較して初めて、あの時の「120」はVariationMotionPlayerか何かの残存影響で、本来のターゲット値ではなかったと気づいた。

手動で再探索してj5=0が正解だった。

AIは数値を扱う。しかしInspectorに表示された数値が本当にその関節の「意図された値」なのかは、シーンを見ないと判断できない。

確定したPLACE BaseAngles

j0 = 55.00°
j1 = 45.17°
j2 = 26.63°
j3 = 2.90°
j4 = -70.57°
j5 = 0.00°

この姿勢でPlacePosePreview.csを動かすと、グリッパが白箱のふちに水平に降りる。EE座標 (-0.137, 0.106, 0.099)。白箱中心まではまだ距離があるが、ここをスキャンの起点にして±25°で広げれば、白箱全体をカバーできる見込みだ。

3回目のスキャンは±25°/5°刻み（11値）で、総点数 10 × 11^4 = 146,410点、所要時間約61分。いま走らせているところだ。

claudeの誤判断を記録する

Claudeは3回間違えた。

• 1回目のスキャン仕様を渡したとき、座標系の整合性を自分から指摘しなかった。j0符号が左右逆になることを事前に検証すべきだった。

• 2回目の76mm離れを見たとき、「リーチ限界」という物理的な制約の話に流れた。実際はスキャン範囲の設計ミスだった。

• j5=120°をInspectorから読み取ったとき、その値が別スクリプトの干渉結果かもしれないと疑わなかった。

3回とも、手動で試して真実を引き当てた。

「グリッパー込みで届くよ」「Playボタン押したらアームが動くけどいいの？」「じゃあ0が正しいね」——どれもシーンを直接操作した人間にしか言えない発言だった。

データ生成の現実

今日の作業を振り返ると、スキャンを3回回した。

所要時間の合計は116分（約2時間）。捨てたデータは36,922点。

R2R2Rの論文が提示する「数百万点のsim2real転移」の裏側には、おそらくこういう試行錯誤の時間が大量に積み重なっている。論文は成功したパイプラインしか書かない。失敗した36,922点は誰の記録にも残らない。

だが、手作業でやると失敗した36,922点こそが学習材料だと実感する。「なぜ足りなかったのか」「何を人間が見るべきだったのか」——これらはプロジェクトを個人で組んでいるからこそ掘り下げられる。

213,312点のデータより、人間の目1回

統合テーブルは213,312点。今日追加されるPLACE領域のデータをマージすれば、さらに数万点増える。

しかし今日、この数字のどの部分も、エイイチが手動でlink1〜link6のTargetを入力した一連の作業がなければ、意味を持たなかった。AIは「データを増やす」ことはできる。「データが正しい起点から生成されているか」を判断するには、画面を見て手を動かす人間が要る。

「精度より体験の成立を優先する。精度はあとからお金で解決できる」という設計哲学は、こういう人間の手作業を含めてこそ成立する。お金で解決できるのは、正しい方向に向かって精度が上がっていくときだけだ。方向が間違っていれば、お金も時間も全部溶ける。

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