AI駆動開発ライフサイクル「AI-DLC」とは？
2025年8月、AWSが ”AI-DLC（AI-Driven Development Lifecycle）” という 「AIを中心に据えた新しいソフトウェア開発の進め方」 を提唱しました。
現在のSDLCは、主に実装工程においてAIを補助的に使用しつつも、まだまだ人間の作業中心に進める流れかと思います。
対してAI-DLCは、要件定義から運用までの全工程の作業のほとんどでAIを主体的に動かし、人間はレビューや意思決定に集中する という役割分担を目指しています。
会話イメージ
従来のSDLC（AIは補助的ツール）
👩💼 プロダクトマネージャー:
「ユーザー管理機能を追加したいんだけど、要件定義と設計をまとめてくれる？」
👨💻 エンジニア:
「承知しました。まず要件定義を確認・作成し、既存機能との整合性を見ます。
その後、画面設計とAPI仕様をまとめます。プログラムは次のフェーズで進めます。」
👨💻 エンジニア → 🤖 AIツール:
「将来プログラムに入るとき用に、ログイン画面のサンプルコードと
併せて単体テストケースの雛形を出しておいて。」
🤖 AIツール:
「コード例とテストケース雛形を生成しました。」
👨💻 エンジニア:
「助かるけど、要件や設計の整合性は人間が責任を持って詰めないといけないのー。」
AI-DLC（AIが中核）
👩💼 プロダクトマネージャー:
「新しくユーザー管理機能を作りたいんだけど、要件定義と設計まとめてくれる？」
👨💻 エンジニア:
「了解しました。今日中にレビュー対象を共有します。」
👨💻 エンジニア → 🤖 AIエージェント:
「追加の要件として、このアプリのユーザー管理機能の想定ユースケースを整理してほしい。
次に他機能との整合性を踏まえて、全体に不足している要件があれば指摘して。
最後にAPI仕様とテストケースまで一式を提案してほしい。」
🤖 AIエージェント:
「承知しました。
～～～～～
要件定義フォルダにユースケースを3つ作成しています。
ただし、現在の監査ログ要件では一部内容に不足があるようでしたので、改善案を追加しています。
API仕様とテストケースを統合した案も生成しました。レビューしますか？」
👨💻 エンジニア:
「ありがとう！レビューするよ。」
🤖 AIエージェント:
「レビューが完了次第、この設計に基づいてプログラミングを自動生成します。
進捗レポートを出しながら進めましょうか？」
まとめるとこんな感じ
| 観点 | SDLC（AI補助あり） | AI-DLC |
|---|---|---|
| AIの位置づけ | 部分的なアシスタント（コード補完、テスト生成など） | プロセス全体を担う共同設計者 |
| 人間の役割 | 要件定義や設計を自力で進め、AIを必要に応じて利用 | AIの提案をレビューし、重要な判断に集中 |
| スピード | 各工程で時間短縮はできるが、人間依存度が高い | 工程全体がAIで一気通貫 → 大幅な短縮 |
| リスク | 抜け漏れは人間の確認次第 | AIの誤判断を人間がレビューする仕組み必須 |
| 体験 | 「便利な道具」としてのAI | 「一緒に仕事する仲間」としてのAI |
どう動くの？
AWSが示すAI-DLCの流れはこんな感じです。
| フェーズ | 内容 |
|---|---|
| Inception（発案） | ビジネス上の意図を出発点として、AIが要件、ユーザーストーリー、ユニットなどを生成。チーム全員で “Mob Elaboration” の儀式を通じて、AIの提案や質問を検証・調整・修正する。 |
| Construction（構築） | 発案フェーズで得られたコンテキストをもとに、AIが論理的な設計（アーキテクチャやドメインモデル）、コードやテストを提案。ここでも Mob Constructionを通して、技術的な判断や設計の選択を人間がよりクリアにする。 |
| Operations（運用） | 構築フェーズまでで積み上げられた文脈（要件・設計・テストなど）を使って、AIがインフラのコード管理やデプロイ等をサポート。チームはこれらを監視・レビューしながら、品質を保って進める。 |
また、この方式では各フェーズ間で文脈が途切れないよう、「成果物や設計アーティファクト、計画などをプロジェクトリポジトリに保存し続けること」 が重視されています。これにより、複数セッションにまたがっても一貫性が失われないようにするという仕組みです。
https://aws.amazon.com/jp/blogs/devops/ai-driven-development-life-cycle/
併せて細かな用語なども刷新されています。
- Sprint → Bolt：従来のスプリントを数時間～1日に集中するサイクル
- Epic → Unit of Work：より小さな単位で作業を区切る
AI駆動開発との違い
ここまで読んで、AI駆動開発と何が違うんや？って思われた方もいるかもしれません。
「AI駆動開発」という言葉は、AIを活用してソフトウェア開発を進める取り組み全般 を指します。
例えば、GitHub Copilotで対話形式でコーディングを進める、Cursorで自然言語的に設計を整理するといった、日々の開発にAIを“便利な道具”として取り入れる実践です。
一方で「AI駆動開発ライフサイクル」は、“プロセスの再設計” まで踏み込んだ考え方です。
単にAIを各工程で利用するのではなく、プロジェクトの流れを定義し直し、Inception（発案）→ Construction（構築）→ Operations（運用）という中でAIと人間の役割を整理しています。モブ型の設計やBoltといった新しい進め方を導入しているのも特徴です。
つまり、
- AI駆動開発：AIを使って開発を効率化するという広い実践
- AI駆動開発ライフサイクル（AI-DLC）：AIとの協働を前提に開発プロセスそのものを組み替えた体系的なモデル
と言えます。
イメージで例えるなら、
AI駆動開発が「可能な道路のみ電動自転車を使って通勤する」ことだとすると、AI-DLCは「電動自転車専用のレーンや交通ルールを整備し、全員が効率的に走れる仕組み」を指していると言えるかと思います。
AI-DLCのポイント
良い点
-
開発スピード向上
AIが要件定義から設計・コード・テストまで自動で提案し、人間はレビューに専念できるため、従来数週間かかった作業が数日で完了する可能性がある。 -
品質と一貫性の確保
過去の設計パターンや社内ルールを踏まえた提案ができ、成果物の品質のバラつきを抑えやすい。 -
人間は意思決定に集中
繰り返し作業をAIに任せ、優先順位や顧客価値といった判断に時間を使える。
課題点
-
暗黙知の扱いが弱い
経験則や非言語的な学びには弱く、明示されていない知識は活かしにくい。 -
文脈保持の限界
長期プロジェクトでは方針の一貫性が途切れる可能性があり、プロンプトやルール管理が必要。 -
責任と役割の明確化
AI出力の誤りに対する責任や承認フローを定義しないと、現場導入は難しい。
簡単に言うと、AI-DLCはスピード・品質・集中力を高めるが、暗黙知や文脈保持、責任分担の課題を乗り越える仕組みづくりがまだまだ必須 ってことですね。
今後の展望
AI-DLCは「未来の開発を大きく変える可能性のある考え方」ですが、まだまだ育ち始めたばかりな印象です。
（こんなのエラーが頻発して、レビューという名のエラー対応に追われるだけでしょ…）
と思われる方もまだ多いと思います。
理論や仕組みづくり、フィードバックの設計は、これからも実務と研究の両面で磨いていく必要がありそうです。
個人的に特に試してみたいのが モブエラボレーション.
上にも少し記述していましたが、アジャイル開発のモブプログラミングの発想を広げて、AIが生成したユーザーストーリーや要件をビジネスユーザー・エンジニア問わず、チーム全員で深掘り・具体化・修正していく取り組みです。
（elaborateの意味：苦心して作り上げた、入念な、手の込んだ、精巧な）
1プロジェクトとして要件の見落としや後工程での手戻りが減ることを目指すのはもちろん、組織の人材育成や社会のIT人材不足のような観点からもより良い未来を目指せる感じがしました
Discussion