Kiroについて、Spec駆動開発について、今一度簡単に振り返る
びーぐるです🐶
公式Discordによれば、Kiroは現在Waiting Listから順次招待されているようです。
プレビューが始まってから3週間ほど経過していますので、待たれていた方には朗報かと思います。
利用者が大きく増えることでKiroの理念であるSpec駆動開発が、AIコーディング界の主流となるかもしれません。
本記事では改めてKiroとは、Spec駆動開発とは何なのかを少しだけ振り返ってみたいと思います。
（本記事は何度か加筆修正を行う予定です）
更新履歴
- 2025/08/05 投稿しました
- 2025/08/07 読みにくい部分の表記を変更しました。現状に合わせて内容を一部修正しました。
- 2025/08/13 現状に合わせて内容を更新しました。
- 2025/08/31 トピックのカテゴリを更新しました。
Kiroとは
KiroはAWSが開発した、AIエージェントと連携したVSCodeベースのIDEです。
"The AI IDE for prototype to production"(プロトタイプからプロダクトまで使えるAI IDE)と称しています。
Cursorライクな従来型のVibe Codingもできますが、目玉としてSpec駆動開発、または仕様(書)駆動開発などと呼ばれている手法を採用しており、これがAIコーディング界に新たな風を吹き込んでいます。
モデルとしてClaude Sonnet 4.0, 3.7が利用可能です。
Spec駆動開発とは
その名の通り、Spec(仕様)を固めてからコーディングに取り掛かる開発手法です。
具体的な挙動としては、AIは人間の要求を分析し要件定義・設計・タスク分割の3つのドキュメントを生成してからコーディングに取り掛かるという流れになります。
AIエージェントによるコーディングの際はこれらのドキュメントが常に参照されることとなり、仕様を無視した実装による手戻り等を極力防ぐことができます。
タスクの途中であってもAIに「何をどのように」つくるかを明確にしている状態をキープできます。
現在流行しているAIコーディングでは「AIとの対話により、アイデアを直接AIにおまかせで実装するスピーディーな開発」、いわばVibe Codingの進化系のようなものが主流です。
しかし、開発を進めていくと、コードの品質の保持の難しさ、ドキュメント不在によるさまざまな弊害、当初の目的から逸脱し全体が肥大化、などの課題が出てきます。
Spec駆動開発であれば、これらの課題を少しは軽減できるのではないかと考えられています。
KiroのSpec駆動開発
KiroのSpec駆動開発では、Specsと呼ばれるドキュメントをAIと対話しながら順に生成させていきます。
- requirements.md（要件定義ファイル）
- design.md（設計ファイル）
- tasks.md（タスクリストファイル）
AIは人間との対話によりドキュメントを生成し、要望に従い都度変更を加え、最終的に人間が承認することで該当のドキュメントが確定し、次のドキュメントの作成フェーズへ移行します。
当然、ドキュメントは前のドキュメントを参照しながら作成されますので、それぞれ要件定義に沿った設計、設計に沿ったタスク分割に落とし込まれます。
また、Specsとは別にSteeringと呼ばれるドキュメントを作成することもできます。
プロジェクト内で守るべき独自のルール・制約・方針等を自然言語で記述することでき、AIエージェントはSpecsの他Steeringに配置されたドキュメントを常に参照して行動します。
既存プロジェクトにKiroを導入した場合、エージェントにSteeringファイルの作成を依頼できます。
ここまで完成したら、AIエージェントに実装を依頼します。
tasks.mdを見てみると、⚡️Start task と書かれている箇所があり、ここをクリックすると各タスクの実装が始まります。
あとは順に押していくだけで、AIエージェントが実装を進めていきます。これだけでアプリケーションが完成します。
ただ、モデルが最高でもClaude Sonnet 4.0なので…モデルのコーディング性能が低く、現実的にはエージェントに完走させるのは難しいです。
あとはプレビュー中はデイリーリミットが厳しく、途中でリミットに到達します。
タスクの数と重さ次第ですが、2～5日かけて実装を完成させることになるかと思います。
その他にもMCPサーバーに対応、及びイベントドリブンなAgent Hooksという機能があり、AIエージェントを補助できます。
実際の様子
とても簡単ですので実際にSpecsを作ってみましょう。
定番のテトリスのSpecsを作成します。それだけでは退屈なので
- 1ブロック、2ブロック、3ブロックも落ちてくる。
- Nextブロックをスキップできる（回数制限あり、回数はブロックを消すと回復する）
という仕様を追加してみます。
Specモードを選んで
要求を入力します。
本来はLLMと相談する等、事前にある程度固めたもののほうが良いとは思いますが、今回はSpecsを生成することが目的なので簡素に入力します。
ブラウザで動作するテトリスを作成したいです。日本語で要件定義書を作成してください。
ちょっと待つとrequirements.mdが生成されます。EARS表記法という5W1Hをベースにした記述方式で記載されています。
テトリスに必要な要件は網羅されているようです。
ここで、追加要求の注文を行います（もちろん最初に入力しても良いです）。
- 降下ブロックとしてモノミノ・ドミノ・トリオミノを追加してほしいです
- プレビューにあるブロックをスキップする機能が欲しいです。
仕様としては4スタックまで貯めることができる・2Line消去ごとに1スタック回復する
ちょっと待つと、requirements.mdが更新され、追加の要求も反映されているようです。
今回は仕様に不足があったので修正を促します。
トリオミノブロックに関して、L字型のものしか定義されていないようです。
3マスの直線のトリオミノブロックも追加してください
今度はしっかり修正されましたので承認を押すと、次に設計書であるdesign.mdが生成されます。
JavaScriptでクラス使わないでほしいなぁとか、アルゴリズム本当に正しいかな、と思うことはいくつかありますが今回は実際にコーディングまではいかないのでこのままにします。
設計の時点で使ってほしい言語・技術やライブラリ・フレームワーク等があればこのフェーズで注文をつけましょう。
ルールの設定やコーディング方針は、ここで言うべきかSteeringに書くべきか、ちょっと迷うところです。要検証。
承認を押すと、タスクリストであるtasks.mdが生成されます。
個人的にはタスクの粒度が粗い気がするのですが、デイリーリミットの件があるので許容します。
承認を押して完成です。
実際のSpecs
tasks.mdを開いてstart taskを押すと、コーディングが始まります。
Spec駆動開発の流行の兆し
Spec駆動開発の影響は、Claude Codeにも波及しています。
KiroでSpecs を作成し、コーディングをClaude Codeに依頼するという使い方
Claude Code自身でSpec駆動開発を行う方法
claude-code-spec-workflow
他にもGemini CLIやCursorでSpec駆動開発を試みている記事を見かけました。
特にCursorではSpec駆動開発を明示的に指示しやすく、相性が良さそうです。
雑感とまとめ
これを書いた2025/08/05では以下のように言っていました。
肝心のKiro自身に関しては、飛ぶ鳥を落とす勢いでデビューしたものの、時間が経過するにつれて話題になることも少なくなりました。
正直Waiting Listの時期が長過ぎました。Kiroの新規利用者が増えないのでは、虎の子のSpec駆動開発をもってしてもお手上げです。
Waiting Listの解除によりKiroを誰でも試せるようになれば、再び注目を集める日が来るかもしれません。
ここから1週間後にはWaiting Listからの招待がかなりのスピードで行われているようで、Kiroの話題が再び増えてきました！
KiroによりAIコーディング界に具現化されたSpec駆動開発自体は、間違いなくAIコーディング界の主流となるポテンシャルを秘めています。
AWSのVPであるMarc Brooker氏は、Kiroの開発ブログの中でこう述べています。
A specification is a kind of (version controlled, human-readable) super prompt.
→仕様書 (Specs) とはバージョン管理され、人間が読めるスーパープロンプトの一種です。
「人間が理解できる形で記述された、プロジェクトの概要を包括的に記載したドキュメントが、そのままAIへの指示書として、長期記憶できるガイドラインとして機能する。当然、人間がプロジェクト自体を理解する助けにもなる。」
ここにSpec駆動開発の本質があります。
この本質の価値・魅力に気づいた人たちが(たとえKiroとは別の形であっても)Spec駆動開発を取り入れ、啓蒙していくことで、AIコーディング界のデファクトスタンダードとなる日が来るかもしれません。
Discussion