2026年4月22日〜24日に開催された Google Cloud Next '26 へ参加してきました。昨年に引き続きアメリカ・ラスベガスで開催され、弊社からはMA部の平井・林・木野、AI事業戦略部の川田・桜井の5名が参加しました。なお、昨年参加した様子は以下の記事で紹介しています。 techblog.zozo.com 今年はAIエージェントを『実戦』に投入し、いかに賢く、安全に使うのかに焦点を当てたセッションが多い印象でした。本記事では、現地での様子と特に興味深かったセッションをピックアップして紹介します。 また、Recapのオンラインイベント「 Google Cloud Next 2026 Recap in ZOZO 」を2026年5月18日に開催しました。このイベントでは、Google Cloud Next '26について、今回のテックブログで紹介できなかった内容など、より詳細に共有しております。 現地の様子 私たちは会期の前々日にラスベガスの空港に到着したのですが、空港内にはさっそくGoogle Cloud Nextの広告が流れており、イベントに向けた熱意が一気に高まりました。 Google Cloud Nextの広告を見かけたハリー・リード国際空港の様子 昨年に引き続き会場は、ラスベガスのマンダレイ・ベイホテル コンベンションセンター。非常に盛り上がっており、特に各セッションや展示ブースでのデモでは参加者から活発な質問が飛び交っていたのがとても印象的でした。 熱気に包まれる会場内の様子 以降では、現地に参加したメンバーが気になったセッションを紹介します。 セッション紹介 What's new in Cloud Run こんにちは、MA部配信基盤ブロックの木野です。私は通知系（LINE/Mail/アプリ）の開発をしています。 公開資料「 What's new in Cloud Run 」のP.1より引用 このセッションでは、Cloud Runが単なるWebアプリのデプロイ先ではなく、より幅広いワークロードを受ける汎用実行基盤へ広がっていることが紹介されていました。セッション全体のメッセージは、Cloud Runが「on-demand compute for everyone」であるという点に集約されており、Vibe Coded Apps、AI Agents、AI Models、Large Scale Appsという4つの観点から新機能が説明されていました。 冒頭では、AI Studioで生成したマルチプレイヤーゲームをそのままCloud Runに公開するデモが紹介されており、Cloud Runが「作ったものをすぐにクラウドへ出す」ための基盤として強く打ち出されていました。また、Cloud Run公式のFully managed MCP Serverも発表されており、人間が操作する実行基盤というだけでなく、AIエージェントから直接デプロイや管理の対象になる基盤へ寄ってきていることも印象的でした。 GA対応したCloud Run Worker Pools 私が特に興味を持ったのは、Cloud Run worker poolsのGAです。Worker poolsは、HTTPリクエストを受けることが本質ではない常駐workerやpull consumer、runnerのような処理に対して、Cloud Run上のより自然な置き場を与える機能だと感じました。 Cloud RunにはこれまでもServiceやJobがありましたが、Serviceはrequest-driven、Jobはrun-to-completionであり、そのどちらにもきれいに当てはまらない処理を表現しづらい場面がありました。セッションでも、Temporalのworkerのようなlong polling前提の処理がworker poolsに適している例が紹介されていました。 この点は、私たちの配信基盤にもそのままつながります。例えばPub/Subのpull consumerや、ループし続ける常駐worker、定期的に状態を見て後続処理を進めるfinalizerのような処理は、実態としてはHTTPエンドポイントを持つことが本質ではありません。それにもかかわらず、これまではCloud Run Serviceの形に寄せるためにヘルスチェックや待受用のコードを持たせていました。worker poolsが一般提供されたことで、こうした処理をより素直な形で実装でき、配信基盤の見通しや運用性を改善できる可能性があります。 Cloud Run Instancesとbuilt-in dev loop 公開資料「 What's new in Cloud Run 」のP.30より引用 もう1つ興味深かったのが、Cloud Run Instancesとbuilt-in dev loopの流れです。セッションでは「ローカルでクラウドをエミュレートしようと頑張るのではなく、Cloud Run上でそのまま開発する」というメッセージが明確に打ち出されていました。ローカルの変更をCloud Run instanceに同期し、そのままdev scriptをクラウド側で実行することで、pushしてデプロイを待つ前に即時検証できる世界観が示されていました。さらに、SSH supportも合わせて紹介されており、Cloud Runを本番の実行基盤として使うだけでなく、開発や調査の場としても扱う方向性が見えてきたと感じました。 これは、複数サービスをまたぐ検証が多い配信基盤の開発体験にとって特に大きい変化だと思います。現在でもローカルでの統合テストやcontainer_testのような仕組みは有効ですが、実サービス依存に近い確認をしたい場合は、どうしてもdev環境への反映待ちや、共有環境ゆえの状態差分が問題になります。もしbuilt-in dev loopが成熟すれば、各開発者が自分の変更をCloud Run側へすぐに反映し、実サービス依存に近い状態で軽く検証を回せるようになります。さらに、人間が行う確認フローとPR後のE2EやCIの構成も近づけられる可能性があり、複数サービスをまたぐ開発・検証体験を大きく変えるアップデートだと感じました。 加えて、このセッションはCloud Runの新機能を個別に列挙するだけでなく、「Cloud Runはどこまで守備範囲を広げようとしているのか」という観点で見ると、とても示唆が多い内容でした。これまではHTTPサービスをスケールさせるためのプロダクトという見方が中心だったと思いますが、今回の発表では、AIエージェントの実行基盤、長時間動くworkerの置き場、さらにはCloud Run上での開発ループまで含めて整理されていました。配信基盤のように非同期処理、複数サービス連携、運用時の可観測性が重要なシステムにとっては、単なる機能の追加以上に、Cloud Runをどう使うかの前提そのものが変わり始めていると感じています。 セッションを通しての感想 Cloud Runは長らく「HTTPサービスを手軽に動かす場所」という印象が強かったのですが、今回のセッションを通して、AIエージェント、常駐worker、開発ループまで含めたより広い実行基盤へ進化していることがよく分かりました。特に私たちのように、非同期処理や複数サービス連携を多く持つシステムにとっては、今後の設計や検証フローを見直すきっかけになるセッションでした。 What's new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds こんにちは、MA部MAシステム開発ブロックの平井です。私は自社マーケティングシステム「ZMP」の開発をしています。ZMPではユーザー毎に最適化された情報を配信するパーソナライズ配信機能があり、そのデータベースとしてGoogle CloudのAlloyDBを利用しています。そこで、私はAlloyDBに関するセッションを聴講しました。 「What's new in AlloyDB」セッション会場の様子 このセッションでは、AlloyDBのアップデートをエンタープライズ・分析機能の観点、AI関連機能の観点から説明していました。 エンタープライズ・分析機能に関するアップデート Hot Standby 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.8より引用 Hot Standbyは、スタンバイ中のノードがWALを受け続けながらアクティブなインスタンスとして動く機能です。この機能によって、起動時間の短縮とプライマリー昇格の加速によるRTOの改善、メモリーキャッシュの暖気とフェイルオーバー後のパフォーマンス低下の抑制により一貫したパフォーマンスの維持が可能になります。 Read Pool Autoscaling 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.9より引用 Read Pool Autoscalingは、読み取りインスタンスがワークロードに応じて自動でスケーリングする機能です。また、事前に決められたスケジュールでスケーリングすることも可能です。例えばサイバーマンデーやブラックフライデーなどあらかじめ高負荷が予想される場合にとても有効です。私たちのパーソナライズ配信システムでも読み取りインスタンスを利用していて、負荷がスパイクする傾向があるため、Read Pool Autoscalingが一般提供された際は、その効果を速やかに検証したいと考えています。 Transparent Query Forwarding 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.11より引用 Transparent Query Forwardingは、プライマリーノードで受け付けた読み取りクエリを読み取りノードにフォワードする機能です。読み取りノードにクエリをフォワードすることでプライマリーノードの負荷を軽減し、クラスター全体のリソースを有効活用するために設計されました。アプリケーション側で必要だったライブラリを利用したプライマリノードと読み取りノードのコネクションの作成/クエリフォワード設定が不要になります。また、書き込みと読み込みの一貫性を担保しているため、アプリケーション側で古い情報を参照する心配がありません。 LakeHouse Federation for AlloyDB 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.16より引用 Lakehouse Federation for AlloyDBは、AlloyDBからBigQueryやIcebergにあるデータを簡単にクエリできる機能です。AlloyDB上のトランザクションデータとBigQuery上の履歴データ、集計データを結合することで統合的な分析が可能になります。 私たちのパーソナライズ配信システムでは、BigQuery上の集計データをAlloyDBにロードして、配信処理に利用しています。Lakehouse Federation for AlloyDBを経由したBigQueryのクエリ時には、コンピューティングの料金が発生するためリアルタイムでの利用は難しいですが、BigQueryを利用した集計データをAlloyDBにロードする処理をより簡素化が可能です。セッションではAlloyDB上のリアルタイムなデータとLakehouse上の履歴データを利用して、実績を比較する例が紹介されていました。 以下の画像は、AlloyDBとLakehouseがシームレスに連携することで、運用と分析の統合的なプラットフォームとして活用できることを表現した図です。AlloyDBからLakehouseへはDatastream機能が提供されていて、LakehouseからAlloyDBへもReverse ETL機能が提供されています。相互のデータ連携機能が提供される一方で、データ連携せずに統合的なデータアクセスを実現する手法として、Lakehouse Federation for AlloyDBが紹介されていました。 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.15より引用 AI関連機能のアップデート AI関連機能で紹介されていた内容は以下になります。 ベクトル検索の改善 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.30より引用 AlloyDB開発チームはベクトル検索を今後の検索機能における中核と位置付け、パフォーマンス向上に注力してきました。Google researchが開発したScaNNでは数百億のベクトルまで拡張でき、高速なクエリパフォーマンスとインデックス構築を実現しています。また、業界標準のHNSWのパフォーマンス向上にも取り組んでいて、オープンソースのpgvectorと比較して最大4倍高速な検索を実現できるそうです。 ハイブリッド検索 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.31より引用 ハイブリッド検索は完全一致を行うためのキーワード検索とセマンティックな検索を行うためのベクトル検索を統合した高度な検索機能です。この検索により固有名詞や型番などは確実にヒットさせつつ、曖昧な表現を含んだ単語でも関連性の高い結果を取得できます。既存のキーワード検索においても、RUM拡張のサポートによるパフォーマンス改善に加え、BM25アルゴリズムの活用によって検索精度の向上を実現しています。キーワード検索自体の機能改善による、それをベースとしたハイブリット検索の精度とパフォーマンスの向上にも取り組んでいるそうです。 Geminiを利用したAI関数の拡張 公開資料「 What’s new in AlloyDB: Scale PostgreSQL for agentic AI and hybrid clouds 」のP.32より引用 ai.if、ai.rank、ai.generateといった関数を活用することで、LLM（大規模言語モデル）の強力な機能をクエリインタフェース上で直接享受できます。例えば、ai.rank関数では、上記画像にあるような「サントリーニ島での夏休暇用のシャツ」を検索する場合、クエリ結果がGeminiに送信され、Geminiが現実世界の情報を加味して最適にソートした結果を返してくれます。 セッション全体に対する感想 AlloyDBがAIエージェント時代のデータベースとして選択されるために単なるデータ蓄積を超えた様々な新機能を開発していることが印象的でした。システムの可用性と信頼性を担保するためのエンタープライス機能、データ分析の基盤として活用するための分析機能、AIのパワーを活用したAI機能と今回紹介しただけでも様々な領域における機能が紹介されていて、データベースに求められている要件が非常に多岐に渡っていることを感じました。 また、私たちのパーソナライズ配信システムではAlloyDBでのベクトル検索機能を利用できておらず、AlloyDB開発チームがベクトル検索に投資している点からも、利用できるユースケースがないか探してみようと思います。 Generative UI for any agent, anywhere: A2UI, AG-UI, MCP Apps, and more こんにちは、MA部MAシステム開発ブロックの林です。私は自社マーケティングシステム「ZMP」の管理画面をフロントエンド・バックエンドを横断して開発しています。 現在のAIとの対話はテキストベースが主流ですが、テキストだけではユーザー体験として不十分なケースが多くあります。Generative UIとは、AIエージェントがユーザーに合わせたインタフェース（UI）を動的に構成するための手法です。ここでは、Generative UI関連のセッションで紹介された技術と、現地で体験したデモについてレポートします。 公開資料「 Generative UI for any agent, anywhere: A2UI, AG-UI, MCP Apps, and more 」のP.1より引用 MCP Apps まず紹介されたのが、Anthropic社が提唱するModel Context Protocol（MCP）の公式拡張「MCP Apps」です。従来のMCPがテキストやデータを返すのに対し、MCP AppsではエージェントがインタラクティブなUIを返します。UIは会話の中に直接埋め込まれ、ユーザーはチャットの流れから離れることなくアプリを利用できます。ChatGPT・Claude・Geminiなど主要なホストがすでに対応しています。 MCP Appsのスピーカーは、UIの形式を大きく3種類に分類して説明していました。 Predefined UI （事前定義）：決まったフォーマットのUIを返す Declarative UI （宣言的）：コンポーネント構造をJSONで指定してUIを組み立てる Generative UI （生成的）：ゼロからUIをその場で生成する MCP Appsはどの形式にも依存しない（agnostic）設計のため、後述するA2UIやAG-UIとも連携できます。A2UIやAG-UIが生成したUIをMCP Appの中でレンダリングしたり、逆にMCP Apps自体をA2UIやAG-UIでレンダリングしたりするコンポーネントとして扱うことも可能です。 A2UI 次に、Google社が提唱するエージェント駆動型インタフェース向けの「宣言型UIプロトコル」であるA2UIが紹介されました。 A2UIでは、あらかじめコンポーネントのカタログを定義しておき、エージェントはそこから選ぶ形でUIを組み立てます。エージェントが送信するのはJSONによるコンポーネント構造とデータのみで、実際の描画は自前のデザインシステム（ReactやFlutterなど）が行います。A2UI標準のBasic Catalogもデザインシステムとして利用できます。 コンポーネントを自前で管理する構造はセキュリティ上の利点もあります。たとえば「クリックターゲット内に隠しフォームを埋め込むUI生成」といった攻撃も、定義済みコンポーネントのみを使う構成であれば防御できます。 また、トランスポート不問のため、AG-UIやMCPと組み合わせることも可能です。 A2UIはすでにGemini Enterpriseにてプレビューで提供が開始されています。 AG-UI そして、CopilotKit社が提唱する「エージェントとフロントエンドの接続を標準化するプロトコル」として、AG-UIが紹介されました。MCPがツールとの接続、A2Aが他のエージェントとの接続を担うのに対し、AG-UIはユーザー向けフロントエンドとの接続を担う位置づけです。 AG-UIのスピーカーは、Generative UIの手法は制御の度合いによってグラデーションがあると説明していました。 Controlled ：アプリ側が厳密に制御するUI Declarative ：JSONなどで宣言的に構成するUI A2UIはここに位置づけられる Open-ended ：AIが自由に生成するUI MCP Appsはここに含まれる手法の1つ AG-UIはこのグラデーション全体をカバーし、ユースケースに応じて各技術と連携・使い分けができる設計になっています。 AKQA社の事例紹介 本パートでは、ブランド企業がGenerative UIに取り組むべき理由について説明がありました。従来のWebサイトはナビゲーション中心のユーザー体験に最適化されています。しかし現在では、多くのユーザーが事前にChatGPTやGeminiで情報収集してサイトを訪れるため、必要な情報が見つからなければ再びAIに戻ってしまいます。そのため、ユーザーの意図に直接応答できる仕組みの重要性が高まっています。 デモでは、ユーザーの意図を機能的・感情的・社会的という3つの側面に分解するアプローチが紹介されました。たとえば「コンバージョンを落とさずに不正検知を改善したい」といった入力から、ユーザーの緊急度や心理的背景を推定し、それに応じたページを動的に生成します。従来は人手でPDF資料を作成しており1件あたり6時間以上かかっていた作業が、この仕組みによってWeb上では約10秒で完了するようになったと説明されていました。 GenLatte Generative UIが組み込まれたラテアート注文アプリを「GenLatte」ブースにて実際に体験できました。ラテアートのデザインをリテイクする指示を出したところ、AIから私専用の追加質問がいくつか投げられました。質問は単一選択のもの、スライダーで微調整するもの、テキスト入力のものなど複数パターンがありましたが、どれも私のラテアートの内容に応じた質問で、人間が答えやすい形式のUIとして提示されました。生成されたラテは実際に飲むことができ、本当にお店でラテを注文しているようでした。Generative UIの可能性を実感できるブースでした。 公開資料「 Personalize the user experience with generative UI 」のP.19より引用 Generative UIが組み込まれたラテアート注文アプリを体験できる「GenLatte」ブース（左）と生成されたラテ（右） 自社での活用の可能性 今回のセッション・デモを通じて、Generative UIは自社でも応用可能だと感じました。 現在の自社マーケティングシステムは、マーケターがSQLを直接書いてセグメントを作成することを前提に設計されています。しかし、すべてのマーケターがSQLを書けるわけではないこと、「すでにあるSQLを元に年齢で配信を出し分けたい」といった軽微な修正であっても毎回SQLを書く必要があることに対して改善を求める声がありました。 一方で、エンジニア側も対応に十分な工数を割けていない状況です。過去にはUI上で条件を絞り込める機能を開発したこともありましたが、後から追加になった絞り込み条件などマーケターの要望に追従できず、利用されづらい状態になっていました。 こうした課題に対して、AIによるSQL生成とGenerative UIを組み合わせるアプローチが有効だと考えています。具体的には、以下のような流れです。 マーケターが自然言語でセグメントの条件を入力する AIがSQLを生成する 生成されたSQLの実行結果（セグメント数）や、既存SQLとの差分などの情報を、Generative UIで動的に構成されたダッシュボードとしてマーケターに提示する このような仕組みが実現すれば、セグメント作成をマーケター完結で迅速かつ柔軟に行えるようになります。結果として、マーケターの作業工数だけでなく、エンジニアへの問い合わせ・対応コストの削減にもつながると考えています。 What's new in Google Cloud's agent platform こんにちは、AI事業戦略部AIソリューション開発ブロックの桜井です。私は社内の業務・事業へAIをどのように組み込み、継続的に価値を出せる形へ育てていくかに関心を持って開発・検証に取り組んでいます。 公開資料「 What's new in Google Cloud's agent platform 」のP.1より引用 このセッションでは、Google Cloud上でAIエージェントを構築し、本番業務に展開していくためのAgent Platformのアップデートが紹介されました。これまでVertex AIとして提供されてきた機能が「Gemini Enterprise Agent Platform」に統合され、Agent時代における新しいインフラ環境として生まれ変わりました。 セッションの冒頭で印象的だったのは、AIエージェントの位置づけが「チャットで質問に答えるもの」から「現実の業務タスクを実行するもの」へ移りつつある、という整理です。 公開資料「 What's new in Google Cloud's agent platform 」のP.5より引用 これまでのエージェントは、ユーザーがチャットで問いかけ、その場で応答を返すInteractive Chat Agentsが中心でした。一方で、これからはバックグラウンドでデータやシステムを監視し、必要に応じて判断・処理・通知するBackground Processing Agentsや、音声・映像を使って人と自然にやり取りするReal-time Audio/Video streaming Agentsも重要になると紹介されていました。 この考え方は、社内業務にAIを組み込むときにも非常に重要だと感じました。例えば、問い合わせ内容から注文情報や配送状況を確認して一次調査をまとめる、商品説明文の改善候補を商品マスタやレビュー傾向から整理する、BigQuery上の販促結果を定期的に確認して異常値を通知する、といった業務は単発のチャット応答ではなく「一定時間、業務を預ける」タイプのタスクです。 Agent Platform全体は、Build、Scale、Govern、Optimizeという4つの領域で整理されていました。 公開資料「 What's new in Google Cloud's agent platform 」のP.6より引用 Buildでは、ADKやAgent Studio、Agent Garden、MCP、A2Aなどを使ってエージェントを作るための機能が提供されます。Scaleでは、Agent RuntimeやAgent Sandbox、Agent Memory Bank、Agent Sessionsなどを使って、エージェントを本番ワークロードとして動かすための仕組みが用意されています。Governでは、Agent Identity、Agent Gateway、Agent Registry、Agent Policy、Model Armorなどにより、権限や通信、セキュリティポリシーを統制します。Optimizeでは、Agent EvaluationやAgent Observability、Agent Simulationなどを使って、運用中の品質を継続的に確認していきます。 特に興味を持ったのは、Agent Runtimeのアップデートです。 公開資料「 What's new in Google Cloud's agent platform 」のP.13より引用 Runtime enhancementsでは、1秒未満の高速なコールドスタート、数秒でのプロビジョニング、最大7日間のLong-running Operation、双方向ストリーミング、リソースレベルのIAM binding、Python、Java、TypeScript、Goへの対応、プロジェクトあたり3,000エージェントまでのスケールなどが紹介されていました。これにより、エージェントを長時間・多段階の業務を担う実行単位として扱うための基盤が提供されます。 さらに、Agent Runtimeは実行環境だけでなく、セッションやメモリ、サンドボックス、評価、Observabilityとつながる形で説明されていました。社内でエージェントを使う場合、単にモデルへプロンプトを送るだけでは足りません。どのユーザーの依頼で、どのセッションの文脈を持ち、どのデータを参照し、どのツールを呼び出し、どのような結果を返したのかを追える必要があります。商品情報、FAQ、問い合わせ履歴、販売実績などを横断する業務ほど、セッション管理やメモリ、実行ログが重要になります。 Governの領域では、Agent IdentityとAgent Registryの考え方が実運用に直結すると感じました。 公開資料「 What's new in Google Cloud's agent platform 」のP.16より引用 Agent Identityでは、エージェントごとにIDを持たせ、最小権限の考え方で権限を付与し、エージェントの操作を監査できるようにすることが説明されていました。これは、業務システムに接続するエージェントを「誰かの権限を使って動くスクリプト」としないために重要です。商品情報を読むだけのエージェント、売上や在庫を集計するエージェント、問い合わせ対応を支援するエージェント、外部SaaSへチケットを作成するエージェントでは、必要な権限がまったく異なります。 また、組織内のエージェント、MCPサーバー、エンドポイントを管理するための中央システムとしてAgent Registryが紹介されていました。エージェントが部署やチームごとに増えていくと、似たようなエージェントが乱立したり、古いバージョンが使われ続けたり、オーナーがわからなくなったりする可能性があります。AIソリューション開発ブロックとしても、各業務領域の知識を持つチームと一緒にエージェントを育てるためには、どこに何があり、誰が管理し、どのデータやツールにつながっているのかを可視化する仕組みが必要になると感じました。 Agent Gatewayやセキュリティのアップデートも、業務利用にあたって重要なポイントです。Agent Gatewayは、エージェントの通信やツールアクセスに対して、中央でガバナンスとセキュリティポリシーを適用するための仕組みとして紹介されていました。IAM連携、プロトコル解析、ログ、Trace IDなどを通じて、エージェントがどの通信を行い、どの操作を実行したのかを追えるようになります。エージェントの数が増えるほど、個別実装ごとに認可やログを作り込むのではなく、共通の制御点を持つことが重要になると感じました。 運用面では、Agent ObservabilityとEvaluationのライフサイクルが印象的でした。 公開資料「 What's new in Google Cloud's agent platform 」のP.19より引用 通常のWebアプリケーションであれば、HTTPステータスやエラー率、レイテンシを見ることで、ある程度の健全性を把握できます。しかしエージェントの場合、レスポンスが返っていても、根拠が不十分だったり、不適切な判断をしていたりする可能性があります。そのため、トレースやダッシュボード、Multi-Agent topology graph、オンライン・オフライン評価、シミュレーション、継続的な改善までを一連のライフサイクルとして見る必要があります。 このセッションを通じて、AIエージェントを業務で活用するうえで必要なインフラが、Agentに最適化された形で整備されつつあることを強く感じました。これまでも、実務でAIを活用する際はプロンプトだけで完結するわけではなく、実行環境、権限管理、ログ、評価、監査などをどう組み合わせるかを試行錯誤する必要がありました。だからこそ、Runtime、Identity、Gateway、Registry、Observabilityのような機能がプラットフォームとして提供されるのは非常にありがたい流れだと感じます。ZOZOでも業務・事業におけるエージェント活用において、権限とログを整えながら、Background Processing Agentsのように、ユーザーが意識しなくても裏側で業務を支える形での活用も推進していきたいと思います。 Gemini Enterprise appとGoogle Workspaceのアップデート こんにちは、AI・アナリティクス本部 AI事業戦略部 生成AI推進ブロックの川田です。ZOZOでは生成AI活用を推進するチームのマネージャーとして、業務活用とプロダクト活用の両面で企画・推進を担当しています。 今回、Google Cloud Next '26に参加して、生成AIが「質問に答えるもの」から「業務を理解し、タスクを実行するもの」へ進化していることを強く感じました。特に、ビジネス部門の業務効率化に直結しそうなGemini Enterprise appとGoogle Workspaceのアップデートを中心に紹介します。 Google Workspace Blog「 10 more announcements from Google Workspace at Cloud Next ‘26 」のカバー画像より引用 Knowledge Catalog まず印象的だったのが、Gemini Enterprise appとも関係の深いKnowledge Catalogです。Knowledge Catalogは、一言でいうと仕事に関わる情報の集約場所です。 AIエージェントが自律的に動くためには、仕事のこと、会社のこと、プロダクトのことなど、業務に必要な文脈を理解している必要があります。しかし実際の業務情報は、メール、Slack、Googleドライブ、Box、Salesforce、BigQueryなど、さまざまな場所に分散しています。これまでは人間がそれらのツールを行き来しながら、必要な情報を探し、つなぎ合わせていました。 Knowledge Catalogは、外部ソースも含めて100以上のコネクタで情報をつなぎ、ユニバーサルなコンテキストエンジンとして機能します。例えば、エージェントがBigQueryから過去のキャンペーン結果を取得し、スプレッドシートから現在の在庫状況を確認します。そして、Boxにあるデザインガイドラインも参照したうえで、新しい施策案を作るといった使い方が考えられます。 これまでも、AIに社内情報を参照させるためにベクトルデータベースを構築したり、RAGの精度向上に試行錯誤したりする必要がありました。Knowledge Catalogによって、普段使っている業務ツールをコネクタでつなぐだけでセマンティック検索の基盤を活用できるようになると、AIのための準備に使っていた時間を、本来考えるべき業務設計に向けやすくなると感じました。 また、Gemini Enterprise appのDeep Research機能においても、Knowledge Catalogは重要な役割を持ちます。プロンプトだけでは伝えきれない社内の前提や文脈を補完できるため、調査結果の質を高められる可能性があります。 Agent Designer v3 次に、Gemini Enterprise appのアップデートとして、ノーコードでエージェントを作成できるAgent Designer v3が紹介されました。 Agent Designer v3の特徴は、大きく3つあります。1つ目は、自然言語でエージェントやワークフローを作成できることです。2つ目は、実行順序や条件分岐を設定し、柔軟にタスクを実行できることです。3つ目は、MCPサーバーをコネクタとして利用し、企業データを扱えることです。 つまり、企業データを理解したエージェントを、開発者だけでなくビジネス部門のメンバーも視覚的に設計できるようになります。日々の定型業務や複数アプリをまたぐ作業を自動化したい場合や、現場のニーズに合ったAIツールを各部門で作って活用したい場合に、大きな効果が期待できます。 ZOZOでの活用例としては、「商品レビューの自動分析・構造化」ワークフローが考えられます。 1. MCPサーバー経由で、BigQueryに蓄積された新着の商品レビューデータを取得する 2. AIがレビュー内容から「フィット感」「サイズ感」「使用感」などの特徴量を抽出し、ポジティブ・ネガティブの感情を判定してJSON形式で出力する 3-1. ネガティブな感情が強い場合や不良品に関する言及があった場合は、カスタマーサポート部門へGmailやチャットで通知する 3-2. 通常のレビューであれば、構造化したデータをAlloyDBやBigQueryに書き込み、レコメンドやパーソナライズ配信のデータとして蓄積する このように、「自社データの取得」「AIによる分析・構造化」「条件に応じた通知やシステム操作」までを一連の流れとして構築できる点が、Agent Designer v3の大きな魅力だと感じました。 Workspace Intelligence Google Workspace Blog「 Workspace Intelligence の発表 」の本文中で使用されている画像より引用 Google Workspaceのアップデートとしては、Workspace Intelligenceも印象に残りました。Workspace Intelligenceは、Google Workspaceの各アプリとGeminiを連携させ、ユーザーの業務背景や文脈をAIに理解させるための統合的な仕組みです。 イメージとしては、Knowledge CatalogのGoogle Workspace版に近いと感じました。Gmail、Googleドライブ、Google Chatなどに分散している情報を横断的に理解し、ユーザーが今必要としている情報やアクションを提示してくれます。 例えば、Ask Gemini in Chatでは優先タスクのリストアップやファイル検索を支援できます。また、GmailではAI InboxやAI Overviewといった機能が紹介されていました。AI Inboxは、受信トレイの中から今日中に返信すべき承認依頼や、プロジェクトの遅延リスクにつながるメールを判断し、ToDoとして提示してくれます。AI Overviewを使えば、メール、ドキュメント、スライドを横断して「あの件の最新ステータスはどうなっているか」「あの仕様は最終的にどのような落とし所になったか」といった質問にも答えられるようになります。 数日間の出張や休暇から戻ったときに、メールやチャットを何百件も遡って状況を把握するのは、多くの人が経験している負荷だと思います。Workspace Intelligenceによって、その不在期間の文脈を要約できれば、人間はキャッチアップ作業に時間を使うのではなく、最初から判断や意思決定できるようになります。 Sheets Canvas 最後に、Sheets Canvasについても紹介します。これはエージェント的な機能というより、データの理解や業務の進め方を大きく変えそうなアップデートです。 Sheets Canvasは、スプレッドシート上のデータをもとに、ノーコードでミニアプリを構築できる機能です。例えば、KPIダッシュボードやプロジェクト進捗を管理するカンバンボードのようなものを、数クリックで作成できます。作成したCanvasはシートのデータとリアルタイムに同期されるため、シートを更新するとアプリ側も最新の状態になります。また、通常のスプレッドシートと同じように他のユーザーへ共有できます。 スプレッドシートは柔軟で便利な一方、データ量が増えると全体像をつかむのに時間がかかることもあります。Sheets Canvasによって、データを入力・管理する場所と、それを理解・活用するための画面が近づくことで、情報を把握するスピードや意思決定の質を高められると感じました。 まとめ 今回紹介したKnowledge Catalog、Agent Designer v3、Workspace Intelligence、Sheets Canvasに共通しているのは、AIが業務の文脈を理解し、必要な情報を探し、タスクの実行まで支援する方向に進んでいる点です。 AIに参照させたいコンテキストを集約し、そのデータを活用するエージェントを作成できるようになることで、これまで人が担っていた情報探索や整理、定型的な判断の一部を任せやすくなります。また、普段利用しているGoogle Workspaceの各アプリにもAI機能が組み込まれることで、日常業務の中で自然にAIを活用できる場面が増えていくと感じました。 一方で、これらの機能は導入するだけで価値が出るものではなく、どの業務に適用し、どのように運用へ組み込むかが重要です。ZOZOでも、業務活用とプロダクト活用の両面でユースケースを見極めながら、研修や検証を通じて社内での生成AI活用を推進していきたいと思います。 おわりに 今回のGoogle Cloud Next '26では、各サービスのアップデートを個別に知るだけでなく、それらが実際の開発・運用体験をどのように変えていくのかを考える機会になりました。Cloud Run、AlloyDB、Generative UI、Agent Platform、Gemini Enterprise app、Google Workspaceといったテーマはそれぞれ異なりますが、どのセッションも、私たちが日々向き合っているシステム設計、データ活用、業務改善、開発体験に直接つながる内容でした。 また、現地ではセッションに加えて、企業ブースやデモ展示を通じて、発表された技術がどのようなユーザー体験として提供されるのかを具体的に知ることができました。資料や動画だけでは分かりにくい細かな操作感や、参加者の反応、会場全体の熱量を肌で感じられたことも、現地参加ならではの大きな収穫でした。 今回得た知見を、ZOZOのプロダクト開発や社内でのAI活用にも活かしていきたいと思います。Google Cloud Next '26では数多くのセッションが公開されていますので、気になる方はぜひ 公式サイトのSession and Activity library もご覧ください。 最後に、弊社ではカンファレンス参加に伴う渡航費や宿泊費は福利厚生のひとつであるセミナー・カンファレンス参加支援制度によって、カンファレンス参加にかかる費用は全て会社負担です。 ZOZOでは一緒にプロダクトを開発してくれるエンジニアを募集しています。ご興味のある方は下記リンクからぜひご応募ください！ corp.zozo.com

G-gen の杉村です。当記事では、Google Cloud Next '26 in Las Vegas の、2日目の開発者向けキーノートに関する速報レポートをお届けします。 Developer Keynote イベントの概要 キーノートの概要 技術的な概要 Google が強調したかったこと 全体像 Build agents with Agent Platform Creating multi-agent systems Enhancing agents with memory Debugging agents at scale Intent to infrastructure with Gemini Cloud Assist Build and share no-code agents Securing agents 関連記事 Developer Keynote イベントの概要 Google Cloud Next は、1年に1回開催される、Google Cloud の旗艦イベントです。2026年は、ラスベガスのマンダレイ・ベイにおいて4月22日（水）から24日（金）までの3日間で開催されます。 参考 : Google Cloud Next 2026 - Las Vegas Conference 例年、2日目の「開発者向け基調講演（ Developer Keynote ）」では、Google が開発者やデータサイエンティスト、機械学習エンジニアなど技術者向けに伝えたい主張や新サービスの発表などが行われます。当記事では、Google Cloud Next '26 の2日目の開発者向け基調講演を、特に注目すべき発表にフォーカスして紹介します。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp Developer Keynote キーノートの概要 Google Cloud Next '26 の初日に行われたオープニングキーノート（基調講演）では、Google Cloud の新機能の発表や、顧客事例が紹介されました。また、AI/ML や生成 AI 向けの開発プラットフォームである Vertex AI が Gemini Enterprise Agent Platform に改名されリブランディングされたことも示されました。 blog.g-gen.co.jp 当記事で紹介する、2日目の開発者向けキーノート（Developer Keynote）では、ラスベガスでのマラソン大会を計画・シミュレーションするデモ AI エージェントを題材に、エージェントの開発、デバッグ、インフラ構築、セキュリティ強化をウォークスルーで紹介する体裁が取られました。 チーフエバンジェリストの Richard Seroter 氏と、Developer Relations Engineer の Emma Twersky 氏のコンビが全体をファシリテーションします。AI エージェント開発を7つのデモにわけて、各デモでスペシャリストが登壇して紹介しました。 Richard Seroter 氏と Emma Twersky 氏 7つのデモは、以下のとおりです。 Build agents with Agent Platform（ Agent Platform でエージェントをビルドする ） Creating multi-agent systems（ マルチエージェントシステムを作成する ） Enhancing agents with memory（ メモリでエージェントを強化する ） Debugging agents at scale（ エージェントを大規模にデバッグする ） Intent to infrastructure with Gemini Cloud Assist（ Gemini Cloud Assist を使用してインテントからインフラストラクチャを構築する ） Build and share no-code agents（ ノーコードエージェントを構築して共有する ） Securing agents（ エージェントをセキュアにする ） これを通じて、Google Cloud と AI を活用すると、いかに素早く簡単にエージェント開発が進められるかを強調しました。 7つのデモ 技術的な概要 このキーノートで紹介されたマラソン大会計画エージェントは マルチエージェント 、すなわち複数の AI エージェントが協調してタスクを行うエージェントです。このマルチエージェントの開発をウォークスルーする形で、様々な技術がプレゼンテーションされました。 エージェントの開発は、AI エージェント開発用ライブラリである Agent Development Kit （ADK）を用いて行います。 開発されたエージェントは、 Agent Runtime （旧称 Vertex AI Agent Engine）にデプロイされます。Agent Runtime はフルマネージドの AI エージェント向けコンピュートプラットフォームであり、組み込みのセッション管理機能とメモリ管理機能などを備えています。 別々にデプロイされた複数のエージェント間の通信は A2A などの標準プロトコルが担い、ガバナンスは Gemini Enterprise Agent Platform に含まれる Agent Registry や Agent Gateway 、 Agent Identity といった機能が担保します。また、 Wiz はソースコードと環境をエージェントがスキャンすることで、セキュリティリスクを高度に可視化し、対処法を提示できます。 また開発作業や運用は、 Agent Observability や Gemini Cloud Assist を組み合わせることで、使い慣れた IDE（統合開発環境）から AI の補助を借りつつ迅速に行うことができます。 Google が強調したかったこと 前述のように、Google Cloud そのエコシステムには AI エージェントの開発、デプロイ、保守を効率的に、かつセキュアに行う手段が揃っています。Google Cloud とそのエコシステムを使って AI エージェントを開発、デプロイ、保守することで、 セキュリティとガバナンスを保ちつつ高速に AI エージェント開発ができる ことを、Google が改めて示した形になります。 また、リブランディングされた Gemini Enterprise Agent Platform が、組織が 統制を効かせつつ AI エージェントを活用する ためのプラットフォームであることも強調されました。多数のエージェントがさまざまな部署によってデプロイされても、重複開発を防ぎつつ、エージェント同士が相互に連携しあい、タスクを自律的に行っていくのが理想です。 そのうえでセキュリティを担保するには、組織が適切なプラットフォーム上で統制を効かせることが不可欠です。Gemini Enterprise Agent Platform には、そのようなサービスが揃っています。 公式ガイド Agent Platform overview から引用 全体像 開発者向けキーノートでは、ラスベガスでのマラソン大会を計画するマルチエージェントを開発します。エージェントの構成は以下のようなものです。 Planner agent : skills と tools を使って走行ルートを決める Evaluator agent : ビジネス要件や地域ルールに従って走行ルートを評価する Simulator agent : 街への影響を見るため、走行ルート上でランダムな振る舞いをする人々をシミュレーションする このような 複数のエージェントが相互に協調 し、マラソン大会の計画というタスクを実行していきます。 開発するマラソン大会計画エージェント Build agents with Agent Platform 走行ルート計画を立てる Planner agents の開発は、Gemini Enterprise Agent Platform の Agent Designer を使って行われました。UI 上で自然言語でエージェントの振る舞いを定義して、Get code ボタンを押すと、AI エージェント開発用ライブラリである Agent Development Kit （ADK）で記述された Python コードが自動生成されました。初期のプロトタイプは、このようにして Agent Designer で生成できます。 Agent Designer Planner agents は内部的に instructions、skills、tools で構成されています。 instructions はエージェントの振る舞いを決めるテキストプロンプトです。 skills は、LLM が自身の知識だけで完結せず、外部ツールや API 等と連携して作業できるように部品化された「実行可能な拡張機能」または「テキストのプロンプト」のことです。Google に特有な言葉ではなく、近年の AI エージェントツールにおいてよく用いられる用語です。タスクを進める中で適切な振る舞いができるように、Google Maps や Geographic Information System（GIS）、レース監督といった Skills が定義されています。 skills からは tools を呼び出すこともできますし、別途配置された Python スクリプトを呼び出すことなども可能です。 tools は、AI エージェントが外部のアプリケーションや API を「道具」のように呼び出すための定義のことです。ここでは、 Google Cloud MCP server for Google Maps が Tools として定義されています。Google Cloud MCP server は、Google Cloud が提供するフルマネージドのリモート MCP サーバーです。Skills で定義された振る舞いにより、MCP server tools が呼び出され、エージェントはマップ情報を手に入れることができます。 instructions、skills、tools こうして構築された Planner agents は、 Agent Runtime （旧称 Vertex AI Agent Engine）にデプロイされます。Agent Runtime はフルマネージドのエージェント用コンピュートプラットフォームです。セッション、メモリ、モニタリングなどのエージェント用機能がネイティブに備わっています。 Creating multi-agent systems 次に、他のエージェントも考えます。ルートを評価する Evaluator agent は Planner agent のサブエージェントとして配置します。一方で街への影響をシミュレーションする Simulator agent は、別の Agent Runtime インスタンスにデプロイされており、Planner agent とは A2A プロトコルを使って通信します。A2A プロトコルは、エージェント間の通信を標準化するプロトコル（あるいはフォーマット）です。 参考 : Agent2Agent (A2A) Protocol マルチエージェントのアーキテクチャ A2A プロトコルでは、各エージェントは Agent card と呼ばれる情報を持ち、自らの役割や能力を広告（advertise）します。これにより、エージェント同士は、呼び出すべき他のエージェントの情報を知ることができます。 Agent card またここでは、エージェントは Gemini Enterprise Agent Platform の Agent Registry という共通レジストリに登録されます。Agent Registry はインターネットにおける DNS のようにイメージできます。エージェントは他のエージェントについて Agent Registry に問い合わせ、必要な能力を持つ他のエージェントを探し出すことができます。Agent Runtime にデプロイされたエージェントは Agent Registry に登録され、相互に発見可能になります。エージェント同士の通信は A2A に基づいて行われるので、複雑な API コントラクトを定義する必要がありません。 参考 : Agent Registry overview Agent Registry に登録されたエージェント一覧 Agent Registry を使ったアーキテクチャ またエージェントが効果的にグラフィカルなユーザーインターフェイスを生成するための標準規格である A2UI も紹介されました。これにより AI が動的に UI を生成できるため、フロントエンドの作り込みにかかる時間が軽減されます。 参考 : a2ui.org A2UI の one-shot prompting A2UI で生成された UI（右ペイン） Enhancing agents with memory Planner agent は、 セッション と メモリ を使います。セッションは、1回の処理内での短期的な記憶であり、メモリはセッションをまたいで記録される長期的な記憶です。どちらの記憶領域も Agent Runtime に標準で備わっており、ADK 上の実装でも少量のコードで済みます。メモリ機能により、Planner agent は過去に策定された計画を覚えておくことができます。 参考 : Agent Platform Sessions overview 参考 : Agent Platform Memory Bank メモリとセッションを定義するソースコード また Planner agent が適切な走行ルートを策定するためには、州や市の定めるルールなどを知っておく必要があります。PDF などの非構造化データをエージェントが参照できるようにするために、ここでは RAG（Retrieval-Augmented Generation）を用います。RAG 構成のためには、非構造化データをエンベディング情報に変換してデータベースに格納する必要があります。 メモリ、セッション、RAG デモでは Google Cloud のデータエンジニアリングエージェントを使い、エンベディング情報を生成するデータパイプラインを簡単に開発できるとされました。Lightning Engine for Apache Spark を使って PDF を読み取り、チャンク化して AlloyDB のテーブルに格納します。本来であれば、チャンク化されたテキストはパイプラインによって、または手動でエンベディング情報に変換される必要があります。しかしここでは、AlloyDB の Auto vector embeddings 機能が使用されました。これにより、テーブルに格納されたデータが、自動的にベクトル化されます。 参考 : Generate and manage auto vector embeddings for large tables AlloyDB に格納された自治体ルールは、tools を通じて呼び出されます。この tools は Google Cloud から提供されている AlloyDB のリモート MCP サーバーを使って、AlloyDB のベクトル化情報をクエリします。 AlloyDB に格納されたチャンクとエンベディング Debugging agents at scale 大量のエージェントが運用されている状況下では、モニタリング、デバッグ、および障害対応の負担が増大します。Gemini Enterprise Agent Platform にはこの状況に対応するための機能が用意されています。 Agent Observability は、Agent Runtime にデプロイされたエージェントのモニタリングを行います。 Gemini Cloud Assist は、Google Cloud における開発や運用を AI で補助する機能の総称です。 参考 : Agent observability 開発者や運用者は、使い慣れた IDE や CLI ツールから、MCP 経由で Gemini Cloud Assist を呼び出し、Agent Observability の情報を自然言語で取得できます。これにより、大規模な AI エージェント運用環境でも、情報取得、障害の解決法の示唆、修正コードの適用などを、すべて 自然言語により 行えることが示されました。 自然言語による AI アプリケーション運用 Agent Observability では、エージェントの動作のトレース情報を確認できます。 AI アプリケーションのトレース情報 また、Gemini Cloud Assist の一部である Gemini Cloud Assist Investigations を使うと、AI がトレース情報やログなどを読み取り、障害の root-cause analysis（RCA、根本原因分析）を行ってくれます。 参考 : Gemini Cloud Assist Investigationsを解説。AIエージェントでトラブルシューティング - G-gen Tech Blog Gemini Cloud Assist Investigations また、任意の IDE から MCP 経由で Gemini Cloud Assist を呼び出すこともできます。自然言語でエラーの原因を問い合わせると、MCP 経由で情報が取得されます。Agent Observability の情報や GitHub 上の issue の情報が収集され、原因や解決方法、修正コードまでもが AI により回答されます。わずか数分で、エラーを解消できました。 IDE からのソースコード改修 Intent to infrastructure with Gemini Cloud Assist Simulator agent は、マラソンランナーをシミュレーションする必要があります。ランナーをシミュレーションするためのサブエージェントである Runner agent を、ここでは Google Kubernetes Engine（GKE）上で稼働させ、またモデルとしては Gemma 4 を用います。Gemma は、Google が提供するオープンモデルです。ローカル環境や GKE のようなプラットフォーム上で動作できます。インフラとして GKE を、モデルとして Gemma を使うことで、Agent Runtime と Gemini のようにフルマネージドな組み合わせよりも、より細かいカスタマイズを行うことができます。 参考 : Gemma モデルの概要 GKE と Gemma デモでは、Simulator agent はもともと Cloud Run service にデプロイされていました。この Cloud Run の定義ファイルを自然言語による指示で GKE に変換します。IDE から MCP 経由で Gemini Cloud Assist を呼び出し、この変換を実環境に適用します。Gemini Cloud Assist が人間と Google Cloud の間の翻訳者として動作したことで、自然言語を使ってインフラをデプロイできました。 Google Cloud と Gemini の統合により、ソースコード開発だけではなくインフラ構築や運用も、自然言語で行えることが示されました。 自然言語で Cloud Run から GKE へ移行する Build and share no-code agents 次に、ここまでで開発した ハイコードエージェント （または フルコードエージェント ）と、Gemini Enterprise app で構築するノーコードエージェントの連携が示されます。飲み物や食料、仮設トイレなどのロジスティクスまわりを計画する Supply chain agent を、ノーコードエージェントとして構築します。 ハイコードエージェントとノーコードエージェントの協調 Agent Runtime にデプロイされたエージェントは、 Gemini Enterprise アプリ からも呼び出し可能になります。Gemini Enterprise アプリは、かつては単に Gemini Enterprise と呼ばれていた、エンタープライズ従業員向けの AI ツールです。 参考 : Gemini Enterpriseを徹底解説！ - G-gen Tech Blog Gemini Enterprise アプリから Planner agent を呼び出すと、A2UI によって動的に生成された UI が反映されています。開発したハイコードエージェントは、カスタムアプリの UI から使用できることはもちろん、Gemini Enterprise アプリからも使用できることが示されています。 ハイコードエージェントを Gemini Enterprise アプリから呼び出す 続いて、ロジスティクス周りの業務を行う追加のエージェントを構築するため、Gemini Enterprise アプリのノーコードエージェント構築機能を使います。Gemini Enterprise アプリの Agent Designer では、ノーコードエージェントを視覚的な UI で構築できます。また Agent Designer は、自然言語で指示することで、自動的にノーコードエージェントを構築してくれます。 Agent Designer Gemini Enterprise アプリの Agent Designer で開発したノーコードエージェントも Agent Registry に登録されるため、他のエージェントから呼び出すことが可能です。 続けて、Gemini Enterprise アプリの UI から Planner agent に「ロジスティクス計画を含めた、総合的な計画を策定して」と指示すると、Planner agent から Supply chain agent が呼び出され、総合的なマラソン大会計画が策定できることが示されました。つまり、フルコードで Agent Runtime にデプロイされているエージェントと、Gemini Enterprise アプリのノーコードエージェントとして構築したエージェントが A2A プロトコルを通じて連携し、タスクを実行した ことになります。 ハイコードエージェントからノーコードエージェントが呼び出された Securing agents マルチエージェント環境のセキュリティを向上するための施策も紹介されました。 Agent Gateway は、エージェント間のプロキシといえます。エージェント間の通信に Identity and Access Management（IAM）ポリシーを適用し、エージェントがどこから使用可能かを制御します。 参考 : Agent Gateway overview Agent Gateway はエージェント間のプロキシ Agent Registry に登録されたエージェントには、自動的に固有の Agent Identity が付与されます。汎用的なサービスアカウントは複数のワークロードに付与できてしまう可能性がありますが、Agent Identity は 必ずエージェントごとに一意 であるため、監査可能性とセキュリティの面で優れています。 Agent Identity Agent Gateway はこの Agent Identity をアクセス制御に使用します。Agent Gateway の Egress Agent Policy は、エージェントから他のエージェントや tools などへのアウトバウンド通信を制御し、ガードレイルの役割を果たします。エージェントからインターネットへの通信を制御することもできます。 Egress Agent Policy デモの環境ではアクセスが厳密に制御されていたため、Planner agent から予算情報を取得するための Finance MCP Server へのアクセスを許可するために、Agent Gateway 上で IAM Allow ポリシーを追加します。ポリシーには条件（conditions）を付与することもでき、ReadOnly のみ、といった指定が可能です。 IAM Allow Policy の追加 続いて、クラウド向けのセキュリティソリューション Wiz が紹介されました。Google は2026年3月に、Wiz の買収完了を発表しました。 Wiz は AI アプリケーションの ソースコードとクラウドの実環境をスキャン して、セキュリティグラフを生成します。また Wiz は、アタックサーフェイス（Attack surface）を検査してリスクを見つけだす Red agent や、根本対処の方法を提示する Green agent など、AI エージェントを用いています。 Wiz と AI アプリケーション デモでは、Planner agent とそのモデル、tools などが可視化されている Wiz の UI が示されました。インターネットからサービスアカウントを通じて Cloud SQL（データベース）に到達できてしまう可能性があることなどが、可視化されています。 セキュリティグラフ Red agent はこのような攻撃経路を評価してリスクを提示するので、ソースコードの静的評価などよりも優れています。 Red agent のリスク提示 Green agent はこれらに対する対策を提示します。デモでは Claude Code の skills を使って Green agent に対処法を提示させ、環境に適用させました。 Green agent の対処法提示（1） Green agent の対処法提示（2） このように、Wiz を使って AI アプリケーションのリスクとその対処法を提示させて、使い慣れた CLI ツールや IDE から自然言語で対処する方法が示されました。これは、開発スピードを遅延させずにセキュリティを確保できることを意味しています。 関連記事 Google Cloud Next '26 の関連記事は、以下の記事一覧を参照してください。開催期間中は、記事が随時公開されます。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。当記事では、Google Cloud Next '26 で発表された Gemini Enterprise アプリ の新機能について、公式の投稿記事「Gemini Enterprise for the agentic task force: introducing long-running agents, agentic collaboration spaces, advanced governance, and more」の内容をもとに紹介します。 はじめに 名称変更とリブランディング 作業の自動化 強化されたエージェントデザイナー Skills が使用可能に 長時間稼働エージェント エージェント管理用受信トレイ A2UI のサポート Data Insights エージェントによる統合分析 Deep Research エージェントの強化 チームの生産性 プロジェクト Canvas の実装 エンタープライズ・エコシステム エージェントギャラリーと Marketplace の統合 Bring Your Own MCP ガバナンス 概要 Agent Identity Agent Registry Agent Gateway はじめに 以下の Google 公式投稿を参考に、Google Cloud Next '26 で発表された Gemini Enterprise アプリ の新機能を紹介します。なお、当記事で紹介する機能の提供ステータス（GA / Preview / Private Preview / Coming Soon）は2026年4月23日現在の情報です。 参考 : Gemini Enterprise for the agentic task force: introducing long-running agents, agentic collaboration spaces, advanced governance, and more 当記事では、上記の記事から画像を引用しており、引用した画像には「画像は公式投稿より引用」と付記してあります。 他の Google Cloud Next '26 の関連記事は、Google Cloud Next '26 カテゴリの記事一覧から参照してください。 blog.g-gen.co.jp 名称変更とリブランディング これまで「Gemini Enterprise」と呼ばれていた Google Cloud の生成 AI ウェブサービスは、 Gemini Enterprise アプリ という名称に変更されました。 これは、Google Cloud の AI 開発プラットフォームである Vertex AI が Gemini Enterprise Agent Platform と改称されたことに伴います。Gemini Enterprise Agent Platform という大きなブランドのもとに、Gemini Enterprise アプリや、新しく発表された AI エージェント向けサービス、そして従来からの Vertex AI サービス群が格納された形です。 Gemini Enterprise Agent Platform（画像は公式投稿より引用） 作業の自動化 強化されたエージェントデザイナー 従来より Gemini Enterprise アプリには、ノーコードエージェントを構築可能なエージェントデザイナー（Agent Designer）が付属していました。このエージェントデザイナーは、自然言語と UI 上の簡単な操作で、タスクを順次実行するノーコードエージェントを簡単に構築できるツールですが、従来は「親」と「子」の2階層のエージェントしか作れませんでした。 従来のエージェントデザイナー しかし今後、エージェントデザイナーは強化され、より複雑なノード構成を取ることができるようになります。Human in the Loop（HITL）のチェックポイントも作成できるようになり、これまでよりも充実したノーコードエージェントを構築可能になります。 当機能は2026年4月23日現在、まだ使用可能になっていません。 新しいエージェントデザイナー（画像は公式投稿より引用） Skills が使用可能に Gemini Enterprise アプリで Skills が使用可能になります。Skills は、LLM が自身の知識だけで完結せず、外部ツールや API 等と連携して作業できるように部品化された「実行可能な拡張機能」または「テキストのプロンプト」のことです。Google に特有な言葉ではなく、近年の AI エージェントツールにおいてよく用いられる用語です。 公式の投稿に掲載されたスクリーンショットからは、追加した Skills はオン・オフを切り替えることができることが示唆されています。 当機能は2026年4月23日現在、まだ使用可能になっていません。 Skills（画像は公式投稿より引用） 長時間稼働エージェント 長時間稼働エージェント （Long-running agents）は、大規模で複数のステップからなるワークフローを実行できる機能です。数時間から数日間、バックエンドで自律的に動作します。 従来の Gemini Enterprise アプリのエージェントは、ユーザーからのテキストプロンプトをきっかけに短時間動作し、同期的に回答を返すものでした。長時間稼働エージェントは、それとは一線を画すものです。 当機能は2026年4月23日現在、まだ使用可能になっていません。 エージェント管理用受信トレイ エージェント管理用受信トレイ （Inbox for agent management）は、エージェントの動作の経過や結果を受け取るためのメッセージボックスです。 メッセージは「入力が必要」「エラー」「完了」などに分類されます。長時間稼働するエージェントとの関連が深いものと想定されます。 当機能は2026年4月23日現在、まだ使用可能になっていません。 エージェント管理用受信トレイ（画像は公式投稿より引用） A2UI のサポート A2UI （Agent-to-UI）プロトコルは、エージェントが UI を動的に生成してユーザーとインタラクティブにやりとりをするための標準を定めた、オープンプロトコルです。Google が開発し、Apache 2.0 ライセンスのもとに公開しています。 参考 : a2ui.org A2UI が Gemini Enterprise アプリでサポートされるようになり、カスタムエージェントはリッチな UI を生成してユーザーとやりとりをすることができます。 当機能は2026年4月23日現在、Preview 公開されています。 参考 : Register and manage agents using A2UI and A2A Data Insights エージェントによる統合分析 Data Insights エージェント は、Gemini Enterprise アプリから利用可能な組み込みエージェントです。既にリリースされている Data Insights エージェントでは、BigQuery のデータを自然言語で問い合わせ可能でした。 Data Insights エージェントの分析対象に、ドキュメント、メール、チャットなどの非構造化データも加えることができるようになると発表されました。 新バージョンは2026年4月23日現在、まだ使用可能になっていません。 Deep Research エージェントの強化 Deep Research エージェント は、既に利用可能な Gemini Enterprise アプリの組み込みエージェントです。Web サイトや社内のデータソースに対して多段的なリサーチを行い、重厚なレポートを生成します。 発表内容は、Deep Research エージェントが強化されるというものでした。強化の内容は詳細に明かされていませんが、「バックグラウンドで何時間も動作」という説明があることから、より長時間の実行が可能になる等のものであることが示唆されています。 新バージョンは2026年4月23日現在、まだ使用可能になっていません。 チームの生産性 プロジェクト Gemini Enterprise アプリに プロジェクト 機能が追加されます。Google Workspace、Microsoft OneDrive、Teams チャットなど、さまざまなソースのコンテキストを統合して、特定のプロジェクトに特化したエキスパートエージェントを作成できる機能として説明されています。 1日目のキーノートの発表とあわせて解釈すると、これはデータソースを限定することでハルシネーションを低減するような仕組みであると想定されます。NotebookLM のように、特定のデータソースに基づいたタスクを Gemini Enterprise アプリに実行させられるものである可能性があります。 公式投稿のスクリーンショットからは、プロジェクトは複数の同僚と共有できるものであることが示唆されています。 当機能は2026年4月23日現在、まだ使用可能になっていません。 Gemini Enterprise アプリのプロジェクト（画像は公式投稿より引用） Canvas の実装 Gemini Enterprise アプリに Canvas が実装されます。Canvas は、リアルタイムの編集機能を備えたエディタであり、Google Workspace 等に付属の Gemini アプリには付属しています。 Gemini Enterprise アプリでは、Canvas がリアルタイムの共同編集機能を備えており、チームでドキュメントやスライドを共同編集できます。AI にスライドの雛形を生成させ、チームでそれを共同編集するという使い方が想定されます。この共同編集は、Gemini アプリにはない機能です。 さらに、Microsoft 365 との相互運用性も意識されており、Canvas で作成したドキュメントやスライドを一般的な Microsoft Office 形式にエクスポートできるようになります。 当機能は2026年4月23日現在、まだ使用可能になっていません。 Canvas（画像は公式投稿より引用） エンタープライズ・エコシステム エージェントギャラリーと Marketplace の統合 エージェントギャラリー は、Gemini Enterprise アプリ内で、ユーザーが使用可能なエージェントを一覧表示する画面です。備え付けの「Google が開発したエージェント」、管理者によって配布される「組織のエージェント」、自分でノーコードで作成した「マイエージェント」などがリストアップされます。 今後、エージェントギャラリーに Agent Marketplace が統合されます。Agent Marketplace ではサードパーティが販売する AI エージェントを購入し、Gemini Enterprise アプリにインストールできます。管理者の承認を経て購入されたエージェントのみが使用可能になります。 当機能は2026年4月23日現在、Preview 公開されています。 参考 : Add and manage A2A agents from Google Cloud Marketplace - Configure marketplace visibility Bring Your Own MCP Bring Your Own Model Context Protocol （BYO-MCP）の実装が発表されました。 この機能により、ノーコードエージェントが自社サーバーでホストされているツールを検出して実行できるようになり、自動化の可能性が広がるとされています。詳細の記述がないものの、Gemini Enterprise アプリに MCP を登録しておき、ノーコードエージェントから呼び出せるようになるものと考えられます。 当機能は2026年4月23日現在、まだ使用可能になっていません。 ガバナンス 概要 Gemini Enterprise Agent Platform 製品群に含まれる Agent Identity、Agent Registry、Agent Gateway といった機能により、組織内で複数の AI エージェントのガバナンスを、ガバナンスを発揮しながら相互に協働させられる世界観が示されました。 Google Cloud Next '26 の2日目に行われた Developer Keynote（開発者向け基調講演）でも、これらについては解説されました。以下の記事も参照してください。 blog.g-gen.co.jp Agent Identity Agent Identity は、AI エージェントに割り振られる、暗号化された固有の ID です。人間が使う Google アカウントや一般のアプリケーションが用いるサービスアカウントとも区別されます。コンテキストアウェアなアクセスと mTLS が前提となっており、意図しない実行環境以外では認証情報が使用できないようになっています。 Agent Identity は Gemini Enterprise Agent Platform Runtime（旧称 Vertex AI Agent Engine）および Gemini Enterprise で使用可能です。 Agent Identity は、既に一般公開（GA）されています。 参考 : Agent Identity overview Agent Registry Agent Registry は、組織内で AI エージェントや MCP サーバー、tools 等が発見されやすいよう、集約管理したり、ユーザーにキュレート（推奨して提示）したりするためのツールです。こちらも、従来からその機能の一部が Gemini Enterprise で使用可能になりました。 Gemini Enterprise アプリから Agent Registry に登録された A2A エージェントを呼び出せるほか、Gemini Enterprise アプリのエージェントデザイナーで開発したノーコードエージェントも Agent Registry に登録されます。また、独自開発したハイコードエージェント（フルコードエージェント）から、Gemini Enterprise アプリのノーコードエージェントを A2A プロトコルで呼び出すなど、 ハイコードエージェントとノーコードエージェント の相互連携も可能になります。 2026年4月23日現在、Agent Registry は Preview 公開されています。 参考 : Agent Registry overview Agent Gateway Agent Gateway は、ネットワークポリシー、データアクセス、セキュリティガードレールを一元管理できる、管理者向けソリューションです。プロンプトインジェクションなどのリスクからの保護を提供する、とされています。またコンテキストアウェアアクセスの能力を持っており、会社固有のルールを適用することで、承認されていないエンドポイントにエージェントがデータを送信してしまうことを防ぐともされています。 これらの機能は、 Model Armor 、 Identity and Access Management （IAM）、 Identity-Aware Proxy （IAP）などの既存サービスとの統合により実現されます。Access control policies によりエージェントがこれらのサービスを適切に使用するように交通整理するのが、Agent Gateway です。 2026年4月23日現在、Agent Gateway は Private Preview 公開されています。使用には Google への申請と、審査への合格が必要です。 参考 : Agent Gateway overview 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it