[セッションレポート] AI エージェントを安全に構築・統制する - Gemini Enterprise Agent Platform の全体像と Equifax 事例 #GoogleCloudNext

2026.04.25
お疲れさまです。とーちです。Google Cloud Nextで、Gemini Enterprise Agent Platformのセキュリティとガバナンス機能を扱うテクニカルセッション「Securely build and govern AI agents in Gemini Enterprise Agent Platform」を聴講してきました。Build (構築) から Govern (統制) までの各レイヤーで何が用意されているかを網羅的に学べる内容で, さらに Equifax 社による事例まで含まれており、実践的な内容でした。
 セッション概要 タイトルSecurely build and govern AI agents in Gemini Enterprise Agent Platform
 概要Your team has built AI models and agents in Gemini Enterprise Agent Platform. Now you need to ensure they scale safely and securely. In this technical session, you'll learn how to use Gemini Enterprise Agent Platform's built-in security controls, and to extend AI protection with Security Command Center. Find out how to protect against prompt injection attacks, prevent sensitive data exposure, and implement security best practices for Agent Runtime to ensure your projects remain secure as they scale to production.
※日本語訳:
あなたのチームは Gemini Enterprise Agent Platform でAIモデルとエージェントを構築した。次に必要なのは, それらを安全かつセキュアにスケールさせることである。本テクニカルセッションでは, Gemini Enterprise Agent Platform に組み込まれたセキュリティ統制の使い方と, Security Command Center による AI 保護の拡張方法を解説する。プロンプトインジェクション対策, 機微データの漏えい防止, Agent Runtime のセキュリティベストプラクティスを押さえ, 本番スケールしてもプロジェクトを安全に保つ方法を学べる。
 スピーカーEliza Kuzmenko 氏 (Google Cloud, Senior Product Manager)
Vinod Nannapaneni 氏 (Equifax, VP, Cyber Architecture and Engineering)
Aniket Patankar 氏 (Google Cloud, Lead Product Manager)
 Gemini Enterprise Agent Platform の全体像セッション冒頭では Aniket 氏が, Gemini Enterprise Agent Platform を「Build / Scale / Govern / Optimize」の4つのレイヤーで捉える全体像を紹介されていました。各レイヤーの役割はざっくり以下のような整理です。
Build: 開発者向けの構築キット。Agent Development Kit (ADK) + 新発表の Agent Studio + 幅広いモデル選択肢
Scale: 改良された Agent Runtime と新発表の Agent Memory Bank で, パーソナライズされた長期コンテキストを保ったまま本番にスケールさせる
Govern: 各種セキュリティ・ガバナンスツールで統制する層。本セッションのメインテーマ
Optimize: 評価・シミュレーション・デバッグで品質を維持し続ける
Aniket 氏はこの全体像を「縦に統合された1つのスタック」と表現されていました。「Google Cloud は AI スタックの全レイヤーに最適化された機能を提供できる唯一のクラウドプロバイダーであり, だからこそエージェント時代に必要な包括的なセキュリティを提供できる」ということを冒頭で強調する形でセッションが始まりました。
 Build と Scale (Eliza 氏パート)ここからは Eliza 氏が Build と Scale のレイヤー, 特にランタイム周りのセキュリティ機能を解説してくださいました。
 ADK 2.0ADK 2.0 では以下の強化が入っているとのことでした。
グラフベースのオーケストレーションで, 長時間・複雑なオペレーションに対応
human-in-the-loop ワークフローの標準サポート
マルチモーダルストリーミング
サブエージェント連携の改善 (親エージェントから子エージェントへのタスク受け渡しや結果の集約がスムーズに)
対応言語を Python / Go / TypeScript / Java に拡張
ここで言うグラフベースのオーケストレーションは, 処理ステップを「ノード」, ノード間のつながりを「エッジ」として書く方式のことです。「A の次は必ず B」という一本道ではなく, ノードの実行結果に応じて次のノードを動的に選んだり, 分岐・ループ・並列を組んだりできるので, エージェントのような「LLM が次の行動を判断する」ワークフローと相性が良い書き方です。
「シングルターンのボットを超えて真のマルチエージェントシステムへ移行する」という言い方をされていて, ADK は複数エージェントを前提とした作りになってきているのだなと感じました。
 Agent RuntimeAgent Runtime は, もともと Vertex AI Agent Engine として提供されていたランタイムが, Gemini Enterprise Agent Platform への再編に合わせて改めて整理されたものです。今回の発表ではスケールとパフォーマンスの両面で強化が入っています。
コールドスタート1秒未満で高応答性を担保
自前コンテナの持ち込み (bring your own container) サポート
long-running agents (LRO) は最大7日間稼働可能
resource-level IAM binding でエージェント単位に IAM ポリシーを直接付与できる (例: 「このエージェントは BigQuery のこのデータセットだけ参照可」のように個別に絞り込み可能)
1プロジェクトあたり 3000エージェントまでスケール
GKE 上でのエージェント ID 対応, Cloud Run でも順次対応予定
ADK でローカル開発したエージェントをそのまま Agent Runtime にデプロイ
個人的には resource-level IAM binding でエージェントごとに明確に権限をつけられるのが良さそうですね。
 Agent Sandbox と Computer Use
本番レベルの信頼性を担保するうえで, Eliza 氏が「ブラックボックスからガラスボックスへ」と表現されていたのが Agent Sandbox の部分でした。Agent Sandbox は安全に隔離された環境でエージェントの処理を動かすための仕組みで, スライドでは以下の3つに整理されていました。
Code Execution (GA): 安全・隔離・管理されたサンドボックス環境でエージェントがコード実行できる
Sandbox BYOC (Next の少し後に Public Preview 予定): カスタムブラウザツールやカスタムコンテナを持ち込み可能 (環境要件に応じて構成できる)
Computer Use: サンドボックス上での低遅延 GUI 自動化。スナップショット取得や実行の rewind (巻き戻し) でリアルタイムなブラウザ操作が可能
ブラウザのプロファイルや Cookie もサンドボックス内に閉じ, ネットワークは Network Policy, アクセスできる外部 API は IAM で制限できます。エージェントがどこを触れるかを統制した状態でブラウザ操作を任せられる, というイメージですね。
Computer Use の具体例として, サポート問い合わせのトリアージを挙げられていました。CRMやサポートツールから追加の情報を取る必要がある場面で, エージェントがブラウザ上のGUIを操作して情報を取得することができます。単なるチャットボットではなく複雑なワークフローが出来そうで期待できますね。
 Sessions と Agent Memory Bank
長期のユーザー体験を作るうえで重要なのが Sessions と Agent Memory Bank で, 以下のような機能が紹介されていました。
カスタムセッションIDで, エンドユーザーと特定の会話履歴を正確にひもづけ
Agent Memory Bank が GA. memory profiles (ユーザーの技術スタックや言語嗜好などを定型スキーマに沿って構造化プロファイルとして保持する機能) は preview
会話履歴から記憶を自動生成・更新し, 短期・長期どちらの記憶からもユーザー嗜好を呼び出して応答に反映できる
ingest API (preview): 会話イベントを継続的に流し込む専用API. アプリ側はイベントを投げるだけでよく, 重複排除やメモリ生成のタイミング制御は Memory Bank 側が非同期に面倒を見てくれる
将来的にマルチエージェント対応
 Agent Identity
Agent Platform でエージェントを扱ううえで, 一番構造が整理されていると感じたのが Agent Identity の話でした。Eliza 氏は以下3種類のアイデンティティを明確に分けて説明されていました。
User Identity (ユーザーID): ユーザーがエージェントや SaaS (Gemini Enterprise 等) にアクセスする際のID. Human IdP (Entra / Cloud Identity / Auth0 など) が発行
Agent Identity (エージェント自身の権限で動く): エージェントが自分自身の権限でリソースにアクセスするためのID. GCP がエージェント作成時に発行. 2-legged OAuth 2 (エージェントとサービスの2者間で完結し, ユーザーを介さず認証する方式) で principal となる
Agent Identity (ユーザーの代理として動く): エージェントがユーザーの権限を借りてリソースにアクセスするためのID. OAuth サーバー (1P / 3P) がユーザーの OAuth dance (委任フロー) をもとに発行. 3-legged OAuth 2 (ユーザー / エージェント / サービスの3者間で, ユーザーの同意フローを経由して認証する方式)
さらに, エージェントIDは SPIFFE ID (OpenID 標準ベース) で暗号的に証明された固有IDが自動付与されます。ライフサイクル管理とガバナンス機能が組み込まれていて, 休眠化した資格情報や過剰権限の問題に対処するため継続的にローテートされる設計です。
 Agent Registry
Agent Registry は, 組織内のエージェントとツールの探索・統制ハブとして位置付けられています。
自社・Google 製・サードパーティのエージェントやツールを一元検索
ADK / non-ADK の MCP サーバー両方を管理境界内で可視化
開発者に対して「承認済みエージェントのみ可視化」などのポリシー設定
バージョン履歴, 各エンドポイント, ガバナンス設定のカスタマイズ
別のセッションでも出てきていましたが, エージェントを一元管理できるという思想は, 増えていくエージェントを管理するうえで分かりやすくて良さそうだなと感じました。
 Govern (Aniket 氏パート)後半は再び Aniket 氏に戻って, 統制 (Govern) レイヤーの解説です。ここからがこのセッションの主題で, Agent Gateway から SCC AI Protection まで, 発表も多岐にわたっていました。
 Agent Gateway
Agent Gateway は, Agent Platform のエージェントのインバウンド・アウトバウンド全トラフィックに対するポリシー適用点となるネットワーク基盤サービスです。基本的な役割や新発表内容については別記事 (Gemini Enterprise の発表まとめ) で解説しているのでそちらをご参照ください。
本セッションで特に強調されていた新発表として以下2つがありました。
ふるまいガバナンス: エージェントのランタイム挙動をセッションやインタラクション単位で監視し, ベースラインからの逸脱を検知
セマンティックガバナンスポリシー: 自然言語で業務上の制約を書ける
 Model Armor
Agent Gateway に統合されているコンテンツ保護ガードレールが Model Armor です。特徴は以下です。
ユーザー → エージェント → MCP ツール → LLM の全経路でやり取りを保護
高度な間接プロンプトインジェクション攻撃, 危険・攻撃的コンテンツのブロック
250以上の分類器による機微データ保護
悪意のあるファイル, ドキュメント, 安全でないURLのブロック
一度有効化すれば常時オン, コード変更不要
プロンプトインジェクションにも対応しているので, 外部公開するようなAIエージェントでは必須の仕組みになりそうだなと感じました。
 Security Command Center AI Protectionここからが SCC 側の話で, 発表のボリュームが一番多かった部分です。
Security Command Center (SCC) は Google Cloud 環境全体のセキュリティリスクを一元的に可視化・管理する統合セキュリティプラットフォームで, AI Protection はその SCC を AI / エージェントワークロード向けに拡張した機能群です。Agent Platform に組み込みで提供され, エージェントのライフサイクル全体にわたるリスク管理を担います。役割は大きく「Discover (発見) / Secure (保護) / Detect (検知)」の3つに分かれます。
 組織横断のAIアセットインベントリ
効果的な AI リスク管理は「何がどこで動いているか」を掴むところから始まる, というのが Aniket 氏の説明でした。SCC AI Protection の AI アセットインベントリ は, 組織全体のAI関連リソースを一画面で見渡せるダッシュボード機能で, 以下が可視化されます。
AIアセット本体: 各プロジェクトで動いているエージェント, それらに紐づく MCP サーバー・ツール, 利用されているファウンデーションモデル, カスタムモデルの推論エンドポイント
データソース: RAG やファインチューニングに使われたデータセット, Agent Memory Bank から抽出されているデータなど. 機微データを含むかどうかまで識別される
Shadow AI アセット: 未承認のエージェント・MCPサーバー, Cloud Run / GKE 上の推論エンドポイント. 今回の Google Cloud Next での新発表として, インベントリの対象範囲がここまで拡張されることが紹介されていました
「どこに機微データを扱うエージェントがいるか」を先に把握できなければ適切なガードレールを置けないので, インベントリはガバナンスの出発点として欠かせない機能ですね。
 Agent Vulnerability Assessment
カスタムAIエージェントの採用が急拡大する一方で, エージェントコードやパッケージに含まれる脆弱性管理は難題になりつつあります。「最新の脆弱性を見逃すリスク」と「Agent Runtime のインフラ層 (ベースイメージなど Google 側責務) 由来の指摘が大量に出て, 自分のコードに対する重要な指摘がそこに埋もれるリスク」の両方があるので, これを整理するのが Agent Vulnerability Assessment の役割です。
4ステップで動きます。
簡単な有効化: SCC AI Protection を有効にすれば, Agent Platform のプロジェクトとアーティファクトに対する脆弱性スキャンも自動でオン
継続的スキャン: 新しい脆弱性が出たら, 過去にスキャン済みだった既存パッケージも再スキャン (artifact analysis ベース)
インテリジェントな仕分け: ベースイメージの脆弱性 (Google 側責務) と, カスタムコード・パッケージの脆弱性 (顧客側責務) を切り分け, アクションの必要なものだけ提示
統合セキュリティレポート: コンテナリソースから reasoning engine や Agent Platform runtime のリソースまでトレースバックし, すぐ対処できる形で提示
デモ画面では, 古いバージョンの LangChain パッケージに特定の CVE を検出し, 脆弱性が修正された新しいバージョンを推奨する例が紹介されていました。
 Agent Access Governance
エージェントが IAM の first-class principal (ユーザーやサービスアカウントと同列に, IAM が正式な権限主体として認識するID) として扱われるようになったことで, 人間と同様に権限の過不足問題が発生します。これを解決するのが Agent Access Governance です。
IAM recommender で過剰権限や休眠状態のエージェントプリンシパルを検出
AI ベースのロール推奨で「現在のロールはX, 活動実績から見るとYは削ってよい」と具体的に提示し, 最小権限化を支援
機能としては既存の IAM recommender の対象がエージェントにも広がっただけ, とも言えますが, エージェント数が数千単位になると人手では絶対に回らないので, 自動推奨は欲しい機能だと感じました。
 Model Armor 違反傾向の可視化
SCC AI Protection では Model Armor の検知結果を組織横断のダッシュボードで見られるようになっています。
分類器別 (PII, プロンプトインジェクション, 責任あるAIなど) の違反傾向
窓口 (surfaces) によるフィルタ (例: Agent Gateway のみ, Agent Gateway + Gemini Enterprise アプリ)
時系列での傾向把握
Model Armor は Agent Gateway や Gemini Enterprise アプリなど複数の箇所に挿し込まれているので, 組織横断で Model Armor の判断結果を確認できるのは CCoE などのチームにとっては嬉しい機能ですよね。
 Agent Platform セキュリティポスチャと AI Compliance Framework
SCC AI Protection には, 標準搭載の検知統制 (detective controls) が用意されています。例えばデータガバナンスの観点では, エージェントが BigQuery / GCS / Cloud DB にアクセスした際に, アクセスパターンからデータの持ち出しを検知する仕組みが追加設定なしで提供されます。カスタマイズも可能です。
加えて今回の目玉発表が AI Compliance Framework です。
Agent Platform 向けのベストプラクティスを統制 (controls) のパッケージとしてまとめたもの
Google の CISO オフィスが「Google Recommended AI」として推奨する deploy 方法の集大成
NIST RMF などの既存コンプライアンス標準にマッピングし, 現状の順守度とアセットの逸脱状況を可視化
Google 自身のベストプラクティスを統制パッケージとして提供し, 既存のコンプライアンス標準とのマッピングまで担う位置付けの機能です。
 Agent Runtime Risk Assessment
ここまで紹介した各機能は「現状の把握」や「個別の違反検知」を担う機能でしたが, Agent Runtime Risk Assessment はそれらから出るシグナルをまとめて取り込み, 攻撃される前にシステムの弱点を洗い出す予防的な分析を担います。具体的には risk engine が virtual red teaming を実施し, 重要な AI リソースに対する実際のリスクを洗い出します。
危険な組み合わせ (toxic combinations) や急所 (choke points) の特定
attack exposure score (攻撃露出度スコア) の算出
修復のための詳細ガイダンス
Aniket 氏は「Thomas (のキーノート) でも出ていた内容」と軽く言及されていました。
 Agent Threat Detection
最後に 実行時の脅威検知 の話でした。Risk Assessment が「攻撃される前の弱点分析」を担当するのに対し, こちらは 実際に発生している悪性活動をリアルタイムで捕捉 する役割です。SCC AI Protection は Google Threat Intelligence / Mandiant のインテリジェンスを取り込んで検知を行っています。基盤は以下4つです。
IAM プリンシパルや既知の脅威アクターに基づく悪性活動検知
Cloud Run などのランタイムから得られる深いシグナル・テレメトリ
アイデンティティに依存しない GCP リソースに対するイベント・挙動監視
複数脅威の相関分析
新たに以下の検知が追加されています。
特権ロール付きエージェントや, エージェントによる権限昇格の検知
不審な認証ワークフローを示すエージェント
悪意あるスクリプト, reverse shell, マルウェアダウンロード, defense evasion (防御回避) の検知
リソースに対するデータ持ち出しや水平移動の検知
エージェント・モデル・MCPツール・データソースをまたいだリスクの相関ビュー
 Equifax における実戦投入 (Vinod 氏パート)セッション後半は, Equifax の Vinod Nannapaneni 氏が, Gemini Enterprise Agent Platform を規制業界でどう使いこなそうとしているかを具体的に共有してくださいました。
 規模感Equifax は米国の大手信用情報機関 (クレジットレポート会社) で, 個人・企業の信用情報という金融規制の対象データを扱う立場にあります。まず規模感として以下の数字が示されました。
Equifax は 毎日 2,000 万件の攻撃から自社を防御
そのうち約半分のチケットは AI エージェントが自動解決
従業員の 約 90% が AI ツールを業務利用中
2023 年以降, AI を組み込んだ製品の出荷数は3倍
毎日 2,000 万件もの攻撃のうち, 半分のチケットを AI エージェントが自己解決しているというのが一番驚きでした。金融関連データを扱う企業がここまで AI 化しているとは, という感じです。
 脅威モデルの変化Vinod 氏は従来の GenAI リスクと agentic AI リスクを2つのグラフで比較して示されていました。
従来の GenAI: 主な懸念はデータ露出 (data exposure)。各社チームはすでに統制済み
Agentic AI: エージェントは自律的に処理を実行するため, リスクが一気に膨らむ
水平移動 (lateral movement) が理論ではなく現実の脅威に
未承認の API 呼び出しが起きうる
エージェントが MCP ツールを呼び出し, 人間向けのインターフェースを介さずに行動できる

「従来のセキュリティレビューは, システムが設計通りに動くことを前提にしていた。しかしエージェントは設計パターンの外側で動く」というフレーズが, agentic 時代の統制が本質的に違うことを端的に言い表していると感じました。
 2つのユースケースではこの脅威モデルの変化を踏まえて Equifax が実際にどんな場面でエージェントを動かしているのか, という話に進みます。Vinod 氏は社内向け・社外向けで毛色の違う2つのユースケースを取り上げて紹介してくださいました。
内部ユースケース: 複数エージェントから成るセキュリティ運用基盤。アラートのトリアージ, シグナル収集, チケットの自動クローズを担い, 各エージェントには固有の役割・ツールアクセス・超えてはいけない境界が定められている
外部ユースケース: 顧客向けの規制データを扱うプロダクト群。金融上の意思決定に関わるため, 出力の正確性 (integrity) とモデルガバナンスを一切崩せない
 アーキテクチャ: 3本柱 + FoundationVinod 氏は自社のエージェントセキュリティアーキテクチャを「3本柱 + Foundation」で整理されていました。
柱1: Define (境界設定)
「エージェントが動き始める前に境界を決める」ための層
Model Armor によって, 開発者が消費できる API をエンタープライズ承認済みのものに限定 → 設計時点で shadow AI を排除
柱の中核はアイデンティティ。従来は専用サービスアカウント運用で「動くが, スケールしない。正しい権限付与を徹底する規律が必要」だった
今回発表された Agent Identity (SPIFFE ベース, 暗号化トークン) は本当に変革的 (transformative) と感じている。すでに非本番環境で試験中
柱2: Protect (能動防御)
すべてのプロンプトとレスポンスを Model Armor + 機微データ保護でスクリーニング
ツール呼び出しやエージェント間アクセスは従来 Apigee を使用していたが, agentic 用途では限界がある
Agent Gateway の採用に向け Google と既に協業中
柱3: Detect (検知)
現状はログベースの検知に依存 (「多くの組織と同じ」とのこと)
ログは「起きたこと」を教えてくれるが, エージェントが本来の業務目的から逸脱した際に監視する術がない
ふるまい異常検知 (anomaly detection) への期待が大きく, 既に環境への導入検討を始めている
Foundation (土台)
Infrastructure as Code でセキュリティをベースラインに組み込み, 構成ドリフトを防ぐ
ポリシーの自動化 (Model Armor 設定, auth ポリシー, forward ポリシーなど) で, 必要な構成を摩擦なくロールアウト
「スケールを可能にするのは摩擦の排除。開発者にセキュリティ作業を増やさず, 正しいことを簡単にやれるようにする」
 Agentic セキュリティの3原則Vinod 氏は締めくくりとして以下3原則を提示されていました。
すべてのIDを分離せよ (Decouple every identity)
各エージェントに専用の最小権限アカウントを持たせる
Agent Identity を使い, 影響範囲を限定する

プロンプトだけでなくアクションをガバナンスせよ (Govern the action, not just the prompt)
Model Armor の導入は重要だが, リスクが現実化するのは実行時であってプロンプト検査時ではない
Model Armor に加えて, エージェントが使うツールそのものをガバナンスすべき

すべてのツールを信頼境界として扱え (Treat every tool as a trust boundary)
MCP は確かに変革的だが, 各ツール接続は脅威ベクタにもなりうる
エージェント本体に適用するのと同じ厳しさをツール接続にも適用する

個人的には2番目の「Govern the action, not just the prompt」が一番刺さりました。プロンプト段階のフィルタリングだけでは agentic 時代の統制としては不十分で, 実行時にエージェントが何をしているかを制御しなければ片手落ち, という指摘は Agent Gateway の位置付けそのものですし, 今後自分が agentic アプリを設計するときにも意識したい考え方だと感じました。
 まとめGemini Enterprise Agent Platform のセキュリティ・ガバナンス機能を Build から Detect まで一気通貫で扱ったセッションでした。ポイントをまとめると以下です。
Agent Platform は Build / Scale / Govern / Optimize の4レイヤーで縦に統合された設計
Agent Identity は「ユーザー / エージェント自身 / エージェント (ユーザー代理)」の3種を明確に区別。SPIFFE ID で暗号的に証明され, ライフサイクル管理も組み込み
Agent Gateway が IAM・Model Armor・ふるまい・セマンティックポリシーの統一実施点
Model Armor はコード変更不要でAgent Gateway やGemini Enterprise アプリにインライン統合
SCC AI Protection は Discover / Secure / Detect の3本柱を提供し, 今回の Cloud Next での新発表として Shadow AI 検出, AI Compliance Framework, ふるまい異常検知, セマンティックガバナンスなどが紹介された
Equifax 事例は agentic 固有のリスク (水平移動・未承認 API 呼び出し・インターフェースなしの行動) を正面から捉え, Define / Protect / Detect + Foundation + 3原則で整理していた
以上, とーちでした。