エージェントを“使う”から“管理する”に変える「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日目の基調講演では、ラスベガスでマラソン大会を企画・シミュレーションするというユニークなデモを通じて、実際に同基盤でマルチエージェントシステムを構築する様子が披露された。
AIエージェントを「作る・動かす・守る」ための基盤
Google Cloudが発表したGemini Enterprise Agent Platformは、これまで提供してきたAI開発基盤Vertex AIを進化させた、AIエージェント時代の統合開発基盤である。
Vertex AIが備えていた生成AIやMLモデル、AIアプリケーションの構築・デプロイ・拡張のための機能に、エージェントの構築・管理に必要な機能を統合。CEOのトーマス・クリアン(Thomas Kurian)氏は、「GoogleのAIをすべての従業員、すべてのワークフローが活用できるよう、新たな段階に進めるための基盤」と位置付ける。
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、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の仕組みで「公道でラクダを引いてはいけない」といったローカルルールも反映する。デモでは、メモリとデータの参照でルートが改善されていく様子が示された。






