Technical Blog テクニカルブログ
  1. HOME
  2. テクニカルブログ
  3. Google SecOpsでアラート一次対応を効率化!トリアージエージェントとPlaybook連携を検証してみた

Google SecOpsでアラート一次対応を効率化!トリアージエージェントとPlaybook連携を検証してみた

投稿者:セキュリティ&ネットワーク事業本部 セキュリティ担当 槨水

こんにちは。セキュリティ担当の槨水です。

アラート対応では、検知後の初動で「何を確認し、次にどのような対応を取るか」を整理する必要があります。
しかし、関連イベントの確認や影響範囲の把握、対応要否の判断材料の整理など、一次対応には多くの手作業が含まれます。

こうした初動対応の一部を自動化できれば、担当者は重要度の高い調査や判断により多くの時間を使えるようになります。

前回のブログでは、Google SecOpsの注目機能として、AIがアラート調査を支援するトリアージエージェントについてご紹介しました。

今回はその続編として、トリアージエージェントとPlaybookを連携させ、アラート一次対応の効率化にどのように活用できるのかを検証してみます。

目次

1. Google SecOpsとは

2. トリアージエージェントとは

3. エージェントの自動化とは

4. トリアージエージェントとPlaybook連携を検証してみた

5. おわりに

1. Google SecOpsとは

Google SecOps(正式名称:Google Security Operations)は、Google Cloudが提供するセキュリティ運用プラットフォームです。

SIEM/SOAR、ケース管理、脅威インテリジェンス、AIを活用した調査支援などの機能を備え、ログの収集から検知、調査、対応までを一元的に支援します。

Google SecOpsの概要や注目機能については、過去のブログでご紹介していますので、併せてご覧ください。

・Google SecOpsの概要紹介ブログはこちら
https://www.niandc.co.jp/tech/20250929_65687/

・Google SecOpsの注目機能紹介ブログはこちら
https://www.niandc.co.jp/tech/20260629_74987/

本記事では、トリアージエージェントとPlaybook連携によるアラート一次対応の効率化に焦点を当ててご紹介します。

2. トリアージエージェントとは

トリアージエージェントは、Google SecOpsに組み込まれたAI搭載の調査支援機能です。

アラートに関連する情報を整理し、「真陽性(True Positive)」= 実際に対応が必要な可能性が高いアラート、 または「偽陽性(Folse Positive)」= 実際には問題ない可能性が高いアラート の可能性、評価理由、調査過程、推奨される次のステップなどを提示することで、セキュリティ担当者の初動調査を支援します。

前回のブログでもご紹介した通り、トリアージエージェントは担当者の判断を置き換えるものではなく、調査に必要な情報整理を支援する機能です。担当者は、AIが提示した調査結果や根拠を確認したうえで、追加調査や対応方針を判断することが重要です。

なお、対象となるサブスクリプションや利用条件、実行回数の上限などは変更される可能性があるため、トリアージエージェントの利用に際してはGoogle Cloud公式ドキュメントなどで最新情報をご確認ください。

次章では、このトリアージエージェントをPlaybookに組み込み、アラート対応の一部を自動化する「エージェントの自動化」についてご紹介します。

3. エージェントの自動化とは

エージェントの自動化とは、AI エージェントを1つのステップとして Playbook(アラート対応手順を自動化するワークフロー)に組み込み、アラート発生後の対応を自動化する仕組みです。

Google SecOpsのPlaybookでは、通知、ケース更新、担当者への割り当て、クローズ処理など、あらかじめ定義した対応フローを自動化できます。ここにトリアージエージェントを組み合わせることで、AIによる調査結果に応じて後続の処理を分岐させることができます。

例えば、調査結果が「偽陽性の可能性が高い」と評価された場合はケースをクローズし、「真陽性の可能性が高い」と評価された場合は担当者へ通知する、といった運用が考えられます。

これにより、アラート対応の初動における定型的な処理を効率化し、担当者はより重要な調査や判断に時間を使いやすくなります。

次章では、実際にトリアージエージェントをPlaybookに組み込み、アラート対応の一部自動化について検証してみます。

4. トリアージエージェントとPlaybook連携を検証してみた

ここからは、実際にトリアージエージェントをPlaybookに組み込み、アラート対応の一部を自動化できるか検証してみます。

今回の検証では、アラート発生を起点にPlaybookを起動し、トリアージエージェントによる調査、調査結果に応じた処理分岐、ケースの自動クローズまでを一連の流れとして確認します。

なお、本検証は検証環境で実施したものであり、実際の運用環境では対象とするアラートや自動化する処理内容を十分に検討したうえで適用する必要があります。

4-1. 検証シナリオ:Root Password Changeアラートを一次対応する

今回の検証では、Linuxのログから検知された「Root Password Change」アラートを使用します。
これは、管理者アカウントであるrootユーザーのパスワード変更を示すアラートです。

rootユーザーはシステム上で強い権限を持つため、rootパスワードの変更は重要な操作の一つです。正当な管理作業として実施される場合もありますが、意図しないタイミングで発生した場合や、通常とは異なる操作元から実行された場合には、不正操作や侵害後の活動である可能性も考えられます。

そのため、Root Password Changeアラートでは、単にアラートが発生したことだけで判断するのではなく、発生元、対象ホスト、操作ユーザー、関連イベントなどを確認し、通常の運用範囲内の操作かどうかを確認する必要があります。

今回このアラートを題材にした理由は、正当な管理作業と不審な操作の両方の可能性があり、トリアージエージェントによる情報整理とPlaybookによる後続処理の自動化を検証する題材として適していると考えたためです。

今回の検証では、トリアージエージェントの調査結果のうち、「verdict」(判定)と「confidence」(確信度)を条件分岐に利用します。具体的には、「False Positive」かつ「High Confidence」と評価された場合のみケースを自動クローズし、それ以外の場合は担当者が確認する運用を想定します。

AIの調査結果をすべて自動処理に利用するのではなく、誤検知の可能性が高く、かつ確信度が高い場合に限定して自動クローズする構成としました。

本検証におけるアラート発生からケースクローズまでの流れは、以下の通りです。

4-2. トリアージエージェントの調査結果を確認する

まず、対象のRoot Password Changeアラートに対して、トリアージエージェントによる調査結果を確認します。

図1:トリアージエージェントによる調査結果
※ブラウザ翻訳により、一部表示が崩れています。

図2:トリアージエージェントによる調査過程
※ブラウザ翻訳により、一部表示が崩れています。

■調査結果まとめ

項目結果
判定False Positive(誤検知)
確信度High Confidence(高)
アラートの概要ユーザによるrootパスワードの変更
調査概要標準的な管理操作によって発生、悪意のある動作や侵害の兆候なし
推奨される次のステップ4件提示。AI が追加調査可能な項目が2件、管理者による確認が必要な項目が2件
調査のタイムラインイベント検索を自動実行し、時系列を表示

今回の検証では、後続のPlaybook処理に利用する項目として、特に「判定」と「確信度」に着目しました。具体的には、判定が「False Positive」、確信度が「High Confidence」となった場合に、ケースを自動クローズする条件として利用します。

4-3. Playbookで自動化する範囲を設計する

次に、トリアージエージェントの調査結果をどのようにPlaybookへ組み込むかを整理します。

今回のPlaybookでは、トリアージエージェントの調査結果をもとに、ケースを自動クローズするか、担当者確認を残すかを分岐させます。

処理の流れは以下の通りです。

1. Root Password Changeアラートを起点にPlaybookを起動
2. AI Agentsステップでトリアージエージェントによる調査を実行
3. 調査結果から「verdict」と「confidence」を取得
4. 条件を満たす場合のみケースを自動クローズ
5. 条件に一致しない場合は担当者確認を残す

4-4. Playbookを作成する

ここからは、実際にPlaybookを作成します。

今回のPlaybook作成で重要なポイントは、以下の3点です。

  • 対象アラートを適切に絞り込むこと
  • AI Agentsステップでトリアージエージェントの調査結果を取得すること
  • verdict と confidence を条件分岐に利用すること

以降では、これらのポイントを中心に設定内容を確認します。

まず、Response > Playbooks から新規Playbookを作成します。
作成時には、Playbookの種類、保存先フォルダ、適用先環境などを設定します。

図3:Playbookの新規作成画面

Playbookの編集画面が開いたら、起動条件を設定します。

Triggerは、Playbookをどの条件で起動するかを決める設定です。
本検証ではシミュレーションでRoot Password Changeアラートを対象に動作確認しますが、実運用では対象外のアラートにPlaybookが実行されないよう、Trigger条件で対象アラートを適切に絞り込むことが重要です。

図4:Playbookの起動条件設定

次に、AI Agentsステップを追加します。
AI Agentsタブから「Triage and Investigation Agent」を追加することで、Playbook内でトリアージエージェントによる調査を実行できます。

追加したAI Agentsステップでは、Playbook実行時にトリアージエージェントを自動実行するか、失敗時に再試行するか、ステップ失敗時に後続処理へ進むか、といった設定を確認できます。

図5:AI Agentsステップの追加

続いて、トリアージエージェントの調査結果をもとに条件分岐を設定します。

図6:条件分岐の追加

今回は、AI Agentsステップの実行結果から以下の2つの値を利用します。

  • verdict:トリアージエージェントの判定
  • confidence:判定に対する確信度

条件分岐では、以下の条件を設定しました。

  • verdict = False Positive
  • confidence = High Confidence

この2つの条件を満たした場合のみ、後続のBranch(条件に応じて次に実行する処理を切り替える仕組み)でケースをクローズするように設定します。

図7:verdict、confidenceを利用した条件設定

最後に、条件を満たした場合のアクションを設定します。
今回の検証では、「False Positive」かつ「High Confidence」と評価された場合に、アラートを含むケースをクローズするため、Branch側に「Close Case」アクションを配置しました。

これにより、トリアージエージェントの調査結果が「False Positive」かつ「High Confidence」と評価された場合に限り、ケースが自動的にクローズされるPlaybookが完成します。

図8:Close Caseアクションの設定

4-5. シミュレーションで動作を確認する

作成したPlaybookの動作を確認するため、シミュレーション機能を利用してRoot Password Changeアラートを流してみます。

今回確認するポイントは以下です。

  • Root Password Changeアラートを起点にPlaybookが起動すること
  • AI Agentsステップでトリアージエージェントによる調査が実行されること
  • 調査結果の「verdict」と「confidence」をもとに条件分岐されること
  • 条件に一致した場合、ケースが自動クローズされること

図9:Playbookシミュレーションの実行画面

シミュレーションの結果、以下の流れを確認できました。

① Root Password Changeアラートに対してPlaybookを実行
② AI Agentsステップでトリアージエージェントによる調査を実施
③ 調査結果が「False Positive」かつ「High Confidence」であることを確認
④ 条件分岐によりBranch側の処理へ進む
⑤ Close Caseアクションによりケースが自動クローズ

図10:Playbookの実行結果

この結果から、トリアージエージェントの調査結果をPlaybook内で利用し、判定結果に応じて後続処理を自動化できることを確認できました。

4-6. 検証を終えての感想

今回の検証を通じて、トリアージエージェントとPlaybook連携は、アラート対応の初動を標準化し、担当者の負荷を軽減するうえで有効な選択肢になり得ると感じました。

一方で、自動クローズのように対応結果へ直接影響する処理は、対象アラートや条件を慎重に設計する必要があります。

まずは過去の運用で誤検知と判断されることが多いアラートや、対応方針が明確なアラートなど、リスクの低い範囲から検証を始めるのが現実的だと思います。

また、最初から完全自動化を目指すのではなく、担当者への通知やケースへのコメント追加など、人の確認を残した形で段階的に適用範囲を広げていくアプローチが有効だと考えます。

おわりに

いかがでしたでしょうか。

今回は、トリアージエージェントをPlaybookに組み込むことで、アラート発生後の初動対応を効率化できることを確認しました。

弊社では、Google SecOpsの導入支援に加えて、検知ルールのチューニングなど、運用定着に向けた伴走サービスも行っています。

お客様の環境や運用課題に合わせて、より実践的な活用をご支援します。

Google SecOpsに興味を持たれた方は、以下のリンクからお気軽にお問い合わせください!

Google SecOpsに関するご相談はこちら

ページのトップへ