はじめに

こんにちは、KDDIアイレット株式会社の伊藤です。
2026年7月30日にGoogle Cloud Next Tokyo ’26に参加してきました。

本記事では、住友重機械工業のセッション「生成 AI と Google Cloud で実現する、製造業 DX と SDV のためのロボット開発基盤構築」についてレポートします。

私は普段、次のような業務に携わっています。

  • サポートデスク向け AI チャットボット/ AI エージェントの構築・運用（Google Cloud）
  • 問い合わせ対応ナレッジを自動で蓄積する仕組みづくり
  • 事業部内の生成 AI 推進（ガイドライン整備・利用環境づくり）

製造業×ロボティクスというと完全に畑違いなのですが、実際に聞いてみると「同じ課題を別の角度から解いている」と感じる場面が多いセッションでした。

本記事は、セッションの網羅的な解説ではなく、そうした「自分の業務に引き寄せて刺さった点」を中心にお届けします。

セッション概要

登壇したのは、フォークリフトなどの産業機械を手がける住友重機械工業です。
セッションの内容を「課題 → 解決策 → どうなったか」の順に整理します。

課題

背景にあるのは、物流・搬送現場の労働者不足です。これに応えるために、機械を「売って終わり」の製品ではなく、出荷後もソフトウェア更新で進化し続ける製品——いわゆる SDV（Software Defined Vehicle）——へ変えていく必要がありました。

ただ、その開発には難しさがあります。題材となった SDV 検証用の自動フォークリフトでは、専門分野の異なる 2 種類のエンジニアが開発に関わります。

  • ロボットエンジニア: 「どこへどう動くか」という行動計画など、フォークリフトの頭脳にあたる部分を担当（主に ROS 2 を使用）
  • 制御エンジニア: 決めた経路を正確にたどる、フォークを思いどおりに動かすといった制御アルゴリズムを担当（主に MATLAB を使用）

使う道具も文化も違うメンバーが、1 台しかない実機を共有して開発しなければならない。当然、実機での実験も気軽にはできません。

解決策

この課題に対して、生成 AI（Gemini CLI）と Google Cloud で開発基盤を構築しました。大きく 4 つの役割で構成されています。

  • 開発環境: クラウド上の開発環境（Cloud Workstations）に AI アシスタント（Gemini CLI）を組み込み、全員が同じ環境で開発可能に。
  • CI/CD: コードのビルドやテストを自動化（GitLab + Cloud Build + Artifact Registry）
  • デジタルツイン: 実機の代わりに動かせるシミュレータや、車載コンピュータを模した仮想 ECU をクラウド上（GKE）に用意
  • データ分析: 実験データを蓄積・分析（Cloud Storage + BigQuery）

実機に触れる機会が限られるぶん、手前のシミュレーション（デジタルツイン）で徹底的に検証しきる進め方です。

どうなったか

シミュレーションで検証を重ねたうえで臨んだ 1 回目の実機実験で、パレットの検出から取得まで問題なく動作したとのこと。この「実機で気軽に試せないから、手前で検証しきる」という感覚は、運用の世界の「本番環境では気軽に試せない」とまったく同じ構造です。分野は違っても、制約の乗り越え方には共通の型があるのだと感じました。

ここからは、私が特に刺さった 3 点に絞って書きます。

1: KAI — ナレッジは「人の善意」ではなく「仕組み」で貯める

一番共感したのが、KAI（Knowledge & AI）と呼ばれる仕組みです。エラーログをキーとした解決策の自動蓄積・検索システムで、Cloud Workstations 上の Gemini CLI が MCP サーバー（Cloud Run）経由で BigQuery のエラーログ DB とやり取りします。

  • 登録: エラーを解決すると、AI がその内容をベクトル検索で類似エラーと突き合わせ、新規登録またはマージ
  • 検索: 誰かが同じエラーに当たると、AI が過去の解決策を引いてくる

私自身、問い合わせ対応のナレッジを AI で自動生成・蓄積する仕組みを作っているのですが、この種の取り組みは必ず同じ壁にぶつかります。「ナレッジが重要なことはみんな分かっているのに、書く時間がなくて貯まらない」——解決した本人が一番忙しく、記録する動機も薄いという構造的な問題です。

KAI のポイントは、「AI がエラーを解決したその場で、AI が登録まで済ませる」ことで、人間の善意に依存しない設計にした点です。さらに登録時に類似エラーを検索して、新規かマージかを判断させている。ナレッジ蓄積を自動化すると今度は重複と散らかりに悩まされるのですが、そこも同じ結論に至っていて、共通の課題意識を感じました。

応用の観点でも考えが広がります。運用の現場では、アラートの一次調査で「過去に誰かが同じエラーを調べている」ケースが非常に多い。調査ログをキーに解決策が自動で貯まる仕組みがあれば、一次調査の質とスピードは確実に上がります。開発者向けの仕組みとして紹介されていましたが、運用・サポートの現場にこそ効く発想だと思いました。

2: グラフ RAG — AI に「社内の文脈」を理解させる

2 つ目はグラフ RAG です。仕組みは次のとおりです。

  • コードとドキュメントを Spanner 上でグラフ DB 化
  • セマンティック検索 × グラフ探索の複合検索
  • 複数リポジトリ間の依存関係もバッチ処理でリンク
  • グラフ生成は CI/CD パイプラインに組み込み

これにより、AI が内製ライブラリの仕様を理解できるようになります。

RAG を実運用したことがある方なら共感いただけると思うのですが、ベクトル検索だけでやれることには限界があります。文書単体は引けても、「このライブラリはどこから参照されているのか」「この手順の前提になっている構成はどれか」といった関係の知識が拾えない。コーディングエージェントが公開ライブラリには強いのに、社内の内製ライブラリでは急に頼りなくなるのも、この「社内の文脈」を持っていないからです。

もうひとつ注目したのは、グラフ生成を CI/CD に組み込んでいる点です。ナレッジ基盤は作った瞬間から陳腐化が始まるので、更新を人のタスクにした時点で負けが見えています。コードが変わればグラフも自動で追随する構造にしてあるのは、KAI と同じ「人に依存しない」思想で一貫しています。

私の周りでも、手順書や構成情報は相互参照だらけで、「あのドキュメントの前提はどこに書いてあるのか」を探す時間が地味に長い。ドキュメント間の参照関係をグラフ化して検索に効かせるアプローチは、運用ドキュメントの世界でもそのまま試す価値がありそうです。

3: ガードレールの内側の自由 — 人材育成の設計

3 つ目は技術というより組織の話です。「クラウド未経験の新入社員を 1 年でどう育てたか」というテーマで、3 つの要素が重要だと語られました。

  • 安全な、セキュリティガードレール（組織ポリシー・IAM）
  • 自由な、プレイグラウンド・AI サポート（Cloud Workstations のセキュアコンテナ + Gemini）
  • 失敗しやすい、サンドボックス（学習は Google Skills Boost で支援）

生成 AI 推進の仕事をしていると、「自由にやらせたい、でも事故は困る」という綱引きに常に悩みます。ルール文書を分厚くして縛る方向に行きがちですが、それは「仕組み化されていない重厚なルール」としてセッション内でも導入前の悩みに挙げられていました。

ルールで縛るのではなく、ガードレールを仕組みとして敷いた内側では自由にさせる。私たちも AI ツールの利用ポリシーを管理設定として配る形を取っており、目指す方向は同じだと再確認できました。

特に良いと思ったのは、「失敗しやすい」をわざわざ 3 要素のひとつに挙げていることです。安全に失敗できる場所がないと、人は挑戦しなくなる。終了時に自動クリーンアップされる Cloud Workstations は、まさに「壊しても戻る」環境で、これが未経験者を 1 年で戦力化した土台なのだと納得しました。

まとめ

このセッションの核心は、「生成 AI でコーディングが速くなった」ではなく、開発基盤・ナレッジ・組織・人材育成を一体で設計していることでした。畑違いのはずの私にも、持ち帰れるものが多くありました。

  1. ナレッジは人の善意ではなく、AI が解決したその場で登録する「仕組み」で貯める
  2. AI に社内知識を理解させる投資は、CI/CD に組み込んで自動で鮮度を保つ
  3. ルールで縛らず、ガードレールの内側に「安全に失敗できる自由」を用意する

どれもロボット開発固有の話ではなく、運用・サポートの現場にもそのまま効く原則です。自分と違う業界のセッションには、課題の共通構造が見える面白さがある——そう実感した時間でした。

最後までお読みいただきありがとうございました。