【セッションレポート】Gemini Enterprise アプリのガバナンス・セキュリティを徹底解説 #GoogleCloudNext
はじめに
お疲れさまです。とーちです。
Google Cloud Next'26 に参加しています。 Gemini Enterprise アプリのガバナンス・セキュリティを扱うセッションを聴講してきましたのでレポートします。Gemini Enterprise アプリ側からの視点で、エージェントの発見からアクセス制御・データ保護・観測性までを整理してくれる内容で、実用度の高い内容でした。（都合により画像撮影しそこねたので登壇スライド画像はなしでお届けします）
セッション概要
タイトル
A deep dive into Gemini Enterprise app governance, security, and compliance
概要
As enterprises graduate from initial AI pilots to full-scale production, the focus shifts from "What can generative AI do?" to "How do we govern and secure it at scale?" Join this technical deep dive that unpacks the multilayered security architecture of Gemini Enterprise app, providing a blueprint for deploying, orchestrating, and governing complex agent ecosystems. We'll go beyond theory into the practical implementation of defense-in-depth strategies, dissecting the three critical AI security layers – content, network, and identity – and demonstrating how to implement centralized governance. You'll leave with a comprehensive enterprise-readiness checklist, equipping you with the specific controls needed to launch secure, compliant AI agents today.
※日本語訳:
企業が生成AIのパイロット導入から本番での全社展開へと進むにつれ、関心は「生成AIで何ができるか」から「どうやって大規模にガバナンス・セキュリティを効かせるか」へと移っています。本テクニカルディープダイブでは、Gemini Enterprise アプリの多層セキュリティアーキテクチャを解き明かし、複雑なエージェントのエコシステムをデプロイ・オーケストレーション・ガバナンスするためのブループリントを提示します。理論だけに留まらず、多層防御 (defense-in-depth) 戦略の実装、コンテンツ・ネットワーク・アイデンティティという3つの重要な AI セキュリティレイヤーの詳細解説、集中的なガバナンスの実現方法を取り扱います。本セッション終了時には、安全でコンプライアンスに準拠した AI エージェントを今すぐ本番投入するために必要な、具体的なコントロール項目を盛り込んだ包括的なエンタープライズ準備チェックリストを持ち帰れます。
スピーカー
- Anusheel Pareek 氏 (Google Cloud, Senior Product Manager)
- Pramod Ramesh 氏 (Google Cloud, Group Product Manager)
加えて、顧客事例パートとして Palo Alto Networks で Director of Infrastructure Engineering and AI Adoption を務める方が登壇されました。
AI スプロールという前提問題
セッションは Pramod 氏による問題提起から始まりました。LLM の登場時、私たちはエンタープライズ内の定型作業を一掃し、生産性を大きく引き上げるという約束を与えられたはずだ、という振り返りです。
しかし現実に組織内で起きているのは、Pramod 氏が AI スプロール (AI sprawl) と呼ぶ状態だと指摘されていました。組織のあちこちで同じ機能のエージェントが重複して作られ、ガバナンスが効かないまま相互に連携し、既存アプリケーションやツール・コネクタ・API の呼び出しも野放しで、どのエージェントがどのデータに触れているかも把握できない、という状態です。
個人的な感触としては、こういう「エージェントが無秩序に増殖してガバナンスが追いつかない」状態に既に陥っているのは、かなり AI 活用が進んでいる企業だなという印象を持ちました。日本の多くの企業の場合は、おそらくクライアント側のエージェント (IDE 統合のコーディングエージェントなど) を個々の開発者が活用するところで止まっていて、全社的に使われるエージェントというのはまだそこまで多くないのではないかなというのが私の感覚です。
セッションのアジェンダはシンプルに3部構成でした。
- Gemini Enterprise アプリが AI スプロール問題をどう解決するか
- Palo Alto Networks が実際にどのように AI 導入とガバナンスを進めているか
- 持ち帰り用のエンタープライズ準備チェックリスト
Gemini Enterprise アプリの位置づけ
Anusheel 氏からは、Gemini Enterprise アプリを「エージェント体験のフロントドア」と位置づける説明がありました。Google として Gemini Enterprise アプリで目指しているゴールは以下の3点と整理されていました。
- 既存のあらゆるエンタープライズデータに、スケーラブルかつセキュアに接続すること
- 開発者・ビジネスユーザーを問わず、全社員に最新の AI ツールや専門エージェントを提供し、エンタープライズの業務コンテキストを踏まえて利用できるようにすること
- ガバナンスを中央集約し、現場の自律性 (AI ツールの民主化) と全社ガードレール・ポリシーを両立させること
Gemini Enterprise アプリを構成する主要な要素として、Anusheel 氏はモデル、標準アシスタント、特化エージェント群、エンタープライズコンテキスト、ガバナンスの5つを挙げられていました。各要素の個別の新機能 (Canvas, Projects, Inbox, long-running agent など) や Gemini Enterprise アプリとエージェントプラットフォーム全体の関係性については、別のセッションレポートでまとめていますので合わせてご覧ください。
本記事で押さえておきたいのは、ガバナンス機能は単独で作り込まれたものではなく、エージェントプラットフォームが提供する基盤的な構成要素（agent registry、agent gateway、agent identity など）の上に成り立っているという点です。
Q&A 形式で読み解く Gemini Enterprise のガバナンス
ここからは Pramod 氏が「お客様役」に入り込み、実際に顧客から寄せられる疑問を Anusheel 氏にぶつけていくロールプレイ形式のデモでした。
Q1. 社内にあるエージェントをどう発見・ライフサイクル管理するか
Pramod 氏の最初の問いは「まず自社にどんなエージェントがあるのかを棚卸しできないとガバナンスは始まらない」という話です。
Anusheel 氏の回答ポイントは次のとおりです。
- Gemini Enterprise 管理コンソールで、Gemini Enterprise エージェントの一覧・作成者・状態・最終利用日時などを一元的に確認できる
- 管理者はラベル付けだけでなく、エージェントの無効化・一時停止 (kill switch) も可能
- エージェントだけでなく、Gemini Enterprise アプリで有効化したデータソース・コネクタも同じ画面から中央管理できる
- 同イベントで別途発表された agent registry には、Gemini Enterprise のエージェントとデータコネクタが自動的に登録され、Gemini Enterprise 以外の Google Cloud 環境上のリソースも含めて横断的に発見できる
- agent registry は単なるディスカバリ用のカタログではなく、agent gateway と統合されてポリシー適用の基盤になっている
後述しますがagent registry では、MCP サーバーも管理できるようでした。
Q2. Gemini Enterprise 外で作ったエージェントやサードパーティのエージェントをどう取り込むか
次の論点は、Gemini Enterprise 内で作ったエージェントだけでなく、社内でカスタム構築したエージェントや ISV 提供のエージェントもまとめて管理したい、という要望への対応です。
Anusheel 氏は「Gemini Enterprise アプリを、組織内のあらゆるエージェントのハブにしたい」と位置づけた上で、以下の統合経路を紹介されていました。
- Agent Engine 上で構築したエージェントとの統合
- Google Cloud Marketplace 経由でサードパーティエージェントを取り込む経路
- A2A エージェントのサポート (A2A カードの情報を参照して数クリックで追加可能)
- agent registry 連携による新しいワークフロー — 管理者が registry 上でエージェントを一覧し、クリックスルーで Gemini Enterprise アプリに組み込める
registry 経由で追加されたエージェントは「ガバナンスされた経路 (governed path)」を通ることになるため、いわゆる シャドウ AI の発生を抑えられる、という話でした。統合方法が整っているだけでなく、「統合したら自動的にガバナンス下に入る」という設計が良いなと思いました。
個人的にこのセクションで面白かったのは、そもそも サードパーティがエージェントを提供する という発想が前提になっていた点です。Gemini Enterprise では Google Cloud Marketplace 経由でサードパーティエージェントを取り込める仕組みが整えられていて、エージェントの流通基盤・マーケットプレイスをクラウドベンダー側で作っていこうという思想が垣間見えたのが新鮮でした。ちなみに AWS 側でも AI agents and tools in AWS Marketplace という同様の仕組みはあるようです。
Q3. API / MCP / ツール・スキルも同じレジストリで管理できるか
エージェントだけではなく、API や MCP サーバー、ツール、スキルも同じ仕組みで管理したい、という質問です。
Anusheel 氏の回答はシンプルで、同じ agent registry が MCP サーバーとスキルにも対応している というものでした。
- コネクタ基盤が代表的なアプリケーションのデータソースには対応済み
- ただし、多くの企業が独自データを MCP で公開しているため、registry 上で MCP サーバーを一覧し、クリックスルーで Gemini Enterprise アプリに追加できるようになっている
- 追加時には、MCP サーバーが提供するツールの 一部だけ を選んでアプリに統合することも可能
- 追加された MCP サーバーは Gemini のチャット基盤 (標準アシスタント) のコンテキストとして使えるほか、社員が自分のエージェントのノードとして利用することもできる
「必要なツールだけを選んで公開できる」というのは、なかなか良いなと思いました。別製品ですが、以前、組織的に統制をかけたい場面でこういう粒度での制御ができるといいなと感じたことがあったので、これは嬉しい機能だなと思います。
Q4. エージェントの共有はどこまで許すか
作ったエージェントの共有範囲の制御についてです。
- Gemini Enterprise の管理者は、各エージェントのライフサイクル管理に加えて、共有範囲 (特定ユーザー・特定チーム・全社) も制御可能
- 一方で、社員が作ったエージェントは本人以外の同僚やチーム全体にも便利であることが多いため、社員同士での共有機能も提供されている
- ただし、デフォルトで 社員同士の共有には管理者の承認が必要 というガバナンス設計になっている
社員間の共有も可能だが、デフォルトで管理者の承認が必要ということでガバナンスとしてバランスが取れているなと思いました。
Q5. エージェントは何にアクセスでき、何ができるのか — agent identity と agent gateway
ここで Anusheel 氏から、Next で新しく発表された2つの基盤的な構成要素が紹介されました。
agent identity
- エージェントは作成時点で、一意で変更不能な ID を付与される
- この ID は、エージェントが行うすべての操作に紐付く (ユーザーの代理として動くときも、自律的に動くときも)
- 常に監査対象として参照可能
agent gateway
- 複雑なネットワーク設定を、フルマネージドのサービス1つで置き換える
- エージェントと他のエージェント・データソース・MCP サーバーなどのターゲットとの間のトラフィックをすべて取り扱う
- 統一されたポリシー適用ポイント として機能する
- 単一障害点 (single point of failure) ではなく、Google のネットワーク基盤の上に乗った API 抽象層である
この2つを組み合わせることで、以下のようなアクセス制御ポリシーを書けるようになります。
- 特定エージェントがアクセスできるエージェント・データソースを制限
- 条件付きルール (例: MCP サーバー内で特定ツールのみ、特定メソッドのみアクセス可) を設定
- 具体例として「Workspace の MCP サーバーにアクセスしてメールの読み取りはできるが、メール送信はできない」というポリシー
さらに、agent gateway はサービス拡張 (service extensions) やサードパーティ製品にも対応しているため、Palo Alto Networks のセキュリティ製品をエージェントのランタイムに組み込む、といった構成も Google Cloud Marketplace 経由で実現可能だと紹介されていました。
Q6. コネクタ経由のデータアクセスとゼロトラスト
次はデータ側、つまりコネクタを経由した業務アプリへのアクセス部分です。
Anusheel 氏は、Gemini Enterprise アプリはゼロトラストの原則として zero ACL leakage (ACL 漏れゼロ) を採用している、と説明されていました。
- Gemini Enterprise アプリに業務アプリを接続しても、ユーザーの権限は常にそのまま尊重・適用される
- 元のアプリで閲覧権限がないデータは、Gemini Enterprise アプリ経由でも絶対に見せない
- OAuth 2.0 の業界標準とベストプラクティスで実装されている
- Gemini Enterprise のコネクタはエージェント的な検索 (agentic search) を行うため、データは元アプリ側に留まり、Gemini Enterprise アプリ側にコピー・取り込みされない
- 結果として、うっかり生じる ACL 漏れも防げる
ユーザー権限を適用しつつデータ閲覧ができる点はいいですね。他の AI エージェントでもいえることですが、今後は AI エージェントからつながる先の、ここで言うとワークスペースの権限やメールの権限などですね、個人がアクセスできる範囲というのを、今まで以上にしっかり設計する必要があるというのを感じています。
Q7. AI は間違うので human in the loop を前提にする
Pramod 氏からは「AI システムは間違えるので、エージェントが外部アプリに書き込みアクションを行う場合（メール送信や Jira チケットの更新など）には human in the loop が必要だ」というコメントが差し込まれていました。
- Gemini Enterprise アプリの外側に影響する操作は、常に human in the loop
- これはデザイン原則として組み込まれている
human in the loop がデフォルトで組み込まれているのはいいなと思いました。個人が使う AI ツール (Claude Desktop など) では MCP サーバーのツールやスキルを使う際には、書き込み系の操作にどう人間の確認を挟むかを個々人が設計・設定する必要があります。一方、Gemini Enterprise のように AI エージェントが個人のローカルではなく組織が管理するクラウド基盤側にホストされている状況だと、管理者が書き込み系のアクションに対して human in the loop を一括で強制するといった統制を効かせられるメリットがあるんだなと感じました。
Q8. 観測性 (オブザーバビリティ)
「測れないものは改善できないし、スケールもできない」という話題です。Gemini Enterprise アプリとエージェントプラットフォームでは、観測性が複数レイヤーで用意されているとのこと。
- アプリレベルのダッシュボード: Gemini Enterprise アプリ全体の利用状況の俯瞰。アクティブユーザー数、継続率 (retention rate)、組織内でよく使われているエージェントの上位など
- エージェントごとのメトリクス: レイテンシ、エラー率、リクエスト数、ツール呼び出し回数など
- OpenTelemetry 準拠のトレーシング: セッション単位で、どのツールが呼ばれたか / 各ホップのレイテンシ / セッションを開始したユーザー / 同一セッションに関与した他エージェントの有無などを確認可能
- OpenTelemetry 準拠のため、外部の観測性プロダクトにエクスポートして分析することもできる
アプリレベルのダッシュボードやエージェントごとのメトリクス、トレーシングといった計測がデフォルトで組み込まれているのは嬉しいですね。
Q9. プロンプトインジェクション対策 — Model Armor
Pramod 氏からは、マクドナルドのエージェントにハンバーガーを注文したついでに「Python でフィボナッチ数列を生成してくれ」と頼んだら実際に生成してしまった、という記事があった、という小噺が紹介されました。
これに対する回答が、Gemini Enterprise と深く統合された Model Armor です。
- 数ステップの設定で Gemini Enterprise の ingress (入口) に Model Armor を有効化できる
- すべてのプロンプトとエージェントからの最終レスポンスが Model Armor でスキャンされ、フラグ付けされたものは自動的にブロックされる
- 事前定義の検出器で、直接・間接のプロンプトインジェクションに加え、有害コンテンツ、PII (個人情報)、金融情報などの機密データ、安全でない URL への対策もカバー
- Model Armor は SDP (Sensitive Data Protection, 機密データ保護) とも連携
- Gemini Enterprise アプリ利用者に追加費用なしで提供される 点が強調されていた
マクドナルドの件は私も X で話題になっているのを見ていたので、実際に発生しているケースと絡めて Model Armor の有効性を紹介されているのは、ありがたみが伝わってきて非常に良いなと思いました。
Q10. 機密データの取り扱いと SDP
企業にとってデータは競合との差別化の源泉なので、機密情報や PII の流出防止は極めて重要、という話です。
- Model Armor が ingress (プロンプト) と egress (レスポンス) のスキャンを担い、加えて各データコネクタに SDP (Sensitive Data Protection) ポリシー を個別に設定できる
- Model Armor 自体も内部で SDP と統合されており、PII や機密データの検出は SDP の分類器を利用している
- コネクタ側の SDP ポリシーは、データソースから AI にデータが渡る前に機密情報をフィルタし、機密・秘匿情報を AI が見てしまうこと自体を防ぐ
- SDP には 200 を超える自然言語理解ベースの分類器 (classifier) があり、独自分類器も作成可能
- Microsoft の機密度ラベル (sensitivity labels) を自動的に認識 するため、"Confidential" や "Sensitive" とタグ付けされたドキュメントは常にブロックされ、AI からアクセスできない
SDP の InfoType detector reference を確認すると、日本固有の infoType detector として JAPAN_PASSPORT (パスポート番号)、JAPAN_DRIVERS_LICENSE_NUMBER (運転免許証番号)、JAPAN_INDIVIDUAL_NUMBER (マイナンバー / 個人番号)、JAPAN_CORPORATE_NUMBER (法人番号)、JAPAN_BANK_ACCOUNT (銀行口座番号) が用意されています。日本の機密情報もカバーされているので、国内利用でもそのまま活用できそうです。
Palo Alto Networks の AI 導入ジャーニー
ここからは顧客事例パートで、Palo Alto Networks から登壇された Director of Infrastructure Engineering and AI Adoption の方が、同社の AI 導入ジャーニーを語るセクションでした。
エンジニアとの会話から見えた「エージェントスプロール」
登壇者の方が社内のエンジニアと話していたときのエピソードがとても印象的でした。
ある日、エンジニアに「何をしているの?」と聞いたところ、そのエンジニアは Pull Request の対応をしており、しかも「Pull Request と会話している」と答えたそうです。誰と話しているのか聞くと、「これは私の SRE 用エージェント、こっちは業務コミュニケーション用のエージェント」という返答でした。
この話を聞いて登壇者の方が感じたのは「素晴らしい」と同時に「社内のエンジニアは、一人あたり少なくとも2つのエージェントを持っている時代になった」ということで、冒頭で語られた エージェントスプロール の実例そのものだと感じた、という文脈でした。
導入フェーズの変遷
Palo Alto Networks の AI 導入はおおむね以下のフェーズをたどったと整理されていました。
- 初期: R&D チームはコードを自分で書くことに慣れていたため、AI 採用はむしろ一苦労。対照的にビジネスサイドは、R&D に依存せず自分で問題を解ける魅力に素早く反応し、研修と合わせて導入が進んだ
- 変革期: 誰もが100個のユースケースを抱え、自分を毎日悩ませる小さな問題を自力でエージェント化しようとし始めた
- 現在 (スケール・最適化フェーズの途中): 全員が100個のエージェントを持ち、さらに増やそうとしている状況。ロールベースアクセス制御、ガバナンス、長期サポート性、運用負荷を増やさない仕組み作り、コスト最適化、プラットフォーム統合 (IDE 系、オーケストレーション系などが混在) が課題
「とにかく可視性の欠如が最大のブロッカーだった」という言葉が非常にリアルでした。エージェントは本来 非決定的なワークフロー を扱うものなので、事後的にでも何が起きたか分からないと、セキュリティファーストな同社としては先に進めなかった、とのことでした。
可視性を得るために使っているツール群
Palo Alto Networks では、同社自身のセキュリティ製品群と Google Cloud 側の仕組みを組み合わせて、エージェント利用の各レイヤーを保護しているという説明がありました。
- AS (AI Runtime Security): AI のランタイム保護を担い、Google Cloud 側の基盤と連携
- 次世代ファイアウォール: ネットワーク層の検査・制御
- Prisma Browser: ユーザーとエージェントの対話レイヤーで、何が起きているかの可視性を提供
- XSIAM: 自社の SIEM/SOAR 基盤。上記の情報を収集・コンテキスト化・ガバナンスと自動アクションに繋げる
Gemini Enterprise 採用の判断基準
「AI オーケストレーションツールの選定基準は?」という Pramod 氏の質問に対して、登壇者の方はセキュリティファーストな会社として以下を挙げられていました。
- どれだけの可視性 (visibility) が得られるか
- 業務を楽にしてくれるか、それとも逆に複雑にするだけか
- プロダクトの境界 (boundary) をどう定義できるか
- 何が起きているかを把握し、問題があったときに行動 (action) を取れるインターフェースがあるか
「エージェントがデータベースを削除してしまった」といった他社事例が話題になるなか、意図しないことが起きたときに何が起きたかを確認して対処できることが最重要、という視点でした。セキュリティの会社らしい観点だなあと納得しました。
実際に立ち上がったユースケース
具体例として挙げられたユースケースがとても生々しくて良かったです。
- 経営層の日常業務: 自動化メール以外でも 1 日最低 400 通のメールを読み、週次レポートを作り、10 〜 20 件の会議に出る、という状況 — 合計で週 10 〜 20 時間。Gemini Enterprise のコネクタと可視性により、これが数秒〜数分単位に短縮。個人アシスタントのように今日やるべきことをまとめてくれ、抜けた項目も指摘してくれる
- 経費精算・出張費の異常検知: 従来は財務チームの手作業が多く、「自分の経費が通るのか、自腹になるのか」という不安を社員に与えていた。AI エージェントによる異常検知で、申請者・承認者双方の体験を改善した初期ユースケース
- エンジニア業務の効率化: Jira のチケット群とプロジェクトの対応関係を把握し、Confluence のページに紐付け、Google Drive のドキュメントを整理する、といった作業。本来は 20 人の関係者を会議室に集めて初めて全貌を掴んでいたような業務を、各所の議事録や資料から AI が要約することで省略できる
Gemini Enterprise でこういったユースケースを実際にどうやって解決していくのか、具体的なやり方のイメージが私の中でまだ掴めていないので、まずは何か一つでもユースケースを解決するエージェントを Gemini Enterprise で作ってみたいなと思いました。
AI 導入リーダーとしてのアドバイス
最後に「セキュリティガバナンスの観点で AI 導入を進めるリーダーとして、一つアドバイスを」と問われ、登壇者の方は以下の趣旨のことを話されていました。
- 2 年前は「なぜ AI を使うのか」と言われる状態だった。しかし 1 年後には 100 個のユースケースが挙がってくるようになった
- ここで必要になるのは セキュリティ観点だけでなく、ビジネス価値・境界・データプライバシー・運用化・スケール観点でのガバナンス
- 「20,000 個のエージェントが何をしているか分からない状態」は失敗・事故のレシピ
- ユースケースを洗い出し、ブレインストーミングし、そのまとめ自体をエージェントに任せて 「この 20,000 個のエージェントは、実は 20 個で代替できるのでは?」という観点で整理する
「20,000 が 20 に集約できるかもしれない」という視点はとても面白かったです。民主化して増やすフェーズが終わったら、今度はその棚卸しと統合に AI 自体を活用していく、という次の一手の話として勉強になりました。
持ち帰るべき 5 つのチェックリスト
セッションの締めくくりとして Pramod 氏が提示されたのは、エンタープライズ AI ガバナンスのチェックリストでした。
- エージェントの一元カタログを作る: 社内のあらゆるエージェントを 1 つの画面で発見・ライフサイクル管理できる仕組みが必要。Gemini Enterprise に統合された agent registry のような機能で実現可能
- エージェントの民主化 × 正しい監査を両立する: エージェントの共有・民主化を進めるなら、誰が作った・誰の代理で動いた・何をしたかを追跡できる監査の仕組みが前提として必要。Gemini Enterprise 標準の agent identity により、エージェントが何をしたかを追跡・監査できる
- 単一のポリシー適用ポイントを持つ: エージェントが様々な経路で同一システムにアクセスする状態はガバナンス崩壊。Gemini Enterprise に統合された agent gateway により、単一の制御点でポリシーを適用する
- コネクタ経由のデータを守る: プロンプトインジェクション、機密データ、社内のラベル情報 (Microsoft Purview 連携を含む) を含め保護が必要。Model Armor と Sensitive Data Protection (SDP) を使い、カスタムコードでのポリシー定義を含めて守る
- エージェント観測性を組み込む: 何が動いているのか、いつ動いたのか、どれだけ使われているのか、何にアクセスしたのか、性能とレイテンシはどうか — これらは OpenTelemetry ベースで Gemini Enterprise エージェントプラットフォームが標準提供する
所感
全体を通して、Gemini Enterprise アプリ側の視点から見た「エージェントガバナンス」の全体像を、実装レベルの具体例と顧客事例込みで把握できたのがとても良かったです。
特に印象に残ったのは以下の 2 点です。
- エージェントを組織で共有するという考え方が前提になっていて、そうすることでガバナンスを確保できる という設計思想。個人ごとにエージェントを抱え込むのではなく、組織として一元的に見える状態にすることでガバナンスが効くようになる、という整理は非常に良いなと思いました
- Q&A 形式で課題と解決策をセットで提示していた構成。顧客から実際に出そうな疑問に対して、Gemini Enterprise のどの機能がどう答えるかがそれぞれ対応づけられていて、非常に分かりやすかったです
今後試してみたいのは、agent gateway のポリシー定義の具体的な設定方法と、Model Armor / SDP のデフォルト検出器でどこまで実運用に耐えるか、というあたりです。機会があれば別途検証してみたいと思います。
以上、とーちでした。
