AWS チームの加藤です。今回は、Kiro の1,000クレジットを手に入れたので、同じ題材（15パズル）を使って Spec session と Vibe session の違いを試してみました。

先に結論を書くと、Spec は設計重視、Vibe は即実装が得意だと感じました。

この記事のポイント

Spec モードと Vibe モードの違い
15パズルを題材にした比較実験
各方式のメリット・デメリット

15パズルを題材にした理由

15パズルを選んだ理由は、次の3点です。

ルールが明確で要件を定義しやすい
UI とロジックの両方があり、題材としてちょうどよい
過去に Gemini / ChatGPT でも作ったことがあり、難易度感が把握しやすい

「簡単すぎず、重すぎない」ので、Kiro の実験題材として扱いやすいと感じました。

1. 今回の方針（Spec / Vibe の違いを見る）

今回注目したかったのは、単純な「作れる / 作れない」ではなく、進め方の違いです。

Spec session はどこまで構造化されるのか
Vibe session と比べて、何が残りやすいのか
小さめの題材で使ったときに、どんな体感差があるのか

Kiro の公式ドキュメントでも、Vibe / Spec の違いが整理されています（https://kiro.dev/docs/chat/vibe/）。

2. Spec session で始める

まずは Spec session で進めました。今回は、15パズルのWebアプリを作る前提で、最初に requirements / design / tasks を作ってもらう流れにしています。

初期プロンプトは以下のようにしました。

15パズル（4x4スライドパズル）のWebアプリを作りたいです。
今回は比較実験のため、まずは Spec session として進めたいです。

要件:
- 4x4の盤面（1〜15のタイル + 空白1つ）
- 空白に隣接するタイルのみクリックで移動可能
- ランダムシャッフル
- クリア判定
- 手数表示
- リスタート/再シャッフル
- UIはシンプルでよい
- まずはブラウザで動けばよい（PC前提）

制約:
- 実装はシンプルに
- 保守しやすい構成
- 比較しやすいように過剰な機能は入れない

まず requirements / design / tasks を作成してください。
曖昧な点があれば先に質問してください。

3. Kiroからの確認質問

Kiroからは、すぐに実装に入るのではなく、先に確認が返ってきました。

技術スタック（バニラJSか、React/Vueか）
シャッフル時に「必ず解ける配置」を保証するか

15パズルではこの2点が実装内容に直結するので、この確認はかなり良かったです。この時点で、Spec session の「先に定義を固める感じ」が出ていました。

4. 条件をそろえるための返答

ここで前提を明示して、条件を固定しました。

確認ありがとうございます。条件を揃えたいです。

技術スタック:
- HTML / CSS / JavaScript（バニラ）
- 単一ページ（ビルド不要）
- 外部ライブラリなし

シャッフルの解決可能性保証:
- 必ず解ける配置のみ生成

追加前提:
- 4x4固定
- クリック操作のみ
- UIはシンプル（アニメーション不要）
- 手数表示あり
- クリア判定あり
- 再シャッフルあり
- PCブラウザ前提
- ロジックの分かりやすさ優先

まず requirements.md を作成してください。

5. requirements.md の出力

Kiroが生成した requirements.md は、非常に丁寧に作られていました。良かった点はこのあたりです。

User Stories 形式で整理されている
各項目に Acceptance Criteria が付いている
15パズル特有の論点（解けるシャッフル、クリア後の操作可否）も入っている

この時点でまだ動くものはありませんが、「何を作るか」が明文化されるのはSpec sessionの強みだと感じました。

6. Spec / Vibe の違い（今回触ってみた感触）

ここでは、今回の体感 + Kiro公式ドキュメントの説明をあわせて整理しています。

Spec session の特徴（今回の体感）

要件 → 設計 → タスクの順で進めやすい
「何を作るか / どう作るか」が残る
後から見返しやすい、共有しやすい

Vibe session の特徴（Kiro docs ベース）

会話中心で、柔軟に進めやすい
質問・試作・探索に向いている
形式的な仕様化を省いて進められる

Kiro 公式でも、VibeはQ&A中心の柔軟なセッション、Specは複雑な開発向けの構造化セッションとして整理されています。このあと実際のログを見ると、こうした違いがどう出るかがさらに分かりやすくなります。

7. design.md / tasks.md の作成

このあと、design.md → tasks.md と進めました。

最終的には、次のような形に整理されました。

design.md

index.html / style.css / puzzle.js の3ファイル構成
puzzle.js に盤面ロジック（純粋関数）を集約
index.html 側で状態管理 / DOM更新 / イベント配線

tasks.md

実装タスクを段階的に分割
ロジック → UI → 初期化 → 統合 → 手動確認の順で進行

このあと tasks.md に沿って実装を進め、Spec session 側も最終的に 15パズルとして動作確認まで完了しました。

8. Vibe session を試してみる

次に、同じ15パズルを Vibe session でも試してみました。

こちらはSpecのように requirements.md / design.md / tasks.md を先に作るのではなく、最初に条件だけそろえて、会話ベースで進める形にしました。

Vibe session に伝えた内容

15パズル（4x4スライドパズル）のWebアプリを作ってください。
今回は比較実験のため、以下の条件を固定して進めてください。

固定条件:
- HTML / CSS / JavaScript（バニラ）
- 単一ページ（ビルド不要）
- 外部ライブラリなし
- 4x4固定
- クリック操作のみ（キーボード操作なし）
- ランダムシャッフルは必ず解ける配置を生成
- 手数表示あり
- クリア判定あり
- 再シャッフルあり
- UIはシンプル（アニメーション不要）
- PCブラウザ前提
- ロジックの分かりやすさ優先

まず、実装前に以下を短く出してください:
1) 要件の要約（箇条書き）
2) 実装方針（ロジック/UIの分離方針）
3) 実装ステップ（3〜6ステップ）
その後、実装を進めてください。