AWS KiroのSpec駆動開発を使って認証付きサーバレスWEBアプリを作った話

AWSから発表されたAWS Kiroを使ってWEBアプリを構築しました。
Vibeコーディングとは異なるSpec駆動開発の魅力について説明しています。

Transcript

1. vibeコーディングに限界を感じたので、 KiroのSpec駆動開発を試した話
2. アジェンダ Vibeコーディングの壁 Kiroとの出会い Kiroで作ってみた！ VibeコーディングとSpec駆動開発の違い 本日の目標 AWS Kiroの概要を知る VibeコーディングとSpec駆動開発を使い 分けられるようになる。
3. Vibeコーディングの壁 AIエージェントの台頭により、誰でも簡単に開発ができるようになった一方で、 「とりあえず作ってみる」により、開発当初と成果物のズレを感じることが増えた。 動くコードは出てくる。でも「意図した要件になっていない」 例： ・Cognito認証を頼むと、Authorizerではなく Lambda 内でトークン検証するコードが出てくる ・DBからの取得がGSIを使わずフルスキャンになっているので遅い 動くデモを作ってみたものはいいものの、クライアントの意図と全く異なっており0から作り直しという経験は実際のPJでも頻繁にある。（筆者談） vibeコーディングは 「設計をすっ飛ばして、いきなりコードを生成する」 ↓ 動くけど、意図とズレたものができあがる
4. Kiroとの出会い Kiroは「仕様 → 設計 → タスク分解 → 実装」の順番で進む コードを書く前に設計を固める ＝ 設計意図がズレない 「これなら vibeコーディングの問題が解決できるのでは？」 要件定義 → 設計 → タスク分解 → 実装 先に要件を固めてから実装する「Spec駆動開発」を搭載したKiroであれば、設計意図とのズレ を解消できるのではないかと考えた。 Kiroの開発フロー
5. Kiroで作ってみた！ サーバレスな認証付きメモ管理 APIを構築した。 ※ Cognito Authorizer で認証・認可を制御 Cloudflont S3 API Gateway Lambda DynamoDB Congnito アーキテクチャ
6. Kiroで作ってみた！ Specモードで起動すると、最初に要件定義書を作成してくれる。 各工程で人間による承認（Human-in-the-Loop）を繰り返しながら実装する。 要件定義 設計 タスク分解 ・Requirements.md（要件定義書） ・Design.md（設計書） ・Tasks.md（実装タスクリスト） Specモード三種の成果物 承認 承認
7. Kiroで作ってみた！ Kiroと開発したWebアプリはログイン認証 ~ メモの登録まで完成している。 ログインページ 投稿ページ https://d3qt51jp25bcg8.cloudfront.net ＊新規登録は塞いでいます。
8. まとめ vibeコーディング vs Kiro Spec駆動 vibeコーディング Kiro Spec駆動 進め方 いきなりコード生成 仕様 → 設計 → タスク → コード 設計の一貫性 AIにお任せ（ブレる） spec で固定してから生成 手戻り 動いてから直す 書く前に設計を確認 向いている場面 雑に動くものを速く 設計通りに作りたいとき → どちらが上ではなく、要件に応じた使い分けが大事。 Kiroが他の何よりも優れていると主張したいわけではないことに留意いただきたい。 それぞれの向き不向きを理解した上で、選択肢の1つとしてKiroを検討してほしい。
9. このスライドも実は Kiro で作りました。 「仕様を書いて、要件を固めてから作業する」 コードだけでなく、プレゼン資料や日々の業務でも大切です。 Kiro、気になった方はぜひ触ってみてください。 ありがとうございました。