はじめに
今回、AWS AI-DLC Unicorn Gymに参加し、システムへの機能追加を題材にAI-DLCを体験しました。
参加前は「AIがコードを書くことで開発が速くなる」というイメージを持っていました。しかし実際に体験してみると、変化していたのはコーディング速度そのものではなく、開発者が担う役割や意思決定のあり方でした。
AI-DLCでは、AIが不足している前提や未決事項を問いかけ、人が判断します。そして、その判断をもとにAIが計画、実装、検証を進めていきます。
本記事では、AI-DLCの概要だけでなく、実際に体験して感じた開発スタイルの変化について紹介します。
AI-DLCとは
AI-DLC は AI-Driven Development Life Cycle の略です。今回は AWS AI-DLC Unicorn Gym への参加を通じて体験しました。Unicorn Gym では、チームでテーマを定め、AI を開発プロセスに組み込みながら、企画から構築・運用までを実践します。
AI-DLC は次の 5 フェーズで進みます。
1. Initialization（初期化）
2. Ideation（意図とスコープの整理）
3. Inception（要件と設計の立ち上げ）
4. Construction（構築）
5. Operation（運用）
ポイントは、コード生成だけで終わらないことです。意図とコンテキストに応じて工程と深さを選び、計画・成果物・承認をつなげます。
| 仕組み | 役割 |
|---|---|
| 適応的なワークフロー | 目的・規模・リスクに応じて、必要な工程と深さを選ぶ |
| 質問と回答の記録 | 判断の理由を後から追える |
| 承認ゲート | 重要な判断や変更を人が確認する |
| 学びの蓄積 | 失敗や訂正を次の工程へ引き継ぐ |
工程選択、深さの調整、人による継続的な検証は、AI-DLC の方法論として説明されています1。承認ゲートも特定バージョンだけの機能ではなく、方法論の原則です。
AI-DLC Workflows v1 / v2で何が変わったか
AI-DLC と AI-DLC Workflows の意味だけ簡単にまとめます。
- AI-DLC: AWS が提唱する開発方法論
- AI-DLC Workflows: その方法論を AI コーディングエージェント上で実行する OSS 実装2
v1 / v2 は、方法論ではなく AI-DLC Workflows のバージョンです。今回利用したのは v2 でした。
| 観点 | v1 | v2 |
|---|---|---|
| 実装方式 | Markdown 中心のルール・ステアリングファイル | TypeScript によるネイティブ実装 |
| 進行の判断 | LLM の解釈に委ねられる部分が大きい | 決定論的なエンジンがルーティングを担う |
| 進行状況 | 会話・成果物から追う | 状態ファイルと監査ログで追える |
| 承認・検証 | 承認は方法論として存在し、記録や分担は利用者側で設計する | 承認状態、監査、レビュー役を仕組みとして持つ |
| 学び | 会話や成果物に残る | 人からの訂正をルールとして蓄積し、次の工程で読む |
v2 で決定論的になったのは、次にどの工程を実行するかという進行判断です。工程内の計画、成果物の生成、質問の組み立ては引き続き AI（LLM）が担います。エンジンが進行を、AI が実行を、人が意思決定と検証を担う役割分担です3。
構成や数値はリリースで変わります。最新情報は公式ドキュメント3を確認してください。
どういった開発体験を得られたか
1. 完成した要件を渡すのではなく、対話を通じて要件を固めていく
AI-DLCでは、最初から完成された要件を用意してAIへ渡すのではなく、AIから提示される質問に答えながら、要件を少しずつ明確にしていきます。
AIは、実現したいことを受け取ると、制約条件や前提、まだ決まっていないことを整理し、判断が必要な項目として人に問いかけます。人はその質問に答えることで、「何を実現するか」だけでなく、「今回は何を対象外とするか」まで具体化できます。
要件を一度に決め切るのではなく、AIとの対話を通じて曖昧さを減らしていく進め方は、今回の体験で特に印象に残りました。
2. 開発者以外もプロセスを追いやすい
AI-DLCでは、AIとの質問と回答を通じて、検討している内容や判断、必要な点が順番に整理されます。そのため、設計書やコードを直接読み解かなくても、現在どのような検討を行い、何を決めようとしているのかを把握しやすくなります。
今回は開発者を中心に取り組みましたが、こうした進め方であれば、業務や企画、運用などの関係者も開発の途中で置き去りにならず、それぞれの立場から必要な判断に関わりながら、最後までプロセスを追いやすいと感じました。
3. 実装結果だけでなく、判断と検証状況を共有する
AI-DLCでは、何を作ったかだけでなく、なぜその方針を選んだのか、どの検証が完了しているのか、何が未確認なのかを記録できます。
例えば、テストを実行できなかった場合には、単に「未実施」とするのではなく、実行できなかった理由や、確認に必要な環境、次に判断すべき担当者を残せます。
これにより、「実装した」「テストが成功した」「実際の環境で利用できることを確認した」という状態を区別できます。
開発者には、コードを書くことに加えて、判断の背景やリスク、検証結果を次の工程や関係者へつなぐ役割が求められると感じました。
衝撃を受けたこと
1. AI-DLC は「AI → 人間」の開発体験だった
矢印は、次の行動を起こす主な対話の起点を表しています。
| 開発の進め方 | 主な流れ | 人の役割 |
|---|---|---|
| 従来の開発手法（ウォーターフォール / アジャイル） | 人間 → 人間 | 要件・計画を作り、チームで実装・レビュー・改善する |
| AI 支援開発（プロンプト中心） | 人間 → AI | 作業を分解して指示し、出力を確認・修正する |
| AI-DLC | AI → 人間 | AI が不足した前提や判断点を示し、人が決定・検証する |
AWS AI-DLC Unicorn Gym に参加するまでは、AI-DLCは「AIにコードを書かせる手法」だと思っていました。しかし実際には、AIが要件や設計上の曖昧さを問いとして提示し、人が判断を重ねることで開発が進みます。AIによって実装が自動化されるほど、人には「何を、なぜ作るのか」を判断する役割が求められると感じました。
2. 後工程で見つかった問題は、上流に戻して解き直す
フェーズを進めても、前の工程で先送りにした問題が消えるわけではありません。Construction や Operation で実装・実行して初めて、要件の抜け漏れ、設計上の前提、運用の制約が問題として現れます。
そのとき、後工程だけでつじつまを合わせるのではなく、必要に応じて Inception に戻り、要件・設計・計画を見直します。AI-DLC では判断と成果物が残るため、どの前提を見直すべきかを追いやすく、上流からやり直す判断を取りやすいと感じました。
AI-DLCを使ううえで気をつけたいこと
- 小さな変更には重い: 軽微な修正まで同じ密度で進めると負担になるため、最初にスコープを絞る。
- 上流の判断ほど変更コストが高い: 前提を変えると後続の成果物を見直す必要がある。
- AI の出力を事実として扱わない: 実測値、ログ、レビュー、人による承認で裏付ける。
まとめ
AI-DLC を通じて、AI 時代の開発者の仕事は、コードを書く量を減らすだけではないと感じました。
- AI が判断点を示し、人が意思決定と検証を行う
- 開発者は、実装に加えて意図・リスク・検証をつなぐ
- 非技術者も構築の途中から参加できる
- 未検証事項と失敗を、次の判断へ引き継げる
AI がすべてを決めるのではなく、人が決めるべきことを見えやすくする。これが今回体験した AI-DLC の価値だとわかりました。
参考文献
-
Open-Sourcing Adaptive Workflows for AI-Driven Development Life Cycle (AI-DLC) — AWS DevOps Blog。適応的な工程選択、深さの調整、人による意思決定と検証。 ↩
-
awslabs/aidlc-workflows — AI-DLC Workflows の実装リポジトリと対応ツール。 ↩
-
AI-DLC Workflows ドキュメント — フェーズ・ステージ構成、エージェント構成、エンジンと実行の役割分担。 ↩ ↩2