0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ロボットは“動く”より“判断する”へ

0
Posted at

Gemini Robotics-ER 1.6 を実装目線で読み解く

はじめに

2026年4月14日、Google DeepMind は Gemini Robotics-ER 1.6 を発表しました。
これはロボット向けの embodied reasoning モデルで、視覚・空間理解、タスク計画、success detection(作業完了判定) を強化したアップデートです。モデルは gemini-robotics-er-1.6-preview として Gemini API と Google AI Studio から利用できます。

このモデルをひとことで言うと、ロボットの手足そのものではなく、ロボットの上位判断レイヤー です。
画像・動画・音声・テキストを受け取り、物体の位置や関係を理解し、必要に応じてツール呼び出しやコード実行を使いながら、次に何をするべきかを決めます。DeepMind の説明でも、Google Search、VLA、サードパーティ関数などを呼び出せる高レベル推論モデルとして位置づけられています。

この記事では、Gemini Robotics-ER 1.6 は何がすごいのか を、できるだけ実装目線で整理します。


先に結論

今回のアップデートで押さえるべきポイントは3つです。

  • Pointing がかなり強い。
    単なる物体検出ではなく、個数把握、大小比較、把持点の検討、制約付き選別まで扱えます。
  • Success detection が実務寄り。
    複数カメラをまたいで「本当に作業が完了したか」を判断しやすくなっています。
  • Instrument reading が面白い。
    圧力計、液面計、デジタル表示を読めるようになり、agentic vision ありでは instrument reading 評価で 93% に到達しています。

要するに、今回の進化は「ロボットをもっと器用に動かす」より、ロボットが状況を読んで判断する 側にあります。
Robotics docs でも、Gemini Robotics-ER 1.6 は座標や bounding box、タスク手順のような構造化出力を返し、既存のロボット制御系とつなぐ前提のモデルとして説明されています。


1. システムとして見るとこうなる

まずは全体像です。
実際の組み込みイメージは、だいたい次のようになります。

Gemini Robotics-ER 1.6 は、画像や動画を見て「何がどこにあるか」を理解し、座標や手順を返します。
Robotics docs では、入力として text / image / video / audio を受け取り、出力は text ですが、その text を point / bounding box / 手順 JSON として扱うのが基本です。

つまり、実装上はこんな分担にするときれいです。

  • Gemini Robotics-ER 1.6: 認識、空間理解、上位計画
  • アプリ側: 座標変換、バリデーション、安全制御
  • ロボット API: 実行

この分け方をしておくと、モデルが賢くなっても制御層を壊さずに差し替えやすいです。


2. どこが進化したのか

2-1. Pointing が「ただの検出」ではなくなった

DeepMind のブログでは、pointing を空間推論の基礎能力としてかなり強く押しています。
ここでいう pointing は「そこにリンゴがあります」だけではありません。たとえば、

  • どの物体が最小か
  • 何個あるか
  • どこを持つべきか
  • 「青いカップに入るサイズのものだけを指せ」に従えるか

といった、ロボットが次の行動を決めるための 中間表現 として使われています。

ここが重要です。
ロボット制御側から見ると、自然文で「青いブロックを取って」と言われるより、座標が返る ほうが扱いやすいからです。

2-2. Success detection がかなり実践的

ロボットは「どう動くか」以上に、終わったかどうかの判断 が難しいです。

たとえば「青いペンを黒いペン立てに入れる」というタスクでも、俯瞰カメラだけでは見えないことがあります。Gemini Robotics-ER 1.6 は複数カメラの関係を扱えるようになっていて、DeepMind の例では overhead view と wrist view を合わせて 完了判定 をしています。

これはかなり現場っぽい改善です。
動作生成はできても、「失敗したからリトライすべきか」「次の工程へ進んでよいか」を決められないと、自律性は伸びません。

2-3. Instrument reading はかなり実用を感じる

今回いちばん面白いのはここだと思います。

Gemini Robotics-ER 1.6 は、圧力計、液面計、デジタル表示 のような計器を読めます。DeepMind は Boston Dynamics との連携を通じて facility inspection の需要を挙げていて、Spot のようなロボットが撮った画像を解釈するユースケースを想定しています。

さらに、計器読み取りでは agentic vision を使います。
これは、モデルが必要に応じて画像をズームしたり、注目点を取ったり、コード実行で割合や間隔を計算したりする流れです。DeepMind の評価では、instrument reading は Gemini Robotics-ER 1.6 単体で 86%、agentic vision ありで 93% でした。


3. 実装フローは「検出 → 計画 → 実行 → 再確認」

実装の流れは、以下の形にすると理解しやすいです。

Robotics docs でも、まず 対象物の位置を取る → その後 custom robot API に合わせて手順を生成する、という流れが紹介されています。
例として出ているのも、blue block を orange bowl に入れるという、まさにこのパターンです。

この流れの良いところは、認識と制御を分離できる 点です。
モデルの出力をそのままモーターに流すのではなく、一度アプリ層で受けてから検証できます。


4. まずは最小構成で試す

公式 docs のサンプルをそのまま実装目線で読むと、最初に試すべきなのはこの3つです。

4-1. 物体の point を取る

最初はここからで十分です。
Robotics docs では、point は [y, x] の 0-1000 正規化座標 で返されます。物体検出のような空間理解タスクは、小さめの thinking budget でも高性能を出しやすいと説明されています。

from google import genai
from google.genai import types
import json

client = genai.Client()

with open("workspace.jpg", "rb") as f:
    image_bytes = f.read()

prompt = """
Get all points matching the following objects: blue block, orange bowl.
The answer should follow the json format:
[{"point": [y, x], "label": "..."}, ...]
The points are in [y, x] format normalized to 0-1000.
"""

response = client.models.generate_content(
    model="gemini-robotics-er-1.6-preview",
    contents=[
        types.Part.from_bytes(data=image_bytes, mime_type="image/jpeg"),
        prompt,
    ],
    config=types.GenerateContentConfig(
        temperature=0,
        thinking_config=types.ThinkingConfig(thinking_budget=0),
    ),
)

points = json.loads(response.text)
print(points)

このステップのポイントは、自然言語でタスクを渡しているのに、アプリ側では機械的に使える座標が手に入ることです。
あとはこの座標をピクセル座標やロボット座標系に変換すれば、既存制御系につなげられます。

4-2. 見えづらい対象は code execution を使う

小物や計器は、1発で読ませるより ズーム・切り出し を挟んだほうが安定します。
Robotics docs では code execution を使って zoom / crop / rotate を行う例があり、DeepMind の instrument reading でも同じ考え方が使われています。

from google import genai
from google.genai import types

client = genai.Client()

with open("meter.jpg", "rb") as f:
    image_bytes = f.read()

prompt = """
How full is the meter of liquid?
1) Find the points for the top of the sight window, bottom of the sight window,
   and the liquid level as [y, x] with values ranging from 0-1000;
2) Use math to determine the liquid level as a percentage;
3) Return JSON only:
{"level_percent": 0}
"""

response = client.models.generate_content(
    model="gemini-robotics-er-1.6-preview",
    contents=[
        types.Part.from_bytes(data=image_bytes, mime_type="image/jpeg"),
        prompt,
    ],
    config=types.GenerateContentConfig(
        temperature=0,
        tools=[types.Tool(code_execution=types.ToolCodeExecution)],
    ),
)

print(response.text)

ここで大事なのは、モデルが途中で画像処理と計算を挟めることです。
「見て答える」ではなく、「見やすい形に変換してから判断する」に変わるので、設備点検やメーター読み取りのようなユースケースと相性がいいです。

4-3. custom robot API につなぐ

Robotics docs では、位置検出のあとに mock robot API へ落とし込む例が紹介されています。これがかなり分かりやすいです。

def move(x, y, high):
    print(f"moving to coordinates: {x}, {y}, {15 if high else 5}")

def setGripperState(opened):
    print("Opening gripper" if opened else "Closing gripper")

def returnToOrigin():
    print("Returning to origin pose")

この API 仕様をモデルに渡して、実行プランを JSON で返させます。

prompt = f"""
You are a robotic arm with six degrees-of-freedom.

Available functions:
- move(x, y, high)
- setGripperState(opened)
- returnToOrigin()

Pick up the blue block at ({block_x}, {block_y})
and place it into the orange bowl at ({bowl_x}, {bowl_y}).

Return only JSON:
[
  {{"function": "move", "args": [0, 0, true]}},
  {{"function": "setGripperState", "args": [true]}}
]
"""

このやり方の良いところは、ロボット側の API を変えずに、上位判断だけモデルに任せられる点です。
なお、Gemini Robotics-ER 1.6 は function calling と structured outputs をサポートしているので、本番では free text を無理に parse するより、最終出力を厳密な JSON に固定する方が安全です。


5. 実装時に気をつけたいこと

最後に、エンジニア目線で大事な注意点だけまとめます。

  • モデルは Preview 扱い。
    API や挙動は変わる可能性があるので、production-critical な用途では十分な検証が必要です。
  • プロンプトは平易な自然言語のほうがよい。
    Robotics docs でも、専門用語より everyday terminology を勧めています。
  • 小さい対象は寄って見る。
    公式 docs でも zoom / crop を積極的に使う例が出ています。
  • thinking budget は精度と遅延のトレードオフ。
    物体検出は小さめ、数え上げや見積もりは大きめが向いています。
  • 人が映る運用ではプライバシー設計が必須。
    公式 docs では、通知と同意、face blurring などで個人データの収集を最小化するよう求めています。

そして、いちばん重要なのはここです。

モデルの出力をそのまま実行しないこと。

ワークスペース境界、衝突禁止領域、最大荷重、グリッパー制約、液体や危険物の扱いなどは、必ずアプリ側でチェックすべきです。DeepMind も、ER 1.6 は安全制約への追従が改善しており、「液体を扱わない」「重すぎる物は持たない」といった判断が向上したと述べていますが、それでも最終的な安全責任は実装側にあります。


まとめ

Gemini Robotics-ER 1.6 を実装目線で見ると、これは「ロボットを直接動かすモデル」ではなく、ロボットに状況判断を与えるモデル です。
特に今回のアップデートでは、pointing、multi-view success detection、instrument reading が実務に寄った形で伸びています。

最初に触るなら、この順番が分かりやすいです。

  1. point / bbox を返す最小例を動かす
  2. code execution 付きで小物や計器を読ませる
  3. custom robot API へ JSON プランをつなぐ
  4. 最後に success detection を入れる

この順で組むと、ロボットの 「見る・考える・確認する」 を段階的に実装できます。
ロボットが本当に役立つのは、器用に動けるときより、状況を理解して次を判断できるとき なのかもしれません。


参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?