この記事は、Google Cloud Next ’26 のセッションレポートです。

セッション情報

  • セッション名: Complex workflows simplified with Gemini Enterprise multi-agent systems
  • 登壇者:
    • Tomas Moreno 氏（Product Manager, Gemini Enterprise, Google Cloud）
    • Dr. Ali Arsanjani 氏（Director, Applied AI, Google Cloud）
    • Christian Heise 氏（Program Manager, Agentic AI, Bosch）
    • Drew Gillson 氏（CTO and co-founder, Gravity）

先に30秒でまとめ

  • 発表されたもの: Supply chain リスク管理のマルチエージェントシステムのライブデモ、Bosch の全社エージェント展開事例、Gravity の自律型 AI アナリスト「Orion」の Gemini Enterprise App 統合
  • 何が変わったか: マルチエージェントが概念実証を超えて本番稼働に移行しつつある / Bosch では月間3,500エージェントが生成される規模に到達 / Gemini Enterprise Marketplace 経由でサードパーティエージェントが企業全社にゼロ手間で展開できる
  • 具体的に何が嬉しいか: リスクマネージャーが Gemini Enterprise App 上でチャットするだけで、SAP Ariba・Moody’s・地政学情報を横断した分析と対策案が自動生成される
  • 一番強い主張 / 目玉: 「アジェンティック AI で最も ROI が高いのはサプライチェーン」という Dr. Arsanjani の断言
  • 印象的だった事例: Bosch の退職エンジニアが持つ暗黙知を NotebookLM に蓄積し、ワークフローエージェントと連携させた「知識継承」の取り組み

本編① Supply chain マルチエージェントシステム

マルチエージェントの構成とデモの流れ

エージェント AI の成熟度は6段階に整理できます。

レベル1が「固定ワークフローをこなすだけの単純なエージェント」、レベル6が「エージェント同士が互いに学習し合い、群知能として進化するシステム」です。今回のデモが実装しているのはレベル4〜5。複数の専門エージェントが並列で動き、さらにオーケストレーターが全体を統制する構成です。

以前なら、ある部品のサプライヤーに関税リスクが浮上したとき、リスクマネージャーはどうしていたか。調達担当者に SAP Ariba を調べてもらい、財務アナリストに Moody’s のレポートを取り寄せてもらい、地政学の専門家にニュースを当たってもらい、それらを統合して対策案を書いてもらい、法務に連絡文書を作ってもらう——それぞれの担当者に依頼して、情報が出揃うまでに何日もかかる、という話です。

このデモでは、その全工程をリスクマネージャーの Sarah がチャット1本で完結させます。

Sarah が「この電子部品サプライヤーについて、今何かリスクはあるか」と Gemini Enterprise App に入力すると、裏側では Risk orchestrator agent が動き出します。地政学・ニュースを監視するエージェントが対象国への新関税を即座に検出し、SAP Ariba に接続するエージェントが既存契約の条件と期限を照合し、Moody’s に接続するエージェントがそのサプライヤーの財務健全性を評価します。それらの情報を統合・分析するエージェントがリスクの全体像をまとめ、最後に対策立案エージェントが代替サプライヤー候補2社とその調達タイムラインを添えた法務向け覚書を生成します。

Sarah の画面に戻ってくるのは、「このサプライヤーは単一調達リスク・新関税・財務脆弱性の三重リスクを抱えている。代替候補はA社とB社で、それぞれの認定に要する期間と財務インパクトはこのとおり」という、判断に直結するアウトプットです。

この一連の流れはすべて Gemini Enterprise App のチャット画面の中で完結します。エージェント間のやりとりは A2A プロトコルで処理されており、Sarah はどのエージェントがどう動いているかを意識する必要はありません。ADK で構築された各エージェントが Gemini Enterprise App に登録されていれば、こういったシステムを誰でも使える状態にできる——それがこのデモの核心です。

本編② Bosch の全社展開

月3,500エージェント、その規模感をどう受け取るか

セッション冒頭、会場の参加者全員がバッジを隣の人に見せるよう促されました。数百人がバッジを見せ合ったところで、「今見えた人数が、Bosch で先月1か月間に生成されたエージェント数の5分の1くらいです」という話が出ました。

月間3,500エージェント。しかも、これは IT 部門が作ったものではありません。コードを一行も書かない普通の社員が、自分の業務に合わせたエージェントを Gemini Enterprise App 上でどんどん作り出している数字です。

Bosch がここに至るまでの経緯は比較的シンプルです。2024年夏に30以上のユースケースを1,700名で検証する POC フェーズを終え、同年11月に Early adopter フェーズ、2025年1月に全社グローバルロールアウト。「AskBosch」という社内ブランドで展開し、展開スピードは速かったです。

一方で、Bosch がこの展開で一番気を遣っているのは「速さとコントロールのバランス」だと Christian は言います。トップのリーダーシップが強力にスポンサーしているから速く動けます。でも数千の社内システムとのコネクター整備はそれぞれのシステム担当者との合意が必要で、EU AI Act に対応したリリース手順の整備も必要です。どちらかに偏ると破綻する、というのが実感として語られていました。

3種類のエージェントと、知識継承の話

Bosch ではエージェントを用途によって大きく3つに分けています。

一つ目は「Bandage agent」と呼ばれるもので、要するに GA 版の Gemini Enterprise App だけでは対応できない社内システムへの橋渡し役です。コネクターが存在しないオンプレシステムに対して、ADK でカスタムエージェントを作り、ユーザーのロールを既存システムの権限にマッピングしてコンテンツを提供します。ガムテープで貼り合わせるような役割なので「Bandage」という名前がついています。

二つ目が「Simple workflow agent」で、代表例は社員研修のカリキュラム個別化です。AI リテラシーの習熟度は人によってまったく違うので、従来の画一的な HR 研修では合わない人が出てしまいます。このエージェントは社員と対話しながらスキルレベルや既存知識を把握し、その人だけのカリキュラムを生成します。

そして三つ目が「Complex workflow agent」で、ここで出てきたエピソードが印象的でした。Bosch には長年勤めてきたベテラン設備エンジニアが少なくありません。そういった人が退職するとき、若い社員たちが退職前にインタビューを実施します。音声の会話やメモ、現場の動画——それらをすべて NotebookLM に投入し、「その人の名前がついたエキスパートノートブック」を作るわけです。引退したエンジニアの知識が、会社のシステムの中で生き続ける。今はすでにトラブルシューティングの参照資料として機能していて、これをインシデント管理やカスタマーサポートのワークフローに組み込んでいけば、さらに大きな価値が生まれると Bosch は見ています。

こうした事例を見て Christian が整理したのは、No-code と ADK の役割の違いです。No-code エージェントは「全社員が使い始める」という導入の火付け役で、ADK エージェントは「そのエコシステム全体の価値を底上げする」ための手段です。まず No-code で広げて、価値が見えてきたところで ADK に転換して深める——この順番が大規模展開では効いていると言います。

本編③ Gravity/Orion のエコシステム統合

Orion とは何か

Orion を一言で言うと、「あなたが何も聞かなくても、勝手にデータを見て、問題を見つけて、対処の選択肢を持ってくる」AI アナリストです。

もう少し具体的に言うと、Orion はユーザーのロール・担当領域・ビジネス目標を把握したうえで、そのユーザーが見るべき企業データを 24/7 で監視し続けます。異常を検知したり、重要なトレンドを見つけたりしたとき、Orion はプロアクティブにそれを報告し、「こういう選択肢があります、どうしますか」と聞いてきます。

従来の BI ツールは「聞かれたことに答える」ものでした。Orion は「聞く前に教えてくれる」ものです。しかも Chat でも Slack でも、そして今回新たに Gemini Enterprise App でも動くので、社員はツールを切り替えなくていい。これが設計の核心にあります。

ADK か A2A か、どちらで統合するか

Gemini Enterprise App に統合するとき、実は選択肢は2つあります。Drew はどちらも試したうえで、それぞれの意味をこう整理しました。

ADK パスは「ゼロから作る」パスです。Google のツールや可観測性機能、デプロイオプションがすぐに使えるので、プロトタイプを速く高品質に仕上げられます。既存システムへのしがらみがないなら、これで本番まで持っていける、と Drew は言います。

A2A プロトコルパスは「既存のシステムをそのまま接続する」パスです。Gravity はすでに2年間かけて Orion のサービング基盤・テナントモデル・セキュリティ境界を作り込んでいました。それを ADK で作り直すより、A2A プロトコルと OAuth 登録フローを実装して接続する方が現実的だったわけです。

どちらを選んでも、最終的に Gemini Enterprise App 上では同じように Google のエージェントと並んで表示されます。「自社に既存のシステムがあるか、ないか」で選べばいい、というメッセージは、パートナー企業にとって分かりやすい判断軸だと思います。

統合で得られた4つの成果と、その先に見えるもの

Orion は Google Cloud Marketplace に登録されており、Gemini Enterprise を展開した企業はそのまま Orion を追加できます。インストールの手間はゼロです。これが Distribution の話で、Drew が「Enterprise AI は少数の主要プラットフォームに収れんしていく」と言う根拠でもあります。Gravity のような外部のソフトウェアベンダーにとって、そのプラットフォームに乗ることは、企業全社の社員に直接届く最短経路になるわけです。

さらに Gemini Enterprise App への掲載には Trust の効果もあります。Google 自身のエージェントと同列に並ぶことで、調達担当者の心理的ハードルが下がるのは現実として大きいです。そしてプロトタイプから実際の企業（スポーツブランドの On Running）が本番で試用するまでにかかった期間は数週間だったと Drew は明かしました。

もう一つ Drew が強調したのが Composability です。A2A 対応のおかげで Orion は他のエージェントと連携できます。先のサプライチェーンデモでも、Orion をサプライヤーデータの接続レイヤーとして組み込むことが技術的に可能で、「Orion が持っているデータを他のエージェントが使える」という構成がそのまま成立します。

Gravity が次に目指すのは、チャットの先にある「成果物の生成」です。会話でインサイトを伝えるだけでなく、エージェントがカレンダーを確認して顧客向けの QBR スライドを自動作成し、意思決定の選択肢を画面に並べて提示する。そこまで来て初めて「本当に自律的なアナリスト」と言えると Drew は語りました。A2UI パッケージなどを通じた Google との協業でその世界を作っていくというのが、Gravity の今後のビジョンです。

おわりに

Gravity/Orionの話で一番印象に残ったのは、ADKかA2Aかという技術の選択より、「Gemini Enterpriseを入れた企業にはOrionがゼロ手間で届く」という流通の仕組みです。プラットフォームに乗ることが配布コストをほぼゼロにする構造は、エージェントを作る側にとっても早めに考えておく価値があります。

もう一つ気になったのは、このセッション全体を通じて「複雑さの置き場所が変わっている」という点です。SarahがSAP AribaもMoody’sも意識せずにチャット1本で答えを得られるのは、複雑さがなくなったのではなく、マルチエージェントが裏側に吸収しているからです。エンジニアの仕事がなくなるというより、システム連携の複雑さをどこに隠すかの設計が、これからの開発の核心になっていく気がします。