AI-DLC（AI-Driven Development Life Cycle／AI駆動開発ライフサイクル）は、AWSが2025年7月に提唱した、ソフトウェア開発のライフサイクル全体をAI前提で組み直す方法論です。AIを既存の工程に後付けするのではなく、計画の立て方もチームの動き方も作り替える点に特徴があります。

この記事では、AI-DLCの定義、従来のSDLC・アジャイル開発との違い、3つのフェーズと10の設計原則、AI駆動開発（AIDD）や仕様駆動開発（SDD）との違い、実際に手を動かして試すための手順、導入でつまずきやすいポイントまで解説します。

AI-DLCとは

AI-DLCは、AIを開発プロセスの中心的な協力者として位置づける開発方法論です。AWSが2025年7月31日にAWS DevOps Blogで公開し、日本語版は同年8月8日に公開されました。

AWSは、従来のソフトウェア開発ライフサイクル（SDLC）の課題を「人間主導の長期的なプロセス」にあるとしています。プロダクトオーナーもエンジニアもアーキテクトも、計画や会議といった本質的ではない活動に時間の大部分を使ってしまう。AI-DLCは、この構造そのものを組み替えようとする提案です。

AIアシストの時代からAI駆動の時代へ

AWSは方法論の定義文書（Method Definition Paper）の中で、AI活用の段階を2つに分けています。コード生成やバグ検出、テスト生成といった個別タスクをAIが支援する段階が「AIアシスト（AI-Assisted）の時代」です。そしてAIの守備範囲が要件の具体化、計画、タスク分解、設計へ広がり、AIが開発プロセスの進行そのものを担う段階を「AI駆動（AI-Driven）の時代」と呼びます。

AI-DLCが問題にしているのは、AIアシストの使い方のまま留まることです。人間主導を前提に設計された既存の手法にAIを継ぎ足しても、AIの速度と能力を活かしきれず、古い非効率を温存してしまう。だからライフサイクルの側を再設計する、というのがこの方法論の出発点です。

「AIが実行し、人間が監視する」への反転

AI-DLCの中核は、人間とAIの役割を入れ替えるメンタルモデルにあります。AWSの表現では「AIが計画を作成し、明確化を求め、人間が重要な決定を行う」となります。

従来のAI活用は、人間が作った計画やタスクをAIに渡して実行させる形でした。AI-DLCではこれが反転し、AIが体系的に詳細な作業計画を作成したうえで、意図のすり合わせとガイダンスを人間に求めます。人間の仕事は、コードを書くことから、AIが提示した計画と成果物を評価して意思決定することへ移ります。

もうひとつの柱が、チームのコラボレーションです。AIが重い作業を引き受けることで、チームはリアルタイムでの問題解決、創造的思考、迅速な意思決定に集中できる、という設計になっています。

AI-DLCと従来のSDLC・アジャイル開発との違い

AI-DLCはゼロから発明された別物ではなく、既存手法をAIの速度に合わせて再設計したものです。どこが引き継がれ、どこが置き換わったのかを、SDLCとアジャイル開発のそれぞれと比べて整理します。

SDLCとの違い

要件定義から設計、実装、テスト、運用へ進む段階構造そのものは、AI-DLCも共有しています。違うのは各段階の主導権と時間軸です。SDLCでは人間が各工程の成果物を作り、レビューや会議で次工程へ引き渡します。AI-DLCでは各工程の成果物ドラフトをAIが作り、人間の検証を経た成果物が次工程のコンテキストとして蓄積されていきます。工程間の引き継ぎコストを減らし、数週間単位だった工程を時間・日単位に縮めることを狙った設計です。

アジャイル開発との違い

アジャイル開発の短いイテレーションを、AI前提でさらに縮めたのがAI-DLCです。スプリントに紐づく儀式、たとえばデイリースタンドアップや振り返り、ストーリーポイントによる見積もりは、イテレーションが週単位であることを前提に成立してきました。AWSはサイクルが時間・日単位になるとこの前提が崩れるとして、ベロシティのような指標の妥当性自体を問い直しています。

一方で、すべてを捨てるわけではありません。ユーザーストーリーやリスク管理簿のように人間の検証に効く成果物は残すこと、既存のアジャイル実践者が1日で実践を始められる学習コストに抑えることが、方法論の設計目標として明記されています。アジャイルの否定ではなく、AI前提の後継と捉えるのが正確です。

AI-DLCの3つのフェーズ

AI-DLCは開発ライフサイクルを3つのフェーズに分けます。

Inception：意図を作業単位まで割る

出発点は「何を作りたいか」というビジネス上の意図です。AIがこれを要件へ、要件をストーリーへ、ストーリーを作業単位へと段階的に分解していきます。

このフェーズで効いてくるのが、意図のすり合わせです。AIは分解の途中で人間に質問を投げ、曖昧な部分を潰しながら進みます。AWSはこの継続的なすり合わせを品質面の効果として挙げており、AIによる抽象的な解釈ではなく、頭に描いているものを正確に構築できるとしています。

成果物も具体的に定義されています。Method Definition Paperでは、このフェーズの出力としてユーザーストーリー、非機能要件、リスクの記述、ビジネス意図に紐づく測定基準、Boltの計画案などが挙げられています。数週間から数ヶ月かかっていた逐次の要件作業を数時間に圧縮できる、というのがAWSの説明です。

Construction：設計から実装・テストまで

論理アーキテクチャとドメインモデルの提案から、コードの実装、テストまでをAIが進めます。ここでも人間は書き手ではなく、アーキテクチャの選択と技術的決定の判断役に回ります。設計上の判断はArchitecture Decision Record（ADR）として文書に残され、人間の検証対象になります。

Operation：IaCとデプロイ

デプロイと運用も対象に含まれます。Infrastructure as Codeとデプロイメントの管理までをライフサイクルの内側に置くのが、コーディング支援ツールとの決定的な違いです。

運用開始後の姿も描かれています。AIがメトリクス・ログ・トレースといったテレメトリを分析して異常やSLA違反の予兆を検出し、あらかじめ定義されたランブックと連携して対処案を提案する。実行に移すのは人間が承認してからです。

ただし、方法論として定義されている範囲と、ツールとして手元で動く範囲は同じではありません。後述する公開ルール集のREADMEでは、Operationsフェーズのデプロイ自動化や監視設定は今後の対象（future）と注記されています。まず動かせるのはInceptionとConstructionだと考えておくと、期待値を外しません。

AI-DLC独自の用語

AI-DLCは、アジャイル開発でおなじみの用語をいくつか置き換えています。名前を変えただけに見えますが、時間の単位が変わっている点が本質です。

スプリントがBoltに置き換わり、単位が週から時間・日へ縮んでいることが、AI-DLCが想定する開発速度を端的に表しています。AWSは、数週間かかっていたタスクを数時間または数日で完了できるとしています。

MobがつくAI-DLCの2つの活動は、AIとの対話をチーム全員で囲む進め方です。AIへの指示出しが特定の一人に閉じると、その人の解釈がそのまま仕様になってしまいます。全員でAIの質問に答える形にすることで、認識のズレをその場で潰します。

AI-DLCを支える10の設計原則

AWSはMethod Definition Paperで、AI-DLCの設計判断の根拠になっている10の原則を定義しています。フェーズや用語が「なぜこの形なのか」は、この原則から読むとつながります。原文の言い回しではなく要旨で整理します。

いくつかの原則には、はっきりした背景があります。原則3についてAWSは、ScrumやKanbanが設計技法を手法の範囲外としてきたことが品質の空白地帯を生んだと指摘し、2022年に米国だけでソフトウェア品質の問題が2.41兆ドルの損失をもたらしたとする調査を引いています。AI-DLCがドメイン駆動設計（DDD）を方法論の中核に据えるのは、この反省が理由です。

原則9では、人間によるレビューを機械学習の損失関数にたとえています。誤りを早い段階で検出して修正すれば、下流に流れてから直すよりもはるかに安くつく。人間の承認をボトルネックではなく品質装置として設計に組み込む、というAI-DLCの態度がよく表れた原則です。

AI-DLCのメリット

AWSは公式ブログで、AI-DLCが狙う効果を5つの観点で説明しています。導入判断の材料として一覧にします。

ただし、これらはAWSが提示する設計意図であり、どんな現場でも無条件に再現される数字ではありません。効果を左右する条件は、後述の「AI-DLCを実務で回すための2つの前提」で扱います。

AI駆動開発（AIDD）・仕様駆動開発（SDD）との違い

AI-DLCを調べていると、AI駆動開発や仕様駆動開発といった近い言葉に必ず出会います。3つは競合する概念ではなく、抽象度が違います。

AI駆動開発が「AIを前提に開発を組み直す」という考え方の総称であるのに対し、AI-DLCはその具体的な実装のひとつです。フェーズの区切り方も、Unit of WorkやBoltといった用語も、AWSが定めたものです。

仕様駆動開発との関係はもう少し重なります。AI-DLCのInceptionフェーズは、意図を要件・ストーリーへ分解して曖昧さを潰す工程なので、仕様駆動開発が重視する「先に仕様を固める」発想と目的が近い。違いは対象範囲で、仕様駆動開発が主に仕様と実装の対応関係を扱うのに対し、AI-DLCはデプロイと運用までをひと続きのライフサイクルとして定義します。SDDを代表するツールKiroでの実践はKiroで始める仕様駆動開発で解説しています。

対比でよく出るもうひとつの言葉がバイブコーディングです。こちらは自然言語の対話で雰囲気のままコードを生成していく進め方を指し、仕様や計画を先に固めるSDDやAI-DLCとは、曖昧さへの向き合い方が逆方向になります。

それぞれの詳細はAI駆動開発（AIDD）とはと仕様駆動開発（SDD）とはで解説しています。

AI-DLCを実際に試す

AI-DLCはホワイトペーパー上の方法論にとどまらず、AWSがオープンソースのワークフロー実装を公開しています。

awslabs/aidlc-workflows は、AIコーディングエージェントにAI-DLCのワークフロー規則を適用するためのリポジトリです。ライセンスはMIT-0で、手軽に始められるルール集（mainブランチ）と、2026年8月時点でGAとして案内されている本格実装のAI-DLC Workflows 2.0（v2ブランチ）の2系統が公開されています。まず方法論の流れを体験するならルール集、エージェントを組み合わせた実行基盤まで見るなら2.0です。

ルール集を使った導入手順

ルール集の対応エージェントは Kiro、Amazon Q Developer、Cursor、Cline、Claude Code、GitHub Copilot、OpenAI Codex です。特定のIDEに縛られない点が、チームへの展開では効いてきます。各エージェントの特徴はAI駆動開発の主要ツールで比較しています。

導入は次の流れです。

1. Releasesページから最新の ai-dlc-rules-v<番号>.zip を、プロジェクトの外側のフォルダにダウンロードする
2. aidlc-rules/ フォルダを解凍する
3. 使用するエージェント向けのディレクトリ（Kiroなら .kiro/steering/）へコピーする
4. エージェントとの対話を "Using AI-DLC, ..." で始める

プロジェクト側には aws-aidlc-rules/（コアワークフロー）、aws-aidlc-rule-details/（詳細ルール）、aidlc-docs/（生成ドキュメント）が置かれます。AIが生成した設計や要件が aidlc-docs/ に残るため、後から判断の経緯を追えます。

AI-DLC Workflows 2.0の新アーキテクチャ

AI-DLC Workflows 2.0は、ルールをエージェントに読み込ませる方式から、状態機械と監査ログを持つエンジンがワークフロー全体を進行させる実装へ進化しました。リポジトリのREADMEによると、構成は次のとおりです（2026年8月時点）。

• フェーズはInitialization・Ideation・Inception・Construction・Operationの5つに拡張され、33のステージで構成される
• 11のドメイン専門エージェント、2つのレビュー専任エージェント、計画を構成するコンポーザーの計14エージェントが分業する
• エンタープライズからワークショップまで9つのスコープを意図の記述から自動判定し、成果物の詳細度も3段階（Minimal／Standard／Comprehensive）から選べる
• すべてのステージに承認ゲートが置かれ、人間の修正内容を記録して同じ指摘を繰り返させない学習の仕組みを持つ
• 対応環境は Claude Code、Kiro IDE、Kiro CLI、Codex CLI、Cursor、opencode、GitHub Copilot

方法論の定義は環境に依存しない1つのコアとして管理され、各環境向けの配布物はそこから生成されます。どのエージェントで実行しても同じワークフローが動く、という設計です。

AI-DLC導入でつまずきやすいポイント

AI-DLCはすべてのステージに人間の承認を置く方法論です。そのため導入すると、負荷のかかる場所がコーディングからレビューと意思決定へ移ります。方法論の構造上起きやすいポイントを3つ挙げます。

レビューと承認が人間側のボトルネックになる

AIの生成速度が上がるほど、人間の検証待ちの成果物が積み上がります。AI-DLCは「AIが提案し、人間が承認する」を全ステージで繰り返すため、承認の速度がそのまま開発全体の速度上限になります。gaipack（KDDIアイレット株式会社）が整理しているAIDDスキームでは、実装の3原則のひとつに「段階的レビュー」を置き、判断基準・承認フロー・責任者を事前に明記することを求めています。レビューをその場の裁量に任せない準備が、承認ゲートを渋滞させないための実務的な答えです。

既存システムへの適用は準備の工程が増える

Method Definition Paperによると、既存アプリケーション（ブラウンフィールド）にAI-DLCを適用する場合、Constructionフェーズの前に、既存コードを静的モデル（コンポーネントの責務と関係）と動的モデル（主要ユースケースでの相互作用）へ引き上げるリバースエンジニアリングの工程が加わります。AIに渡すコンテキストを簡潔で正確にするための手順で、新規開発にはない準備です。ドキュメントが散逸した既存システムほどこの工程が重くなるため、後述するインプット品質の評価を先に済ませておくと、見積もりを外しにくくなります。

チームのレビュー経験が品質の上限を決める

AI-DLCでは、検証と意思決定の最終責任を人間が持ちます。裏を返すと、設計やセキュリティの妥当性を見抜くレビュー側の経験が、そのまま成果物品質の上限になります。AIDDスキームでも、人間が実施すべき判断や創造的なタスクまでAIに任せるのではなく、人間の判断をより正確で高速にするための支援ツールとしてAIを位置づけています。生成を任せる範囲を広げる前に、その出力を判断できるレビュー責任者を体制に確保しておくことが前提になります。

AI-DLCを実務で回すための2つの前提

AWSは、数週間かかっていたタスクを数時間または数日で完了できるとしています。ただしこの速度は、どんなプロジェクトでもそのまま出るわけではありません。AIDDスキームが掲げる「開発スピードを従来比2倍以上」という効果にも、インプット品質が80%以上という実現条件が付きます。AI-DLCのフェーズを回し始める前に、次の2つを確認しておくと空振りを避けられます。

なお、この記事で触れる定量的な数値は、いずれも特定の条件下でのお客様事例やAWSの提示値であり、同じ効果を保証するものではありません。

AI-DLCを適用する範囲を決める

AI駆動開発は全タスクが対象ではありません。タスクの性質によって効果の出方が変わります。AIDDスキームでは、次の分類で適用可否を判断しています。

AI-DLCのInceptionフェーズは要件定義に相当しますが、この表では要件定義・企画は★☆☆です。矛盾しているわけではありません。AIが担うのは分解と整理であって、優先度やゴールを決めるのは人間だという線引きです。AWSが「人間が重要な決定を行う」と書いているのと同じことを、タスクの粒度で表したものと考えるとつながります。無理にAI化しないことが、かえって品質を上げます。

インプット品質を先に評価する

もうひとつが、手元の資料がどれだけ整っているかです。整理度合いによって取るべき進め方が変わります。

AI-DLCはInceptionでAIに意図を分解させますが、渡す材料が散らかっていれば、分解の精度もそこで頭打ちになります。実際、要件定義の型を標準化したお客様事例では、要件定義ドキュメントの戻し回数が約3回から約1回へ約66%削減できましたが、効いたのはツールではなく定型フォーマットを決めたことでした。

資料の整え方には段階があります。AIDDスキームではGood／Better／Bestの3段階で整理しています。Goodは最低限のルールで、Excelの描画やテキストボックス、セル結合をやめ、色だけで意味を持たせずテキストで明示し、処理条件や分岐はGherkin形式（Given／When／Then）で書く。Betterはその上で、依頼内容や要件定義、議事録、処理条件をMarkdown化し、フロー図やER図をMermaidに寄せる段階です。Bestは全資料をMarkdown／Mermaidに統一してGitで一元管理し、修正が1箇所で全工程に波及する状態を指します。

要件定義の工程をどう組み立てるかは、AIDD要件定義でも支援しています。

AI-DLCに関するよくある質問

AI-DLCについて検索されることの多い質問と回答をまとめました。

AI-DLCとは何ですか？

AWSが2025年7月に提唱した、AIを開発プロセスの中心に据える開発方法論です。Inception・Construction・Operationの3フェーズでライフサイクル全体を定義し、AIが計画を作成して人間が意思決定を行う役割分担を取ります。

AI駆動開発とAI-DLCの違いは何ですか？

AI駆動開発は、AIを前提に開発を組み直すアプローチ全般を指す総称です。AI-DLCは、それを実現するためにAWSが定義した具体的な方法論のひとつで、フェーズの区切り方やUnit of Work・Boltといった用語まで定めています。

AI-DLCとSDDの違いは何ですか？

仕様駆動開発（SDD）は、仕様を一次情報として先に固め、そこから実装を導く手法です。AI-DLCのInceptionフェーズは目的が近いものの、AI-DLCはデプロイと運用までを含むライフサイクル全体を定義する点で範囲が広くなります。

AI-DLCはアジャイル開発を置き換えるものですか？

AWSはAI-DLCを、既存のアジャイル手法から大きく逸脱しない設計にしたと説明しています。ユーザーストーリーのように検証へ効く成果物は残し、既存の実践者が1日で実践を始められる学習コストを目標に置いています。実務上の一番大きな変化は、週単位のスプリントが時間・日単位のBoltに置き換わる点です。

AI-DLCはどのAIコーディングエージェントで使えますか？

awslabs/aidlc-workflows のルール集は Kiro、Amazon Q Developer、Cursor、Cline、Claude Code、GitHub Copilot、OpenAI Codex に対応しています。AI-DLC Workflows 2.0では Claude Code、Kiro IDE、Kiro CLI、Codex CLI、Cursor、opencode、GitHub Copilot が対応環境です（いずれも2026年8月時点）。

まとめ

AI-DLCは、AIを既存の開発工程に足すのではなく、計画の作り方とチームの動き方から組み替える方法論です。Inception・Construction・Operationの3フェーズ、Unit of WorkとBoltという時間単位の再定義、Mobでの意図すり合わせ、そしてそれらを支える10の設計原則が骨格になります。

方法論としての枠組みはAWSのMethod Definition Paperに、実装は awslabs/aidlc-workflows にあり、ルール集とAI-DLC Workflows 2.0のどちらからでも試せます。小さなプロジェクトでInceptionまでを一度回してみると、AIに任せられる範囲と、人間が判断すべき境界が見えてきます。

AI-DLCの考え方を実際の開発体制に落とし込みたい方は、お気軽にKDDIアイレットへお問い合わせください。