【図解】Kiro Specの3つのワークフローを徹底比較：Requirements-First / Design-First / Bugfix

はじめに：Kiro Specに3つのワークフローが登場

こんにちは。DXソリューション営業本部の松浦です。

Kiroの大きな特徴である「Spec（仕様駆動開発）」機能。以前の記事では、Specの基本的な考え方やバイブコーディングとの違いを紹介しました。

AWS Kiroが「仕様駆動開発(SDD)」で切り開くAI開発の確実性～バイブコーディングと何が違うの？～
Kiroの仕様駆動開発（SDD）の基本的な考え方とバイブコーディングとの違いを解説した記事です。
 

実は、Kiro Specには3つのワークフローが用意されています。2026年2月19日リリースのv0.10で「Design-First」と「Bugfix」が新たに追加され、従来の「Requirements-First」と合わせて3つのアプローチから選べるようになりました。

この記事では、この3つのワークフローの全体像と使い分けを図解で視覚的に解説します。「どのワークフローを選べばいいの？」という疑問に、判断フローチャートで即座に答えられるようにしました。

出典・参考情報

本記事は、以下のKiro公式ドキュメントおよびチェンジログの情報を基に作成しています。

• Kiro公式ドキュメント - Feature Specs（2026年2月18日更新）
• Kiro公式ドキュメント - Requirements-First Workflow（2026年2月18日更新）
• Kiro公式ドキュメント - Design-First Workflow（2026年2月18日更新）
• Kiro公式ドキュメント - Bugfix Specs（2026年2月18日更新）
• Kiro IDE Changelog v0.10（2026年2月19日リリース）

1. 3つのワークフローの全体像

まず、3つのワークフローの全体像を1つの図で把握しましょう。

flowchart TD
    Start["🚀 Specを開始"] --> Intent{何をしたい？}

    Intent -->|"新機能を作りたい
（要件が明確）"| RF["📋 Requirements-First"]
    Intent -->|"新機能を作りたい
（設計が先にある）"| DF["🏗️ Design-First"]
    Intent -->|"バグを直したい"| BF["🔧 Bugfix"]

    RF --> RF1["requirements.md
要件定義"]
    RF1 --> RF2["design.md
技術設計"]
    RF2 --> RF3["tasks.md
タスク生成"]

    DF --> DF1["design.md
技術設計"]
    DF1 --> DF2["requirements.md
要件導出"]
    DF2 --> DF3["tasks.md
タスク生成"]

    BF --> BF1["bugfix.md
バグ分析"]
    BF1 --> BF2["design.md
原因分析・修正設計"]
    BF2 --> BF3["tasks.md
修正タスク生成"]

    RF3 --> Impl["✅ 実装"]
    DF3 --> Impl
    BF3 --> Impl

    classDef reqFirst fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    classDef designFirst fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    classDef bugfix fill:#fff3e0,stroke:#ef6c00,stroke-width:2px
    classDef startEnd fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px

    class RF,RF1,RF2,RF3 reqFirst
    class DF,DF1,DF2,DF3 designFirst
    class BF,BF1,BF2,BF3 bugfix
    class Start,Impl startEnd

3つのワークフローはいずれも3つのフェーズを経て実装に至りますが、最初のフェーズが異なるのが最大の違いです。

2. どのワークフローを選ぶべきか？判断フローチャート

ワークフローの選択はKiroが自動判定するのではなく、ユーザー自身が選ぶ仕組みです。Specを開始すると、Kiroが2段階で質問してきます。

まず、Specの目的として「Build a Feature（新機能開発）」か「Fix a Bug（バグ修正）」かを選択します。

Build a Featureを選んだ場合は、続けて「Requirements（要件定義から開始）」か「Technical Design（技術設計から開始）」かを選択します。Fix a Bugを選んだ場合はそのままBugfixワークフローに進みます。

なお、Kiroの設定でデフォルトのワークフローを指定しておけば、この選択ステップをスキップすることも可能です。

では、「どのワークフローを選べばいいか分からない」という方のために、判断フローチャートを用意しました。

flowchart TD
    Q1{"何をしたい？"} -->|"バグを修正したい"| BF["🔧 Bugfix を選択"]
    Q1 -->|"新機能を作りたい"| Q2{"要件から始めたい？
設計から始めたい？"}

    Q2 -->|"作りたいものは決まっている
（要件から始めたい）"| RF["📋 Requirements-First を選択"]
    Q2 -->|"アーキテクチャや技術的な
アプローチから考えたい
（設計から始めたい）"| DF["🏗️ Design-First を選択"]

    classDef reqFirst fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    classDef designFirst fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    classDef bugfix fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

    class RF reqFirst
    class DF designFirst
    class BF bugfix

判断のポイント

• バグ修正なら迷わずBugfix：根本原因の分析とリグレッション防止が組み込まれています。
• 設計が先にあるならDesign-First：アーキテクチャ図や設計書がある場合、それを起点にすると効率的です。
• 要件が明確ならRequirements-First：「何を作るか」が決まっていて「どう作るか」はKiroに任せたい場合に最適です。
• 迷ったらRequirements-First：最も汎用的なワークフローなので、迷った場合はこちらを選びましょう。

3. 3つのワークフローの詳細比較

3つのワークフローを様々な観点で比較します。

4. シナリオ別おすすめワークフロー

具体的な開発シナリオごとに、どのワークフローが最適かを紹介します。

graph LR
    subgraph RF ["📋 Requirements-First が最適"]
        RF1["顧客要望を
機能に落とし込む"]
        RF2["新規アプリを
ゼロベースで構築"]
        RF3["PMからの要件を
実装に移す"]
    end

    subgraph DF ["🏗️ Design-First が最適"]
        DF1["既存の設計書を
Kiroに取り込む"]
        DF2["性能要件が厳しい
システム構築"]
        DF3["技術スタック指定
のプロトタイプ"]
    end

    subgraph BF ["🔧 Bugfix が最適"]
        BF1["本番環境での
緊急バグ修正"]
        BF2["過去対応時に修正で
デグレした経験"]
        BF3["複雑な原因調査が
必要なバグ"]
    end

    classDef reqFirst fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    classDef designFirst fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    classDef bugfix fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

    class RF1,RF2,RF3 reqFirst
    class DF1,DF2,DF3 designFirst
    class BF1,BF2,BF3 bugfix

シナリオ1：顧客からの機能要望を実装する

おすすめ：Requirements-First

顧客から「こういう機能が欲しい」という要望を受けた場合、その要望をプロンプトに入力するだけで、EARS形式の構造化された要件に変換されます。要件を顧客と確認した後、設計と実装に進めます。

シナリオ2：AWSサービスを組み合わせたシステム構築

おすすめ：Design-First（High Level Design）

「API Gateway + Lambda + DynamoDBで通知システムを構築したい」のように、使用するサービスが決まっている場合はDesign-Firstが最適です。アーキテクチャを先に固めてから、実現可能な要件を導出できます。

シナリオ3：本番環境の緊急バグ修正

おすすめ：Bugfix

本番環境でバグが発生した場合、Bugfix Specを使うことで「何が壊れているか」「どう直すべきか」「何を壊してはいけないか」を明確にした上で、安全に修正できます。リグレッションテストも自動生成されるため、修正による二次被害を防げます。

シナリオ4：アルゴリズムの実装

おすすめ：Design-First（Low Level Design）

レートリミッターやキャッシュ戦略など、特定のアルゴリズムを実装したい場合は、Low Level Designで擬似コードやインターフェース定義から始めると効率的です。

まとめ：ワークフローを使い分けてSpec駆動開発を加速

この記事では、Kiro Specの3つのワークフロー（Requirements-First、Design-First、Bugfix）の全体像と使い分けを図解で解説しました。

graph LR
    A["要件が明確"] -->|Requirements-First| G["✅ 実装"]
    B["設計が先にある"] -->|Design-First| G
    C["バグを直したい"] -->|Bugfix| G

    classDef reqFirst fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    classDef designFirst fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    classDef bugfix fill:#fff3e0,stroke:#ef6c00,stroke-width:2px
    classDef goal fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px

    class A reqFirst
    class B designFirst
    class C bugfix
    class G goal

ポイントのおさらい

1. Requirements-First：「何を作るか」が明確な時に。要件からスタートし、設計はKiroに任せる。
2. Design-First：「どう作るか」が決まっている時に。設計からスタートし、実現可能な要件を導出する。
3. Bugfix：バグ修正に。根本原因の分析とリグレッション防止が組み込まれた安全な修正フロー。

v0.10で追加されたDesign-FirstとBugfixにより、Kiro Specはより多くの開発シナリオに対応できるようになりました。状況に応じて最適なワークフローを選び、Spec駆動開発を活用していきましょう。

 ↓QESではKiroについて積極的に情報発信していきますので是非ご覧ください！

QES Kiro ブログ一覧
 QESのエンジニアがKiroの基本的な使い方から実践的なTipsを発信！
 

もし「このサービスについて知りたい」「AWS環境の構築、移行」などのリクエストがございましたら、弊社お問合せフォームまでお気軽にご連絡ください。複雑な内容に関するお問い合わせの場合には直接営業からご連絡を差し上げます。また、よろしければ以下のリンクもご覧ください！
＜QES関連ソリューション/ブログ＞

＜QESが参画しているAWSのセキュリティ推進コンソーシアムがホワイトペーパーを公開しました＞

※Amazon Web Services、"Powered by Amazon Web Services"ロゴ、およびブログで使用されるその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。