はじめに
前回の記事ではAWSのSecurityAgentとDevOpsAgentのセットアップについて解説しましたが、この記事ではより実践的な活用方法を解説します。
SecurityAgentによるGitHubのプルリクエスト(PR)のセキュリティレビューや、設計書のレビュー。
DevOpsAgentによるGitHubリポジトリとAWSにデプロイされたリソースに関するAIを使った調査やインシデント分析や予測。
これらを連携させて活用することでAIを使った開発と運用（DevOps）の効率化、さしずめAIOpsを実現できます。
前回の記事
【AWS】AWS Security Agent & DevOps Agent セットアップガイド【FrontierAgents】
前提条件
今回の記事では、Security Agent と DevOps Agent のセットアップ（Agent Space の作成、GitHub 統合、コードレビューの有効化）が完了していることを前提とします。
DevOpsの課題
システム開発と運用を品質を担保しながらより高速に行うためには以下のような課題があります。
- セキュリティレビューが開発速度に追いつかず、リリースのボトルネックになっている
- ペネトレーションテストは年に数回の定期実施で、開発サイクルとは別のタイムラインで動いている
- インシデント対応が属人化していて、再発防止策が次の開発サイクルにフィードバックされない
- 開発フェーズで得られたセキュリティの知見が、運用フェーズに引き継がれない
これらの課題に対して、AWSが提供する2つのフロンティアエージェント「AWS Security Agent」と「AWS DevOps Agent」を組み合わせることで、AIがより自律的にセキュリティレビューとインシデント監視を行う仕組みを構築できます。
本記事では、シンプルな TODO アプリを題材に、この2つのエージェントを組み合わせた構成の全体像を紹介し、具体的なシナリオで構築手順を追っていきます。
2つのフロンティアエージェント
AWS Security Agent
AWS Security Agent は、開発ライフサイクル全体を通じてアプリケーションを保護するフロンティアエージェントです。主に3つの機能を提供します。
設計セキュリティレビュー
コードを書く前の段階で、設計ドキュメントを組織のセキュリティ要件に照らして検証します。セキュリティチームが AWS コンソールで定義した要件（承認済み認可ライブラリ、ロギング標準、データアクセスポリシーなど）に基づいて、設計上の不備を早期に発見します。
コードセキュリティレビュー
GitHub 上のプルリクエスト（PR）を自動的に検知し、組織のセキュリティ要件や一般的な脆弱性（入力バリデーション不足、SQL インジェクションなど）に対して分析します。指摘は GitHub の PR コメントとして直接提供されるため、開発者は普段のワークフローの中でセキュリティフィードバックを受け取れます。
ペネトレーションテスト
オンデマンドで多段階の攻撃シナリオを実行し、自動スキャンツール（DAST/SAST）では発見できない脆弱性を特定します。脆弱性を発見した場合は、影響分析・再現可能な攻撃パス・修正コードを含む PR を GitHub に自動生成します。
AWS DevOps Agent
AWS DevOps Agent は、インシデントの解決と予防を自律的に行うフロンティアエージェントです。
常時稼働の自律型インシデント対応
アラートやサポートチケットが発生した瞬間に調査を開始します。オブザーバビリティツール（Amazon CloudWatch、Datadog、New Relic など）のテレメトリデータ、GitHub リポジトリのコード変更履歴、CI/CD パイプライン（GitHub Actions）のデプロイ履歴を相関分析し、根本原因を特定します。
予防レコメンデーション
過去のインシデントパターンを分析し、以下の領域で改善を提案します。
- オブザーバビリティ: 監視・アラート・ロギングの強化
- インフラ最適化: オートスケーリング・キャパシティチューニング
- デプロイパイプライン強化: テスト・バリデーションの追加（GitHub Actions のワークフロー改善を含む）
アプリケーショントポロジー
リソースとその関係性を自動的にマッピングし、トポロジーグラフとして可視化します。インシデント調査時にアーキテクチャ全体の影響範囲を把握するのに役立ちます。
GitHubを中心とした機能
Security Agent は GitHub の PR を監視・コメント・修正 PR を生成し、DevOps Agent は GitHub リポジトリのコード変更やデプロイ履歴を分析に活用します。
各サービスの連携イメージ
2つのエージェントを組み合わせると、以下のようなセキュリティチェックとインシデント分析構成が構築できます。
ポイントは、GitHub が各サービス連携のハブとして機能していることです。
Security Agent は GitHub 上の PR を通じて開発者とやり取りし、DevOps Agent は GitHub のコード変更・デプロイ履歴を分析に活用します。
題材: TODO アプリの構成
今回のシナリオで使う TODO アプリの構成を紹介します。
AWS 構成（サーバーレス）
[クライアント]
↓ HTTPS
[API Gateway]
↓
[Lambda] ←→ [DynamoDB]
↑
[Cognito] (認証)
[CloudWatch] (監視 → DevOps Agent が参照)
[GitHub Actions] (CI/CD)
- API Gateway + Lambda: TODO の CRUD API
- DynamoDB: TODO データの保存
- Cognito: ユーザー認証（JWT トークン）
- CloudWatch: メトリクス・ログ・アラーム
- GitHub Actions: ステージング・本番環境へのデプロイ（CDK）
※構成図は後述のDevOpsAgentのトポロジーの画面キャプチャをご覧ください
API エンドポイント:
| メソッド | パス | 説明 |
|---|---|---|
| POST | /todos | TODO を作成 |
| GET | /todos | 自分の TODO 一覧を取得 |
| GET | /todos/{id} | TODO の詳細を取得 |
| PUT | /todos/{id} | TODO を更新 |
| DELETE | /todos/{id} | TODO を削除 |
シンプルな構成ですが、Security Agent の指摘を引き出すために、意図的にいくつかの脆弱性を含めた状態で開発を進めます。
具体的なシナリオで追うサービス連携手順
Step 1: 設計レビュー（Security Agent × AWS コンソール）
TODO アプリの設計ドキュメントを作成し、Security Agent にアップロードします。設計ドキュメントには以下を記載します。
- API エンドポイントの設計
- 認証・認可フロー（Cognito + JWT）
- データモデル（DynamoDB テーブル設計）
- エラーハンドリング方針
↓ウェブアプリで開始を選択
Security Agent が設計ドキュメントを組織のセキュリティ要件に照らして検証し、指摘を返します。
しばらく待つとステータスがCompletedになります。
レビュー結果はサマリー表示で緊急度ごとに何件発見されたかを確認できます
各レビュー結果は一覧表示されます
各レビュー結果は詳細を確認できます
レビュー結果はCSVでダウンロード可能
レビュー結果はCSVでダウンロードも可能です。
今回は以下のようなレビュー結果が得られました
| 項目 | 結果 | 指摘内容 |
|---|---|---|
| 認証のベストプラクティス | COMPLIANT（準拠） | Cognito + JWT の認証は適切 |
| 認可のベストプラクティス | NON_COMPLIANT（非準拠） | ユーザーが自分の TODO のみアクセスできるオーナーチェックが設計に記述されていない |
| シークレット保護 | INSUFFICIENT_DATA | Lambda が IAM ロールを使っているか、シークレットの管理・ローテーション方法が不明 |
| デフォルトのセキュリティ設定 | INSUFFICIENT_DATA | DynamoDB 暗号化、API Gateway TLS 強制、Cognito パスワードポリシーなどのデフォルト設定が未記載 |
| ログ保護 | INSUFFICIENT_DATA | 機密データのマスク、ログ保持期間、アクセス制御が未記載 |
| 情報保護 | INSUFFICIENT_DATA | DynamoDB の暗号化、API Gateway の TLS 強制が明記されていない |
| 監査ログ | INSUFFICIENT_DATA | どのイベントをログに記録するか、ログエントリの内容が未定義 |
| テナント分離 | INSUFFICIENT_DATA | マルチテナント構成だがオーナーチェックの記述がない |
| カスタム要件（オーナーチェック） | INSUFFICIENT_DATA | GET/PUT/DELETE /todos/{id} でオーナー検証のロジックが設計に記述されていない |
開発者はこれらの指摘を受けて設計を修正し、実装に進みます。
Step 2: コードレビュー（Security Agent × GitHub PR）
修正した設計に基づいてコードを実装し、GitHub に PR を作成します。ここでは、Security Agent の動きを見るために、意図的にいくつかの脆弱性を含めた状態で PR を出します。
todo-api-security-demo/
├── bin/
│ └── todo-api.ts # CDK エントリポイント
├── lib/
│ └── todo-api-stack.ts # CDK スタック定義
├── lambda/
│ ├── createTodo.ts # 入力バリデーションなし（意図的）
│ ├── getTodos.ts
│ ├── getTodo.ts # 認可チェックなし（意図的）
│ ├── updateTodo.ts # 認可チェック・入力バリデーションなし（意図的）
│ └── deleteTodo.ts # 認可チェックなし（意図的）
├── package.json
├── cdk.json
└── tsconfig.json
PR を作成すると、Security Agent が自動的に検知してコードを分析します。
テスト用に脆弱性を含むコードをプルリクエストします。
SecurityAgentから審査中のメッセージが入ります
SecurityAgentの審査完了後、レビュー結果が返されます
Security Agent の指摘は「何が問題か」「なぜ重要か」「どう修正すべきか」の3点が明確で、開発者がすぐにアクションを取れる内容になっています。
問題は何ですか? catch ブロックは、とを両方(error as Error).messageとも(error as Error).stackHTTP 500 レスポンスボディにシリアル化します。Lambda 環境では、.stack内部ファイルパス (例: /var/task/lambda/createTodo.js:NN)、DynamoDB テーブル名、および AWS SDK コールチェーンが公開されます。
なぜこれが重要なのでしょうか？スタックトレースやエラーメッセージが漏洩すると、攻撃者は内部実装の詳細、テーブル名、コード構造などを正確に把握でき、標的型攻撃に必要な労力を直接的に削減できるからです。
推奨事項は何ですか? catch ブロックのレスポンスボディをハードコードされた静的文字列のみに置き換えますbody: JSON.stringify({ message: 'Internal server error' })。完全なエラーを CloudWatch にのみログ記録しますconsole.error(error)。
以下は今回発見された問題の一部です
- 情報漏洩（スタックトレース)
- オーナーチェック欠落（IDOR）
- XSS（クロスサイトスクリプティング）
開発者は GitHub 上で指摘を確認し、修正をコミットします。Security Agent が再チェックして問題がなければ、PR をマージします。
Step 3: インシデント監視（DevOps Agent × 本番環境）
コードレビューの指摘を修正してマージ・デプロイした後、DevOps Agent がアプリケーショントポロジーを更新します。TODO アプリの場合、API Gateway → Lambda → DynamoDB の依存関係がトポロジーとして可視化されます。
DevOps Agent は以下のデータを相関分析し、デプロイの影響を監視します:
- CloudWatch のメトリクス（Lambda のエラーレート、API Gateway の 5xx レート、DynamoDB のスロットリング）
- CloudWatch Logs（Lambda の実行ログ）
- GitHub リポジトリのコード変更差分
- GitHub Actions のデプロイ履歴
ここで、DevOps Agent のインシデント調査の動きを見るために、意図的にバグを含むコードをデプロイしてエラーを発生させます。Lambda ハンドラーにランタイムエラーを引き起こすバグを仕込み、API にリクエストを送ると 500 エラーが返る状態にします。CloudWatch アラーム（Lambda エラーレートの閾値超過）がトリガーされると、DevOps Agent が自動的に調査を開始します。
CloudWatchアラームが発生したことを確認
DevOpsAgentで最近のアラームを調査
アラーム調査が開始される
ダッシュボードでは調査のステータスが確認できる
調査完了後、「調査タイムライン」ではどのような調査が行われたのかと根本的な原因が表示されます。
DevOps Agent は GitHub の PR 履歴、コード変更差分、CloudWatch のエラーログを相関分析し、根本原因を正確に特定してくれました。
「根本原因」タブでは根本原因と影響範囲などの説明が確認できます
根本原因のタブに表示されている「Generate mitigation plan」ボタンを押すと緩和計画が作られました。
緩和申請では具体的な解決のためのアクションが説明されています
緩和計画の要約:
- PR #4 をリバートする新しい PR を作成し、PR #3 のセキュリティ修正を再適用して CDK で再デプロイすることを推奨
- エージェント対応仕様として以下の要件変更を提示:
-
getTodo.tsに todoId パラメータの入力バリデーションを実装 - 全 Lambda ハンドラーにセキュアなエラーハンドリングを実装（スタックトレースをレスポンスに含めない）
-
getTodo.tsにユーザー所有権チェックを実装
-
検知されたインシデントと対応方法はGitHubにIssueに登録
DevOpsAgentによりインシデントと対応方法の情報がまとめられているため、その内容をGitHubのIssueへ登録するのも負担が減ります。
登録されたIssueをKiroなどで対応してSecurityAgentでレビューし、デプロイした結果、再度DevOpsAgentで監視するようなサイクルが構築できます。
補足: MCP サーバーによる DevOps Agent の拡張
DevOps Agent は MCP（Model Context Protocol）に対応しており、Agent Space に MCP サーバーを追加することで機能を拡張できます。例えば、GitHub MCP サーバーをホスティングして接続すれば、調査結果を基に GitHub Issue を自動作成することも可能です。ただし、現時点ではホスティング済みのエンドポイント URL は提供されていないため、自前で MCP サーバーをホストする必要があります。
Step 4: 予防レコメンデーション（DevOps Agent）
DevOps Agent がアプリケーションの構成と過去のインシデントパターンを分析し、予防レコメンデーションを提示します。
ウェブアプリの左メニューから「予防」を選択
「今すぐ実行」を選択
しばらく待つと結果が表示されます
↓記載内容要約
カテゴリ: Governance
推奨事項: 「GitHub Actions による CI/CD 自動化と包括的品質ゲートを実装し、コードリグレッションの本番到達を防止」
背景: 入力バリデーション不在のコードが品質ゲートなしで本番デプロイされ、GetTodoFunction の全リクエストが 100% 失敗したインシデントに対応
具体的な提案: PR マージ時に自動テスト、コードカバレッジ検証（85%以上）、TypeScript 型チェック、ESLint 静的解析を実行し、全チェック合格後のみ CDK デプロイを許可する仕組みを構築
Step 3 のインシデント調査で特定された根本原因（セキュリティ修正のリバートが品質ゲートなしで本番に到達した）に対して、再発を防止するための具体的なアクションが提示されています。
Step 5: 次の開発サイクルへの反映
DevOps Agent の調査結果・緩和計画・予防レコメンデーションを受けて、次の開発サイクルに反映します。ここでは、Step 3 で DevOps Agent が提示した要件を Security Agent のカスタムセキュリティ要件に追加し、次回以降のコードレビューで自動的に検証されるようにします。
今回は Step 3 の緩和計画で指摘された「エラーレスポンスのセキュアなハンドリング」を新たに追加します。また、Step 4 の予防レコメンデーションで提示された「GitHub Actions による CI/CD 品質ゲート」は、開発チームのタスクとして別途対応します。
Security Agentのカスタム要件を追加
↓以下のような設定を行い、「セキュリティ要件の作成と有効化」を行いました
| 項目 | 内容 |
|---|---|
| セキュリティ要件名 | エラーレスポンスのセキュアなハンドリング |
| 説明 | Lambda ハンドラーのエラーレスポンスに内部実装の詳細（スタックトレース、エラーメッセージ、ファイルパス）を含めない |
| 適用性 | API エンドポイントを処理するすべての Lambda ハンドラーに適用する。特に catch ブロックでエラーレスポンスを返す箇所が対象 |
| コンプライアンス条件 | 遵守: catch ブロックでエラーを捕捉した場合、レスポンスには汎用的なエラーメッセージ（例: "Internal server error"）のみを返し、詳細なエラー情報は console.error で CloudWatch Logs にのみ記録すること。違反: catch ブロックで (error as Error).message や (error as Error).stack をレスポンスボディに含める実装 |
| 是正ガイダンス | catch ブロックのレスポンスを JSON.stringify({ message: "Internal server error" }) に置き換え、console.error("Error:", error) でログに記録してください |
この要件を追加することで、次回の開発サイクルで開発者がスタックトレースをレスポンスに含めるコードを PR に出した場合、Security Agent が組織要件違反として自動的に検出してくれます。
これで一通りの連携が完了です。
- Step 1〜2: Security Agent が設計・コードの脆弱性を検出
- Step 3: DevOps Agent がインシデントを調査し、根本原因と緩和計画を提示
- Step 4: DevOps Agent が予防レコメンデーションを提示（CI/CD 品質ゲートの導入）
- Step 5: 緩和計画・予防レコメンデーションの内容を Security Agent の組織要件や開発タスクに反映
次の開発サイクルでは、今回追加した組織要件が反映された状態で Security Agent がレビューを行うため、同じ種類の問題は設計・コードの段階で検出されるようになります。
補足: 自動修正で対応しきれない場合の Kiro IDE の活用
サービス連携の中で、Security Agent が自動生成する修正 PR で対応できるケースは多いですが、すべてがカバーされるわけではありません。
例えば Step 4 の「CI/CD 品質ゲートの導入」のような、アーキテクチャレベルの変更が必要なレコメンデーションは、開発者が自分で実装する必要があります。こうしたケースでは、Kiro IDE が開発者を補完します。
- Kiro のチャットで「GitHub Actions に品質ゲートを追加したい」と相談しながら実装を進める
- Steering ファイル（
.kiro/steering/）にチームのコーディング規約やアーキテクチャパターンを定義しておけば、規約に沿ったコードを生成できる
連携の主役はあくまで Security Agent × DevOps Agent ですが、「人間が考えて実装する必要がある修正」では Kiro が頼れる相棒になります。
導入のポイント
段階的な導入アプローチ
いきなりサービス連携構成を構築する必要はありません。以下のステップで段階的に導入できます。
Step 1: Security Agent のコードレビューから始める
GitHub リポジトリを接続するだけで開始できるため、最も導入障壁が低いです。まずは既存のリポジトリに対してコードレビューを有効にし、どのような指摘が出るかを確認してみてください。
Step 2: ペネトレーションテストを追加
コードレビューで効果を実感したら、ペネトレーションテストを追加します。ステージング環境に対して実行し、自動スキャンツールでは見つけられない脆弱性を発見できるか試してみてください。
Step 3: DevOps Agent を運用環境に導入
オブザーバビリティツール（CloudWatch）と GitHub リポジトリを DevOps Agent に接続し、インシデント調査と予防レコメンデーションを有効にします。
Step 4: サービス間連携構成
DevOps Agent の予防レコメンデーションを Security Agent の組織要件に反映する運用フローを確立します。これで連携が完成します。
考慮事項
- 組織のセキュリティ要件の定義が品質を左右する: Security Agent は定義された要件に基づいてレビューを行うため、要件が曖昧だとレビューの精度も下がります。最初は小さく始めて、徐々に要件を充実させていくのがおすすめです
- GitHub リポジトリの権限設定: Security Agent がどのリポジトリにアクセスできるかを適切に設定する必要があります
- GitHub Actions パイプラインとの統合: ペネトレーションテストの実行タイミングをデプロイパイプラインのどこに組み込むかを検討してください
- チーム間の役割分担: 組織要件の定義はセキュリティチーム、コードレビューへの対応は開発チーム、予防レコメンデーションの評価は運用チームが担当するなど、役割を明確にしておくとスムーズです
さいごに
AWS Security Agent と DevOps Agent を組み合わせることで、「設計 → コードレビュー → デプロイ → インシデント監視 → 予防 → 次の開発サイクル」という連携構成を構築できます。
今回はシンプルな TODO アプリで検証しました。Security Agent は設計レビューで認可チェックの欠落を NON_COMPLIANT として検出し、コードレビューでは IDOR・スタックトレース漏洩・XSS をコード行レベルで指摘しました。DevOps Agent はインシデント発生時に GitHub の PR 履歴とコード変更を相関分析して根本原因を正確に特定し、緩和計画と予防レコメンデーション（CI/CD 品質ゲートの導入）を提示しました。
この連携により以下のようなことが実現できます
- GitHub を中心としたフロー: 開発者は普段の GitHub ワークフローから離れることなく、セキュリティフィードバックを受け取れる
- 人がボトルネックにならない: セキュリティレビューもインシデント調査もAIエージェントが自律的に実行する
- フィードバック連携構成が閉じている: DevOpsAgentの調査結果・予防レコメンデーションがSecurityAgentの組織要件に反映され、次の開発サイクルで自動的に検証される
まずはSecurityAgentによるGitHubのPRレビューから始めてみてください。GitHub リポジトリを接続するだけで、DevOps加速の第一歩を踏み出せます。
セットアップ手順は以下の記事で解説しています。
英語版記事
英語版記事はこちら
[AWS] Achieving AIOps with Frontier Agents [Frontier Agent]