AI の毎朝セキュリティ確認は「人が動く必要があるか」で色を決める

いつ使うか

• WAF・ログイン失敗・クラウドの操作記録（CloudTrail など）を AI エージェントに毎日まとめさせたい
• 既存のアラームが鳴りすぎて読まれていない

構成（株式会社 Stock 武田氏の Zenn 記事より）

• 指示書 1 枚をスケジュール実行。観測窓は「前回の実行から今回まで」（月曜は金曜から 72 時間）。
• 実行してよいのは許可リストにある読み取り専用コマンドだけ。作成・更新・削除、コンテナや DB への接続、権限変更は実行せず「要判断」に書かせる。書き込みは共有ノート 1 件の作成だけで、そのキーは別に持たせる。
• ルーティンでは直さない。是正の提案は保留して「既知の事項」として渡し、増えていないかだけ見る。
• 指示書に最初から書く: タイムスタンプは JST で書く（Logs Insights の @timestamp は UTC で、AI は混ぜる）。スキャン量（statistics.bytesScanned）を合計し、上限を超えそうなら残りを止めて「未確認」にする。

判定の作り方

1. 固定しきい値ではなく、同じ長さの窓の直近 7 日の中央値と比べる（平均だと 1 日の大きな攻撃に引きずられる）。証跡の停止のように 1 件で赤のものだけ固定ルールにする。
2. アラームが鳴ったら、実行者・送信元・MFA の有無まで AI に引かせる。社員の IAM ユーザー、MFA あり、想定内の作業（リリース、調査の読み取り）は社外回線でも緑。権限変更・秘密の読み出し・外部公開・実行者不明は黄。
3. 色は 🔴 要対応、🟡 要確認、🟢 対処済み、🔵 平常、⚪ 未確認。WAF で遮断できた急増は緑、遮断されずアプリまで届いてエラーが増え原因不明なら黄。
4. 緑にしたものも技術レポートには実行者と操作を全件残す。共有ノートには IP や利用者識別子を書かず、件数と判定だけ。⚪ は共有ノートには出さない。

S3 の公開ブロック監視で「塞いだ」操作に鳴らない

PutBucketPublicAccessBlock は有効化にも無効化にも使われるので、API 名だけ数えるとバケット作成のたびに鳴る。設定値が false のときと削除だけ数える。

{ ($.eventName = "DeletePublicAccessBlock") ||
  ($.eventName = "DeleteBucketPublicAccessBlock") ||
  (($.eventName = "PutBucketPublicAccessBlock") &&
   (($.requestParameters.PublicAccessBlockConfiguration.BlockPublicAcls IS FALSE) ||
    ($.requestParameters.PublicAccessBlockConfiguration.IgnorePublicAcls IS FALSE) ||
    ($.requestParameters.PublicAccessBlockConfiguration.BlockPublicPolicy IS FALSE) ||
    ($.requestParameters.PublicAccessBlockConfiguration.RestrictPublicBuckets IS FALSE))) }

• requestParameters の構造は自分の環境の実イベントで確かめる。パスが 1 段ずれると何も数えない監視になる。直したら検証環境でわざと false を入れ、鳴ることを確認する。
• 外部公開のアラームが鳴ったら、まず「開けたのか塞いだのか」を見る。

注意

• AI の「ログが無い」は「AI が見た範囲に無かった」という意味でしかない。実際には別の保存先に出ていた例がある。前提にして課題を起票する前に確かめる。
• これはリアルタイム監視の代わりではなく、前日分の見直し。即時の通知はアラームの役目。

関連

• AI の脆弱性巡回は「該当なし」を信用しない作りにする
• SOC の誤検知除外フィルターを LLM に「候補 3 案」出させて人が選ぶ

出典

• @yousukezan · 2026-11-07 （株式会社 Stock 武田 峻一「毎朝のセキュリティ確認をAIに任せたら…」Zenn）