AI-DLCとは何か。AI駆動開発の全体像と5つのフェーズ

AI-DLC（AI-Driven Development Life Cycle）は、コードを書く工程だけでなく、何を作るかという意図から要件、設計、実装、テスト、運用までをAI前提でつなぎ直す開発方法論です。AWSが2025年に公開し、現在はAWS Labsが実行可能なワークフローとして公開しています。

調べると「3フェーズ」と「5フェーズ」の説明が出てきます。どちらかが単純に誤りなのではありません。2025年のAWS公式解説は方法論の大きな流れを3つで示し、2026年9月3日時点のAWS Labsの実装ガイドは5フェーズ33ステージに具体化しています。実際に使うときは、参照している文書の日付と粒度を確認する必要があります。

AI-DLCはAIコーディングと何が違うか

AIコーディングは、自然言語の指示をもとにコードを補完、生成、修正する技術や開発スタイルの総称です。AI-DLCは、コード生成を含みますが、対象をそこに限定しません。ビジネスの意図を要件へ変え、作業単位へ分け、設計とテストを通し、デプロイ後の観測を次の企画へ戻すところまでを扱います。

違いは、AIを使う工程の数ではなく、成果物のつながりにあります。要件からユーザーストーリー、設計、コード、テストまでを追跡できる状態にし、次の工程が前の工程の推測に依存しないようにします。AIにコードを書かせるだけなら、要件が曖昧なままでも実装は始まります。AI-DLCでは、曖昧さを質問と検証へ戻す仕組みも開発工程に含めます。

コード生成の方式やレビューの変化はAIコーディングとは何かで整理しています。AI-DLCは、その前後を含むライフサイクルの話です。

3フェーズと5フェーズは、どちらが正しいか

2025年8月に公開されたAWS公式ブログは、AI-DLCをインセプション、コンストラクション、オペレーションの3フェーズで説明しています。インセプションでビジネスの意図を要件、ストーリー、作業単位へ変え、コンストラクションで設計、コード、テストを進め、オペレーションでデプロイを扱う構成です。

一方、AWS Labsの現行ガイドは、初期化と企画を独立させた5フェーズ33ステージです。インセプションの中にドメイン設計や契約設計も置かれ、2025年の3フェーズ説明とは工程の境界も完全には同じではありません。

ここでは、3フェーズを方法論の大枠、5フェーズを現在公開されているワークフローの実行単位として読み分けます。「AI-DLCは常に3フェーズ」と覚えるより、概念を知りたいのか、現行ワークフローを動かしたいのかを先に分ける方が安全です。実装に使う場合は、記事に書かれた数字ではなく、利用するバージョンのガイドを確認します。

現行の5フェーズで何をするのか

1. 0Initialization作業場所を作り、既存環境を検出し、状態を初期化する
2. 1Ideation意図、実現性、制約、範囲、体制を整理し、次へ進む判断をする
3. 2Inception要件、ユーザーストーリー、設計、作業単位、実行計画へ具体化する
4. 3Construction機能・非機能を設計し、コード、テスト、CIを作る
5. 4Operationデプロイ、環境、可観測性、障害対応を整え、結果を次の企画へ戻す

33ステージの内訳は、Initializationが3、Ideationが7、Inceptionが9、Constructionが7、Operationが7です。ただし、すべてを同じ重さで実行するチェックリストではありません。市場調査、実現性確認、ラフな画面、非機能設計などには実行条件があります。運用で得たフィードバックは次のIdeationへ戻ります。

Inceptionの9ステージには、既存コードの解析、チームの開発規則の確認、要件分析、ユーザーストーリー、画面、ドメイン設計、作業単位への分解、契約設計、デリバリー計画があります。要件分析は常に実行し、利用者向けの機能がある場合は受け入れ条件を持つユーザーストーリーを作ります。実装前に全部を確定するのではなく、Constructionへ渡す材料と未確定事項の境界を作る工程です。

成果物は、次の工程の入力としてつなぐ

各フェーズで文書を増やすこと自体が目的ではありません。Ideationで作る意図とスコープは、Inceptionの要件へ入ります。利用者向け機能では、要件を受け入れ条件を持つユーザーストーリーへ、ユーザーストーリーを依存関係を持つ作業単位と実行計画へ変えます。Constructionでは、その作業単位から機能設計、コード、テストを作ります。

このつながりがあると、テストが落ちたときに、コードだけでなく要件や設計まで戻って確認できます。反対に、要件とテストの間が切れていれば、AIはその場の指示に合わせて修正できても、どの利用者の必要を満たす変更なのかを追跡できません。AI-DLCがフェーズ間に検証ゲートを置くのは、後工程へ渡す前にこの切断を見つけるためです。

成果物の名称をそのまま導入する必要はありません。既に要件管理や設計判断、テスト管理の仕組みがあるなら、同じ情報を二重に持つより、どの記録が次工程の入力になるかを対応づけます。重要なのは書式ではなく、意図から運用まで判断の理由が途切れないことです。

検証ゲートは、何を保証するのか

現行ワークフローでは、InitializationからIdeationへ進む箇所を除き、フェーズの境界に検証ゲートがあります。自動検査が見るのは、必要な成果物が欠けていないか、要件と後続成果物のリンクが切れていないか、孤立した成果物や不整合がないかです。前工程の欠落を抱えたまま後工程が作り込むことを防ぎます。

ゲートを通れば、要件や設計の内容が事業として正しいと保証されるわけではありません。追跡できることと、判断が妥当であることは別です。たとえば、ユーザーストーリーに受け入れ条件があっても、その条件が利用者の課題を解いているか、許容するリスクが適切かは自動検査だけでは決まりません。

AI-DLCの公式説明も、AIが計画を作り、文脈を揃える質問をし、人の検証を受けてから実装する流れを置いています。AIが主導するとは、人が工程から消えることではなく、人の仕事を成果物の作成から意思決定へ寄せることです。

33ステージをすべて実施するのか

33は現行ガイドに定義されたステージの総数で、すべての案件で全項目を実行するという意味ではありません。各ステージには常時実行と条件付き実行があり、スコープ、案件の種類、実行計画で変わります。たとえば、既存コードの解析は既存システムを変更する場合に行い、ユーザーストーリーは利用者向け機能がある場合、詳細な画面はUIを作る場合に進みます。

省略は自由な近道ではありません。なぜ対象外なのかが、案件の範囲や条件から説明できる必要があります。小さな修正に市場調査や画面設計を毎回要求すれば工程が重くなり、反対に権限や外部接続を伴う機能で制約確認を飛ばせば、実装後に判断をやり直すことになります。

導入は、小さな機能を一周させる

最初から社内の開発標準を33ステージへ置き換える必要はありません。Nueなら、利用者が結果まで確認できる小さな機能を1つ選び、意図、対象外、受け入れ条件、実装、テストまでを一周させます。その過程で、AIが作れる成果物、人へ戻すべき判断、既存の承認と重複するゲートを確認します。これはAI-DLC公式の効果を示す実績ではなく、導入範囲を見極めるための進め方です。

見るべきなのは、生成したコードの量ではありません。要件からテストまで追跡できたか、判断待ちで止まる条件が明確だったか、運用で得た情報を次の要件へ戻せたかです。工程を増やすことではなく、AIが速く作るものと、人が責任を持って決めるものをつなぐことがAI-DLCの役割です。

NueのAI受託開発も、要件書の完成を開始条件にせず、解決したいことを1つ決めて動くものを作り、レビューから次の判断材料を得ます。ただし、NueがAI-DLCを導入して効果を測定したという意味ではありません。公式の方法論と、自社が公開している開発の進め方は分けて扱います。