G-gen の武井です。当記事では、Google Cloud Next '26 in Las Vegas のブレイクアウトセッション「Built-in defense: The next evolution of Security Command Center for AI-era」について、速報レポートをお届けします。

G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。

セッションの概要
プラットフォームネイティブなセキュリティの考え方
- シフトダウン
- プリエンプティブなセキュリティとは何か
SCC の新しい提供形態
- SCC Standard 2.0（GA）
SCC の6つの方針
開発者向けのセキュリティ機能
AI・エージェント向けのセキュリティ機能
Google Cloud 全体のセキュリティ機能
- Security & Compliance
- Gemini Cloud Assist による修復

セッションの概要

本セッションでは、Security Command Center（以下、SCC）を中心とした Google Cloud のプラットフォームネイティブなセキュリティの進化と、AI・エージェント時代に向けた新機能が発表されました。

登壇者は Google Cloud の Abhishek Hemrajani 氏と Nav Jagpal 氏の2名です。前半で Abhishek 氏が「組み込み型プラットフォームセキュリティ」の考え方と新機能群を概観し、後半で Nav 氏が実際のコンソール画面を使ったデモを披露する構成でした。

参考 : Security Command Center overview

プラットフォームネイティブなセキュリティの考え方

シフトダウン

セッション冒頭で Abhishek 氏が打ち出していたのは、「We must shift security left — actually, down」というメッセージでした。

長らく語られてきたシフトレフトの発想を踏まえつつ、より的確に表現するなら、セキュリティを開発者の手前に寄せる（左に寄せる）のではなく、プラットフォーム側に組み込むのが本質であり、AI とエージェントの時代において、これまでのようにセキュリティをシステム開発の工程に組み込むアプローチではスケールしないと説明されていました。

プリエンプティブなセキュリティとは何か

Abhishek 氏はセキュリティの成熟度を以下の3段階で整理していました。

段階	概要
Reactive（事後対応）	復旧や根本原因の特定を優先
Proactive（事前対応）	インシデント化する前にリスクを特定・緩和
Preemptive（先制）	発生前にシステム自体を安全に設計し、問題を最小化

この発想を突き詰めたのが、SCC が目指すプリエンプティブなプラットフォームネイティブ・セキュリティです。具体的な特徴として以下の3点が挙げられていました。

特徴	概要
Cloud Constructs	Cloud IAM とポリシー構成要素を活用し、クラウドセキュリティ管理をシンプルにする
Embedded Detections	クラウドの挙動を継続的に監視する、専門的かつ組み込み型の検出テクノロジー
No Daemons / Probes	コレクター・デーモン・プローブ・ログ取り込みコストを排除し、TCO と運用の複雑さを削減

SCC の新しい提供形態

SCC Standard 2.0（GA）

新たに SCC Standard 2.0 が GA（一般公開）となりました。以下3点がハイライトとして示されています。

特徴	概要
すぐに使えて無料	すぐに利用可能。SCC Premium の 30 日間無料トライアルもワンクリックで有効化できる
必須セキュリティがデフォルト有効	Data Security および Compliance に加えて、AI とクラウドの必須セキュリティがデフォルトで有効に
コンテキスト内での検出結果表示	Cloud Hub ダッシュボードや Compute Engine、Google Kubernetes Engine（以下、GKE）などのコンソールに、セキュリティ検出結果が直接表示される

SCC の6つの方針

SCC は、以下の6つ方針に沿って整理されています。すべての機能がコンテキストとアプリケーションを認識するよう設計されており、AI・エージェント型アプリとクラウドワークロードの双方をカバーします。

#	項目	概要
1	Identify（特定）	Google Cloud アセットと IAM ポリシーのリアルタイムインベントリ、AI アセット（モデル、データ、エージェント、ツール、MCP サーバー）の自動探索、Cloud Run や GKE 上のエフェメラルワークロード検出
2	Prevent（防御）	175 以上の組み込みクラウドディテクター、構成の継続的検証、Mandiant CVE 情報と相関させた脆弱性可視化、過剰権限の特定と最小権限への移行
3	Detect（検出）	暗号資産マイニング、マルウェア、データ持ち出し、ネットワーク異常、不審なバイナリ、ID 関連リスク、攻撃ツール検出、ルートキット、バックアップ／DR の問題など、アクティブな脅威を検出
4	Find（発見）	セキュリティグラフで既知リスクのコンテキストを相関、仮想的なレッドチーミングと攻撃パスシミュレーションで未知のリスクを発見
5	Discover（データ保護）	機密データの発見・分類、リテンションと暗号化を含むデータポスチャ管理、違反の自動監視と監査証跡の生成
6	Monitor（コンプライアンス監視）	クラウド環境全体、選択リソース、主要プロジェクトでのコンプライアンス強制、標準への準拠状況の継続的な監視とレポート、監査証跡の生成

開発者向けのセキュリティ機能

Day 0 と Day N の二軸で捉える

Abhishek 氏の整理では、開発者向けセキュリティは「Day 0 で設計時にセキュリティを組み込み、Day N ではアプリケーションを認識した運用を行う」というライフサイクルで捉えられていました。

Secure-by-Design

Secure-by-Design がプレビュー公開されました。具体的には以下の3点が特徴として挙げられていました。

Application Design Center、App Hub、SCC に統合
アプリケーション設計ワークフロー内でプリエンプティブなセキュリティ評価を直接実行
検出結果から実際のコード行までのリネージを追跡し、SDLC（Software Development Life Cycle）全体でのセキュリティトレーサビリティを実現

なおセッションでは、プラットフォームチームと開発者がそれぞれ Application Design Center 上でフレームワーク適合状況を確認し、不合格項目に対して Gemini が修正案を自動生成してデプロイ前に対処する、という一連の流れがデモで示されていました。

参考 : Application Design Center overview

Application-Centric

SCC に Application-Centric が GA となりました。従来はインフラレベルで優先順位付きリストが提示されていましたが、脆弱性・ID・データ・AI セキュリティ・脅威のすべてを、重要アプリケーションのコンテキストで可視化できるようになります。

App picker : 脆弱性、ID、データ、AI セキュリティ、脅威の各画面をアプリケーション単位で切り替え
App-aware nodes : 攻撃パスシミュレーションにアプリ認識ノードが加わり、アプリケーションとリソースを関連付けて分析
改善されたトレーサビリティ : アプリケーションアーキテクチャの設計意図が破られたときに追跡可能

アプリケーション中心の SCC がもたらす価値として、Abhishek 氏は以下の3点を挙げていました。

ビジネスインパクトによる優先順位付け : ビジネス優先度に基づいて、重要なアプリケーションのセキュリティリスクを切り分けて優先する
影響範囲の可視化 : アプリケーションと基盤リソースのつながりを可視化し、問題発生時にどこまで影響が及ぶかを把握できる
設計意図との整合性維持 : 検出結果のリネージを活用し、ランタイムで発見された問題の原因をソースコードまで遡って追跡できる

AI・エージェント向けのセキュリティ機能

Built-in AI and Agent Security

AI・エージェント向けセキュリティの中核となる柱として、以下の3点が整理されていました。

Agent Security Posture : Google が推奨するコントロールに基づく、Secure-by-Design で構築されたエージェント型アプリ
Agent Asset Discovery : AI エージェント、アセット、機密データに関する組織全体インベントリ
Agent Vulnerability Scanning : エージェントパッケージや Skills の脆弱性を特定

Agents are the new Insider Threat

以下のスライドを使い、Agents are the new Insider Threat（エージェントは新たな内部脅威である）というメッセージが強調されていました。

人間が内部脅威になる理由は、悪意・強い不満・アカウント乗っ取りのいずれかですが、エージェントの場合はそのどれもなくても望ましくない挙動を取り得る、というのがその理由です。Abhishek 氏は、この課題に対処するアプローチとして以下 3 つを挙げていました。

領域	概要
Anomaly Detection	エージェントの挙動と推論プロセスを分析し、リスクを特定して信頼を確立
Reputation and Fraud Defense	AI を悪用した巧妙な不正や乱用への防御
Model Armor	入力プロンプトと出力レスポンスを審査し、モデルとのインタラクションを保護

Built-in Security for Gemini Enterprise Agent Platform

Gemini Enterprise Agent Platform 向けの組み込みセキュリティが Preview 公開されました。SCC を基盤としており、以下 5 つの機能が提供されます。

コンプライアンスコントロールによるアセスメント
エージェントと MCP ツールのエージェントレスな自動探索
イメージの脆弱性スキャンと設定ミス検出
ランタイムおよびコントロールプレーンの脅威検出
セキュリティグラフに基づくトキシックコンビネーション検出

Model Armor によるインタラクションの保護

Model Armor は、アプリケーションコードを一切変更せずに、AI モデルとのインタラクションをインラインで保護できる機能です。ユーザーから Agent、Agent から AI Model など、エージェントを中心としたすべてのインタラクションパスをカバーします。

また、現在 GA で利用できる検出器と、今後追加される予定の検出器は以下の通りです。

提供状況	検出器	概要
GA	Content safety model	危険・有害なコンテンツ（性的、憎悪など）をブロック
GA	Sensitive data service	テンプレートベースで PII データをマスキングもしくはブロック
GA	Prompt safety model	プロンプトインジェクションやジェイルブレイクの試行を検出
GA	Google AV and SafeBrowsing	悪意のあるファイルや安全でない URL をブロック
Coming Soon	Custom topics	組織のポリシーに基づくカスタムトピック検出器の作成
Coming Soon	Allow/Deny lists	許可リストを使った false positive 管理
Coming Soon	Custom rules engine	プロンプトインジェクション／ジェイルブレイク検出用のカスタムルール

参考 : Model Armor overview

なお、セッション内のデモでは、組織全体の AI アセットを俯瞰するインベントリ画面や、Cloud Run や GKE 上で開発者が独自に構築したエージェントの自動検出、サプライチェーン脆弱性やパイプライン侵害、Jupyter Notebook 内の認証情報漏洩といった AI 固有のリスクに対する攻撃パス可視化も紹介されました。

Google Cloud 全体のセキュリティ機能

Security & Compliance

Cloud Hub で利用できる Security & Compliance がプレビュー公開されました。オブザーバビリティ、アプリケーションランタイム、信頼性、セキュリティのシグナルを一枚の画面で相関させられるため、クラウド環境全体の状況を横断的に把握できます。

Gemini Cloud Assist による修復

検出結果の修復を支援する Gemini Cloud Assist も紹介されていました。なお Gemini Cloud Assist は、Google Cloud に組み込まれた Gemini による補助機能です。コーディング補助サービスである Gemini Code Assist とは名称が似ていますが異なるものですので注意してください。

Nav 氏のデモでは、パブリック公開された Compute Engine インスタンスに OS 脆弱性が存在するトキシックコンビネーションを題材に、Gemini Cloud Assist が問題の詳細と攻撃パスを解説し、外部 IP の削除や VM の停止、外部トラフィックの制限といった修復オプションを提示する流れが披露されました。gcloud コマンドの実行と Terraform コードの出力の両方に対応しており、コマンドはログイン中のユーザーの IAM 権限で実行されるため、既存のアクセス制御をバイパスしない点も特徴です。

最終的には、攻撃パスの遮断、脆弱性の緩和、リスクスコアの低下、優先順位の更新までが数分以内に完結しました。Abhishek 氏は「検出結果の 80% 以上は Gemini で修復可能」という数字も紹介しており、修復作業のトイル（労力）削減への期待が強調されていました。