AWS開発におけるAIを活用した検証強化

課題

運用や開発をしていると、なぜもっと早いタイミングでこの問題に気づけなかったのかと苦労することはないでしょうか？
例えば、コンパイルエラーにはならずとも、特定の条件下ではエラーが発生し得る、障害につながる原因になり得るなどなど。

また、最近ではAIを使用したコードレビューは当たり前になってきていると思いますが、正しくAIを選択し、使用できているでしょうか？
正直私は特性までを理解して使用できていません。。

そこで今回は以下を目的とした検証を行いました。

• AIを用いて障害や問題の検知を楽にすること
• 適切なAIを選択すること

やったこと

• 簡単なシステムをCDKで構築
  • 「CloudWatch（サブスクリプションフィルター）→Lambda→SNS」のシンプルな構成
• AIのレビューで使用するプロンプトを作成
• CDK資材とプロンプトを基に複数のAIにレビュー
  • 今回は以下3つのAIエージェントを使用
    • Kiro
    • Amazon Q
    • Copilot
• 出力結果の確認と比較

システムの構築

「CloudWatch（サブスクリプションフィルター）→Lambda→SNS」のシンプルな構成
サブスクリプションフィルターでLambdaをトリガーし、文言を整形後SNSにてUserへ通知を飛ばす想定

プロンプトの作成

障害や問題を検知することを目的としたプロンプトを作成しました。
（↓こんな感じ）

# AWS CDK 設計・実装レビュー依頼プロンプト

## あなたの役割

あなたは **AWSアーキテクト / SRE / セキュリティエンジニアの視点を併せ持つ専門家AI** です。  

以下に提示する AWS CDK（Cloud Development Kit）資材一式を読み込み、  

**設計・実装・運用・セキュリティ・コスト・可用性** の観点から、  

障害や問題が発生し得る点を網羅的かつ批判的にレビューしてください。

---

## 対象物

- AWS CDK のソースコード（TypeScript / Python / 他）

- Stack 定義

- Construct 設計

- IAM ポリシー

- ネットワーク構成（VPC, Subnet, SG, NACL 等）

- マネージドサービス設定（ALB, ECS, EKS, Lambda, RDS, S3, etc）

- 環境分離（dev / stg / prod）

- パラメータ、Context、環境変数

---

## レビューの目的

以下を満たすか確認してください。

- 本番障害につながる設計・実装ミスがないか

- セキュリティ事故を引き起こす可能性がないか

- 将来的なスケールや運用で問題が顕在化しないか

- AWS ベストプラクティスや Well-Architected Framework に反していないか

- CDK 特有のアンチパターンが含まれていないか

---

## 必須レビュー観点

最低限、以下の観点を必ず含めてください。

### 1. 可用性・耐障害性

- Single AZ 構成になっていないか

- 冗長化不足、フェイルオーバー不能な設計

- Auto Scaling 設定の妥当性

### 2. セキュリティ

- IAM ポリシーの過剰権限

- パブリックアクセスの不要な公開

- シークレット管理の不備

- ログ・監査証跡不足

### 3. 運用・保守性

- ログ、メトリクス、アラート不足

- 障害調査が困難になる構成

- 環境差分による事故リスク

### 4. コスト

- 無駄に高コストになり得る構成

- 開発・検証環境での過剰スペック

- 常時起動リソースの妥当性

### 5. CDK設計観点

- Stack / Construct の責務分離

- ハードコード値の多用

- Context / Parameter Store / Secrets Manager の使い分け

- 将来の拡張性

---

## 出力フォーマット（厳守）

検出した **問題点ごと** に、必ず以下の形式で出力してください。

### 問題点 X

- **概要**  

  （何が問題かを簡潔に）

- **根拠**  

  （どのコード・設定・設計思想が原因か。AWSベストプラクティスや一般的知見に基づいて説明）

- **想定される影響**  

  （障害内容、セキュリティリスク、運用負荷、コスト増など）

- **修正方針・改善案**  

  （設計レベル・CDK修正例・AWSサービス選定含む。可能であれば具体的な対応）

---

## 重要な指示

- 問題が「起き得る可能性が低い」場合でも、**本番システムとして無視できないものは必ず指摘**してください

- 推測の場合は「推測である」ことを明示してください

- 問題が見つからない場合でも「現状問題なし」とせず、**将来リスク・改善余地**を必ず提示してください

---

## 出力方法

- レビュー結果は **Markdown形式** でまとめてください

- 最終出力は以下のファイルとして保存する前提で記述してください  

以下は必須項目としました。
・問題点
・問題としたその根拠
・想定される影響
・修正案

単純なAIによるコードレビューやAWS Fault Injection Simulator（FIS）との比較
・単純なAIレビュー：構文・ロジックの誤り、可読性・保守性がメイン
・FIS：構築後に検証、事前設計が必要
⇒今回はAWS構成・設計・運用をメインに壊れたらどうなるかまでレビューできる

出力結果の確認

Copilot

• 検知した問題数：17
• 修正内容について細かく具体的なコードがありわかりやすい
• しかもコピペできる形で修正がしやすかった
• 優先度で分類までしてくれており、サマリも出力してくれていた
• チェック観点が少し過剰な気もした

Amazon Q

• 検知した問題数：6
• 指摘内容については適切であるが、修正方針が曖昧
• 具体的なコード等がなくわかりづらった
• 既存コードの把握に強い想定であったが、他AIと比較すると出力が弱く感じた

Kiro（Vibeモード）

• 検知した問題数：10
• Copilotと同じく修正案の具体的なコードと、優先度の分類がされていてよかった
• Kiroは仕様書作成などに強く、SpecモードもあるのでKiroの機能としてはこれだけではないこと留意したい

まとめ

• AIを活用してより障害や問題の検知を楽にすることができました。
  • 今後はGitHub Acitonsなどに取り込んで自動化なども行ってみたいです。
• 検証を通してユースケースに応じたAIの利用がより効果を高めると感じました。
  • 今回触れられなかったAIも多々ありますので、今後はそれらについても検証をしていきたいです。
  • また、使用するエンジンやコストなどの観点には今回触れられなかったので是非皆さんも調べてみてください。