AI-DLC：スクラムとの違いから見るAI時代の開発手法

はじめに

AWSが提唱する「AI-DLC（AI-Driven Development Lifecycle）」という新しい開発手法をご存知でしょうか？

これは、従来のアジャイル開発手法（スクラムなど）を「AIを後付けする」のではなく、AIを中心に据えて開発手法そのものを再構想するという野心的な取り組みです。

現在携わっているプロジェクトを進めている中でこの「AI-DLC」というものを知りました。今回、プロジェクト全体への導入は時期尚早として見送られましたが、個人的に非常に興味深く、チームに断片的にでも取り入れられないかと考えています。

本記事では、AI-DLCの概要と、現在主流のスクラムとの違いを整理しながら、AI時代の開発がどう変わっていくのかを考えてみます。

AI-DLCとは

AI-DLC（AI-Driven Development Lifecycle：AI駆動開発ライフサイクル）は、Amazon Web Servicesが提唱する、AIを中心に据えた新しい開発手法です。

従来のアジャイル開発手法は、人間が主導し2〜4週間のスプリントで進めることを前提に設計されていました。しかし、AIの進化により、開発サイクルを数時間〜数日で回せるようになってきています。AI-DLCは、既存の手法にAIを後付けするのではなく、「AIが開発を主導し、人間が承認・検証する」という発想で開発プロセスそのものを再設計しています。

具体的には、AIが要件分解、設計、コード生成、テストを提案し、人間は重要な局面で検証・承認を行います。従来のスプリントは「Bolt（ボルト）」と呼ばれる数時間〜数日の超短期イテレーションに置き換わり、設計品質を保ちながら開発速度を劇的に向上させることを目指しています。

出典：AWS AI-DLC ホワイトペーパー

AI-DLCが解決しようとしている課題

従来の開発手法の限界

スクラムをはじめとする既存のアジャイル手法は、人間が主導する長期プロセスを前提に設計されています：

• スプリント期間：2〜4週間
• デイリースタンドアップ、レトロスペクティブなどの定期的な儀式
• ストーリーポイントによる見積もり
• ベロシティによる進捗管理

しかし、AIを適切に活用していくことで、開発サイクルを数時間〜数日で回せるようになってきているのを実感しています。

後付けではなく再構想

AI-DLCは、既存の手法にAIを無理やり当てはめるのではなく、第一原理から開発手法を再設計します。
論文では「私たちには自動車が必要であり、より速い馬車ではない」と表現されています。

スクラムとAI-DLCの主な違い

1. 会話の方向が逆転

観点	スクラム	AI-DLC
主導者	人間	AI
会話の流れ	人間 → AI：「これをやって」	AI → 人間：「次はこれをやりましょう。A案とB案があります」
人間の役割	実行者・指示者	承認者・検証者

スクラムの場合：
開発者がタスクを分解し、AIに「このコードを書いて」「このテストを作って」と指示します。

AI-DLCの場合：
AIが高レベルの意図を受け取り、タスク分解、設計、実装オプションを提案し、人間は重要な局面で承認・選択します。

例えるなら、Google Mapsのようなもの：

• 人間が目的地（意図）を設定
• AIがルート（タスク分解と推奨事項）を提案
• 人間は監視を維持し、必要に応じて調整

2. イテレーション期間の劇的な短縮

項目	スクラム	AI-DLC
名称	Sprint（スプリント）	Bolt（ボルト）
期間	2〜4週間	数時間〜数日
計画頻度	スプリントごと	継続的
フィードバック	スプリント終了時	リアルタイム

AI-DLCでは、スプリントを**Bolt（ボルト）**と改名し、「前例のない速度を提供する迅速で集中的なサイクル」を強調しています。

3. 設計技法の位置づけ

スクラムの場合：

• 設計技法（DDD、BDD、TDDなど）はスコープ外
• 「チームで決めてね」というスタンス
• 結果として設計品質にばらつきが生じる

AI-DLCの場合：

• 設計技法をコアに統合
• ドメイン駆動設計(DDD)などをAIが自動適用
• 開発者は検証と調整のみ

これにより、「より良いシステムをより速く構築する」ことを目指します。

4. 見積もりと指標

スクラムの場合：

• ストーリーポイントで工数見積もり
• ベロシティで進捗管理
• タスクの難易度（簡単/中程度/困難）を区別

AI-DLCの場合：

• AIがタスク間の境界を曖昧にする
• 工数見積もりの重要性が低下
• ベロシティよりもビジネス価値を重視

AI-DLCの主要な成果物

Intent（意図）

「レコメンデーションエンジンを開発する」のような高レベルの目標

Unit（ユニット）

Intentを独立した機能ブロックに分解したもの（スクラムのエピックに相当）

Bolt（ボルト）

超短期間のイテレーション単位（スクラムのスプリントに相当）

Domain Design（ドメイン設計）

AIが自動生成するビジネスロジックのモデル

Deployment Units（デプロイメントユニット）

テスト済みでデプロイ可能なパッケージ

AI-DLCの3つのフェーズ

1. Inception Phase（開始フェーズ）

Mob Elaborationという儀式を実施：

• 全員が1つの部屋に集まる（スクラムのプランニングに近い）
• AIが意図をユーザーストーリーとUnitに分解
• チーム全員でレビュー・調整
• 数週間の作業を数時間に圧縮

スクラムとの違い：
スクラムのスプリントプランニングは人間が主導しますが、AI-DLCではAIが初期提案を行い、人間が検証・調整します。

2. Construction Phase（構築フェーズ）

Mob Constructionで全チームが協働：

• AIがドメインモデル → 論理設計 → コード → テストを生成
• 開発者は各ステップで検証・承認
• 重要な決定（トレードオフなど）は人間が判断

スクラムとの違い：
スクラムでは開発者が個別にタスクを実行しますが、AI-DLCでは全員が同じ部屋で、AIの提案を検証しながら進めます。

3. Operations Phase（運用フェーズ）

• AIがログやメトリクスを分析して異常検知
• 問題の解決策を提案
• 開発者が承認したら実行

スクラムとの違い：
スクラムは開発フェーズに焦点を当てますが、AI-DLCは運用フェーズでもAIの積極的な活用を想定しています。

人間の役割はどう変わるのか？

スクラムにおける人間の役割

• タスクの分解と実行
• コードの記述
• テストの作成
• 設計の決定

AI-DLCにおける人間の役割

• 承認者・検証者として機能
• AIの提案を検証
• 重要な決定を下す
• トレードオフを判断
• リスクを管理

各ステップで人間がチェックすることで、エラーが大きくなる前に修正できます。

役割の変化

スクラムの役割

• プロダクトオーナー
• スクラムマスター
• 開発チーム（フロントエンド、バックエンド、インフラ、DevOps、セキュリティなど専門化）

AI-DLCの役割

• プロダクトオーナー
• 開発者（専門化サイロを超越）

AIがタスク分解と意思決定を支援することで、従来の専門化された役割の境界が曖昧になります。

実践するには？

AI-DLCの論文には、AIとやり取りするための具体的なプロンプト集が付録として含まれています。

例えば、ユーザーストーリー作成時のプロンプト：

あなたの役割：あなたは経験豊富なプロダクトマネージャーです。

今後の作業を計画し、計画の各ステップにチェックボックスを付けて
mdファイルにステップを記述してください。

重要な決定を独自に行わないでください。
計画を完了したら、私のレビューと承認を求めてください。

私の承認後、同じ計画を一度に1ステップずつ実行できます。

このように、AIに「計画 → 承認待ち → 実行」のサイクルを守らせることで、人間の監視を確保します。

採用のアプローチ

AI-DLCは、既存のアジャイル手法から大きく逸脱していないため、比較的容易に採用できるよう設計されています。

• 実践による学習
  • ドキュメントやトレーニングではなく、実際のプロジェクトでAI-DLCの儀式を実践しながら学ぶ。
  • （AWSは「AI-DLC Unicorn Gym」という支援プログラムを提供しているようです。）
• 開発者エクスペリエンスツールへの組み込み
  • 既存の開発ツール（JiraやBacklogのようなプロジェクト管理ツール、あるいは企業が独自に構築している開発統合ツール）にAI-DLCを組み込むことで、普段使っているツールの中で自然に実践できるようになります。
  • 例えば、Jiraに「Intent」を入力すると、AIが自動でユーザーストーリーとUnitに分解して登録してくれる、といったイメージです。

現実的な課題と考察

AIの現在の能力

AI-DLCは、AIの将来の可能性については楽観的ですが、現在の状態については現実的です：

• 高レベルの意図を完全自律的にコード化するには、まだ信頼性が不十分
• 人間の監視なしに独立して動作させるのは危険
• 解釈可能性と安全性の確保が必要

バランスの取り方

• AI支援：開発者が主導、AIは補助 → AIの潜在能力を引き出せない
• AI駆動：AIが主導、人間が監視 → AI-DLCが目指すバランス
• AI自律：AIが完全自律 → 現時点では時期尚早

スプリント期間の議論との関連

以前の記事「1週間？2週間？スプリント期間で迷ったときの決め方とレビューを分けた話」では、1週間スプリントと2週間スプリントの選択について議論しました。

AI-DLCの視点から見ると：

• 1週間スプリントでも、AI時代には長すぎる可能性がある
• 数時間〜数日のBoltが新しい標準になるかもしれない
• ただし、ステークホルダーへの報告は隔週でも良い（レビューの分離）

私が属しているチームが実践している「レビューを目的別に分離する」というアプローチは、AI-DLCの考え方とも整合しているため、段階的に取り入れていけそうだと感じています。

開発チームへの段階的な導入

現実問題として、いきなりInception Phase（開始フェーズ）のような初期段階から組み込むのはハードルが高いと感じています。そこで、まずは現在のスプリントを回しながら、Construction Phase（構築フェーズ）を少しずつ組み込んでいくのが現実的な第一ステップではないかと考えています。

具体的には、AIにドメインモデルや設計の提案をしてもらい、開発者が検証・承認するという流れを試してみることから始められそうです。

また、プロジェクト全体に展開していくには、導入効果を可視化することも重要です。従来の開発サイクルと比較して、開発スピードや効率がどの程度向上したのかを測定し、開発に直接関わっていないステークホルダーにも納得してもらえるデータを示していく必要があると思っています。

まとめ

AI-DLCは、従来のスクラムを置き換えるというよりも、AI時代に最適化された開発手法の1つの形を提示しています。

主な違いのまとめ

観点	スクラム	AI-DLC
主導者	人間	AI
イテレーション	2〜4週間	数時間〜数日
設計技法	スコープ外	コアに統合
見積もり	ストーリーポイント	ビジネス価値重視
人間の役割	実行者	承認者・検証者
専門化	役割が分離	役割が収束

これからの開発

AI-DLCが示唆するのは：

1. イテレーションの高速化：週単位から時間・日単位へ
2. 会話の逆転：人間が指示するのではなく、AIが提案する
3. 継続的な検証：各ステップで人間が監視・承認
4. 設計品質の自動化：AIが設計技法を適用、人間は検証

まだ実験的な段階ですが、AIの進化とともに、このような開発手法が現実的になっていく可能性は高いのかなと思います。私自身も、開発者やスクラムマスターのロールを通して積み重ねてきた従来の開発手法や思考パターンが、根底から変わろうとしていることをひしひしと感じています。

私たち開発者は、「AIに何をやらせるか」から「AIの提案をどう検証・承認するか」へと、役割をシフトしていく必要があるのかもしれません。

参考資料

• AI-Driven Development Lifecycle (AI-DLC) Method Definition - Amazon Web Services, Raja SP

関連記事

• 1週間？2週間？スプリント期間で迷ったときの決め方とレビューを分けた話