AI-DLC(Kiroとawslabs/aidlc-workflows)でAI駆動開発をやってみる

はじめに

AI駆動開発を組織で使っていきたい！
でも、開発者がバラバラ使ってて、AI駆動開発の力を引き出せるのか。。。
プロダクトを良く知っている人、想いのある人や開発者、運用とのコミュニケーションがボトルネックになるんじゃない？

・・・そんなことをぼんやりと考えていた時に、AWSは AI-DLC（AI-Driven Development Life Cycle） という方法論を公開してくれました。
私は、まだ全てを理解していませんが、AI-DLCの実装例をaidlc-workflowsで公開してくれているので、どんなものか試してみようと思います。チームで使うものなのですが、試すのは 僕独りです。

AI-DLCの概要

あらためて、AI-DLC は、AWSが提唱するAIネイティブなソフトウェア開発方法論です。従来のSDLC（Software Development Life Cycle）がAIを補助的なツールとして扱うのに対し、AI-DLCはAIを開発プロセスの中心に据えつつ、重要な意思決定は人間が行う「Human in the Loop」で開発を進めます。
また、フェーズは「Inception」、「Construction」、「Operation」の3つが定義されていて、それをUnitと呼ばれる単位で回していきます。
図の左側に各フェーズに必要なメンバのロールとやることが書かれているように、「Inception」、「Construction」は基本的に モブ で行います。 POや開発者が同じものをみて、その場で議論する というのが大切なのだと思います。

出典: Raja SP, "AI-Driven Development Lifecycle (AI-DLC) Method Definition", Amazon Web Services

AI-DLCの3フェーズ の概要

AI-DLCの「Inception」、「Construction」、「Operation」に対して、実装例である aidlc-workflows でどのようなことをしているか記載しています。
（「Operation」は未実装です。）

🔵 INCEPTION PHASE（計画）

何を作るか、なぜ作るかを決める

ステージ	概要
Workspace Detection	ワークスペースの状態を分析し、Greenfield（新規）かBrownfield（既存コードあり）かを判定
Reverse Engineering	既存コードベースを分析し、アーキテクチャ、コード構造、API、技術スタックのドキュメントを生成
Requirements Analysis	ユーザーリクエストを分析し、明確化のための質問を行い、要件ドキュメントを生成
User Stories	要件をユーザー中心のストーリーに変換し、ペルソナと受け入れ基準を定義
Workflow Planning	実行するフェーズを決定し、包括的な実行計画を作成
Application Design	主要なコンポーネントの識別、インターフェース定義、サービス層の設計
Units Generation	システムを管理可能な作業単位（Unit）に分解し、依存関係を定義

🟢 CONSTRUCTION PHASE（構築）

どう作るかを決め、実装する

ステージ	概要
Per-Unit Loop	各ユニットごとに以下のステージを実行
Functional Design	ユニットの詳細なビジネスロジック、ドメインモデル、ビジネスルールを設計（技術非依存）
NFR Requirements	非機能要件（スケーラビリティ、パフォーマンス、セキュリティ等）を決定し、技術スタックを選定
NFR Design	NFR要件を設計パターン（Circuit Breaker、CQRS等）と論理コンポーネントに落とし込む
Infrastructure Design	論理コンポーネントを実際のインフラサービス（AWS Lambda、DynamoDB等）にマッピング
Code Generation	計画を作成し承認を得た後、コード、テスト、デプロイアーティファクトを生成
Build and Test	ビルド手順、ユニットテスト、統合テスト、パフォーマンステストの手順書を生成

🟡 OPERATIONS PHASE（運用）

デプロイとモニタリング（将来拡張予定）

緑色のステージは常に実行され、黄色のステージは条件付きで実行されます。AIがプロジェクトの複雑さを分析し、必要なステージだけを選択します。

aidlc-workflowsの導入

Kiroで使う際の導入手順も記載します。

1. aidlc-workflowsのクローン

githubからクローンします

git clone https://github.com/awslabs/aidlc-workflows.git

2. プロジェクトフォルダの作成

プロジェクトフォルダを作成します。

mkdir my-project
cd my-project

3. ルールファイルのコピー

Kiro IDEの場合

k.kiro/steering に コアのルールファイルを配置しつつ、ルールの詳細を別ディレクトリに置いています。

mkdir -p .kiro/steering
cp -R ../aidlc-workflows/aidlc-rules/aws-aidlc-rules .kiro/steering/
cp -R ../aidlc-workflows/aidlc-rules/aws-aidlc-rule-details .kiro/

ディレクトリ構成

以下の状態になっていれば aidlc-workflows を使う準備ができています。

.kiro/                              # Kiroの場合
├── steering/
│   └── aws-aidlc-rules/
│       └── core-workflow.md        # メインワークフロー定義
└── aws-aidlc-rule-details/
    ├── common/                     # 共通ルール
    │   ├── process-overview.md
    │   ├── session-continuity.md
    │   └── welcome-message.md
    ├── inception/                  # INCEPTION PHASEのルール
    │   ├── workspace-detection.md
    │   ├── requirements-analysis.md
    │   └── workflow-planning.md
    └── construction/               # CONSTRUCTION PHASEのルール
        ├── functional-design.md
        ├── code-generation.md
        └── build-and-test.md

実際の開発フロー

MCP App（ダッシュボード付きのリモートMCPサーバ）を開発した際の実際のフローを紹介します。
ここでは、AI-DLCに焦点を当て、MCP Appの詳細は別の記事にします。

Step 1: AI-DLCワークフローの開始

チャットで「Using AI-DLC, ...」というプレフィックスを付けてリクエストを送ります。

Using AI-DLC, 
aidlcのworkflowに従うと、どんな開発ステップを踏んでいけばよいですか？
今、MCP Appと呼ばれるもののサンプル（知らない人に凄さをつたえられるもの）をリモートサーバとして立て、Claude desktopから呼び出してデモしたいと考えています。

AIエージェントがAI-DLCワークフローを認識し、ウェルカムメッセージを表示します。

Step 2: Workspace Detection

Kiroがワークスペースを分析し、Greenfield（新規）かBrownfield（既存コードあり）かを判定します。

• Greenfield → Requirements Analysisへ
• Brownfield → Reverse Engineeringへ

この段階でaidlc-docs/フォルダが作成され、aidlc-state.md（進捗状態）とaudit.md（監査ログ）が生成されます。

Step 3: Requirements Analysis

Kiroが要件を分析し、明確化のための質問をします。AI-DLCの重要なルールとして、AIは勝手に仮定を置かず、必ず質問することが定められています。

質問は専用のMarkdownファイルに出力されます
また、質問は選択肢を作ってくれているので、比較的に答えやすいです。以後、要件以外も質問があるときはmarkdownファイルに選択肢で応える

# Requirement Clarification Questions（例）

## Q1: 外部APIの選択
A) OpenWeatherMap API（天候データ）
B) Alpha Vantage API（株価データ）
C) CoinGecko API（暗号通貨）
D) REST Countries API（国データ）
E) Other（自由記述）

[Answer]: A

回答を入力すると、AIが矛盾や曖昧さをチェックし、問題があれば追加質問します。すべてが明確になると、requirements.mdが生成されます。
ここでのレビューは大切なので、人間がしっかり確認します。変更があればこの場で伝え、よければ承認することを伝えます。「Human in the Loop」ってことですね。

Step 4: Workflow Planning

Kiroが実行計画を提案してくれます。
ここでも変更があれば伝えます。

Step 5: Application Design

アプリケーション設計の計画をしてくれます。

質問が書かれたmarkdownファイルをみても質問6だけ意味が分からなかったので聞いてみています。
すると、↓のように分かりやすく教えてくれました。

Step 6: Units Generation

Unitと呼ばれる単位に作業を分割してくれます。
人間が分割の粒度や依存関係が正しいかをレビューをします。

ここまでが、INCEPTION PHASEです。
次のステップから、CONSTRUTION　PHASEに入ります。

Step 7: NFR Requirements

ここからは Unit ごとに繰り返します。
まずは、非機能要件を定義します。

Step 8: NFR Design

Unitの非機能設計も行います。

Step 9: Infrastructure Design

インフラ設計も行います。
ここまでで、だいたい決まっているので、出てくる質問もデフォルトで選択肢が入力されていたりします。

Step 10: Code Generation

コード生成の前に、計画が作成されます。

その後、実装してくれます。
ここはだいぶ長い間走ってくれました。

Step 11: Build and Test

ビルドとテストに入ります。

生成されたのは、手順書でした。
何かおかしい気がしたので、テストをいつしたのか聞いてみました。

なんと、手動テストのつもりだったようなので、遺憾の意を伝えるとKiroがやってくれました。

curlでAPIのテストだけやってもらいました。

こんな感じでユニットごとに開発を進めます。

生成されるドキュメント

aidlc-docs/
├── aidlc-state.md              # 進捗状態
├── audit.md                    # 監査ログ（全やり取り記録）
├── inception/
│   ├── plans/
│   ├── requirements/
│   │   ├── requirements.md
│   │   └── requirement-clarification-questions.md
│   └── application-design/
│       └── components.md
└── construction/
    ├── plans/
    │   └── unit-1-code-generation-plan.md
    ├── unit-1-mcp-server-core/
    │   ├── functional-design/
    │   │   └── domain-entities.md
    │   └── code/
    │       └── code-summary.md
    └── build-and-test/
        └── build-instructions.md

監査ログの例

audit.mdにはKiroとのやり取りが記録されます

---
## Requirements Analysis - Transport Support Verification
**Timestamp**: 2026-01-30T00:30:00Z
**User Input**: "HTTP/SSE transport を直接サポートしていません。というのは本当でしょうか？"
**AI Response**: Re-researching Claude Desktop transport support - found conflicting information, need to clarify
**Context**: INCEPTION Phase - Requirements Analysis stage, verifying technical accuracy

---
## Requirements Analysis - Authentication Concern
**Timestamp**: 2026-01-30T00:35:00Z
**User Input**: "この時の認証ができない気がしています。カスタムコネクタに設定欄があるのですが、うまく動作していないと報告がありました。何か動いている事例などはありますか？"
**AI Response**: Researching working authentication examples and known issues with Custom Connectors
**Context**: INCEPTION Phase - Requirements Analysis stage, investigating authentication feasibility

---

## Workflow Planning
**Timestamp**: 2026-01-30T10:30:00Z
**User Input**: "つづけて"
**AI Response**: "ワークフロー計画を承認しました。Application Designに進みます。"
**Context**: ワークフロー計画の承認

AI-DLC（aidlc-workflows）を動かしてみた感想

総論めっちゃポジティブです。

1. チーム開発でのワークフローに使えそう！

プロダクトの価値からブレずに動くものをつくれる。一人でこそこそ作ってるよりも確実に意思疎通をしやすい。
また、作るべきドキュメントも標準化できるので、AI駆動開発に慣れていない人でもある程度質を保てそうです。

2. チームのコラボレーションが大切

要件定義や設計などの段階でプロダクトの価値や設計指針など、人間はいろんな観点で質問を受けます。
このとき、責任をもって答えられるロールの人を集めておく必要があると思いました。
判断がないと物事が進まないのは従来の開発でも同じで、AI-DLCだとより顕著にボトルネックになります。
（将来的には、全部自分で回答できればいいんだろうなあ。）

3. 若手メンバを含めたチーミング

賛否ありそう。
極端に言うと、若手エンジニアが手を動かす余地がない。
シニアのやり方を横でみて、質問して、早く独立してもらえるようにするという方針になるのかな。
（結局今までの開発も同じなのかな）

4. （今回載せていないが）既存のコードからドキュメント類を生成させるリバースエンジニアリングもめっちゃ使える。

ドキュメントが最新化されていないとか、そもそもないとかそんなときに、めちゃくちゃ助かりました。
ビジネスコンテキストからアーキテクチャ、コードのレベルでドキュメントを整理してくれて、分かりやすかったです。

参考リンク

• AI-DLC（AI-Driven Development Life Cycle - AI-DLCの投稿：AWS公式ブログ
• awslabs/aidlc-workflows - AI-DLCワークフローのGitHubリポジトリ
• Kiro - AWSの IDE

---