「Google Cloud Next '26」現地レポート 第1回

エージェントを“使う”から“管理する”に変える「Gemini Enterprise Agent Platform」

AIエージェントだけで“1万人参加のマラソンイベント”を計画せよ ― Google Cloudが年次イベントでデモ

　Google Cloudは、2026年4月22日から24日まで、米ラスベガスで「Google Cloud Next '26」を開催した。Geminiの普及を背景に、AIエージェント時代の本格到来を見据えて発表されたのが「Gemini Enterprise Agent Platform」だ。自律的に動くAIエージェントを構築し、企業システムへ組み込み、運用するための包括的なプラットフォームとなる。

　2日目の基調講演では、ラスベガスでマラソン大会を企画・シミュレーションするというユニークなデモを通じて、実際に同基盤でマルチエージェントシステムを構築する様子が披露された。

Google Cloud Next '26

AIエージェントを「作る・動かす・守る」ための基盤

　Google Cloudが発表したGemini Enterprise Agent Platformは、これまで提供してきたAI開発基盤Vertex AIを進化させた、AIエージェント時代の統合開発基盤である。

　Vertex AIが備えていた生成AIやMLモデル、AIアプリケーションの構築・デプロイ・拡張のための機能に、エージェントの構築・管理に必要な機能を統合。CEOのトーマス・クリアン（Thomas Kurian）氏は、「GoogleのAIをすべての従業員、すべてのワークフローが活用できるよう、新たな段階に進めるための基盤」と位置付ける。

Gemini Enterprise Agent Platform

　Google Cloud Platformプレジデントのブラッド・カルダー（Brad Calder）氏は、同基盤は「構築」「実行・スケール」「ガバナンス」「観測・最適化」の4つの要素で構成されていると説明する。

構築：Agent Development Kit（ADK）

　エージェントの開発基盤となるのがADKだ。「スキル」と「ツール」を組み合わせてエージェントの能力を定義する。MCP（Model Context Protocol）ともシームレスに連携して、外部のツールやデータソースとの接続を可能にする。

　なお今回、すべてのGoogle CloudサービスがデフォルトでMCPに対応したことも発表された。

実行・スケール：Agent Runtime

　エージェントを実際に動かすサーバーレスの実行環境であり、デプロイ・管理・スケーリングのための一連の機能を備える。

　「セッション」機能は、ユーザーとの会話状態を継続的に保持し、「メモリ」機能は、ユーザーの過去の行動や好みを記憶させることが可能だ。ステートレスな1回限りの応答ではなく、長期にわたり業務フローを支えるエージェントを構築するための基盤になる。

ガバナンス：Agent Identity、Agent Gateway、Agent Registry

　エージェントのセキュリティと管理を担う3つのコンポーネントが用意されている。

　「Agent Identity」では、デプロイ時に自動発行される固有の認証情報によって、IAMポリシーをエージェント単位で適用できる。「Agent Gateway」は、すべてのエージェントの通信を中継するプロキシで、インバウンド・アウトバウンドのポリシーを一元管理する。「Agent Registry」は、稼働中のエージェントを登録・管理するディレクトリで、エージェント同士がA2A（Agent-to-Agent）プロトコルを通じてお互いを発見、連携できる仕組みを提供する。

観測・最適化：Agent Observability

　本番環境で動くエージェントの挙動を監視・分析する機能群だ。エージェントのツール呼び出しや推論フローをトレースとして記録し、エラーの根本原因の特定や性能の最適化を支援する。さらに、エージェントの動作に基づく評価（eval）機能も統合されている。

Gemini Enterprise Agent Platformのコンポーネント

　これらのすべての機能は、Gemini Enterprise、Workspace、サードパーティのマーケットプレイス・エージェントにまたがる「共有コンテキスト」として束ねられる。企業内のあらゆるエージェントが同じ文脈を参照しながら協調できる設計だ。

　なお、カルダー氏は、「エージェントはGeminiに限らず、AnthropicのClaudeなどModel Gardenの他のモデルも選択できる」と、オープン性も強調した。

エージェントだけでマラソンイベントを設計できるのか？

　基調講演で披露された同基盤のデモは、「ラスベガスで1万人規模のマラソン大会を開催する」というシナリオで進んだ。

　こうした大規模イベントの開催には、交通規制や緊急車両のルート変更、地域経済への影響、ランドマークの活用など、考慮すべき条件が無数にある。これらをエージェントだけで処理させるというのがデモのテーマだ。

デモのシナリオ

　登場したのは3つのエージェントである。ルートを計画する「プランナー」、そのルートを採点する「エバリュエーター」、実際にランナーが走ったらどうなるかを再現する「シミュレーター」だ。この3つのエージェントが連携しながら、マラソンのプランを段階的に作り上げていく。

　まず、マラソンのルートをどう引くかだ。ラスベガスの大通り（Strip）で42.195kmのコースを作るには、地図データや地理情報、レース運営のノウハウが必要になる。そこで、プランナーエージェントに、Google Maps、GIS（地理情報システム）、レースディレクターの3つの「スキル」が与えられた。

　スキルは、YAMLのメタデータとMarkdown本文で構成され、エージェントが必要なタイミングでロードする仕組みであり、推論のターン数とトークン消費を軽減できる。Google MapsスキルはMCPサーバーを通じてランドマーク情報などの地図データを取得し、GISスキルはPythonスクリプトを呼び出してGeoJSONデータを処理する。

　レースディレクタースキルは、レース計画委員会が実際に使っていたGoogleドキュメントをGeminiで変換したもの。このように、「既存の文書を簡単にエージェントのスキルとして使える」という。こうしてプランナーエージェントは、ラスベガスの街並みを走り抜けるルートを生成した。

プランナーエージェント

　さらに、プランナーエージェントはメモリ機能も利用している。Agent Runtimeの「Memory Bank」にシミュレーション結果を蓄積し、過去の計画を記憶として参照している。

　また、ラスベガス市やネバダ州の条例文書をAlloyDBに取り込み、RAGの仕組みで「公道でラクダを引いてはいけない」といったローカルルールも反映する。デモでは、メモリとデータの参照でルートが改善されていく様子が示された。