はじめに
Kiro CLI を使って AI-DLC（AI-Driven Development Life Cycle）の開発手法を実践し、実際にアプリを開発してみました。
AI が開発プロセスを主導するという新しい体験について、率直に感じたことをまとめています。
これから AI-DLC を試してみようと思っている方や、AI 駆動開発に興味がある方の参考になれば幸いです。
前提
Kiro CLI と AI-DLC の詳細な技術仕様や使い方については本記事では深掘りしません。
あくまで実際に使ってみた感想を中心にまとめています。
開発したアプリ: 複数のスーパーマーケットのチラシ（PDF/画像）を解析し、指定した商品の価格を安い順に表示する CLI ツールです。Amazon Bedrock（Claude 3.5 Sonnet v2）のマルチモーダル機能を活用し、Strands Agents SDK によるマルチエージェント構成で実装しました。実装の詳細は割愛しますが、AI-DLC を使った開発体験に焦点を当てて紹介します。
AI-DLC の詳細については公式ドキュメントを参照してください。
AI-DLC GitHub リポジトリ
AI-DLC 公式ブログ
AI-DLC とは？
AI-DLC は、AWS が提唱する AI 駆動型のソフトウェア開発ライフサイクルです。AI が会話を主導し、人間は承認と検証に集中します。プロジェクトの複雑さに応じてプロセスを適応させ、各フェーズで人間の承認を必須化することで、品質を担保します。
3つのフェーズ
AI-DLC は 3つのフェーズで構成されています。
出典: AI-Driven Development Life Cycle: Reimagining Software Engineering
- INCEPTION PHASE: 何を作るか、なぜ作るかを明確化
- CONSTRUCTION PHASE: どう作るかを決定し、実装
- OPERATIONS PHASE: デプロイと運用
今回は個人開発のため、INCEPTION PHASE と CONSTRUCTION PHASE のみを実施しました。
セットアップ
今回は Kiro CLI を利用して AI-DLC のフローを実行しました。
AI-DLC はルールファイルによって実現されています。Kiro CLI で利用する場合はプロジェクトの.kiro/steering/配下にワークフロー定義を配置すると、Kiro CLI が自動的に読み込み、開発セッション全体でそのルールに従って動作します。これにより、質問、計画、コード生成といった各ステージが AI-DLC のワークフローに沿って実行されます。
ステアリングファイルの配置
# プロジェクトルートで実行 cd /path/to/your/project # AI-DLCワークフローをクローン git clone https://github.com/awslabs/aidlc-workflows.git # ステアリングファイルを配置 mkdir -p .kiro/steering cp aidlc-workflows/aidlc-rules/aws-aidlc-rules/core-workflow.md .kiro/steering/ cp -r aidlc-workflows/aidlc-rules/aws-aidlc-rule-details .kiro/
開発開始
kiro-cli chat # プロンプト: 「Using AI-DLC, [あなたのプロジェクト説明]」
重要: AI-DLC を起動するには、プロンプトを"Using AI-DLC, ..."で始めます。
AI-DLC の開発フロー
プロンプトを開始すると、AI エージェントが以下のステージに沿ってプロアクティブに質問してくれます。基本的にはその質問に回答していくことで、自然と開発が進められるようになっています。
INCEPTION PHASE（要件定義）
| ステージ | 内容 |
|---|---|
| ワークスペース検出 （Workspace Detection） |
新規/既存プロジェクトの判定 |
| 要件分析 （Requirements Analysis） |
12 個の質問に回答して要件を明確化 |
| ユーザーストーリー （User Stories） |
ユーザー視点での機能定義 |
| ワークフロー計画 （Workflow Planning） |
開発プロセスの決定 |
| アプリケーション設計 （Application Design） |
システムアーキテクチャの設計 |
| ユニット生成 （Units Generation） |
作業単位への分割（今回は 5 ユニット） |
※ユーザーストーリーは個人開発のためスキップさせました。
CONSTRUCTION PHASE（設計・実装・テスト）
各ユニットで以下を繰り返し：
| ステージ | 内容 |
|---|---|
| 機能設計 （Functional Design） |
7-10 個の質問でビジネスロジックを設計 |
| 非機能要件 （NFR Requirements） |
7-10 個の質問で技術選定 |
| コード生成 （Code Generation） |
実装計画 → 承認 → 自動生成 |
| 統合テスト （Build and Test） |
全ユニット完了後に実行 |
驚いたこと
バイブコーディング感覚でサクッと作ろうと思って始めたところ、予想以上に多くの質問に回答する必要があり驚きました。
INCEPTION PHASE（要件定義）
- 要件分析（Requirements Analysis）で 12 個の質問
- アーキテクチャ設計（Application Design）の承認
- 作業単位の分割（Units Generation）と承認
CONSTRUCTION PHASE（設計・実装・テスト）
各ユニット（今回は5つ）ごとに：
- 機能設計（Functional Design）で 7-10 個の質問
- 非機能要件（NFR Requirements）で 7-10 個の質問
- 実装計画（Code Generation）の承認
合計すると、70 個以上の質問や承認ポイントがありました。
もっと気軽に使えるツールだと思ってた...というのが率直な感想です。
ただ、本番利用を想定した場合、実装の抜け漏れや機能/非機能要件の考慮漏れを防げそうな感覚は持ちました。実際、INCEPTION PHASE で時間をかけて回答した部分については、CONSTRUCTION PHASE ではほとんど迷うことなく進んだ感覚がありました。
一方で、アジャイル開発のように取り組むタイミングに応じた優先度付けやリリース期限に応じて柔軟に対応することが求められるシーンでは、決定を遅らせたり進捗管理を工夫するなどの考慮が必要かもしれないと感じました。この点に関しては今後試してみたいと思っています。
良かったところ
1. 会話を主導してくれる
AI-DLC がルールに反映されていない場合、進め方を自前でルール化したりプロンプトを工夫しないとプロアクティブに進め方を誘導してくれませんが、
AI-DLC は進め方についてはほぼ自動的にタスクを進めることができました。
AI-DLC ホワイトペーパーでは、この関係をGoogle Maps のアナロジーで説明しています
"An analogy to illustrate this is Google Maps: humans set the destination (the intent), and the system provides step-by-step directions (AI's task decomposition and recommendations). Along the way, humans maintain oversight and moderate the journey as needed."
人間は目的地（Intent）を設定し、AI がステップバイステップの道順を提示してくれます。
次はどんな指示をすればうまく進んでもらえるのか悩む時間がゼロになったのは、体験が良かったです。
2. 進捗管理を自動でやってくれる
AI-DLC がルールに反映されていない場合、私は Kiro CLI を使う際に、進捗管理ドキュメントを独自にルール化したりプロンプトで都度指示を出して作成・更新させて運用していました。 このドキュメントがないと、Kiro CLI のチャットセッションが切れた時にどこまで作業が完了していて次のタスクが何なのか？を Kiro CLI が正確に知る方法がないためです。 AI-DLC では、この進捗管理が標準機能として組み込まれているため、独自実装が不要になりました。
自動生成されるドキュメント
aidlc-state.md: 進捗状況を自動記録audit.md: 全ての決定を記録
このルールにより、「どこまで進んだっけ？」「なぜこの決定をしたんだっけ？」と思うことがあってもすぐに Kiro CLI が理解できる状態になります。
3. 曖昧さを排除してくれる
AI-DLC の構造化質問により、曖昧な回答は自動検出されます。
実例: NFR Requirements（非機能要件）で、技術選定について「A か B でよりエラー発生しにくい方」と曖昧に回答したところ、AI-DLC が即座に曖昧さを検出しました。
AI-DLC の対応
AI-DLC は曖昧な回答を検出すると、明確化質問を自動生成し、各オプションのメリット・デメリットを提示してくれます。この曖昧さ検出プロセスにより、誤った仮定を防ぎ、技術選定の根拠が明確になります。
ただし、人間が曖昧な回答をした場合は別ドキュメントで明確化を要求され、明確化が完了しないと次に進めない仕組みになっています。要件の漏れや曖昧さを早期発見できるのは良いのですが、その分時間はかかります。
4. 新しい学習体験
各プロセスの細かいポイントを学べる
AI-DLC を通じて、要求から要件、設計、実装、テストへの流れや、NFR Requirements（非機能要件）の要素、Functional Design（機能設計）の詳細度など、開発プロセスの細かいポイントを学べました。特に、非機能要件では具体的に何を決めるのかという疑問が、AI-DLC の質問を通じて明確になりました。
プロダクトオーナーの気持ちになれる
開発に関して考えることが減った分、システムの価値を考える時間が増え、システムの本質についてより深く考えられるようになりました。効率良くユーザーへ価値提供するためのスコープについても考えられるようになったのは、予想外の副次的効果でした。
イマイチだったところ
1. コンテキストウィンドウすぐ溢れる
問題
長時間のセッションではトークン消費が激しく、Thinking の時間も長くなります。特に、CONSTRUCTION PHASE で5つのユニットを連続で実装していると、コンテキストウィンドウが逼迫してオーバーフローが発生しやすい状況になりました。これは Kiro CLI が使用する LLM のコンテキスト制限に起因し、AI-DLC が生成する多数のアーティファクト（requirements.md、stories.md、design.md など）を参照し続けることで、セッションが長くなるほどトークン消費が増加します。
対策
1 セッションでやり切れるタスクに収めたり、フェーズの区切りで終了して新しいセッションで再開するのが有効です。実際、Inception Phase 完了で一旦終了し、翌日新しいセッションで再開したところ、スムーズに進みました。
2. レビューは相変わらず大変
問題
AI-DLC を使っても、生成されたコードのレビューは人間がやる必要があります。実装は AI が設計に基づいて突っ走るため、レビューの負荷は依然として高いです。
良い点
INCEPTION/CONSTRUCTION PHASE それぞれで、共同で設計を実施しているため、いきなりレビューをするよりかは負荷は下がります。また、設計書もルールに基づいて標準化されたドキュメントが生成されているので理解しやすくなっており、改善されていると感じました。
開発規模と時間
参考までに、今回の開発の統計を記載します。
| 項目 | 数値 |
|---|---|
| ファイル数 | 47 ファイル |
| コード行数 | 約 2,705 行 |
| テストコード | 約 755 行 |
| 総計 | 約 3,460 行 |
開発時間は約 5-6 時間でした。手動実装の場合は簡単に見積もって 20-25 時間かかるとすると、約 4 分の 1 程度の時間で開発が完了することになります。もちろんそんなに綺麗に完了することはないと思いますが、、、
注意: 本記事は1 人での開発体験を記録したものです。AI-DLC は本来、チーム開発での協働的なプロセスを想定しています。
AI-DLC 公式ブログでは、以下のように説明されています：
"In the Inception phase, AI transforms business intent into detailed requirements, stories and units through 'Mob Elaboration' – where the entire team actively validates AI's questions and proposals. In the Construction phase, using the validated context from the Inception phase, AI proposes a logical architecture, domain models, code solution and tests through 'Mob Construction' – where the team provides clarification on technical decisions and architectural choices in real time."
「Mob Elaboration」「Mob Construction」という用語が示すように、チーム全体での協働作業を前提とした設計になっています。
まとめ
AI-DLC を使ってみて
AI-DLC（AI-Driven Development Life Cycle）を実際に使ってみて、AI が開発プロセスを主導するという新しい体験ができました。
驚いたこと
バイブコーディング感覚で取り組んでいたため、質問の多さに初めは面倒に感じました。しかし、本番利用を想定した場合、実装の抜け漏れや機能/非機能要件の考慮漏れを防げそうな感覚を持ちました。一方で、アジャイル開発のような柔軟な対応が求められるシーンでは、決定を遅らせたり進捗管理を工夫する必要があるかもしれません。
良かったこと
AI が会話を主導してくれる快適さ、進捗管理が自動化される安心感、曖昧さを排除してくれる厳密さ、そして開発プロセスの学びになりました。
イマイチだったこと
コンテキストウィンドウの制約とレビュー負荷は依然として高いことが課題でした。
最後に
AI-DLC は、AI が開発プロセスを主導するという新しい開発体験を提供してくれました。
今回は個人開発で取り組みましたが、今後は実務で利用してみてどれほどの成果が出るのかを検証してみたいと思いました。
