生成AI

既存プロジェクトに「AI-DLC」を導入してわかった、AI駆動開発の現実

AI駆動開発

2026.07.22

はじめに

生成AIによるコーディング支援は急速に普及し、IDE組み込みのアシスタントから自律的に変更を行うエージェントまで、選択肢は増え続けています。一方で 「コード単体は書けるが、既存システムの文脈に沿った変更が難しい」「AIが生成した成果物の妥当性をどう担保するのか」 という課題に直面するチームも多いのではないでしょうか。

こうした課題に対しAWSが提唱する開発方法論が AI-DLC（AI-Driven Development Life Cycle） です。本記事ではAI-DLCのコンセプトと、既存プロジェクトに導入して見えてきたメリット・デメリットを整理します。

AI-DLCとは

AI-DLCは、生成AIをソフトウェア開発ライフサイクル全体に組み込むためのフレームワークです。要件定義からリリース後の運用までを複数のフェーズに分割し、各フェーズで AIと人間が「mob（モブ）」として共同作業する ことを基本としています。

特徴は次の3点です。

段階的アーティファクト生成: 各フェーズの成果物（ユーザーストーリー、ユニット設計、コンポーネントモデル等）をマークダウン文書として明示的に残す
mob elaboration（モブによる具体化）/ mob construction（モブによる構築）: AIがドラフトを生成し、人間（チーム全体）がレビュー・修正を加える協働モデル
トレーサビリティの確保: 要件→設計→実装まで成果物のチェーンを追跡可能にする

なぜAI-DLCが必要なのか

単にAIエージェントにコードを書かせるだけのアプローチ（いわゆる「vibe coding」）には、本番運用される既存プロジェクトに適用しづらい弱点があります。

AIが既存コードのドメイン知識やアーキテクチャ制約を踏まえずに変更を行ってしまう
生成プロセスがブラックボックス化し、出力物の妥当性レビューが困難になる
同じ要求から再度生成しても結果が再現せず、チームでの合意形成の足場にできない

AI-DLCは 「AIが書きやすいプロンプトを書く」のではなく、「人とAIが共有できる成果物を段階的に積み上げる」 発想で、これらの課題に応えようとするアプローチです。

AI-DLCと「AI駆動開発」「XX駆動開発」の関係

混同されやすいので位置づけを整理しておきます。AI-DLCの正式名称は AI-Driven Development Life Cycle であり、 AI駆動開発（AI-Driven Development）の一形態 です。両者は対立概念ではなく、AI駆動開発という広い概念のなかで「ライフサイクル全体を対象として、AIを中心にした開発プロセス」がAI-DLCにあたります。

同じAI駆動開発のなかには、次のようなスタイル差があります。

AIアシスト型コーディング: Copilot等の補完中心、人間が主導
vibe coding: 即興的にAIへ任せる進め方
構造化アプローチ: フェーズと成果物を定義し、AIと協働で段階的に積み上げる方法。代表例として AI-DLC（AWS提唱、ライフサイクル全体のフェーズ分割を主軸とする）や Spec-Driven Development（GitHub Spec Kit、AWS Kiro等が採用、仕様を起点とした成果物チェーンを主軸とする）がある

AI-DLCとSpec-Driven Developmentは 並列関係 にあり、どちらも構造化アプローチに属しますが、主軸の置き方が異なります。本記事はAI-DLCを中心に扱いますが、AI駆動開発という広い視点では、これらは相互に学び合える方法論として併走しています。

また、AI-DLCは設計・実装スタイル（DDD、TDD、BDD、Clean Architecture等の 「XX駆動開発」 ）を限定しません。フェーズ構造と成果物の流れを規定するのみで、各フェーズの中でどの設計手法を採用するかはチームに委ねられます。たとえばComponent ModelフェーズでDDDを、Code GenerationフェーズでTDDを採用することはAI-DLCの枠組みと両立します。

AI-DLCの進め方

AI-DLCは大まかに以下のフェーズで構成されます。各フェーズが固有のプロンプトを持ち、前フェーズの成果物を入力として次フェーズの成果物を生成します。

Inception: AIがビジネス要件から詳細な要件、ストーリー、ユニットへ変換
Construction: AIがアーキテクチャ、ドメインモデル、コード実装、テストを提案
Operations:AIがIaCとデプロイメントを管理

各フェーズの最後で人間がレビューし、必要に応じて差し戻すことで最終的な品質を担保します。それぞれのフェーズでは、以下のような作業ステップが実施されます。

Intent: 取り組む課題と達成したいゴールを自然言語で記述
User Stories: アクターと受け入れ基準を含むストーリーへ分解
Units: 独立してビルド・デプロイ可能な論理ユニットへグループ化
Domain Designs: ユニット内の責務分担とインターフェースを設計
Code Generation: ユニット単位で実装コードを生成
Build IaC / Operate: インフラ構築・運用への引き継ぎ

既存プロジェクトに導入するメリット

要求の言語化が強制される: 「設定変更の手間を減らしたい」のような曖昧な要望が、受け入れ基準付きのユーザーストーリーへ自動で展開される
設計判断の選択肢が明示される: ユニット分割の方針（凝集度重視/独立性重視など）をAIが複数案で提示するため、意思決定の質が上がる
早い段階で軌道修正できる: 設計段階のドキュメントレビューで方向性を直せるため、コードレビュー時の大きな手戻りが起きにくい
設計が知識資産として残る: 生成された成果物がそのまま設計ドキュメントとなり、新規メンバーへの引き継ぎ資料として再利用できる

既存プロジェクトに導入するデメリット・注意点

小規模タスクには重い: ストーリーから順に積み上げるため、数行の修正に適用するとオーバーヘッドが大きい
生成ドキュメント量の肥大化: 1機能あたりトータルで数千〜1万行規模のドキュメントが生成されることがあり、保守対象として扱うかは事前に方針を決める必要がある
既存コーディング規約への適合は別途必要: AIが提案するコンポーネント分割が既存規約と合わないケースがあり、規約や前提を成果物に反映させる工夫が要る
ドキュメント陳腐化リスク: 生成された設計文書は実装後にメンテナンスされないとすぐに現実と乖離する

実プロジェクトでの導入事例：設定ファイル整理

本番稼働しているプロジェクトに、サーバーレスアプリケーションで運用されている 設定ファイル群の整理タスク にAI-DLCを適用しました。背景には既存システム特有の以下の課題がありました。

同じ設定値が複数ファイルに分散しており、変更時の修正漏れリスクが高い
設定がソースコード構成と密結合しており、コードを理解しないと修正箇所を判断できない
設定ファイル構成をベストプラクティスに沿った形へ近づけたい

適用範囲

Intent から Code Generation までを実施し、運用フェーズは未適用です。具体的には、5つのユーザーストーリーを以下4ユニットへ分解しました。

設定検証ツール: 変更前後の挙動同一性を機械的に確認するためのスクリプト群
Bundle設定の集約: 重複していた設定の一元化
環境別設定の再構造化: 環境固有値とサービス共通値の分離
設定ドキュメントの整備: 変更シナリオとトラブルシューティングの体系化

効果と課題

Intent から Code Generation までを順に走らせることで、 「何を変えるべきか」が設計段階で言語化される という効果が大きく感じられました。特に、ユニット1の検証ツールが先行して実装されたことで、後続ユニットの実装時に「リファクタ前後で挙動が変わらないこと」を機械的に確認できる土台が整った点は、既存プロジェクトに対する変更としての安心感に繋がりました。

一方で、4ユニット分の設計ドキュメントは数千行規模となり、 生成された文書をどこまで正式な設計資産として保守するか が早期に課題となりました。 Inception, Constructionの各フェーズおよび作業ステップごとに50-500行程度のドキュメントが10-20ファイル程度作成され、理解を深めるための補足資料としてレビュー時にだけあればよいもの、方針決定の意図や根拠として残すべきものを区別することが難しいと感じました。