AI-DLCを完全理解する第1回: 「AI-DLC」って何？

吉田真吾 (@yoshidashingo) です。

これだけは覚えて帰ってね💡

AI-DLC (AI-Driven Development Life Cycle) は、AIが開発プロセスを主導することを目指すフレームワーク

ウォーターフォール、V-Model (V字モデル) 、RUP、アジャイル、DevOpsと比較することで、AI-DLCの「どこが新しいのか」がクリアになる

最大の特徴は「適応型ワークフロー」: 5つの必須ステージは常に実行しつつ、残りのステージはAIがプロジェクトの状態を見て選択的に実行する

AI-DLCとは、AWS (Amazon Web Services) がオープンソースとして公開した、AIモデルが開発プロセスそのものを主導するためのフレームワークです。INCEPTION (計画) 、CONSTRUCTION (実装) 、OPERATIONS (運用) の3フェーズ・全14ステージで構成され、プロジェクトの状態に応じて実行するステージをAIが動的に選択する「適応型ワークフロー」が最大の特徴です。

引用元：AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 | Amazon Web Services ブログ

ソフトウェア開発手法の変遷をざっくり振り返る

AI-DLCの何が新しいかを理解するために、まずは簡単にこれまでの開発手法を振り返ってみましょう。

ウォーターフォール (1970年〜)

1970年、Winston W. Royceが論文「Managing the Development of Large Software Systems」を発表しました。よく「ウォーターフォールの生みの親」と言われますが、実はRoyce自身はこの方法を推奨していたわけではありません。論文の中では「この順次的なやり方はリスクが高い」と述べた上で、フィードバックループを組み込んだ改良案を提示していました。しかし皮肉なことに、彼が「問題のある例」として示した一方向の流れが、業界で広く採用されました。なお「ウォーターフォール」という名前はRoyce自身が付けたものではなく、1976年にBellとThayerが論文の中でRoyceの手法を引用する際に使った呼び方が定着したものです。

ウォーターフォールの特徴はシンプルです:

要件定義 → 2. 設計 → 3. 実装 → 4. テスト → 5. 運用

各フェーズが完了してから次に進みます。前のフェーズに戻るのは「原則として想定しない」とされています。

良い点: 進捗が見えやすく、大規模プロジェクトの管理に向いています。 つらい点: 途中で要件が変わると対応が難しいです。テストの段階で「そもそも要件が間違っていた」と気づいても、手戻りのコストが巨大です。

V-Model (1980年代〜)

ウォーターフォールの発展形として登場したのがV-Modelです。左辺で定義した各フェーズに対応する検証フェーズを右辺に配置し、V字の形になります。

要件定義 ─────────────────── 受入テスト
  基本設計 ───────────── 結合テスト
    詳細設計 ─────── 単体テスト
        実装

最大の特徴は、「何をテストするか」を設計段階で決めることです。要件定義の段階で受入テストの基準を定め、基本設計の段階で結合テストの項目を決めます。「テストは後から考える」ではなく、「テストと開発を対にする」発想は、後のTDD (テスト駆動開発) にもつながる考え方です。

ただし、V-Modelもウォーターフォールと同じく直線的な流れであり、途中での要件変更には弱いです。

RUP: Rational Unified Process (1990年代後半〜)

1990年代後半、Ivar Jacobson、Grady Booch、James Rumbaughの3人 ("Three Amigos"と呼ばれる) が中心となって、Rational Unified Process (RUP) を体系化しました。RUPはウォーターフォールの「一方通行」を改善し、反復型の開発プロセスを定義しました。

RUPの4フェーズはこうです:

Inception (方向づけ) : 何を作るか、なぜ作るかを定義します
Elaboration (推敲) : アーキテクチャを確立し、主要なリスクを潰します
Construction (作成) : 実際にシステムを構築します
Transition (移行) : ユーザーに引き渡します

ここで注目してほしいのは、フェーズ名です。InceptionとConstruction。AI-DLCのフェーズ名とぴったり一致します。AI-DLCがRUPの構造を意識して命名した可能性があります。

アジャイル宣言 (2001年)

2001年2月、アメリカ・ユタ州のスノーバードにソフトウェア開発者17名が集まり、「アジャイルソフトウェア開発宣言」を発表しました。この宣言は4つの価値を掲げています:

プロセスやツールよりも個人と対話
包括的なドキュメントよりも動くソフトウェア
契約交渉よりも顧客との協調
計画に従うよりも変化への対応

アジャイルは「大きなものを一度に作る」のではなく、「小さく作って、素早くフィードバックをもらう」ことを重視します。代表的な手法にはScrum (2〜4週間のスプリントで反復) 、XP (Extreme Programming) 、Kanban (フロー制御で継続的に流す) などがあります。スプリントで区切るかどうかは手法によって異なりますが、共通するのは「変化を歓迎する」姿勢です。

DevOps (2009年〜)

2009年、ベルギー・ゲントでPatrick DeboisがDevOpsDaysというカンファレンスを開催しました。これが「DevOps」という言葉の起源とされています。

DevOpsの核心は、開発 (Development) と運用 (Operations) の壁を壊すことです。コードを書く人と動かす人が別々のチームで、お互いの事情を知らない ― そんな分断をなくそう、という運動でした。

技術面では、CI/CD (継続的インテグレーション/継続的デリバリー) のパイプラインが普及し、コードの変更がコミットされるたびに自動でテスト→ビルド→デプロイが走るのが当たり前になりました。文化面では、開発・テスト・運用が一つのチームとして責任を共有する体制が広がりました。Infrastructure as Code (インフラをコードで管理する) やモニタリングの自動化も、DevOpsの流れから生まれた重要なプラクティスです。

DevOpsが導入した「開発から運用まで一気通貫で面倒を見る」という考え方は、AI-DLCの3フェーズ構成 (INCEPTION→CONSTRUCTION→OPERATIONS) にも共通しています。

AI-DLCの登場: AIが開発プロセスを「駆動」する

ここまで見てきた開発手法には共通点があります。人間がプロセスを設計し、人間がプロセスに従うということです。ウォーターフォールでもアジャイルでもDevOpsでも、「次に何をすべきか」を決めるのは人間でした。

AI-DLCはこの構図を変えようとしています。

AI-DLC (AI-Driven Development Life Cycle) は、AWSが2025年に公開した、AIモデルが開発プロセスそのものを主導するフレームワークです。GitHubリポジトリ (awslabs/aidlc-workflows) でオープンソースとして公開されています。プロジェクトの状態を評価した上で、必須のステージは確実に実行しつつ、条件に応じて追加のステージを選択的に実行します。

3つのフェーズ

AI-DLCのフェーズ構成は、見た目はRUPに似ています。

フェーズ	目的	焦点
INCEPTION	計画とアーキテクチャ	何を作るか、なぜ作るか
CONSTRUCTION	設計・実装・テスト	どうやって作るか
OPERATIONS	デプロイと運用 (将来拡張用)	どう動かすか

3つのフェーズの中に、合計14のステージが定義されています。ユーザーが指示するゴールに応じて、AIが必要なステージだけを選んで実行します。OPERATIONSフェーズは現時点ではプレースホルダー (将来拡張用の枠) であり、今後ステージが追加されていく見込みです。

14のステージは、ALWAYS (常時実行) とCONDITIONAL (条件付き実行) の2種類に分かれます。ALWAYSステージはどんなプロジェクトでも必ず実行されます。CONDITIONALステージは、プロジェクトの状態に応じてAIが実行/スキップを判断します。

ALWAYSステージ (5つ) : どんなプロジェクトでも必ず実行

Workspace Detection ― プロジェクトの状態を調べる
Requirements Analysis ― 要件を整理する
Workflow Planning ― どのステージを実行するか決める
Code Generation ― コードを生成する
Build and Test ― ビルドしてテストする

CONDITIONALステージ: INCEPTIONフェーズ (4つ)

Reverse Engineering ― 既存コードの解析 (既存コードがある場合のみ)
User Stories ― ユーザーストーリーの作成 (ユーザー向け機能がある場合)
Application Design ― アプリケーション設計 (新しいコンポーネントが必要な場合)
Units Generation ― 作業単位の分割 (複数ユニットが必要な場合)

CONDITIONALステージ: CONSTRUCTIONフェーズ (4つ)

Functional Design ― ビジネスロジック設計 (複雑なロジックがある場合)
NFR Requirements ― 非機能要件の定義 (性能やセキュリティの考慮が必要な場合)
NFR Design ― 非機能要件の設計 (上記を実行した場合)
Infrastructure Design ― インフラ設計 (クラウドリソースの指定が必要な場合)

OPERATIONSフェーズ (1つ)

Operations ― 運用・デプロイ (※現時点ではプレースホルダー)

これが「適応型ワークフロー」の正体です。CONDITIONALステージの実行/スキップを判断する際、AIは以下の4つの要素を評価します:

ユーザーの意図の明確さ: リクエストがはっきりしているか
既存コードベースの状態: ゼロから作るのか、既存のコードがあるか
変更の複雑さとスコープ: 1ファイルの修正か、システム全体に影響するか
リスクとインパクト: 失敗したときの影響はどれくらいか

たとえば、既存プロジェクトの単純なバグ修正であれば、5つのALWAYSステージだけでサクッと完了します。一方、大規模な新規システム構築であれば、CONDITIONALステージも含めて14ステージのほぼすべてがフルに実行されます。同じフレームワークが、タスクの大きさに応じて自動で伸び縮みするため、従来の「軽すぎる/重すぎる」プロセスの問題が構造的に軽減されます。ただし、この動的な判断はAIモデルの評価精度に依存するため、各ステージ終了時の承認ゲートで人間が判断の妥当性を確認する設計になっています。

既存手法との比較

ウォーターフォールからAI-DLCまで、プロセス決定者・フェーズ構造・要件変更への対応・ドキュメント・品質保証の5軸で比較します。

観点	ウォーターフォール	V-Model	RUP	アジャイル	DevOps	AI-DLC
プロセス決定者	人間 (PMが計画)	人間 (PMが計画)	人間 (アーキテクトが判断)	人間 (チームが自己組織化)	人間 (チームが設計)	AI (モデルが提案、人間が承認)
フェーズ構造	固定・直線	固定・V字対応	固定・反復	反復 (スプリント等)	継続的フロー	適応型 (動的にスキップ)
要件変更への対応	困難	困難	やや柔軟	柔軟	柔軟	要件の曖昧さに応じて深度を変える
ドキュメント	重厚	重厚 (テスト計画含む)	中程度	最小限	コードと一体化	AIが必要分だけ生成
品質保証	テストフェーズで一括	設計段階でテスト計画	イテレーションごと	スプリントごと	CI/CDで継続的	各ステージに承認ゲート

では、AIがプロセスを決めるとして、品質や安全性はどう担保されるのか？

AI-DLCを支える3つの仕組み

AI-DLCには、適応型ワークフローを安全に機能させるための重要な仕組みが3つあります。これらは第7回で詳しく掘り下げますが、ここでは概要を確認します。

1. Adaptive Depth (適応的深度)

ステージを「実行するかどうか」だけでなく、実行する場合の詳しさも問題の複雑さに応じて3段階で自動調整されます。

深度	使われる場面
Minimal	要件が明確でシンプルな変更。バグ修正など
Standard	通常の複雑さ。不明点を質問で解消しながら進める
Comprehensive	高リスクまたは大規模。トレーサビリティ付きの詳細な要件定義

同じRequirements Analysisステージでも、バグ修正なら数行の要件メモで済み、大規模システム移行なら複数ラウンドの質問を経た包括的な要件定義書が生成されます。成果物の種類は同じでも、中身の密度が変わる ― これがAdaptive Depthの核心です。

2. 承認ゲート

14ステージ中13ステージの終了時に、人間の明示的な承認が必要です。唯一の例外は、情報収集だけを行うWorkspace Detectionです。AIが提案し、人間が決裁する ― 自動化と人間のコントロールのバランスが、フレームワークレベルで設計されています。

承認なしに次のステージに進むことはできません。仕様書には「DO NOT PROCEED until user confirms (ユーザーが確認するまで先に進むな) 」と明記されています。

3. 監査証跡 (Audit Trail)

AI-DLCでは、すべてのやり取りがaudit.mdというファイルにタイムスタンプ付きで記録されます。ユーザーが何を言ったか、AIが何を判断したか、いつ承認が下りたか ― すべてが原文のまま (要約禁止) 残ります。

これは「後から振り返れる」だけでなく、「別のセッションで続きから再開できる」という実用的なメリットもあります。AI-DLCにはセッション継続の仕組み (aidlc-state.mdによる進捗追跡) があり、前回の作業をそのまま引き継げます。LLMのコンテキストウィンドウ (一度に処理できるテキスト量の上限) の制約を、ファイルベースの状態管理で乗り越える設計です。

まとめ

第1回はAI-DLCの全体像と、その背景にある開発手法の変遷について説明しました。今回学んだことは以下です。

AI-DLCは「AI-Driven Development Life Cycle」の略で、AWSが発表した、AIが開発プロセスを主導するフレームワーク
INCEPTION → CONSTRUCTION → OPERATIONSの3フェーズ、全14ステージで構成されます
14ステージは5つのALWAYS (常時実行) と9つのCONDITIONAL (条件付き実行) に分かれ、AIがプロジェクトの状態に応じてCONDITIONALステージの実行/スキップを判断します (適応型ワークフロー)
13ステージに承認ゲートがあり、AIの判断を人間が確認・制御できる設計です
従来手法の長所 ― ウォーターフォールの構造性、RUPの反復性、アジャイルの適応性、DevOpsの一気通貫 ― との共通点を持ちつつ、AI主導の適応型ワークフローという新しい試みを提示しています

次回予告

第2回では、AI-DLCの最初のステップ「Workspace Detection」と「Reverse Engineering」を詳しく見ていきます。プロジェクトを始めるとき、AI-DLCはまず何をするのか？既存のコードがある場合とない場合で、どう振る舞いが変わるのか？ ― 「現場を知る」ことの大切さを、TOGAFやレガシーコード改善の知見と絡めて解説します。