はじめに
先日開催されたGoogle Cloud Next Tokyoにおいて、「企業でのセキュリティも考慮したAI Agent導入の最適解とは」と題されたセッションに参加しました。このセッションは、企業におけるAIエージェントの導入をセキュリティの側面から深く掘り下げたもので、特にGoogleのサービスを活用した具体的な対策について詳細な解説がなされました。
セッションの概要
このセッションは、「企業でのセキュリティも考慮したAI Agent導入の最適解とは」と題され、AIエージェントの導入方法とそのセキュリティ対策が主要なテーマとして取り上げられました。特に、AIの活用が進む中で避けては通れないセキュリティの課題に対し、Google Cloudが提供するソリューションやフレームワークを用いた具体的なアプローチが紹介されました。
セッションの内容
セッションでは、まずGoogleのAIエージェントサービスであるGoogle Agentspaceの紹介から始まり、その導入時の注意点、そしてセキュアな利用を実現するための様々な対策が解説されました。
1. Google Agentspaceとその導入のポイント
Google Agentspaceは、企業内でのAI活用における大きな課題であった「ハルシネーション（AIが事実と異なる情報を生成すること）」の問題を解決するために設計されたSaaS型サービスであると説明されました。従来のNotebookLMが個人でのデータソース指定やファイルアップロードを必要としたのに対し、Google Agentspaceは社内外のデータソース、特にGoogle Workspaceを利用していない企業がよく使うBox、Microsoft 365（SharePoint、OneDrive）といった他社サービスと直接連携し、それらをデータソースとして利用できる点が大きな特徴であると述べられました。これにより、ユーザーが個別にファイルをアップロードする必要がなく、社内の既存データを活用できるとされます。
Google Agentspaceを導入する際の重要なポイントが三つ挙げられました。
- 情報ソースの特定と整理: まず、企業内でAIに利用したいデータがどこに存在するか（オンプレミスのファイルサーバー、Box、OneDriveなど）を特定することが重要であるとのことでした。データが1箇所に集中しているか、分散しているかを確認し、そのデータをどう活用したいかを明確にする必要があると強調されました。また、データを有効活用するためには、事前に整理していくことも不可欠であると指摘されました。
- 認証基盤連携とソース接続の設計: Google AgentspaceがBoxやMicrosoftサービスに接続する場合、シングルサインオン（SSO）による認証基盤の連携が前提となるとのことでした。企業が現在どのようなSSO（例: Entra ID, Okta, OneLogin, Hengeなど）を導入しているかを把握し、GoogleアカウントとのSSO設定を行う必要があると説明されました。クラウドサービスを頻繁に利用している企業であれば、SAML連携が容易であるため、設定自体はそれほど難しくないとの見解が示されました。
- 段階的な導入と効果検証: 社内に大量のデータが存在する場合（特にBoxのように容量無制限で何でも詰め込まれがちな場合）、無関係なデータまでAIが学習してしまうリスクがあるため、段階的な導入が推奨されました。具体的には、まず特定の部署で50人から100人程度の規模で導入し、接続するデータソースを限定して効果を検証することが提案されました。これにより、データソースが多すぎるなどの問題点があれば、整理したり、一時的にGoogle Driveのような別の場所にデータを移行するといった対策を検討できると述べられました。
2. Google Agentspaceのセキュリティ
Google Agentspaceのセキュリティにおける最大の利点は、シングルサインオン（SSO）連携を通じて、ユーザーごとの参照権限が維持された状態で利用できることであると強調されました。これは、AIが個々のユーザーに見える範囲のデータのみを学習や回答に利用するという仕組みを意味します。例えば、経営層の機密情報が格納されたストレージが一般社員と同じであっても、経営層には見えるが一般社員には見えない、あるいは一般社員間のプロジェクト情報は経営層には見えないといった制御が可能であると説明されました。これにより、他の生成AIサービスのようにデータソース全てから情報を引き出してしまうリスクが排除され、適切なデータソースのみが利用できる点がGoogle Agentspaceの優れている点であると述べられました。
3. Chrome Enterprise Premiumの活用
Google Agentspaceのセキュリティをさらに強化するプロダクトとして、Googleが提供するChrome Enterprise Premiumが紹介されました。Webサービスが主流となり、ブラウザが企業のデータエンドポイントとなる現代において、Google Chromeのトップシェアを活かしたセキュリティ強化がこのプロダクトの目的であると説明されました。
主なセキュリティ機能として、以下が挙げられました。
- データ損失防止機能（DLP）: ダウンロード時のURLチェックによるウイルス検知・ブロックや、機密情報（例：社内機密情報、個人情報、クレジットカード番号など）が含まれるファイルのアップロード阻止機能があると説明されました。これにより、Google Agentspaceで扱う社内データは安全に保護され、許可されていないChatGPTなどの外部AIサービスへの機密情報アップロードやスクリーンショットの禁止も可能であると述べられました。
- アクセス制御とゼロトラスト: 従業員のブラウザ上での振る舞いをログとして記録し、Google SecOps（旧Chronicle）やSplunkのようなSIEMソリューションに連携して分析できるとのことでした。また、社内ネットワークからのアクセスは許可するが、自宅からのアクセスはブロックするといったゼロトラスト制御が可能であり、これは従来のクラウドプロキシやZscalerのような製品なしにChromeブラウザ側で実現できると強調されました。
- ログイン制御と情報流出対策: 会社のGoogleアカウント以外ではChromeブラウザにログインさせないといった制御も可能であり、これにより個人Gmailの利用などによる情報漏洩リスクを防げると説明されました。これらの機能を活用することで、Google Agentspaceや社内AIのセキュリティを強化できるとのことでした。
CTCでは、Google Agentspaceの導入支援パッケージも提供しており、Box連携などを事前構築した検証環境を試せる「Google AgentSpace 共同PoC」や、顧客のGoogle Cloud環境に構築する「Google AgentSpace 導入パッケージ」が用意されていると紹介されました。
4. カスタムAIエージェントのセキュリティ対策
セッションの後半では、SaaS型AgentSpaceだけでなく、Google Cloud上で個別にAIエージェントを構築する場合のセキュリティ対策について詳細が語られました。
AIエージェントの概要と活用手段
AIエージェントとは、LLM（大規模言語モデル）とRAG（Retrieval Augmented Generation）の組み合わせに加え、外部サービスへのアクション実行能力、そして目標達成のために推論を繰り返す自律性を持った新しいAIアプリケーションであると定義されました。Google CloudでAIエージェントを活用する手段は大きく分けて三つあると説明されました。
- SaaS型（AgentSpace）: ノーコードで連携先を登録するだけでエージェントを構成できる、いわゆるSaaS型のサービスです。
- PaaS型（Vertex AI）: Google Agentspaceでは対応できない業界特有の処理や、独自のシステム連携が必要な場合に利用されます。プラットフォームの管理はGoogle側が担い、ローコードで開発が可能であると述べられました。
- IaaS型（Cloud Run, GKE, Compute Engineなど）: 独自AIモデルを用意する場合や、GPUを利用する場合に、Cloud Run、GKE、Compute EngineといったIaaSサービスを利用してカスタムエージェントをホストする形式です。また、オンプレミス環境でGeminiを利用するGoogle Distributed Cloud (GDC)もIaaS型ソリューションに含まれるとのことでした。
不適切な扱いによるリスク
AIエージェントを適切に扱わない場合のリスクについて、具体的な事例が示されました。例えば、社員の「人事評価をどうすればもっと良くできるか」という問いに対し、先輩のロールモデルを基にした人事ナレッジベースのAIエージェントを試作した例が挙げられました。このエージェントに、虚偽の職歴データソースを登録し、プロンプトで特定の社員の個人情報を尋ねると、AIが要求通りに個人情報を漏洩させてしまうというデモンストレーションが行われました。
この漏洩が起きた要因として、いくつかの点が指摘されました。
- プロンプトとアウトプットの制御不足: 不正な要求をそのまま通してしまい、個人情報を含む出力がフィルタリングされなかったこと。
- 不適切なデータ管理: 個人情報がマスキングされずに生データ（ローデータ）のまま管理されていたこと。
- 過剰なアクセス権限: エージェントが個人情報というデータに対して過剰なアクセス権限を持っていたこと。
このような問題は、CSIの欠陥ではなく、ユーザーが負うべき責任を十分に果たしていないために起きるとの見解が示されました。
責任共有モデル
Google Cloudの責任共有モデルが重要であると強調されました。これは、Googleが管理する範囲（青いブロック）と、ユーザーが負うべき責任の範囲（白い部分）を明確に区別するものです。SaaS、PaaS、IaaSの各モデルにおいて、ユーザーは、入出力データの管理、アクセス管理、データガバナンスといった領域で責任を負う必要があると説明されました。
セキュリティ対策のフレームワーク/ガイドライン
AIエージェントのセキュリティ対策を考える上で参考となる二つのフレームワークとガイドラインが紹介されました。
- Google Secure AI Framework (SAIF): AIエージェントを構成するデータ、アプリケーション、モデル、インフラストラクチャといった各コンポーネントにおけるリスクと対策が体系的に整理されており、網羅性が高く有用であると推奨されました。
- OWASP Security Project (OWASP GenAI Security): Webアプリケーションのセキュリティ標準化で知られるOWASPが、2023年春からAIエージェントに特化したガイドラインの策定を開始しているとのことでした。プロンプトインジェクションだけでなく、エージェントのコード実装（例：LangChain）やコンテキストエンジニアリングなど、トレンドに合ったセキュリティリスクと対策が日々更新されていると紹介されました。
モデルへの入出力制御
モデルへの入出力制御は、AIエージェントにおけるセキュリティの要となると説明されました。
- プロンプトフィルタリング: 不正なプロンプト（例：個人情報の聞き出し、法的・倫理的に許容できない要求、プロンプトインジェクション攻撃）を拒否する対策です。
- アウトプットフィルタリング: 個人情報や機密情報、反社会的な情報が含まれる出力を検出し、事前にブロックする対策です。これにより、不適切な人事情報の漏洩などが防げると説明されました。
Google Cloudでは、PaaSやIaaS型のモデル向けに、入出力制御専用のWeb Application Firewall（WAF）のような「Model Armor」が提供されており、API呼び出しによってプロキシとして機能すると述べられました。Google Agentspaceでは直接Model Armorを利用できないものの、システムプロンプトやガードレール機能を使ってフィルタリングを実装することが可能であると補足されました。
取り扱いデータの管理
データの管理における対策は、個人情報や機密情報の漏洩リスクを低減するために重要であると述べられました。
- 機密情報の検出と特定: 参照データに個人情報や機密情報が含まれていないかをチェックし、どこにそうした機密データが格納されているかを特定すること。
- 情報の匿名化: 個人を特定できないように抽象度を高めたり、マスキングを行って無害な情報に変換する「匿名化」処理。これにより、キャリアパスの提示のようなデータ活用を安全に行えるようになると説明されました。
Google Cloudでは、「Sensitive Data Protection (SDP)」と「Data Loss Prevention (DLP)」が利用可能であると紹介されました。これらを活用することで、AIエージェントが参照する社内データや個人情報において、機密情報を検出してマスキングでき、取り扱ってはいけないデータが何か、どこにあるかを効率よく監視し、漏洩リスクを防ぐことができると述べられました。
アクセス制御
アクセス制御は、主に二つの側面から対策が語られました。
- エージェントへのアクセス制限: AIエージェント自体が過剰な権限を持ち、無制限にデータに触れたり、外部システムを認証できてしまう状態を抑制する対策です。
◦ Privileged Access Management (PAM): 特権管理により、エージェントを管理する時間やメンバーを限定できる。
◦ 組織ポリシー: 利用可能なGoogle APIやサービス、モデル（例：Geminiのみに特定）を制限し、組織全体に強力な統制をかけることができる。
◦ VPC Service Controls (VPC SC): 特定のネットワークや端末からでないとAIエージェントシステムにアクセスできないように制限することが可能である。
- エージェントから外部へのアクセス制御: AIエージェントが主体となって外部にアクションを起こす際に、無制限にコードが実行できてしまう状態を防ぐ対策です。
◦ Principal Access Boundary (PAB): エージェントがアクセスできるGoogle Cloudの範囲を制限できる。
◦ IAM拒否ポリシー: エージェントのサービスアカウントからIAM権限を強制的に剥奪できる。
◦ VPC Service Controls (VPC SC): ここでもVPC SCを活用することで、外部のGoogle CloudへのAPIアクセスを最小単位に抑えることが可能である。
これらの対策は、AIエージェントシステム全体に関わるアクセス制御として、効率的かつ多層的なセキュリティ強化を実現すると締めくくられました。
まとめ
今回のセッションを通じて感じたのは、AIエージェントの導入は「便利さ」と「安全性」をどう両立させるかが最大のポイントだということです。Google Agentspaceのように既存のデータソースと直接連携できる仕組みは、現場の業務効率を一気に高める可能性を秘めていますが、それと同時にアクセス制御や情報の匿名化など、事前のセキュリティ設計が欠かせないことも強く実感しました。
特に印象的だったのは、SSO連携による権限の維持や、Chrome Enterprise PremiumによるDLP機能など、Googleのエコシステム内で完結するセキュリティ強化のアプローチです。これらは、運用負荷を最小限にしながら安全性を確保するという点で、企業にとって非常に現実的だと感じました。
簡単30秒