Google Cloud Next '26は、2026年4月22日から4月24日の3日間、アメリカ・ラスベガスのMandalay Bayにおいて開催されるGoogleのクラウドサービスに関する世界最大級のイベントです。「ディープ ラーニング、刺激的なセッション、共同での問題解決など、充実した 1 週間になることでしょう。業界の専門家や、あなたと同じ課題や機会に直面している同業者から直接学ぶチャンスです。Next 26 を終える頃には、他では得られない斬新なアイデア、最先端のスキル、行動につながる知見を身につけていることでしょう。」と銘打っており、AIコンテンツで大いに盛り上がった昨年や一昨年にも勝るとも劣らないイベントとなることが期待されます。
私たちNTTインテグレーションも、Google Cloudに精通した専門家として、技術イノベーションの最新動向を取り入れ、顧客に対するソリューション提供に活かしていくことを目指して参加しています。
このような貴重な機会ですので、現地からいち早くブログで最新情報や熱量を発信してまいります。
登壇者のHemrajani氏はまず、冒頭のスライドでGoogle Cloudのセキュリティプラットフォーム全体像を示しました。セキュアな基盤（Google Cloud自体）の上に、Resource Manager・Identity・Access Management・Access Riskが積み重なる構造です。このスタック全体にわたって今年も多くのアップデートが出ており、中でも目を引いたのは以下の点でした。
しかし、Hemrajani氏は「去年ならこれで話が終わっていた」と話されていました。2026年の今、人間のIAMの話だけではもう足りていないというところからエージェントアイデンティティのトピックの説明に進みました。
人間でさえ付与された権限の3%しか実際には使っていないそうです。そして、エージェントはその余った97%でも動いてしまいます。2010年代に人間向けに設計されたIAMの考え方をそのままエージェントに当てはめても機能しないのは、こういう理由からなのだそうです。
ということで、次の章からセッションの内容をさらに詳細に紹介していきます！
Hemrajani氏が重要なスライドの紹介として投影したのは、エージェント向けセキュリティスタックを示す図でした。構成は3つの水平レイヤーと3つの制御ピラーからなっています。この新スタックに関する発表が
スタックの土台となる水平レイヤーは、次の3層で構成されます。
| レイヤー | 内容 |
| Agent Gateway | IAPやオブザーバビリティなどの入出力（Ingress/Egress）でのポリシー適用ポイント |
| Agent Identity | 各ランタイムに紐付いたマネージドアイデンティティ |
| Agent Runtime | Workspace / Gemini Enterprise / Cloud Run / GCE / GKE / Agent Engine |
水平レイヤーを貫く縦軸として、3つの制御に関するピラーが定義されています。
| ピラー | 内容 |
| Guardrails | VPC Service Controls / Compliance Manager / Org Policy / AI Security Posture |
| Access Management | Agent Access Boundary / Access Governance / Human in the loop / Allow and Deny |
| Runtime Defense | Reputation and Fraud Defence / Agent Anomaly Detection / Vulnerability and Threat Detection / Model Armor |
セッションの最後に設けられたQ&Aでも最も多かった質問のひとつが「サービスアカウントとAgent Identityは何が違うのか」でした。Hemrajani氏の回答をまとめると以下のとおりです。
| 項目 | サービスアカウント | Agent Identity |
| 利用の単位 | 複数エージェントが共有可 | エージェント×ランタイムに1対1 |
| ライフサイクル | 個別に管理が必要 | エージェントのライフサイクルと同期（自動） |
| 認証情報 | 管理者が管理 | エージェント自身からも不可視（漏洩不可） |
| ポリシー設計の複雑度 | 共有しているため高い | 1対1なので精密に設定可能 |
GKEについてはまだ次四半期まで待つ必要があるそうですが、もしAgent Identityが利用可能になったらすぐに移行することをHemrajani氏は繰り返し強調していました。
また、Agent Identityは3種類のアイデンティティタイプをカバーします。
今回新たにAgent Identity Auth Manager（Preview）が発表されました。OAuthフローをエージェント実装側が意識せずに処理できる仕組みで、開発者の認証実装コストを大幅に削減するとのことです。
エージェントのアクセス管理は「ゼロデイから防御を積み上げる」設計でなければならない、というのがセッションを通じたメッセージでした。具体的には4つの制御を重ね合わせます。
将来提供予定のUnified Access Policyでは、Allow/Deny/条件/コンテキストを1つのポリシー定義にまとめられるようになります。GCPリソースだけでなくMCPサーバー・他エージェント・外部ツールへのアクセスも同一ポリシーで管理できるとのことです。
デモでは「Spock」という名のSpend Optimizer Agentが登場しました。Google ADKで構築し、Agent Engineにデプロイした後、Agent Registryに自動登録されてAgent Identityが発行される流れが示されました。
デモは次の手順で進められました。
「Allowだけでなく、DenyとAccess Boundaryを重ねることで初めて意図した制御が実現する」という点を、ライブで動く実物を使って示したのが効いていました。
Security Command Center（SCC）のStandard Tierが全Google Cloud顧客向けに無料で有効化されました。SCC内の検出結果の中にある「AI Security」ビューでは以下が可視化されます。
Model Armorの保護状況もここから確認でき、デモ環境では「90モデルのうち5つしかModel Armorで保護されていない」という状況が可視化されました。プロンプトインジェクション・ジェイルブレイク試行・センシティブデータ検出なども一画面で把握できます。
Hemrajani氏はランタイム防御を「人間がインサイダー脅威になるのは、悪意があるか、アカウントが乗っ取られた場合だ。しかしエージェントは、悪意がなくても、乗っ取られていなくても、最初からインサイダー脅威として振る舞い得る」と話されていました。
そのため、エージェントの挙動ベースラインからの逸脱を検知するAgent Behavior Analysisが必要であり、IAM自体が自動的にアクションを取れる仕組み（Circuit Breaker）を将来的に組み込む計画であると説明されました。
そして、Model Armorはエージェントとやり取りする全経路にアプリケーション変更不要でインライン統合を適用します。
Google Cloud Nextの現地参加初日、朝イチのセッションにもかかわらず立ち見が出るほどの入りで、「AIエージェントのセキュリティ」というテーマへの関心の高さを肌で感じました。
「課題→数字→スタック→デモ」という流れが一本筋で通っていたのが印象的でした。機能紹介だけでなく、「Deny Policyが発動して削除がブロックされる」場面をライブ画面で見て安心して本番環境で動かせるのではないかと考えさせられました。後日、発表内容の動画が公開された際には確認していただけると実際に利用した時のユースケースが分かりやすいと思いますので確認することを推奨します。
Q&Aでは「Workload Identity Federationへの展開は？」「VPC Service ControlsへのAI支援は？」といった深い質問が相次ぎ、ギリギリまで手が挙がっていました。エージェントセキュリティは「どこから始めるかわからない」フェーズを抜け、「具体的に何をやるか」を議論できる段階に入ってきたと思います。
セッション全体を通じて繰り返し語られた重要ポイントを3点にまとめます。
Google Cloud、Google Workspaceに関する お問い合わせはこちら
XIMIX®はNTTインテグレーションが所有する登録商標です。（商標登録第６７５５２３４号）