はじめに
Part1 でKiroのSpec生成を、Part2 でAWSサーバーレスAPIの実装を紹介しました。
後編では、実際に使ってみての考察をまとめます。
- Spec駆動で何が変わったのか
- 何が変わらなかったのか
- vibeコーディングとどう使い分けるか
Spec駆動で変わったこと
1. タスクの抜け漏れがなかった
tasks.md が自動生成されることで、「IAM権限の付与」「環境変数の設定」「GSIの追加」といったインフラ系の細かい作業が抜け落ちないというメリットがありました。
vibeコーディングで「メモ作成APIを作って」と頼むと、Lambdaのコードは生成されても「DynamoDBへの書き込み権限をIAMで付与する」という手順を忘れることがあります。Kiroでは tasks.md にそのステップが最初から含まれていました。
2. 要件のトレーサビリティが確保された
各タスクには対応する要件番号が記載されています。
- [x] 7.1 Create Memo Lambda関数の実装
- _要件: 3.1, 3.2, 3.3, 3.4, 3.6_
「このコードは何のために書いているのか」が常に要件と紐づいているため、実装中に「あれ、これどこまで実装すればよかった？」という迷いが少なかったです。
Spec駆動で変わらなかったこと
specがあっても解決しない問題もありました。
1. specの品質は入力の品質に依存する
当然ですが、specの質は渡す仕様書の質に比例します。今回は良いspecが生成されましたが、「なんとなく認証付きAPIを作りたい」程度の入力だと、specの精度は落ちます。
vibeコーディングの「仕様なしで出力する雑さ」がSpec駆動に移っただけ、という状況にもなりえます。
2. 既存コードへの適用には工夫が必要
今回は新規プロジェクトだったため、specを最初から作れました。既存のコードベースにKiroを適用する場合は、現状のコードからspecを逆生成するか、既存設計を考慮したspecを書く必要があります。
vibeコーディングとSpec駆動の比較
| 観点 | vibeコーディング | Kiro Spec駆動 |
|---|---|---|
| 進め方 | 指示 → コード生成 | 仕様 → spec生成 → コード生成 |
| 設計の一貫性 | AIに委ねる（ブレやすい） | specで固定してから生成 |
| 手戻りのタイミング | 動いてから直す | 書く前にspecで確認できる |
| 向いているもの | プロトタイプ・雑に試したい | 設計意図を守りたい実装 |
| AWS固有の詳細 | AIが補う（精度はまちまち） | specだけでは補えない |
| 初期コスト | 低い（すぐ書き始める） | やや高い（specを作る時間が必要） |
| 適した規模 | 小さい・使い捨て | 中規模以上・チーム開発 |
どちらが優れているわけではなく、使い分けだと思います。
個人的な使い分け指針
vibeコーディングが向く場面
- 「とりあえず動くものを確認したい」プロトタイプ
- 1時間で試して捨てるようなもの
- 自分だけが使うスクリプト
Kiro Spec駆動が向く場面
- 「設計意図を守って実装したい」プロダクションコード
- 複数のサービスが絡む複雑な構成
- チームで認識を合わせながら開発する場合
- 要件から実装まで一気通貫でドキュメントを残したい場合
まとめ
今回の実験で確認できたこと：
Spec駆動でできたこと
- 設計意図を守ったコード生成
- DynamoDBのGSI設計など、アクセスパターンを考慮した設計の文書化
- タスクの抜け漏れ防止（IAM権限、環境変数など）
- 要件→設計→実装のトレーサビリティ確保
Spec駆動でできなかったこと
- 開発フェーズに応じた細かい設定の調整は別途確認が必要
一言で言うと：
vibeコーディングは 速さ、Spec駆動は 精度。
早く動くものが欲しいならvibeコーディング、設計意図を守って作りたいならKiroのSpec駆動と使い分けるのはアリだと思います。
Kiro、気になった方はぜひ触ってみてください。
シリーズ記事
- Part.1：vibeコーディングの課題とKiroのSpec生成
- Part.2：KiroのSpec駆動でAWSサーバーレスAPIを実装してみた
- Part.3：vibeコーディングとKiro Spec駆動の使い分けを考えてみた ← 本記事