トップ > AI-DLC > AI駆動開発ライフサイクル（AI-DLC）についての社内勉強会の内容を公開します

AI駆動開発ライフサイクル（AI-DLC）についての社内勉強会の内容を公開します

AI-DLC
記事タイトルとURLをコピーする

こんにちは、サーバーワークスで生成AIの活用推進を担当している針生です。

先日、AWS（Amazon Web Services）が提唱する新しいソフトウェア開発手法「AI駆動開発ライフサイクル（AI-DLC）」についての社内勉強会を実施しました。

本記事は、社内勉強会で紹介した内容の主要なポイントを書き起こしたブログとなります。

※ 社内勉強会で使用したスライド資料については、以下のリンク先にて全ページ分を公開しています。 speakerdeck.com

AI-DLCとは何か

AI駆動開発ライフサイクル、AI-DLCについてご存じでしょうか？

AI-DLCは、AWSがホワイトペーパーで発表した、仕様駆動開発に対応する新しいソフトウェア開発手法です。従来の開発手法であるアジャイルやスクラムに「AIを後付け」するのではなく、ゼロベースでAIを前提として設計されている点が大きな特徴です。

最も衝撃的なのは、従来数ヶ月かかっていた開発が数日で完了するという点でしょう。これは誇張ではなく、AI-DLCの設計思想に基づいた結果として、ホワイトペーパーにて提示されているものです。

10個の主要な設計原則

AI-DLCには10個の設計原則がありますが、今回の勉強会では特に重要な5つを紹介します。

1. 後付けではなく最初から設計

既存の開発手法にAIを追加するのではなく、完全にゼロベースで設計されています。その結果、開発サイクルが数週間・数ヶ月単位から数時間・数日単位に短縮されます。

ホワイトペーパーには印象的な言葉があります。

「必要なのは自動車であり、より速い馬車ではありません」

アジャイル/スクラムを「馬車」と例えるなら、AI-DLCは「自動車」です。馬車を速くするのではなく、まったく新しい移動手段に切り替える発想です。

この原則により、デイリースクラムなど従来のスクラムイベントの多くが不要になります。

2. 会話の方向性の逆転

従来は人間がAIに指示していましたが、AI-DLCではAIが人間に問いかけるという関係に逆転します。

わかりやすい例えとして、Googleマップを考えてみてください。目的地を設定すれば、最適なルートは自動的に提案されます。私たちはそのルートを確認して承認するだけです。AI-DLCでも同様に、AIが全体像を示し、人間は重要な判断ポイントで意思決定を行う役割に徹します。

3. 設計技法のコアへの統合

従来のアジャイルフレームワークは、設計技法をチームの裁量に委ねていました。一方、AI-DLCは設計手法を中核に組み込んでいます。これにより、手探りの負担を減らしながら品質を維持し、高速なイテレーションを実現できます。

4. AIの能力に合わせた設計

完全自立動作を目指すのでもなく、人間がAIを補助するだけでもない。AI-DLCは、この両極端の中間を目指しています。

AIができることは最大限活用し、人間は検証・意思決定・最終確認に集中する。この役割分担により、AIの強みを最大限に引き出します。

5. 複雑なシステムの構築に対応

AI-DLCは、エンタープライズレベルの複雑なシステム開発に特化しています。設計パターンをベースとし、単純なシステムや技術判断が少ないアプリケーションは対象外です（そうしたものはノーコード/ローコードツールで対応します）。

※ 残り主要原則についてはスライド資料に記載しています。

AI駆動開発ライフサイクル(AI-DLC)のホワイトペーパーを解説 - Speaker Deck

コアフレームワーク：3つのフェーズ

AI-DLCは、3つのフェーズで構成されています。

用語の整理

まず、重要な用語を整理しましょう。

インテント（意図）: 目的を定義する（Googleマップで言う「目的地の設定」）

ユニット: AIが分割した作業単位（スクラムのエピックに相当）

ボルト: 最小単位のイテレーション（スクラムのスプリントに相当。ただし数時間〜数日単位）

インセプションフェーズ：意図からユニットへ

プロジェクトの最初のフェーズです。ここではモブエラボレーションという作業イベントが発生します。チーム全員が1つの画面を共有しながら共同作業を行います。

AIが意図をもとにユーザーストーリー、受入れ基準、ユニットに分割し、人間がレビューや設計調整を行います。所要時間は数時間〜数日です。

成果物として以下が生成されます。

  • PRFAQ
  • ユーザーストーリー
  • 非機能要件
  • リスクの説明
  • 測定基準
  • 提案されたポイント

コンストラクションフェーズ：ユニットからデプロイメントユニットへ

インセプションで作成したユニットを、実際にデプロイ可能な形に変換するフェーズです。所要時間は数日です。

ここでは以下の作業が行われます。

  1. ドメイン設計
  2. リリース設計
  3. コード生成
  4. 自動テスト実行
  5. デプロイメントユニット作成

AIがこれらを作成し、人間は検証と指摘を行います。

オペレーションフェーズ：デプロイから運用へ

最終フェーズでは、デプロイと運用を行います。ここでもAIが主導します。

テレメトリーデータをAIが積極的に分析し、異常検知や予測を行います。「こういう問題が起こっています」「こうした方がいいのでは」といった提案をAIが行い、人間はそれを見て承認や判断を下します。

グリーンフィールドとブラウンフィールド

AI-DLCは、新規開発（グリーンフィールド）と既存システム変更（ブラウンフィールド）の両方に対応しています。

ブラウンフィールド開発の場合、コンストラクションフェーズで「既存システムの理解」というステップが追加されます。既存コードや仕様設計をAIに読み込ませて学習した上で、構築を開始します。

詳細なフローチャートについて、スライド資料に記載しています。

AI駆動開発ライフサイクル(AI-DLC)のホワイトペーパーを解説 - Speaker Deck

実践のためのツール

勉強会では、実際にAI-DLCを実践するためのツールを紹介しました。

利用可能なツール

  1. Kiro: 仕様駆動開発の原則が組み込まれている
  2. Spec Kit: GitHubで公開されている仕様駆動開発対応ツール
  3. その他のAIコーディングツール: Amazon Q Developer、Claude Code、GitHub Copilotなど

プロンプトの活用

Amazon Q DeveloperやClaude Codeでも、適切なプロンプトを使うことでAI-DLCを実践できます。基本的な流れは以下の通りです。

  1. セットアッププロンプト: フォルダー構成や作業単位を指定
  2. ユーザーストーリー作成プロンプト: 製品説明を記述して入力
  3. 対話的な進行: AIからの質問に答えながらインセプションフェーズを進める
  4. 順次プロンプト実行: ユニット分割、ドメインモデル作成、コード生成のプロンプトを順番に実行

※ 残りのプロンプトついては、スライド資料に掲載しています。

AI駆動開発ライフサイクル(AI-DLC)のホワイトペーパーを解説 - Speaker Deck

所感：これは本当に実現可能なのか

正直なところ、初めてこの内容を読んだとき、「本当にこんなことが可能なのか？」と疑問に思いました。数ヶ月の開発が数日で完了するというのは、にわかには信じがたいです。

しかし、AWSのホワイトペーパーを読み込むうちに、これは単なる理想論ではなく、AIの能力を最大限に引き出すための体系的なフレームワークだと理解できました。

重要なのは、これまでの開発手法に「AIを追加する」のではなく、AIを前提としてゼロから設計し直すという発想の転換です。馬車を速くするのではなく、自動車を使う。この比喩が、AI-DLCの本質を表しています。

おわりに

AI-DLCは、アジャイルやスクラムに慣れ親しんだ開発者にとっては、まさに衝撃的な内容だと思います。デイリースクラムが不要になり、スプリントが数時間単位になり、AIが開発を主導する。これまでの常識が覆される開発手法です。

しかし、AIの進化を考えると、こうした開発手法が主流になる日は、そう遠くないのかもしれません。

詳細に興味のある方は、ぜひAWSのホワイトペーパーをご覧ください。

参考資料

針生 泰有(執筆記事の一覧)

サーバーワークスで生成AIの活用推進を担当