Kiro は、プロンプトから詳細な Spec を作成し、コード、ドキュメント、テストの作成まで支援するエージェント型のコーディングサービスです。

AI コーディングツールを使うと、プロンプトを入力して動くアプリケーションを素早く作成できます。一方で、本番環境で利用するアプリケーションとして仕上げるには、要件、設計、実装方針を整理することが重要です。

Kiro の Spec は、機能開発に必要な要件、設計、実装タスクをドキュメントとして整理し、実装に進むためのワークフローを提供します。

Vibe coding と Spec-driven development

Kiro 公式ブログでは、プロンプトを重ねて動くアプリケーションを作る体験について触れたうえで、本番利用に向けてはさらに多くの整理が必要になると説明されています。

たとえば、次のような点です。

  • モデルがどのような前提で実装したのか
  • 実装上の判断がドキュメントとして残っているか
  • 要件が明確になっているか
  • アプリケーションが要件を満たしているか確認できるか
  • システムがどのように設計されているか理解できるか

Kiro は vibe coding にも対応しつつ、Spec や Hooks などの機能によって、プロトタイプを本番システムに近づけるための開発体験を提供します。

Kiro の Spec とは

Kiro の Feature Specs は、アイデアから実装までを明確なフェーズで進めるための機能です。

公式ドキュメントでは、Feature Specs の主な利点として、以下が挙げられています。

  • アイデアから実装までを明確なフェーズで進められること
  • 開発の開始地点に合わせてワークフローを選べること
  • 要件ドキュメントや設計ドキュメントを自動生成できること
  • 個別の実装タスクとして進捗を追跡できること
  • プロダクトとエンジニアリングの認識合わせに使える共有成果物を作れること

Feature Specs は、複数の実装タスクを含む複雑な機能、チームでのドキュメント共有が必要なプロジェクト、要件や設計を反復的に整理したい開発に適しています。

Feature Specs のワークフロー

Kiro の Feature Specs には、主に次の 2 つのワークフローがあります。

  • Requirements-First：作りたいシステムの振る舞いを要件として整理し、その後に技術設計と実装タスクを生成する流れ
  • Design-First：技術設計やアーキテクチャを先に整理し、その後に要件と実装タスクを導き出す流れ

この記事では、Requirements-First の流れを中心に紹介します。

Requirements
    ↓
Design
    ↓
Tasks
    ↓
Implementation

Requirements-First は、システムにどのような振る舞いが必要かを先に整理し、その内容をもとに技術設計と実装タスクを生成するワークフローです。

Requirements-First の流れ

ステップ 1：Requirements Phase

Requirements-First では、まず Kiro のパネルまたはコマンドパレットから Feature Spec を作成し、Requirements-First workflow を選択します。

Requirements Phase では、Kiro が入力されたプロンプトをもとに requirements.md を生成します。

requirements.md には、主に次の内容が含まれます。

  • 明確な受け入れ条件を含むユーザーストーリー
  • EARS 形式のシステム動作
  • 機能要件
  • エッジケースやエラーハンドリング

EARS 形式では、たとえば次のように要件を表現します。

WHEN [condition/event]
THE SYSTEM SHALL [expected behavior]

この形式により、要件を明確でテスト可能な形に整理できます。

ステップ 2：Design Phase

要件を確認した後、Kiro は design.md を生成します。

design.md には、要件をどのように実装するかが整理されます。

主に次の内容が含まれます。

  • システムアーキテクチャとコンポーネント
  • 相互作用を示すシーケンス図
  • データモデルとインターフェース
  • 技術スタックの推奨
  • エラーハンドリングの方針
  • テスト戦略

このフェーズでは、技術的なアプローチ、アーキテクチャ上の判断、技術選定、設計の実現可能性を確認します。

ステップ 3：Tasks Phase

設計を確認した後、Kiro は tasks.md を生成します。

tasks.md には、実装に必要なタスクが整理されます。

主に次の内容が含まれます。

  • 個別に追跡可能な実装タスク
  • 明確な説明と期待される結果
  • タスク間の依存関係
  • 必須タスクと任意タスク

タスクは個別に実行することも、すべてのタスクをまとめて実行することもできます。

Spec ファイルを使った実装

Kiro は、requirements.md、design.md、tasks.md を作成します。

  • requirements.md：ユーザーストーリーや受け入れ条件を含む機能の詳細
  • design.md：アーキテクチャ、技術上の判断、構成
  • tasks.md：順番に実行できる開発フェーズとタスク

Kiro は実装を開始する際、会話履歴だけから要件を推測するのではなく、これらの Spec を参照して作業を進めます。

また、Spec はチャットから #spec コンテキストプロバイダーで参照できます。Kiro は requirements.md、design.md、tasks.md を会話コンテキストに含め、ドキュメント化された仕様に沿った応答を行います。

Vibe セッションと Spec セッションの使い分け

Kiro では、Vibe セッションと Spec セッションを切り替えて利用できます。

Vibe セッション Spec セッション
概要 Q&A を中心とした対話型セッション 複雑な開発タスクを構造化して進めるセッション
向いている用途 コードに関する質問、説明、概念理解、探索的なコーディング 複雑な機能開発、アプリケーション開発、大きなリファクタリング
進め方 会話を中心に柔軟に進める 要件と実装詳細を文書化しながら段階的に進める
ドキュメント 正式な仕様プロセスを通さずに進める 要件、設計、タスクを整理したドキュメントを作成する
チーム利用 素早い確認や学習に適している 複数メンバーが実装計画を理解し、仕様に対する進捗を追跡する場面に適している

Vibe セッションは、すばやい質問、コードの説明、概念理解、探索的なコーディングに適しています。

Spec セッションは、複雑な機能、アプリケーション全体、または計画的な実行が必要な大きなリファクタリングに適しています。

実際の画面で見る Spec のワークフロー

以下は、Kiro の Spec を利用した画面例です。Requirements、Design、Tasks の流れで、機能開発に必要な情報を整理しながら実装へ進めます。

まとめ

Kiro の Spec は、機能開発を要件、設計、タスクに整理し、実装まで進めるためのワークフローです。

Requirements-First では、まずシステムの振る舞いを要件として整理し、その後に技術設計と実装タスクを生成します。

Spec セッションは、複雑な開発タスク、複数の実装タスクを含む機能、チームで共有するドキュメントが必要な開発に適しています。

一方、Vibe セッションは、すばやい質問、コードの説明、概念理解、探索的なコーディングに適しています。

Kiro を利用する際は、作業の内容に応じて Vibe セッションと Spec セッションを使い分けることで、要件、設計、実装タスクを整理しながら開発を進められます。