AIDLC のライフサイクル全体像
フェーズ2では、生成AIを前提とした「理想の開発プロセス(To)」を整理します。その中核が AIDLC(AI-Driven Development Life Cycle) です。このページは AIDLC が提唱するライフサイクルの全体像を図解します。
一言でいうと
Section titled “一言でいうと”AIエージェントが計画・要件・コード・テスト・インフラ構成の生成をライフサイクル全段でオーケストレーションし、人間は各要所で検証・承認・重要判断を担う——AIを開発の中心に据え直した方法論です。AWS が2025年に提唱しました。
スローガンは 「人は WHAT と WHY を、AI が HOW を」 です。
ライフサイクルの全体像
Section titled “ライフサイクルの全体像”graph LR
BI["ビジネス意図<br>(人間)"]
BI --> I["Inception<br>構想"]
I -->|Mob Elaboration| G1{"合意<br>チェックポイント"}
G1 --> C["Construction<br>構築"]
C -->|Mob Construction| G2{"承認<br>チェックポイント"}
G2 --> O["Operations<br>運用"]
O --> P["本番"]
どのフェーズも内側に、AIが生成して人間の承認を受ける共通ループを持ちます。
graph LR A["AIが計画を作る"] --> B["AIが確認を求める"] B --> C["人間が重要判断を下す"] C --> D["AIが計画を実装する"] D --> A
3つのフェーズ
Section titled “3つのフェーズ”| フェーズ | 内容 | 特徴的な概念 |
|---|---|---|
| Inception(構想) | ビジネス意図を要件・ストーリー・ユニットへ変換する | Mob Elaboration(全ロール同席でAIの問い・提案を検証) |
| Construction(構築) | 論理アーキテクチャ・ドメインモデル・コード・テストを生成する | Mob Construction(技術判断にチームがリアルタイムで指針を与える) |
| Operations(運用) | IaC・デプロイ・監視を管理する | 現状は placeholder で未成熟 |
2つの新しい単位: Bolt と Mob
Section titled “2つの新しい単位: Bolt と Mob”AIDLC の新規性は「粒度」と「同期」にあります。
- Bolt(ボルト): 従来の2〜4週のスプリントを、数時間〜1日以内の短く濃密なサイクルに置き換える時間箱
- Mob(モブ): PM・開発者・QA・運用が同じ場でAI生成物をリアルタイム検証する集団レビュー。従来の逐次ハンドオフを排する
この2つで開発を圧縮するのが、生産性向上(AWS は10〜15倍と主張)の源泉とされます。ただしこの数値は提唱者の自己申告で、独立検証は確認できていません。
ロールの分担
Section titled “ロールの分担”graph TD H["人間(意思決定主体)"] -->|WHAT / WHY| D["決定・承認・責任"] AI["AIエージェント(実行主体)"] -->|HOW| E["生成・実装・オーケストレーション"] D -.承認.-> E E -.提案.-> D
人間はアーキテクチャ判断・ビジネス整合・リスク評価・重要判断の承認を担い、AIはタスク分解・生成・テスト作成・リファクタリングを担います。「The agent proposes, the human approves(AIは提案し、人間は承認する)」を設計思想としています。
なぜこれが「To(理想)」なのか
Section titled “なぜこれが「To(理想)」なのか”本プロジェクトは、この AIDLC をそのまま導入するのではなく、日本の組織で運用できる形に落とし込むことを目指します。AIDLC は理想像として明快ですが、日本企業のガバナンス(稟議・決裁権限規程・品質保証部門)とそのまま組み合わせると、複数の衝突が起きます。
その衝突を測るために、AIDLC が暗黙に置いている前提条件を明らかにする必要があります。これはフェーズ2の「理想モデルの前提条件一覧」(別途整理)で扱い、フェーズ3のギャップ分析の物差しにします。
- AWS DevOps Blog「AI-Driven Development Life Cycle」(原典)
- GitHub awslabs/aidlc-workflows(公式実装)
- 詳細な調査メモ: リポジトリの
research/phase1/20260710-aidlc.md