AI-DLCは、AIにコードを書かせる方法ではありません。AIが計画を立てて質問を出し、人が判断して承認する。この役割分担を開発プロセスそのものに組み込む方法論です。
「AI-DLCを自社でも試すべきか」と聞かれたとき、判断材料になるのは用語の暗記ではなく、何が変わり、何が必要で、どこまで公開情報で裏付けられているかです。この記事では、定義と公式用語、スクラムや仕様駆動開発（SDD）との違い、日本での公開事例、導入の前提条件、小さく試す手順を、2026年10月時点の公開情報で整理します。
この記事でわかること
- AI-DLCの定義と、基本にある「AIが提案し、人が承認する」という考え方
- 3つのフェーズと、Mob Elaboration・Mob Construction・Bolt・Unit of Workの意味
- 従来のSDLC・スクラム・仕様駆動開発（Kiroなど）との違い
- 日本で公開されている実践例と、その数字の読み方
- 導入の前提条件、つまずきやすい点、小さく試す手順
AI-DLCは「AIを主役に据えて開発プロセスを作り直す」方法論
AI-DLC（AI-Driven Development Life Cycle）は、AIを開発プロセスの中心に置いて工程を組み直す方法論です。従来の工程にAIを足すのではなく、AIがいる前提で工程を作り直す点が出発点になります。
既存の開発にAIを足す方式との違い
多くのチームが今やっているのは、スクラムなどの既存の進め方はそのままに、コーディングの部分だけAIに任せるやり方です。コードを書く時間は縮まります。ところが、節約した時間がレビュー待ちや会議といった周辺の儀式で消えてしまう。AI-DLCはここを問題視します。
AWS公式ブログでは、これを「後付け（retrofit）ではなく再構想（reimagine）」と表現しています（AI-Driven Development Life Cycle: Reimagining Software Engineering）。計画づくりや要件の詰めといった上流まで、AIの得意なことに合わせて組み替えます。
基本思想は「AIが計画・提案、人が判断・承認」
進め方のループは単純です。AIが詳細な作業計画を作る。AIが確認のための質問を出す。人が内容を検証して承認する。承認されてから実装に進み、このループをすべての開発活動で繰り返します。
もう1つの柱が、チームの動き方です。定型作業をAIが引き受けるぶん、人はその場で集まって判断することに時間を使います。計画も要件もリポジトリ内に成果物として残るので、セッションが変わっても作業を続けられます。
AI-DLCは特定のツール名ではなく、進め方の型です。AWSはOSSの実装（awslabs/aidlc-workflows）を公開しており、現行の実装ではClaude Code、Kiro、Codex CLI、Cursor、GitHub Copilotなどに対応しています。ただし提唱時の原典はAmazon Q DeveloperとKiroが中心の記述でした。複数ツールで動くという点の根拠は、現行のリポジトリ側の記述です。
3つのフェーズ（Inception・Construction・Operations）
AI-DLCの作業は、Inception（計画）、Construction（設計と実装）、Operations（運用）の順に進みます。各フェーズの中身と成果物は次の表のとおりです。
| フェーズ | やること | 主な成果物 |
|---|---|---|
| Inception | ビジネス上の意図を、要件・ユーザーストーリー・作業単位（Unit）に落とす | 実行計画、要件、確認質問、ユーザーストーリー、Unit of Work |
| Construction | 論理アーキテクチャ、ドメインモデル、コード、テストをAIが提案し、人が確定する | 設計文書、コード、テスト |
| Operations | 蓄積した文脈を使い、AIがインフラ定義とデプロイを管理し、チームが監督する | IaC、デプロイ設定 |
成果物の具体名は、OSS実装の解説に基づく記述です。ワークスペース直下に文書として生成され、次の工程の入力になります。
Operationsについては、2026年1月時点の解説に、実装側でまだ成熟していないとするものがあります。現行リポジトリでの状況は公式の記述から確認できていません。最初から3フェーズ全部を回そうとするより、InceptionとConstructionから始める進め方のほうが現実的です。
公式用語を4つだけ押さえる
AI-DLCは、スクラムの用語を置き換える形で独自の言葉を持っています。最初に覚えるのは4つで足ります。
| 用語 | 意味 | 置き換え元 |
|---|---|---|
| Mob Elaboration | Inceptionで、チーム全員がAIの質問や提案をその場で検証する | 要件定義の会議 |
| Mob Construction | Constructionで、技術・アーキテクチャの判断をその場で明確にする | 個別の設計レビュー |
| Bolt | 週ではなく、時間〜日単位の短く集中したサイクル | スプリント |
| Unit of Work | Inceptionで要件から切り出す作業単位（原典に詳細な定義はない） | エピック |
Mobは、チーム全員がその場で一緒に検証・判断することを指します。AIが数分で出した案を、後日の会議にかけていては意味がない。だから判断者が全員そろう場を先に作ります。
Boltは短い1周のサイクル、Unit of Workはその対象となる作業単位です。AWS社員による入門記事では、BoltはConstructionで1つのUnit of Workを一巡する反復単位と説明されています。
ビジネス上の意図を書く起点として「Intent」という言葉も出てきますが、原典のブログに定義はなく、解説記事ごとに説明がまちまちです。この記事では扱いません。
スクラムやSDDとは役割が違う
AI-DLCは、従来のSDLCやスクラムを置き換える全体の進め方で、仕様駆動開発（SDD）とは担当するレイヤーが違います。比べる対象によって、答えの形が変わります。
SDLC・スクラムとの違いは「誰が先に動くか」
従来の手法は、人が主導して長い期間で回す前提でした。計画づくりと会議に時間がかかるのは、そのためです。AI-DLCは主導権を逆にします。
| 観点 | 従来のSDLC・スクラム | AI-DLC |
|---|---|---|
| 計画と質問 | 人が考えて会議で出す | AIが作って人に問う |
| 人の役割 | 作業と判断の両方 | 判断・承認・監督に集中 |
| 作業サイクル | スプリント（週単位） | Bolt（時間〜日単位） |
| 作業の単位 | エピック | Unit of Work |
| 合意の取り方 | 会議と非同期のやり取り | Mobによる同期的な協働 |
| 記録 | チケットや議事録に分散 | 成果物をリポジトリに永続化 |
AI-DLCは従来を全否定しているわけではありません。ドメイン駆動設計やアジャイル由来の要素は引き継いでいるとする解説があります。「アジャイルをやめる」のではなく、「人が動く前提で作られた儀式を、AIが先に動く前提で組み直す」と捉えるのが正確です。
原典にスクラムとの詳細な比較表はありません。上の表は、原典の記述を整理したものです。
仕様駆動開発（Kiroなど）とはレイヤーが違う
AI-DLCとSDDを同じ土俵で比べると、どちらを選ぶかという誤った問いが生まれます。AWS Japanのソリューションアーキテクトによる整理では、2つはレイヤーが違います（Kiro SDDの進化を整理する）。
| AI-DLC | 仕様駆動開発（Kiroの例） | |
|---|---|---|
| 扱う範囲 | チーム全体でシステムをどう作るか | 個々の機能をどう作るか |
| 位置づけ | 上位の方法論 | ツール側の仕組み |
| 主な成果物 | 要件、Unit of Work、設計、計画 | requirements.md、design.md、tasks.md |
接続点は明確です。Inceptionで切り出したUnit of Workが、Kiroの仕様（Spec）を作るときの入力になります。Unitが大きければ、複数のSpecに分けます。どちらも「各ステージの出力が次のステージの文脈になる」という原則を共有しています。
ここは二次情報で混乱が多い点です。「AI-DLCはSDDを含む工程全体」とまとめる記事もありますが、AWS Japanの一次情報は「同じレイヤーではない」としています。この記事は一次情報に従います。
使い分けの目安は簡単です。システム全体の進め方、役割分担、承認の流れを決めたいならAI-DLC。個別機能の仕様をAIに渡せる形で書き出したいならSDD。AWS Japanの整理では、InceptionのUnitをKiroのSpecの入力にする形で組み合わせられます。SDDだけで足りる小さな案件に、AI-DLCの全工程を適用する必要はありません。
AI駆動開発の全体像から確認したい方は、AI駆動開発とは何かの解説が入口になります。
日本では11社87名のワークショップと現場適用の例が公開されている
日本の公開事例は、2日間のワークショップと、自社プロダクトへの適用という2種類に分かれます。どちらの数字も、本番運用の実績ではない点に注意が必要です。
11社87名のUnicorn Gymでは2日間で成果物まで到達
2026年1月、AWS Loft Tokyoで合同のAI-DLC Unicorn Gymが2日間で開かれました。参加は11社87名で、各社6〜8名（エンジニア4〜6名とビジネス担当2名）で構成されています。1日目にInception、2日目にConstructionを実施しました（AWS Japan ブログ）。
公開されている成果は次のとおりです。個社の成果ではなく、参加者全体の例として載っています。
| 題材 | 想定していた期間 | ワークショップでの到達点 |
|---|---|---|
| IT資産管理 | 約8週間 | 2日でAWSデプロイまで |
| IoTデータ分析 | 約6か月 | 2日でUIからAPI連携まで |
| 金融機関のシステム更改の要件文書化 | 約1か月・10人弱 | 6人・2日 |
満足度は5点満点で4.56、肯定的な回答は98.8%、継続フォローを希望した参加者は92.5%でした。
ただし、これは2日間の集中ワークショップの数字です。通常業務にそのまま持ち込んだときの短縮率ではありません。
参加者が挙げた課題は、実は速度の話ではなかった
成果以上に注目したいのは課題の側です。出てきた課題の最多はセキュリティとコンプライアンスで、そのほか個人情報・機密情報の扱い、社内制度や承認プロセスとの整合、AI生成コードのレビュー体制が挙がっています。
レビューについては、「レビューする側の知識が追いつかない」という点が指摘されています。AIが速く作れるほど、人が確認する量は増える。速度の問題は、次の瞬間にレビューの問題へ移ります。
自社プロダクトに適用したSaaSメーカーの例
もう1つの公開例は、SaaSメーカーが既存プロダクトに適用した事例です（AWS Builders Flash）。3名のチームで取り組み、通常1〜2日かけていた社内ワークショップを数時間に圧縮しました。ドキュメント設計は、従来1人日以上かかっていたものが、数時間〜1人日になったと報告されています。
一方で執筆者自身が、リソース削減は「まだ明確に実感できる段階ではない」と書いています。成果の誇張がない分、この事例は参考になります。成功の鍵として挙げているのは技術ではなく、人、コミュニケーション、オーナーシップでした。
公開事例の短縮率は、体験会・PoC・新規開発のものが中心です。大規模な既存システムを長期運用している現場での定量的な実績は、公開情報の範囲では確認できていません。
導入判断は体制・レビュー・セキュリティの3点で決まる
導入の可否は、ツールの性能よりも、判断できる人がいるか、レビューが回るか、セキュリティの枠に収まるかで決まります。経営層や開発部長が見るべきなのはこの3点です。
試す前に確認する前提条件
最初に確認することは次の3つです。
- AIを操作する人と、成果物を判断する人がいるか。 ドライバーと呼ばれるAI操作役に加え、出てきた設計やコードの良し悪しを見極められるレビュー担当が必要です。完成度の判断基準や、AIが逸脱したときの対処が決まっていないと、承認が形だけになります。
- 関係者が同じ場で判断できるか。 Mobの前提は同期的な協働です。承認が数日かかる稟議フローのままだと、Boltの短いサイクルが成立しません。
- 情報の持ち出しルールが決まっているか。 セキュリティと機密情報は、ワークショップ参加企業の最大の懸念でした。使う環境とデータの範囲を先に決めます。
ツールを入れるだけでは不十分で、プロンプトや設定ファイルがあるだけではAI-DLCになりません。求められるのは、AIの提案を読んで良し悪しを判断できるレビュー能力です。AI駆動開発研修では、AIに計画を任せて人が承認する進め方と、その判断を支えるレビューの視点を、実務に近い題材で身につけられます。
向く案件と向かない案件
AI-DLCの強みは、要件の詰めから設計までを一気にまとめる場面で出ます。逆に、工程を回すコストが成果を上回る案件があります。
| 向きやすい | 向きにくい |
|---|---|
| 新規開発、新機能の立ち上げ | 小さな修正、typoの修正 |
| 要件があいまいで、関係者のすり合わせが要る案件 | 仕様が確定済みの受託 |
| 業務理解のある担当と開発者が同席できる案件 | 判断者が同じ場にそろえない案件 |
同じ傾向は、AI-DLCとSpec Kitを比較した検証ブログでも指摘されています。仕様を先に固める手法はどれも、小さな修正には過剰になります。
現場で起きやすいつまずき
つまずきは、技術よりも運用側で起きます。
AI生成コードをレビューできる人材の不足は、公開されている課題の中でも目立つ悩みです。レビューを経験の浅い担当に任せると、AIの誤りを素通りさせます。AIが暗黙の前提で補完した内容が、ハルシネーション（もっともらしい誤り）として入り込む問題もあります。
長い作業ではAIが保持できる文脈の限界にも当たります。成果物をリポジトリに残す設計は、これを避けるための仕組みでもあります。
Operationsまで広げる場合は、運用の成熟度が前提になります。監視、手順書、ガードレールが整っていない状態で自動化を進めると、事故の原因になります。段階導入が基本です。
AIにルールや文脈を持たせる設計については、ハーネスエンジニアリングの考え方が補助線になります。
小さく試す手順
試すなら、2日間の集中ワークショップを自社で再現するのが現実的です。次の手順で進めます。
- 対象を選ぶ。 社内ツールや新しい小機能など、失敗しても影響が小さい新規案件を選びます。typo修正や仕様確定済みの案件は外します。
- メンバーを決める。 エンジニア4〜6名とビジネス担当2名、計6〜8名を目安にします。AI操作役とレビュー担当を最初に指名します。
- サンドボックス環境を用意する。 本番コードや機密データから切り離したリポジトリに、OSSのワークフローを導入します。AI環境にはClaude Codeなどを使えます。Claude Codeの概要はこちらで確認できます。
- 1日目にMob Elaborationを行う。 ビジネス上の目的から、AIの質問に全員で答え、要件とUnit of Workまで確定します。
- 2日目にMob Constructionを行う。 Unitごとに、設計・コード・テストを1つのBoltで回します。
- 振り返りで3つを記録する。 実際にかかった時間、レビューに費やした工数、手戻りの回数です。
最後の記録が、本格導入の判断材料になります。公開事例の数字を鵜呑みにするより、自社の数字を2日間分でも取るほうが、社内の説得力は段違いです。
PoCから社内定着までの全体設計は、AI駆動開発導入の進め方で扱っています。
よくある質問
AI-DLCとは何ですか？
AIが計画と質問を出し、人が判断・承認する開発方法論です。要件定義から運用までのプロセス全体を、AIを前提に組み直します。
AI-DLCとスクラムは併用できますか？
併用ではなく、置き換えを前提にした設計です。ただしアジャイルの考え方は引き継いでおり、スプリントはBolt、エピックはUnit of Workに対応します。
AI-DLCと仕様駆動開発（SDD）の違いは何ですか？
レイヤーが違います。AI-DLCはチーム全体の進め方、SDDは個々の機能の作り方です。InceptionのUnit of Workが、Kiroの仕様の入力になります。
AI-DLCはKiroやAmazon Q Developerでしか使えませんか？
いいえ、他のツールでも使えます。方法論はツールに依存せず、現行のOSS実装はClaude Code、Cursor、Codex CLI、GitHub Copilotなどにも対応しています。
小さな修正や仕様が固まった案件にも向いていますか？
向きません。工程を回すコストのほうが大きくなります。新規開発や、要件のすり合わせが必要な案件から始めてください。
まとめ
最初にやることは、全社展開の検討ではなく、6〜8名で2日間の試行を設計することです。対象は新規の小さな案件、AI操作役とレビュー担当を指名し、時間・レビュー工数・手戻りを記録する。この3点で、自社に合うかが判断できます。
その先で問われるのは、ツールではなく人の側です。AIの提案を承認できるレビュー能力と、同期して判断する習慣は、AIが賢くなっても代替できません。ここが育っていないチームは、AI-DLCを入れても速くなりません。
こうした進め方をチームに定着させる手段として、当協会のAI駆動開発研修があります。AIに計画を任せ、人が判断・承認する開発の型と、レビューできる人材の育て方を、実務に近い形で身につけられます。
