[Google Cloud Next '26 Las Vegas] IAMの今後の展望：AIエージェントのセキュリティ、ガバナンス、およびランタイム防御

Google Cloud Next '26 Las Vegasとは

Google Cloud Next '26は、2026年4月22日から4月24日の3日間、アメリカ・ラスベガスのMandalay Bayにおいて開催されるGoogleのクラウドサービスに関する世界最大級のイベントです。「ディープ ラーニング、刺激的なセッション、共同での問題解決など、充実した 1 週間になることでしょう。業界の専門家や、あなたと同じ課題や機会に直面している同業者から直接学ぶチャンスです。Next 26 を終える頃には、他では得られない斬新なアイデア、最先端のスキル、行動につながる知見を身につけていることでしょう。」と銘打っており、AIコンテンツで大いに盛り上がった昨年や一昨年にも勝るとも劣らないイベントとなることが期待されます。

私たちNTTインテグレーションも、Google Cloudに精通した専門家として、技術イノベーションの最新動向を取り入れ、顧客に対するソリューション提供に活かしていくことを目指して参加しています。

このような貴重な機会ですので、現地からいち早くブログで最新情報や熱量を発信してまいります。

本記事で紹介するセッション概要

• 講演日時：2025年4月23日 11:00 - 11:45 GMT-7
• セッションタイトル：What’s next in IAM: Security, governance, and runtime defense for AI agents
• 登壇者
  • Abhishek Hemrajani
    • グーグルクラウドの製品管理担当シニアディレクター
• セッション内容のサマリ
  • AIを成功裏にスケールアップするには、信頼が不可欠です。そして、その信頼はゼロトラストアーキテクチャから始まります。Google Cloudは、企業がビジネスデータに基づいたエージェントを構築・管理できるよう支援します。エージェントID、IDおよびアクセス管理（IAM）、ポリシーベースのセキュリティ制御、そしてModel Armorによるランタイム防御といった最新のスタックによって、エージェントはしっかりと保護されます。このセッションでは、GoogleがどのようにAIエージェントを保護しているか、そしてこれらの機能がどのように次世代クラウドコンピューティングの信頼基盤を再構築しているかを探ります。

なぜこのテーマが重要か

登壇者のHemrajani氏はまず、冒頭のスライドでGoogle Cloudのセキュリティプラットフォーム全体像を示しました。セキュアな基盤（Google Cloud自体）の上に、Resource Manager・Identity・Access Management・Access Riskが積み重なる構造です。このスタック全体にわたって今年も多くのアップデートが出ており、中でも目を引いたのは以下の点でした。

•  Custom Org Policyが130以上のGoogle Cloudプロダクトに対応 
•  Gemini-powered Role RecommenderがGAに（役割の選定を大幅に簡略化） 
• MFAを全顧客の必須要件とする取り組みが進行中 

   

しかし、Hemrajani氏は「去年ならこれで話が終わっていた」と話されていました。2026年の今、人間のIAMの話だけではもう足りていないというところからエージェントアイデンティティのトピックの説明に進みました。

•  エージェントのアイデンティティの数は人間アイデンティティの80〜100倍（「200倍」という試算もある） 
• セキュリティ実務者の88%が「特権ユーザー＝人間」と捉えている
• すでに存在するエージェントの42%が過剰な権限を持っている

人間でさえ付与された権限の3%しか実際には使っていないそうです。そして、エージェントはその余った97%でも動いてしまいます。2010年代に人間向けに設計されたIAMの考え方をそのままエージェントに当てはめても機能しないのは、こういう理由からなのだそうです。

ということで、次の章からセッションの内容をさらに詳細に紹介していきます！

セッション内容

エージェント向けセキュリティ新スタックの全体像

Hemrajani氏が重要なスライドの紹介として投影したのは、エージェント向けセキュリティスタックを示す図でした。構成は3つの水平レイヤーと3つの制御ピラーからなっています。この新スタックに関する発表が

水平レイヤー（基盤）

スタックの土台となる水平レイヤーは、次の3層で構成されます。

縦軸ピラー（制御）

水平レイヤーを貫く縦軸として、3つの制御に関するピラーが定義されています。

Agent Identity：サービスアカウントとの根本的な違い

セッションの最後に設けられたQ&Aでも最も多かった質問のひとつが「サービスアカウントとAgent Identityは何が違うのか」でした。Hemrajani氏の回答をまとめると以下のとおりです。

GKEについてはまだ次四半期まで待つ必要があるそうですが、もしAgent Identityが利用可能になったらすぐに移行することをHemrajani氏は繰り返し強調していました。

また、Agent Identityは3種類のアイデンティティタイプをカバーします。

1. 協働（Collaboration）：人間がエージェントと連携する際のアイデンティティ
2. 自律動作（Agency）：エージェントが自らのアイデンティティでリソースにアクセスする
3. 委任（Delegation）：人間に代わってエージェントが外部サービスに投稿・操作する

今回新たにAgent Identity Auth Manager（Preview）が発表されました。OAuthフローをエージェント実装側が意識せずに処理できる仕組みで、開発者の認証実装コストを大幅に削減するとのことです。

アクセス管理の多層防御

エージェントのアクセス管理は「ゼロデイから防御を積み上げる」設計でなければならない、というのがセッションを通じたメッセージでした。具体的には4つの制御を重ね合わせます。

• Allow Policy：何を実行できるかを定義する
• Deny Policy：Allowより優先されるブラックリスト。条件付きで特定操作を禁止する
• Human in the loop：エージェントがアクションを起こす瞬間に人間が介入・承認する
• Agent Access Boundary（Principal Access Boundaryの進化形）：付与権限の多寡に関わらず、エージェントが操作できる範囲を上限として絞り込む

将来提供予定のUnified Access Policyでは、Allow/Deny/条件/コンテキストを1つのポリシー定義にまとめられるようになります。GCPリソースだけでなくMCPサーバー・他エージェント・外部ツールへのアクセスも同一ポリシーで管理できるとのことです。

デモ：Spend Optimizer Agent "Spark"

デモでは「Spock」という名のSpend Optimizer Agentが登場しました。Google ADKで構築し、Agent Engineにデプロイした後、Agent Registryに自動登録されてAgent Identityが発行される流れが示されました。

デモは次の手順で進められました。

1. Spockにログ閲覧・BigQuery参照・監視データ閲覧・Compute Instance Admin権限をAllow Policyで付与
2. タグ`ENV=PROD`の付いたVMに対するcompute.instances.deleteをDeny Policyで禁止
3. Agentに「直近7日間未使用のリソースを探せ」→ 対象VMを特定
4. Agentに「そのVMを削除せよ」→ Deny Policyが発動し、削除を阻止
5. Policy Analyzerで権限グラフを可視化し、過剰な権限を特定

「Allowだけでなく、DenyとAccess Boundaryを重ねることで初めて意図した制御が実現する」という点を、ライブで動く実物を使って示したのが効いていました。

Security Command Centerで全AI資産を可視化

Security Command Center（SCC）のStandard Tierが全Google Cloud顧客向けに無料で有効化されました。SCC内の検出結果の中にある「AI Security」ビューでは以下が可視化されます。

• AIインベントリ（デモ環境では563エージェント・91モデル・72データソース・複数MCPサーバー）
• エージェントごとの設定不備（CMEKなし、VPC-SCなしなど）
• エージェントランタイムの脆弱性（CVE情報と修復ガイドを含む）
• 脅威検知（マルウェア実行・特権昇格・防衛回避など）
• Attack Exposure Scoreに基づくリスク優先度付けと「Toxic Combinations」の検出
• Shadow AI Discovery（近日提供予定）により、把握しきれていない野良エージェントの発見も可能になるとのことです。

Model Armorの保護状況もここから確認でき、デモ環境では「90モデルのうち5つしかModel Armorで保護されていない」という状況が可視化されました。プロンプトインジェクション・ジェイルブレイク試行・センシティブデータ検出なども一画面で把握できます。

Runtime Defense：Model ArmorとAgent Behavior Analysis

Hemrajani氏はランタイム防御を「人間がインサイダー脅威になるのは、悪意があるか、アカウントが乗っ取られた場合だ。しかしエージェントは、悪意がなくても、乗っ取られていなくても、最初からインサイダー脅威として振る舞い得る」と話されていました。

そのため、エージェントの挙動ベースラインからの逸脱を検知するAgent Behavior Analysisが必要であり、IAM自体が自動的にアクションを取れる仕組み（Circuit Breaker）を将来的に組み込む計画であると説明されました。

そして、Model Armorはエージェントとやり取りする全経路にアプリケーション変更不要でインライン統合を適用します。

• 保護対象：有害コンテンツ / PII / プロンプトインジェクション / 悪意あるURL・ファイル
• Aの統合先：Vertex AI / Gemini / Gemini Enterprise / GKE
• Previewの統合先：Firebase / LangChain（その他も作業中）
• カスタムトピックフィルター・独自分類器による誤検知チューニングも可能

会場の様子

Google Cloud Nextの現地参加初日、朝イチのセッションにもかかわらず立ち見が出るほどの入りで、「AIエージェントのセキュリティ」というテーマへの関心の高さを肌で感じました。

「課題→数字→スタック→デモ」という流れが一本筋で通っていたのが印象的でした。機能紹介だけでなく、「Deny Policyが発動して削除がブロックされる」場面をライブ画面で見て安心して本番環境で動かせるのではないかと考えさせられました。後日、発表内容の動画が公開された際には確認していただけると実際に利用した時のユースケースが分かりやすいと思いますので確認することを推奨します。

Q&Aでは「Workload Identity Federationへの展開は？」「VPC Service ControlsへのAI支援は？」といった深い質問が相次ぎ、ギリギリまで手が挙がっていました。エージェントセキュリティは「どこから始めるかわからない」フェーズを抜け、「具体的に何をやるか」を議論できる段階に入ってきたと思います。

まとめ

セッション全体を通じて繰り返し語られた重要ポイントを3点にまとめます。

•  Agent Identityへの移行を今すぐ検討する 
  • サービスアカウントの共有運用はエージェント時代のリスクになります。Agent EngineはGA、Gemini EnterpriseはPreviewで利用可能。GKEは次四半期に対応予定。 
    
    
•  多層防御はエージェントにも適用すること 
  •  Allow Policyだけでは不十分です。Deny Policy・Human in the loop・Agent Access Boundaryを組み合わせることで初めて実用的なガードレールが機能します。 
    
    
•  SCCのAI Securityをまず有効にして現状を把握する 
  • Standard Tierは無料で全顧客向けに有効化済み。AI資産のインベントリ・脆弱性・脅威検知・Model Armor保護状況が一画面で確認できます。これをベースラインに整備を進めるのが現実的なスタート地点となる。  

     

参考

Google Cloud、Google Workspace に関するご相談はXIMIXへ！

Google Cloud、Google Workspaceに関する お問い合わせはこちら
XIMIX®はNTTインテグレーションが所有する登録商標です。（商標登録第６７５５２３４号）