AI-DLCとは：AWSが提案する仕組みを事例で理解する
この記事で学べること
- AI-DLCと、似た略称を持つAIシステム開発ライフサイクルの違い
- 初期版の3フェーズからWorkflows 2.0の5フェーズへ変わった点
- 公式チュートリアルで人とAIの作業が進む順序
- 方法論、ワークフロー、公開実装、組織統制を分ける4層の見方
- チームで試行導入する前に使える判定チェックリスト
AI-DLCは人の計画と承認を挟みながらAIで開発を進める
AI-DLCは、AIが計画と作業を支援し、人が要所で判断する開発の進め方です。
「この機能を追加して」とAIへ頼んでも、誰のための機能か、どこまで変えてよいか、何を確認すれば完成かは自動では決まりません。依頼を計画、承認、実行、検証へ分けることで、人が判断する場所とAIへ任せる作業を区別できます。
この記事では、「AI-DLCでは人とAIがどの順で作業し、導入前に何を決めるべきか」という問いに焦点を当て、中心概念の仕組み、混同しやすい境界、実務での判断材料を扱います。
最後まで読むと、「AI-DLCでは人とAIがどの順で作業し、導入前に何を決めるべきか」という問いを、自分の状況に照らして判断するための材料を持ち帰れます。
AIシステムの開発工程とAWSのAI支援開発手法を区別する
AI-DLCという表記には、少なくとも2つの使われ方があります。1つはAIシステム自体を企画し、学習させ、評価し、運用する一連の流れです。もう1つは、AIに計画や作業を手伝わせながらソフトウェアを開発する流れです。本記事で扱うのは、AWSが2025年に公表した後者のAI-Driven Development Life Cycleです。[1]
2026年8月29日までに本記事で確認した一次資料の範囲では、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年に公表された方法は、企画、構築、運用の3段階で説明されていました。[1] 現在公開されている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は版によって実装範囲が異なる
初期の公開手順では、利用開始と監視が将来対応として残っていました。現在の2.0では、Operationに「公開までの自動手順、利用環境の準備、公開の実行、稼働状況の把握、障害対応、性能確認、利用結果を受けた改善」の7工程が定義されています。[4][5]
ただし、工程が定義されたことと、自社環境で安全に運用できることは別です。使用する版と実装範囲を確認し、自社の自動テストと公開手順、監視、障害対応、変更承認へどう接続するかを設計する必要があります。
Altisource事例は既存コード・案件・設計資料を接続する効果を示す
AWSの顧客事例では、AltisourceがAmazon Q DeveloperをJira、Bitbucket、Figma、データベースへ接続し、既存コード、案件情報、設計資料を参照できるAI-DLCを整備したと報告されています。開発者は、アプリケーション全体の解析、処理ルールの文書化、利用者が見る画面と裏側の処理にまたがる変更提案に利用しました。[6]
この事例が示すのは、AI-DLCの価値がコード生成機能だけでは決まらないことです。既存システムの制約、設計資料、作業項目を同じ文脈へ接続し、計画とレビューへ使える状態にしています。
同事例には、35万行を超えるレガシーJavaコードの更新、生産性や脆弱性件数の変化などが掲載されています。ただし、これはAWSが公開した顧客事例であり、AI-DLCだけの効果を独立比較した研究ではありません。[6] 自社で同じ効果を前提にせず、試行導入前に測定指標と比較条件を決める必要があります。
AI-DLCの方法論・作業手順・公開実装・組織統制を分ける
ここでは、方法論と製品機能を混同しないためにAI-DLCを次の4層へ分けます。AWSの公式分類ではありません。
| 層 | 確認する対象 | 導入時の問い |
|---|---|---|
| 方法論 | AIが計画・実行し、人が判断・検証する原則 | 人が判断すべき箇所を定義できるか |
| 作業の流れ | 5段階、条件によって行う工程、作業の分け方 | 案件の種類に応じて確認の深さを変えられるか |
| 公開されている手順 | ルールファイル、作成される資料、実行できる工程 | 自分たちが使うAIでも同じ流れを実行できるか |
| 組織の管理 | 利用権限、自動確認、人のレビュー、記録、運用担当 | AIの提案を検査し、必要なら実行を止められるか |
4層のうち、公開実装だけを導入しても、受け入れ条件や責任分担がなければ形だけの承認になりやすくなります。反対に、既存の開発手順が機能しているチームは、方法論の一部だけを取り入れ、要件質問や実装前計画の品質を改善する選択もできます。
小さな修正や緊急対応では適用範囲を絞る
AI-DLCは、要件の不確実性が高い機能開発、既存システムの解析が必要な変更、複数職種の判断をつなぐ案件に向いています。次の条件では、すべての工程を適用すると確認作業の負担が便益を上回る場合があります。
- 変更箇所と正解が明確な小さな修正
- 即時復旧が優先されるインシデント対応
- 自動テストやレビュー担当者がなく、成果物を検証できない案件
- 機密情報をAIへ渡せる範囲が決まっていない環境
- 運用担当とリリース責任者が決まっていないプロジェクト
Adaptive Workflowは不要なステージを省く考え方を持ちますが、何を省いてよいかの最終判断は人が行います。緊急対応では既存のインシデント手順を優先し、事後レビューでAI-DLCの成果物へ判断を戻す運用が現実的です。
試行導入前のチェックリスト
最初から全社標準にせず、影響範囲を限定した1案件で確認します。次の各項目に「はい」と答えられない場合は、その項目を試行導入の前提作業にします。
- 解決する業務課題と、作らない範囲を1段落で説明できる
- 機能要件と非機能要件の受け入れ条件がある
- AIが作る計画と成果物を確認する担当者と時間を確保している
- コード、テスト、設計資料、課題管理情報の参照範囲を決めている
- 権限設定、テスト、CI、レビューで実行を止められる
- 導入前後で比較する指標と測定期間を決めている
- 不具合時のロールバックと責任者を決めている
- 公開実装が未対応の工程を既存プロセスで補える
評価指標は、作業時間だけに限定しません。要件の手戻り、レビュー修正回数、テスト失敗、欠陥、監査記録の欠落など、品質と統制も同時に確認します。比較条件を事前に決めることで、AI-DLCの効果と、ツール変更や担当者差による影響を分けやすくなります。
まとめ：AI-DLCは小さな案件で人の承認と検証を測る
AWS AI-DLCは、AIに開発のすべてを委譲する仕組みではありません。AIが計画、質問、実行を担い、人が業務文脈、承認、検証、責任を担う開発ライフサイクルです。現行2.0は、Initialization、Ideation、Inception、Construction、Operationの5フェーズで、着手判断から公開後の改善までをつなぎます。
公開情報だけでは、AI駆動開発フレームワークの採用率1位を決められません。AWS AI-DLCは、方法論、公開ワークフロー、公式チュートリアル、企業事例を追跡できる代表例として学ぶ価値があります。導入時は4層を分け、公開実装の範囲と組織側の統制を確認したうえで、小さな案件から測定してください。
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
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。