AI-DLCとは？
AI-DLC（AI-Driven Development Lifecycle）は、2025年8月にAWSが提唱した 「AIを中心に据えた新しいソフトウェア開発の進め方」 のことです。
これまでのSDLC（要件定義→設計→実装→テスト→運用）は、AIを補助的に使用しつつも、まだまだ人間が中心に進める流れかと思います。
でもAI-DLCでは、設計や分解、検証や学習といった部分のほとんどをAIに任せ、人間はレビューや意思決定に集中する という新しい役割分担を目指しています。
会話イメージでの比較
従来のSDLC（AIは補助的ツール）
👩💼 プロダクトマネージャー:
「ユーザー管理機能を作りたいんだけど、要件定義まとめてくれる？」
👨💻 エンジニア:
「了解です。まず要件を整理して、画面設計とAPI仕様を起こします。
1週間くらいでドラフトを出せると思います。」
🤖 AIツール（補助）:
「ログイン画面のコード例と、テストケースのテンプレートを生成しました。」
👨💻 エンジニア:
「助かるけど、全体設計や要件の整合性までは見てくれないんだよな。
結局そこは人間が詰めないといけない。」
AI-DLC（AIが中核）
👩💼 プロダクトマネージャー:
「ユーザー管理機能を作りたい。要件を整理してくれる？」
🤖 AIエージェント:
「想定ユースケースは3つあります。さらに監査ログの要件が不足しているようです。
設計図・API仕様・テストケースをまとめた案を生成しました。レビューしますか？」
👨💻 エンジニア:
「いいね。まずは設計を確認して、必要なら修正を加えよう。」
👩💼 プロダクトマネージャー:
「最初からテストまでそろっているのは心強いね。レビューに集中できる。」
まとめるとこんな感じ
| 観点 | SDLC（AI補助あり） | AI-DLC |
|---|---|---|
| AIの位置づけ | 部分的なアシスタント（コード補完、テスト生成など） | プロセス全体を担う共同設計者 |
| 人間の役割 | 要件定義や設計を自力で進め、AIを必要に応じて利用 | AIの提案をレビューし、重要な判断に集中 |
| スピード | 各工程で時間短縮はできるが、人間依存度が高い | 工程全体がAIで一気通貫 → 大幅な短縮 |
| リスク | 抜け漏れは人間の確認次第 | AIの誤判断を人間がレビューする仕組み必須 |
| 体験 | 「便利な道具」としてのAI | 「一緒に仕事する仲間」としてのAI |
従来型は“アシスト付きマラソン”、AI-DLCは“伴走パートナーと一緒に走る”イメージです。
どう動くの？
AWSが示すAI-DLCの流れはこんな感じです。
| フェーズ | 内容 |
|---|---|
| Inception（発案） | ビジネス上の意図を出発点として、AIが要件、ユーザーストーリー、ユニット（小さな作業単位）などを生成。チーム全員で “Mob Elaboration” の儀式を通じて、AIの提案や質問を検証・調整します。 |
| Construction（構築） | 発案フェーズで得られたコンテキストをもとに、AIが論理的な設計（アーキテクチャやドメインモデル）、コードやテストを提案。ここでも “Mob Construction” と呼ばれる共同作業を通して、技術的な判断や設計の選択を人間がクリアにしていきます。 |
| Operations（運用） | 構築フェーズまでで積み上げられた文脈（要件・設計・テストなど）を使って、AIがインフラのコード管理やデプロイ等をサポート。チームはこれらを監視・レビューしながら、品質を保って進めます。 |
また、この方式では各フェーズ間で文脈が途切れないよう、「成果物や設計アーティファクト、計画などをプロジェクトリポジトリに保存し続けること」 が重視されています。
これにより、複数セッションにまたがっても一貫性が失われないようにする仕組みも組み込まれています。
併せて細かな用語なども刷新されています。
- Sprint → Bolt：短期間で集中するサイクル（数時間〜数日）
- Epic → Unit of Work：より小さな単位で作業を区切る
AI駆動開発との違い
ここまで読んで、AI駆動開発と何が違うんや？って思われた方もいるかもしれません。
「AI駆動開発」という言葉は、AIを活用してソフトウェア開発を進める取り組み全般 を指します。
例えば、GitHub Copilotでコードを書く、ChatGPTで要件定義を整理するといった、日々の開発にAIを“便利な道具”として取り入れる実践です。
一方で「AI駆動開発ライフサイクル」は、“プロセスの再設計” まで踏み込んだ考え方です。
単にAIを各工程で利用するのではなく、Inception（発案）→ Construction（構築）→ Operations（運用） という流れを定義し直し、その中でAIと人間の役割を整理しています。モブ型の設計やBoltといった新しい進め方を導入しているのも特徴です。
つまり、
- AI駆動開発：AIを使って開発を効率化するという“広い実践”
- AI駆動開発ライフサイクル（AI-DLC）：AIを前提に開発プロセスそのものを組み替えた“体系的なモデル”
と言えます。
イメージで例えるなら、
AI駆動開発が「電動自転車を使って通勤する」ことだとすると、AI-DLCは「電動自転車専用のレーンや交通ルールを整備し、全員が効率的に走れる仕組み」を指しています。
ポイント
良いところ
1. 開発スピードが段違いに速くなる
AIが要件定義から設計・コード生成・テストまで一気通貫で提案してくれるため、これまで数週間かかっていた作業が数日で完了する可能性があります。
例えば、「ユーザー管理機能を作りたい」と入力すると、翌日には画面設計・API仕様・テストコードまで揃って返ってくる。人間はレビューと修正に集中でき、ゼロから積み上げる必要がなくなります。
2. 品質と一貫性がそろう
AIは過去の設計パターンや社内ルール、セキュリティ要件を踏まえて提案できるので、「人によって品質がバラバラ」という課題を抑えられます。
これにより、レビュー時の細かい指摘が減り、全体の水準を一定に保ちやすくなります。
3. 人間は“考えること”に集中できる
テストコードや仕様書更新といった繰り返しの作業はAIに任せられるため、人間は「どの機能を優先するか」「顧客にどんな価値を届けるか」といった意思決定に集中できます。
これは「事務作業を秘書に任せて、自分は戦略会議に集中する」ようなイメージです。
課題点
1. 学習と反省の仕組みがまだ弱い
AIが出す成果は“その場しのぎの調整”に近く、過去の失敗や成功から学んで改善する仕組みはまだ不十分です。
人間なら「この前失敗したから気をつけよう」と思えることも、AIは毎回リセットされてしまうリスクがあります。
2. 文脈の記憶が難しい
要件の背景や顧客のこだわりなど、長期のプロジェクトでは膨大な文脈が発生します。
AIがそれをすべて保持して正しく次に活かすのはまだ難しいのが現実です。
例えば「最初の打ち合わせで“セキュリティ優先”と決めたのに、数か月後にはAIが“速度優先”の設計を提案してきた」といった食い違いが起きかねません。
3. 責任と役割の線引きが不可欠
AIが出した設計やコードに不具合があった場合、誰が責任を取るのか？特に公共系や金融系では「AIのせい」では済まず、結局は人間が責任を問われます。
そのため、レビューや承認のフローをどう組み込むかをあらかじめ定義することが必須です。
今後の展望
AI-DLCは「未来の開発を大きく変える可能性のある考え方」ですが、まだまだ育ち始めたばかりな印象です。
理論や仕組みづくり、フィードバックの設計など、実務と研究の両面で磨いていく必要があります。
これから期待したいのはこんな進展です。
- 実際のプロジェクトでのパイロット実装やケーススタディ
- フィードバックループやポストモーテムを取り入れた「学習・反省」の仕組み
- 文脈記憶やナレッジ共有を支えるシステムの発展
- 倫理・安全性・透明性を踏まえたガイドラインとの統合
AIを「ただの便利な道具」としてではなく、「一緒に伴走する仲間」として迎えるため、AI-DLCは、そのための第一歩になりそうです。