VLMにロボットの動作を作らせたい人へ。その出力を実機へ送る前に、試して直す工程を挟めます。
「ブロックをつかんで、ボウルへ入れる」。言葉では簡単です。しかし、つかむ位置が少しずれれば、その後の動作が正しくても物は運べません。ロボットに必要なのは、もっともらしい手順から、実際に物が動く軌道へ到達する仕組みです。
Sakana AIは2026年9月28日の公式発表で、東京大学との共同研究「SAIL」を紹介しました。VLMが生成した軌道をシミュレータで実行し、映像から進み具合を評価して修正する研究です。論文v2は9月19日改訂、初稿は3月9日で、IROS 2026に採択されています。
結論から言うと
SAILは、ロボットを動かす前の試行錯誤に、推論計算を使います。
生成モデルが軌道を提案し、シミュレータがその動きを実行する。評価モデルが途中経過を調べ、生成モデルへ返す。これを探索として回し、選ばれた軌道を実機へ送ります。
さらに、そこで得られた成功軌道を集め、別の制御モデルを学習する実験まで進んでいます。一度の動作を改善する計算が、次の動作を作るためのデータにもなるわけです。
導入を考えるなら、見るべき場所は三つあります。軌道のどこを直すか伝えられるか。実際の作業台をシミュレータへ再現できるか。そして、探索で得た成功例を次の試行に残せるかです。
シミュレーションで動作を試し直してから実行する考え方を表したAI生成イラスト。実験装置や実際の軌道を再現した図ではありません。
VLMが作るのは、手先の位置と姿勢の列
まず、SAILの出力を具体的に見ます。
論文の問題設定と手法では、ロボットの手先の状態を、三次元の位置、クォータニオンで表した姿勢、グリッパーの開閉状態で表します。その状態を順番に並べたものが、一本の軌道です。
| 軌道に入る情報 | 動作への意味 |
|---|---|
| 手先の位置 | どこへ移動するか |
| 手先の姿勢 | どの向きで物に近づくか |
| グリッパーの開閉 | どの段階でつかみ、離すか |
VLMがこの列を生成し、逆運動学のコントローラが各ウェイポイントを順番に実行します。逆運動学は、指定した手先の位置や姿勢に届くように、関節の状態を求める処理です。
ここで、役割が分かれます。
コントローラが指定位置へ到達できても、そこが物をつかめる位置とは限りません。VLMの出力形式が正しく、関節を動かせても、タスクは失敗し得ます。だからSAILは、生成した軌道によって何が起きたかを、実行後の映像で調べます。
生成時には、現在の物体配置とロボットの状態に加え、成功した動作の例を与えます。著者の技術解説によると、成功軌道の保管庫から見た目の近い場面を選び、探索中に見つかった成功例も追加します。VLMの重みを更新する代わりに、与える実例と修正材料を変えていく構成です。
実験で使われたVLMは、生成側も評価側もGemini Robotics-ER 1.5です。SAILは、それらを使って軌道を改善する周囲の仕組みを研究しています。
「失敗した」だけでは、つかむ位置を直せない
軌道全体に成功か失敗かを付けるだけでは、修正箇所が分かりません。
手を伸ばせなかったのか。物の横でグリッパーを閉じたのか。つかめたのに途中で落としたのか。同じ失敗でも、変えるべき位置や動作は違います。
SAILの評価処理は、成功したお手本の動画から、タスクを順序付きの小さな作業へ分解します。論文が挙げるペンの受け渡しなら、近づく、つかむ、持ち上げる、渡す、といった段階です。
次に、候補軌道をシミュレータで動かし、動画から等間隔でフレームを取り出します。実験では50フレームです。評価VLMは、いまの小作業がどれだけ進んだかを0〜100%で推定し、完了したら次の小作業へ進みます。
完了済みの段階と現在の進捗を合わせることで、動画全体に「どこまで進んだか」という曲線ができます。その平均を、探索で候補を比べるためのスコアに使います。
そして、この途中のスコアを捨てません。
修正処理では、映像の進捗スコアを、対応する軌道上のウェイポイントへ結び付けます。生成VLMへ戻すのは、実行した位置や姿勢に進捗が付いた軌道です。高く評価された区間を保ち、低い区間を修正するよう促します。
これなら、「どこかを直して」と頼むより、進み具合が止まった場所に対応する動作を検討できます。たとえば把持の前後で進捗が止まる場合、次に調べる対象を、その周辺の位置・姿勢・開閉タイミングへ絞れます。これは仕組みから導ける使い方で、失敗原因を必ず正しく特定できるという保証ではありません。
探索木の一つのノードに、動作が丸ごと入っている
修正を繰り返すと、別の問題が出ます。
同じ候補を直し続けるべきでしょうか。それとも、別の動きを作り直すべきでしょうか。
SAILはモンテカルロ木探索の定式化で、この選択を扱います。特徴は、木の一つのノードが、最初から最後までの一本の軌道になっていることです。親から子への枝は、その軌道を修正した関係を表します。
一本の軌道に沿って時間を進めることと、探索木の枝をたどることは別の操作です。子ノードを作るたびに、新しい軌道全体をシミュレータで試します。
論文の処理を簡略化した図。探索と修正のループはシミュレータ側で回ります。
候補を選ぶときには、これまでの評価と探索回数を使います。成績のよい枝を掘り下げながら、十分に調べていない枝にも計算を配る。実験では、選んだノードから三つの修正版を生成しています。
この構造があると、一つの修正案に固執せず、途中までうまくいった軌道も材料として使えます。生成、実行、評価、修正の履歴を、次の計算先を決めるために残す設計です。
候補を増やすだけより、修正と探索を組み合わせる
実際に、どの程度効いたのでしょうか。
著者の公開結果では、ALOHAシミュレータの6課題について、それぞれ20通りの初期配置を評価しています。一本だけ生成する場合の平均25%に対し、最大45候補を探索する場合は73%まで、成功軌道を見つけた割合が上がりました。成功判定には、探索を誘導するVLMの点数とは別に、シミュレータの正解判定関数を使っています。
さらに、論文の同じ15候補での比較を見ると、計算の使い方の違いが分かります。
| 方法 | 15候補の使い方 | 6課題の平均成功率 |
|---|---|---|
| 幅優先の比較手法 | フィードバックなしで候補を広く生成 | 51% |
| 深さ優先の比較手法 | 一列に修正を繰り返す | 37% |
| SAIL | 複数の候補探索と修正を組み合わせる | 65% |
数値は論文の丸め表記に合わせた著者報告です。本記事ではシミュレーションや実機実験を再現していません。
同じ候補数でも、生成を並べることと、実行結果を次の修正へ使うことでは結果が変わっています。一方、ノートPCを閉じる課題では、この予算で幅優先の方が高い成功率でした。ここでも、SAILの探索があらゆる動作で最適だったわけではありません。
自分のシステムに取り入れるなら、まず候補数の上限をそろえ、独立に生成する方法と、途中の進捗を返す構成を比べます。時間やAPIコストも併せて記録すると、その作業に適した計算の使い方を判断できます。
実機に持ち出すと、作業台の再現が効いてくる
シミュレータで成功した軌道を実機へ送るには、両者の物体配置を合わせる必要があります。
SAILの実機検証では、LeRobot SO-101アームで、青いブロックを赤いボウルへ入れます。試行ごとにブロックとボウルの位置を変え、その場の配置を仮想空間へ再構成しています。
ここには、VLMへの指示とは別の処理が並びます。
- 固定したRealSense D435iから、カラー画像と奥行きを取得する。
- GroundingDINOで対象を検出し、SAM2で物体の領域を切り出す。
- その領域の奥行きから三次元の点群を作る。
- カメラの校正情報とArUcoマーカーを使い、ロボット座標系で物体の位置・姿勢を求める。
- 対応する物体をその位置・姿勢でシミュレータに配置し、カメラの見え方も合わせる。
その環境で最大15候補まで探索し、見つかった成功軌道を実機で実行したところ、6試行中5試行が成功しました。著者らは残る1試行の失敗を、位置・姿勢の推定誤差と、現実の接触挙動を十分に再現できなかったことに帰しています。
この結果から、導入時の作業が見えてきます。軌道の生成だけを改善しても、ブロックの位置が仮想空間でずれていれば、そのずれを含んだ世界で成功する軌道を探してしまいます。
さらに、公開解説の制約にあるとおり、実機の軌道実行はオープンループで、動作中の視覚フィードバックを使いません。実行前にうまくいく動きを探す設計なので、動いている途中で物体がずれたときの修正は別に必要です。実機で確認された範囲も、この1課題、各方式6試行に限られます。
成功軌道120本が、次の制御モデルの教材になる
探索には計算時間がかかります。毎回VLMに候補を作らせ、動画を評価させる処理を、反復作業でも続けるのでしょうか。
SAILの方策を学習する実験では、別の使い道を試しています。シミュレータ内で物体配置を変えながら探索し、成功軌道を120本集めました。それを使い、Action Chunking with Transformers（ACT）というモデルを行動模倣で学習しています。
行動模倣では、お手本の観測と動作から、その動作を出す方策を学びます。ここでは、探索で見つけた成功例がお手本です。
探索の成果が、選ばれた一本の軌道から、繰り返し使える学習データへ広がります。
実機では、この学習済み方策を使う方式も6試行中5試行に成功しました。論文が「平均実行時間」として報告する値は、MCTS方式の644.72秒に対し72.306秒です。処理別の内訳は示されていないため、これはアーム自体の移動速度の比較とは扱えません。
また、学習後もシミュレータを使います。その試行用に再構成した環境で方策を複数回実行し、成功した軌道を選んでから実機へ送る流れです。
開発工程として見ると、初めは時間をかけて動ける軌道を見つけ、その成果を教材にして次の候補生成へ回す構成になっています。ただし、学習用データの生成時間や学習時間まで含めた費用回収は、この実験だけでは判断できません。繰り返す回数と作業配置の変わり方に合わせて、別に見積もる必要があります。
自分のロボットで試すなら、まず一つの作業を閉じる
この研究から実装へ進むなら、最初の対象は「ブロックを決まった容器へ移す」のように、開始条件と終了条件を書ける作業が扱いやすそうです。以下は論文の構成を踏まえた導入上の提案です。
まず、観測から再現までを通します。 カメラが推定した物体位置をシミュレータへ置き、実物の位置と比較します。手先が到達できる範囲と、物体をつかめる配置が一致するかを確認します。
次に、生成と修正の境界を決めます。 軌道の各ウェイポイントと動画のフレームを対応付けて保存し、どの動作の後で進捗が止まったかを追えるようにします。最終的な成功・失敗も別に残せば、評価モデルが高得点を付けた失敗を調べられます。
そして、成功例を再利用できる形で残します。 初期配置、観測、軌道、結果を一組にして保存する。動く軌道が集まった段階で、毎回探索する構成と、そのデータで方策を学習する構成を比較します。探索中と実機実行中の失敗を分けておくと、修正すべき場所も追いやすくなります。
SAILが示したのは、ロボットの動作生成に、実行前の検証と修正を組み込む道筋です。そのために必要なものは、生成モデル、実際の配置に合わせたシミュレータ、途中経過を返す評価、そして成功を蓄えるデータです。
生成した動作を試し、直し、次の教材にする。この循環まで作ると、一本の成功軌道が次の開発につながります。
参考文献
Sakana AI — SAIL: Scaling In-Context Imitation Learning（2026年9月28日）
https://sakana.ai/sail/
Sakana AI・東京大学 — SAIL: Test-Time Scaling through Iterative Refinement for VLMs as Robot Trajectory Generators（公式技術解説）
https://pub.sakana.ai/sail/
Makoto Sato, Yusuke Iwasawa, Yujin Tang, So Kuroki — SAIL: Test-Time Scaling for In-Context Imitation Learning with VLM（arXiv:2603.08269v2、2026年9月19日改訂、CC BY 4.0。本記事では手法と結果を日本語で要約）
https://arxiv.org/html/2603.08269v2
Creative Commons — Attribution 4.0 International（論文の利用許諾）
https://creativecommons.org/licenses/by/4.0/