株式会社 MBK Digital 執行役員 CTO の岩尾です。
MBK Digital では、主にお客様のデータ活用や AI 活用の支援を行っています。最近は特に、企業が AI エージェントをどう業務に組み込み、どう安全に運用していくかというテーマでご相談いただく機会が増えてきました。
そうした背景もあり、ラスベガスで開催された Google Cloud Next ’26 では、プロダクト発表そのものだけでなく、Google が AI エージェントの開発プロセスをどう見せようとしているかに強く注目していました。
なお、1 日目のオープニングキーノートについては、弊社の古畑が以下の記事で詳しくまとめています。全体の発表トーンや初日の大きなメッセージを押さえてから読むと、今回の Developer Keynote の位置づけもより掴みやすいと思います。
そのうえで今回の Developer Keynote を見ていて、いちばん印象に残ったのは新機能の多さではなく、エージェントをどう作り、どう運用し、どう直し、どう守るかがかなり具体的に見えたことでした。
今回のキーノートは、ラスベガスでのマラソン開催を計画するマルチエージェントシステムを題材に、7 つのデモを順番に見せる構成でした。単なる製品紹介というより、エージェントを本番で動かすまでの工程を順番に追体験させるような内容だったのが印象的でした。
この手のキーノートは、どうしても「何が新しいか」に目が行きがちです。でも今回は、それ以上に「チームでエージェントを開発するとき、実際にどんな工程を踏むのか」が見えたのがよかったです。だからこそ、エンジニアだけでなく、PdM / PM のように開発プロセス全体を設計したり調整したりする人にも見てほしい内容でした。
7つのデモは、そのままエージェント開発の工程表になっていた
Developer Keynote で示された 7 つのデモ
この 7 本の並びはかなり示唆的でした。最初にエージェントを作り、次に複数エージェントを連携させ、memory と context を持たせる。そのうえで、大規模運用での観測とデバッグ、インフラ変更、no-code 展開、セキュリティ統制まで進んでいく。つまりこれは「すごいエージェントができました」という完成品のデモではなく、作り始めてから本番運用までの流れを見せるデモだったと思います。
Demo 1. Build agents with Agent Platform
最初のデモでは、Google の Gemini Enterprise Agent Platform を使って、実運用を前提にしたエージェントをどう作るかが示されました。
基盤としては、ADK（Agent Development Kit）でエージェントを作り、Agent Runtime で実行し、Google Cloud の各種サービスや Google Cloud のリモート MCP サーバーとつなげる構成です。
マラソン計画の例では、まず Planner agent を作成し、ルート設計に必要な指示、スキル、ツールを与えていきました。Google Maps などのツールや、既存の運営知識を組み込むことで、単なる会話 AI ではなく、実際に仕事を進めるエージェントにしていく流れが紹介されました。
ここで興味深かったのは、skills が単なる補足メモではなく、メタデータと本文を持つまとまった部品として扱われていたことです。必要なときだけ読み込むことで、エージェントの専門性とコンテキスト効率を両立させる設計になっていました。
ここで見えたのは、エージェント開発とは単にプロンプトを書くことではなく、役割定義、ツール設計、外部システム接続を含む設計作業だということです。
Demo 2. Creating multi-agent systems
次に、1 つのエージェントだけではなく、複数のエージェントが役割分担して協調する仕組みが紹介されました。
このシステムでは主に、ルートを作る Planner、ルートを評価する Evaluator、実際の影響を再現する Simulator の 3 つが連携します。
ここで重要なのが、Agent2Agent（A2A）と Agent Registry です。A2A はエージェント同士が標準的な方法で通信するためのプロトコルで、Agent Registry はエージェントの能力を登録して発見できる仕組みです。これにより、エージェント同士が相互に見つけ合い、必要に応じて協力できるようになります。
また、評価結果をユーザーに見せるために、A2UI による動的 UI 生成も紹介され、エージェントが自分で必要な表示を組み立てる流れが示されました。A2UI は A2A をベースにした UI ツールキットとして紹介されており、エージェント側が必要な UI を動的に返せるのが特徴です。
このパートを見ていて感じたのは、エージェントを増やすこと自体が目的ではなく、重要なのは責務分割の設計だということです。どこまでを Planner に持たせ、どこからを Evaluator や Simulator に切り出すか。その切り方自体が設計論として表に出ていたのがよかったです。
Demo 3. Enhancing agents with memory
3 つ目のデモでは、エージェントをより賢くするための memory と context 管理がテーマでした。単発で応答するだけではなく、前回までの計画やシミュレーション結果を踏まえて改善していくには、エージェントが状態を持つ必要があります。
そのために、Sessions で会話や処理の流れを保持し、Memory Bank で長期的な学習や過去の知見を記憶し、RAG で外部文書やルールを検索して参照する仕組みが使われていました。
例としては、ラスベガスやネバダ州のルール文書を処理し、埋め込み化して AlloyDB に保存し、Planner agent が必要な規則を参照しながらルートを改善していました。つまり、エージェントが過去の経験と外部知識を踏まえて判断する方向に進化していることが示されました。
ここまで来ると、もはや「AI 機能追加」の話ではなく、コンテキスト設計と知識基盤設計の話です。実装者だけでなく、要件定義や運用設計に関わる人にも重要なパートでした。
Demo 4. Debugging agents at scale
4 つ目は、こうした複雑なエージェントを本番環境でどうデバッグするかです。エージェントはツール呼び出し、推論、文脈圧縮など多くの要素が絡むため、問題が起きたときに原因が見えにくくなります。
ここでは Agent Observability と Gemini Cloud Assist を使って、Simulator agent の障害を調査していました。デモでは、コンテキスト管理まわりの問題によって処理が止まっており、Observability で状況を確認しながら原因を絞り込んでいく流れが示されていました。
Cloud Assist はログやトレースを見て原因を絞り込み、コードの修正案まで提案し、そのまま IDE から修正を適用して問題を解決していました。
個人的にはこのデモがかなりよかったです。エージェントの話は、どうしても構築デモで終わりがちです。でも実際に困るのは、本番で遅い、壊れる、意図せず暴走する、といった場面です。このデモは、エージェント運用ではインフラ監視だけでなく、推論やコンテキスト管理の可視化が重要だという点をかなり明確に示していました。
Demo 5. Intent to infrastructure with Gemini Cloud Assist
5 つ目のデモでは、Cloud Assist を使って、開発者の意図をインフラ変更につなげる流れが紹介されました。
ここでは既存のシステムを改善する例として、ランナーを扱うコンポーネントを Cloud Run から GKE に移し、同じクラスタ上で Gemma 4 を動かす構成へ変えていました。
開発者が自然言語で変更を指示すると、Cloud Assist が IaC の修正案や推奨構成を示し、必要なインフラ変更を支援します。さらに、スケール時のストレージ問題も自動で調査し、より適した構成へ導いていました。
つまりこのデモの主旨は、AI エージェントが単にコードを書く補助だけでなく、インフラや運用構成の変更まで含めて支援することにありました。エージェント開発はアプリコードだけでは完結せず、インフラ設計や運用設計も含めて継続的に見直すものだ、というメッセージがはっきり出ていたと思います。
Demo 6. Build and share no-code agents
6 つ目は、開発者向けの高コードなエージェントだけでなく、ノーコードでもエージェントを作って共有できるという話でした。Gemini Enterprise アプリ上では、すでに作ったエージェントをそのまま利用できるほか、業務担当者が Agent Designer を使って新しいエージェントを簡単に作れます。
例では、マラソン運営に必要な物品調達や発注を支援する Supply chain agent を、Gemini Enterprise アプリ上の Agent Designer で業務担当者が構築していました。これにより、開発者が作った Planner agent と、業務担当が作った調達用エージェントが連携し、全体の作業を効率化できることを示していました。
この流れがよかったのは、高コード側で作ったエージェントが Agent Registry を通じて他の面でも活用され、ノーコード側のエージェントともつながっていたことです。個別に作って終わりではなく、共有と再利用まで含めて設計されているのが印象的でした。
ここでのメッセージは、高コードとノーコードを分けるのではなく、両方をつなげて使えることです。開発チームが基盤となるエージェントを作り、業務側が周辺業務のエージェントを足していく。この役割分担はかなり現実的で、これからの組織設計を考える上でも重要だと感じました。
Demo 7. Securing agents
最後は、エージェントを安全に運用するためのセキュリティとガバナンスです。エージェントは強力な分、権限を持ちすぎると危険なので、細かいアクセス制御が必要になります。
ここでは、Agent Identity によるエージェント固有の識別、Agent Gateway による通信や権限の制御、IAM ポリシーによる細かなアクセス管理が紹介されました。
例として、Finance MCP Server に対して ReadOnly 条件を持つポリシーのような細かな制御をかけられることが示されていました。さらに Wiz と連携し、実際に悪用可能な脆弱性や攻撃経路を見つけて修正する流れも示され、エージェント時代のセキュリティをどう実現するかが説明されました。
ここで重要なのは、「AI アプリのセキュリティ」ではなく、エージェントが外部ツールやデータに触る前提のセキュリティとして描かれていたことです。守る対象はモデルだけではなく、権限、通信経路、外部システム連携、実環境の露出まで含みます。
まとめ
今回の Developer Keynote を見ていて強く思ったのは、これは単なる製品紹介ではなく、エージェント開発の工程を見せる教材としてかなりよくできていたということです。
Google Cloud が考えるエージェント開発は、次の 7 段階で整理できると思います。
- エージェントを作る
- 複数エージェントを連携させる
- memory と context を持たせる
- 大規模運用で観測・デバッグする
- 意図からインフラ変更までつなげる
- ノーコードでも作って共有する
- 安全に統制する
つまり、エージェントを作るだけではなく、本番で動かし続けるための全体基盤を Google Cloud が提供する、というのが講演全体のメッセージでした。
しかも、このデモ一式はソースコードが公開されており、単なるステージ上の演出ではなく、再現可能な教材として見せようとしている点もよかったです。
だからこのキーノートは、エージェントを実装するエンジニアだけでなく、PdM / PM、アーキテクト、セキュリティ担当にもおすすめです。
「AI エージェントを作る」とは、何を決め、どこでつまずき、どう運用していくのか。その全体像を、かなり具体的にイメージできる回でした。
株式会社MBKデジタルの公式技術ブログ。 データとAIで企業の意思決定を変革します。 本ブログでは、Google Cloud (BigQuery)を中心とした大規模データ基盤のアーキテクチャ、LLM/RAGを用いたビジネス実装、そして顧客に伴走する中で得られたエンジニアリングの知見を、現場のエンジニアが発信します。
Discussion