AWS Security Agent まとめ
第1章：はじめに 〜 なぜ AWS Security Agent なのか
AWS Security Agent は、AWS re:Invent 2025 にて発表された新しいセキュリティサービスです。
これまで AWS のセキュリティサービスは、主に「実行環境」や「設定」を対象に進化してきました。一方で、本サービスは 設計やコードといった開発物そのものを対象にする という点で、これまでとは異なるアプローチを取っています。
従来の AWS セキュリティ運用の課題
脆弱性検知は「後追い」になりがち
従来の AWS セキュリティ運用では、アプリケーションを本番環境にデプロイした後に、
- Amazon Inspector による脆弱性検知
- AWS Security Hub による設定不備やリスクの集約
といった形で問題が可視化されるケースが一般的でした。
このモデルでは、問題が発見された時点ですでにシステムは稼働しており、
設計やコードに起因する脆弱性の場合、修正コストが高くなる傾向があります。
設計・コード段階のセキュリティレビューは属人化
設計書レビューやコードレビューにおけるセキュリティ観点は、
- 特定のセキュリティ有識者に依存している
- レビューの粒度や品質が人によってばらつく
- 忙しいと後回しにされやすい
といった課題を抱えがちです。
結果として、「セキュリティを意識しているつもりでも、体系的に担保できていない」状態に陥ることも少なくありません。
DevSecOps / シフトレフトの文脈
こうした背景から、近年は DevSecOps や Shift Left（シフトレフト）といった考え方が重視されるようになってきました。
Shift Left とは、セキュリティを開発プロセスの後半ではなく、
設計や実装といった早い段階に組み込む というアプローチです。
AWS Security Agent は、この Shift Left を「人の努力」ではなく、
サービスとして実現しようとする試み と言えます。
第2章：AWS Security Agent とは何か
AWS Security Agent は、アプリケーションの設計・コード・デプロイ前段階を対象に、
セキュリティレビューや侵入テストを自動で実施する AI エージェント型のセキュリティサービス です。
単なる脆弱性検知ツールではなく、
- 何を作ろうとしているのか
- その設計やコードがどのようなリスクを持つのか
- どう修正すべきか
といった点を、一連の流れとして扱うことを目的としています。
「Agent」という名前が示す意味
ルールで検知するツールではない
従来の多くのセキュリティツールは、あらかじめ定義されたルールやシグネチャに基づき、
「条件に一致したかどうか」を判断して問題を検知してきました。
この場合、
- 想定外の構成や実装には弱い
- なぜ問題なのかが分かりにくい
といった課題がありました。
コンテキストを理解して判断・提案する存在
AWS Security Agent は、アーキテクチャ構成、コード、セキュリティ要件といった情報を踏まえ、
アプリケーション全体の文脈（コンテキスト）を理解した上で判断 を行います。
その結果として、
- なぜそれがリスクになるのか
- 実際にどのような攻撃が成立し得るのか
- 現実的な修正方法は何か
まで含めて提示できる点が大きな特徴です。
この「理解して考え、提案する」振る舞いこそが、
AWS Security Agent が単なるツールではなく「Agent」と呼ばれる理由です。
第3章：AWS Security Agent の主要機能
AWS Security Agent は、アプリケーション開発ライフサイクルの中でも特に
「設計」「コード」「本番前検証」 にフォーカスし、3つの主要機能を提供します。
いずれも「検知して終わり」ではなく、理解・説明・修正提案までを一貫して行う点が特徴です。
設計段階のセキュリティレビュー
設計段階のセキュリティレビューでは、アーキテクチャ設計やシステム構成を入力として、
セキュリティ観点からの妥当性を評価します。
- 認証・認可設計は適切か
- ネットワーク分離やアイソレーションは十分か
- データ保護や暗号化設計に抜け漏れはないか
といったポイントを、組織のセキュリティ要件と照らし合わせて分析します。
この段階で問題を指摘できることで、
コードを書く前にリスクを潰す ことが可能となり、後工程での手戻りを大きく減らせます。
コードのセキュリティレビュー
コードのセキュリティレビューでは、ソースコードや Pull Request を対象に解析を行います。
一般的な SAST（静的解析）は、特定の危険な書き方やパターン検出に主眼が置かれますが、
AWS Security Agent はそれに加えて、
- コードの文脈理解
- 設計との整合性
- アプリケーション全体としての振る舞い
といった点を考慮して判断を行います。
そのため、単なる指摘ではなく、
- なぜそれがリスクなのか
- 実際にどう修正すべきか
といった 開発者が次に取るべきアクション まで含めたフィードバックが得られます。
オンデマンド・ペネトレーションテスト
AWS Security Agent は、オンデマンドでのペネトレーションテストも提供します。
アプリケーション構成や実装内容を理解した上で、
- 攻撃シナリオの生成
- 多段階攻撃のシミュレーション
- 攻撃が実際に成立するかの検証
を行います。
従来のペネトレーションテストは高コストかつ低頻度になりがちでしたが、
Security Agent では 必要なタイミングで繰り返し実施できる 点が大きな違いです。
さらに、結果として得られるのは単なる報告書ではなく、
- 実際に成立する脆弱性
- 影響範囲やリスクの説明
- 具体的な修正提案
まで含めた、実践的なアウトプットです。
第4章：従来の AWS セキュリティとの使い分けとまとめ
他の AWS セキュリティサービスとの住み分け
AWS Security Agent は、既存の AWS セキュリティサービスを置き換えるものではありません。
それぞれが守るレイヤーとタイミングが異なります。
-
Security Hub / Amazon Inspector
- 実行環境・設定・ランタイムのセキュリティを担保
- デプロイ後のリスク可視化が中心
-
AWS Security Agent
- 設計・コード・本番前段階のセキュリティを担保
- 開発プロセスの早い段階でのリスク低減が目的
このように、後追いの検知 と 事前の予防 という役割分担で考えると理解しやすくなります。
どんなチームに向いているか
向いているケース
- セキュリティレビューが特定の担当者に依存している組織
- ペネトレーションテストの頻度を上げたいが工数が確保できない場合
導入時に意識すべきポイント（Preview 前提）
- 現時点では Preview サービスである点 (2025/
- すべてを自動化に任せきりにせず、人の判断と組み合わせること
- まずは一部プロジェクトから段階的に試すこと
まとめ
AWS Security Agent は、
セキュリティを「後追いのチェック」から「開発プロセスの一部」へと変えるサービスです。
セキュリティ担当者は「レビューする人」から「ルールや方針を定義する人」へ、
開発者は「指摘されて直す」から「最初から安全な設計・実装を選ぶ」へと役割が変わっていきます。
AWS Security Agent は、
AI Agent を前提とした次世代のセキュリティ運用 に向けた重要な一歩と言えるでしょう。