はじめに（修正版）
設計レビューの段階でセキュリティの抜け漏れを拾い切るのは、思っている以上に難しい。認可の考慮不足、機密データの露出、監査ログの設計漏れなどは、実装や結合テストの後半で見つかって手戻りになりがちだ。特に「設計書に書いていない＝考えていない」になってしまうと、修正の影響範囲が一気に広がる。
そこで本記事では AWS Security Agent（プレビュー） の Design Security Review を使って、設計段階からリスクを洗い出す流れを試す。やることはシンプルで、Kiro の Spec-Driven Development で生成した技術設計書（design.md）をアップロードし、AWS のベストプラクティス（＋必要に応じて組織要件）に照らして指摘をもらう。
具体的には、まずデフォルトの要件だけで1回レビューを回し、その後で カスタムセキュリティ要件を追加してもう一度レビューする。要件追加の前後で結果がどう変わるかを見ることで、「デフォルトだけだと何が見えにくいのか」「組織要件を入れると何が改善されるのか」を整理するのが狙いになる。
AWS Security Agent のステータス: 2026年2月時点でパブリックプレビュー。利用可能リージョンは US East (N. Virginia) のみ。プレビュー期間中は無料で利用できる。
関連記事: Kiro の Spec-Driven Development で
design.mdを生成するまでの手順は
Kiro の Spec-Driven Development でヒアリング結果を構造化された仕様書に変換する ── 要件定義をAIで効率化 を参照。
本記事で使う設計書
本記事では、Kiro の Spec-Driven Development で生成した EC サイトのユーザー認証機能の設計書（design.md） を Security Agent のレビューにかける。
この design.md には以下が含まれている詳細は関連記事を参照。
- システム構成図（Mermaid）: Next.js → API Gateway → Lambda → Cognito の接続関係
-
API エンドポイント設計:
/auth/signup、/auth/signin等 9つのエンドポイント -
TypeScript インターフェース定義:
SignupFormProps、LoginFormState、IAuthClient等 - AWS CDK インフラコード: Cognito User Pool、Lambda、API Gateway の定義
- セキュリティ考慮事項: CSRF 対策、レート制限、トークン管理
- ログ記録戦略: ログレベル定義、PII マスキング方針
AWS Security Agent とは
AWS Security Agent は、re:Invent 2025 で発表された AI エージェントだ。開発ライフサイクル全体にわたってアプリケーションのセキュリティを継続的に検証するサービスで、以下の3つの機能を持つ。
| 機能 | 概要 |
|---|---|
| Design Security Review | 設計書のセキュリティレビュー（本記事で解説） |
| Code Review | GitHub PR に対する自動セキュリティレビュー |
| Penetration Testing | デプロイ済みアプリへのペネトレーションテスト |
従来の SAST（静的解析）ツールはソースコードのみ、DAST（動的解析）ツールは実行環境のみを対象とするが、AWS Security Agent は設計書・ソースコード・セキュリティ要件のすべてを理解した上でレビューを行う点が特徴的だ。
公式ページ: https://aws.amazon.com/security-agent/
全体ワークフロー
本記事で実行するワークフローの全体像は以下のとおり。
[Kiro] design.md 生成
↓
[Security Agent] Agent Space 作成
↓
[Security Agent] Design Security Review 実行（1回目: デフォルト要件のみ）
↓
[Security Agent] カスタムセキュリティ要件を追加
↓
[Security Agent] Design Security Review 再実行（2回目: カスタム要件あり）
↓
[比較] 1回目と2回目の結果を比較
↓
[Kiro] design.md にセキュリティ修正を反映
前提条件
- AWS アカウント（US East (N. Virginia) リージョンで利用可能であること）
- Kiro で design.md が生成済み（関連記事の手順で生成）
- AWS Security Agent のプレビューアクセス（2026年2月時点ではリクエスト不要で利用可能）
手順1: Agent Space の作成
AWS Security Agent は Agent Space という単位でプロジェクトを管理する。Agent Space は、セキュリティレビューの対象となるアプリケーションを表す論理的なコンテナだ。
AWS マネジメントコンソールで AWS Security Agent を開き（リージョンを US East (N. Virginia) に切り替え）、初期画面で 「最初のエージェントスペースを作成」 をクリックする。
Agent Space の作成フォームで以下を入力し、「作成」 をクリックする。
| 項目 | 入力値 |
|---|---|
| エージェントスペース名 | ec-site |
| 説明 | テスト用 Agent Space |
作成が完了すると、Agent Space のダッシュボードが表示される。設計レビュー、コードレビュー、ペネトレーションテストの3つの機能が表示されるが、今回使用するのは設計レビューだ。設計レビューは Agent Space 作成直後から 「✅ 準備完了」 となっており、追加のセットアップは不要。
補足: コードレビューは GitHub 連携、ペネトレーションテストはデプロイ済みアプリへのアクセス設定がそれぞれ必要だが、Design Security Review はこれらのセットアップなしで即座に利用できる。
手順2: Design Security Review の実行（1回目: デフォルト要件のみ）
まずはカスタムセキュリティ要件を追加せずにレビューを実行し、AWS のデフォルトのベストプラクティスだけでどの程度の検出ができるかを確認する。
Web Application へのアクセス
Agent Space のダッシュボード右上にある 「ウェブアプリを起動」 ボタンをクリックすると、Security Agent の Web Application に遷移する。Web Application は AWS マネジメントコンソールとは別のインターフェースで、Design Security Review の実行はここから行う。
| インターフェース | 用途 |
|---|---|
| 管理コンソール（AWS マネジメントコンソール内） | Agent Space の作成・設定、セキュリティ要件定義 |
| Web Application | Design Security Review の実行、結果の確認 |
設計書のアップロードとレビュー
Web Application の左サイドバーから 「Design reviews」 を選択し、「Create design review」 をクリックする。レビュー名を入力し、Kiro で生成した design.md をアップロードして 「Start design review」 をクリックする。
アップロードできるドキュメントの種類は DOC、DOCX、JPEG、MD、PDF、PNG、TXT で、1レビューあたり最大5ファイル（各2MB、合計6MB）まで。
1回目のレビュー結果
レビューは約1分で完了した。結果は以下のとおり。
AWS デフォルトの 10のセキュリティコントロール に対してレビューが実行され、以下の結果が得られた。
| ステータス | 件数 | 該当コントロール |
|---|---|---|
| ✅ Compliant | 4件 | Trusted Cryptography、Authentication、Audit Logging、Secure by Default |
| ⚠️ Insufficient data | 4件 | Log Protection、Authorization、Information Protection、Secret Protection |
| ⊘ Not applicable | 2件 | Privileged Access、Tenant Isolation |
| ❌ Non-compliant | 0件 | なし |
Non-compliant（違反）が0件という結果だ。Kiro が生成した design.md は、暗号化（Cognito の bcrypt）、認証フロー、セキュアなデフォルト設定（HttpOnly Cookie、HTTPS 強制、未認証アクセス拒否）については十分な記述があり、AWS のベストプラクティスに準拠していると評価された。
一方、Insufficient data が4件あり、設計書に以下の情報が不足していると指摘された。
- Log Protection: ログの保存先、アクセス制御、保持期間、改ざん防止措置が未記載
- Authorization: 認証（誰であるか）は記載あるが、認可（何ができるか）が未記載
- Information Protection: PII の保存時暗号化が未明記
- Secret Protection: Lambda → Cognito 間の認証方法（IAM ロール等）が未記載
ポイント: カスタムセキュリティ要件を定義していなくても、AWS のデフォルトのベストプラクティス（10コントロール）でレビューが実行される。まず最初にデフォルトでレビューし、結果を見てからカスタム要件を追加するアプローチも有効だ。
手順3: カスタムセキュリティ要件の追加
1回目の結果を踏まえ、組織固有のセキュリティ要件を追加してレビュー精度を上げる。
AWS マネジメントコンソールに戻り、左サイドバーの 「セキュリティ要件」 をクリックする。「マネージドセキュリティ要件」（AWS 提供のデフォルト10件）と 「カスタムセキュリティ要件」 のタブがある。
「カスタムセキュリティ要件を作成」 をクリックすると、以下のフィールドを持つフォームが表示される。
- セキュリティ要件名: チェック対象の名称
- 説明: チェック内容の概要
- 適用性: どのようなシステムに適用するか
- コンプライアンス条件: 準拠/違反の判定基準
- 是正ガイダンス: 違反時の修正方法
今回は以下の3つのカスタム要件を作成した。
| # | セキュリティ要件名 | 概要 |
|---|---|---|
| 1 | API JWT認証の必須化 | すべての保護対象 API エンドポイントで JWT 認証を必須とする |
| 2 | 個人情報の暗号化保存 | PII を保存するストレージで保存時暗号化を有効にする |
| 3 | 外部API呼び出しのタイムアウト設定 | 外部 API 呼び出しに接続/リードタイムアウトを設定する |
「セキュリティ要件の作成と有効化」 ボタンをクリックすると、作成と同時にレビューへの適用が有効化される。3件とも作成が完了すると、カスタムセキュリティ要件の一覧に表示される。
ポイント: カスタムセキュリティ要件は一度定義すれば Agent Space 内のすべてのレビューに自動適用される。プロジェクト横断で一貫したセキュリティ基準を維持できるため、最初の設定に時間をかける価値がある。
手順4: Design Security Review の再実行（2回目: カスタム要件あり）
カスタム要件を追加した状態で、同じ design.md に対してレビューを再実行する。Web Application で新しいレビュー（ec-site-with-custom-requirements）を作成し、design.md をアップロードして実行した。
2回目のレビュー結果
1回目と2回目の比較
| カテゴリ | 1回目（デフォルトのみ） | 2回目（カスタム要件あり） | 変化 |
|---|---|---|---|
| ❌ Non-compliant | 0件 | 3件 | +3 |
| ⚠️ Insufficient data | 4件 | 4件 | ±0 |
| ✅ Compliant | 4件 | 4件 | ±0 |
| ⊘ Not applicable | 2件 | 2件 | ±0 |
| 合計コントロール | 10件 | 13件 | +3 |
カスタム要件を追加したことで、Non-compliant が 0件 → 3件に増加した。 これは「設計書に問題がなかった」のではなく、「デフォルト要件だけでは検出できないリスクがあった」ということだ。
Non-compliant 3件の詳細
1. 外部API呼び出しのタイムアウト設定（カスタム要件）
Lambda 関数から Cognito への AWS SDK 呼び出しに接続タイムアウトとリードタイムアウトが設定されていない。Lambda のタイムアウト（30秒）は設定されているが、SDK クライアントレベルのタイムアウトが未設定のため、Cognito が無応答になった場合にリソース枯渇のリスクがある。
是正: AWS SDK クライアント初期化時に connectionTimeout: 5000（5秒）と requestTimeout: 30000（30秒）を設定する。
2. 個人情報の暗号化保存（カスタム要件）
Cognito User Pool にメールアドレスと氏名を保存しているが、保存時暗号化（encryption at rest）が設計書に明記されていない。Cognito はデフォルトで暗号化をサポートしているが、設計書にその旨の記載がなく、鍵管理方針も未定義。
是正: Cognito User Pool の保存時暗号化が有効であること（AWS 管理キーによる AES-256）を設計書に明記し、CDK 定義にもコメントとして記載する。
3. Audit Logging Best Practices（マネージド要件）
1回目のレビューでは Compliant だったが、2回目では Non-compliant に変化した。カスタム要件の追加によりレビューのコンテキストが変わり、「ログレベルとフォーマットの定義はあるが、具体的にどのセキュリティイベントをログに記録するかが不明確」と判定が厳しくなった。
是正: ログ記録すべきセキュリティイベント（認証成功/失敗、パスワードリセット、アカウントロック、トークンリフレッシュ、不正アクセス試行）を明示的に定義し、各イベントでユーザー ID、IP アドレス、タイムスタンプ、アクション結果を記録する設計を追加する。
発見: カスタム要件を追加すると、既存のマネージド要件の判定結果も変わることがある。カスタム要件がレビューのコンテキストを豊かにし、より厳密な評価が行われるためだ。これは組織セキュリティ要件を定義する大きなメリットの一つと言える。
手順5: レビュー結果を Kiro で設計書に反映する
Security Agent から指摘された Non-compliant 3件と Insufficient Data 4件を、Kiro にフィードバックして design.md を更新する。
Kiro IDE でプロジェクトを開き、Vibe モードのチャットで以下のように修正を依頼した。
#spec:user-authentication
AWS Security Agent の Design Security Review で以下が指摘されました。
design.md に不足している情報を追加して修正してください。
【Non-compliant（違反）3件】
1. 外部API呼び出しのタイムアウト設定
修正: AWS SDKクライアント初期化時に接続タイムアウト（5秒）とリードタイムアウト（30秒）を設定する
2. 個人情報の暗号化保存
修正: Cognitoの保存時暗号化がAWS管理キーで有効であることを明記し、CDK定義にも反映する
3. Audit Logging Best Practices
修正: 8種類のセキュリティイベントの記録設計を追加する
【Insufficient Data（情報不足）4件】
4. Log Protection: ログの保存先、アクセス制御、保持期間、改ざん防止措置
5. Authorization: 認可モデル、APIでの認可チェック方法
6. Information Protection: PII保存時暗号化、転送時セキュリティ
7. Secret Protection: IAMロールによるCognitoアクセス、シークレット管理方針
Kiro は design.md を読み込み、指摘事項に対応するセクションを自動的に追加・更新した。
Kiro は約3分半（Credits: 1.17）で以下の修正を design.md に反映した。
Non-compliant 3件の修正:
-
外部API呼び出しのタイムアウト設定: AWS SDK クライアント初期化時に
connectionTimeout: 5000、requestTimeout: 30000を設定するコード例を追加 - 個人情報の暗号化保存: Cognito User Pool の AWS 管理キーによる AES-256 保存時暗号化を明記し、CDK 定義にもコメントを追加
- Audit Logging: 8種類のセキュリティイベント（認証成功/失敗、パスワードリセット、アカウントロック、トークンリフレッシュ、不正アクセス試行、ログアウト）を定義し、各イベントでユーザー ID、IP アドレス、タイムスタンプ、アクション結果を記録する設計を追加
Insufficient Data 4件の修正:
- Log Protection: CloudWatch Logs への保存、IAM によるアクセス制御、90日間の保持期間、改ざん防止措置（書き込み専用、CloudTrail 監査）を追加
- Authorization: 認証済みユーザーがアクセスできるリソースとアクション、API Gateway での認可チェック、Lambda 関数内でのリソースレベル制限を追加
- Information Protection: Cognito の保存時暗号化、パスワード転送時の HTTPS セキュリティ、ログ内の PII マスキング方針を明記
- Secret Protection: IAM 実行ロールによる Cognito アクセス、ハードコードされたシークレットがないこと、環境変数にはリソース ID のみを設定する方針を追加
IaC テンプレートへの反映
Kiro の design.md には AWS CDK のインフラコードが含まれている。セキュリティレビューの指摘事項は IaC レベルにも反映される。今回の修正では、CDK 定義に以下が追加された。
- Cognito User Pool の保存時暗号化に関するコメント
- AWS SDK クライアントのタイムアウト設定コード
- CloudWatch Logs の保持期間設定
結果まとめ: カスタム要件がレビュー精度を変える
本記事で最も重要な発見は、カスタムセキュリティ要件の有無がレビュー結果に大きく影響するということだ。
1回目（デフォルトのみ）: Non-compliant 0件 / 10コントロール → 問題なしに見える
2回目（カスタム要件あり）: Non-compliant 3件 / 13コントロール → 実際には問題あり
デフォルト要件だけでは「問題なし」と判定された設計書が、カスタム要件を追加することで3件の違反が検出された。しかも、カスタム要件の追加によってマネージド要件の判定まで変化した（Audit Logging が Compliant → Non-compliant）。
これは、セキュリティレビューの品質は「チェックリストの質」に大きく依存するという当然の事実を、データで示している。
注意点とベストプラクティス
注意点
- AWS Security Agent はプレビュー段階である。 利用可能リージョンは US East (N. Virginia) のみ。プレビュー期間中は無料だが、GA 後の料金体系は未定
- 設計レビューは万能ではない。 AI によるレビューは人間のセキュリティエキスパートによるレビューを補完するものであり、代替するものではない
- 設計書の品質がレビューの質に直結する。 Kiro の Steering Files を適切に設定し、design.md の詳細度を上げることが重要。今回の実践でも、Kiro が CDK コードレベルの設計を生成していたことで、Security Agent がインフラ構成まで評価できた
- Insufficient Data は「問題なし」ではない。 設計書に情報が不足しているという指摘であり、実装段階で問題が顕在化するリスクがある
ベストプラクティス
- まずデフォルト要件でレビューし、次にカスタム要件を追加する。 段階的に精度を上げることで、どの要件がどのような検出に寄与しているかが明確になる
- カスタムセキュリティ要件は具体的に定義する。 「セキュリティに気をつける」ではなく、「すべての API エンドポイントで JWT 認証を必須とする」のように、コンプライアンス条件が検証可能な形で記述する
- レビュー結果の CSV をエクスポートして記録する。 レビュー結果は「Download report」ボタンで CSV 出力できる。設計変更のたびにレビューを再実行し、結果の推移を追跡する
- Kiro へのフィードバックは具体的に。 Security Agent の指摘内容と是正ガイダンスをそのまま Kiro に渡すことで、的確な修正が得られる
まとめ
Kiro の Spec-Driven Development で生成した design.md を AWS Security Agent の Design Security Review にかけることで、設計段階からセキュリティリスクを体系的に洗い出せることを確認した。
| 項目 | 結果 |
|---|---|
| レビュー対象 | Kiro で生成した design.md（30.32 KB） |
| レビュー所要時間 | 約1分 |
| 1回目（デフォルト要件のみ） | Non-compliant 0件 / Insufficient data 4件 / Compliant 4件 |
| 2回目（カスタム要件3件追加） | Non-compliant 3件 / Insufficient data 4件 / Compliant 4件 |
| Kiro へのフィードバック反映 | 7件の指摘すべてを約3分半で design.md に反映 |
| コスト | 無料（プレビュー期間中） |
ワークフローのポイントは以下の3つだ。
- カスタムセキュリティ要件がレビュー精度を大きく左右する。 デフォルト要件だけでは検出できないリスクがあり、組織固有の要件を定義することで Non-compliant が 0件 → 3件に増加した
- Kiro の design.md は Security Agent のレビューに十分な詳細度を持っている。 CDK コード、API 設計、セキュリティ考慮事項が含まれているため、インフラレベルまでの評価が可能
- 指摘結果を Kiro にフィードバックすることで、design.md に自動反映される。 セキュリティ修正が設計書レベルで完結し、実装段階での手戻りを防げる
設計段階でのセキュリティレビューは、実装後の手戻りコストを考えれば最もコストパフォーマンスの高い品質向上策だ。プレビュー期間中に試してみることを勧める。