1. はじめに
クラウドサイン Product Engineering 部で主にフロントエンドエンジニアとして活動している山下（@kirehashi_3）です。
さて、生成 AI はエンジニアリングの現場で急速に存在感を高めています。この記事をご覧の皆さんもすでに開発業務において生成 AI を利用したことがあるでしょう。しかし現状の生成 AI の用途の多くは「特定の作業を便利にするツール」としての利用にとどまっており、開発プロセス全体を見据えた運用には至っていません。
AWS が提唱する「AI-Driven Development Lifecycle (AI-DLC)」は、AIの特定の作業といった限定的な利用を超えて、計画から実装、テスト、運用に至るまでソフトウェア開発のライフサイクル全体に AI を統合することを目指す新しい考え方です。本記事では、AWS が公開している「AI-Driven Development Lifecycle (AI-DLC) ホワイトペーパー」を参考に、その全体像を整理し、スクラムとの思想的な比較を通じて位置づけを明確にしたうえで、現場でどのように活用できるかを探っていきます。
2. AI-Driven Development Lifecycle（AI-DLC) とは
2-1. AI-DLCの背景となる思想
最初に AI-DLC の背景となる思想として重要なものを抽出して解説します。
1. 指示の流れを逆転させ、AIが提案する
既存の開発手法では人間が AI に指示を与える形で AI を利用していました。しかし、AI-DLC では AI にあらかじめ高レベルの意図を提示したうえで、AI 側から推奨案などを提示します。そして人間は案に対して承認者として意思決定を行う役割を担います。
これにより人間側は必要な意思決定に集中でき、速度と品質の両立が可能となります。
2. 設計技法をAI-DLCの中核要素に統合する
スクラムなどでは DDD (ドメイン駆動開発 / Domain-Driven Development) などの設計手法をフレームワークに含めておらず、チームの選択に委ねていました。しかし、これはソフトウェア品質の低下の要因となっていたとしています。
そこで AI-DLC では、DDD・TDD (テスト駆動開発 / Test-Driven Development) などの設計手法を中核に組み込んだうえで AI が自動適用することを前提としています。
3. 各フェーズにおいてリスク管理に必要な人間による検証と意思決定は保持する
現状では AI は人間の意図にもとづいてコードのすべてを自動生成するには信頼性が十分とは言えません。
よって、AI-DLC では開発者が最終的な検証、意思決定を行う役割を維持しています。
これにより AI による自動化の恩恵を受けつつも、安全性を保持できるようにしています。
2-2. AI-DLCのコアフレームワーク
次に AI-DLC で使われる用語について説明したうえで、AI-DLC のフレームワークを説明します。
- インテント（Intent）：達成すべき目的（ビジネス目標、機能など）を高レベルで記述したもの。
- ユニット（Unit）：インテントを疎結合かつ高凝集な作業単位に分割したもの。各ユニットはユーザーストーリーなどのタスクの情報を含み、測定可能な価値を提供するように設計される。
- ボルト（Bolt）：AI-DLC におけるユニットを実装するための最小の反復単位。スクラムのスプリントに相当するが、より短い数時間〜数日で実施される。またボルトはユニットごとに独立しており、並列に実行することも可能となっている。
- ドメイン設計（Domain Design）：ユニットのビジネスロジックを独立してモデル化した成果物。
- 論理設計（Logical Design）：ドメイン設計を拡張し、システム全体の機能的な関係性を定義した成果物。
- デプロイメントユニット（Deployment Units）：テスト済みで本番投入可能な成果物（コード・設定・インフラを含む）。
AI-DLC を実施する際のフローは 3 つのフェーズから構成されています。
- インセプションフェーズ：AI とチームが協調してインテントを収集し、ユニットに変換していくフェーズ。モブエラボレーションと呼ばれるイベント内で実施する。
- モブエラボレーション：AI が初期のユーザーストーリー、受け入れ基準、ユニット分解を提案する。参加者はその提案をレビュー・修正し、現実的な制約に合わせていく。
- コンストラクションフェーズ：インセプションフェーズで定義したユニットをテスト済みで運用可能なデプロイメントユニットに変換していくフェーズ。AI が中心として生成しつつ開発者は AI 成果物を検証・意思決定していく。AI-DLC ではモブコンストラクションでの実施を推奨している。
- モブコンストラクション：チームが同室で、AI の提案に対して検証・意思決定しボルトを完成させる作業すること。
- オペレーションフェーズ：システムのデプロイ、観測、保守を中心とするフェーズ。AI が監視や異常検知を担い、異常を予測して対処などのアクションを提案し、開発者が承認・実行する。
このワークフローにより AI が初期案として計画を提示し、人間が成果物を検証するという流れを実現できます。
2-3. AI-DLCのメリット
AI-DLC による最大のメリットは、開発速度を大幅に向上できることです。スクラムでは 1〜4 週間程度のスプリントで実施されていましたが、AI-DLC では数日のボルトという単位でリリースされるため大幅に高速化されます。これによりフィードバックへの対応なども高速化され、より早くユーザーの需要に適応することが可能となります。
また各フェーズで AI の成果物を人間が検証するため、AI 駆動でありながらチームの意図や制約から逸脱しにくいといったメリットも存在します。
AI-DLC についてより詳細を学びたい方は、AWS よりAI-DLCに関するホワイトペーパーが公開されているのでこちらをご覧ください。各種フェーズにおける AI のプロンプトについても紹介されているので、実際に試してみる際にも参考になると思います。
3. スクラムとの比較
多くのチームではスクラムがすでに導入されているかと思いますが、AI-DLC とはどのような違いがあるか背景思想の共通点や違いを比較します。
まず、スクラムと AI-DLC の背景思想はどちらも短いサイクルでフィードバックを得て改善を繰り返すことを重視しています。そして、顧客に素早く価値を届けることをゴールとしている点でも共通しています。しかし、そこに至る思想やプロセスには明確な違いがあります。
スクラムは人間同士の協調・合意を中心に据え、経験主義的な検査を通して適応を繰り返します。一方 AI-DLC は AI をプロセスの中心に据えています。人間は検証し承認するいわゆるガードレールとしての役割に据えることでより高速なイテレーションを実行し、フィードバックループをより速く回せるようになっています。
またスクラムはチームが各自で経験主義的に改善していくべきという思想から、意図的に不完全と呼べるフレームワークが提案されていました。これによりスクラムにおいては DDD などの設計技法などは含まれていません。しかし、AI-DLC はこの設計技法との分離がソフトウェア品質の低下を招いたとして設計技法を中核要素として組み込むことを提案しています。
4. 現時点でのAI-DLCの実現可能性
AI-DLC は開発のあらゆるフローを AI と統合したビジョンを描いていますが、そのすべてが現時点で実現可能というわけではありません。実務の観点から見ると、フェーズごとに AI 活用の成熟度には大きな差があります。
インセプションフェーズ（計画・設計）
現在の AI エージェントでも適切なコンテキストを提供すれば、要件を整理したり、ユーザーストーリーや設計ドキュメントのドラフトを生成できます。AI-DLC では AI はこうした初期成果物のたたき台を提示し、プロダクトオーナーや開発者、QA といった関係者がレビュー・修正することで、現実の制約や組織の状況に適合させていきます。したがって、AI-DLC が想定している「たたき台の生成」という役割は、現時点でも十分に実現可能な領域です。
コンストラクションフェーズ（実装＋テスト）
実装という領域においては AI はもっとも成熟度が高いフェーズといえます。Claude Code や Devin などといったさまざまな形態のコーディングエージェントがリリースされており、すでに実務レベルで広く使われています。AWS も Kiro という仕様書駆動開発*1に基づくコーディングエージェントを組み込んだ IDE をリリースしています。
テストについては、特にユニットテストの領域では AI コーディングエージェントが一定の性能を発揮できる段階にあります。一方で、統合テストや E2E テストの領域では mabl など生成 AI の活用などは始まっているものの、あくまで補助的な立ち位置であり人間による設計やレビューは欠かせません。よってテストの領域においては AI-DLC のフローの実現は部分的なものにとどまるでしょう。
オペレーションフェーズ（運用）
運用においても AI 活用の取り組みは進みつつあります。たとえば Datadog の Watchdog はログやメトリクスを解析して異常を自動検知し、インシデントの早期発見を支援しています。同様に、CloudWatch や他の監視ツールも AI を活用した要約や異常通知を取り入れており、運用における異常検出の支援においては活用が進んでいます。
一方 AI-DLC が構想するような「次にどのようなアクションを取るべきかを AI が提案し、場合によっては自動的に実行する」レベルにはまだ到達していません。実際の対応には人間の判断が必要であり、AI の役割はあくまで監視や情報整理の補助にとどまっているのが現状です。
5. まとめ
本記事では、AWS が提唱する AI-DLC の全体像を整理し、スクラムとの比較や実現可能性について考えてきました。
現段階では AI-DLC のフローのすべてを完全に実現することは難しいですが、AI をより高いレベルで統合した開発プロセスとして、取り入れやすいフェーズで取り入れていくことは可能です。
また AWS がリリースした Kiro においてもこの AI-DLC の「AI を中心に据えつつ人間に承認させる」という思想が現れています。今後、AWS はこの AI-DLC を実現するためのサービス展開を推し進めていく可能性が高いと個人的には考えています。
今後の AI 活用のトレンドの背景として知っておくことで、今後開発されていく AI を統合したサービスに対してもより理解が深まるのではないでしょうか。
*1:仕様書駆動開発の詳細はテックブログを参考ください。claude-code-spec-workflowで始める仕様書駆動開発
