はじめに
前回は、Cursor に SpecKit を導入し、Constitution（開発方針） を作成しました。
Constitution では、
- Terraform を優先する
- モジュール化を意識する
- State 管理を明確にする
- 日本語で仕様・設計・タスクを作成する
といった、このプロジェクトで守るルールを定義しました。
まだこの時点では Terraform は1行も書いていません。
今回はその続きとして、Specification（仕様） を作成します。
SpecKitでは「まず仕様を書く」
これまで私は AI を使うとき、
Terraform で AWS WAF を作ってください。
のように、いきなり実装を依頼していました。
しかし SpecKit では違います。
まず AI に依頼するのは
何を作るのか
です。
つまり、
という流れになります。
今回はこの Specification を作成していきます。
今回作るもの
今回のお題は
「AWS WAF」
です。
最終的には Terraform で
- AWS WAFv2
- CloudWatch Logs
- stg は Count
- prd は Block
という構成を作る予定です。
ただし今回は、
まだ Terraform は作りません。
Cursor Agentへ依頼
今回は Cursor Agent に以下のように依頼しました。
/speckit-specify
AWS WAF を Terraform で構築する仕様を作成してください。
要件:
- ALB 向けの AWS WAFv2 WebACL を作成する
- Scope は REGIONAL
- stg は Count / Alert を基本とする
- prd は Block を基本とする
- AWS Managed Rules を利用する
- CommonRuleSet
- KnownBadInputsRuleSet
- SQLiRuleSet
- IPReputationList
- AnonymousIpList
- CloudWatch Logs へ WAF ログを出力する
- Terraform で実装する
- module 化を前提にする
- variables / tfvars で環境差分を管理する
- 日本語で仕様を作成する
今回の段階では、まだ実装は行わず、仕様作成のみ実施してください。
最後の
まだ実装は行わない
という一文がポイントです。
AIが作成したもの
Agent は以下のような構成を作成しました。
specs/
└── 001-aws-waf-alb/
├── spec.md
└── checklists/
この時点では
Terraform ファイルは存在しません。
代わりに、
仕様書が作成されました。
Requirementsが整理される
spec.md を見ると、
例えば
- ALB向けWebACL
- REGIONAL
- Managed Rules
- CloudWatch Logs
- Terraform
- module化
などが
Requirements として整理されていました。
さらに
- stg → Count
- prd → Block
という環境差分まで仕様として明文化されています。
これまでは
tfvars を見れば分かる
という状態でしたが、
SpecKit では
仕様として最初に定義
されます。
User Storyも作成される
SpecKit は
Requirements だけではありません。
例えば
ALBを保護したい
環境ごとに防御レベルを切り替えたい
といった
User Story
も作成されます。
さらに、
それぞれに
- 優先順位
- 受け入れ条件
- エッジケース
まで整理されていました。
Acceptance Criteriaまで作られる
個人的に驚いたのが、
Acceptance Criteria
つまり
受け入れ条件
まで自動生成されたことです。
例えば
CloudWatch Logsへログが出力される
stgではCountになる
prdではBlockになる
など、
実装完了の判断基準まで仕様書に含まれます。
AI にコードを書かせる前にレビューする
ここで重要なのは、
SpecKit は
AIが作った仕様をそのまま採用するものではない
ということです。
人がレビューします。
今回も、
仕様を確認すると
ALB への関連付けまで含まれていました。
この時点では
「まあいいか」
と思っていました。
しかし実際に実装を進めると、
今回はWebACLだけ作成したい
という要件変更が発生しました。
SpecKit では、
このような変更も
まず仕様を修正してから
設計・実装へ反映していきます。
この流れは
従来のAI開発との大きな違いだと感じました。
仕様だけ作る意味
最初は
仕様だけ作って意味があるの？
と思っていました。
しかし、
このあと実施する
- Plan
- Tasks
- Implement
は
すべて
この spec.md
を元に生成されます。
つまり、
仕様書が
プロジェクト全体の基準
になります。
AIとの会話も変わった
今までは
Terraformを書いてください
でした。
しかし今回は
AWS WAFの仕様を作ってください
になりました。
たったこれだけですが、
AIとの会話の内容が大きく変わります。
コードを書く前なので、
要件変更が発生しても
仕様を修正するだけで済みます。
これが仕様駆動開発のメリットだと感じました。
次回予告
次回は
/speckit-plan
を実行し、
今回作成した仕様をもとに
Terraform の設計書を作成します。
ここでは
- module構成
- variables設計
- CloudWatch Logs設計
- WAF構成
などが
どのように設計へ落とし込まれるのかを紹介します。
おわりに
SpecKit を使う前は、
「AIにコードを書いてもらう」
という使い方しかしていませんでした。
しかし実際に使ってみると、
最初に仕様を作ることで
プロジェクト全体の方向性が明確になります。
今回はまだ Terraform は1行も書いていません。
それでも、
開発の土台となる仕様書が完成しました。
次回はいよいよ、この仕様書をもとに Terraform の設計（Plan） を作成していきます。