背景
AI コーディングが普及し爆速開発が実現しつつある昨今に登場した仕様駆動開発（SDD）は、その高速な開発サイクルをスポイルしてしまう、というジレンマを抱えがちである。
では、アプリケーション開発ほど頻繁な変更がなく、堅牢性が強く求められるクラウドインフラ（IaC）の領域ならどうだろうか。SDD の堅牢さと IaC は相性が良いのではないか？
そんな仮説のもと、実際に試してみることにした。
使用技術
- Terraform + AWS
- Gemini 2.5 Pro
- github/spec-kit
とりあえず spec-kit で作ったもの
良かった点 (Good)
実際に試してみて、SDD と Terraform の組み合わせが有効だと感じた点。
- AI との壁打ちによる非機能要件の発見:
- SDD の真骨頂、仕様を練るフェーズで AI と対話することで、自分だけでは見逃しがちだった非機能要件を洗い出し、要件に盛り込むことができた。
- 仕様書ベースのコード生成がもたらす安心感:
- きっちりとした仕様書さえ完成すれば、AI が吐き出すコードに対しても「仕様に基づいている」という一定の安心感が得られた。(目 grep の負荷軽減)
もう一歩な点 (More)
- AI が生成する Terraform コードのブレ:
- （MCP で知識強化していても）誤ったコードが出力されることがあった。例えば、API Gateway v2 を使っていたはずが、途中から急に v1 を使うコードに変更されてしまったりした。
- 本当に細かいところまで仕様書 (spec) に書かないと、AI はすぐにブレてしまう可能性がある。でも、それはなかなか非現実的。
- トラブル時の舵取りには知識が必須:
- spec があっても AI はトラブルを起こす。そのときの舵取りをミスるとあっという間に時間を浪費してしまう。spec があろうがなかろうが、結局、ドメインや技術領域への一定の知識は求められる。
- タスク粒度のジレンマ:
- トラブルを避けるには、できるだけタスクの粒度を小さく切るのが定石
- しかし、そうすると「一番大変な 0 -> 1 フェーズは結局、手で作るのか？」という疑問が湧く
- 後からそれを spec に落とし込むのも、なかなかに大変な作業で、億劫
結論: 手堅いが、まだ早い
現時点での率直な所感は、「手でやった方が確実かつ早い」 というもの。
そもそも Terraform 自体が宣言的な性質を持つため、コード自体が仕様を表現しているとも言える。もしかすると、SDD で spec を書くよりも、コードから仕様書をリバースエンジニアリングできるレベルまで落とし込む方が、IaC における「あるべき姿」なのかもしれない（spec 不要説）。
一方で、仕様策定フェーズにおける AI との強制的な壁打ちでのインサイト獲得（非機能要件の発見など）は、明確な利点だった。
MCP による知識強化や LLM そのもののさらなる飛躍によって、このアプローチが化ける可能性はまだまだ秘めていると感じている。