「ホワイトボードに手書きで書いたto-doリストを、Spotが読んでそのまま実行した。」

4足歩行ロボットのSpotが、リビングで靴を靴箱に入れ、空の缶を片付ける映像が3月に公開された。実証デモそのものより興味深いのは、その背後にある仕組みだ。エンジニアが書いたコードは「自然言語プロンプト」のひとまとまりだけで、作業の順序・失敗処理・リトライはすべてGemini Roboticsが判断した。

これは何?

Boston DynamicsとGoogle DeepMindが組んで作った2つの成果物が、1か月のうちに相次いで発表された。

(1) 「To Do List with Spot」 — 家庭環境で自然言語の指示により清掃を行う実験的なデモ。Gemini Robotics-ER 1.5がSpotのSDKを呼び出してタスクをオーケストレーション。(2) AIVI-Learning（商用製品） — SpotのAIVI（産業用ビジョン検査機能）にGemini Robotics-ER 1.6が統合された正式リリース。2026年4月8日、すべてのAIVIユーザーに自動で有効化。

一言でまとめると、ロボットの動かし方が「コードを書く」から「自然言語で指示する」へと移行しつつある。しかもデモの話ではなく、実際の産業現場でだ。

  • 計器盤の認識精度 23% → 98%
    Gemini Robotics-ER 1.5から1.6 + agentic visionに移行するとこれだけ跳ね上がる。比較：Gemini 3.0 Flash単体では67%。
  • 「ステートマシンのコード」を書く時間 → 自然言語プロンプトを書く時間
    各ステップをコードで定義する方式から、自然言語でツールの用途を説明すればLLMが自動でシーケンスを組み立てる方式へ。
  • 現場のユーザーが「なぜそう判断したか」を確認できるようになった（Transparent Reasoning）
    AIVIが検査結果を返すだけでなく、推論プロセスを開示するように。安全・規制産業にとって欠かせない変化。
  • Zero-Downtime Upgrades（無停止アップデート）
    モデルはクラウドで自動更新。ファームウェアのアップデートやダウンタイムなしに検査精度が自動で向上する。

コードを書かずに、どうやってロボットを動かすのか?

従来のロボットプログラミングは「ステートマシン」方式だ。移動→カメラ起動→物体認識→グリップ→移動→置く、という各ステップを、分岐処理・失敗処理・リトライまで含めてコードで書く。環境が変われば、コードも書き直す。

Boston Dynamicsのチームがやったことは違う。SDKの上に「ツール（tool）レイヤー」を作り、各ツールが何をするかを自然言語プロンプトで説明した。たとえば「TakePicture」ツールのプロンプトはこのように書かれている。

「このコマンドは指定されたカメラで写真を撮る。カメラの選択には微妙なニュアンスがある。GoToで到着した直後は、必ずグリッパーカメラから撮影すること — 最も情報量が多い。もしロボットがすでに何かを持っている場合は、(1) PutDownをすぐに呼び出すか、(2) 前面カメラでエリアを探索する。ただし前面カメラは低い位置にあるため、高い場所にある物を撮影するには不向きだ。」

これはコードではない。ロボットのハードウェアが持つ物理的な制約を自然言語で説明したものだ。そしてこれが機能する。デモ当日、ホワイトボードに手書きされたto-doリストをSpotがカメラで読み取り、項目ごとにツールを呼び出して最後まで処理した。

現場で報告されている変化は以下のとおりだ。

指標 従来（コード型自動化） Spot × Gemini Robotics
新しいタスクの追加 ステートマシンのコードを作成・テスト・デプロイ 自然言語プロンプトを追加して即座に実演
計器盤の認識精度 従来のビジョンモデル / Gemini Robotics-ER 1.5：23% Gemini Robotics-ER 1.6 + agentic vision：98%
モデルの更新 ロボットのファームウェア更新＋ダウンタイムが必要 Zero-Downtime、クラウドで自動反映
判断根拠の確認 ブラックボックス Transparent Reasoning（推論ステップの開示）
失敗時の処理 例外処理コードを人が全て記述 ツールが自然言語で応答（「手がふさがっているので掴めません」）→ LLMが再計画

最後の行が肝心だ。ツールが結果を自然言語の文で返すと — 「物を掴みました」「手がふさがっているので掴めません」 — Gemini Roboticsがそれを見て次のステップを再考する。例外ケースを人があらかじめ全てコーディングしなくてもよいというのが、本当の変化だ。

では、産業現場では何が変わったのか?

家庭用の清掃デモが興味深いのは「珍しいから」ではない。同じ仕組みが産業現場（AIVI-Learning）にそのまま適用されているからだ。

Spotは自動車工場・発電所・物流センターで定期点検の任務を担う。1回の巡回で点検する設備は数百件に上る — ゲージ（アナログ圧力計・温度計）、サイトグラス（タンク内の液体水位）、コンベアベルトの損傷、油漏れの痕跡、5S整理の状態など。これを正確に読み取るには、単純な物体認識ではなく「複雑な視覚的推論」が必要になる。

点検項目 従来 Gemini Robotics-ER 1.6統合後
アナログゲージ / サイトグラスの0〜100%測定 物体認識のみ可能、数値は読み取れない 正確な数値の抽出が可能
5Sコンプライアンス監査 人が直接点検 自動化（マルチシフト人員を代替）
パレットカウント 手作業 / 別途ビジョンシステム AIVIが直接処理
水たまり・無許可人員の検知 定期的な人員巡回 Site View通知（次回リリース）
モデルの更新 現場のダウンタイムが必要 クラウド自動更新、ダウンタイム0

とりわけ計器盤の認識精度のジャンプ — 23% → 98% — が意味するのは、単純な数値の改善ではない。ここまで来て初めて、「人が毎回確認しなくていい」自動点検が現実のものになる。23%なら人が付き添う必要がある。98%なら人は例外だけを見ればいい。

もう一つ注目すべき違いがある。「agentic vision」という新しい概念だ。モデルが画像を一度見て答えるのではなく、画像に点を打ったり領域を切り取ったり見直したりする「scratchpad」的な動作を通じて、段階的に推論する。人間が時計の針を正確に読もうと近づいて見直す行動を、モデルが再現しているのに近い。

企業として押さえるべき4つの視点

SpotはすでにHyundai Motor Group系列をはじめ、自動車・重工業・物流の現場に導入が進んでいる（Boston DynamicsはHyundai Motor Group傘下）。決して遠い話ではないのだ。ロボット導入の意思決定が「コード外注コスト」から「プロンプト運用力」へと移っていく可能性がある。

  1. ステップ1: ロボットワークフロー設計者の役割が変わる
    「各ステップをどうコード化するか」ではなく、「どんなツールを作ってLLMに自由に組み合わせさせるか」へ。ツールの入力・出力・エラーメッセージを自然言語でうまく設計する能力が、ロボット運用力そのものになる。
  2. ステップ2: 点検結果の「推論ログ」を残す
    Transparent Reasoningが有効になると、点検のたびにLLMの判断根拠が記録される。産業安全規制（労働安全衛生法など）において「なぜそう判断したか」の根拠が求められる場面で、このログが重要な証拠となる。
  3. ステップ3: クラウドモデルへの依存度を明示的に評価する
    Zero-Downtime Upgradeは便利だが、モデルが自動で切り替わるということでもある。発電所・半導体ファブのように変更管理（MoC）が厳格な産業では、「今日検査したモデル」と「明日検査したモデル」が異なる可能性があることを、運用手順に織り込む必要がある。
  4. ステップ4: データ共有の利用規約を確認する
    AIVI-Learningを利用する際は、施設データをBoston Dynamicsと共有する必要がある（BD内部利用に限定）。自社の産業機密（半導体プロセス・発電所図面など）が学習データとして使われてよいか、法務・セキュリティの観点から必ず検討が必要だ。

始め方のポイント

  1. ステップ1: 「コード型自動化」を自然言語プロンプト＋ツールレイヤーで再解釈する
    ロボット/RPAのワークフローを持つ会社は、既存のステートマシンのロジックを「ツール単位」に分解し、各ツールの用途・制約・失敗パターンを自然言語で書き出してみる。このプロセス自体が、LLMベースの自動化導入への第一歩になる。
  2. ステップ2: 精度のベースラインを「人が付き添える」水準で設定する
    Gemini Robotics-ER 1.6の98%のような数値が意思決定の閾値になる。80%以下は人が毎回確認する必要があり、ROIが出ない。95%以上が達成できる領域から適用候補として検討する。
  3. ステップ3: Transparent Reasoningを運用ログとして活用する
    点検自動化を導入する際は「結果だけ」もらうのではなく、推論プロセスも一緒に保存する。事故発生時の原因分析・規制対応の根拠になる。
  4. ステップ4: モデルの自動更新ポリシーを運用手順に反映する
    Zero-Downtimeは便利だが、安全が重要な産業では「どのモデルバージョンが検査を実行したか」が追跡できる必要がある。運用手順にモデルバージョンの記録を追加する。
  5. ステップ5: データ共有可能な領域と隔離すべき領域を分ける
    すべての検査データを外部の学習に送るわけにはいかない。一般的な安全点検（汎用）と固有の機密情報（プロセス・図面）は、別々のワークフローで運用する。

さらに深掘りしたい人へ

Boston Dynamics — Tools for Your To Do List with Spot and Gemini Robotics 家庭用清掃デモの内部構造を、BDのエンジニア自身が解説した記事。ツールプロンプトの実際の例、SDK統合の方法、限界についても詳しくまとめられている bostondynamics.com

Ars Technica — Robot dogs now read gauges and thermometers using Google Gemini Gemini Robotics-ER 1.6の性能ジャンプ（23%→98%）とagentic visionの概念を、専門知識がなくても読めるように解説した分析記事。安全モデルの変化についてもまとめられている arstechnica.com

The Robot Report — BD and Google DeepMind use Gemini to make Spot smarter AIVI-Learningの商用リリース発表のまとめ。Zero-Downtime Upgrade・Transparent Reasoning・各種アセット対応の拡張が1ページで把握できる therobotreport.com