はじめに

前回は、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） を作成していきます。