Alert Center APIで設計するGWSアラート自動通知

Google Workspace の Admin SDK には、Google が能動的に生成するセキュリティアラートをプログラムで取得できる Alert Center API が含まれています。この記事では、Alert Center API を使ったリアルタイム監視フローを設計する際の判断軸を整理します。

この記事を読んだほうが良い人

• 100名前後の組織で Google Workspace を管理している情シス担当者
• セキュリティアラートをメール確認や手動チェックで対応しており、見落とし・対応遅延に不安を感じている
• GWS のアラートを Slack などの社内ツールへ自動連携する仕組みを検討中
• 監査ログの事後分析だけでなく、リアルタイムのインシデント検知体制を整えたい

Google Workspace Alert Center APIとは何か

Alert Center API は Admin SDK（Google Workspace の管理機能を操作する API 群）の一部として提供されており、Google が検知・生成したセキュリティアラートをプログラムで取得・管理できます。Google 公式ドキュメントによると、現行バージョン（v1beta1）はすべての Google Workspace 顧客が利用可能です。

混同されがちな「監査ログ（Admin Reports API）」との違いを先に整理します。

監査ログ（Admin Reports API） は、管理コンソール操作・ログイン・Drive 共有などのイベントを事後に検索・集計するためのものです。「先週の不審なログイン件数を集計したい」「特定ユーザーの操作履歴を調べたい」という用途に向いています。

Alert Center API は Google 側が能動的に生成したアラートを取得します。不審なログインや漏洩した認証情報を Google 側が検知した時点でアラートが生成され、API 経由で受け取れます。情シス側は「Google が今何かを検知した」というシグナルをリアルタイムに処理できます。

監査ログは「事後の分析ツール」、Alert Center API は「能動的なリアルタイム検知の窓口」です。両者は用途が異なるため、どちらか一方を選ぶものではなく、組み合わせて使うのが理想です。

情シス視点でのアラートタイプ分類

Alert Center API が提供するアラートは複数カテゴリに分かれています。Google 公式の Alert Types リファレンスをもとに、情シスが対応優先度を決める観点で整理すると以下のようになります。

優先度	アラートカテゴリ	代表的なアラートタイプ	初期対応の方向性
緊急	アカウントセキュリティ	漏洩認証情報の検知 / 不審なログイン	アカウント停止・パスワードリセット
緊急	標的型攻撃	国家支援型攻撃の警告	経営層・担当者への即時エスカレーション
高	デバイスセキュリティ	デバイス侵害の可能性	端末の隔離・MDM によるリモートロック
高	管理者操作変更	管理者権限変更・SSO設定変更	変更の承認確認・不審時は復元
中程度	メールセキュリティ	フィッシングメール検知・マルウェア再分類	メール隔離確認・ユーザー周知
中程度	データ保護	DLP（データ損失防止）ルール違反・ランサムウェア疑惑	ポリシー確認・対象データの保全
低	ユーザー管理	ユーザー追加・削除・権限変更	プロビジョニング手順との照合
参考	サービス状況	サービス障害・強制アナウンス	復旧確認・ユーザーへの案内

優先度「緊急」のアラートは、深夜・休日でも即時通知が必要なケースです。「高」はオンコール担当が30分以内に確認できる体制が理想です。「中程度」以下は通常業務時間内の対応でも許容できますが、翌朝まとめて確認するより自動通知がある方が、インシデント見落とし率を構造的に下げられます。

通知方式の選択：ポーリングとPub/Sub

Alert Center API の通知受け取り方式には、大きく2つの選択肢があります。

ポーリング（定期取得） は、GAS（Google Apps Script）などのスクリプトが定期的に API を呼び出してアラートを取得する方式です。Google Cloud の追加リソースが不要で、実装もシンプルです。取得間隔分の遅延（例: 5分ごとなら最大5分）は生じますが、100名規模の組織における多くのアラートタイプには十分な応答速度が得られます。Alert Center API の認証にはサービスアカウントが必要で、Google Cloud プロジェクトでの事前設定が必要になります。

Pub/Sub（プッシュ通知） は、Google Cloud Pub/Sub（Google のマネージドメッセージングサービス）にトピックを作成し、アラート発生時に自動でメッセージを受け取る方式です。Alert Center API の設定で Pub/Sub トピックを通知先として登録することで、新しいアラートが生成されるたびにメッセージが発行されます。Cloud Run や Cloud Functions などのサーバーサイドコンポーネントが必要になりますが、ほぼリアルタイムの通知が実現します。

2方式の主要な違いをまとめると以下の通りです。

比較軸	GAS ポーリング	Pub/Sub + Cloud Functions
GCP 追加リソース	不要（GAS 無料枠で動作）	Cloud Pub/Sub + Functions が必要
実装の複雑さ	低い	中〜高い
検知の遅延	最大数分（ポーリング間隔に依存）	数秒〜ほぼリアルタイム
向いているケース	まず動かしたい / GCP 経験が浅い	緊急アラートの即時検知が必須
月次コスト目安	ほぼゼロ	GCP 従量課金（小規模なら微量）

100名規模の情シスにとっての現実的な判断基準を整理すると、以下の通りです。

• GCP リソースを増やしたくない / まず動くものを作りたい → GAS ポーリングから始める
• 緊急アラートに数分以内の検知を保証したい → Pub/Sub + Cloud Functions
• Pub/Sub の運用経験がある / 専任 IT 担当が複数いる → Pub/Sub も現実的

GAS ポーリングで始め、運用の中で「もっと速い検知が必要」と判断したタイミングで Pub/Sub に移行する段階的アプローチが、現場では無理なく機能します。

GASポーリングを選んだ場合に固める設計判断

GAS ポーリング方式で実装を進める前に、3つの設計判断を明確にしておく必要があります。

重複通知の防止: Alert Center API を定期実行で呼び出すと、前回取得済みのアラートも毎回含まれて返ってきます。同じアラートが Slack に何度も流れると担当者の混乱を招くため、アラートごとに付与される一意の ID を記録して「通知済みかどうか」を判別する仕組みが必要です。GAS にはスクリプトに紐付いたキーバリュー形式のデータ保存領域があり、通知済み ID の管理に活用できます。このストレージには容量上限があるため、古い ID の定期的なクリーンアップもセットで計画することが、長期安定稼働の前提条件です。

実行時間の上限への対処: GAS は1回の実行で最大6分間という時間制限があります。アラートの取得範囲を「前回実行時刻以降」に絞り込むことで、1回の実行で処理する件数を一定に保てます。大量のアラートが短期間に発生するインシデント発生時に処理がタイムアウトする事態を、設計段階から回避できます。

サービスアカウントの最小権限設計: Alert Center API の呼び出しには、Google Cloud プロジェクトのサービスアカウントと管理コンソールでのドメイン全体委任の設定が必要です。サービスアカウントに付与するスコープは Alert Center の読み取り権限のみに絞り、他の Admin SDK スコープと混在させない設計が基本です。スクリプトが侵害された際の被害範囲を最小化する、最小権限原則の実践です。

GWSセキュリティアラートのSlack自動通知設計

アラートを Slack に流す設計では、「どのアラートをどのチャンネルに、誰へのメンションつきで通知するか」を事前に定義しておく必要があります。

以下は優先度別の通知設計ひな形です。組織規模や体制に合わせて調整してください。

アラート優先度	通知先チャンネル	メンション	想定対応時間
緊急	#security-incident（プライベート）	@channel または担当者個人指名	即時（24時間）
高	#it-security（プライベート）	オンコール担当 @mention	30分以内
中程度	#it-ops	なし（バッジ通知のみ）	翌営業日午前中
低・参考	#it-logs	なし	週次確認で可

設計時に特に意識すべきポイントが3つあります。

チャンネルの可視性: 緊急・高優先度のアラートはプライベートチャンネルで管理し、担当者が確実に確認できる環境を作ります。パブリックチャンネルに流すと情報が埋もれやすく、見落としリスクが上がります。

通知メッセージの構造: 受け取った担当者が「何が起きているか」「誰が確認すべきか」「次のアクションは何か」を素早く判断できる形式にします。最低限含めるべき要素は次の5点です。

• アラートタイプ名（漏洩認証情報 / 不審なログイン / フィッシング検知 等）
• 影響を受けるユーザー名またはドメイン
• Google がアラートを生成した検知日時（JST 変換後）
• 優先度の分類（緊急 / 高 / 中程度 / 低）
• 初動アクションの一言案内（「管理コンソールのアラートセンターを確認してください」等）

管理コンソールへの直リンクをメッセージに含める設計も可能ですが、権限を持たない人が誤ってアクセスする混乱を避けるため、確認先は文字での案内に留め、操作は担当者に委ねる方がシンプルに機能します。

サイレント時間帯の設計: 深夜・休日でも「緊急」アラートは即時通知する一方、「中程度」以下は翌朝9時にまとめて通知するなど、担当者のアラート疲労を防ぐルールを事前に設定します。この設計を省くと、通知量の多さに担当者が慣れてしまい、本来見るべきアラートを読み飛ばす習慣が生まれます。

運用上の注意点：False Positiveとエスカレーション設計

自動監視フローを導入すると、必ずぶつかるのが False Positive（偽陽性：実害はないのにアラートが発火するケース）の問題です。

特に多いのは以下のようなケースです。

• 海外出張中のユーザーによる地理的異常アクセス検知
• 新しいデバイスからの初回ログインによる不審デバイス検知
• DLP ルールの設定が広すぎることによる大量のルール違反アラート
• IT 部門によるテスト・演習中に発生するアラート

False Positive への基本姿勢は「アラートを無視する習慣を作らない」ことです。偽陽性が多いと担当者がアラート通知に慣れてしまい（アラート疲労）、本当に重要なアラートを見落とすリスクが高まります。

有効な対策は2点あります。1点目はアラートタイプ別のトリアージ手順を文書化しておくこと。「このアラートが来たら、まず何を確認するか」を事前に決めると、担当者が判断に迷わず動けます。2点目は、False Positive と判断したアラートを適切にクローズして記録を残すこと。Alert Center API にはアラートのステータスを更新する機能があるため、Slack 通知フロー内でクローズ操作ができる仕組みを組み込むと、運用が格段に楽になります。

運用が安定してきたら、月次で「アラート件数 × 種別ごとの対応結果」を集計することを推奨します。「DLP アラートの大半が誤検知だった」という傾向が見えてきたら、DLP ルールの粒度見直しや、誤検知率の高いアラートタイプを低優先度チャンネルへ移動する設定調整のトリガーになります。False Positive の傾向を定期的にフィードバックするサイクルが、セキュリティ監視の長期精度を保つための現実的な保全策です。

エスカレーション経路の事前設計も重要です。自動通知だけでは対応が完結しない場合を想定し、以下のルールを事前に決めておきます。

• 30分以内に初動確認者が反応しない場合 → バックアップ担当への再通知
• 緊急アラートが業務時間外に発生した場合 → 電話連絡またはページャーへのエスカレーション
• 国家支援型攻撃アラートが発生した場合 → 経営層・法務・外部セキュリティベンダーへの即時報告

エスカレーション先と対応 SLA（Service Level Agreement：対応時間の取り決め）は、組織のセキュリティポリシーと合わせて文書化し、関係者全員が把握している状態を目指します。

まとめ：監査ログと組み合わせて「検知先行」の体制へ

Google Workspace Alert Center API を活用した自動監視フローは、100名規模の情シスでも導入できる現実的な手段です。

設計の核心は「アラートタイプごとの優先度分類」と「通知先・対応時間の事前定義」にあります。監査ログによる事後分析を既に活用しているチームでも、Alert Center API による能動的な検知を Slack 連携に乗せると、深夜・休日のインシデント見落としリスクを構造的に低減できます。

最初のステップは、緊急度の高いアラートタイプ（漏洩認証情報・不審ログイン・管理者操作変更）に絞った GAS ポーリング実装から始めることです。全アラートタイプを一気に取り込もうとすると、False Positive への対応が追いつかず運用が破綻しやすくなります。「小さく始めて磨く」積み上げ方が、セキュリティ監視自動化を定着させる現実的な進め方です。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。