こんにちは、DX開発事業部の山中です。Google Cloud Next ’26 に現地参加してました！
この記事は Google Cloud Next ’26 「From Prototype to Production: Building with Gemini Enterprise Agent Platform」のセッションレポートです。
司会の Jason Davenport さん（Developer Advocate, Google Cloud）、Addy Osmani さん（Director of Product Management, Google Cloud）、Dave Elliott さん（Developer Relations, Google Cloud）の3人が会場からライブ配信する約22分のセッションで、Gemini Enterprise Agent Platform の全体像を紹介しました。ADK でプロトタイプを作る話ではなく、「そのプロトタイプを本番に載せるための仕組み」 に焦点を絞った内容です。ADK でエージェントは動かせたが本番運用までの距離感が掴めていない方、LLM 評価と Agent Evaluation の違いが気になる方に参考になると思います。
Agent Platform は4本柱
この1〜2年、プロトタイプは5分で書けるのに、ID・ガバナンス・メモリ・観測をバラバラのサービスでつなぎ合わせる必要があった、と Addy さんは語りました。Agent Platform はその状況を整理し、Build / Scale / Govern / Optimize の4柱で必要な部品を揃えたエンドツーエンドプラットフォームです。
| 柱 | 代表コンポーネント |
|---|---|
| Build | Agent Development Kit [New] / Agent Studio [New] / Agent Garden / Gemini API / A2A / MCP / RAG |
| Scale | Agent Runtime [GA] / Agent Sessions [GA] / Agent Sandbox [GA] / Agent Memory Bank [GA] |
| Govern | Agent Gateway [New] / Agent Identity [GA] / Agent Registry [New] / Agent Anomaly Detection [New] / Model Armor / Agent Security [New] |
| Optimize | Agent Evaluation [New] / Agent Simulation [New] / Agent Observability [New] / Agent Optimizer [New] |
Scale は GA、Govern と Optimize に [New] が多く、今回の Next ’26 で踏み込んできた領域が一目で分かります。
Build — ADK が起点
エージェントを作る入り口は Agent Development Kit（ADK） です。対応言語は Python / Go / TypeScript / Java で、ADK で 0→1 を素早く済ませ、1→本番は他の柱で支える役割分担が明確です。
Govern — 暗号学的に生成されるエージェント ID
Govern の中心は Agent Identity です。エージェントごとに 暗号学的に生成された ID を発行し、他のサービスへのアクセスも個別の認証情報で管理します。
チームメンバーにログインを許可するとき、私のトークンを使い回させたりはしません。エージェントにも同じ扱いをします。（Addy さん）
監査ログで「どのエージェントの、どのアクションが原因か」を後追いできることが本番運用での肝になります。Gateway・Registry・Anomaly Detection も同じ柱に並び、Dave さんは Anomaly Detection を「hidden gem」と表現されました。
Scale — Memory Bank と Long-running Agents
半年ほど前に GA 化された Agent Memory Bank は、「これは覚えておくべきかも」を自動で判断・管理します。その上に乗るのが Long-running Agents で、数時間ではなく 数日〜数週間 走る前提のエージェントを first-class で扱えるようになりました。
数日走るエージェントが、途中で半分の作業内容を忘れたら使い物になりません。（Addy さん）
Optimize — 非決定性を前提に組む
Optimize は新設の柱 です。LLM もエージェントも非決定的である、という事実を前提に据えています。オーケストレーターで複数エージェントを束ねた瞬間に非決定性は積み上がるため、Agent Evaluation は単発の LLM 出力ではなく フロー全体が目的を達成しているか を評価します。
Agent Tracing はエージェントの挙動をグラフで可視化し、長時間実行でロジックが破綻した箇所を後追いできるようにします。Agent Sandbox は blast radius（影響範囲） を制限する役割です。Addy さんは「ハンマーと釘だけ渡して鳥小屋を作らせる」という比喩で、必要最小限のツールだけを入れたサンドボックスを推奨されていました。
開発者の役割はどう変わるか
Dave さんは「開発者は本質的に problem solvers であり、ツールが言語・IDE から AI に広がるだけで役割の核は変わらない」と語りました。Addy さんは Grady Booch の「ソフトウェアエンジニアリングの歴史は抽象度の上がる歴史である」を引用し、fleets of agents を管理する 方向に寄っていく、と見立てを示されました。機械学習そのものは「数学なので加速する」という意見で揃い、論文公開から Hugging Face や Kaggle で触れるまでのスピードは過去に例がない、と語られました。
これから触ってほしいもの
Agent Platform のリポジトリはセッション当日朝5時に公開、会場には Agent Hack Zone（21デモ + 5種類の CodeLab）と AI Agents Challenge for Startups の発表もありました。
まとめ
プロトタイプを本番に載せるときに毎回つまずく「ID・ガバナンス・メモリ・観測」をプラットフォーム側が引き取りに来た、という構造がよく分かるセッションでした。非決定性を前提にした評価・観測・サンドボックスを用意するのが本番運用への近道だと感じました。自分の手元のエージェントを4本柱に並べて、薄いところを点検するところから始めるのが良さそうです。
簡単30秒