Gemini Robotics 2：DeepMind自身の数字が示すもの

Gemini Robotics 2の正体

この命名は誰の助けにもなっていないので、まずシンプルに説明しておく。「Gemini Robotics 2」はファミリー全体の名前でもあり、そのファミリーの中にある特定の1モデルの名前でもある。3つのモデルが同じ日に一斉に発表され、それぞれ役割が異なる。

この分割は重要だ。まともなエージェントシステムを設計するなら、私も同じアーキテクチャを描くはずだからだ。1つのモデルが「何をすべきか」を推論し、うまくいったかどうかを追跡する。別の、より高速なパーツが実行を担う。DeepMindは、ER 2が「モーターの実行を、その時点で与えられた下位のvision-language-action(VLA)モデルに委ねる」と明言している。つまり計画役は、意図的に「手」の実装を気にしない設計になっている。

ドキュメントの中の一つの記述が、全体の見方を変えてくれる。ER 2はGemini 3.5 Flashをベースに構築されている。Proクラスの派生版でもなければ、専用に設計されたアーキテクチャでもない。空間推論、動画中の特定シーン検索、複数ロボットのオーケストレーションをチューニングしたFlashクラスのモデルなのだ。Gemini 3.6 Flashを追っていた人なら、その裏にある計算資源の規模感はおおよそ想像がつくはずで、Flash-Liteシリーズも同じことを物語っている。

ポインティングや座標系の処理は、Geminiのエージェント型ビジョンと同じ系譜から来ている。ファミリー全体を比較検討したいなら、私が更新し続けているGeminiの代替ツール一覧も参考にしてほしい。

全身制御という主張は本物であり、はっきりさせておく価値がある。これまでのバージョンはテーブル上の作業向けに、ヒューマノイドの上半身しか動かしていなかった。今回は脚も制御する。DeepMindが公開したデモ用のプロンプトは_「水差しを一番下の棚の緑色のビンに入れて」_というもので、Apptronikの Apollo 2がテーブルまで歩いていき、水差しを持ち上げ、棚まで歩いて置く。同じモデルのチェックポイントは、二指グリッパーを装着したFranka Duoも動かしており、こちらのほうが実は静かに印象的だ。

DeepMindが自ら公開した数字

以下が、DeepMindが報告したとおりの完全な表だ。3つのスキルグループはいずれも1つの共有チェックポイント上で動作し、3種類の異なるロボット本体で実行されている。だからこそ、ここで見られる差は恥ずかしいものではなく、むしろ興味深い。

多指グループの一番上と一番下を並べて見てほしい。この2つの組み合わせだけで、2026年のロボット学習がどこまで来ているかがすべて分かる。電球を外す作業は92%。取り付ける作業は36%。どちらも同じロボットの、同じ5指・22自由度のSharpaWaveハンドを使っている。違うのは動きの種類だ。外す動作はゆるく、多少の誤差も許容される。取り付ける動作は、トルクをかけながら位置合わせを保つ必要がある。片方はただの「つかむ」動作で、もう片方は「制御」の問題なのだ。

グリッパーグループはほぼ全ての項目でハンドグループを上回っており、これも少し考えてみる価値がある2番目のポイントだ。Franka Duo上の二指Robotiqグリッパーは精密な差し込み作業で89.6%を出しているのに対し、人型のハンドはジップロックの作業でわずか40%しか出せていない。自由度が多いほど、細かい作業ではむしろ結果が悪くなった。少なくとも今のところは。

そしてDeepMind自身がそう認めている。グラフの注記にはこうある。「Gemini Robotics 2は全身動作とグリッパーを使った巧緻タスクでは中〜高程度の成功率を達成しているが、多指を使った巧緻な操作は依然として課題が残る」。同じページの別の場所では「私たちのロボットは動作速度についてまだ進歩の余地がある」とも述べており、人間レベルの巧緻性は「主張」ではなく「目標」として位置づけられている。

単一の混合数値では、これらすべてが見えなくなる理由

この5つの多指タスクを平均すれば、40%台半ばあたりの数字になり、そこから学べることは何もない。あるモーションではほぼ解決済みで、別のモーションではほとんど機能していないという事実は見えなくなる。また、どのタスクを前提にプロダクトを設計してはいけないかも分からなくなる。

これはロボティクスに限った問題ではまったくない。あらゆるカテゴリーのAIマーケティングの標準的な状態であり、自分自身の業界も例外ではない。ひとつの一次対応デフレクションの数字が、まったく同じばらつきを覆い隠してしまう。実際に数字を動かしてみて、見出しがいかに簡単に操作できるかを見てほしい。

"都合のいい4つだけ"を試してみると、どのマーケティングチームも喜んで印刷したくなるような数字が出てくる。同じモデル、同じ日、同じ研究所。それを作るために何かを偽造したわけでもない。これがそのトリックであり、単一の数字を報告するすべてのベンダーが使える手口だ。

最も興味深い数字は、ロボットではなく人間についてのものだ

ER 2のベンチマークの中に、DeepMindが3パターンで比較している数字が埋もれている。これは推論モデルが下流の実行役をどれだけうまく操縦できるかを測るもので、変わるのはその実行役だ。実機のロボット、シミュレーションされたロボット、そして人間の遠隔操作者。

同じ計画役モデルでも、ロボットを指示するより人間を指示するほうが14ポイント成績が良い。どちらかのケースでモデルの性能が落ちているわけではない。相手側の人間が、あいまいさを吸収し、つかみ損ねをリカバーし、指示に書かれていなかった意図を補ってくれているだけなのだ。

デモ映像を見ていたRedditのコメント投稿者も、外から見て同じ結論に達している。

"The bottleneck seems to be software. So until we get ai good enough to pilot a robot, it's going to remain slow.

If you see robots piloted by humans, they are much faster."

u/dranaei, Reddit

これは壁に貼っておきたいくらいの発見であり、実のところロボティクスの発見ではない。数字が付いたAIコパイロットの議論そのものだ。計画を立てたうえで有能な人間に引き渡すモデルは、同じモデルが自らエンドエフェクタを操作するよりも成績が良く、その差は数値で測れる。サポート業務に当てはめれば、エージェントが人が送る返信の下書きを作るケースと、エージェントが自分で返信するケースの違いだ。どちらの成績が良いかについての正直な答えは、DeepMindと同じで、人間がループに入っているほうだ。タスク別の数字が別のことを語るようになるまでは。

これは自律性そのものへの反論ではまったくない。選ぶ前にその数字を知っておくべきだという主張であり、その数字は速く動く。半年前の最良のAIエージェントが、今日選ぶべきものとは限らないくらい速く。

ER 2の比較データの残りの部分も強力で、公平に報告する価値がある。

進捗分類は、このページの中で最も差が大きい項目だ。57.4%対、ロボティクス以外の最良モデルの46.2%。この指標は「タスクのどこまで進んでいるか分かるか」を測るもので、フレームごとに5段階のバケットに分類してスコア化される。地味な指標だが、エージェントが「続けるべきか、助けを求めるべきか」を判断する前に必ず知っておく必要のあるものだ。DeepMindはまた、モーメント検索の精度が91.3%で、平均絶対誤差が0.96秒、実行速度は大型モデルカテゴリーの4倍だと報告している。

この57.4%という数字は、裏を返せば10回に4回ほど進捗を見誤っているということでもある。この分野のベストであっても、それだけの頻度で間違えるのが普通の状態であり、これはまさに「最先端」という一行の主張が消し去ってしまう類の事実だ。

誰も話題にしていない安全性の急上昇

これは私が思わず身を起こしてしまった数字だ。まだどこでも取り上げられているのを見たことがない。

Gemini Robotics ER 1.6が安全指示に従っていたのは47.2%の割合でしかなかった。このモデルは2026年4月にリリースされた、つまり4か月前のものであり、両方の安全性指標でOpus 5とGPT 5.6 Solの両方を下回っていた。ロボティクス向けに調整されたモデルが、比較対象となった汎用テキストモデルよりもロボットの安全性で劣っていたということだ。

ER 2はこれを大きく改善し、97.9%と93.0%まで引き上げている。良いことだ。ただ、ここで有用な教訓は、バージョンラベルを信頼することについて前世代の数字が示している内容のほうだ。「フロンティアラボの最新ロボティクスモデル」というものが、先週まで、安全制約に従う割合が半分未満だったということになる。DeepMindはこのためのベンチマークとしてASIMOV-Agenticを新たに公開し、パブリックデータセットとして提供している。これは推論エージェントが安全でないツール呼び出しを拒否するか、タスクが不可能であることを予測できるか、そして不確かなときに人間に助けを求めるかを測定するものだ。

拒否すること、失敗を予測すること、不確かなときにエスカレーションすること。これは、多くのサポートAIのドキュメントよりも、よくできたサポートエージェントの説明としてすぐれており、そのままエスカレーション管理にも当てはまる。ハンドオフはさらに別の規律であり、チャットのハンドオーバーは多くのチームが最初に間違えるポイントだ。

ここでの限界については正確に述べておく価値がある。このブログはER 2をDeepMind史上最も安全なロボティクスモデルだと主張しているが、ASIMOV-Agenticの結果自体については数値スコアを何も公開していない。それらは別の安全性技術レポートにまとめられている。そして開発者向けドキュメントは、責任の所在についてはっきりと書いている。「ロボット周辺の安全な環境を維持するのはあなたの責任だ」と。

コストと、ドキュメントに潜む落とし穴

価格が付いているのはER 2だけだ。ハードウェアに触れる2つのモデルには価格が一切ない。単純に、購入すらできないからだ。

価格は2倍になった。ER 2は入力・出力の両方でER 1.6の2倍だ。ただ、入力レートが一律であるため、音声中心の作業は視覚系の作業に比べて相対的な上昇幅は小さくなる。コンテキストウィンドウはまったく増えていない。ストリーミング版の姉妹モデルgemini-robotics-er-2-streaming-previewもあり、見出しの料率は同じだが、バッチ料率もキャッシュもない。

ドキュメントの中には、先に読んでおかないと午後の時間を丸ごと持っていかれる4つのポイントがある。

1. 制限のないAPIキーは容赦なく403になる。 ロボティクス系はGeminiの中でもデフォルトキーを拒否する唯一の窓口なので、最初の呼び出しの前にAI Studioで制限を追加しておくこと。
2. ストリーミングエンドポイントは画像入力をJPEG、1秒あたり1フレームに制限している。 リアルタイムを謳う文脈の中では奇妙な制約だ。ロボットのカメラフレームは1秒に1枚までしかストリーミングできない。
3. ストリーミングエンドポイントは構造化出力とコード実行をサポートしない。 つまりJSONスキーマを使う経路も、エージェント型ビジョンの経路も、非ストリーミングモデルの領分になる。
4. ドキュメントはレイテンシのためにmediumの思考レベルを推奨しているが、はじめかたのサンプルコードはhighのまま出荷されている。 そこからコピペすると、遅いデフォルト設定を引き継いでしまう。

これらのモデルには、普通のGeminiのページには付いていないプライバシー通知も付いている。モデルが「ハードウェアを操作し、動かすために動画データと音声データを活用する」ため、Googleは、通知と同意を得るまで、識別可能な人物をロボットの周囲に居させないことを求めており、さらに顔のブラー処理も要求している。これを無料利用枠の「プロダクト改善に使用:はい」という項目と並べてみてほしい。カメラを人に向けた無料利用枠のロボットは、クォータの問題ではなく、同意の問題になる。

そしてカレンダーに書き込んでおく価値のあるスケジュールの話をひとつ。gemini-robotics-er-1.6-previewは2026年8月31日に停止される。ER 1.5はすでに4月に引退済みだ。つまり1年の間に2つのエンドポイントが引退しており、現行のモデルコードにはいまだに-previewという接尾語が付いたままで、固定できる安定したエイリアスは存在しない。

新しいロボットへの適応と、複数ロボットの話

Gemini Robotics On-Device 2は、私が個人的に最も静かに重要だと感じている部分だ。ローカルで動作し、Gemini Robotics 1.5からのモーション転送の成果を引き継いでおり、まったく新しい双腕ロボットにも「わずか数時間の適応時間、多くの場合200例未満」で適応できる。新しい形状、新しいセンサー、一致しない自由度にも対応する。

新しいロボット本体を立ち上げるのに200例未満というのは、この分野の経済性を変えてしまう数字だ。あのグリッドの中のタスクはDexmate、SO101、Trossenの各プラットフォームで実行されており、いずれも旗艦のヒューマノイドではない。パネルのひとつは、ロボットアームが「私はロボットです」というチェックボックスをクリックしているもので、おそらくジョークだと思うし、私はそれを気に入っている。

複数ロボットの連携も、もう一つの新機能だ。ロボット同士が通信し、互いの物理的な強みを認識し、タスクを互いに委任し合う。デモではApollo 2ヒューマノイドがFrankaアームと並んで作業しており、モニターにはモデルが実際に見ている映像が表示されている。

DeepMindはApptronik、Boston Dynamics、Agile Roboticsをパートナーとして謝辞に挙げている。別のデモでは、Boston DynamicsのSpotがオーケストレーションされたSpot APIを通じてポップコーンを取ってくる様子も見られる。ハードウェア側では、Apptronikが2026年2月に5.2億ドルのシリーズA-Xを調達し、累計は10億ドル近くに達している。指摘しておく価値があるのは、Apollo 2はデータ収集用のプラットフォームであり、商用機ではないという点だ。商用機はApollo 3で、発表日はまだない。関係する4社のハードウェアベンダーいずれからも、仕様や価格は一切公開されていない。

現場のエンジニアたちが実際に語ったこと

Hacker Newsのスレッドは619ポイント、553件のコメントに達し、どの報道記事よりも読む価値がある。中でも最も有用だったコメントは、こうしたモデルに実際に取り組んでいる人物からのものだった。

"Plus we have no good reliable accuracy testing data in most cases (most tests occur on a few demos, but that isn't a good representation of how must things work), popular benchmarks, such as libero have been saturated, and nearly everything gets 95% there, most companies and researchers have their own benchmarks here."

adityashankar, Hacker News

飽和したベンチマークと、みんなが自分の宿題を自分で採点している状況。これはソフトウェアAIの評価にもほぼそのまま当てはまる話であり、だからこそOpenAI自身の評価ガイダンスも、公開のリーダーボードを信じるよりも自前の評価セットを作ることを強く推奨している。

最も鋭い批判は、モデルそのものについてではまったくない。動画の「見せ方」についてのものだ。

"This is why we need long continuous shots of robots interacting doing tasks, rather than the sizzle reels with 5 second shots. The long shots tell the true story of how far along the technology is, while the short shots make it look way more advanced than it really is. Still, great to see the progress being made."

u/edgroovergames, Reddit

あるHNのコメント投稿者はさらに踏み込み、このデモを「無駄に複雑なロボットで低い成功率のピックアンドプレースを大げさに見せているだけ」と評し、競合の公然と遠隔操作していることを明示した映像のほうが好ましいと述べている。実際の展開に近いからだという。厳しい評価だが、45.7%という数字を踏まえれば、あながち的外れとも言えない。

その36%という数字は、さらに大きな議論の根拠として取り上げられることになった。

"A 36% success rate on screwing in a light bulb means there's probably something to LeCunn's take that VLM/VLA models aren't going to be the thing powering tomorrow's robots, but only time will tell."

cowboy_henk, Hacker News

最も鋭い反論は一行で来た。私が賭けるならこちらだ。

"It's still very early days. There are many benchmarks that LLMs scored 36% on just 18 months ago that they're now at 100% on."

heaney-555, Hacker News

そして、あるロボット工学者が「ゆっくり慎重に」と「速く滑らかに」がまったく別の問題クラスである理由を説明している。

"An algorithm to fold tshirts 90% of the time is easy. The cloth hangs down by gravity and you can just look for right angles (corners), find their coordinates with binocular matching, and move them to meet each other. Getting 99%, or folding them quickly, so that the fabric is actually moving instead of just hanging still- incredibly, incredibly more complex."

hwillis, Hacker News

「それってFigureがもう見せていたのでは」という声もかなり多く見られた。そこで、本当に重要な比較の話に移ろう。

この表を公開しているのは他に誰もいない

この分野の他のすべてのラボについて、同等のタスク別数値がないか探してみた。公開されているものはこれで全部だ。

自社のローンチページに絶対的なタスク別失敗率を載せているのはDeepMindだけだ。Figureは巧緻性タスクの名前を挙げ、4分間の皿洗い機動画を見せているが、そこにはいっさい数字が付いていない。Teslaは Optimusのモデル名すら一度も明かしていない。Physical Intelligenceはタスク別レートをグラフ化しているが、それはRL専門のベースラインとの比較であり、値は明記されずクライアント側でレンダリングされているだけだ。

だからGemini Robotics 2について正直に読み取るべきなのは「Googleのロボットは遅れている」ということではない。自社のロボットが実際にどこまで来ているかを見せているのはGoogleだけであり、しかもその開示した数字のせいで批判されている。これは良くないインセンティブだ。このままいけば、次のラボはただ動画だけを公開するようになるだろう。

AIエージェントを購入する側にとって、これが意味すること

私はロボットの仕事はしていない。サポートチケットを処理するAIエージェントを作っている立場から見ても、今回のリリースは、ベンダーが私に見せるべきものについての考え方を変えるものだった。

あるお客さまの話をしよう。デンマークのB2B車両テレマティクス企業で、Zendeskで月間約200件のチケットを処理し、2,000件規模へと拡大しつつあるチームだった。そこのエージェントは、データベースに存在しないブランドの車種について、自信満々に「はい、そのお車の型式には対応しています」と顧客に伝えるようになってしまった。ナレッジベースには「すべての型式に対応」と書かれていた。ボットはそれを信じたのだ。彼ら自身によるその初期セットアップの総括は「最初は試行錯誤だった」というものだった。このタイプのチケットは、タスク別の表では明確にゼロ点になるはずのものだが、混合された数字の中では単純に見えなくなっていた。これはカスタマーサービスの自動化においてよくある、特別珍しくもない失敗の形であり、だからこそハルシネーション防止はモデルの問題である以上に、設定の問題なのだ。

だからこそ、eeselのすべての導入は、まず顧客自身のチケット履歴に対してシミュレーションを実行する。解決済みチケットのバッチを取り出し、エージェントが答えたであろう内容を生成し、実際に人間が送った内容と比較してスコア化し、実際の顧客が1人も関わる前にギャップレポートを作成する。これはDeepMindの表と同じ考え方であり、ただ電球ではなく自分たちのチケットから作られているだけだ。あるDTCサプリメントブランドのCXリーダーは、この要件を私よりうまく言い表している。

"The AI will never be able to answer 100% of the questions... I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

この今回のリリースから、物理・非物理を問わずAIエージェントを購入する際に持ち帰りたい3つのポイント。

1. 見出しの数字ではなく、タスク別の表を求める。 ベンダーが単一のデフレクション数値を提示してきたら、インテント別、チケットタイプ別に分割してもらうよう求める。真実はそのばらつきの中にあり、AIの性能指標もその粒度でこそ役に立つ。初回解決率にも同じことが言える。
2. 本番投入の前に、自社の履歴でテストする。 他人のタスクで実行したベンチマークは、自社の返金ポリシーのエッジケースについては何も予測してくれない。敵対的テストと同じ発想であり、エージェントを評価することがデモを信じるより優れている理由もそこにある。
3. 92%のタスクではなく、32%のタスクを前提に設計する。 エージェントがどの作業を拒否すべきかを把握する。確信度のしきい値を意図的に設定し、ハンドオフをきれいに保つ。ひとつの自信満々な間違いを防ぐことは、カバレッジの1ポイントよりも価値がある。

最後のポイントがすべてを決める。チケットの60%を解決し、残りをきれいにエスカレーションするエージェントは、100%に挑んで5件に1件は間違えるエージェントよりも優れたプロダクトであり、お客さまも常にそう言っている。誤った回答が生み出す後始まつ的なチケットのコストを織り込めば、解決件数あたりのコストの計算もこちらのほうが有利になる。

計測についてもっと詳しく知りたいなら、カスタマーサービスの評価についての私の記事のほうがここより深く掘っている。エージェントと人間のコスト比較も同様だ。まだ基盤モデルを選んでいる最中なら、どのLLMがサポートに向いているかのほうが、どんなロボティクスのベンチマークよりも良い出発点になる問い掛けだ。

eeselを試す

エージェント型カスタマーサービスソフトウェアを探していて、この記事が何度も主張してきたようなタスク別の正直さを求めているなら、eeselはまさにそれを提供するために作られたものだ。Zendeskや、すでに使っているどのヘルプデスクにもプラグインでき、Freshdeskも含まれる。マクロと過去のチケットから学習する。そして実際の履歴に対してシミュレーションを実行するので、顧客に返信する前に、チケットタイプ別の精度の形を見ることができる。

具体的な違いはこうだ。どのチケットタイプに触れさせ、どれには触れさせないかを自分で決められ、単一のデフレクション率ではなく、アクションごとの承認・却下件数が見られる。Gridwiseは最初の1か月で一次対応リクエストの73%を解決し、残りの27%が何であるかも把握できた。料金はチケット単位なので、キューの一部しか処理しないエージェントのために座席分を買う必要はない。

eeselを試す、無料で。あるいは、古いチケットを100件だけ渡して、ギャップレポートが何と言うか見てみるのもいい。