AI-DLC（AI駆動開発ライフサイクル）とは？仕組み・Bolt・導入事例を解説

AI-DLC（AI-Driven Development Life Cycle＝AI駆動開発ライフサイクル）は、AWSが2025年に提唱した、要件定義から設計・実装・運用までの全工程でAIを主役に据える開発方法論です。AIを実装補助として後付けするのではなく、AIが計画・コード・テストを生成し、人間は検証と意思決定に集中するよう役割を反転させます。従来のスプリントは数時間〜数日で回す「Bolt（ボルト）」に、エピックは「Unit of Work」に置き換わり、Intent・Mob Elaboration・Mob Constructionといった独自の用語体系を持ちます。本記事ではその仕組みと用語、3フェーズ、実際の導入事例、2026年に公開されたオープンソース実装まで整理します。

まとめ：AI-DLCの要点

• 提唱元と位置づけ：AWSが2025年に発表した方法論。AIを開発の中心に据え、人間は検証・意思決定に回る。
• 3フェーズ：Inception（何を作るか）→ Construction（どう作るか）→ Operations（動かす）。各フェーズをAIが主導し人間が検証する。
• 独自用語：Intent（意図）、Unit of Work（作業単位）、Bolt（数時間〜数日の作業サイクル）。スクラムのスプリント／エピックに対応する。
• 協働の要：チーム全員でAIの提案を詰めるMob Elaboration（Inception）とMob Construction（Construction）。
• 実装：2026年にawslabs/aidlc-workflowsとしてOSS公開。v2は2026年6月18日にプレビュー公開され、TypeScriptによる決定論的な実行エンジンを備える。Amazon Q Developer・Kiro・Claude Code・GitHub Copilotなどで利用できる。
• 実績：東京海上日動システムズが金融業界初のワークショップを実施し、通常数週間の作業を1.5日で形にした事例がある。

以下で、用語・フェーズ・協働の進め方・事例・課題・導入判断の順に掘り下げます。

AI-DLCとは何か：定義と登場した背景

AI-DLCは、ソフトウェア開発ライフサイクル（SDLC）そのものをAI前提で再設計する取り組みです。AWSは2025年、DevOps開発者向けブログ「AI-Driven Development Life Cycle: Reimagining Software Engineering」でこの方法論を公表しました。核心は、要件定義・設計・実装・テスト・運用の各工程でAIが一次成果物を生成し、人間がその妥当性を判断するという分担にあります。

AIをアシスタントから主役に反転させる考え方

従来のSDLCは人間がタスクを主導し、コード補完のようにAIを補助的に使う形でした。この使い方では、計画・会議・ドキュメント調整といった非コーディング作業がボトルネックとして残ります。AI-DLCはこの構造を反転させ、AIが計画・設計・コード・テストの草案を作り、人間はレビューと意思決定に専念します。人間が下流の検証に集中することで、要件から動くコードまでの往復回数を増やせる点がねらいです。

2025年に提唱された背景

背景には、Amazon Q DeveloperやClaude、GitHub Copilotなど生成AIによるコード生成・テスト自動化の精度向上があります。単一工程の効率化では全体のリードタイムが縮まりにくいという課題認識のもと、「工程横断でAIを組み込む」発想が生まれました。開発支援ツールの具体像はAmazon Q Developerの主要機能と特徴やCoding Agentの全体像も参考になります。

AI-DLCの基本用語：Intent・Unit・Bolt

AI-DLCは、AI主導のワークフローを表すために用語を刷新しています。スクラム経験者は、まず既存概念との対応で押さえると理解が早いです。

Intent（意図）：ビジネスゴールを高レベルで記述する起点

Intentは「ユーザー登録機能を追加したい」「レポートを自動生成したい」といった、何を作るかを端的に表した出発点です。抽象的なため、AIとの対話で具体化していきます。プロダクトマネージャーやステークホルダーがIntentを提示し、AIが必要な機能や要件を深掘りする流れになります。曖昧さを残さない記述が精度を左右するため、EARS記法による要件の明確化のような手法とも相性がよい領域です。

Unit of Work（作業単位）：Intentを分割した実装粒度

Unit of Workは、Intentを実現するための細かな作業単位です。エピックが大きな機能塊を指すのに対し、Unitはさらに小さく完結しやすい粒度で定義されます。AIはIntentを複数のUnitに分解し、それぞれを短期間で実装できるよう設計します。分割により、1つの大きな機能を複数のBoltで並行して進められるようになります。

Bolt（ボルト）：数時間〜数日で回す作業サイクル

Boltは、スクラムのスプリントに相当する反復サイクルですが、期間が桁違いに短いのが特徴です。スプリントが1〜4週間なのに対し、Boltは数時間から数日で1周します。AIがプランとコードの草案を出し、人間がすぐにレビュー・修正する反復を短時間で繰り返すため、フィードバックループの回転数が上がります。この短さこそが、AI-DLCがアジャイルと差別化される中核です。

AI-DLCの3フェーズ：Inception・Construction・Operations

AI-DLCはプロジェクトを、Inception（発案）→ Construction（構築）→ Operations（運用）の3フェーズで進めます。各フェーズの成果物はリポジトリに保存され、文脈を次フェーズへ引き継ぐことで、長期プロジェクトでも一貫性を保ちます。

Inceptionフェーズ：Intentを要件とUnitへ具体化する

Inceptionでは、AIが与えられたIntentを詳細な要件・ユーザーストーリー・Unitへ変換します。たとえば「新規顧客登録機能」というIntentに対し、AIは入力画面・入力チェック・DB登録処理などのUnitを提案します。この段階の検討会がMob Elaborationで、チームがAIの提案や疑問点を検証し、不足要素を補います。ここで作るべきタスクが確定します。

Constructionフェーズ：AIが設計・コード・テストを提案する

Constructionでは、Inceptionで固めた文脈をもとに、AIが論理設計・ドメインモデル・コード・テストを生成します。人間チームはMob Constructionでリアルタイムに技術判断を共有し、要件との整合を確認しながら修正します。AIの成果物が意図から逸脱しないよう逐次点検することで、速度と品質を両立させます。

Operationsフェーズ：IaCとデプロイをAIが支援する

Operationsでは、蓄積した文脈をもとにAIがInfrastructure as Code（IaC）やデプロイを支援し、人間が進捗を監視・承認します。ログやメトリクスの解析による異常検知をAIが担う想定もあり、運用フェーズでも定型作業をAIに寄せ、チームは改善検討にリソースを回せます。

モブエラボレーションとモブコンストラクション：AIと人間の協働

AI-DLCの実効性を左右するのが、チーム全員が同席してAIの提案を詰める「モブ（Mob）」形式の協働です。AIが出すのはあくまで草案であり、人間の知見をその場で反映することで、曖昧な提案を意図に沿った成果物へ収束させます。

モブエラボレーション（Mob Elaboration）：Inceptionでの要件詰め

モブエラボレーションは、Inceptionフェーズでチーム全員が集まり、AIが出したIntentやUnitに意見を出し合う検討会です。ビジネス要件に不足があればその場で補い、Unit化の粒度を調整します。AIが投げかける質問に対して人間がドメイン知識を回答することで、AI側の文脈も補強されます。要件の抜け漏れをこの段階で潰しておくと、後工程の手戻りを減らせます。

モブコンストラクション（Mob Construction）：Constructionでの実装レビュー

モブコンストラクションは、Constructionフェーズで、AIが生成した設計・コード・テストを全員でレビューする場です。たとえばAIが生成した画面コードに対し、エンジニアがUI要件との適合を確認しながら修正します。対話的に技術判断を共有することで、レビュー待ちの滞留を減らし、実装方針をその場で決められます。

AIと人間の役割分担：どこまで任せ、どこを人が担保するか

AIは計画立案・コード生成・テスト作成といったルーティンを担い、人間は要件定義・重要な意思決定・最終レビューに注力します。とくにセキュリティ・法規制・ビジネス上の制約など、AIが把握しきれない文脈の判断は人間の責務です。AIが生成したコードにも静的解析やレビューを適用し、誰がどの成果物を承認するかを事前に定めておくことで、責任範囲を明確にします。反復プロセスでAIと協働する進め方は、AIエージェント活用によるチケット駆動開発（TiDD with Agent）とも発想が重なります。

従来手法との違い：アジャイル・SDLC・AI-SDLCとの比較

AI-DLCはアジャイルの拡張に見えますが、役割分担とサイクル長で明確な違いがあります。混同されやすい「AI-SDLC」との切り分けも押さえておきましょう。

アジャイル（スクラム）との違い

スクラムでは数週間のスプリントで区切り、プロダクトオーナーが優先順位を管理します。AI-DLCではスプリントが数時間〜数日のBoltに置き換わり、IntentをAIがUnitへ分解して優先度も考慮します。反復的にビジネス価値を届ける思想は共通ですが、AIが計画と実装の草案を主体的に作る点、そして反復の回転数が桁違いに速い点が異なります。

AI-SDLCとの違い：用語の混同を整理する

「AI-SDLC」や「SDLCへのAI活用」は、既存のSDLCの各工程にAIを取り入れる一般的な概念を指すことが多い言葉です。これに対しAI-DLCは、AWSが定義したBolt・Unit・Mobといった具体的な用語体系とプロセスモデルを伴う狭義の方法論です。「AIをSDLCで使う」全般の話か、AWSのAI-DLCという特定の方法論かを区別すると、情報を取り違えずに済みます。

DDD・TDDの統合：高度な設計手法をAIに担わせる

AI-DLCは、従来は適用に手間がかかったドメイン駆動設計（DDD）やテスト駆動開発（TDD）をAIと組み合わせる想定です。DDDでは専門知識をモデルへ反映する必要がありますが、AIにドメイン知識を与えることでモデル構築を早められます。TDDでは、要求仕様からAIが包括的なテストスイートを自動生成できるため、設計のベストプラクティスを一貫して適用しやすくなります。

AI-DLC Workflows：オープンソース実装とv2（2026年最新）

AI-DLCは概念だけでなく、実行を支援するワークフロー実装がオープンソースで公開されています。2025年時点の解説記事にはない最新の動きなので、導入検討ではここを押さえておくと差がつきます。

awslabs/aidlc-workflows：OSSとして公開

AWSはAI-DLCの適応型ワークフローを、GitHubのawslabs/aidlc-workflowsとしてオープンソース公開しました。これはAIコーディングエージェント向けの「ステアリングルール（進行制御ルール）」の集合で、プロジェクトの規模・複雑さに応じて実行する段階が変わるAdaptive（適応型）設計になっています。AWSのDevOpsブログ「Open-Sourcing Adaptive Workflows for AI-Driven Development Life Cycle」で発表されました。

v2の変更点：TypeScript実装と決定論的エンジン

AI-DLC Workflows v2は、2026年6月18日にプレビュー公開されました。ネイティブなTypeScript実装へ作り直され、決定論的な実行エンジンと状態管理が加わっています。ルールベースで進行を制御する方向を強め、再現性の高い実行を狙った刷新です。プレビュー段階のため、最新の対応状況は公式リポジトリで確認してください。

対応するAIコーディングエージェント

aidlc-workflowsは特定ツールに縛られず、複数のAIコーディングエージェントで利用できます。公開情報では、Amazon Q Developer・Kiro・Cursor・Cline・Claude Code・GitHub Copilot・OpenAI Codexなどが対象として挙げられています。手元のエージェントにルールを読み込ませて、Inception相当のワークフローから試せる構成です。ツール選定の観点は仕様駆動開発（Spec-Driven Development）の解説も併せて参照すると整理しやすくなります。

AI-DLCの導入事例：東京海上・DMM・Gaudiy

AI-DLCは、AWSが主催する「AI-DLC Unicorn Gym」というワークショップ形式で各社が検証を進めています。ここでは公開されている実例を、数値とともに紹介します。

東京海上日動システムズ：金融業界初の取り組み

東京海上日動システムズは、2025年8月26〜27日に金融業界初となるAI-DLC Unicorn Gymを実施し、4チームが参加しました。2日間で各チームが動く初版を作り、1チームはテスト環境へのデプロイまで完了しています。通常なら数週間かかる開発タスクを約1.5日で形にした点が、生産性向上の実証として注目されました。同社は以前、レガシーJavaのサーバーレス化を効率化するコード生成基盤で外注コストを約30%削減しており、AI-DLCはその先の「工程横断での底上げ」を狙う位置づけです。

DMMほか各社のUnicorn Gym：見えてきた前提条件

DMM.comはAWS主催のUnicorn Gymに参加し、モブ形式で意思決定が高速化する一方、リモート環境での進め方や、ステークホルダーが多いことによるバッチサイズ問題、スコープの小ささが課題になると報告しています。以降も富士通・弥生・タイミー・mixiなどが参加し、2026年には東京での11社合同（1月）、大阪での9社合同（5月）といった合同開催も行われました。適用のコツとして各社が挙げるのは、AIを前提に業務フロー自体を作り替える必要性です。

Gaudiyの3ヶ月実践：ホワイトペーパーを自社流に運用

Gaudiyは2025年末に、AI-DLCを3ヶ月実践した知見を公開しました。AWSのホワイトペーパーの概念を自社流に解釈し、Claude Codeで運用できる形に落とし込んだうえで、従来より速いペースで開発を進められたと報告しています。ワークショップ単発ではなく、継続運用した視点での知見として参考になります。

AI-DLCの課題と、導入を判断する基準

AI-DLCには明確なメリットがある一方、技術・組織の両面に課題があります。効果が出やすい場面とそうでない場面を見極めたうえで導入範囲を決めます。

技術的・組織的な課題

技術面では、生成AIモデルのコンテキスト長の限界により、長大なプロジェクト全体の文脈を一度に把握しづらい制約があります。設計成果物をこまめにリポジトリへ保存して文脈を維持し、AIには小分けに情報を渡す工夫が有効です。組織面では、人間主導からAI中心へプロセスを変える文化的ハードルが大きく、リーダー層のコミットメントと、AIが理解しづらい暗黙知の形式知化（仕様書やドメイン知識の明文化）が前提になります。AIの誤りに備え、成果物ごとの承認フローを事前に定めておく必要もあります。

導入に向く場面・慎重にすべき場面

事例を踏まえると、AI-DLCが効きやすいのは、スコープを小さく切り出せる新規機能や、少人数で意思決定を完結できるチームです。Boltの短サイクルは、要件が明確でフィードバックを即座に反映できる状況で真価を発揮します。逆に、ステークホルダーが多くて承認に時間がかかる案件や、レガシーの依存関係が密で1つの変更が広範囲に波及するシステムでは、DMMが指摘したバッチサイズ問題が足かせになりやすく、いきなり全面適用するのは避けたほうが無難です。まず小さなユースケースでナレッジとテンプレートを蓄積し、運用ルールを整えてから広げる進め方が現実的です。なお「AIで10倍速くなる」といった大幅な速度向上はAWSが掲げる期待値であり、実際の効果は案件の性質に依存する点は割り引いて捉えるべきです。

よくある質問（FAQ）

AI-DLCとは何の略ですか？

AI-Driven Development Life Cycle（AI駆動開発ライフサイクル）の略です。AWSが2025年に提唱した、開発の全工程でAIを主役に据える方法論を指します。

Bolt（ボルト）とは何ですか？

スクラムのスプリントに相当する作業サイクルですが、期間が数時間〜数日と大幅に短いのが特徴です。AIの草案を人間がすぐレビュー・修正する反復を高速で回すための単位です。

モブエラボレーションとは何ですか？

Inceptionフェーズで、チーム全員が集まってAIが出したIntentやUnitを検証・補強する検討会です。実装レビューにあたるConstructionフェーズの検討会はモブコンストラクションと呼びます。

AI-SDLCとAI-DLCは違うものですか？

「AI-SDLC」は既存のSDLCにAIを取り入れる一般概念を指すことが多い言葉で、AI-DLCはAWSがBolt・Unit・Mobといった具体的な用語体系とともに定義した特定の方法論です。文脈でどちらを指すか区別すると混同を避けられます。

AI-DLCは無料で試せますか？

ワークフロー実装がawslabs/aidlc-workflowsとしてオープンソース公開されており、Amazon Q DeveloperやClaude Code、GitHub CopilotなどのAIコーディングエージェントに読み込ませて試せます。v2は2026年6月にプレビュー公開されています。

関連記事

• Amazon Q Developerの主要機能と特徴：開発支援の新しい形
• 仕様駆動開発（Spec-Driven Development）とは何か？従来の開発手法との違いから見るAI時代に注目される理由
• AIエージェント活用によるチケット駆動開発 (TiDD with Agent) の概要と背景を解説
• Coding Agentとは何か？AIによる自動プログラミング支援の全体像
• 要件の曖昧さを構文ルールで排除するEARS記法の基本定義と誕生経緯