AI-DLCとは：AWSが提案する仕組みを事例で理解する
この記事で学べること
- AI-DLCと、似た略称を持つAIシステム開発ライフサイクルの違い
- 初期版の3フェーズからWorkflows 2.0の5フェーズへ変わった点
- 公式チュートリアルで人とAIの作業が進む順序
- 方法論、ワークフロー、公開実装、組織統制を分ける4層の見方
- 試行導入にあたって確認したい前提条件と留意点
AI-DLCにおける人とAIの役割
AI-DLCは、AIが計画案や成果物を作り、人が要所で判断する開発の進め方です。本記事では、AWSが2025年に公表したAI-Driven Development Life Cycleを扱います。[1]
たとえば、AIに「この機能を追加して」と依頼しても、誰のための機能か、どこまで変更してよいか、何を確認すれば完成といえるかは、その一言だけでは伝わりません。
AI-DLCでは、こうした依頼を計画・承認・実行・検証に分けます。AIが計画案や質問を作り、人が目的や条件を補って承認します。その後、AIが作業し、人が成果物を確認する流れです。
本記事では、公式チュートリアルと企業事例をもとに、この流れを説明します。あわせて、導入前に決めておきたいことや、既存の開発手順との関係を整理します。AI-DLCの採用手順や組織展開の計画までは扱いません。
AIシステムの開発工程と、計画・実装にAIを使うAWSの手法の違い
AI-DLCを理解するときは、AIシステム自体の開発ライフサイクルと区別する必要があります。前者は、AIモデルやAIシステムを作る側が、企画、学習、評価、運用を進める流れです。[7] 本記事で扱うAWSのAI-DLCは、AIに計画や作業を手伝わせながらソフトウェアを開発する方法を指します。[1]
2026年9月21日までに本記事で確認した一次資料の範囲では、AIを使う開発方法を横断して採用率を比較した公開調査を確認できませんでした。そのため、AWS AI-DLCを「市場シェア1位」とは位置付けません。公式の考え方、誰でも内容を確認できる作業手順、手順を追える教材、企業事例がそろった代表例として選びます。[2][3][4][6]
GitHubのStar数、対応ツール数、記事数から分かるのは、関心の大きさです。
組織で継続利用されている割合とは一致しません。導入時は人気の順位ではなく、自分の開発工程で同じ手順と確認結果を再現できるかを見ます。
中心にあるのは「計画・承認・実行・検証」の反復
AWS AI-DLCの中核は、AIがすべてを自律的に決めることではありません。AIが計画案と確認事項を作り、人が業務文脈を補い、承認後にAIが実行し、人が成果物を検証する反復です。[1][2]
通常のチャット利用では、「機能を追加して」という依頼から実装へ直行しやすくなります。AI-DLCでは、要件、設計、実装、テストなどの各段階で同じ反復を使い、判断と成果物をファイルとして残します。監査証跡（誰が何を確認し、どの判断で進めたかを後から追える記録）を作りやすくする設計です。[3]
ただし、見出しや箇条書きで記述したルールファイルだけで安全性や品質を保証できるわけではありません。実際に変更を止めるには、権限設定、テスト、CI（変更を自動チェックする仕組み）、承認手順などの実行可能な統制が別に必要です。
現行AI-DLCは準備から運用まで案件別に工程を調整する
2025年に公表された方法は、Inception（計画と全体構成）、Construction（設計と実装）、Operations（公開と監視）の3段階で説明されていました。[1][3] 現在公開されているAI-DLC Workflows 2.0は、準備、構想、要件整理、構築、運用の5段階と33の作業工程を定義しています。[4][5]
| 2.0のフェーズ | 答える問い | AIに任せる主な作業 | 人が判断すること |
|---|---|---|---|
| Initialization（準備） | どの環境で始めるか | AIが使う保存場所と進捗記録を準備する | 開始する場所や対象が正しいか確認する |
| Ideation（構想） | 取り組む価値と実現可能性があるか | 目的、調査結果、制約、範囲、体制、初期案を整理する | 着手するか、どこまでを対象にするか決める |
| Inception（要件整理） | 何を、なぜ作るか | 現在の仕組みを調べ、必要な機能、全体構成、作業計画を提案する | 目的、完成とみなす条件、優先順位を決める |
| Construction（構築） | どう作るか | 機能、速度や安全性などの条件、コード、テストを作る | 全体構成、制約、確認結果、品質基準を判断する |
| Operation（運用） | どう公開し、維持するか | 利用開始の準備、監視、障害対応、性能確認、改善を支援する | 公開してよいか、誰が操作できるか、問題時に元へ戻す方法を決める |
すべての案件が同じ深さで5フェーズを通るわけではありません。公開ワークフローは、既存コードの有無、依頼の種類、複雑さを見て、必要なステージと検討の深さを提案します。小さな不具合修正と、新規サービス開発で同じ量の設計資料を要求しない点が、Adaptive Workflow（案件に応じて工程を調整するワークフロー）の特徴です。[2][4][5]
公式チュートリアルは要件の合意後に実装へ進む
AWSの2025年版公式チュートリアルの題材は、川渡りパズルを解く新規Webアプリです。単純な題材により、アプリ固有の技術ではなくAI-DLCの流れが説明の中心です。[3] このチュートリアルは初期の3フェーズ版ですが、「AIが計画し、人が承認する」という中核の反復は2.0にも引き継がれています。[4]
Inceptionで曖昧な依頼を開発可能な単位へ変える
最初の依頼は、AI-DLCを使って川渡りパズルのWebアプリを作る、という短い内容です。ワークフローは既存コードがないGreenfield（新規開発）と判断し、既存システムの解析を省いて要件分析へ進みます。[3]
AIは、採用するパズルの種類、操作方法、スコアを保存するか、ランキングが必要かなどを質問します。人が回答すると、AIは矛盾や未回答を確認し、次に実行するステージを計画します。単純なアプリでは不要と判断したユーザーストーリー作成を省くこともあります。
この時点で大切なのは、AIが「正しそうな仕様」を決めるのではなく、人が選べる形へ論点を変換することです。Inceptionの成果はコードではなく、合意済みの要件、受け入れ条件、実行計画です。
Constructionで計画をレビューしてからコードを作る
Constructionでは、AIが業務上の計算や判断、外部サービスとの接続、データ、テスト、文書、公開用ファイルを含むコード生成計画を作ります。計画は見出しや箇条書きを簡単な記号で書けるMarkdownファイルとして保存され、人が内容を変更または承認した後に実装へ進みます。[3]
これにより、レビュー対象が完成後の大量のコードだけになりません。「何を作る予定か」と「実際に何を作ったか」を分けて確認できます。要件の誤解を実装前に見つけられることが、AI-DLCの計画工程を置く理由です。
Operationは版によって説明の範囲が異なる
2025年版の公式チュートリアルは、コード作成とテストを終えた時点でワークフローを完了し、公開や監視の具体的な作業までは実演していません。[3] 現在の2.0では、Operationに「公開までの自動手順、利用環境の準備、公開の実行、稼働状況の把握、障害対応、性能確認、利用結果を受けた改善」の7工程が定義されています。[4][5]
ただし、工程が定義されたことと、自社環境で安全に運用できることは別です。使用する版と実装範囲を確認し、自社の自動テストと公開手順、監視、障害対応、変更承認へどう接続するかを設計する必要があります。
Altisource事例は既存コード・案件・設計資料を接続する効果を示す
AWSの顧客事例では、AltisourceがAmazon Q DeveloperをJira、Bitbucket、Figma、データベースへ接続したと報告されています。これにより、AIが既存コード、案件情報、設計資料を参照できるAI-DLCの環境を整備しました。開発者は、アプリケーション全体の解析、処理ルールの文書化、利用者が見る画面と裏側の処理にまたがる変更提案に利用しました。[6]
この事例が示すのは、AI-DLCの価値がコード生成機能だけでは決まらないことです。既存システムの制約、設計資料、作業項目を同じ文脈へ接続し、計画とレビューへ使える状態にしています。
同事例には、35万行を超えるレガシーJavaコードの更新、最大25%の生産性向上、コードの脆弱性54%減が掲載されています。[6] ただし、これはAWSが公開した顧客事例であり、AI-DLCだけの効果を独立した条件で比較した研究ではありません。自社でも同じ効果が得られると考えるのではなく、数値の測り方や比較条件が自社の状況に合うかを確認する必要があります。
AI-DLCの方法論・作業手順・公開実装・組織統制を分ける
ここでは、方法論と製品機能を混同しないためにAI-DLCを次の4層へ分けます。AWSの公式分類ではありません。
| 層 | 確認する対象 | 導入時の問い |
|---|---|---|
| 方法論 | AIが計画・実行し、人が判断・検証する原則 | 人が担う判断を具体化できるか |
| 作業の流れ | 5段階、条件によって行う工程、作業の分け方 | 案件の種類に応じて確認の深さを変えられるか |
| 公開されている手順 | ルールファイル、作成される資料、実行できる工程 | 自分たちが使うAIでも同じ流れを実行できるか |
| 組織の管理 | 利用権限、自動確認、人のレビュー、記録、運用担当 | AIの提案を検査し、必要なら実行を止められるか |
4層のうち、公開実装だけを導入しても、受け入れ条件や責任分担がなければ形だけの承認になりやすくなります。反対に、既存の開発手順が機能しているチームは、方法論の一部だけを取り入れ、要件質問や実装前計画の品質を改善する選択もできます。
小さな修正や緊急対応では適用範囲を絞る
AI-DLCは、要件の不確実性が高い機能開発、既存システムの解析が必要な変更、複数職種の判断をつなぐ案件に向いています。次の条件では、すべての工程を適用すると確認作業の負担が便益を上回る場合があります。
- 変更箇所と正解が明確な小さな修正
- 即時復旧が優先されるインシデント対応
- 自動テストやレビュー担当者がなく、成果物を検証できない案件
- 機密情報をAIへ渡せる範囲が決まっていない環境
- 運用担当とリリース責任者が決まっていないプロジェクト
Adaptive Workflowは不要なステージを省く考え方を持ちますが、何を省いてよいかの最終判断は人が行います。緊急対応では既存のインシデント手順を優先し、事後レビューでAI-DLCの成果物へ判断を戻す運用が現実的です。
試行導入における前提条件と留意点
AI-DLCを試す前に、解決したい業務課題と対象外の範囲を区別し、機能や性能、安全性について何を満たせばよいかを決めておく必要があります。この前提が曖昧なままでは、AIが詳しい計画を作っても、人が承認や検証を行う基準を持てません。
AIが参照できる情報の範囲も判断に影響します。既存コード、テスト、設計資料、課題管理情報を使えるほど計画の文脈は増えますが、機密情報や個人情報まで無制限に渡せるわけではありません。利用するAIと接続先ごとに、参照を認める情報と操作権限を分けて考える必要があります。
人の確認を置くことと、問題のある実行を実際に止められることも別です。AIが作った計画や成果物を確認する役割に加え、権限設定、テスト、CI、変更承認、問題発生時に元へ戻す方法を既存の開発・運用手順へ接続できるかが前提になります。公開実装が扱っていない工程は、自社の手順で補う必要があります。
効果を評価するときは、作業時間だけでは判断できません。要件の手戻り、レビューでの修正、テスト失敗、欠陥、監査記録の欠落なども、品質と管理の状態を知る材料になります。ただし、評価指標や比較期間を一律に決められるわけではありません。案件の規模、既存ツール、担当者の経験など、結果に影響する条件をそろえて比較しなければ、AI-DLCの効果だけを切り分けることは困難です。
まとめ：AI-DLC導入では人の判断と検証を設計する
AWS AI-DLCは、AIに開発のすべてを委譲する仕組みではありません。AIが計画、質問、実行を担い、人が業務文脈、承認、検証、責任を担う開発ライフサイクルです。現行2.0は、Initialization、Ideation、Inception、Construction、Operationの5フェーズで、着手判断から公開後の改善までをつなぎます。
公開情報だけでは、AI駆動開発フレームワークの採用率1位を決められません。ただし、AWS AI-DLCは、方法論、公開ワークフロー、公式チュートリアル、企業事例をたどれるため、人とAIの役割分担を考える代表例になります。
導入を検討するときは、ツールの機能だけでなく、誰が何を承認し、どの基準で成果物を検証し、問題があればどの仕組みで実行を止めるかを既存の開発・運用体制に結び付ける必要があります。方法論、ワークフロー、公開実装、組織統制を分けて見ると、自社に必要な準備と、既存手順を残すべき範囲を判断しやすくなります。
AIへ渡すルールと検証の考え方は、ハーネス（AIに渡すルール、手順、検証をまとめた仕組み）エンジニアリングとはとSpec-Firstの原則でも整理しています。
参考文献
- Amazon Web Services, AI-Driven Development Life Cycle: Reimagining Software Engineering, 2025年7月31日
- Amazon Web Services, Open-Sourcing Adaptive Workflows for AI-Driven Development Life Cycle (AI-DLC), 2025年11月29日
- Amazon Web Services, Building with AI-DLC using Amazon Q Developer, 2025年11月29日
- AWS Labs, AI-DLC — one core, many harnesses, AI-DLC Workflows 2.0
- AWS Labs, Phases and Stages, AI-DLC Workflows 2.0
- Amazon Web Services, Altisource boosts developer productivity by 25% with Amazon Q Developer
- National Institute of Standards and Technology, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile, 2024年7月26日
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。