はじめに

前回は Plan（設計） と Tasks（タスク分解） を行いました。

SpecKitによって、

仕様
設計
タスク

までが整理され、実装前の準備が完了しました。

今回はいよいよ

Implement

です。

Terraformを生成し、実際にAWSへデプロイしていきます。

しかし、今回一番面白かったのは、

「AIが最初から完璧なコードを書いた」わけではない

という点でした。

むしろ、

AIと一緒に設計を改善しながら実装を進める

という開発スタイルになりました。

Implement開始

まずは Cursor Agent に

プロンプト

/speckit-implement

specs/001-aws-waf-alb/tasks.md に基づいて
Terraform を実装してください。

terraform apply は実行せず、
fmt / validate / plan まで実施してください。

と依頼しました。

すると、

Terraformプロジェクト一式を生成してくれました。

Terraform構成

生成された構成はこちらです。

ディレクトリ構成

bootstrap/
    tfstate-backend/

modules/
    waf-alb/
        versions.tf
        variables.tf
        locals.tf
        main.tf
        outputs.tf

environments/
    stg/
    prd/

実務でもよく見る構成です。

module化され、

環境ごとの差分は

tfvars

terraform.tfvars

で切り替える設計になっていました。

validateは成功

まずは

validate

terraform fmt
terraform validate

を実施。

どちらも成功しました。

ここまでは順調です。

planで止まる

次に

plan

terraform plan

を実施すると、

ここで停止しました。

理由は

Terraform Backendでした。

応答

BucketRegionError

というエラーです。

原因はBackend

実は、

生成された backend.tf は

backend.tf

example-terraform-state

という

サンプル値のままでした。

当然ですが、

実際のS3バケットではありません。

AIは

「実環境が分からないので停止する」

という判断をしました。

この動きは

個人的にはかなり好印象でした。

勝手に進めるのではなく、

必要な情報が無いときは止まってくれます。

Backendが無い問題

さらに考えてみると、

Terraform Backend 自体が存在していませんでした。

つまり、

Terraform State

を保存する

S3バケットも

DynamoDBテーブルも

ありません。

そこでAIから

bootstrap

という提案がありました。

bootstrap追加

最終的には

ディレクトリ構成

bootstrap/
    tfstate-backend/

を追加しました。

ここでは

S3
DynamoDB

だけを作成します。

Backendは

Terraform自身が管理できないので、

まず土台だけを作る

という構成です。

bootstrapだけapply

bootstrapは

ローカルStateで実行します。

つまり、

terraform

terraform init

terraform plan

terraform apply

を

bootstrapだけ実施しました。

作成されたものは

S3 Bucket
Versioning
Public Access Block
SSE-S3
DynamoDB

だけです。

これで

Terraform Backend

が完成しました。

stgのplanが成功

Backend完成後、

改めて

terraform

terraform init

terraform plan

を実施すると

正常にplanできました。

ここで初めて

Terraformの差分が確認できます。

要件変更が発生

ここで、

仕様変更が入りました。

最初は

という設計でした。

しかし今回は

WebACLだけ作りたくなりました。

ALBへのアタッチは不要です。

AIに相談してみる

そこで

Cursor Agentへ

プロンプト

WebACLは作るけど
ALBへのアタッチはしないようにしたい

と相談しました。

するとAgentは

単純にassociationを削除するのではなく、

こんな提案をしてくれました。

応答

enable_association

true

false

という変数を追加し、

Terraformから

ON/OFF

できるようにする設計です。

これは

実務でも使いやすい設計でした。

planも変わる

変更前は

plan

Plan

4 resources

でした。

しかし

associationが無くなり、

plan

Plan

3 resources

になりました。

つまり、

作成されるのは

WebACL
CloudWatch Logs
Logging設定

だけです。

ALBへの影響はありません。

applyしてみる

ここで

stg環境だけ

applyしました。

結果はこちらです。

apply結果

WebACL

CloudWatch Logs

Logging Configuration

が作成されました。

ALBへの関連付けは

作成されていません。

つまり、

既存サービスへの影響なし

という状態です。

WAFのdescriptionでエラー

実装中に

もう一つ面白いことがありました。

WebACLの

description

でエラーになりました。

原因は

原因

（）

()

などの括弧が

WAFでは利用できなかったためです。

Agentは

エラー内容を解析し、

ASCIIだけのdescriptionへ修正してくれました。

こういう細かなAWS仕様まで

調べながら対応してくれるのは便利だと感じました。

prdも確認

最後に

prdでは

plan

terraform plan

まで実施しました。

結果は

plan

Plan

3 to add
0 change
0 destroy

でした。

さらに

Managed Rulesは

override_action

none

となっており、

Countではなく

Block

になっていました。

環境差分も

variablesだけで切り替えられています。

SpecKitを使って感じたこと

今回一番印象に残ったのは、

AIがコードを書くだけではなかったことです。

例えば

Backend構成を提案する
module構成を改善する
要件変更を設計へ反映する
enable_associationを提案する
WAF制約を調査する

など、

一緒に設計を育てている

感覚がありました。

シリーズまとめ

今回で

まで体験できました。

SpecKitは

「AIにコードを書かせるツール」

ではなく、

仕様を起点にAIと開発を進めるためのフレームワーク

だということを実感しました。

次回予告

最終回では、

今回のシリーズ全体を振り返りながら、

実際に使って感じたメリット・デメリットや、

SpecKit が向いているプロジェクト・向いていないプロジェクトについてまとめたいと思います。

また、実際に AI とやり取りする中で得られた「こう依頼すると良かった」「ここは人が判断すべきだった」といった実践的な知見も紹介します。

Cursor × SpecKitではじめる仕様駆動開発