仕様駆動開発をKiroで実践する手順

AIに実装を任せるとき、何を作るかが曖昧なままだと出力も曖昧になります。仕様を先に固めてから実装へ進む仕様駆動開発（SDD）が注目されているのはそのためで、AWSのKiroはこの流れをツール側で形式化したものです。

この記事では、Kiroのspecが生成する3つのファイルの役割と回し方、導入手順、steering・hooksによる運用、2026年8月時点の料金を整理し、そのうえで受託開発に持ち込むときに決めておくべきことを解説します。

Kiroにおける仕様駆動開発（SDD）とは

Kiroは、仕様駆動開発を製品の中心に据えた開発ツールです。まずKiroそのものの位置づけと、仕様を扱う単位であるspec、そしてバイブコーディングとの違いを整理します。

Kiroの概要：IDE・CLI・Webを持つエージェント型AI

Kiroの公式FAQでは、KiroはIDE・CLI・Webインターフェースを持つエージェント型AI（agentic AI）と説明されています。プロンプトを詳細なspecへ変換し、そこから動くコード・ドキュメント・テストを作る、という流れが製品の軸です。

IDEはCode OSSをベースにしており、VS Codeの設定・テーマ・Open VSX互換プラグインを移行できます。サインインはGitHub・Google・AWS Builder ID・AWS IAM Identity Centerに対応し、AWSアカウントは必要ありません。

specの位置づけ：思いつきを構造化文書へ変える仕組み

Kiroでは仕様を spec と呼び、開発プロセスを形式化した構造化成果物として扱います。公式ドキュメントでは、高レベルのアイデアを詳細な実装計画へ変換するための体系的なアプローチと説明されています。

specは機能追加（Feature Specs）だけでなくバグ修正（Bugfix Specs）にも使えます。ポイントは、思いつきをそのまま実装させるのではなく、いったん構造化された文書に落としてから実装へ渡す、という順序が固定されていることです。

バイブコーディングとの違い：実装の前に合意物を作るかどうか

バイブコーディングは、プロンプトから直接実装へ進み、動くものを見ながら方向を調整するスタイルです。対してKiroの仕様駆動開発は、実装の前にrequirements.md・design.md・tasks.mdという合意物を作ります。

最初のコードが出るまでの速さでは、バイブコーディングに分があります。一方、複数人で開発する場合やお客様の検収があるシステム開発では、判断の根拠が文書として残る仕様駆動開発のほうが後工程が安定します。プロトタイプはバイブコーディング、本実装はspec、という使い分けが現実的です。

Kiroのspecが生成する3つのファイル

specを作ると、次の3ファイルが成果物として生成されます。

※バグ修正の場合は requirements.md の代わりに bugfix.md が使われます。

requirements.md：何を作るかを固める

ユーザーストーリーと受け入れ基準を書きます。公式のチュートリアルにあるとおり、Kiroは要件をEARS記法（Easy Approach to Requirements Syntax）で構造化します。「WHEN（条件）／THE SYSTEM SHALL（期待する振る舞い）」のように条件と応答を対にして書く記法のため、散文の要件よりレビューがしやすくなります。

ここが曖昧なまま次へ進むと、後続の設計と実装がまとめてぶれます。AIに書かせる場合でも、受け入れ基準が人の目で判断できる粒度になっているかは確認してください。

design.md：どう作るかを決める

技術アーキテクチャ、シーケンス図、実装上の検討事項を書きます。requirements.mdを入力にして生成されるため、上流が固まっていないと設計も揺れます。

tasks.md：作業を追跡可能にする

実装タスクを個別に追跡できる形へ分解します。進捗がリアルタイムで更新されるので、どこまで終わったかが構造として見えます。公式ドキュメントによると、Kiroはタスク間の依存関係をグラフとして解析し、依存のないタスク同士をまとめて並列に実行します。

Kiroで仕様駆動開発を始める導入手順

インストールからspec作成までの流れを、IDEを例に整理します。手順の詳細は公式のインストールガイドにあります。

Kiroをインストールしてサインインする

公式サイトからOSに合ったインストーラを取得してインストールします。起動後、GitHub・Google・AWS Builder ID・AWS IAM Identity Centerのいずれかでサインインすれば準備完了です。前述のとおりAWSアカウントは不要で、後述する無料プランの範囲で試せます。

steeringでプロジェクトの前提を共有する

プロジェクトを開いたら、最初にsteeringファイルを用意します。Kiroパネルの「Generate Steering Docs」を実行すると、リポジトリを解析して、プロダクトの目的（product.md）・技術スタック（tech.md）・プロジェクト構造（structure.md）をまとめた基礎ファイルが生成されます。specの精度はここで渡す前提情報に左右されるため、spec作成より先に済ませておくのが定石です。

specを作成して3ファイルをレビューする

チャット画面のSpecボタンから、作りたい機能を自然言語で記述します。要件、設計、タスクの順に生成されるので、各フェーズで内容を確認してから次へ進みます。tasks.mdが完成したら、タスク単位で実行し、ステータスの更新で進捗を追います。

Kiroで仕様駆動開発を回す3段階のワークフロー

Kiroのワークフローは3段階です。

1. 要件（またはバグ）の分析：何を作る／直すかを定義する
2. 設計：技術アーキテクチャと実装アプローチを作成する
3. タスク：実行可能な単位へ分解し、進捗を追跡する

各段階の出力が次の段階の入力になります。したがって、途中で人がレビューを挟まないと、上流の誤りはそのまま下流へ流れます。

2026年8月時点のKiroでは、この基本形に加えて進め方を選べます。要件から始めて設計を導くRequirements-Firstと、アーキテクチャや擬似コードから始めて要件を導くDesign-Firstの2つがあり、内容が固まっている機能向けには、冒頭の確認質問に答えるだけで承認ゲートを挟まずに3ファイルを生成するQuick Specも用意されています。承認を省くほど速くなる代わりに、上流の誤りを止める機会は減る、という関係です。

KDDIアイレットのAIDD スキームでは、これを「実装の3原則」のひとつ「段階的レビュー」として明文化しています。AIの生成結果は小まめに人がレビューし、各ステップで承認を得たうえで次へ進む。判断基準・承認フロー・責任者は事前に決めておく。Kiroの3段階はこの考え方とそのまま噛み合います。

steeringとhooksで仕様駆動開発を安定させる

specは1回作って終わりの成果物ではありません。プロジェクトの前提知識を渡すsteeringと、イベント駆動の自動化であるhooksを組み合わせると、spec単体では埋まらない部分を運用でカバーできます。

steering：プロジェクトの前提知識を常駐させる

steeringは、Markdownファイルを通じてプロジェクトの規約・ライブラリ・標準をKiroに継続的に伝える仕組みです。チャットのたびに前提を説明し直さなくても、生成結果が既存のパターンに揃います。プロジェクト単位で効かせる .kiro/steering/ と、全ワークスペースに効かせる ~/.kiro/steering/ があり、衝突した場合はプロジェクト側が優先されます。

読み込み方法は、常時読み込むalways、対象ファイルに応じて読み込むfileMatch、明示的に指定したときだけ読むmanualの3モードから選べます。AGENTS.md形式にも対応しています。specの品質は前提情報の質に左右されるため、steeringが薄いままspecを量産しない、という順序を守るのが現場でのコツです。

hooks：イベントを起点に検査や更新を自動化する

hooksは、ファイル保存・ツール実行・タスク完了といったイベントを起点に、シェルコマンドまたはエージェントへの指示を自動実行する仕組みです。.kiro/hooks/ にJSONで置くと、トリガーとマッチャに応じて動きます。保存時のlint実行、ソース追加時のテスト雛形生成、エージェントが変更を確定する前の検証などを仕込めます。

仕様駆動開発の文脈で効くのは、specタスクの完了（PostTaskExec）を起点にした自動化です。実装が終わるたびに関連ドキュメントの更新や検査を走らせるよう設定しておくと、仕様と実装のズレを人の記憶に頼らず検出しやすくなります。

Kiroの料金プラン（2026年8月時点）

Kiroはクレジット制のサブスクリプションです。公式の料金ページには、2026年8月時点で個人向けに次の5プランが提示されています（チーム向けは問い合わせベースの提供です）。

クレジットはプロンプト処理の作業量に応じて消費される単位で、公式の説明では、specタスクの実行のような複雑な処理は1クレジットを超えることが多いとされています。選ぶモデルによっても消費量は変わります。有料プランでは1クレジット0.04ドルで追加購入できます。表示価格は税抜で、日本の請求先住所で契約する場合は消費税が別途かかります。料金は改定されるため、契約前に公式ページで最新を確認してください。

受託開発でKiroを使うときに決めておくこと

ここからは、自社プロダクト開発を前提にした解説では触れられない部分です。

まず、生成された3ファイルのどれをお客様との合意物にするか。AIが出した requirements.md は、そのままでは社内の作業メモです。どこまでを合意した仕様とみなすかを先に決めておかないと、tasks.md まで進んだあとの手戻りが大きくなります。

AIDD スキームでは、成果物を性質で2つに分けています。

Kiroの requirements.md はInput側、design.md と tasks.md は生成の過程でOutput側の性質を帯びます。この線引きを最初に引いておくと、検収時に「どの文書を根拠にするか」で揉めません。

もうひとつが、渡す材料の品質です。AIDD スキームでは、インプットの整理度合いで進め方を切り替えます。80%を超えていれば要件定義フェーズを必須として正式に要件定義ドキュメントを作り、30%を超え80%以下ならインプット前整理フェーズを挟んでから再評価、30%程度以下ならAIDDの適用見送りや限定適用を検討する、という段取りです。specの精度は渡した材料の精度を超えないため、Kiroを入れる前に手元の資料がどの状態にあるかを見立てておくと、着地が早くなります。要件定義の工程設計はAIDD 要件定義で支援しています。

Kiroの仕様駆動開発の限界と注意点

導入すれば品質が上がる、という道具ではありません。運用を設計する前に、つまずきやすい点を3つ押さえておきます。

着手までの時間：承認を挟む分だけ初速は落ちる

各フェーズでレビューと承認を挟む構造のため、プロンプトから直接実装するスタイルと比べると、最初のコードが出るまでは遅くなります。使い捨てのスクリプトや小さな検証までspecにするとオーバーヘッドが勝つので、specを使う対象と、Quick Specや通常のチャットで済ませる対象を、チームで線引きしておくことをおすすめします。

仕様の精度：入力が曖昧なら3ファイルも曖昧になる

specは入力から生成されるため、要件の言語化が浅いままだと、EARS記法で体裁が整っていても中身の薄い要件が量産されます。書式が整っていることと、内容が正しいことは別です。前述したインプット品質の見立てと、受け入れ基準を人が判断できる粒度に保つレビューが、この問題への実務的な対処になります。

仕様と実装の乖離：作ったspecは放置すると古くなる

実装が進むと、途中で下した判断がspecに反映されないまま、文書と実体のズレが広がります。hooksによる更新の自動化や、レビュー時にspecと実装を突き合わせる運用を先に決めておくと、乖離を早い段階で検出できます。ズレを検知する仕組みの考え方はAIエージェントのハーネスと仕様の品質管理で扱っています。

Kiroの仕様駆動開発に関するよくある質問

Kiroの仕様駆動開発について検索されることの多い質問と回答をまとめました。

Kiroの仕様駆動開発は、他のSDDツールと何が違いますか？

Kiroはspecという単位で requirements.md / design.md / tasks.md の3ファイルを生成し、要件から設計、タスクまでを一続きの成果物として扱います。ツールごとの比較は仕様駆動開発（SDD）とはで整理しています。

Kiroの仕様駆動開発は無料で試せますか？

2026年8月時点では、月50クレジットのKiro Freeプランで試せます。specタスクの実行は1クレジットを超えることが多いため、継続的に使うなら有料プランが前提です。

specはバグ修正にも使えますか？

使えます。その場合は requirements.md の代わりに bugfix.md が生成され、以降は同じ3段階のワークフローで進みます。

AIに全部書かせてよいですか？

生成そのものは任せてかまいませんが、各段階で人のレビューを挟む前提です。段階の出力が次の入力になる構造のため、上流を承認せずに進めると誤りが下流へ増幅します。

導入前に何を準備すればよいですか？

手元の資料が読み取れる形になっているかを確認してください。仕様書がテキストとして構造化されていれば、specの初稿の精度が上がります。開発プロセス全体の考え方はAI駆動開発（AIDD）とはで扱っています。

まとめ

Kiroの仕様駆動開発は、requirements.md・design.md・tasks.md の3ファイルと、要件→設計→タスクの3段階で構成されます。各段階の出力が次の入力になるため、人のレビューをどこに挟むかを決めておくことが実質的な導入設計になります。steeringで前提を渡し、hooksで検査と更新を自動化すれば、specを作って終わりにしない運用が組めます。

受託開発で使うなら、生成された文書のどれをお客様との合意物とするかを先に決めておくこと。そして、specの精度は渡す材料の精度を超えないという前提で、資料の整備状況から確認することをおすすめします。なお、ここで挙げた進め方や判断基準はお客様の状況に応じて調整するものであり、同じ手順で同じ効果が出ることを保証するものではありません。

仕様駆動開発を実際のプロジェクト体制へ落とし込みたい方は、お気軽にKDDIアイレットへお問い合わせください。