Kiroの仕様駆動開発を実践したら、結果バイブコーディングになった話

2025.12.13
こんにちは、AI事業本部の洲崎です!

クラスメソッド AI駆動開発 Advent Calendar 2025、13日目の記事です！

https://adventar.org/calendars/11778
今回はKiroのワークショップを通じて仕様駆動開発を実践してみました。

結果として、Kiroの使い方以上に大事なことを学ぶことになりました。。
 なぜKiroなのか？Kiroの存在自体は知っていたものの、あまり触っておらず、正直別のツール（Claude Code）を使っていました。

しかし、AWS re:Invent 2025ではKiroの存在感が強く、Kiroハウスといった展示ブースや、

https://dev.classmethod.jp/articles/reinvent2025-house-of-kiro/

フロンティアエージェントとして、Kiro Autonomous Agentがキーノートで発表されたりと、本格的に学ぶのに良い機会だと思ったのがきっかけです。

https://dev.classmethod.jp/articles/kiro-autonomous-agent-early-access/
 Kiroワークショップの内容Kiroの公式ワークショップは日本語対応されており、かなりのボリュームです。

https://catalog.workshops.aws/kiro-intro/ja-JP
今回は以下の流れで実践してみました。
セットアップ（IDE、MCPサーバー設定）
仕様駆動開発の座学
ステアリングファイルの作成
スペック（要件・設計・タスク）の作成
アプリケーションの実装
 仕様駆動開発とバイブコーディングワークショップの座学で最も強調されていたのは、バイブコーディングと仕様駆動開発の違いです。
バイブコーディング
曖昧なアイデアに基づく即座のコード生成
AIのコンテキストウィンドウに依存
最小限のドキュメントで実施
仕様駆動開発
構造化された要件定義と設計ドキュメント
明確なアーキテクチャの決定
チームでスケールするための開発プラクティス
Kiroは仕様駆動開発を実現するために、以下の機能を提供しています。
Spec
要件（requirements.md）、設計（design.md）、タスク（tasks.md）の管理

Steering
プロジェクト固有のガイドライン（Claude CodeのCLAUDE.mdに相当）

Chat
プロジェクトコンテキストを理解したAI（Kiro）との会話

Hooks
自動化されたワークフロー

 実践して学んだこと セットアップは簡単でしたKiro IDEをダウンロードし、MCPサーバー（Fetch、AWS Knowledge、Playwright）を設定しました。

この辺りは公式ワークショップの内容で問題なく進みました。

MCPを設定中のKiro IDEのチャット画面は以下です。

プロンプトを与えるだけで、mcp.jsonを生成してくれます。

 ステアリングでコンテキストを与える.kiro/steering/配下に以下のマークダウンファイルを配置することで、Kiroにプロジェクトの知識を提供することができます。

Foundation steering filesを実行すると、以下の3つのファイルが自動生成されます。
product.md：プロダクト概要とビジネス目標
tech.md：技術スタック
structure.md：プロジェクト構造と命名規約
さらに独自のステアリングファイルを作成すれば、ドメイン固有の用語やコード標準をコンテキストとして与えることができます。

ステアリングファイルは常に読み込むことや、条件付きで読み込むことも可能です。

https://kiro.dev/docs/steering/
 スペック作成で設計を固めるKiroパネルの「SPECS」から新規作成すると、Kiroと対話しつつ以下を生成します。
Requirements.md
機能要件と非機能要件の整理

Design.md
技術アーキテクチャの設計

Tasks.md
実装ロードマップ（実行タスク）

この段階で各mdファイルをレビューし、要件を固めます。
 実装フェーズKiroにtasks.mdに従って、アプリケーションを構築してもらうように依頼します。
tasks.md の最初のタスクを実装してください。
requirements.md を参照し、シンプルですが完全なアプリケーションを作成してください。
 ここまではよかった仕様を固めてKiroにアプリケーションを構築してもらうところまでは進んでいたのですが、結果的に、私の実装はバイブコーディングと何ら変わらないものになりました。。

完成したアプリケーション（UI）がこちらです。



背景がダークに、文字が黒で見づらすぎます。。

赤の注意書きも見づらい。こんなはずではなかった。

もっとリッチで使いやすいアプリケーションを（勝手に）求めていました。
あまりにも見づらかったので、とりあえずstyle.cssを調整してもらいました。

何が問題だったのでしょうか。
 問題1：要件が曖昧なまま進めたtasks.mdを確認していましたが、何となくで進めてしまっていました。
そもそも今回、私は「Kiroを学ぶこと」が目的で、「タスク管理アプリを作ること」はワークショップの中での手段でした。

そのため、以下の観点が抜け落ちていました。
誰が使うのか？（自分？チーム？）
どんな課題を解決するのか？（既存ツールの何が不満？）
何ができれば成功なのか？（どこまで作れば満足？）
結果、要件定義の段階でも、この辺りが全くイメージできていなかったです。
UIのデザインイメージがない
ユーザーフローが明確でない
機能（何が必要なのか）のイメージができていない
この状態でtasks.mdに「基本UIレイアウトの作成」と書かれていても、どんなUIなのかを具体的にイメージできていませんでした。
 問題2：専門知識の不足私の場合、もともとフロントエンド（特にUI/UX）の知識が特に不足していました。

そのため、例えば以下の観点での判断ができない状態です。
どんなレイアウトが使いやすいのか
どんな色使いが見やすいのか
どういう技術要素を利用するのか
結果、Kiroに「シンプルなUIを作って」と依頼しても、私自身が良し悪しを判断できない状態でした。
 問題3：Specのレビュー不足問題1、問題2と繋がりますが、Specができた段階で専門家にレビューを依頼しなかったことも失敗の要因です。

特にrequirements.mdとdesign.mdは、この段階で知見がないのであれば、社内メンバー（デザイナーやフロントエンドエンジニアなど）にレビューしてもらうか、もう少しAIと壁打ちして内容を固めるべきでした。
 学んだ教訓 教訓1：まず「何を作りたいか」を明確にする要件定義の前に、作る目的を明確にするべきでした。
ダメな例
シンプルなタスク管理アプリを作る
良い例
【目的】
- 誰が：個人開発者が
- 課題：複数のプロジェクトのタスクが混在して管理しづらい
- 解決：プロジェクト単位でタスクを整理し、優先度を可視化したい

【要件】
- 参考デザイン：Trelloのようなカード型UI
- カラースキーム：#FFFFFF（背景）、#0052CC（プライマリ）
- ユーザーフロー：ログイン不要、ブラウザのlocalStorageで保存
- 必須機能：タスク追加、ステータス変更（ToDo/進行中/完了）、優先度設定
requirements.mdには、目的と課題を明記し、誰が見ても同じイメージを持てるレベルの具体性が必要だと実感しました。
 教訓2：専門知識がない領域は早めに相談する大前提として、作成するアプリケーションに対してのある程度の技術要素の知識は押さえておくべきだと思いました。

私の場合だと、フロントエンドやUI/UXは入門レベルでも押さえておくべきです。

チーム開発であれば、Spec段階で各専門家とレビューをするのが良いと思います。
 教訓3：反復改善のプロンプトを行う仕様駆動開発でも、一発で完璧なものは出すのは難しいと感じます。

例えば、以下のようなプロンプトパターンで改善を試みるのが重要だと感じました。
理由を聞く
なぜこのアプローチを選びましたか？
代替案を求める
このUIレイアウトの別のアプローチを見せてください
仕様との整合性を確認
このインターフェースはrequirements.mdで言及されたすべての機能をサポートしていますか？
 AI駆動開発で本当に大事なことKiroは仕様駆動開発のための優れたツールです。

しかし、ツールは手段であり、目的ではありませんでした。
今回の実践で学んだ最も重要なことは、以下の観点です。
1. まず「何を作りたいか」を明確にする
誰が使うのか、どんな課題を解決するのか、何ができれば成功なのか
「ツールを学ぶため」ではなく、「これを作りたいから」という明確な動機が必要
2. 要件を具体的に固める
「誰が見ても同じイメージを持てる」レベルまで
参考デザイン、カラースキーム、ユーザーフローを明示
3. Spec段階でレビューする
専門家の知見を早期に取り入れる
特にrequirements.mdとdesign.mdは必ずレビューを行う
4. 反復改善を前提にする
一発で完璧を目指さず、プロンプトで改善を重ねる
仕様駆動開発は、チームで設計をレビューしながら進めれば、一から書くよりも圧倒的に効率的なんだろうと思います。

ただし、そもそも何を作りたいかが明確でなければ、どんなツールを使ってもバイブコーディングになるということを、身をもって理解しました。
 おまけAWS re:Invent 2025のEXPOでCodeRabbit社からもらった「VIBE CODE CLEANUP SPECIALIST」というTシャツを着てワークショップをやっていました。

皮肉にも、私の実装はほとんどバイブコーディングになってしまいました。

次回は、このTシャツの名に恥じないよう、しっかり仕様を固めてから臨みます！
ではまた！AI事業本部の洲崎でした。