【Google Cloud Next Tokyo 26】実機でしかできないことに集中する – 住友重機械工業が示したロボット開発の工程の切り分け方

Google Cloud Next Tokyo 26（2026年7月30日 – 31日、東京ビッグサイト）で聴講した、カスタマーセッション「生成 AI と Google Cloud で実現する、製造業 DX と SDV のためのロボット開発基盤構築」のレポートです。

ハードウェアを伴う開発では、実機の数がそのまま開発速度の制約になり得ます。
住友重機械工業では、自動フォークリフトの自律化機能を開発するにあたり、シミュレーションやビルド、データ分析などをGoogle Cloud上に集約していました。
そのうえで、実機には実機でなければ確認できない作業だけを残しています。
この記事では、その工程の切り分けを中心にセッション内容を整理します。

なお、本記事に掲載しているスライド写真は、いずれも私が会場で撮影したものです。

セッション情報

30分のセッションでは、SDV という言葉の整理、開発基盤のアーキテクチャ、自動フォークリフトを題材にした開発の進め方、人材開発・組織開発が扱われました。
この記事では、そのうち開発基盤と実験工程に焦点を絞ります。

結論から

開発基盤の狙いを示していたのが、この1枚です。

Google Cloud 上の開発プラットフォームによって
ハードウェアを伴う開発工程全体を加速させる

挙げられていた要素は3つです。

このなかで、私が特に気になったのはシミュレータの使い方でした。
別のスライドでは、実機実験について「実機を使用しないと実施できない作業（パラメータ調整など）に専念」と説明されています。

つまり、シミュレータは実機を不要にするためのものではありません。
実機で確認する項目を事前に絞り込み、限られた実機の時間を、本当に実機が必要な作業へ回すためのものです。

この工程設計が、今回のセッションで最も参考になった部分でした。

前提：SDV とは何か

「ハードウェアの性能」で決まる時代から
「ソフトウェアの知能」で進化し続ける時代へ

スライドでは、スマートフォン、自動車、物流・建設機械の3つが並べられていました。

ソフトウェア更新によって出荷後も機能が増えていく。その対象が、スマートフォンや自動車だけでなく、物流機械や建設機械にも広がりつつあります。

出荷後も継続して機能を改善するのであれば、メーカー側にも継続的なソフトウェア開発と運用の仕組みが必要です。
今回の開発基盤は、その前提から設計されていました。

何を作っていたのか：SDV 検証用の自動フォークリフト

題材は AGF（自動フォークリフト）です。
目的として3つ挙がっていました。

• フォークリフト自動化機能の内製開発
• OTA などの SDV 機能検証
• クラウド開発環境の効果実証

ここで重要なのは、AGFが単なる機能開発の対象ではなく、クラウド開発環境そのものを検証するための実証環境でもあることです。

制約：技術背景の違うメンバーが、実機1台を共有している

技術背景の異なるメンバーで構成されたチーム
最終的な実験は共通の実機 AGF で行う

開発体制は、次のように分かれていました。

ロボットエンジニアと制御エンジニアでは、扱う技術も担当領域も異なります。
しかし、最終的な検証先は同じ1台のAGFです。
ここでは、実機そのものが共有資源になります。
複数の機能を並行して開発できても、実機検証の段階では順番や調整が必要になります。

その制約を前提として、実機に持ち込む前の工程をどこまでクラウド上で済ませられるかが設計されていました。

4つの工程のうち、どこをクラウドで担ったか

新機能開発の流れは、横一本の時間軸に4工程を並べる形で示されていました。

重要なのは、実機実験の前にシミュレーション実験を独立した工程として置いていることです。

実機を使う前に確認できるものは確認しておき、実機では環境差や物理特性、パラメータなど実物でなければ分からない点を詰める。

実機の利用時間を増やすのではなく実機で確認する内容を減らす設計です。

シミュレータでの動作確認

アルゴリズムなどに問題が無いかクラウド上で確認

画面には、倉庫内を走行するフォークリフトの3Dビュー、操作画面、地図と経路の表示が並んでいました。

実機では、安全確認や場所の確保、作業者の立ち会いが必要です。一方、クラウド上のシミュレータであれば、同じ制約を受けずに繰り返し試せます。

後述するアーキテクチャでは、これらのシミュレータがGoogle Kubernetes Engine上に配置されていました。

実機に残されたのは「実機を使用しないと実施できない作業」

実機での実験を扱った検証動画のスライドには、こう書かれていました。

1回目の実機実験でパレットの検出から取得まで問題なく動作

検証動画には青いAGFが床のパレットへ近づく様子と、AGF側の視点からパレットを捉えた画面が映っていました。

ただし、この結果は限定して読む必要があります。
示されているのは、パレットの検出から取得までの機能が、1回目の実機実験で動作したという事実です。
すべての機能が初回で成功することを示すものではありません。

ですが、事前にシミュレーションで確認し、実機では最終的な差分を確かめるという工程が具体的な形で示されていました。

支える基盤：シミュレータもクラウドの中にある

全体アーキテクチャは4つのブロックでできていました。

Artifact Registryからは、製品ハードウェアとデジタルツイン側の仮想ECUの両方へDockerイメージが配布されます。
さらに、仮想ECUと製品ハードウェアの双方から、実験データがCloud Storageへ集約される構成になっていました。

シミュレーションと実機を別系統の仕組みにせず、同じイメージ配布とデータ収集の流れに乗せている点が特徴です。

CI/CD だけを取り出したスライドもありました。

自動化ワークフローを CI テンプレートとして一括で管理

マルチ アーキテクチャ ビルドや内製システムとの連携を標準化

図には、次の処理が含まれています。

• AMD64／ARM64向けのDockerビルド
• Aptパッケージのビルド
• グラフDBの作成
• リポジトリ間のグラフリンク

CI/CD管理システムでは、AMD64とARM64の両方に対応したDockerビルドが構成されていました。異なるCPUアーキテクチャ向けのビルドを個々の開発者に任せるのではなく、CI/CDのワークフローとして一括管理することで、マルチアーキテクチャビルドを標準化しています。

おわりに

チームの変化を示すスライドもありました。

サイロ化した個人開発からシナジーを生むチーム開発へ

単にシミュレータをクラウドへ移しただけではありません。
開発環境、ソースコード、ビルド、実験データを共通の基盤へ集めたことで、個別に進めていた開発を統合しながら検証できる形へ変えています。

30分のセッションで学びになったのは、次の3点です。

1. 体制は「技術背景の異なるメンバーで構成されたチーム」で、「チームで1台の実機を共有」している – 実機での実験を同時に走らせにくくする条件だと考えています
2. 工程では、実機実験の前にシミュレーション実験が置かれている – 「可能な限りシミュレータで動作確認を済ませておくことが重要」、実機実験は「実機を使用しないと実施できない作業（パラメータ調整など）に専念」。実機の順番待ちを短くするのではなく、実機に持ち込む用件を減らす設計に見えます
3. シミュレータ群は Google Kubernetes Engine 上にあり、実機と同じ Artifact Registry から配られている – 実験データも同じ Cloud Storage に集まる描き方でした

私が普段扱っているのは、クラウド上で完結するソフトウェア開発です。それでも、この考え方はそのまま応用できそうです。
まず、並列化できない資源がどこにあるかを見つける。そして、その資源を使う前に済ませられる検証や処理を手前の工程へ移す。

今回の事例では、それが1台の実機とクラウド上のシミュレータでした。
ソフトウェア開発であれば、共有検証環境や本番に近いステージング環境、特定のレビュー担当者などが同じ位置に来るかもしれません。

限られた資源を増やす前に、そこへ持ち込む仕事を減らせないかを考える。
その順番は、ハードウェアの有無にかかわらず使えそうです。