AI-DLC を調べてみた

背景・目的

生成AIをソフトウェア開発に取り入れる動きが進むなかで、多くの現場では「AIをコード補完アシスタントとして使う」か「AIに丸ごと生成させる」かの二択になりがちです。しかしどちらも、開発速度と品質の両立という点では物足りなさが残ります。

そんななか、AWSが AI-DLC（AI-Driven Development Life Cycle） という方法論を提唱し、ワークフローのルール群をオープンソースで公開しました。AIを「補助」ではなく「開発の推進役」に据えるという発想の転換が特徴です。

今回は、この AI-DLC がどういう考え方の方法論なのかを、公式ブログ・GitHubリポジトリに加えて、AWSが公開している方法論定義ペーパー（Method Definition Paper、Raja SP氏著）をもとに整理します。用語・10の原則・3フェーズ・従来手法との対比まで押さえ、全体像を掴むことを目的とします。実際にコーディングエージェントへ組み込んで動かす検証は次回に回します。

まとめ

項目	内容
これは何	AIを開発ライフサイクル全体の推進役に据え、人間が要所の意思決定を担うAWS発のAIネイティブ開発方法論
何ができる	Intent（意図）→ Unit → Bolt の階層で要件定義→設計→実装→テスト→運用をAI主導で回し、①開発速度の向上 ②品質の担保 ③手戻り削減を狙える
中核の発想	従来手法を「AIで後付け」せず第一原理から再設計。会話の主導権はAIが握り、人間は承認者に回る
3つのフェーズ	Inception（構想）→ Construction（構築）→ Operations（運用）。各フェーズが成果物を文脈として次へ引き継ぐ
反復単位	Sprint を Bolt に改称。数週間ではなく数時間〜数日単位の短く強い反復サイクルを前提とする
従来手法との違い	ウォーターフォールの弱点（手戻り）とAgileの課題（設計のばらつき）の両方に同時に手を打つ。設計技法（DDD/BDD/TDD）をコアに統合
実装手段	ワークフローのステアリングルールを配布。Kiro・Amazon Q Developer・Cursor・Cline・Claude Code・GitHub Copilot・OpenAI Codex に対応
本記事の射程	概要・従来手法との対比・10原則・3フェーズを整理し、既存の開発フローをAI-Driven化する進め方（設計段階）まで扱う

概要

用語の整理

記事で繰り返し出てくる用語を先に整理します。定義は方法論定義ペーパーに基づきます。

用語	意味
AI-DLC	AI-Driven Development Life Cycle。AIをライフサイクル全体の中心に据えたAIネイティブな開発方法論
Intent（意図）	達成したいことを表す高レベルの宣言（ビジネス目標・機能・性能スケーリング等）。AIによる分解の起点
Unit	Intentから導かれる自己完結した作業要素。DDDのSubdomainやScrumのEpicに相当。疎結合で並行開発・独立デプロイが可能
Bolt	AI-DLCの最小反復単位。ScrumのSprintに相当するが、build-validationを数時間〜数日で回す
Domain Design	Unitのビジネスロジックをインフラと切り離してモデリングする成果物（DDDの戦略的・戦術的要素）
Logical Design	Domain Designを非機能要件（NFR）向けに拡張し、アーキテクチャパターン（CQRS・Circuit Breaker等）を適用した設計。ADRも生成
Deployment Units	実行コード・構成・インフラ（コンテナ、Lambda、Helm、Terraform/CFN等）をまとめた運用成果物。各種テスト済み
Mob Elaboration / Mob Construction	チーム全員（Mob）でAIの問い・提案をリアルタイムに検証・調整する協働儀式

従来手法（ウォーターフォール・Agile）との対比

AI-DLCの位置づけを掴むために、伝統的なウォーターフォールおよびAgile（Scrum）との違いを整理します。

観点	ウォーターフォール	Agile（Scrum）	AI-DLC
進め方	要件→設計→実装→テスト→運用を前工程完了後に順次実行	短いスプリントで反復的に開発	AIがLevel 1 Planを提案し、人間の検証を挟みながら反復
反復単位	反復なし（一方向・後戻り困難）	Sprint（通常2〜4週間、書籍により4〜6週間）	Bolt（数時間〜数日）
主導するのは誰か	人間（工程ごとの担当）	人間（自己組織化チーム）	AIが会話を主導し提案、人間は承認者・検証者
設計技法の扱い	上流工程で人間が実施	範囲外（チームが任意に選択）	DDD/BDD/TDDを方法論のコアに統合
ドキュメント	工程ごとに大量の中間文書	動くソフトウェアを重視し文書は最小限	成果物を永続化しAIの「コンテキストメモリ」として活用
変更への強さ	弱い（後工程での変更コストが高い）	強い（反復ごとに軌道修正）	強い（人間の検証をloss functionとして早期に誤りを刈り取る）
フィードバック	各工程末・リリース後	スプリントレビュー単位	各ステップでリアルタイム（連続的）

ウォーターフォールは工程が一方向で、後工程になるほど手戻りコストが高くなるのが弱点でした。Agileはそれを短い反復で克服しましたが、設計技法をチーム任せにした結果、品質のばらつきという課題が残りました。

AI-DLCは、この2つの延長線上ではなく「第一原理からの再設計（Reimagine rather than Retrofit）」を掲げます。反復サイクルを数時間〜数日のBoltまで縮め、設計技法をコアに取り込み、AIが会話を主導することで、ウォーターフォールの弱点（手戻り）とAgileの課題（設計のばらつき）の両方に同時に手を打とうとしている、と読み取れます。

どういう発想か（10のKey Principles）

方法論定義ペーパーは、AI-DLCの土台として次の10の原則を挙げています。

原則	要旨
1. Reimagine rather than Retrofit	既存のSDLC/AgileにAIを後付けせず、第一原理から再設計する。「速い馬車ではなく自動車が必要」
2. Reverse the conversation direction	会話の主導権を反転。AIが意図をタスクへ分解して提案し、人間は承認者・選択者になる（Google Mapsの比喩）
3. 設計技法をコアに統合	Scrum/Kanbanが設計技法を範囲外にした反省から、DDD/BDD/TDDを方法論のコアに据える。本書はDDDフレーバー
4. AIの能力に合わせる	現状のAIは自律的に意図をコード化しきれないと認識。人間が検証・意思決定・監督の最終責任を持つ
5. 複雑なシステム向け	継続的な機能適応・高い設計複雑性・多数のトレードオフを伴う大規模/規制下のシステムが対象。単純な系はローコード/ノーコードへ
6. 人間との共生を高める要素は残す	ユーザーストーリーやリスクレジスタなど、人間の検証・リスク低減に不可欠な成果物は残し、リアルタイム利用向けに最適化する
7. 慣れによる移行容易性	既存実務者が1日で習得開始できることを目指し、馴染みある用語の関係を保ちつつ刷新（Sprint→Bolt等）
8. 責務を集約し効率化	AIのタスク分解・意思決定支援により、開発者がインフラ/フロント/バック/DevOps/セキュリティの専門サイロを越える。ただしPO・開発者は監督・検証・戦略判断の責務を保持
9. 段階を最小化しフローを最大化	ハンドオフを減らしつつ、人間の検証を「loss function」として要所に配置し、下流の無駄を早期に刈り取る
10. 決め打ちのSDLCワークフローを持たない	新規開発・リファクタ・不具合修正等の経路ごとに固定ワークフローを規定せず、AIがLevel 1 Planを提案し人間が検証・調整するAI-First方式をとる

公式ブログでも、この方法論の本質が次のように示されています。

AI-DLC is an AI-centric transformative approach to software development that emphasizes two powerful dimensions: AI Powered Execution with Human Oversight ... and Dynamic Team Collaboration ...

要するに、AIに任せきりでも人間任せでもなく、AIが手を動かしつつ要所で人間が舵を取る協働モデルです。

どう動くか（ワークフローと3フェーズ）

AI-DLC の中核は「AIがLevel 1 Plan（実装の流れ）を提案する → 人間が検証・修正する → さらにサブタスクへ分解する」という再帰的なループです。各ステップは戦略的な意思決定ポイントであり、人間の監督が loss function のように働いて、誤りが下流へ雪だるま式に広がる前に刈り取ります。

生成された成果物（Intent・ユーザーストーリー・ドメインモデル・テスト計画等）はすべて永続化され、AIがライフサイクル全体で参照する「コンテキストメモリ」になります。成果物は相互にリンクされ、前方・後方のトレーサビリティ（例：ドメインモデル要素と特定ユーザーストーリーの対応）が確保されます。

このもとで、開発は3つのフェーズで進みます。

フェーズ	AIの役割	主な儀式・成果物
Inception（構想）	Intentをユーザーストーリー・NFR・リスクへ分解し、Unitへ構成	Mob Elaboration。成果物はPRFAQ、ユーザーストーリー、NFR、リスク記述、測定基準、推奨Bolt
Construction（構築）	Domain Design → Logical Design → コード・テスト生成の順で実装	Mob Construction / Mob Testing。AWSサービスへのマッピング、自動テスト実行
Operations（運用）	テレメトリ（メトリクス・ログ・トレース）を分析し異常検知・SLA違反予測、runbook連携で対処案を提示	人間が検証・承認したうえでAIが対処を実行

各フェーズがより豊かな文脈を次へ引き継ぐことで、AIの提案が段階的に的確になります。

この往復構造を、時系列（上から下）で「人間・AI・成果物」の役割分担として並べると次のようになります。人間とAIが各ステップで検証・提案をやり取りし、AIが生成した成果物がコンテキストメモリとして次のステップへ引き継がれます。

人間 / Mob	AI	成果物（コンテキストメモリ）
Intent（意図）を提示	Intentを認識しLevel 1 Planを生成	Level 1 Plan
Level 1 Planを検証・修正	IntentをUnitへ分解し、ストーリー/NFR/リスクを提案	Units / PRFAQ / ストーリー / NFR / リスク / 推奨Bolt
Mob Elaborationでストーリー/NFR/リスクを調整	Domain Designを作成（DDDでモデリング）	Domain Design
Domain/Logical Designを検証しトレードオフを承認	Logical Design + ADR、コード・単体テストを生成	Logical Design / ADR / コード
生成コード・テストを検証	Deployment Unitsを生成し各種テストを実行	Deployment Units
デプロイ構成・AIの対処案を承認	テレメトリを分析し異常検知・対処案を提示	テレメトリ / runbook

表の読み方は次のとおりです。

• 上から下へ時系列で進み、Inception → Construction → Operations の順にフェーズが移る
• 人間とAIは各行で提案・検証をやり取りする（Mob Elaboration / Mob Construction のリアルタイム検証ループ）
• AIが生成した成果物は永続化され、次のステップのAIの入力（コンテキストメモリ）になる

適用シナリオ（Green-Field / Brown-Field）

方法論定義ペーパーは、新規開発と既存改修の2シナリオで具体例を示しています。

• Green-Field（新規開発）：Product Ownerが「クロスセル向けレコメンドエンジンを開発する」等の高レベルIntentを提示。AIがLevel 1 Planを生成し、チームが検証したうえでInception → Construction → Operationsへ進む。Inceptionでは「主要ユーザーは誰か」等の明確化質問から入る
• Brown-Field（既存改修）：新機能追加・NFR最適化・技術的負債返済など。ConstructionフェーズでまずAIが既存コードを意味的に豊かなモデル表現（静的モデル／動的モデル）へ「引き上げ」、開発者が検証・修正する。以降のフローはGreen-Fieldと同様

どう使うか（利用方法）

AI-DLC はコーディングエージェント向けの ステアリングルール として提供されます。プロジェクトのワークスペースにルール群を配置し、対応エージェントに読み込ませることで、AIがAI-DLCの三段階ワークフローに沿って振る舞うようになります。

対応プラットフォームは幅広く、Kiro、Amazon Q Developer IDE Plugin、Cursor IDE、Cline、Claude Code、GitHub Copilot、OpenAI Codex がサポートされています。たとえば Kiro の場合は Kiro Steering Files としてルールを .kiro/steering/ 配下に配置する形になります。

また、方法論定義ペーパーの Appendix A には、AIとやり取りするためのプロンプト例が収録されています。すべての成果物を aidlc-docs/ 配下（plans・requirements・story-artifacts・design-artifacts 等）へ保存し、計画を承認してから作業を進める運用が示されています。

導入アプローチと制約

導入を容易にするアプローチとして、ペーパーは次の2つを挙げています。

• Learning by Practicing：AI-DLCは一連の儀式（Mob Elaboration / Mob Construction 等）であり、ドキュメントや座学ではなく実案件で実践して習得する。AWSのSolution Architectが AI-DLC Unicorn Gym というフィールドオファリングとして提供している
• 開発者体験ツールへの組み込み：SDLCを横断する自社オーケストレーションツール（Cognizant FlowSource、Aspire CodeSpell、HCL AIForce 等）にAI-DLCを埋め込み、大規模組織でも自然に実践できるようにする

制約・前提としては次の点があります。

• 対象は複雑なシステム：高い設計複雑性・多数のトレードオフを伴う大規模/規制下のシステム向け。単純な系はローコード/ノーコードが適する
• 人間の関与が必須：検証・意思決定・監督の最終責任は開発者が持つ。AIへの完全放任は想定されていない
• チーム協働を前提とする：Mob Elaboration / Mob Construction は「1つの部屋・共有スクリーン・ファシリテーター」を想定した協働儀式

実践：既存の開発フローをAI-Driven化する進め方

ここでは、既存のフロー（試験計画→テストデータ→TDD→lint→PR→MRレビュー）をAI-DLC寄り、すなわちAI-Drivenに組み替えて回す進め方を整理します。以下の手順はまだ実行していない設計段階の内容です（※未検証）。実際の実行ログは次回の記事で扱います。

使うツールは、コーディングエージェント（Kiro CLI または Amazon Q Developer）と、awslabs/aidlc-workflows が配布するステアリングルールを想定します。

ステップ1：ステアリングルールを配置する

1. GitHubのReleasesからルールZIPをダウンロードし、Kiroのステアリングディレクトリへ配置します（※以下は未実行の手順）。

mkdir -p .kiro/steering
cp -R ~/Downloads/aidlc-rules/aws-aidlc-rules .kiro/steering/
cp -R ~/Downloads/aidlc-rules/aws-aidlc-rule-details .kiro/

1. あわせて成果物を蓄積するフォルダ（コンテキストメモリ）を用意します。方法論定義ペーパーのAppendix Aでは aidlc-docs/ 配下（plans・requirements・story-artifacts・design-artifacts 等）に保存する運用が示されています。

ステップ2：起点を「Intent」にしてAIに計画を出させる

ここが最大の切り替えです。人間が手順を並べるのをやめ、意図だけをAIに渡し、AIにLevel 1 Planを提案させます。

1. 次のような意図をAIに渡します（プロンプト例）。

コンポーネントXの結合試験を完了させたい。
仕様書は specs/ 、設計書は design/ にある。
結合試験の計画から検証までの進め方（Level 1 Plan）を提案してほしい。
順序と、観点の抜け漏れも指摘してほしい。
私が承認するまで実装・実行はしないこと。

1. AIが「試験計画→テストデータ→TDD→lint/security→PR→MRレビュー」に相当する流れを自ら提案します。人間はそれをレビューし、過剰・不足を調整します（Mob Elaborationに相当）。ここで人間は「手順を書く人」ではなく「承認する人」に回ります。

ステップ3：各ステップを「AI提案→人間承認」の往復で回す

承認したLevel 1 Planに沿って、各ステップをAI主導で進めます。人間は検証・承認に集中します。

ステップ	AI主導での回し方	成果物の保存先
試験計画	AIが設計書を読み、試験計画ドラフトと観点の抜けを提示。人間が承認	aidlc-docs/test-artifacts/plan.md
テストデータ	AIが仕様から期待値・境界値・異常系を生成し、十分性を自己レビュー。人間が承認	aidlc-docs/test-artifacts/data/
TDD	AIがテスト生成→実行→失敗の相関分析→修正案。100% PASSまで承認しながら反復	実行ログを同フォルダに蓄積
lint/format/security	AIが実行し、指摘を修正案つきで提示。人間が承認	—
Push / PR作成	AIが差分要約つきでPRを起票。人間が承認	PR本文
MRレビュー	AIが差分をチェックしコメント、問題なければ通す	レビュー記録

各ステップで、AIが生成した成果物を aidlc-docs/ に蓄積してリンクさせることで、AIが常に前工程の文脈（コンテキストメモリ）を参照できます。仕様↔試験計画↔テストデータ↔結果のトレーサビリティが保たれます。

ステップ4：小さく始める

いきなり全工程を回すと重いので、まずは1コンポーネント × ステップ1〜3（試験計画→テストデータ→TDD）に絞って往復を体感するのがおすすめです。残りのlint/PR/MRは同じ「AI提案→人間承認」パターンの拡張になります。

なお、Bolt（数時間〜数日の反復）やMob（1部屋集合）といったAI-DLCの儀式は、単一の試験フェーズに無理に持ち込む必要はありません。移植すべき中核は「AIが計画を提案し人間が検証する往復ループ」と「コンテキストメモリ」の2点です。

https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/
https://github.com/awslabs/aidlc-workflows

考察

• AIを「アシスタント」ではなく「推進役」に置き換え、会話の主導権まで反転させる発想が新鮮でした。従来のAgileに生成AIを後付けする形ではなく、ライフサイクルそのものを第一原理から再設計している点が本質的な違いだと感じます
• 人間の検証を loss function（下流の無駄を早期に刈り取る仕組み）と捉える考え方は、場当たり的なプロンプティング（Vibe Coding）から規律あるエンジニアリングへ移す狙いを明確に表していると思います
• 設計技法（DDD/BDD/TDD）を方法論のコアに統合している点は、品質のばらつきを抑えるうえで実務的に効きそうです。特にDDDフレーバーは、Unitを疎結合な境界づけられたコンテキストに分割して並行開発する狙いが明快でした
• 現場でも、要件の曖昧さが手戻りを生みやすいので、Inceptionフェーズの Mob Elaboration（明確化質問→ユーザーストーリー・NFR・リスクの合意）は特に効きそうだと考えます
• 一方で、Bolt（数時間〜数日）という短サイクルや「1つの部屋に集まるMob」形式は、リモート中心のチームや既存スクラム運用との擦り合わせが必要になりそうです。導入時のチェンジマネジメントが鍵になりそうです
• 次のステップとして、本記事の実践セクションで整理した進め方を実際に回してみたいです。まずは小さなUnitを1つ、Kiro もしくは Amazon Q Developer で Inception → Construction まで通し、体感の速度と品質を検証して次回記事にまとめる予定です

AI-Assisted と AI-Driven の境界（既存フローとの比較で見えたこと）

学びを深めるなかで、既存の開発フローに「AIレビュー」「AIによるテスト生成」「AIでPR作成」を組み込んでも、AI-DLCの狙う姿にはならないことに気づきました。方法論定義ペーパーは、この違いを AI-Assisted（AIが特定タスクを補助）と AI-Driven（AIが開発を駆動）という2つのパラダイムとして明確に区別しています。

境界を分けるのは、タスクにAIを何個使うかではなく、次の3点です。

観点	AI-Assisted（各タスクをAIが補助）	AI-Driven（AI-DLCが目指す姿）
会話の主導権	人間がAIに頼む。人間が主語	AIが問い・提案し、人間は承認者。原則2「Reverse the conversation direction」
計画（タスク分解）	人間が手順を固定し、AIは各作業をこなす	AIがLevel 1 Planを生成し、人間が検証・修正。原則10「No Hard-Wired Workflows」
成果物	各ステップでAI呼び出しが点在	成果物を永続化し連鎖させる「コンテキストメモリ」

公式ペーパーには次のようにあります。

AI recommends the Level 1 Plan based on the given pathway intention. Humans verify and moderate these AI-generated plans through interactive dialogue with AI

たとえば「試験計画作成→AIレビュー」「テストデータ作成 with AI」「TDD（テスト生成はAI）」「lint/security」「PR作成」「MRレビュー（AIチェック）」という一連の流れを組んでも、順序を人間が固定しAIに各作業を振っている限りは AI-Assisted の完成形にとどまります。同じタスク群でも AI-Driven に寄せるには、①起点をIntentにしてAIにLevel 1 Planを提案させる ②各ステップで人間は書き手ではなく承認者に回る ③成果物（仕様・計画・データ・結果・原因分析）をリンクしてAIが常に前工程の文脈を参照する、という組み替えが要ります。差分は「タスクの中身」ではなく「誰が段取りを握り、AIが計画層に入っているか」にあります。

この観点は、結合試験のような単一フェーズにAI-DLCを取り入れたい場合にも効きます。AI-DLCをフェーズ構造ごと持ち込むのではなく、「AIが計画を提案し人間が検証する往復ループ」と「コンテキストメモリ」という中核メカニズムだけを移植するのが現実的だと考えます。

参考

https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/
https://github.com/awslabs/aidlc-workflows
https://aws.amazon.com/blogs/devops/building-with-ai-dlc-using-amazon-q-developer/