前へ 1 2 次へ

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

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

文●末岡洋子 編集● 福澤/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

 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の仕組みで「公道でラクダを引いてはいけない」といったローカルルールも反映する。デモでは、メモリとデータの参照でルートが改善されていく様子が示された。

前へ 1 2 次へ

過去記事アーカイブ

2025年
02月
03月
04月
05月
06月
07月
08月
09月
10月
2024年
04月
05月
06月
07月
08月
09月
10月
12月
2023年
01月
02月
03月
05月
06月
07月
09月
12月
2022年
03月
04月
05月
06月
07月
08月
12月
2021年
02月
04月
05月
06月
08月
09月
10月
11月
2020年
05月
06月
2019年
04月
11月
2018年
07月
09月
10月
2017年
06月
2014年
07月