👻
KiroとQで仕様書駆動開発！欲しいものを手に入れろ！！StreamlitをFargateでホストする！！！

2025/11/03に公開
こんにちは。AWS AmbassadorのTsumitaです。

いきなりですが、皆さんはKiroをお使いですか？
KiroはVS Codeをフォークして作られたAI IDEです。仕様書(Spec)駆動開発やVibe Codingをすることができます。

本記事はKiroとAmazon Q Developerを組み合わせて効率的に開発しよう！という記事です。
Kiroだけで欲しいものを手に入れた際の記録はKiroで仕様書駆動開発！！欲しいものを手に入れろ！！StreamlitをFargateでホストする！！！をご確認ください。
Kiroは記事を記載した2025/11/03時点ではPreviewですが、2025年中にはGAされると信じています。

 いきなりまとめKiroで「要件定義・設計・実装計画」までを行い、Amazon Q Developerで「実装」を行う”分業”することで効率が爆上がりする。
Kiro単体で実装を行うと1~2時間程度かかったが、Amazon Q Developerであれば30分程度で実装できた。
Kiroかわいい。この世に存在しないものはKiroとAmazon Q Developerで作ってみよう。

 モチベーションKiroさんは仕様書を定義してくれるところはとても良いのですが、実装スピードや正確性がいまいちという問題があります。その問題を低減するために、KiroとAmazon Q Developerを組み合わせることで爆速で開発したい！！というのが今回のモチベーションです。

 本題ここからは実際にKiroとAmazon Q Developerを使って欲しいものを作っていきましょう。

Amazon Q DeveloperはCLIとしても利用できますが、今回はVS Codeのプラグインを利用していきます。

 前提Kiroがインストール済みであること
Kiroにログイン済みであること
Amazon Q Developerがインストール済みであること
Amazon Q Developerにログイン済みであること

uvがインストール済みであること
適切なIAM 権限を持っていること

 1. Amazon Q DevloperにMCPサーバを設定するまずはMCPサーバを設定しましょう。今回はAWS公式が提供している3つのMCPサーバを利用します。最新のLLMであっても、知識カットオフ以降の情報は持っていないため、MCPサーバを活用するなどして最新の情報を取得しましょう。

※うまく設定できない場合はuvxコマンドをフルパスで記載したらうまくいくかもしれません。
{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": [
        "awslabs.aws-documentation-mcp-server@latest"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": [
      ]
    },
    "awslabs.terraform-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.terraform-mcp-server@latest"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": [
      ]
    },
    "awslabs.aws-api-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.aws-api-mcp-server@latest"
      ],
      "env": {
        "AWS_REGION": "us-east-1"
      },
      "disabled": false,
      "autoApprove": [
      ]
    }
  }
}
今回は.amazonq/mcp.jsonに設定を記載することでプロジェクトをスコープとしてMCPサーバを設定しました。ユーザ全体で有効にしたい場合は~/.aws/amazonq/mcp.jsonに同様の設定を行いましょう。赤矢印のアイコンを押下することで設定されているMCPサーバを確認することができます。

 2. モデルを選択しよう基本的に最新のモデルを選択すれば良いと思います。今回はClaude Sonnet 4.5を選択します。

本操作時にモデルの左側のボタンで"Agentic Code"を有効化しましょう。Amazon Q DeveloperがAgenticに動いてくれます。

 3. Let's 開発Kiroで仕様書駆動開発！！欲しいものを手に入れろ！！StreamlitをFargateでホストする！！！で作成された.mdファイルを利用してAmazon Q Developerで開発してきましょう。
requirements.md
 Requirements Document
 Introductionこのプロジェクトは、生成AIを組み込んだStreamlitアプリケーションをAWS上にHTTPS対応でデプロイするためのインフラストラクチャを構築します。Terraformを使用してIaCとして管理し、ECS Fargateを活用した高可用性とセキュリティを確保したアーキテクチャを実現します。また、コード品質を保証するためのLinter、Formatter、静的解析ツールも統合します。

 Requirements
 Requirement 1: HTTPS通信対応User Story: インフラ管理者として、StreamlitアプリケーションがHTTPS経由で安全にアクセスできるようにしたい。これにより、ユーザーデータの暗号化と通信の安全性を確保できる。

 Acceptance CriteriaWHEN ユーザーがアプリケーションにアクセスする THEN システムはCloudFrontを使用してHTTPS（ポート443）経由で通信を提供しなければならない
WHEN HTTPリクエストを受信した THEN システムは自動的にHTTPSにリダイレクトしなければならない
WHEN SSL/TLS証明書が必要な THEN システムはCloudFrontのデフォルトドメイン（*.cloudfront.net）が持つ証明書を使用しなければならない
WHEN CloudFrontディストリビューションを作成する THEN システムはALBをオリジンとして設定しなければならない

 Requirement 2: ECS Fargateによる高可用性デプロイメントUser Story: 開発者として、Streamlitアプリケーションが高可用性を持ち、スケーラブルな環境で動作するようにしたい。これにより、トラフィックの変動に対応し、サービスの安定性を確保できる。

 Acceptance CriteriaWHEN アプリケーションをデプロイする THEN システムはap-northeast-1（東京リージョン）のECS Fargateを使用してコンテナを実行しなければならない
WHEN トラフィックが増加した THEN システムは自動的にタスク数をスケールアウトできなければならない
WHEN 複数のアベイラビリティゾーンが利用可能な THEN システムは3つのAZ（ap-northeast-1a、1c、1d）にタスクを分散配置しなければならない
WHEN タスクが異常終了した THEN システムは自動的に新しいタスクを起動しなければならない
WHEN Application Load Balancer（ALB）を使用する THEN システムはヘルスチェックを実施し、異常なタスクへのトラフィックを停止しなければならない

 Requirement 3: Terraformによるインフラ管理User Story: インフラ管理者として、すべてのAWSリソースをTerraformでコード化して管理したい。これにより、インフラの再現性、バージョン管理、変更追跡が可能になる。

 Acceptance CriteriaWHEN インフラをプロビジョニングする THEN システムはTerraformコードを使用してすべてのAWSリソースを作成しなければならない
WHEN Terraformコードを実行する THEN システムはリモートステート管理（S3バックエンド）を使用しなければならない
WHEN リソースを変更する THEN システムはterraform planで変更内容を事前確認できなければならない
WHEN MCPサーバが利用可能な THEN システムはTerraform関連のMCPツールを活用してドキュメント検索や実行を行わなければならない
WHEN Terraformプロバイダーを使用する THEN システムは最新の安定版プロバイダーバージョンを使用しなければならない
WHEN システムデフォルトタグを設定する THEN システムはすべてのリソースに共通のタグを自動的に適用しなければならない

 Requirement 4: セキュリティのベストプラクティスUser Story: セキュリティ担当者として、AWSのセキュリティベストプラクティスに従ったインフラを構築したい。これにより、脆弱性を最小化し、コンプライアンス要件を満たすことができる。

 Acceptance CriteriaWHEN VPCを作成する THEN システムはプライベートサブネットとパブリックサブネットを分離しなければならない
WHEN ECSタスクを実行する THEN システムはプライベートサブネット内でタスクを実行しなければならない
WHEN セキュリティグループを設定する THEN システムは最小権限の原則に従い、必要なポートのみを開放しなければならない
WHEN IAMロールを作成する THEN システムは最小権限の原則に従い、必要な権限のみを付与しなければならない
WHEN シークレット情報を管理する THEN システムはAWS Secrets ManagerまたはSSM Parameter Storeを使用しなければならない
WHEN ログを記録する THEN システムはCloudWatch Logsにアプリケーションログとインフラログを出力しなければならない
WHEN パブリックアクセスが不要なリソースがある THEN システムはそれらをプライベートに保持しなければならない
WHEN Terraformコードをスキャンする THEN システムはCheckovなどの静的解析ツールでセキュリティ問題を検出できなければならない

 Requirement 5: コード品質管理ツールの統合User Story: 開発者として、Terraformコードの品質を自動的にチェックし、一貫性のあるコードスタイルを維持したい。これにより、コードレビューの効率化とバグの早期発見が可能になる。

 Acceptance CriteriaWHEN Terraformコードを作成する THEN システムはterraform fmtでコードフォーマットを実行できなければならない
WHEN Terraformコードを検証する THEN システムはterraform validateで構文チェックを実行できなければならない
WHEN セキュリティスキャンを実行する THEN システムはCheckovの最新版を使用してセキュリティとコンプライアンスの問題を検出しなければならない
WHEN Lintを実行する THEN システムはTFLintの最新版を使用してベストプラクティス違反を検出できなければならない
WHEN ツールをセットアップする THEN システムは各ツールのバージョンをドキュメントに記載しなければならない

 Requirement 6: Streamlitアプリケーションのコンテナ化User Story: 開発者として、StreamlitアプリケーションをDockerコンテナとしてパッケージ化したい。これにより、環境の一貫性と移植性を確保できる。

 Acceptance CriteriaWHEN Dockerイメージをビルドする THEN システムはStreamlitアプリケーションとその依存関係を含むイメージを作成しなければならない
WHEN イメージをプッシュする THEN システムはAmazon ECRにイメージを保存しなければならない
WHEN セキュリティスキャンを実行する THEN システムはECRの脆弱性スキャン機能を有効化しなければならない
WHEN 本番環境にデプロイする THEN システムはマルチステージビルドを使用してイメージサイズを最適化しなければならない

 Requirement 7: モニタリングとロギングUser Story: 運用担当者として、アプリケーションとインフラの状態を監視し、問題を迅速に検出したい。これにより、ダウンタイムを最小化し、ユーザー体験を向上できる。

 Acceptance CriteriaWHEN アプリケーションが実行される THEN システムはCloudWatch Logsにログを出力しなければならない
WHEN メトリクスを収集する THEN システムはCPU使用率、メモリ使用率、リクエスト数などの主要メトリクスをCloudWatchに送信しなければならない
WHEN 異常が検出された THEN システムはCloudWatch Alarmsを使用してアラートを発行できなければならない
WHEN ログを長期保存する THEN システムはログ保持期間を設定できなければならない

 Requirement 8: コスト最適化User Story: インフラ管理者として、不要なコストを削減しながら必要なパフォーマンスを維持したい。これにより、予算内で効率的にサービスを運用できる。

 Acceptance CriteriaWHEN リソースをプロビジョニングする THEN システムは適切なインスタンスサイズ（Fargateタスクサイズ）を選択しなければならない
WHEN トラフィックが少ない THEN システムは最小タスク数を1に設定できなければならない
WHEN NAT Gatewayを使用する THEN システムは単一AZ（ap-northeast-1a）に配置しなければならない

 Requirement 9: ドキュメンテーションUser Story: 新しいチームメンバーとして、インフラの構成と使用方法を理解するための明確なドキュメントが欲しい。これにより、オンボーディングを迅速化し、運用ミスを減らすことができる。

 Acceptance CriteriaWHEN プロジェクトをセットアップする THEN システムはREADMEファイルに前提条件、セットアップ手順、使用方法を記載しなければならない
WHEN Terraformモジュールを作成する THEN システムは各モジュールに説明、入力変数、出力値のドキュメントを含めなければならない
WHEN アーキテクチャを説明する THEN システムは最新のAWSアイコンを使用した.drawio形式のシステム構成図を提供しなければならない
WHEN トラブルシューティングが必要な THEN システムは一般的な問題と解決策を記載したドキュメントを提供しなければならない
design.md
 Design Document
 Overviewこのドキュメントは、StreamlitアプリケーションをAWS上にHTTPS対応でデプロイするためのインフラストラクチャ設計を定義します。ECS Fargateを使用した高可用性アーキテクチャを採用し、CloudFrontによるHTTPS通信、Terraformによる完全なIaC管理、そしてセキュリティベストプラクティスに準拠した構成を実現します。

 主要な設計目標
HTTPS通信: CloudFrontのデフォルトドメイン証明書を使用したHTTPS通信

高可用性: 3つのAZ（ap-northeast-1a、1c、1d）にまたがるECS Fargateタスクの分散配置

セキュリティ: VPC分離、最小権限の原則、プライベートサブネット内でのタスク実行

コスト最適化: 単一AZのNAT Gateway配置

IaC管理: Terraformによる完全なインフラ管理とMCPサーバの活用

コード品質: TFLint、Checkov、terraform fmt/validateによる品質保証

 Architecture
 High-Level Architecture
 Network Flow
ユーザーリクエスト: ユーザーはCloudFrontのHTTPSエンドポイント（*.cloudfront.net）にアクセス

CloudFront → ALB: CloudFrontはALBにリクエストを転送（HTTP/HTTPS）

ALB → ECS Tasks: ALBはヘルスチェックに基づいて正常なFargateタスクにトラフィックを分散

ECS Tasks処理: Streamlitアプリケーションがリクエストを処理

外部通信: ECSタスクは必要に応じてNAT Gateway経由でインターネットにアクセス

 Region and Availability Zones
Region: ap-northeast-1（東京リージョン）

Availability Zones:
ap-northeast-1a（NAT Gateway配置）
ap-northeast-1c
ap-northeast-1d


 Components and Interfaces
 1. Networking Layer
 VPC (Virtual Private Cloud)
CIDR Block: 10.0.0.0/16

DNS Support: 有効

DNS Hostnames: 有効

 SubnetsPublic Subnets (3つのAZ)
ap-northeast-1a: 10.0.1.0/24
ap-northeast-1c: 10.0.2.0/24
ap-northeast-1d: 10.0.3.0/24
用途: ALB、NAT Gateway
Private Subnets (3つのAZ)
ap-northeast-1a: 10.0.11.0/24
ap-northeast-1c: 10.0.12.0/24
ap-northeast-1d: 10.0.13.0/24
用途: ECS Fargateタスク

 Internet GatewayVPCにアタッチ
Public Subnetsからのインターネットアクセスを提供

 NAT Gateway
配置: ap-northeast-1aのPublic Subnet

Elastic IP: 1つ割り当て

用途: Private Subnets内のECSタスクからのアウトバウンド通信

 Route TablesPublic Route Table
0.0.0.0/0 → Internet Gateway
関連付け: すべてのPublic Subnets
Private Route Tables (3つ)
0.0.0.0/0 → NAT Gateway (ap-northeast-1a)
関連付け: 各Private Subnet

 2. Security Groups
 ALB Security Group
Inbound Rules:
Port 443 (HTTPS): 0.0.0.0/0 (CloudFrontからのアクセス用)


Outbound Rules:
All traffic: ECS Security Groupへ


 ECS Security Group
Inbound Rules:
Port 8501 (Streamlit): ALB Security Groupから


Outbound Rules:
Port 443: 0.0.0.0/0 (AWS APIs、ECR用)


 3. CloudFront Distribution
 Configuration
Origin: Application Load Balancer

Origin Protocol Policy: HTTP or HTTPS (設定可能)

Viewer Protocol Policy: redirect-to-https

Allowed HTTP Methods: GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE

Cached HTTP Methods: GET, HEAD, OPTIONS

Cache Policy: CachingDisabled (Streamlitの動的コンテンツ用)

Origin Request Policy: AllViewer (すべてのヘッダー、クエリ文字列、Cookieを転送)

Price Class: PriceClass_200 (北米、ヨーロッパ、アジア、中東、アフリカ)

SSL Certificate: CloudFrontデフォルト証明書（*.cloudfront.net）

Minimum Protocol Version: TLSv1.2_2021

 Custom HeadersX-Custom-Header: CloudFrontからのリクエストを識別するためのカスタムヘッダー（オプション）

 4. Application Load Balancer (ALB)
 Configuration
Scheme: internet-facing

IP Address Type: ipv4

Subnets: すべてのPublic Subnets（3つのAZ）

Security Group: ALB Security Group

Deletion Protection: 有効（本番環境）

Access Logs: S3バケットに保存（オプション）

 Target Group
Target Type: ip

Protocol: HTTP

Port: 8501

VPC: メインVPC

Health Check:
Protocol: HTTP
Path: /
Interval: 30秒
Timeout: 5秒
Healthy Threshold: 2
Unhealthy Threshold: 3
Matcher: 200-299


Deregistration Delay: 30秒

 Listeners
HTTPS Listener (Port 443):
Action: Forward to Target Group
SSL Certificate: ACM証明書（カスタムドメイン使用時、またはセルフ署名証明書）


 5. ECS Cluster and Fargate
 ECS Cluster
Name: streamlit-app-cluster

Container Insights: 有効

Capacity Providers: FARGATE, FARGATE_SPOT（オプション）

 Task Definition
Launch Type: FARGATE

Network Mode: awsvpc

Requires Compatibilities: FARGATE

CPU: 512 (.5 vCPU) または 1024 (1 vCPU)

Memory: 1024 MB (1 GB) または 2048 MB (2 GB)

Task Role: ECSタスクロール（アプリケーション権限用）

Execution Role: ECSタスク実行ロール（ECR、CloudWatch Logs、Secrets Manager用）

Platform Version: LATEST (1.4.0以降、エフェメラルストレージ暗号化対応)

 Container Definition{
  "name": "streamlit-app",
  "image": "${ECR_REPOSITORY_URL}:latest",
  "cpu": 512,
  "memory": 1024,
  "essential": true,
  "portMappings": [
    {
      "containerPort": 8501,
      "protocol": "tcp"
    }
  ],
  "environment": [
    {
      "name": "STREAMLIT_SERVER_PORT",
      "value": "8501"
    },
    {
      "name": "STREAMLIT_SERVER_ADDRESS",
      "value": "0.0.0.0"
    }
  ],
  "logConfiguration": {
    "logDriver": "awslogs",
    "options": {
      "awslogs-group": "/ecs/streamlit-app",
      "awslogs-region": "ap-northeast-1",
      "awslogs-stream-prefix": "ecs"
    }
  }
}

 ECS Service
Launch Type: FARGATE

Platform Version: LATEST

Desired Count: 2（最小）

Deployment Configuration:
Maximum Percent: 200
Minimum Healthy Percent: 100
Deployment Circuit Breaker: 有効（ロールバック有効）


Network Configuration:
Subnets: すべてのPrivate Subnets（3つのAZ）
Security Groups: ECS Security Group
Assign Public IP: 無効


Load Balancer:
Target Group: ALB Target Group
Container Name: streamlit-app
Container Port: 8501


Service Discovery: 無効（ALB経由のアクセスのみ）

Auto Scaling:
Minimum Tasks: 1
Maximum Tasks: 10
Target Tracking Scaling Policy:
Metric: ECSServiceAverageCPUUtilization
Target Value: 70%
Scale-in Cooldown: 300秒
Scale-out Cooldown: 60秒



 6. Container Registry (ECR)
 ECR Repository
Name: streamlit-app

Image Tag Mutability: IMMUTABLE

Image Scanning: 有効（プッシュ時にスキャン）

Encryption: AES-256（デフォルト）またはKMS

Lifecycle Policy:
最新10イメージを保持
untaggedイメージは1日後に削除


 7. IAM Roles and Policies
 ECS Task Execution Role
Purpose: ECSエージェントがAWSサービスを呼び出すための権限

Managed Policies:
AmazonECSTaskExecutionRolePolicy


Custom Policies:
ECRからのイメージプル
CloudWatch Logsへのログ書き込み

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetAuthorizationToken",
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:ap-northeast-1:*:log-group:/ecs/streamlit-app:*"
    }
  ]
}

 ECS Task Role
Purpose: コンテナ内のアプリケーションがAWSサービスにアクセスするための権限

Custom Policies: アプリケーション要件に応じて設定
S3バケットへのアクセス（必要に応じて）
DynamoDBテーブルへのアクセス（必要に応じて）
Bedrockなど生成AIサービスへのアクセス

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "arn:aws:bedrock:ap-northeast-1::foundation-model/*"
    }
  ]
}

 8. Monitoring and Logging
 CloudWatch Logs
Log Groups:
/ecs/streamlit-app: アプリケーションログ
/aws/ecs/containerinsights/{cluster-name}/performance: Container Insights


Retention Period: 30日（設定可能）

Encryption: KMS暗号化（オプション）

 CloudWatch Metrics
ECS Metrics:
CPUUtilization
MemoryUtilization
RunningTaskCount


ALB Metrics:
TargetResponseTime
RequestCount
HealthyHostCount
UnHealthyHostCount
HTTPCode_Target_2XX_Count
HTTPCode_Target_4XX_Count
HTTPCode_Target_5XX_Count


CloudFront Metrics:
Requests
BytesDownloaded
BytesUploaded
4xxErrorRate
5xxErrorRate


 Data Models
 Terraform State Management
 Backend Configuration
Storage: ローカルファイルシステム

Location: terraform.tfstate（プロジェクトルート）

Version Control: .gitignoreに追加（状態ファイルはコミットしない）

Backup: 手動バックアップ推奨

 Terraform Variables
 Required Variablesvariable "project_name" {
  description = "Project name used for resource naming"
  type        = string
  default     = "streamlit-app"
}

variable "region" {
  description = "AWS region"
  type        = string
  default     = "ap-northeast-1"
}

variable "vpc_cidr" {
  description = "CIDR block for VPC"
  type        = string
  default     = "10.0.0.0/16"
}

variable "availability_zones" {
  description = "List of availability zones"
  type        = list(string)
  default     = ["ap-northeast-1a", "ap-northeast-1c", "ap-northeast-1d"]
}

variable "container_image" {
  description = "Container image URL"
  type        = string
}

variable "container_cpu" {
  description = "Container CPU units"
  type        = number
  default     = 512
}

variable "container_memory" {
  description = "Container memory in MB"
  type        = number
  default     = 1024
}

variable "ecs_desired_count" {
  description = "Desired number of ECS tasks"
  type        = number
  default     = 2
}

variable "ecs_min_capacity" {
  description = "Minimum number of ECS tasks"
  type        = number
  default     = 1
}

variable "ecs_max_capacity" {
  description = "Maximum number of ECS tasks"
  type        = number
  default     = 10
}

variable "default_tags" {
  description = "Default tags to apply to all resources"
  type        = map(string)
  default = {
    Project     = "streamlit-app"
    ManagedBy   = "Terraform"
    Environment = "production"
  }
}

 Terraform Module Structureterraform/
├── main.tf                 # Main configuration
├── variables.tf            # Variable definitions
├── outputs.tf              # Output values
├── versions.tf             # Provider versions
├── backend.tf              # Backend configuration
├── modules/
│   ├── networking/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   ├── security/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   ├── ecs/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   ├── alb/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   ├── cloudfront/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   └── monitoring/
│       ├── main.tf
│       ├── variables.tf
│       └── outputs.tf
└── examples/
    └── complete/
        ├── main.tf
        └── terraform.tfvars

 Error Handling
 Terraform Error Handling
 Resource Creation Failures
Strategy: 各リソースに適切なdepends_onを設定し、依存関係を明示

Retry Logic: AWS APIのレート制限エラーに対する自動リトライ

Validation: terraform validateによる構文チェック

Plan Review: terraform planによる変更内容の事前確認

 State Management Errors
State Lock: DynamoDBによる状態ロック機能

State Backup: S3バージョニングによる状態ファイルのバックアップ

State Recovery: 状態ファイルの破損時の復旧手順をドキュメント化

 Application Error Handling
 ECS Task Failures
Health Check: ALBヘルスチェックによる異常タスクの検出

Auto Recovery: ECS Serviceによる自動タスク再起動

Circuit Breaker: デプロイメント失敗時の自動ロールバック

Logging: CloudWatch Logsへのエラーログ出力

 ALB Error Responses
5xx Errors: バックエンドエラー時のカスタムエラーページ（オプション）

4xx Errors: クライアントエラー時の適切なレスポンス

Timeout: 60秒のタイムアウト設定

 CloudFront Error Handling
Origin Errors: オリジンエラー時のカスタムエラーページ設定

Cache Behavior: エラーレスポンスのキャッシュ制御

Failover: オリジングループによるフェイルオーバー（オプション）

 Security Error Handling
 IAM Permission Errors
Least Privilege: 最小権限の原則に基づく権限設定

Policy Validation: IAM Policy Simulatorによる権限検証

Error Logging: CloudTrailによるAPI呼び出しの監査ログ

 Network Errors
Security Group: 適切なインバウンド/アウトバウンドルール

Network ACL: サブネットレベルのトラフィック制御（オプション）

VPC Flow Logs: ネットワークトラフィックの監視

 Testing Strategy
 Infrastructure Testing
 Terraform Validation# フォーマットチェック
terraform fmt -check -recursive

# 構文検証
terraform validate

# セキュリティスキャン（Checkov）
checkov -d . --framework terraform

# Lintチェック（TFLint）
tflint --recursive

 Pre-deployment Testing
Plan Review: terraform planの出力を確認

Cost Estimation: Infracostによるコスト見積もり（オプション）

Compliance Check: Checkovによるコンプライアンスチェック

 Post-deployment Testing
Smoke Test: デプロイ後の基本的な動作確認
CloudFront URLへのHTTPSアクセス
Streamlitアプリケーションの起動確認
ヘルスチェックエンドポイントの確認


Load Test: Apache BenchやLocustによる負荷テスト（オプション）

Security Test: AWS Security Hubによるセキュリティ評価

 Application Testing
 Container Testing# ローカルでのコンテナビルド
docker build -t streamlit-app:test .

# ローカルでのコンテナ実行
docker run -p 8501:8501 streamlit-app:test

# コンテナイメージのスキャン
docker scan streamlit-app:test

 Integration Testing
ECS Task: タスク定義の検証とタスク起動テスト

ALB: ターゲットグループへの登録とヘルスチェック

CloudFront: オリジンへの接続テスト

 Code Quality Tools
 Terraform FormatterTool: terraform fmt
Purpose: コードフォーマットの統一
Usage:
terraform fmt -recursive
CI Integration: コミット前の自動フォーマット

 Terraform ValidatorTool: terraform validate
Purpose: 構文エラーの検出
Usage:
terraform init
terraform validate

 TFLintVersion: 最新安定版（v0.50.0以降推奨）
Purpose: Terraformコードのベストプラクティスチェック
Configuration: .tflint.hcl
plugin "aws" {
  enabled = true
  version = "0.30.0"
  source  = "github.com/terraform-linters/tflint-ruleset-aws"
}

rule "aws_resource_missing_tags" {
  enabled = true
  tags = ["Project", "ManagedBy", "Environment"]
}

rule "terraform_naming_convention" {
  enabled = true
}

rule "terraform_deprecated_interpolation" {
  enabled = true
}
Usage:
tflint --init
tflint --recursive

 CheckovVersion: 最新安定版（3.0.0以降推奨）
Purpose: セキュリティとコンプライアンスのスキャン
Severity Handling:
CRITICAL: 修正必須（ビルド失敗）
HIGH: 修正必須（ビルド失敗）
MEDIUM: レポートのみ（警告、修正不要）
LOW: レポートのみ（警告、修正不要）
INFO: レポートのみ（情報、修正不要）
Configuration: .checkov.yaml
framework:
  - terraform

# CRITICALとHIGHのみ失敗とする
check-severity:
  - CRITICAL
  - HIGH

compact: true
quiet: false

output:
  - cli
  - json
Usage:
checkov -d . --framework terraform --check-severity CRITICAL,HIGH --output json --output-file-path checkov-report.json
対応方針:
CRITICAL/HIGHの問題は必ず修正
MEDIUM/LOW/INFOの問題はレポートのみで修正不要
Key Checks:
CKV_AWS_23: Security group ingress rules
CKV_AWS_24: Security group egress rules
CKV_AWS_68: CloudFront distribution encryption
CKV_AWS_158: CloudWatch log group encryption

 Pre-commit HooksTool: pre-commit
Configuration: .pre-commit-config.yaml
repos:
  - repo: https://github.com/antonbabenko/pre-commit-terraform
    rev: v1.88.0
    hooks:
      - id: terraform_fmt
      - id: terraform_validate
      - id: terraform_tflint
      - id: terraform_checkov

 Makefile for Quality Checks.PHONY: fmt validate lint security check all

fmt:
 terraform fmt -recursive

validate:
 terraform init -backend=false
 terraform validate

lint:
 tflint --init
 tflint --recursive

security:
 checkov -d . --framework terraform

check: fmt validate lint security

all: check

 Security Best Practices
 Network Security
 VPC Isolation
Public Subnets: ALBとNAT Gatewayのみ配置

Private Subnets: ECS Fargateタスクを配置、直接インターネットアクセス不可

Network ACLs: デフォルトACLを使用（必要に応じてカスタマイズ）

 Security Groups
最小権限の原則: 必要最小限のポートとソースのみ許可

Egress Rules: 必要なアウトバウンド通信のみ許可

Security Group Chaining: ALB → ECS間でSecurity Group IDを使用した参照

 Network Monitoring
VPC Flow Logs: VPCトラフィックの監視（オプション）

CloudWatch Logs: フローログの保存と分析

GuardDuty: 脅威検出サービスの有効化（推奨）

 IAM Security
 Role-based Access Control
Task Execution Role: インフラストラクチャ操作用

Task Role: アプリケーション操作用

Separation of Concerns: 役割の明確な分離

 Policy Best Practices
Least Privilege: 必要最小限の権限のみ付与

Resource-based Policies: 特定のリソースへのアクセスのみ許可

Condition Keys: 条件付きアクセス制御の活用

 Secrets Management
Environment Variables: 環境変数による設定管理

Task Definition: ECSタスク定義内での環境変数設定

Note: AWS Secrets ManagerやSSM Parameter Storeは使用しない

 Container Security
 Image Security
ECR Image Scanning: プッシュ時の自動脆弱性スキャン

Image Signing: Docker Content Trust（オプション）

Base Image: 最小限の公式ベースイメージ使用

Multi-stage Build: ビルドツールを含まない最終イメージ

 Runtime Security
Read-only Root Filesystem: 可能な限り読み取り専用に設定（オプション）

Non-root User: 非rootユーザーでのコンテナ実行

Resource Limits: CPU/メモリリミットの設定

Fargate Ephemeral Storage Encryption: プラットフォームバージョン1.4.0以降で自動暗号化

 GuardDuty Runtime Monitoring
有効化: Fargate Runtime Monitoringの有効化

脅威検出: ランタイムでの異常動作検出

自動対応: CloudWatch EventsとLambdaによる自動対応（オプション）

 Data Security
 Encryption at Rest
S3: Terraform State、ALBログの暗号化

ECR: コンテナイメージの暗号化

CloudWatch Logs: ログの暗号化（KMS）

 Encryption in Transit
CloudFront: HTTPS通信の強制

ALB: HTTPS Listenerの設定（オプション）

ECS → AWS APIs: TLS 1.2以上での通信

 Compliance and Auditing
 CloudTrail
有効化: すべてのAPI呼び出しの記録

Log Encryption: CloudTrailログの暗号化

Log Integrity: ログファイルの整合性検証

 AWS Config
Resource Tracking: リソース設定変更の追跡

Compliance Rules: コンプライアンスルールの評価

Remediation: 自動修復アクション（オプション）

 Security Hub
有効化: セキュリティ状態の統合ビュー

Standards: CIS AWS Foundations Benchmarkの適用

Findings: セキュリティ問題の集約と優先順位付け

 Deployment Strategy
 Initial DeploymentTerraform State Backend Setup
S3バケットとDynamoDBテーブルの作成
バックエンド設定の初期化
Network Infrastructure
VPC、Subnets、Internet Gateway、NAT Gatewayの作成
Route Tablesの設定
Security Infrastructure
Security Groupsの作成
IAM Rolesとポリシーの作成
Container Registry
ECRリポジトリの作成
初期イメージのプッシュ
Load Balancer
ALBとTarget Groupの作成
Listenersの設定
ECS Cluster and Service
ECS Clusterの作成
Task Definitionの登録
ECS Serviceの作成
CloudFront Distribution
CloudFront Distributionの作成
キャッシュ設定の適用
Monitoring Setup
CloudWatch Log Groupsの作成
CloudWatch Alarmsの設定

 Update Deployment
 Application Updates# 1. 新しいイメージのビルドとプッシュ
docker build -t streamlit-app:v2 .
docker tag streamlit-app:v2 ${ECR_URL}:v2
docker push ${ECR_URL}:v2

# 2. Task Definitionの更新
terraform apply -target=module.ecs.aws_ecs_task_definition.main

# 3. ECS Serviceの更新（新しいタスクのデプロイ）
terraform apply -target=module.ecs.aws_ecs_service.main

 Infrastructure Updates# 1. 変更内容の確認
terraform plan

# 2. 変更の適用
terraform apply

# 3. デプロイメントの監視
aws ecs describe-services --cluster streamlit-app-cluster --services streamlit-app-service

 Rollback Strategy
 Application RollbackECS Service: 以前のTask Definition Revisionへのロールバック
Circuit Breaker: デプロイメント失敗時の自動ロールバック
Manual Rollback:
aws ecs update-service \
  --cluster streamlit-app-cluster \
  --service streamlit-app-service \
  --task-definition streamlit-app:PREVIOUS_REVISION

 Infrastructure Rollback
Terraform State: 以前の状態への復元

Git Revert: Terraformコードの以前のコミットへの復帰

Backup Restore: S3バージョニングからの状態ファイル復元

 Blue/Green Deployment（オプション）
 CodeDeploy Integration
Deployment Controller: CODE_DEPLOYの使用

Target Groups: Blue/Green用の2つのTarget Group

Traffic Shifting: 段階的なトラフィック移行

Automatic Rollback: デプロイメント失敗時の自動ロールバック

 Cost Optimization
 Resource Sizing
 ECS Fargate
Initial Size: 0.5 vCPU、1 GB RAM

Scaling: CPU使用率に基づく自動スケーリング

Minimum Tasks: 1（開発環境）、2（本番環境）

Fargate Spot: 非本番環境でのSpot使用（オプション）

 NAT Gateway
Single AZ: ap-northeast-1aに1つのみ配置

Cost: 約$32/月 + データ転送料金

Alternative: NAT Instanceの検討（コスト削減）

 CloudFront
Price Class: PriceClass_200（北米、ヨーロッパ、アジア）

Cache Strategy: 静的コンテンツのキャッシュ最大化

Compression: Gzip/Brotli圧縮の有効化

 Cost Monitoring
 AWS Cost Explorer
Daily Monitoring: 日次コスト確認

Service Breakdown: サービス別コスト分析

Forecasting: 月次コスト予測

 Cost Allocation Tagsdefault_tags = {
  Project     = "streamlit-app"
  ManagedBy   = "Terraform"
  Environment = "production"
  CostCenter  = "engineering"
}

 Cost Optimization Recommendations
Reserved Capacity: 長期利用の場合、Savings Plansの検討

Auto Scaling: 適切なスケーリングポリシーによるリソース最適化

Log Retention: CloudWatch Logsの保持期間を適切に設定

Unused Resources: 定期的な未使用リソースのクリーンアップ

Right Sizing: CloudWatch Metricsに基づくリソースサイズの最適化

 Documentation Requirements
 README.md
 Content Structure
Project Overview: プロジェクトの目的と概要

Architecture Diagram: システム構成図（.drawio形式）

Prerequisites:
Terraform（最新安定版）
AWS CLI（v2推奨）
Docker
TFLint（最新版）
Checkov（最新版）


Setup Instructions:
AWS認証情報の設定
Terraformバックエンドの初期化
変数ファイルの設定


Deployment Steps:
初回デプロイメント手順
アプリケーション更新手順
ロールバック手順


Verification:
デプロイメント確認方法
ヘルスチェック確認
ログ確認方法


Troubleshooting:
よくある問題と解決策
デバッグ方法


Cost Estimation: 月次コスト見積もり

Maintenance: 定期メンテナンス作業

 Architecture Diagram (.drawio)
 Required Elements
最新のAWSアイコン: AWS Architecture Icons（2023年版以降）

Components:
ユーザー
CloudFront Distribution
Application Load Balancer
ECS Fargate Tasks（3つのAZ）
VPC（Public/Private Subnets）
NAT Gateway
Internet Gateway
ECR
CloudWatch Logs
Secrets Manager


Network Flow: トラフィックフローの矢印

Security Boundaries: VPC、Subnet境界の明示

Availability Zones: 3つのAZの視覚的表現

 Module Documentation
 Each Module Should Include
Purpose: モジュールの目的

Inputs: 入力変数の説明

Outputs: 出力値の説明

Examples: 使用例

Dependencies: 依存関係

Notes: 注意事項

 Operational Runbook
 Content
Deployment Procedures: デプロイメント手順

Monitoring Procedures: 監視手順

Incident Response: インシデント対応手順

Backup and Recovery: バックアップと復旧手順

Scaling Procedures: スケーリング手順

Security Procedures: セキュリティ対応手順

 MCP Server Integration
 Terraform MCP Server Usage
 Documentation Search# AWS Provider ドキュメント検索
mcp_awslabsterraform_mcp_server_SearchAwsProviderDocs \
  --asset_name aws_ecs_service \
  --asset_type resource

 Terraform Execution# Terraform Plan実行
mcp_awslabsterraform_mcp_server_ExecuteTerraformCommand \
  --command plan \
  --working_directory ./terraform \
  --aws_region ap-northeast-1

 Security Scanning# Checkovスキャン実行
mcp_awslabsterraform_mcp_server_RunCheckovScan \
  --working_directory ./terraform \
  --framework terraform \
  --output_format json

 AWS Documentation MCP Server Usage
 Best Practices Research# ECS Fargateベストプラクティス検索
mcp_aws_docs_search_documentation \
  --search_phrase "ECS Fargate best practices security" \
  --limit 10

 Documentation Reading# 特定のドキュメントページ読み込み
mcp_aws_docs_read_documentation \
  --url "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-fargate.html" \
  --max_length 5000

 AWS CLI MCP Server Usage
 Resource Management# ECS サービス状態確認
mcp_awslabsaws_api_mcp_server_call_aws \
  --cli_command "aws ecs describe-services --cluster streamlit-app-cluster --services streamlit-app-service --region ap-northeast-1"

 CloudWatch Logs# ログストリーム確認
mcp_awslabsaws_api_mcp_server_call_aws \
  --cli_command "aws logs tail /ecs/streamlit-app --follow --region ap-northeast-1"

 Design Decisions and Rationale
 CloudFront with Default Certificate
Decision: CloudFrontのデフォルト証明書（*.cloudfront.net）を使用

Rationale: カスタムドメイン不要、ACM証明書管理の簡素化、即座にHTTPS利用可能

Trade-off: カスタムドメイン使用不可

 Single NAT Gateway
Decision: ap-northeast-1aに単一のNAT Gatewayを配置

Rationale: コスト最適化（月額約$32の節約）

Trade-off: NAT Gatewayの単一障害点、AZ障害時のアウトバウンド通信不可

Mitigation: ECS Fargateタスクは3つのAZに分散、インバウンドトラフィックは影響なし

 ECS Fargate over EC2
Decision: ECS FargateをEC2ベースのECSより優先

Rationale: サーバー管理不要、自動スケーリング、セキュリティパッチ自動適用

Trade-off: EC2より若干高コスト

Benefit: 運用負荷の大幅削減

 Private Subnet for ECS Tasks
Decision: ECS FargateタスクをPrivate Subnetに配置

Rationale: セキュリティベストプラクティス、直接インターネット露出の回避

Requirement: NAT Gateway経由のアウトバウンド通信

 Terraform Module Structure
Decision: 機能別モジュール分割（networking、security、ecs、alb、cloudfront、monitoring）

Rationale: 再利用性、保守性、テスト容易性の向上

Benefit: 段階的なデプロイメント、部分的な更新が可能

 Container Insights Enabled
Decision: ECS Container Insightsを有効化

Rationale: 詳細なメトリクス収集、パフォーマンス分析

Trade-off: 追加コスト（CloudWatch Logsストレージ）

Benefit: 運用可視性の向上

 Conclusionこの設計は、AWSのベストプラクティスに準拠し、セキュリティ、可用性、コスト効率のバランスを取ったStreamlitアプリケーションのインフラストラクチャを提供します。Terraformによる完全なIaC管理、MCPサーバの活用、そして包括的なコード品質ツールの統合により、保守性と信頼性の高いシステムを実現します。
tasks.md

 Implementation Plan
 1. プロジェクト構造とTerraform基本設定のセットアップ
Terraformディレクトリ構造を作成（modules/、examples/complete/）
versions.tfでTerraformとプロバイダーバージョンを定義
backend.tfでローカルバックエンド設定を定義
variables.tfで共通変数を定義
outputs.tfで出力値を定義
.gitignoreファイルを作成してTerraform状態ファイルを除外
Requirements: 3.1, 3.5, 3.6
 2. コード品質ツールの設定
.tflint.hclファイルを作成してTFLintルールを設定
.checkov.yamlファイルを作成してCheckov設定（CRITICAL/HIGHのみ失敗）
Makefileを作成してfmt、validate、lint、securityコマンドを定義
Requirements: 5.1, 5.2, 5.3, 5.4, 5.5
 3. Networkingモジュールの実装
 3.1 VPC、Subnets、Internet Gatewayを作成
modules/networking/main.tfでVPCリソースを定義
3つのPublic Subnets（10.0.1.0/24、10.0.2.0/24、10.0.3.0/24）を作成
3つのPrivate Subnets（10.0.11.0/24、10.0.12.0/24、10.0.13.0/24）を作成
Internet Gatewayを作成してVPCにアタッチ
modules/networking/variables.tfで入力変数を定義
modules/networking/outputs.tfでVPC ID、Subnet IDsを出力
Requirements: 4.1, 4.2
 3.2 NAT Gateway、Route Tablesを作成
ap-northeast-1aのPublic SubnetにNAT Gatewayを作成
Elastic IPをNAT Gatewayに割り当て
Public Route Tableを作成（0.0.0.0/0 → IGW）
Private Route Tablesを作成（0.0.0.0/0 → NAT Gateway）
Route Table AssociationsでSubnetsを関連付け
Requirements: 4.2, 8.3
 4. Securityモジュールの実装
 4.1 Security Groupsを作成
modules/security/main.tfでALB Security Groupを定義（Port 443 ingress）
ECS Security Groupを定義（Port 8501 ingress from ALB SG）
Security Group間の参照を設定
modules/security/variables.tfで入力変数を定義
modules/security/outputs.tfでSecurity Group IDsを出力
Requirements: 4.3
 4.2 IAM RolesとPoliciesを作成
ECS Task Execution Roleを作成
AmazonECSTaskExecutionRolePolicyをアタッチ
ECR、CloudWatch Logsアクセス用のカスタムポリシーを作成
ECS Task Roleを作成（Bedrockアクセス用）
Trust Policyを設定（ecs-tasks.amazonaws.com）
Requirements: 4.4
 5. ECRモジュールの実装
modules/ecr/main.tfでECRリポジトリを作成
Image Tag MutabilityをIMMUTABLEに設定
Image Scanningを有効化（プッシュ時スキャン）
Lifecycle Policyを設定（最新10イメージ保持、untaggedは1日後削除）
modules/ecr/variables.tfで入力変数を定義
modules/ecr/outputs.tfでリポジトリURLを出力
Requirements: 6.2, 6.3
 6. ALBモジュールの実装
 6.1 Application Load Balancerを作成
modules/alb/main.tfでALBリソースを定義
internet-facing schemeで3つのPublic Subnetsに配置
ALB Security Groupを関連付け
Deletion Protectionを有効化
modules/alb/variables.tfで入力変数を定義
modules/alb/outputs.tfでALB DNS名、ARNを出力
Requirements: 2.5
 6.2 Target GroupとHTTPS Listenerを作成
Target Groupを作成（target type: ip、protocol: HTTP、port: 8501）
Health Checkを設定（path: /、interval: 30s、timeout: 5s）
HTTPS Listener（Port 443）を作成してTarget Groupに転送
セルフ署名証明書またはACM証明書を設定
Requirements: 2.5
 7. ECSモジュールの実装
 7.1 ECS ClusterとTask Definitionを作成
modules/ecs/main.tfでECS Clusterを作成
Container Insightsを有効化
Task Definitionを作成（launch type: FARGATE、network mode: awsvpc）
CPU: 512、Memory: 1024を設定
Task RoleとExecution Roleを関連付け
modules/ecs/variables.tfで入力変数を定義
modules/ecs/outputs.tfでCluster名、Task Definition ARNを出力
Requirements: 2.1, 2.4, 7.2
 7.2 Container Definitionを作成
Container Definitionでイメージ、ポート、環境変数を設定
Port Mapping（containerPort: 8501）を設定
CloudWatch Logs設定（log group: /ecs/streamlit-app）
環境変数（STREAMLIT_SERVER_PORT、STREAMLIT_SERVER_ADDRESS）を設定
Requirements: 6.1, 7.1
 7.3 ECS Serviceを作成
ECS Serviceを作成（launch type: FARGATE、desired count: 2）
3つのPrivate Subnetsに配置
ECS Security Groupを関連付け
Assign Public IPを無効化
Load Balancer設定（Target Group、Container、Port）
Deployment Circuit Breakerを有効化
Requirements: 2.2, 2.3, 2.4, 4.2
 7.4 Auto Scalingを設定
Application Auto Scalingターゲットを作成（min: 1、max: 10）
Target Tracking Scaling Policyを作成（CPU使用率70%）
Scale-in/Scale-out Cooldownを設定
Requirements: 2.2
 8. CloudFrontモジュールの実装
modules/cloudfront/main.tfでCloudFront Distributionを作成
OriginにALBを設定（Origin Protocol Policy: HTTP or HTTPS）
Viewer Protocol Policyをredirect-to-httpsに設定
Cache PolicyをCachingDisabledに設定
Origin Request PolicyをAllViewerに設定
Price ClassをPriceClass_200に設定
CloudFrontデフォルト証明書を使用
Minimum Protocol VersionをTLSv1.2_2021に設定
modules/cloudfront/variables.tfで入力変数を定義
modules/cloudfront/outputs.tfでCloudFront Domain Nameを出力
Requirements: 1.1, 1.2, 1.3, 1.4
 9. Monitoringモジュールの実装
modules/monitoring/main.tfでCloudWatch Log Groupsを作成（/ecs/streamlit-app）
Log Retention Periodを30日に設定
CloudWatch Alarmsを作成（CPU使用率、メモリ使用率、UnHealthyHostCount）
modules/monitoring/variables.tfで入力変数を定義
modules/monitoring/outputs.tfでLog Group名を出力
Requirements: 7.1, 7.3, 7.4
 10. メインTerraform設定の統合
terraform/main.tfですべてのモジュールを呼び出し
モジュール間の依存関係を設定
default_tagsをプロバイダー設定に追加
terraform/outputs.tfで主要な出力値を定義（CloudFront URL、ALB DNS名、ECR URL）
Requirements: 3.1, 3.6
 11. サンプル設定の作成
examples/complete/main.tfでサンプル設定を作成
examples/complete/terraform.tfvarsでサンプル変数値を設定
必要な変数（project_name、region、container_image）を設定
Requirements: 9.2
 12. Dockerfileとサンプルアプリケーションの作成
Dockerfileを作成（マルチステージビルド）
最小限のベースイメージを使用（python:3.11-slim）
非rootユーザーでの実行を設定
app/main.pyでシンプルなStreamlitアプリケーションを作成
requirements.txtで依存関係を定義
Requirements: 6.1, 6.4
 13. ドキュメントの作成
README.mdを作成（プロジェクト概要、前提条件、セットアップ手順、デプロイ手順）
アーキテクチャ図（.drawio形式）を作成
トラブルシューティングセクションを追加
コスト見積もりを記載
Requirements: 9.1, 9.3, 9.4
 14. デプロイメントスクリプトの作成
scripts/deploy.shでデプロイメントスクリプトを作成
Dockerイメージのビルド、タグ付け、ECRプッシュを自動化
Terraform init、plan、applyを実行
scripts/destroy.shで削除スクリプトを作成
Requirements: 3.1
 15. コード品質チェックの実行と修正
terraform fmtでフォーマットを実行
terraform validateで構文チェックを実行
tflintでLintチェックを実行して問題を修正
checkovでセキュリティスキャンを実行してCRITICAL/HIGH問題を修正
Requirements: 5.1, 5.2, 5.3, 5.4, 4.8


 1. Ruleファイル作成Amazon Q Developerが開発する際の規則となるRuleファイルを作成しましょう。Ruleファイル自体はチャットウィンドウのボタンを押下することで作成可能です。今回は"Development-rules-definition"というファイル名にしました。



Development-rules-definition.mdが作成されたら、Kiroで作成された.mdファイルを元にRuleを作ってもらいましょう。コンテキストとして.mdファイルをして上で以下プロンプトを入力しました。
.mdファイルの内容から"Development-rules-definition.md"を作成してください。開発に必要なルールのみを抜き出して開発ルール定義にして欲しいです。





 2. 実装Ruleファイルまで作成できたらあとはTask.mdの内容をもとに実装を進めてもらいましょう。今回は簡素なプロンプトを投げて実装を進めてもらいます。
tasks.mdの内容をもとに最後まで実装してください。
上記プロンプトだけで10分弱でTerraformファイルとStremlitのサンプルアプリを実装してくれました。

Kiroさんは1時間弱かかりました。実装スピードだけを比較するとAmazon Q Developerの圧勝ですね。



 3. デプロイ出来上がったスクリプトを使ってデプロイしていきましょう。
失敗しました。そんなものです。

エラーをそのままチャットウィンドウに貼り付けて修正してもらいましょう。
Terraform applyには成功しましたが、CloudFrontのURLにアクセスすると503が返却されています。その旨をチャットで伝えたら1分ほどで修正してくれました。





3回Kiroさんとやりとりすることで動作確認することができました。




 おまけAmazon Q Developerが作ってくれた構成図です。プロンプトは「最新のAWSアイコンを利用して.drawio形式でアーキテクチャ図を作成して。」です。

雰囲気は伝わってくるのですが、業務で利用するには多々修正が必要ですね。とはいえ.drawio形式なのでGUIで容易に修正可能です。サクッとこのレベルの構成図を作ってくれるのは嬉しいですね。


 おわりKiro単体で実装するよりもAmazon Q Developerと組み合わせた方が効率が良いことがわかっていただけたでしょうか？Amazon Q Developer ProライセンスであればIP補償やログ取得機能などさまざまなことが可能となります。

知識が全くない人が0から作り切るのは難しいですが、一定知識のある人であれば強い相棒となってくれることでしょう。
AIと仲良くして自分の好きなものをどんどんアウトプットしていきましょう。AIが全てを解決してくれるわけでもないため、人間自身も継続的に努力をして技術力や経験を積み重ねていきましょう。
この記事を読んでくれた方が少しでもアクションを起こしてくれたら嬉しいです！