AWS Security Agent でAIペネトレーションテスト — 受託SaaSのクラウド監査を自動化する 2026

2026 年 5 月初旬、Zenn Trending に 「AWS Security AgentでAIによるレビューとペネトレーションテストをやってみた」 がランクインしました。AWS が公開した Security Agent は、LLM ベースで IAM / VPC / S3 / RDS など主要サービスの設定をレビューし、ペネトレーションテスト相当の挙動まで踏み込むという、これまで人手だった領域を一気に自動化する道具です。

弊社の受託では AWS 上に SaaS を構築 → 顧客に引き渡し → 顧客側が運用 という流れの案件が多く、引き渡し後のクラウドセキュリティ監査が 「年 1 回の高額外注 vs 何もしない」 の二択になりがちでした。本記事では、AWS Security Agent を受託 SaaS の継続監査に組み込む設計を整理します。

なぜ AWS のクラウド監査が “受託の盲点” だったのか

AWS 上の受託案件で、引き渡し後に発覚しがちな落とし穴は以下です。

これらは マネーフォワードGitHub事件から学ぶ — 受託で必ず実施したいソースコード漏洩監査 で扱った “ソースコード側の監査” と対になる 「クラウドインフラ側の監査」 で、両方が揃わないと受託 SaaS の防御は完成しません。

AWS Security Agent ができること（受託で気にすべき範囲）

元 Zenn 記事と AWS 公式ドキュメントから、受託で重要な機能を抽出します。

特に 「設定変動の月次レポート」 は、運用フェーズ受託のサブスク化に直結する機能です。今までは “年 1 回の手動診断” でしか得られなかったレポートが、月次で自動生成 + 受託側で解釈 という形で月次定額の価値を作れます。

受託 SaaS のスコープ設計 — “どこまで AI に任せるか”

AWS Security Agent を受託で使う際、スコープ設計を誤ると 誤検知の山に埋もれて運用が止まるのが典型的失敗です。受託で安定運用する標準スコープを示します。

ポイントは 「人がやる」レーンを明示的に残すことです。AI Security Agent が高い精度で検出を出せても、ビジネス文脈・契約観点・規制対応は AI に丸投げできません。受託としては、AI 出力に対する解釈と顧客説明こそが本質的な価値になります。

誤検知の吸収 — 受託で実装する仕組み

LLM ベースのセキュリティ診断は 誤検知の吸収が運用の全てです。受託で組み込む仕組みは以下の 3 段重ね：

[Security Agent 検出]
   ↓
[1段目: 既知例外DB との突合]   ← 過去に "問題なし" と判断した検出は自動抑制
   ↓
[2段目: 重大度の自動再採点]    ← 業務影響度 + 攻撃成功確率で再採点
   ↓
[3段目: 受託側エンジニアのトリアージ] ← Slack 通知 → 30 分 SLA でトリアージ
   ↓
[顧客報告]                     ← 月次レポートに残す

ポイントは 「既知例外 DB」 の運用です。一度 “ビジネス上の理由で許容” と判断した検出は、再発時に自動抑制する仕組みがないと、毎月同じ通知が量産されてアラート疲れが起きます。受託の運用契約では、例外台帳のメンテナンスが地味ながら最重要タスクになります。

これは AIで月$0.5のセキュリティ診断 — 受託サービスとしてパッケージ化する設計と価格戦略 で扱った “アプリ層 / コード層の AI 診断” の クラウドインフラ層 に当たります。両者を組み合わせると、受託 SaaS の 「コード + クラウド」両面をひと続きのセキュリティ運用として設計できます。

受託で使う “ペネトレーションテスト相当” の運用

AWS Security Agent の ペネトレーションテスト相当機能は、本物のペネトレーションテストの代替にはなりませんが、「事前スクリーニング + 月次健康診断」 として極めて有用です。

受託の現場では 「平時は AI、年 1 と節目は人手のプロ」 という二段構えが現実解です。AI Security Agent だけで全てカバーできる、と顧客に説明すると後で “本物の手動 PT が必要だった” と発覚する事故になります。

月次運用契約の設計 — 人手をどこまで載せるか

AWS Security Agent をベースに、受託で月次運用契約を組むときの設計軸を示します。

左に寄せるほど AI の出力をそのまま顧客が受け取る運用、右に寄せるほど受託側エンジニアの工数が乗る運用になります。どこに置くかは、受託 SaaS の規模と、顧客側にアラートを受け止める人がいるかどうかで決まります。

なお 「初回監査だけ」を単発で切り出すのは避けるべき です。是正対応と月次運用が続かないと、1 回限りのレポートが棚に眠るだけで顧客の安全には貢献しません。

引き渡しチェックリスト — 受託でそのまま使える 12 項目

• AWS Security Agent が顧客アカウントで稼働している
• スコープ（カバー対象 / 対象外）が文書化されている
• 既知例外 DB が初期化済み（過去判断の引き継ぎ済み）
• Slack 通知の宛先 / 重大度別ルーティングが設定済み
• 月次レポートのテンプレが顧客承認済み
• CloudTrail / GuardDuty の有効化が確認済み
• IAM の最小権限化が一巡している
• S3 / RDS / DynamoDB の暗号化が全リソースで有効
• Terraform / CloudFormation の差分修正フローが回っている
• “Security Agent 単独では PT 代替にならない” が顧客と合意済み
• 年 1 手動 PT の予算と手配が SOW に明記
• 緊急時の連絡経路（24h or 営業時間内）が文書化

まとめ — クラウド監査は “年 1 高額外注” から “AI 月次サブスク + 人手節目” へ

AWS Security Agent は、受託 SaaS のクラウド監査の経済性を根本から変えるツールです。年 1 の高額外注に頼るしかなかった中小規模の SaaS でも、設定が変わるたびに健康診断を回す運用が現実的な選択肢になりました。

ただし本文で見たとおり、監査の重さは AWS アカウントの構造・例外がどれだけ溜まっているか・顧客側にアラートを受け止める人がいるかで大きく変わります。同じ「月次監査」でも、例外台帳をゼロから起こす環境と引き継げる環境では初月の手間が別物です。上のチェックリストを自社の AWS 環境に当てて埋まらない項目があった方、「年 1 PT の合間が無防備だ」と感じている方は、いま動いているアカウントの状況を添えて お問い合わせフォーム からご相談ください。どこまで AI に寄せられるかを見てから、運用の形を組み立てます。

Sources

• AWS Security AgentでAIによるレビューとペネトレーションテストをやってみた（Zenn）
• AWS Security Agent 公式ドキュメント
• Securing Autonomous AI Agents on Kubernetes（InfoQ）