AIDLC(AI-Driven Development Life Cycle)
既存プロセスの体系 ／ 種別: ライフサイクルプロセス(開発の全工程)
AIエージェントが計画・要件・コード・テスト・インフラ構成の生成をライフサイクル全段でオーケストレーションし、人間は各要所で検証・承認・重要判断を担う、AIを中心に据え直した開発方法論(AWS が2025年に提唱)
ひとことで言うと: 「AIが開発を回し、人は WHAT と WHY を決めて要所で承認する」進め方。従来の2〜4週スプリントを数時間〜1日の「Bolt」に縮め、全ロールが同席する「Mob」でAI生成物をその場で検証する。本プロジェクトが現実へ落とし込もうとしている理想像(To)であり、ここでは「今どう語られているか」を整理する
全体マップ(第1階層)
各フェーズをクリックすると、フェーズ内のワークフロー(第2階層)へ移動します。
graph LR
ph0["Inception(構想)"]
ph1["Construction(構築)"]
ph0 -->|"Mob Elaboration 合意点"| ph1
ph2["Operations(運用)"]
ph1 -->|"計画承認(plan-verify) / Mob Construction チェックポイント"| ph2
gEnd{"承認+トレーサビリティ監査(規制業界)"}
ph2 --> gEnd
click ph0 "/process-compass/processes/aidlc/inception/" "Inception(構想)の詳細へ"
click ph1 "/process-compass/processes/aidlc/construction/" "Construction(構築)の詳細へ"
click ph2 "/process-compass/processes/aidlc/operations/" "Operations(運用)の詳細へ"目的と成果
目的(purpose): AIを開発ライフサイクルの中心に据え直し、AIが計画・生成・テスト・デプロイを回し、人間は WHAT/WHY と重要判断に集中することで開発速度・品質・整合性を飛躍させる(提唱者の建前)
成果(outcomes):
- 「数週間かかっていた作業を数時間〜数日で」— re:Invent では 10〜15倍の生産性向上を主張(AWS 発の自己申告、独立検証は未確認)
- business intent → user story → requirement → code → test の end-to-end トレーサビリティ
- 逐次ハンドオフを排し、全ロールが同期して意思決定する
原典: AWS。原典ブログ 2025-07-31(著者 Raja SP)、re:Invent 2025 DVT214 で本格発表。実装は awslabs/aidlc-workflows(MIT-0)
ISO/IEC/IEEE 12207 対応: 主に「テクニカル(要件〜実装〜運用を全域でAIに再配分)。合意・組織・マネジメント系(責任・決裁・品質保証)は言説では薄く、それが懸念点になる」プロセス群をカバー
ロール
| ロール | 責任 | 日本の現場での実態 |
|---|---|---|
| AIエージェント(実行主体) | タスク分解、代替案生成、要件/ストーリー/コード/テスト/IaC の生成、リファクタリング、ワークフローのオーケストレーション | 生成物の正しさは保証されない(ハルシネーション)。責任主体になれない |
| 人間(意思決定主体、総称) | アーキテクチャ判断、ビジネス整合、リスク評価、倫理・品質判断、重要判断の承認。「AI may drive workflows, but humans remain responsible」 | 生成速度に対し人間の検証が追いつかず「passive approver(受動的承認者)」化するリスク。これが理想像の最大の脆弱点 |
| プロダクトマネージャー | Mob セッションでビジネス意図・優先度を提示し、WHAT/WHY を確定する | 日本では事業部門と情シスの分離により不在になりがち |
| 開発者 | Mob で技術判断・実装レビュー、AIへの技術的指針を与える。役割が「書き手」から「検証者・判断者」へ移行する | — |
| QA | Mob で品質観点の検証、テスト妥当性の確認を行う | 日本の独立QA部門による組織上独立した検証と Mob(同席レビュー)の同期協働は噛み合わない(独立性 vs 同期のジレンマ) |
| Operations | Mob で運用/インフラ観点を提示する | Operations フェーズ自体が現状 placeholder で未成熟 |
ゲート(決裁・レビュー)
| ゲート | 種別 | Deliverables | 判定基準 | 判定者 | 判定結果 |
|---|---|---|---|---|---|
| Mob Elaboration 合意点 ※4時間〜半日で全員合意して終える。AIも豊富なコンテキストを獲得する | 決裁(Go/Kill) | 要件 / ストーリー / ユニット | 作るもの/ストーリーに全員が合意 | Mob参加者(PM/Dev/QA/Ops) | 合意して次へ / 差し戻し |
| 計画承認(plan-verify) | 決裁(Go/Kill) | AIが提示した実行計画 | AI creates plan → humans validate the plan | 人間(担当ロール) | 承認して実行 / 修正指示 |
| Mob Construction チェックポイント ※重要判断がAI出力に暗黙に飲み込まれないよう明示的に人間へ上げる(The agent proposes, the human approves) | 決裁(Go/Kill) | アーキ/ドメインモデル/コード/テスト案 | 技術判断・アーキ選択の妥当性 | Dev中心のMob | 承認 / 技術指針を与えて再生成 |
| 承認+トレーサビリティ監査(規制業界) | 決裁(Go/Kill) | コード〜要件の連鎖 | steering files 準拠 / 監査可能性 | 人間(監査/責任者) | 承認 / 是正 |
成果物(information items)
| 成果物 | 作成者 | 説明 |
|---|---|---|
| ビジネス意図(business intent) | プロダクトマネージャー | Inception の入力 |
| 要件・ユーザーストーリー・ユニット(units of work) | AIエージェント(実行主体) | AI生成 → Mob検証。Construction の入力コンテキストになる |
| 論理アーキテクチャ / ドメインモデル | AIエージェント(実行主体) | AI生成 → Mob検証。コード生成の基盤 |
| コード+テスト | AIエージェント(実行主体) | AI生成 → Mobレビュー。テスト失敗で self-correct する |
| IaC / デプロイ構成 | AIエージェント(実行主体) | AI生成 → チーム監督。本番運用へ |
| Steering files(ステアリングファイル) | 人間(意思決定主体、総称) | 人間(組織)が事前定義。全フェーズでAIの生成を制約する(セキュリティポリシー、アーキ標準、規制ガイドライン=EU AI Act 等、責任あるAI原則) |
暗黙の前提条件(これが崩れると成立しない)
- 高品質なモデル — 生成物が実用水準に達し、ハルシネーション率が人間の検証で吸収できる範囲であること
- 明確な仕様/意図 — Inception で「作るものに全員が合意」できるだけビジネス意図が言語化可能であること(レガシー・暗黙知の多い現場ほど崩れる)
- 検証の自動化 — AIの自己検証が機能する前提として包括的な自動テストとCI基盤が既にあること。テストの正しさ自体は誰が保証するか未解決
- 信頼できるガードレール — steering files が組織標準・規制・セキュリティを正しく符号化できていること
- 人間の検証キャパシティ — 生成速度(Bolt=時間単位)に人間の判断が追随できること(「人が管理できる賢さ/速さの上限」論点)
- 明確な責任者(Clear ownership)と強い品質ゲートが存在すること
アンチパターン(建前 vs 実態)
受動的承認者(rubber stamp)化
| 建前(あるべき姿) | 重要判断を明示的に人間へ上げ、人間が実質的に検証・承認する |
|---|---|
| 実態 | 生成速度に検証が追いつかず、チェックポイントが形骸化して人間が中身を見ずに承認する |
| なぜ起きるか | Bolt が時間単位で回るのに対し、人間の検証帯域が有限だから |
| 弊害 | 品質・セキュリティ事故。AI-DLC 自身が「keep humans from becoming passive approvers」を設計目標に挙げるほど本質的リスク |
ドキュメントの陳腐化
| 建前(あるべき姿) | 各フェーズの生成ドキュメントが実装と同期し続ける |
|---|---|
| 実態 | 大量生成されたドキュメントがコード変更に追随せず、すぐ陳腐化する |
| なぜ起きるか | 作るより維持が難しく、追随の仕組みがないため |
| 弊害 | トレーサビリティの前提が崩れ、監査・規制レビューの根拠が失われる |
責任分界の空白
| 建前(あるべき姿) | 「humans remain responsible」— 人間が責任を持つ |
|---|---|
| 実態 | どの承認が誰の法的/契約的責任かが方法論に規定されず、宣言だけが残る |
| なぜ起きるか | AIエージェントは責任主体になれず、自律エージェントの責任論が未整備だから |
| 弊害 | 障害・瑕疵の際に責任の所在が定まらない |
建前と実運用(日本の現場)
- 多段稟議・DR・投資決裁は週〜月単位だが Bolt は時間単位。決裁が構造的に追いつかず「AIは回るが承認が詰まる」ボトルネックが予測される
- 日本の独立QA部門・品質保証部による組織上独立した検証は、QA を Mob(同席レビュー)に取り込む AI-DLC の前提と噛み合わない(独立性 vs 同期協働のジレンマ)
- SI受託では成果物レビューが検収を兼ねるが、「何を検収対象とするか(コード/意図/プロンプト)」「AI生成物の瑕疵担保責任は受注者か発注者か」が契約上未整備
- 実運用では(1)管理職が全チェックポイントで実質再レビューし速度優位が消える、(2)決裁が形骸化しAI生成物を無検証で通す、の両極に振れやすい。中庸(実効的な Human-in-the-loop)を保つ組織能力が要る
フェーズ一覧(第2階層へ)
- Inception(構想) — ビジネス意図を要件・ストーリー・ユニットへ変換する。Mob Elaboration で全員がAIの問い・提案をリアルタイム検証する
- Construction(構築) — 検証済みコンテキストを使いAIが論理アーキテクチャ・ドメインモデル・コード・テストを提案する。Mob Construction でチームがリアルタイムに指針を与える
- Operations(運用) — 蓄積コンテキストでAIがIaC・デプロイ・監視を管理する(チーム監督下)。現状は placeholder で未成熟