mechArm 270 Pi 受け渡し動作の成立を探る Log#1 | 今まではピック&プレースの成功判定は座標にあったが、次の判定基準は人の中にある
新しいシリーズを始める。名前は「受け渡し動作の成立を探る」。ロボットアームが人に物を渡し、人から物を受け取る。それだけのことを、成立するまで記録する。
この回にコードは出てこない。実機も動かさない。前のシリーズが終わりに近づいたところで行き詰まり、その行き詰まりを対話で解きほぐし、次に進む方向が決まるまでの過程だけを扱う。実装のない構想回なので、コードの代わりに対話そのものをログ本体として全量で残す。外した議論も、途中で訂正された過程も消さない。考えが動いた記録がこの回の中身になる。
動的追従で骨格は立ったが、業務の問いだけ残った
「動的追従の限界を探る」は、カメラで対象を追いながらピック&プレースができるかを追い続けた一連だった。視覚サーボでブロックを掴み、箱に置く。FKテーブルを引いて姿勢を決め、補正記憶で狙いを更新し、VLMで成否を判定する。Log#56 まで積んで、そこまでは動くようになった。
技術的な骨格は立った。しかし、ずっと解けない問いが残っていた。
このアームで、現実にどんな業務が頼めるんだろう。
デモとしては成立する。だが「そのタスクで業務を頼むのかな」と考えると、答えが出ない。速度も精度も耐久性も、産業用アームに全部負ける。負けると分かっている土俵で「有効なタスク」を探し続けていた。
産業用アームの土俵で業務を探しても答えが出ない
この状態を、対話の中では次のように話した。
いまだに有効なタスクが思いつきません（デモとしてはいいけど、現実問題そんなタスクで業務を頼むのかな？になってしまう）
返ってきた指摘は、前提そのものを疑うものだった。
— このアームで「業務として頼まれるタスク」は存在しません。ここで現実の業務を探し続けるのは、形を変えた穴埋めです。
— その問いが出てくること自体が、タスクを成果物だと思っている証拠です。タスクは成果物ではなく、動きの質を測るための測定器です。測定器に業務価値を求める必要はない。
ここが転換点だった。問いが悪かったのであって、アームが悪かったのではない。産業用アームと同じ軸（重量・速度・精度・耐久）で比べれば必ず負ける。だが、その軸の上でタスクを探していた限り、出てくる答えは永久に「デモとしてはいいけど」で止まる。
続けて、良いタスクの条件が3つ提示された。
人が見ている。観測者がいない動きに体験は存在しない
失敗が可視である。精度が出ない前提でどう体験を成立させるかが主題なので、失敗が見えないタスクでは思想が検証できない
人とロボットの間で何かが受け渡される。ここで初めて動きが意図の伝達になる
そして具体案として出たのが「手渡し」だった。
位置精度が要らないタスクとして手渡しが出てきた
— pick-and-place をやめて、人にものを渡す／人から受け取るに変える。人間同士なら無意識にやっている——相手を見る、手を差し出す、相手が掴んだのを確認して離す、掴まなければ待つ。この一連が全部「動きによる会話」です。
このタスクには、卓上アームにとって都合のいい性質が並んでいる。
性質 | 意味 |
|---|---|
位置精度がほぼ要らない | 人間が手を合わせてくれる。精度を競う必要が消える |
タイミング・予告性・譲る動きが問われる | 動きの品質がそのまま評価軸になる |
失敗が誰の目にも即座に分かる | 渡らない・早く離す・待ちすぎるは全部見える |
未解決の研究課題である | デモの遊びではない |
赤ブロック追従の資産はそのまま使える、追う対象がブロックから人の手になるだけ——と、この時点では言われた。この発言は後で訂正されることになる。
資産は捨てない。手渡しは PLACE の置き換えになる
対話の中で、提案側から自己訂正が入った。ここを消さずに残す。
— 一つ訂正させてください。「赤ブロック追従の資産はそのまま使える。追う対象が手になるだけ」と書いたのは雑でした。あと「pick-and-place をやめて」も言い過ぎです。自分で「止まっているものを止めたまま次に行くな」と書いておきながら、次に乗り換えを勧めていました。
— 正しくは、手渡しは PLACE の置き換えです。PICK → 保持 → HOME までは今の本線そのまま。最後の「離す」だけが変わる。土台は捨てない。
そして、本当の難所が名指しされた。
— 「離すタイミング」に、現在、測定手段がありません。人が掴んだかを知る手段が VLM しかない。API往復は秒オーダーで、離す判断のループには遅すぎる。グリッパーは push-hold で、力・電流のフィードバックを読めていない。つまり「掴まれたのを確認して離す」は、いま測れない。
測定してから推論する、という原則に従うなら、ここを飛ばして設計してはいけない。逆に言えば、手渡しの本質は最初から丸ごと測定問題だった。タスク選びの問題ではなかった。
測れる形に落とすと、こうなる。
固定の提示姿勢へ差し出して静止する。姿勢が1つで済むので FK テーブルの穴に当たらない
上カメラで手がフレームに入ったことだけ見る
N秒後に開く。掴まれていなければ落ちる
離す判断を人に委ねず、時間で決め打ちして落とす。落ちた回数が、そのまま「N が適切だったか」の測定値になる。ここから初めて、閉ループにする価値があるかを判断できる。
成功を判定するのが座標から人へ移る
対話は「これができるようになると何が変わるのか」に進んだ。
— 変わるのは、根本的には「ロボットが正しいかどうかを、誰が判定するか」です。
— ピック&プレースでは正解が空間座標にあります。箱の中心±何mm、成功か失敗かは幾何で決まる。人間は仕様を書いた後、実行の場からいなくなる。だから従来の産業ロボットはケージに入れられ、人を排除することで成立してきた。
— 手渡しでは正解が相手の内部に移ります。同じ軌道・同じ精度で差し出しても、相手が「受け取りやすかった」と感じれば成功、身構えたら失敗。成功条件が座標からもう測れない。
具体的に変わることが3つ挙げられた。
時間の主導権が共有される。ピック&プレースはロボットが自分のペースで動けばいいが、手渡しは相手の準備・ためらい・タイミングに動きを合わせる必要がある。SPEED 固定という発想自体が成立しなくなる
動きが通信路になる。差し出す速度や停止の仕方が「今から渡します」「まだ待ちます」という信号として読まれる。動きの品質が飾りではなく機能になる
失敗の意味が変わる。落としたブロックは拾えばいいが、人の目の前で不意に離せば信頼を失う。失敗コストが物損から関係の損傷に変わる
冷静な補足も入った。
— 「協働」という言葉は業界で安売りされています。協働ロボットは10年前からあるが、その中身の大半は「ケージなしで隣に置けるピック&プレース」で、人と動きを交わしてはいない。安全に共存することと、協働することは別物です。
手渡し研究の最前線は世界に数グループしかない
企業として手渡しを製品化しているところは見当たらない。主戦場は企業研究所と大学のベンチマークだった。
HandoverSim（NVIDIA Seattle Robotics Lab）は、人からロボットへの受け渡しをシミュレーションで評価するベンチマーク。卓上に7自由度アーム、グリッパー、手首RGB-Dカメラ、シミュレートされた人の手。人が物を掴んで差し出し、ロボットが衝突なく受け取って指定位置まで運べば成功。人間のモデル化には DexYCB の人・物インタラクション軌跡を再生している。構成が卓上アーム＋カメラで、こちらの設定に最も近い。
R2HandoverSim（2026）は、ロボットから人へ渡す側の最新ベンチマーク。この分野は手法が急速に進歩している一方、標準的な評価プロトコルがないため客観的な比較ができない、という問題意識で作られた。重要なのは結論のほうで、成功率単体よりも、計画実行可能性・到達性・把持安定性・把持アフォーダンス・安全性という5つの補完的な指標のほうが、人が感じる手渡しの質をよく反映すると、30人の被験者による検証で示している。
DexH2R（ICCV 2025）は、UR10e と ShadowHand による初の実機データセット。人間らしい動きを担保するためにテレオペでデータを収集している。
Cakmak et al.（2011） は、人がロボットからの手渡しでどの提示姿勢を好むかを調べた研究。15年前の論文だが、向きを揃えて物を渡すという問題の直接の先行研究にあたる。
調べていく途中で、R2HandoverSim の著者本人の投稿に行き当たった。IROS 2026 に2本が採択されたという報告で、片方が R2HandoverSim、もう片方が言語と視覚の手がかりから人の意図を推測して提示方法を選ぶ研究。600件の実世界での試験を通じて検証されたと書かれていた。
つまり、この領域の最前線は世界に数グループしかない。「調べても同じ論文しか出てこない」のは、調査が足りないのではなく、そもそも人が少ないということだった。
10倍難しい問題の、向こうが解けない1割を取る
不安をそのまま口に出した。
これってピック＆プレースの10倍難しくない？ おれに出来るのかな？
— 彼らがやっていることは10倍難しい。でもやることは、それではありません。
— あの研究が難しいのは、意図推定・把持予測・衝突回避を全部リアルタイムで解こうとしているからです。ハンマーをどう使いたいかを推測し、人がどこを掴むかを予測し、最適な提示姿勢を計算する。フルスタックの研究で、確かに10倍あります。
— でも最初の一歩は、固定の提示姿勢へ差し出して静止する、手がフレームに入ったのを見る、N秒後に開く。これは技術的には、今の PLACE より簡単です。箱の中心±数mmを狙う Z-servo も、FKテーブルの穴も、補正記憶の収束もない。姿勢は1つ、判断は手が見えたかだけ、離すのはタイマー。
— ピック&プレースの難しさは制御の中にありました。だから Log#56 まで積むことになった。手渡しの難しさは評価の中にあります。渡しやすかったかをどう測るか、どのNが心地よいか、差し出す速度で体感がどう変わるか。
— 600件の実世界試験をやったチームにも、できないことがあります。毎日、同じ人間が、体感を記録し続けること。ユーザースタディは30人×1回で終わる。こちらは1人×毎日できる。n=1 の縦断記録は学術には出せない形式です。
10倍難しい問題の、向こうが解けない1割を取る。それが位置取りだと言われた。
協働と受け渡しは研究の階層が違う
ここからシリーズ名を決める議論に入った。この過程自体が、研究テーマの輪郭を削り出す作業になった。
最初に出した案は「手渡しの設計」「離す瞬間の研究」「精度の外側」など。どれも刺さらなかった。
なんか全然伝わらないね。
そこで階層の整理に入った。
今回の研究の本質って、「物を運ぶこと」ではなくて「人と一緒に作業すること」なんですよね。だから「受け渡し」は手段であって、テーマは人との協働だと思います。
一度はこれで「人との協働動作を探る」に傾いた。だが次にこう考え直した。
「手渡し」だと、ロボット→人の一方向しか含まれません。今回やろうとしているのは、人→ロボット（受け取る）とロボット→人（渡す）の双方向です。つまり研究対象は物の受け渡しなんですよね。
この揺れに対して、指摘が入った。
— 一つ前で「受け渡しは手段、テーマは協働」と言っていたのが、今回は「研究対象は受け渡し」に戻っています。どちらも正しいですが、シリーズ名はどちらの階層に付けるかの判断が先です。
そこで定義を確認した。
— 受け渡し動作：物が人とロボットの間を移動する動作。物の移転が目的で、始まりと終わりが明確な一回の出来事。
— 協働動作：人とロボットが一つの目的を共有して動く動作すべて。受け渡しはその一部で、他に「待つ」「譲る」「順番に作業する」「相手に合わせて速度を変える」などを含む。物が移動しなくても成立する。
— 関係は包含です。協働動作 ⊃ 受け渡し動作。受け渡しは「物」を軸にした定義、協働は「関係」を軸にした定義です。
案としては「受け渡し動作の限界を探る」も出た。前作「動的追従の限界を探る」と完全に対になるので、シリーズ感は最も強くなる。だがこれには反対が入った。
— 前作の「限界」は誠実な言葉でした。動的追従がどこで壊れるかを実測しに行き、実際に限界に当たり続けた56本だった。しかし新シリーズは逆で、成立するかどうかをゼロから見に行く話です。まだ一度も成立していないものの「限界」は探れません。対句の美しさのために中身とズレた言葉を選ぶのは、誇張を禁じてきた文体ルールの精神に反します。
「ハンドオーバー」というカタカナ語を使う案にも反対が入った。日本語で「ハンドオーバー」が定着しているのは通信工学の基地局切り替えであること、「動的追従」が機能したのは日常語でありながら技術用語だったからで、カタカナ語への置き換えは同じ効果を生まないこと、研究圏への接続は英語発信で Handover と書けば済むこと。
最終候補は2つに絞られた。
A. mechArm 270 Pi 受け渡し動作の成立を探る
B. mechArm 270 Pi 人との協働動作を探る
ここで争点になったのが「50〜60本に耐えるか」だった。
シリーズは#50から60くらいは耐えられるシリーズである必要があります。受け渡し動作シリーズではそれには耐えられないように思いますがどうですか？
— 耐えられます。根拠は前作の実績です。「動的追従の限界を探る」は、カメラで追従してピック&プレースできるかという、文にすれば一行のタスクで56本の記事が出ました。PLACE の Z-servo 残差だけで何本書きましたか。記事の本数はタスクの大きさではなく、測定の解像度で決まる。
— 逆に「協働動作を探る」の方が50本に耐えられません。協働はテーマであってタスクではないからです。「動的追従」が56本持ったのは、成功と失敗が毎回測定できる具体的タスクだったから。大きな名前は記事を生みません。測れる問いが記事を生みます。
分解して数えると、渡す側だけでこれだけある。
提示姿勢の設計（高さ・向き・手首の角度で体感がどう変わるか）
差し出す速度と減速カーブ
静止してから開くまでの N の探索
手の検出、上カメラと横カメラの役割再設計
「掴まれた」をどう測るか（視覚か、時間か、将来は電流か）
早すぎた離しで落とした失敗の記録と分類
向きを揃えて渡す
受け取る側で同じ問題系がもう一周する。しかも受け取りのほうが難しく、先行研究も薄い。さらに台帳の状態語設計、VLM判定の適用、R2HandoverSim の指標との突き合わせ、人間同士の受け渡し観察、動きの比較実験の設計が乗る。
別のAIに投げても同じ結論とロードマップが返った
ここで別のAIに同じ問いを投げた。両案を対等に書き、忖度なしにどちらかへ軍配を上げるよう依頼した。返ってきた結論は A だった。理由も、こちらで出ていたものとほぼ同じだった。
加わった価値が1つある。ロードマップの明文化だ。
動的追従の限界を探る（完）
受け渡し動作の成立を探る（50〜60本）
人との協働動作を探る（次フェーズ）
シリーズ名の遷移そのものが研究の進化を語る、という見立て。B案は捨てるのではなく、3番目の席に予約されたことになる。
独立した2つのAIが同じ階層図に到達し、同じ結論を出した。判断材料としては収束したと見て、A に決めた。
A案の唯一の弱みとして両方が挙げた「待つ」「渡さない判断」を扱うときのズレは、実際には問題にならない。「受け渡しの成立を探る」なら、待つことも渡さないことも成立条件の探索に含まれる。「受け渡し動作を探る」だったら窮屈だったが、「成立」の一語が入っていることで器が一回り広い。
敵わない土俵ではなく、相手が存在しない土俵だった
ロボットアームをどのようにしていけばいいのか迷っていた。考えれば考えるほど既存の業務だと産業用ロボットアームの仕事に敵わないと考えていた。もしくは出来ることがあっても限定的と捉えていた。
この行き詰まりの正体は、産業用アームの土俵で勝てる業務を探すという問いの立て方そのものだった。速度・精度・耐久性、あの土俵の軸では産業用が勝つ。仮に卓上アームの性能が一段上がっても、この構図は変わらない。同じ軸の上で順位が少し動くだけで、答えは「デモとしてはいいけど」のままだった。
受け渡しで視界が開けたのは、性能の差を詰めたからではない。産業用アームが構造的に持っていない評価軸に移ったからだ。産業用の世界では「人が受け取りやすいか」がそもそも測定項目にない。ケージの中に人がいないのだから当然だ。あそこは敵わない土俵ではなく、相手が存在しない土俵だった。
そして、この転換は最初の設計と矛盾していない。掲げてきたのは「ロボット開発はエンジニアだけのものではない」という一行だった。動的追従の56本は、エンジニアの土俵（制御・精度）を個人でどこまで登れるかの証明で、必要な基礎工事だった。受け渡しは、そこで登った土台の上で、初めてデザイナーの土俵で勝負する話になる。
実機の一歩目は、差し出して静止して開くまで
フェーズ | シリーズ名 | 状態 |
|---|---|---|
1 | mechArm 270 Pi 動的追従の限界を探る | 完結へ |
2 | mechArm 270 Pi 受け渡し動作の成立を探る | Log#01・いまここ |
3 | 人との協働動作を探る | 予約席 |
実機の一歩目は、ここまでで十分だと決めた。
ブロックを掴んで HOME、前に差し出して静止、N秒後に開く、手で受ける。視覚による手の検出はまだ要らない。現行コードの流用でできる範囲から始める。体感として「ロボットから物を受け取る」を最初に経験することが、評価軸を作るための一次データになる。
人の指が爪の近くに入るタスクなので、グリッパー周りは物理リスクのある変更として外部レビューを挟む。それは次回以降の話になる。
測定してから推論する。受け渡しの本質が測定問題である以上、この原則は前シリーズよりさらに重く効いてくる。
