はじめに

最近話題のAI駆動開発（AI-Driven Development）。
AIエージェントを搭載したIDEのKiroでデモアプリの要件定義、実装、AWS環境へのデプロイを実践したので、開発フロー&実践から学んだKiroを使いこなすTipsを共有。

1. AWS構成図

ECS+Auroraのシンプルなアプリ(VPN経由で利用)。言語はPythonベース。
作成したコード管理用のCodeCommit、コンテナイメージ用のECRは予め手で作成し、その他のリソースはKiroにCDKを書いてもらいデプロイ。

IAM Identity Centerのユーザにライセンスを紐づけてKiroを使用した。

KiroからAWS操作に必要な権限は、作業端末からaws loginでブラウザ認証し、一時的な権限を持たせた。

2. 開発フロー

今回は①Vibeモードによる要件定義、②Specモードによる実装・テスト、③CDKデプロイの3ステップでKiroに開発してもらった。人間はKiroへの指示、Kiroの作成物の確認・承認のみ行った。

①Vibeモードで要件を作る

最初に「こんな感じのものが欲しい」という抽象的なイメージ（Vibe）をKiroに投げてみて、作ってくれた案を人間がレビュー、リテイクや承認をする。対話を通じて、AIに「何を作るべきか」の構成案を作らせるフェーズ。

フィードバックループが非常に高速なので、早ければ数分で要件が固まることになる。

これはリードタイムの大幅な短縮である一方、従来のドキュメント作成プロセスで不可欠だった「代替案の比較検討」や「制約事項の言語化」をスキップ、結論だけがドキュメント化されることで、後日システム構成を変更する際の判断基準や、技術選定の意図が分からなくなる可能性もある。

今回は実施しなかったが、「なぜその案を採用し、どこを人間が修正したのか」という意思決定のプロセスをArchitecture Decision Records(ADR)の形式などで明文化し、残しておくと開発スピードとブラックボックス化の防止を両立させられるのではないか、と記事を書きながら思った。

②Specモードで開発実装

構成が決まったら、KiroのSpecモードに切り替え。(実装フェーズに入ったらKiro側からSpecに切り替えていい？って言われた)

このフェーズに入った段階で何を実装するかのタスクリストが作られるので、リストの内容に問題が無ければタスクの上から実行していくことになる。

テストもKiroに任せるケースが多くなると考えられる。今回ユニットテストの作成と実行はKiroにやってもらったが、何かしらエラーは出るだろうし、エラーの原因が環境側にあるなど、対応が単なるコード修正に留まらないこともあるだろう。

コード以外の部分のトラシューもKiroがやってくれるのだが、単に直してねーという指示だと同じような作業を繰り返してドツボにはまることがあるため、人間の側でトラシューの方向性は予め確認したほうがよい。後述のコツ②参照。

③CDKでAWSリソースをデプロイ

アプリのコードができたら、アプリ基盤用のCDKのコードをKiroに作ってもらい、
ターミナルからcdk deployでデプロイ。

今回は諸々の検証があり開発前にVPCなどのリソースをちょこちょこ手動で作っていたため、リソースが複数のVPCに分散してデプロイされるという事態が起こった。…ので、真っ新なAWS環境に全部お任せで作ってもらうのが簡単で安全。
もし既存のリソースがある環境にデプロイするのであれば、このVPCにデプロイしてね、とARNなりリソースIDを指定したほうがよい。

今回はデモアプリだったため、AIDLCとしてもスピード重視の開発をしたが、実際はデプロイ前にcdk-nagによるセキュリティ・コンプライアンス遵守チェックのフェーズが入るだろう。

3. 実践から学んだ「Kiroを乗りこなすコツ」

AI駆動開発をスムーズに進めるために、特に重要だと感じたポイントは以下の3つ。

コツ① Kiroとチャットするときは「新しいセッション」を恐れず使う

会話が長くなってくると、AIが過去の思わぬ文脈に引きずられてしまったり、踏まえてほしい事柄を忘れてしまったりする。

実際、現在のセッションでは必要な情報を覚えていないため前のセッションに戻る、ということがあった。また、開発・デプロイの途中に同じセッションでトラブルシューティングをした際は、ちょっとした不要なワードを覚えてしまいトラシュー後もKiroの返答が意図しないものになってしまった。

Kiroとチャットしてるとなんとなく同じセッションで会話を続けがちだけど、このセッションは何の情報を覚えているか？何の情報を持たせるか？ を意識しながらチャットをするのが重要だと感じた。AI駆動開発における成果物の品質を左右する点だと思う。

機能単位(認可・認証、データモデル、etc…)やフェーズ（実装→テスト、テスト→AWS環境デプロイなど）でセッションを分けるとどのセッションでチャットするべきか判断しやすい。

コツ② 「実行前の計画策定」を徹底させる

Kiroがクレバーに判断してくれるとはいえ、既存のコードや環境に変更を加える際は人間のチェックを挟むことが必要。実行する責任は人間にある。

といっても作業内容を細かくチェックするのは大変なので、今回は**「これから行う作業ステップを箇条書きで計画して」**と指示してリストを出してもらったが、これはやってよかった。

予め広範囲のコマンド実行許可を付与してるケースも含め、AIの作業内容にゴーサインを出すのはユーザなので、判断しやすくなる資料を作ってもらうと判断の負荷が下がる。

「調査/計画策定のみ実施し、コードや環境に変更は加えないで」と付け加えておくとさらに安全。

もし計画概要を見て「なぜその手順なのか？」「破壊的変更はないか？」等、疑問に思ったことがあれば遠慮なく聞けるので、手戻りを防ぐためにもAIが何を実行しようとしているのかは毎回確認を怠らないようにしたい。

コツ③ 一度に実行するタスクを大きくしすぎない

一度に実行させるタスクを小さくすることで、AIの作業が行き当たりばったりになったり思わぬ方向に行くことを防げる。

20程度のStepから構成されるタスクリストを最初から最後まで全部実行させてみたが、途中でエラーが出てつまづいたときなどトラブルシューティングが行き当たりばったりになってしまっていた。
(もし作業が思わぬ方向に行ってるけど実行終わりそうにない、というときは実行をキャンセルすることで中断可能)

一度に実行するのはタスクリストの1~2Stepが安全。
いずれにせよコードの差分（diff）はこまめに確認し、想定通りの作業をしているかチェックする。

おわりに

AI駆動開発は成果物が高速でできるため、意思決定もスピーディーに行う必要がある。
開発は少人数のメンバが一同に会し、画面を共有しながら短時間で開発するシーンが増えていくのではないだろうか。

ドキュメント化、コーディングなど、いわゆる「手を動かす」作業はAIが担っていくことになり、ブラックボックス化を防ぐ仕組み作りに焦点が当たると考えられる。

今後はプロンプトを標準化し、ADRの作成等AIと人間の合意形成のプロセスの記録も自動化して開発に組み込めないか試してみたい。