はじめに
元々AWSがAIを使った統合開発環境をリリースしたという話は耳にしていて、AWS re:Inventに参加してKiroのクレジットをもらったことと、Keynoteなどで紹介されているところを見て仕様駆動開発というものが気になり導入してみることにした。
Kiroとは
公式サイトより翻訳して引用
Kiroは、IDE と CLI を備えたエージェント型AIで、仕様駆動型（spec-driven）開発により、プロトタイプから本番環境への移行を支援します。
シンプルな作業から複雑なタスクまで、Kiroはあなたのそばで働き、プロンプトを詳細な仕様へ、そして動作するコード、ドキュメント、テストへと変換します。これにより、あなたが構築するものは意図どおりの成果となり、チームとすぐに共有できる状態になります。
Kiroのエージェントは、難易度の高い問題の解決や、ドキュメント生成、単体テスト作成といったタスクの自動化を支援します。
Kiroを使えば、常にあなたが主導権を握りながら、プロトタイプのその先を構築することができます。
仕様駆動開発というものを特徴としたAIエージェントを使えるIDEという感じ。似たものでいうとCursorが近いと思われる。ユーザーからの要望をすぐにコードに起こすのではなく、まず仕様に起こしてユーザーと合意形成してからコードを作成することで手戻りなく実装することができる。こちらも公式サイトからの翻訳を載せておく。
仕様駆動型開発は、vibe coding の楽しさをそのままにしつつ、その限界を克服する開発手法です。
vibe coding では、複雑なタスクや大規模なコードベースの上に構築する際に、過度なガイダンスが必要になることがあります。また、文脈を誤って解釈するケースもあります。さらに、vibe coding でタスクを実装していく過程では、途中で下した判断や設計の意図を追跡・記録してチームと共有することが難しいという課題もあります。
一方、仕様駆動型開発では、コードを書き始める前に、Kiro と協働して要件、システム設計、実装タスクを明確に定義します。このアプローチにより、思考過程や実装上の判断が明示的にドキュメント化され、Kiro はより複雑なタスクでも、少ないやり取り（shots）で実装できるようになります。
導入方法
今回はWindows 11のPCに導入した。まず公式サイトにアクセスし、右上の「Downloads」をクリック。
そして自分の環境にあったインストーラーをダウンロードする。今回はWindowsなので「Download for Windows(x64)」を選択。
ダウンロードしたexeファイルを開くと、まず使用許諾契約書の同意を求められるので同意する。
続いてインストール先の指定を行う。基本はデフォルトの場所でOKのはず。
続いてプログラムのショートカットを作成する場所を指定する。ここは任意。
実行する追加タスクを聞かれる。デフォルトでは「サポートされているファイルの種類のエディターとしてKiroを追加する」という項目と「PATHへの追加」にチェックが入っている。今回はデフォルトのまま実行。
インストール内容について確認されるので問題なければ「インストール」をクリック
インストールが完了してKiroのアプリを立ち上げるとサインインの方法を聞かれる。今回は私はAWS Builder IDでログインしてみた。
「Sign in with AWS Builder ID」をクリックするとブラウザ画面に遷移しAWS Builder IDでログインするためのアドレスやパスワード、ワンタイムパスワードを求められる。入力後、IDEに戻るとVS Codeの設定を引き継ぐかどうかを確認される。KiroはVS Codeをフォークして作成されているため、設定を引き継ぐことができる様子。
ほかにもダークモードかライトモードかを聞かれる。今回はダークモードを指定した。ここまで実施するとKiroのIDEが使えるようになる。
Kiroを使って開発してみる
導入したKiroを使って早速仕様駆動開発を試してみる。今回はToDoリストのアプリを作ってみた。画面を見た感じKiroを使うにはまずは空のフォルダが必要みたいなので作成した。
今回「test_todo」というフォルダを作って開いたところ以下の画面が表示された。KiroではAIと壁打ちしてどんどんコードを変えて作成していく「Vibeモード」と仕様を作成してからコードを書く「Specモード」の2つがある。今回はもちろんSpecモードを選択した。
また基盤モデルは選べるみたいで利用時のクレジットも表示されていた。ここは一旦デフォルトのAutoで進めていく。
まずはtodoリストを作りたいことを伝える。すると、自動的に要件文書として「requirements.md」を作成してくれた。6つの要件が作成されていて、それぞれユーザーストーリに基づいた機能要件が記載されている。例えば以下のような形だ。
### 要件 1
**ユーザーストーリー:** ユーザーとして、新しいタスクをToDoリストに追加したいので、完了すべき事項を記録し整理できるようにしたい。
#### 受入基準
1. ユーザーがタスクの説明を入力してEnterキーを押すかボタンをクリックしたとき、ToDoアプリはタスクを作成してリストに追加しなければならない
2. ユーザーが空のタスクを追加しようとしたとき、ToDoアプリは追加を防止し現在の状態を維持しなければならない
3. 新しいタスクが追加されたとき、ToDoアプリは入力フィールドをクリアし次の入力のためにフォーカスしなければならない
4. タスクが追加されたとき、ToDoアプリはタスクを即座にローカルストレージに永続化しなければならない
5. 入力フィールドがフォーカスを受けたとき、ToDoアプリは穏やかな美観を損なうことなく微細な視覚的フィードバックを提供しなければならない
要件はEARS（Easy Approach to Requirements Syntax）パターンに従って構造化されているとのこと。
EARSは車で有名なロールスロイスの航空機のエンジンを作っているところの技術者が考案した要求を自然言語で記述するための簡易構文テンプレートのこと。一定の語順で記述するテンプレートが6つあり、これを使って要件を記述する。
型としては
- Ubiquitous型（常在型）
いつでも無条件に成立するときの要件を記述
例：アプリは未完了のタスクをすべてメインタスクリストに表示しなければならない。 - Event-driven型（契機型）
何らかのイベントやトリガーが発生した場合に成立する要件を記述
例：ユーザーがタスクを完了に変更したとき、アプリはそのタスクを完了済みリストに移動しなければならない。 - State-driven型（状態型）
ある状態や条件下でのみ成立する要件を記述
例：タスクが期限超過状態の間、アプリはそのタスクを赤色で表示しなけれなならない。 - Optional型（選択型）
選択的・例外的な場合にのみ成立する要件を記述
例：リマインダー機能が有効な場合、アプリはユーザーが各タスクに期限日時を設定できるようにしなければならない。 - Unwanted(不測型・例外型)
望ましくない、あるいは異常な状況が発生した場合に成立する要件を記述
例：ユーザーがリマインダーが設定されているタスクを削除しようとした場合、アプリは削除前に確認ダイアログを表示しなければならない。
ここで生成された要件を確認し要件が足りていなかったり、不要なものがあれば削除して要件を固めていく。要件が問題なければ続いて設計（design）フェーズに進む。
設計フェーズに進むとまず設計内容が記載されたdesign.mdが作成された。design.mdには技術スタックやコンポーネント、インターフェースなどが記載されていた。
正直、Webアプリをそんなに作ったことがないので善し悪しがわからず、とりあえず問題ないとして次に進んだところ、実装計画（task.md）が生成された。
実装計画にはどの順番で何を実装するのかが記載されていた
この画面に記載されているStartTaskをクリックすると実装が進み始めるとのこと。実装を進めると細かくテストなどを行い、エラーが出ればそれを確認して原因を探し修正をおこなってくれた。
出来たものがこちら。
ちゃんとToDoリストっぽいものができている。触ってみるとタスクの削除や修正、私が追加したかったタスクの順序変更も実装されていた。しかし、最初にできたものはタスク内容の更新がうまくできておらずタスクの削除などがうまくおこなえなかったので、それを伝えて再度修正してもらっている。テストをしっかり行っているとはいえ多少の抜け漏れはあるのかもしれない。
感想
実際にKiroで仕様駆動開発をしてみてきちんと作成したものに関する要件や設計が整理されて出てくるのは、業務をするうえで作成したものの説明もしやすいし、動作内容についてどういう文書をもとに作られているのかがわかりやすいところがよいと感じた。
一方で、作ろうとするシステムやアプリに対してある程度の知見や経験がないと結局作成した設計や要件に関する善し悪しがわからないので、その場合はVibeで壁打ちして色々とAIに対して質問して、自分の知識を増やしながら開発していくのがよいのではないかと感じた。