AI駆動開発 2026年8月2日

ロボットの「体」をAIが設計する時代——Transformer Transformerが示す次の一手

ロボットに「布を投げる動作」のデモを見せる。すると、そのタスクに最適化されたロボットの設計——リンク、ジョイント、モーター、慣性特性のすべて——が自動で生成される。

Columbia大学のHuy Ha、Karen Liu、Shuran Songらが発表した Transformer Transformer は、そういうモデルだ。論文に記載されている実験結果は具体的で、ALOHA2というバイマニュアル（両腕）プラットフォーム向けに生成した設計は、元の設計と比べて追跡誤差を73%削減し、最大関節速度を30%向上させた。

数字だけ取り出すとインパクトがある。だが、この研究が面白いのは数字よりも「何をどう考えたか」という設計思想にある。

なぜ今これが重要か：「頭脳」の次は「体」

ここ数年、ロボット研究への投資の大半は「賢くする」方向に向かっていた。より大きなデータセット、より精巧な強化学習、より高性能なポリシーアーキテクチャ。それ自体は間違っていないが、論文が率直に指摘しているように、「badなembodiment（身体設計）は、どれだけ優れたポリシーも妨げる」。

論文の比喩をそのまま引用するなら、「ボールを投げるデータをいくら集めても、ロボットの形状が最適でなければ、ボールではなく自分自身を投げることになる」。

これは笑えるが、本質をついている。ロボットの「頭脳」の自律化が一段落しつつある今、「体」の設計そのものを自動化・最適化するフェーズが始まりつつある。Transformer Transformerはその流れの中に位置する。

技術の中身を整理する：3つの柱

1. RoboTokens——ロボットを「共通言語」で表す

異なる形状・構造のロボットを、1つのモデルで扱うには、共通の語彙が必要だ。これが RoboTokens の役割。

仕組みはシンプルだ。リンク、ジョイント（固定・回転・スライド・ボール）、モーター、状態、アクションを、それぞれ「型付きトークン」として表現する。ジョイントトークンは接続する2つのリンクのIDを参照する形式なので、6自由度のアームでも35自由度のバイペッドでも同じフォーマットで記述できる。

実際に11体のロボット（MuJoCo Menagerieより）をトークン化した結果、1体あたり28〜101のRoboTokensに収まった。これは、ロボットをXML形式（MJCF）で記述した場合の27〜110分の1のサイズだ。ロボットの質量は0.65kgのデクスタラスハンドから67.5kgのクアドラペッドまで、2桁分の幅をカバーしている。

このコンパクトさが重要で、「拡散モデルでエンドツーエンドに扱える」という実用上の意味がある。テキスト形式なら言語モデルが何千トークンもかけて自己回帰的に出力しなければならないところを、数十のトークンで拡散できる。

2. Transformer Transformer——1つのモデルが3役を演じる

モデルの本体は、拡散トランスフォーマー（DiT）だ。DDIMノイズスケジュールを使い、どのトークンをマスクするかによって同じネットワークが異なる役割を担う。

すべてをマスク：無条件のロボット生成器
アクションをマスク：クロスエンボディメントコントローラー（異なるロボットを動かす）
エンボディメントをマスク：動作条件付きロボット設計器

同じ重みで、同じ訓練で、3つの役割をこなす。これはアーキテクチャの効率性という意味だけでなく、「設計・制御・評価を分離しない」という思想的な選択でもある。

なお、論文タイトルの「Transformer」は2重の意味を持つ：最初の "Transformer" は「embodimentを変えられるロボット」を、2つ目は「自己注意アーキテクチャ」を指す。

3. Dynamics Self-Guidance——見たことのない報酬関数にゼロショット対応

ロボット設計の最大の難しさの一つは、「どんな報酬関数で最適化するか」が事前に決まっていない点だ。タスクが変われば報酬関数も変わる。

Transformer Transformerが採用した解法は、モデルを特定の報酬関数に対して訓練するのではなく、ダイナミクスモデルとして訓練することだ。報酬に依存しない予測を出力し、推論時にその予測を報酬に変換してグラジェントを計算、それでエンボディメント拡散を誘導する——これがDynamics Self-Guidanceと呼ばれる手続きだ。

3つの設計空間にわたる実験では、訓練時に見ていない報酬関数とトラジェクトリに対してゼロショットで最適化でき、進化的ベースラインと比べてパフォーマンスと実行時間を改善したと報告されている。

「設計」をモデルに渡すことの意味

ここからは見方の話になる。

ソフトウェアの世界では「デプロイ後に変更できる」ことが当たり前だ。しかしハードウェア——とりわけロボットの物理的構造——は、一度設計・製造すると変えられないのが前提だった。「設計時にあらゆる用途を想定しなければならない」という制約が、ロボット開発コストを高く保ち続けてきた。

Transformer Transformerが示しているのは、設計空間をモデルの学習対象にするという発想の転換だ。タスクを入力すれば設計が出てくる。設計を入力すれば制御が出てくる。1つのモデルが設計者・制御器・評価者を兼ねる。

これはロボット開発の「フロー」を根本から変える可能性がある。今は「設計→製造→テスト→再設計」というウォーターフォール的なサイクルが支配的だ。もしモデルがシミュレーション上で設計と検証を高速で回せるなら、そのサイクルが短縮される。製造前に「このタスクにはこの形状が有効」という検証が完了する世界が、少なくとも研究レベルでは見え始めている。

ただし、留保も必要だ。現時点での実験は、シミュレーション上での評価が中心で、実際に製造したのは「布を投げる」タスクの1件だ。シミュレーションと実環境のギャップ（sim-to-real gap）がどこで顔を出すか、量産時のコスト構造はどうなるか——この部分はまだ答えが出ていない。「73%の誤差削減」は事実だが、それを一般化するには慎重な目が必要だ。

実務的な論点：何を考えるべきか

製造業・ロボットメーカーの担当者にとっては、「設計最適化のコストが変わる」という文脈で読む価値がある。特定タスク向けにカスタムロボットを設計することは、これまでは高コストの専門作業だった。設計探索をモデルで自動化できるなら、「専用機」を経済的に作れる閾値が下がる。汎用ロボットに頼らざるを得なかった領域で、専用設計の経済合理性が出てくる可能性がある。

研究者・開発者が次に注目すべき論点はいくつかある。

製造可能性の制約をどう組み込むか：モデルが生成する設計が、現実の製造プロセスで作れるかどうかはまた別の問題だ。モーターの入手性、素材の物性、加工精度——これらをトークン化に組み込む方法論はまだ途上にある。
検証コストはどこへ行くのか：設計生成が速くなれば、「どの設計が本当に使えるか」を検証するコストが次のボトルネックになる。物理試作なしに確信を持てるシミュレーション精度が鍵になる。
誰が報酬関数を定義するのか：Dynamics Self-Guidanceは訓練時に見ていない報酬関数にゼロショット対応できるが、そもそも「何が良い設計か」の定義は人間が与える。タスクの曖昧さや多目的最適化をどう扱うかは、実務化に向けた現実的な課題だ。

経営・事業企画の観点からは、この研究が「ロボットの専用化が加速するシナリオ」を想定する材料になる。汎用ロボット一台で何でもやる路線と、タスク特化型を安く作る路線——その選択が数年以内に具体的な事業判断として出てくる可能性がある。