こんにちは、クラウドネイティブ技術部の平田です。
先日行われたAWS Summit Japan 2026に参加してきました。去年から続いて2回目の参加になります。 今年はAWS認定全冠を取得したので金色の何かしらを貰えるのではと期待していましたが、AIPを取っていなかったので金の扇子は貰えませんでした。無念。
AWS Summitですが、去年に輪をかけて生成AI一色といった雰囲気でした。全体を通してAI DLCやAmazon Bedrock AgentCoreなど、AI駆動開発による開発・リリースの加速や、AI Agentの構築・活用についてのトピックが非常に多く、会場の熱量もそこに集中していた印象です。
一方で、AI駆動開発によって開発・リリース速度が上がれば上がるほど、「人間をボトルネックにせずにプロダクト品質やセキュリティをどう担保するか」という課題感も強く語られていました。弊社内でも、AI駆動開発フローの中でどうDevSecOpsを推進していくかは今まさに向き合っている課題です。
その解の一つとして、AWSからSecurity AgentやDevOps Agentといった、開発・運用・セキュリティを補助するAgent系サービスが発表されており、積極的に機能追加が行われています。今回のSummitでも、Security Agentの活用について紹介するセッションがあったので聴講してきました。
- セッション名：AWS Security Agent: 設計から導入まで"攻め"のアプリケーションセキュリティ [SEC221]
- 現在preview中のデザインレビュー・コードレビュー機能や、活用事例について紹介されていました
このセッションで紹介されていた機能の中でも、コードレビュー機能の使い心地が気になったので実際に触ってみました。
Security Agentの概要
AWS Security Agentは、開発ライフサイクル全体を通してアプリケーションのセキュリティを継続的に担保することを目的としたAI Agentサービスです。2025年12月にプレビューとして発表され、2026年3月にはペネトレーションテスト機能がGA(一般提供)となっています。
主な機能は以下の4つです。
- デザインレビュー(preview)
- 設計・アーキテクチャドキュメントをアップロードし、組織のセキュリティ要件との適合性をレビュー
- 脅威モデリング(preview)
- 設計ドキュメントやソースコードをもとに、STRIDE分類に基づいた脅威を洗い出し、深刻度と対応方針を提示
- コードレビュー(preview)
- リポジトリ内のコードを、セキュリティ要件や一般的な脆弱性パターンに基づいてレビュー。PRへの自動コメントやワンクリックでの修正PR作成が可能
- ペネトレーションテスト(GA)
- 稼働中のWebアプリケーション・APIに対して、多段階の攻撃シナリオを組み立てて実行し、脆弱性を検出・検証
ペネトレーションテストは$50/task-hourの従量課金制で、平均的なアプリケーションのテストで24task-hour程度(約$1,200)かかる想定とのことです1。
一方、デザインレビュー・コードレビュー・脅威モデリングの3機能はまだpreview中のため、現時点では追加課金なしで利用できます(アカウントあたりデザインレビュー月200件、コードレビュー月1,000件までの上限付き)2。
利用可能なリージョンは以下の9リージョンです3。なお、Summit時点ではpreview機能に対応しているのはバージニア北部のみだったようですが、現在は東京リージョンでも使えるようです。
- us-east-1(米国東部・北バージニア)
- us-west-2(米国西部・オレゴン)
- ap-south-1(アジアパシフィック・ムンバイ)
- ap-southeast-1(アジアパシフィック・シンガポール)
- ap-southeast-2(アジアパシフィック・シドニー)
- ap-northeast-1(アジアパシフィック・東京)
- eu-central-1(欧州・フランクフルト)
- eu-west-1(欧州・アイルランド)
- sa-east-1(南米・サンパウロ)
実際にコードレビューをさせてみる
AWS管理コンソールから設定を行いつつ、実際にコードレビューを試してみました。
Security Agentでは、マネージドのセキュリティ要件パックや、独自に定義したセキュリティ要件を設定してそれに沿ってレビューさせることが可能です。
今回はデフォルトで有効化されている、10の要件を含むマネージドパック「ASA Base Pack」のみを有効化して試します。このパックは認証・認可、データ保護、ログ、入力値検証など、多くのワークロードに共通するセキュリティ観点をベースラインとしてカバーしているようです。
1. エージェントスペース作成
まずはエージェントスペース名を入力し、エージェントスペースを作成します。 リポジトリとの紐付けや、レビュー実施に使用するSecurity Agent Webアプリのドメインはエージェントスペース単位で管理されるようです。
2. GitHubと連携
続いて、Security AgentとGitHubを連携します。GitHub Appsのインストール後、OAuthによりログイン・認可を行います。連携を許可するリポジトリを限定することも可能です。 Organization環境の場合は管理者の承認が必要になるので注意してください。この連携設定はAWSアカウント単位で管理されます。
3. コードレビューを構成
エージェントスペースに2.で作成したGitHub統合を接続し、コードレビューを構成します。 また、リポジトリ単位で「コードレビューコメント(PRへの自動コードレビュー・コメント投稿)」と「コード修正(検出結果の修正)」をそれぞれ有効化できるので、両方をオンにしておきます。読み取り専用のコード解析とは異なり、コメント投稿や修正PR作成といった書き込み操作はこれらのトグルで個別に制御される仕組みのようです。
レビューの基準は以下から選択可能です。今回は両方を選択します。
- Security Agentに設定されたセキュリティ要件との適合性チェック
- 一般的なセキュリティ脆弱性の検出
- 両方(デフォルト)
4. コードレビューを実行
レビュー対象のリポジトリには、ClaudeCodeに雑に作ってもらった脆弱なアプリ(FastAPI)を用意しました。
なお、リポジトリのルートに.awssecurityagent/filtering.mdというファイルを置いておくことで、スキャン対象からファイル・フォルダを除外したり、誤検知を減らすためのコンテキストを与えたりできるようですが、今回はこのカスタマイズは行っていません4。
レビュー方法には、オンデマンドのフルスキャンとPRの自動レビューの2パターンがあるので、両方試してみます。
オンデマンドのフルスキャン
まずはオンデマンドのスキャンを実施します。
Security Agent Webアプリにログインし、コードレビューを作成します。対象のリポジトリやログ出力先を選択できますが、ブランチ指定の項目は見当たらなかったので、デフォルトブランチのコードがスキャン対象になっているものと思われます。
検出された違反に対して自動でPRを作成する設定も可能で、無効化していても検出結果の確認画面からワンクリックでPR作成が実施できます。また、スキャン結果はPDFでダウンロードすることも可能です。
数百行程度の単純なコードでしたが、スキャン完了までは45分程度かかりました。時間はある程度かかりますが、修正のPRも自動作成してくれるのは嬉しいですね。
フルスキャンは、リポジトリ全体を読み込んでアプリケーションのエントリーポイントやトラストバウンダリ、データフローを把握し(プロファイリング)、リスクの高い箇所に専門のAgentを割り当てて調査し(脆弱性探索)、検出候補を重複排除・要否判断した上で(トリアージ)、最後に別のAgentが検出結果を独立して検証する(独立検証)、という4段階のプロセスで動いているようです。
単純なパターンマッチではなく、アプリケーション全体のコンテキストを踏まえてレビューしている点が特徴と言えそうです。
ちなみに今回はアプリケーションに10個の脆弱性を仕込んだ上でスキャンを実行しましたが、結果は以下の通り、埋め込んだ脆弱性はすべて検出されました。
| # | 埋め込んだ脆弱性 | 深刻度 | 分類 | 検出結果 |
|---|---|---|---|---|
| 1 | SQLインジェクション(ログイン・検索) | Critical | Security Finding | ✅ 検出 |
| 2 | 認証・認可の欠如(全エンドポイント無防備) | Critical | Security Finding | ✅ 検出 |
| 3 | 管理者エンドポイントの認証情報漏洩 | Critical | Security Finding | ✅ 検出 |
| 4 | OSコマンドインジェクション | Critical | Security Finding | ✅ 検出 |
| 5 | ハードコードされた認証情報・シークレット | Critical | Security Finding | ✅ 検出 |
| 6 | パスワード平文保存 | High | Security Finding | ✅ 検出 |
| 7 | 特権操作の監査ログ欠如 | Critical | Non-Compliant Requirement | ✅ 検出 |
| 8 | 通信・保存データの暗号化欠如 | High | Non-Compliant Requirement | ✅ 検出 |
| 9 | 安全でないデフォルト設定(APIドキュメント公開等) | Medium | Non-Compliant Requirement | ✅ 検出 |
| 10 | ロギング基盤の欠如 | Medium | Non-Compliant Requirement | ✅ 検出 |
単純なものから複数コンポーネントをまたぐようなものまで、幅広く検出できていました。1〜6は一般的なセキュリティ脆弱性(Security Finding)として、7〜10はASA Base Packのセキュリティ要件への違反(Non-Compliant Requirement)として検出されており、コードレビュー構成時に選択した2つの観点(セキュリティ要件への適合性チェック・一般的な脆弱性の検出)がそれぞれ機能していることがわかります。
PRの自動レビュー
次にPRを作成してみます。PRの自動レビューは有効化済みです。ClaudeCodeに脆弱なコードを含むPRを作成してもらうと、PR作成から数分後、Security Agentのbotから「AWS Security Agent is analyzing your code…」というコメントが投稿されました。その15分後くらいに、レビュー指摘のコメントが追加されました。（現状、PRコメントの日本語対応はされていないようです）
PRコメントはデフォルトでもある程度決まったフォーマットで生成されるようで、Copilotの指摘と比べるとだいぶ読みやすく感じました。（検出の根拠、リスク、推奨対応などが含まれる）
加えて、PRコメントに「@AWS-Security-Agent fix all findings」と投げれば、Security Agentが修正まで自動で行ってPRに反映してくれます。
なお、このPRコメントによる自動修正はコードレビューの構成時に「コード修正」を有効化しておく必要があるようです。公式ドキュメント上、リポジトリへの読み取りアクセス(コード解析)と、コメント投稿・修正PR作成といった書き込み操作は明確に分離されており、コードレビュー構成時に「コードレビューコメント」と「コード修正」をリポジトリごとに独立してオン/オフする仕組みになっています5。今回は事前に両方を有効化していたため、追加の作業なしで自動修正まで確認できました。
まとめ
今回試してみて、Security Agentのコードレビュー機能は「コードに脆弱性や組織のセキュリティ要件違反が含まれていないかを、アプリ全体のコンテキストを理解した上でチェックしてくれ、指摘だけでなく修正PRまで自動で作ってくれる」という体験としては非常に完成度が高いと感じました。その上で、既存の選択肢と比べてどこが嬉しいのかを整理してみます。
従来のSAST(semgrepやCheckovなど)との比較
semgrepやCheckovのような従来のSASTツールは、高速・無料(または低コスト)・ローカル実行可能という強みがあり、決定的なルールに基づく検出であれば今後もこれらのツールが適任だと考えています。実際、AWS Summit 2日目のアーキテクチャ道場でも「LLMに任せるのは推論が必要な部分に絞り、決定的な操作は従来通りコードで実施すべき」という趣旨の話があり、この考え方には強く同意します。
一方でSecurity Agentのコードレビューが優位に立つのは、アプリケーション全体のコンテキスト(エントリーポイント・トラストバウンダリ・データフロー)を踏まえた上で、単体のパターンマッチでは見つけにくい「設計上の穴」や「複数ファイルをまたいだ攻撃経路」を推論できる点です。ルールベースのSASTでは検知が難しい、ビジネスロジックに起因する脆弱性や、複数のコンポーネントの組み合わせによって初めて成立する脆弱性のカバーは、Security Agentのような推論型のレビューに向いている領域だと感じます。
つまり、「決定的に検知できるものはSASTに任せ、コンテキスト理解や複数ファイルをまたいだ推論が必要な部分をSecurity Agentが補う」という併用が現実的な使い方になりそうです。
他のAIコーディングエージェント(ClaudeCode・Codex・Copilotなど)との比較
ClaudeCodeやCodex、Copilotなどのコーディングエージェントを使えば、わざわざSecurity Agentを使わずともコードレビュー自体は実施できます。それでもSecurity Agentを併用する意味があるとすれば、以下の点だと考えています。
- セキュリティ要件を組織で一元管理し、全リポジトリ・全チームに一律で適用できる
- プロジェクトやチームごとに都度セキュリティ要件を定義せずとも、組織単位で定義された要件セット(ASA Base Packのようなマネージドパックや独自要件)を開発フローへ強制的に組み込める点は、ガバナンスの観点で大きなメリットです
- 開発者ごとの指示に依存しない
- ClaudeCodeなどでレビューさせる場合、どこまで厳密にセキュリティ観点でレビューできるかは開発者の指示やレビュー用Skillの有無等で左右されがちです。Security AgentはAWSによって専用にチューニングされたセキュリティレビューエージェントであり、検証プロセスも組み込まれているため、一定の品質を組織として担保しやすいと感じました
なお、Security AgentはMCPサーバーとしても提供されており、ClaudeCodeなどからSecurity Agentによるコードスキャンを呼び出すことも可能なようです。ローカル環境にAWS認証情報を設定しておくことで、MCPサーバーがエージェントスペースやS3バケットなどの必要なリソースをオンデマンドでプロビジョニングしてくれる仕組みになっています6。
総評
Security Agentのコードレビューは、「組織ごとのセキュリティ要件を各チームの開発フローに一律で適用し、検出・修正までを容易に実施できる」という点が最大の魅力に感じました。今後の機能拡張にも期待しつつ、引き続き実運用への導入も検討していきたいと思います。
preview期間中は追加コストなしで試せるので、DevSecOpsの体制強化を検討している場合は今のうちにぜひ触ってみることをお勧めします。
