DX開発事業部 フルスタックセクションの田村です。
Google Cloud Next 2026 よりセッションの要点解説をお届けいたします。
今回は「Building Agentic Defense with MCP Servers」セッションを聴いてきました。

はじめに

スピーカーは Google Cloud のプリンシパルアーキテクト Sandy Borneman-Wenzel 氏。MCP（Model Context Protocol）を使って Google SecOps（Chronicle）をエージェントに繋ぎ、SOC の調査ワークフローを自動化する実装を、惜しみなく公開してくれたセッションでした。

エージェントの定義

セッションではまず改めて「エージェントとは何か」という定義から始まりました。

  • Model（LLM）
  • Tools（外部 API 等）
  • Orchestration（マルチエージェント協調）
  • Runtime（実行環境）

セキュリティの文脈でこれを見ると、「Tools」の部分が肝になっており、Chronicle の SIEM・SOAR・GTI（Google Threat Intelligence）・SCC（Security Command Center）などを Tools として繋ぐのが MCP サーバーの役割になっています。
エージェントがセキュリティツールを『道具』として使える形にすることが、エージェントを考えていく上での出発点ですね。

5層スタックと Google SecOps MCP の位置づけ

Google SecOps MCP が提供するのは 3点で、Chronicle REST API への「安全なツール接続」、エージェントが参照するための「サンプルと文脈」、エンタープライズ向けの「ガバナンス」となっています。

全体のスタックは下から上へ積み上がる構造で、MCP は「API 層をエージェントが扱えるツールに変換する」位置を担っていて、APIを直接叩くコードを書くのではなく、MCP 経由で道具として渡すというのがエージェント SOC の基盤となっていることがわかりました。

Agentic SOC の全体像

  • SOC Orchestrator（Gemini 3.1 Pro）：調査全体を統括
  • CTI Researcher（Gemini 3.1 Flash）：脅威インテリジェンス調査担当
  • Tier 1 Analyst（Gemini 3.1 Flash）：アラート初期トリアージ担当
  • MCP サーバー × 4：SecOps SIEM、SOAR、GTI、SCC

170本の Runbook を Vertex AI で構築した RAG システムと組み合わせて、サブエージェントが自分で適切な調査手順を引き出す構造になっているようです。

Orchestrator に Pro、サブエージェントに Flash を割り当てているのはコストとレイテンシの最適化のためとのことです。
指示・判断は大きいモデルで、実行・検索はレスポンスが速い方で行うという役割分担は実務でも真似できる発想ですね。

AI Runbook によって「エージェントの振る舞い」を変える

固定の動作フローを実装するのではなく、Runbook を RAG で動的に引き出す設計にしている点が興味深かったです。

「Hardcoded Agent vs Runbook-Driven Agent」という対比がありました。

Hardcoded の場合、エージェントは決まった手順しか実行できませんが、Runbook-Driven の場合、インシデントの種類に応じて適切な Runbook を RAG で取得し、その手順に従って動作させることができます。

特にセキュリティの世界では脅威の種類が日々変化します。
そのため170本の Runbook を最新の TTP に合わせて更新するだけで、エージェントの対応範囲が広がります。

この『Runbook の更新 = エージェントのアップデート』という設計思想は、汎用性を持ったエージェントを効率よく運用するうえで非常に参考になりますね。

デモ：Mimikatz の脅威ハンティングを 20秒で

ライブデモはエンドユーザー向け Gemini Enterprise から始まりました。
入力したプロンプトは「環境内で Mimikatz の使用を示す UDM イベントを調べてほしい」という趣旨のものでした。

GTI（Google Threat Intelligence）で Mimikatz のリスクスコアを調べつつ、Chronicle SIEM で UDM クエリを実行します。

最終的な結果は 84件がマッチし、ユーザー frank.kolzig がドメインコントローラー上で Mimikatz を実行していたことが特定されました。
UDM クエリも自動生成されています。

これをアナリストが手作業でやると
1. Chronicle の画面を開く
2. UDM クエリを書く
3. GTI で調べる
4. インシデントを起票する

上記のような工程を踏む必要がありますがエージェントなら 1つのプロンプトで完結します。
現場のアナリストの負担がどれだけ変わるかがとても実感しやすいシナリオと感じました。

セッション全体を振り返って

「MCP で Chronicle を繋いでエージェントを作る」という話は概念としては理解できていましたが、170本の Runbook を RAG に入れて Runbook-Driven な設計にする、という部分はこのセッションを聴くまで考えたことはなかったです。

Runbook の蓄積・更新をどう組織的に回すかが実用化のカギで、そこはまだ課題として残っている印象でしたが、エージェントの「賢さ」を実装ではなくデータで管理する発想は画期的だと思いました。

「エージェントはユーザーより権限を持たない」という原則もセッション中に触れられていました。
エージェントに広い権限を与えないことで、誤動作した場合の影響範囲を最小限に抑える設計となっており、セキュリティに限らずエージェントを組織に導入するうえでの基本方針として使える考え方だと思います。