はじめに
前回は 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化され、
環境ごとの差分は
terraform.tfvars
で切り替える設計になっていました。
validateは成功
まずは
terraform fmt
terraform validate
を実施。
どちらも成功しました。
ここまでは順調です。
planで止まる
次に
terraform plan
を実施すると、
ここで停止しました。
理由は
Terraform Backendでした。
BucketRegionError
というエラーです。
原因はBackend
実は、
生成された 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 init
terraform plan
terraform apply
を
bootstrapだけ実施しました。
作成されたものは
- S3 Bucket
- Versioning
- Public Access Block
- SSE-S3
- DynamoDB
だけです。
これで
Terraform Backend
が完成しました。
stgのplanが成功
Backend完成後、
改めて
terraform init
terraform plan
を実施すると
正常にplanできました。
ここで初めて
Terraformの差分が確認できます。
要件変更が発生
ここで、
仕様変更が入りました。
最初は
という設計でした。
しかし今回は
WebACLだけ作りたくなりました。
ALBへのアタッチは不要です。
AIに相談してみる
そこで
Cursor Agentへ
WebACLは作るけど
ALBへのアタッチはしないようにしたい
と相談しました。
するとAgentは
単純にassociationを削除するのではなく、
こんな提案をしてくれました。
enable_association
true
false
という変数を追加し、
Terraformから
ON/OFF
できるようにする設計です。
これは
実務でも使いやすい設計でした。
planも変わる
変更前は
Plan
4 resources
でした。
しかし
associationが無くなり、
Plan
3 resources
になりました。
つまり、
作成されるのは
- WebACL
- CloudWatch Logs
- Logging設定
だけです。
ALBへの影響はありません。
applyしてみる
ここで
stg環境だけ
applyしました。
結果はこちらです。
WebACL
CloudWatch Logs
Logging Configuration
が作成されました。
ALBへの関連付けは
作成されていません。
つまり、
既存サービスへの影響なし
という状態です。
WAFのdescriptionでエラー
実装中に
もう一つ面白いことがありました。
WebACLの
description
でエラーになりました。
原因は
（）
()
などの括弧が
WAFでは利用できなかったためです。
Agentは
エラー内容を解析し、
ASCIIだけのdescriptionへ修正してくれました。
こういう細かなAWS仕様まで
調べながら対応してくれるのは便利だと感じました。
prdも確認
最後に
prdでは
terraform 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ではじめる仕様駆動開発