はじめに
これまでの4回で、
- SpecKit の導入
- Constitution
- Specification
- Plan
- Tasks
- Implement
まで一通り体験しました。
最終回となる今回は、
実際に使ってみて感じたこと
をまとめます。
正直に言うと、最初は
「AIにコードを書いてもらうためのツール」
くらいにしか思っていませんでした。
しかし、一連の開発を終えた今では、
SpecKit に対する印象は大きく変わりました。
今回完成したもの
今回最終的に完成したのは、
Terraform を使った AWS WAF の構成です。
構成としては
Terraform Backend
├── S3
└── DynamoDB
AWS WAF
├── WebACL
├── Managed Rules
├── CloudWatch Logs
└── Logging Configuration
さらに、
- stg → Count
- prd → Block
という環境差分まで Terraform で管理できるようになりました。
最初から完璧ではなかった
AIを使った開発というと、
「一度お願いしたら完成する」
というイメージを持つ方も多いと思います。
しかし、
実際はそうではありませんでした。
今回だけでも、
途中で何度も設計を見直しています。
例えば、
- Terraform Backend が存在しない
- ALBへのアタッチが不要になった
- WAF の description 制約に引っかかった
など、
実際の開発らしい問題が発生しました。
Backend問題
一番最初にぶつかったのが
Terraform Backendでした。
最初の plan は
BucketRegionError
で失敗しました。
原因は、
backend.tf が
example-terraform-state
というサンプル値だったからです。
最初は
「Terraform が間違っているのかな？」
と思いました。
しかし、
実際には
Backendそのものが存在していませんでした。
bootstrapという考え方
そこで AI が提案してくれたのが
bootstrap/
という構成でした。
Terraform 自身が利用する State を、
まず Terraform で作る。
そのためだけの
Bootstrap プロジェクトです。
最終的には
bootstrap/
└── tfstate-backend
を作成し、
- S3
- DynamoDB
だけを先に apply しました。
この考え方は、
これまで何度も Terraform を使ってきましたが、
あまり意識していませんでした。
要件変更も仕様から直す
途中で、
仕様変更もありました。
最初は
WebACL
↓
ALBへアタッチ
する設計でした。
しかし今回は
WebACLだけ作成したくなりました。
普通なら
Terraformだけ修正して終わりです。
しかし SpecKit では
Specification
↓
Plan
↓
Tasks
↓
Implement
の順番で修正します。
コードだけ直すのではなく、
設計そのものを更新する。
これが仕様駆動開発なんだと実感しました。
enable_associationという提案
面白かったのは、
Agent が
association を削除しなかったことです。
代わりに、
enable_association
という変数を提案しました。
つまり、
enable_association = true
なら
ALBへアタッチ。
enable_association = false
なら
WebACLだけ作成。
将来のことまで考えた設計になっていました。
これは実務でもそのまま使えそうです。
AIは「調査」もしてくれる
実装中、
WAF の description でエラーになりました。
調べてみると、
WAFでは
全角括弧だけでなく
半角括弧も利用できませんでした。
Agentは
エラーメッセージを読み取り、
原因を調査し、
description を修正してくれました。
ただコードを書くだけではなく、
AWS の仕様まで調べて対応してくれるのは便利でした。
一番印象が変わったこと
今回一番印象が変わったのは、
AIへの指示です。
以前なら、
Terraformを書いてください
でした。
しかし今回は、
仕様を作ってください
↓
設計してください
↓
タスクへ分解してください
↓
レビューしてください
↓
実装してください
という会話になりました。
AIを
コーディングツールではなく、
設計者やレビュアーとして使っている感覚です。
Cursor Agentとの付き合い方
今回学んだことがもう一つあります。
最初は、
私は
cdして
terraform initして
terraform planして...
と、
細かく指示しようとしていました。
しかし実際には、
stg環境でterraform planしてください
だけで十分でした。
Agent が
- ディレクトリ移動
- コマンド実行
- エラー解析
まで判断してくれます。
つまり、
コマンドを教えるのではなく、
目的を伝える
方がうまくいきました。
SpecKitはどんな人に向いている？
実際に使ってみて、
特に向いていると感じたのは
- Terraform
- AWS
- Kubernetes
- アプリケーション開発
など、
設計が重要なプロジェクトです。
逆に、
数行のスクリプトを書くような用途では、
少しオーバースペックかもしれません。
今後使ってみたいもの
今回は
AWS WAFだけでした。
今後は
- VPC
- ECS
- RDS
- Network Firewall
- GuardDuty
など、
より大きな構成でも試してみたいと思っています。
SpecKitの効果は、
システムが大きくなるほど実感できそうです。
シリーズを終えて
今回、
5回にわたって
Cursor × SpecKit を試してきました。
最初は
「AIにTerraformを書いてもらう」
くらいの認識でした。
しかし実際には、
AIと一緒に
- 仕様を考え
- 設計し
- タスクへ分解し
- レビューし
- 実装する
という、
これまでとは全く違う開発体験になりました。
もちろん、
最終的な判断は人が行う必要があります。
それでも、
設計の壁打ち相手やレビュー担当として、
AIは非常に心強い存在でした。
おわりに
今回のシリーズでは、
実際の Terraform 開発を題材に、
SpecKit を使った仕様駆動開発を体験しました。
SpecKit は、
「AIにコードを書いてもらうためのツール」
ではありません。
「AIと一緒に開発を進めるためのフレームワーク」
だと感じています。
これから AI を活用した開発がさらに増えていくと思います。
その中で、
「まず仕様を書く」
という考え方は、
今後ますます重要になっていくのではないでしょうか。
もし SpecKit が気になっている方は、
ぜひ小さなプロジェクトから試してみてください。
きっと、これまでとは少し違う開発体験ができると思います。
最後まで読んでいただき、ありがとうございました。